Re: _approximate doesn't work

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 17,  7:25pm, Peter Stephenson wrote:
} Subject: Re: _approximate doesn't work
}
} Anthony Charles wrote:
} > There's a lot of differences
} 
} The business end of command completion changed.  It used simply to add
} the commands array directly; now it goes through the function
} _path_commands.

Skipping that for the moment, on line 641 of the 4.3.5 output (which
corresponds to line 394 in 4.3.4), the tag "commands" is being added
to the _comp_tags list twice:

+_next_label:11> _comp_tags=' commands  commands  builtins ' 

This appears to related to the call to "_wanted commands ..." from
_path_commands, at about line 322.  Note that PREFIX has not yet been
set when that first call to _path_commands occurs -- but it is set
later, before _path_commands is called again.

In any case, now that commands is in _comp_tags again, _path_commands
is going to be called again, and everything that's in _comp_tags at
that point eventually ends up duplicated:  at line 2291 "commands" is
appended again, and so on, until by line 5875 we have everything in
there three times and "commands" six times.

Something similar happens in 4.3.4, but only after returning to
_main_complete and calling _approximate, so there's only one set of
duplicates.

I think perhaps _main_complete needs to clear _comp_tags at the point
where it increments _completer_num, around line 169.  That would get
rid of one set of the duplicate tags.  (I've tried poking that in to
a running shell with zed, and it seems to be OK.)

The other set of duplicate tags seems result from _path_commands having
two consecutive calls to _wanted:

  _wanted commands expl 'external command' \
      compadd "$@" -ld descs -a dcmds && ret=0
  _wanted commands expl 'external command' compadd "$@" -a cmds && ret=0

Why?  Anyway the tweak to _main_complete should snuff that as well, I
think, once we get back that far.

} The problem is around this bit that's used if descriptions
} for the commands are needed (the verbose style is set and at least some
} commands have descriptions):
} 
}   for cmd in ${(@)commands[(I)$PREFIX*]}; do
[...]
} I can see that _path_commands is skipping this loop, indicating the
} expansion was empty.  However, I can't see why this is happening.

Hmm, I get

: _path_commands:15:then then for; line=whatis: -s: unknown option

which then means all my descriptions are empty, so $need_desc is set
to the empty string and it never even gets near that loop, nor does it
execute the pair of _wanted calls quoted above.  Instead it just falls
straight through to

_wanted commands expl 'external command' compadd "$@" -k commands && ret=0

which works like the 4.3.4 code and everything is fine.

Apparently _path_commands should not assume that whatis accepts any
options.  Have we got Debian or Solaris dependencies creeping in here?

That's about as far as I can get with this, I'm afraid.