Highlight executables in path subdirs

[amerlyq]

I have something like

if [[ -d "$HOME/.bin" ]]; then export PATH="$HOME/.bin:$PATH"; fi
# Where
.bin
├── often-used.bin
└── rarely-used.d
    └── pr1.bin

ZSH allows me to call binaries in subdirs by relative path: rarely-used.d/pr1.bin from any place.
Could it be possible to highlight them as a valid commands to launch?
Like example -- launching searching for binaries inside PATH nested subdirs on each / entered?

[danielshahaf]

You are describing the PATH_DIRS option.

Yes, it would be possible to support that. This would include:

1. Adding a TODO test case (a test marked as "currently failing"; see tests/README.md)
2. Teaching _zsh_highlight_main_highlighter_check_path to consider subdirs when called on a command word (i.e., from its first callsite) and the option is set.

Would you be interested in implementing this? Even simply adding a test would be helpful.

[danielshahaf]

About the implementation: the option might have to be tested early, like INTERACTIVE_COMMENTS is, and for the same reason. Also, the first hunk and a half of this diff (ignore the log message and the remaining hunks) might be reusable here. (That commit is an unfinished fix for #202; I'm hoping to finish it the fix in time for the next release.)

[amerlyq]

Hmm, ok. Along fortnight, I will look what could be done.
Thanks for the impl pointers -- it's one of the best responses, I received under issues:)

[danielshahaf]

Actually, can you try this patch?

diff --git a/highlighters/main/main-highlighter.zsh b/highlighters/main/main-highlighter.zsh
index 64a2032..83e40b1 100644
--- a/highlighters/main/main-highlighter.zsh
+++ b/highlighters/main/main-highlighter.zsh
@@ -86,7 +86,12 @@ _zsh_highlight_main_highlighter()
   if [[ -o interactive_comments ]]; then
     local interactive_comments= # set to empty
   fi
+  if [[ -o path_dirs ]]; then
+    integer path_dirs_is_set=1
+  fi
   emulate -L zsh
+  (( path_dirs_is_set )) && setopt path_dirs # required for detecting command words
+  unset path_dirs_is_set # remove the parameter, leave the option
   setopt localoptions extendedglob bareglobqual
   local start_pos=0 end_pos highlight_glob=true arg style
   typeset -a ZSH_HIGHLIGHT_TOKENS_COMMANDSEPARATOR

Turns out the type builtin already does the heavy lifting for us, if the option is set.

If the patch works, we'd still need (a) a test, (b) to make the setopt effective only for the type call (not for the whole function), (c) to see if other options need similar handling (at least to scan the source code of type in Src/builtins.c to see what other options it consults).

[amerlyq]

Draft patch, seems like it did the job.
However, somehow feeling isn't intuitive, because after several characters of the dir name, command becomes red, untill you type whole relative path, know nothing about wrong you or not.
I'm ashamed to notice only now, that it's supposed default behaviour for syntax highlighter overall.
Indeed, it's too much to desire distinct colors for 'there will be command, type more' (simple orange) and 'no one command with such prefix possible' (red).
Maybe, as a compromise, at least full match for 'directory in path' could be underlined orange when typed -- similar to command ambiguity case, presuming there are some binaries inside?

[danielshahaf]

Indeed, it's too much to desire distinct colors for 'there will be command, type more' (simple orange) and 'no one command with such prefix possible' (red).

Highlighting prefix of a valid command in yellow has been requested before (see #148). It's a good idea. The specific case of "the command-word-so-far is [edit: a prefix of] a directory name in $PATH, and PATH_DIRS is set" will probably need to be coded explicitly, though (in the catchall branch of the case $arg selector).

[danielshahaf]

If the zsh/parameter module is available, checking something for being "a prefix of a valid command word" should basically consist of doing patterned lookups ("Is there a key matching the pattern ${input}*?") on the associative arrays $commands, $functions, et al.

[amerlyq]

Thanks for the implementation!
My bad I couldn't look at issue earlier, spending a little free time to port my vim configs to neovim))
Sorry, you was forced to do it yourself.

[danielshahaf]

No problem. (I thought neovim was mostly compatible with vim, though? A 95% drop-in replacement?)

[amerlyq]

Aah, not so simple when you use >100 plugins:) Part of them hit some neovim bugs, part was necessary to fix/enhance/wrap under jobs API, being unable to use interactive shell in neovim. And overall doesn't new vim gives great reason to inspect and refactor old bloated configs by applying all the last years experience?))

[danielshahaf]

Wow. Good luck with your project! :)