history completion oddity

history completion oddity

[Peter Stephenson]

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

history completion (ESC-/) on
  % echo ${PWD
does nothing.  On
  % echo ${PWD/
it gives me what I expect (don't ask):
  % echo ${PWD/bc01/bc01/test}/$f

I would guess that something visceral is grabbing potential parameter
completions before the history code can do anything --- given the second
result, the list of history words is OK, and also, more subtly, it's not
falling over on the incompletely parsed parameter.  I didn't get very far
looking at the trace output, a large chunk of which (in my case) seems to
be testing for colouring strings.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: history completion oddity

[Bart Schaefer]

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" ...)