Re: [FEATURE][PATCH] Complete local executables with ./ prefix, if prefix-needed is false

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Dec 8, 2021 at 8:31 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>
> Furthermore, anyone who has already added «zstyle ':…:*' prefix-needed
> false» to their zshrc will silently get the new behaviour when they upgrade.

Yeah, that's probably the biggest objection to re-using this style name.

> ...[Perhaps] a better approach here would be to complete
> both executables in $PATH and executables in $PWD, but under separate
> tags.  If we did that, prefix-needed would have its usual semantics in
> this case.
>
> Second, if Alice's $PATH does not include "." and her zstyle settings
> are such that «zstyle -T :…:executables prefix-needed» is false, why
> should the implied prefix be "./"?

The intent of the original patch appears to be to automatically offer
local executables when no matching name is found in the non-local
$path.  Does your question imply that it should instead be possible to
complete executables from arbitrary location(s) outside $path, rather
than only locally?

If so, then instead of (or as well as?) prefix-needed, an array-valued
style 'executable-prefixes' (or whatever) could provide a list of
places that should be searched and automatically inserted ahead of the
command word.  If combined with the patch's prefix-needed semantic,
one would need to both set prefix-needed to false and set
executable-prefixes to include "./" in order to get Marlon's effect.
That would solve the "silently get new behavior" issue and (I think)
also allow one to e.g. add "/etc/" when completing commands after
"sudo"?

One might then also be able to use the existing mechanisms to create
additional tag names, rather than wiring a new tag name into
_command_names.  (This is vaguely similar to Zach's question about
adding a custom tag to "cd" completion.)