HASH_LIST_ALL?

HASH_LIST_ALL?

[Matt Garman]

If I understand the purpose of the HASH_LIST_ALL setting, I should
be able to add a program to my path, and have that program be
accessable via tab-completion without running "rehash" (i.e., the
rehash is automatic upon a tab-completion attempt for a command).

Furthermore, the zshoptions man page says that HASH_LIST_ALL is set
by default.  And indeed, that appears to be the case, because when I
do a "setopt" (with no arguments), I don't see any reference to
hashlistall.  (And, if I do a "setopt hashlistall", the output of
setopt with no arguments doesn't change.)

So as far as I can tell, HASH_LIST_ALL is set on my shell.  However,
tab completion on new commands does not work until I have manually
done a rehash.

Am I doing something wrong?

Thanks!
Matt

-- 
Matt Garman
email at: http://raw-sewage.net/index.php?file=email

Re: HASH_LIST_ALL?

[Bart Schaefer]

On Wed, 13 Oct 2004, Matt Garman wrote:

> If I understand the purpose of the HASH_LIST_ALL setting, I should
> be able to add a program to my path, and have that program be
> accessable via tab-completion without running "rehash" (i.e., the
> rehash is automatic upon a tab-completion attempt for a command).

Unfortunately that's almost exactly the opposite of what it means.

What HASH_LIST_ALL means is that the *first* time you do completion of 
command word -- not the first time for each new command; the single first 
time you complete with the cursor in the command word position -- that the 
entire search path is added to the hash.  The alternative, with the option 
unset, is for the hash search to stop as soon as it finds the command in 
question, then continue where it left off if necessary later.  In neither
case are previously-hashed directories searched again (except for relative
paths like "." and "..") until after a "rehash" is done.

Re: HASH_LIST_ALL?

[Matt Garman]

On Wed, Oct 13, 2004 at 07:43:35PM -0700, Bart Schaefer wrote:
> In neither case are previously-hashed directories searched again
> (except for relative paths like "." and "..") until after a
> "rehash" is done.

I see.  Is there a simple way to achieve the behavior you describe
above?

I asked the same question on the gentoo-user mailing list, and one
person gave the following suggestion:

###############################################
rehashComplete() {
    rehash;
    zle expand-or-complete;
}

zle -N rehash-complete rehashComplete
bindkey "\t" rehash-complete
###############################################

That works (meaning, it makes the shell behave as I want), but I was
just hoping there was a simpler method, i.e. "setopt something".

Anyway, thanks for the helpful information!
Matt

-- 
Matt Garman
email at: http://raw-sewage.net/index.php?file=email

Re: HASH_LIST_ALL?

[Bart Schaefer]

On Wed, 13 Oct 2004, Matt Garman wrote:

> rehashComplete() {
>     rehash;
>     zle expand-or-complete;
> }

Egad.  That means you're rehashing on every completion, not just on every 
command completion.  What a terrific waste of time and CPU.  If you're
using compsys, the right way to do this is by adding to your completer
zstyle:

  _force_rehash() {
    (( CURRENT == 1 )) && rehash
    return 1	# Because we didn't really complete anything
  }

  zstyle ':completion:*' completer \
    _oldlist _expand _force_rehash _complete ...

(where "..." is the rest of whatever you already have in that style).

> That works (meaning, it makes the shell behave as I want), but I was
> just hoping there was a simpler method, i.e. "setopt something".

Unfortunately, there's not.  Command completion uses the $command variable 
from the zsh/parameter module, which means it forces command hashing to 
occur even if you (un)set all the options that otherwise turn hashing off.