Re: bashcompinit: sourcing /etc/bash_completion

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Thu, 11 Jun 2015 18:36:39 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Jun 11,  7:15pm, Daniel Hahler wrote:
> }
> } > } 
> } > }     local cword words=()
> } 
> } > Well, that's unfortunate.  In zsh "local" is not a special token, so the
> } > arguments are parsed as normal shell words, so you cannot have an array
> } > initialization as part of a "local" declaration.
> } 
> } Could this be easily improved, without breaking backward-compatibility?
> 
> If it could be easily improved, it would have been changed years ago.

It could, in principle, be very difficultly and time-consumingly
improved.

We need in any case to keep the builtin interface to handle cases like

  local=local
  $local -i i

which are valid --- the case

  $local array=(one two)

is not valid as there's no keyword to signal special parsing.

The old interface could be supplemented with a reserved word interface
that institutes special parsing, a mix of assignment and command lines.
The reserved word could be disabled leaving the builtin (they're in
different hash tables), so it would be possible to work around any
breakages or even leave it off by default if that turned out to be
necessary.

The bin_typeset code would then need to accept both methods.  The way to
do this would probably be to post-process the builtin interface to
deliver the right combination of normal arguments and scalar
assignments.  This is fundamentally mechanical, so if done carefully it
wouldn't break anything.

There are lots of fiddly little details like ensuring consistent option
parsing with the new interface.

If anyone has an enforced month of idleness...

pws