Re: PATCH: 3.1.6-pws-4: Re: simulation of dabbrev-expand

[Adam Spiers <adam@thelonious.new.ox.ac.uk>]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> } > On Sep 9,  1:39pm, Adam Spiers wrote:
> } > } Subject: simulation of dabbrev-expand
> } > }
> } > } It appears to always work fine when grabbing words from history added
> } > } by the current shell, but either doesn't work at all, or very
> } > } unreliably when you want to grab a word from the saved history.
> 
> I'm finally able to reproduce something like this.

[...]

> The problem is in zle_tricky.c's use of quietgethist().  With Wayne's new
> stuff, the history list may have holes in it, but makecomplistflags() is
> trying to iterate over the history by calling quietgethist() on consecutive
> integers until it returns nothing -- which happens whenever it encounters
> such a hole.

Ahhh!  Of course!  I had looked at quietgethist() but never twigged
about the holes.

> I think the patch below should take care of this part, but it's possible
> that I've done more than was necessary; in particular, the hist.c hunk
> may not be needed: it might suffice to call the original quietgethist()
> before the loop in makecomplistflags().  It's also possible that calling
> up_histent() N times is the wrong thing to do:  Should the number passed
> to compgen -H specify the number of history entries searched or the range
> of history numbers searched?  I've interpreted it as the former.

I think that's a sensible choice.

[snip patch]

Bart, you're a hero.  This bug has been er, bugging me for ages.
Together with Sven's nice duplicate removing options we can finally
have the dabbrev-expand behaviour which up till now has been the only
aspect of zsh I've found inferior to any other shell.  Great work guys :-)