Re: history completion oddity

[Bart Schaefer <schaefer@brasslantern.com>]

On Tue, 20 Jun 2000, Peter Stephenson wrote:

> I expect Sven will tell me this is the way it should work (or has to work),
> but it's worth a try...

I think this is in fact a bug ...

> history completion (ESC-/) on
>   % echo ${PWD
> does nothing.

Using the _history completer and ^X?, I find that this line gets executed:

+_all_labels:39> compadd -1V -default- -Q -a h_words

This ought to produce a match, but apparently it does not, because the
return value is nonzero so _all_labels eventually returns 1.  With

>   % echo ${PWD/

the same compadd is executed, but this time it DOES match.

> I would guess that something visceral is grabbing potential parameter
> completions before the history code can do anything

Nope.

Incidentally, I just had an exchange with A. Spiegl in which he noted that
history completion is unacceptably slow because he has HISTSIZE=15000.  He
also has several match specs.  I played around with the _history completer
a little and found that it gets called once for every match spec, which
thus assigns h_words=("${(@)historywords[2,-1]}") each time ... I estimate
that at ~5 words per command and ~4 bytes per word, zsh is copying about
300Kb of memory every time it does that assignment, so zsh rips through
as much as 3Mb every time he hits TAB.

Admittedly, keeping 15000 lines of history is a little unusual, but there
must be something we can do about this.  (Imagine what was going on before
Sven added "compadd -a arrayname" ...)