Re: Bug#519535: history expansion: modifier completion missing

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

[-bugs.debian.org]

On Mar 16,  6:18pm, Peter Stephenson wrote:
} 
} I thought this was going to be harder than it turned out to be; as you can
} see it's really quite simple, particularly since I already wrote modifer
} completion and it would appear had the foresight to make it handle the
} history case.

Nit-pick:  This doesn't handle the new :a/:A modifiers.

Other nit-pick about :a itself -- get a load of this:

torch% echo foo
torch% !!:a
/usr/local/src/zsh/zsh-build/echo foo
zsh: no such file or directory: /usr/local/src/zsh/zsh-build/echo

That's almost certainly not the intended behavior ... is it?  Replace :a
with :h or :t there and you get "modifier failed" (which seems odd as
well, but ...).

} It's in _normal which is where we handle normal command arguments.
} I think this is both the first and last place where get to massage
} command line arguments generically---we don't just want this in
} default completion since history expansion, if active, trumps
} everything else.

I started out agreeing with this, but now I'm not sure it makes any
difference.  History expansion trumps everything when it works, and
leaves the command line unchanged when it fails.  Notice:

schaefer<511> bindkey | grep expand
"^X*" expand-word
"^XG" list-expand
"^Xa" _expand_alias
"^Xe" _expand_word
"^Xg" list-expand
"^[ " expand-history
"^[!" expand-history
schaefer<512> !!<ESC!>
schaefer<512> bindkey | grep expand<C-u>
schaefer<512> !!:<ESC!>
schaefer<512> !!:

Same happens with <C-x*> or <C-xe> or even <C-xg> and <C-xG>.  If
history can expand, it does, if it can't, it doesn't.  If I try it
with <C-x?> (_complete_debug), I get an expansion with no backtrace
for !!, but a completion with backtrace for !!:.

So I think you can put this pretty much anywhere, as long as it's
somewhere that gets reached before the completion system gives up.
In fact in the unlikely event that one has a file named '!2:u2' one
might even want to be offered both history modifiers and \!2:u2 as
completions after "!2:".  However, this might be complicated by the
quoting business with $PREFIX ...

} It probably needs to go in _value for assignments; is right at the top
} the appropriate place?

Lost me here, sorry.

} The rum thing is the way $PREFIX acquires quoted !'s. I thought
} $PREFIX was fairly raw, so you could handle special characters?
} Obviously I'm misremembering, because I traced the quoting to some
} completely general code for all special characters.

_approximate certainly treats $PREFIX as though things like tildes
and glob qualifiers aren't quoted and don't need it, but ...

} Anyway, that has two effects: first you have to check $words, because
} that does have the raw form, and secondly you have to update $PREFIX
} so that you get the raw !'s inserted into the command line. (But
} you don't usually have to do that even if you're inserting special
} characters, do you? You just need to make sure compadd has the
} argument -Q, which it does here, except that's not good enough.
} Baaaaaaa.)

I don't know how the generic quoting code plays in, but I suspect this
is done this way *because* history expansion takes place so early.  If
it looks like a history expansion and it got this far, then it must be
a *failed* history expansion and needs to be quoted if it matches any
other completion -- otherwise the history expansion will fail *again*
after accept-line, and spoil the whole command.
 
} I think -z $compstate[quote] ensures we're not already doing something
} clever inside nested quotes, which would mean the expression couldn't be a
} history expansion.  I think.

History expansion occurs inside double quotes, though, so if the quote
state is double-quote then ... er, um ... perhaps it's necessary to
run compstate -q and examine $compstate[all_quotes] ...