Zsh Mailing List Archive
Messages sorted by:
Re: simulation of dabbrev-expand
- X-seq: zsh-workers 7924
- From: Adam Spiers <adam@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh workers mailing list <zsh-workers@xxxxxxxxxxxxxx>
- Subject: Re: simulation of dabbrev-expand
- Date: Fri, 17 Sep 1999 22:44:55 +0100
- In-reply-to: <19990916173409.A17932@xxxxxxxxxxxxxxxxxxxxxxx>
- Mail-followup-to: zsh workers mailing list <zsh-workers@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <19990909133913.A30055@xxxxxxxxxxxxxxxxxxxxxxx> <990909171104.ZM15814@xxxxxxxxxxxxxxxxxxxxxxx> <19990916173409.A17932@xxxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: Adam Spiers <adam@xxxxxxxxxx>
Adam Spiers, on thelonious (adam@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> Bart Schaefer (schaefer@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> > On Sep 9, 1:39pm, Adam Spiers wrote:
> > } 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.
> > Can you perhaps give a more specific example? I'm not having any trouble
> > with this at all.
> % history 1 | grep ' /' | wc -l
> % less /<TAB>
> % less /usr/share/zsh/functions/_man
> zsh: do you wish to see all 51 possibilities?
> Where did all the others go?
> The newer entries work fine. This problem has
> exhibited itself in exactly the same way across zsh-3.1.6-pws-* :-(
I've done a lot of further investigation into this, and *still* cannot
spot an exact pattern to when it does and doesn't work, which is
unbelievably frustrating. However, I'm beginning to suspect that it
may have something to do with history duplicates. Sven's latest patch
to _history_complete_word is very nice, but if the `history_sort'
configuration key is unset, no sorting occurs, and hence no removal of
duplicates. (As we're talking about individual words extracted from
the history, the options dealing with history line duplicates have
little bearing on this.)
How can I ensure that there are no duplicate words in the list of
matches? Even if this isn't the real problem I'm experiencing, it may
well help narrow it down. This questions leads me to another: we have
all these variables at our disposal in the widget functions for
examining the completion system's state in great detail ... but the
one thing we still can't do (AFAICS) is actually see what completions
have currently been calculated. If there was a special array
parameter, `completions' say, then things like removing duplicate
matches, or choosing your own match sorting algorithm (although heaven
forbid I would ever need to implement a quicksort in zsh :-) would
become possible in the shell functions. Have I missed something here?
Messages sorted by: