Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion of suffix-autoremoval behaviors in ZSH #666

Open
maxlandon opened this issue Jan 5, 2023 · 0 comments
Open

Discussion of suffix-autoremoval behaviors in ZSH #666

maxlandon opened this issue Jan 5, 2023 · 0 comments

Comments

@maxlandon
Copy link
Contributor

Hello Rob,
Opening this ticket more for the sake of discussion and listing various cases than to propose a precise thing to do.
So here I'm basically looking at how the ZSH completion system might play with your SuffixMatcher model.

A few things outright:

  • Your SuffixMatcher-based model, from what I saw and tested, is reliable and predictable. Also simplifies greatly the logic for people writing completers.
  • Hence the need, if any of the following would be useful, to proceed by little touches and steps, while ensuring each does not produce
    unwanted edge cases.
  • Again, given the subject considered here, the need to discuss and check all paths before doing anything else.

Constraints

  • None of the logic and modifications to the values can be done anywhere else than in the shell/zsh package.
  • Carapace is ultimately in control of what should be: zsh "should not take initiatives" on its own, otherwise would risk doing the wrong thing.

ZSH options of interest

Three options appear in the documentation that are relevant here (one of which already used as -S ''):

-S suffix
    Like -P, but gives a string to be inserted after each match.

-q
    The suffix given with -S will be automatically removed if the next character typed is a blank or does not insert anything, 
    or if the suffix consists of only one character and the next character typed is the same character.
    
-r remove-chars
    This is a more versatile form of the -q option. The suffix given with -S or the slash automatically added after completing 
    directories will be automatically removed if the next character typed inserts one of the characters given in the remove-chars. 
    This string is parsed as a characters class and understands the backslash sequences used by the print command. 
    For example, ‘-r "a-z\t"’ removes the suffix if the next character typed inserts a lower case character or a TAB, and ‘-r "^0-9"’ 
    removes the suffix if the next character typed inserts anything but a digit. One extra backslash sequence is understood in this 
    string: ‘\-’ stands for all characters that insert nothing. Thus ‘-S "=" -q’ is the same as ‘-S "=" -r "= \t\n\-"’.

    This option may also be used without the -S option; then any automatically added space will be removed when one of the characters 
    in the list is typed.

Notes:

  • -q is interesting in that it applies relatively sane suffix-autoremoval without carapace having to mess with
    populating -r with the right patterns: hence -q is useful for things like paths slashes and list separators.
  • -r gives much finer-grained control, but at the expense of more things to take care of, thus more work upfront.

Example with slashes in directory paths

Note that this example cannot be taken as a general rule, but just as first step to visualize the process.

Consider the following values returned by carapace (here all values are strictly equal to their display values):

Downloads/ Public/ code/

Those values are probably invoked with either NoSpace() or NoSpace('/'). Thus, what might done:

  1. The SuffixMatcher matches the values.
  2. Remove the suffix from the value (but never put it in the display, because might introduce redundancies)
  3. Pass the removed suffix / to the -S flag in zsh code.
  4. Either:
    • Simply pass -q to zsh completions, which will remove the slah if either a slash or a blank char is inserted after.
    • Pass the removed suffix to -r. (I strongly fear, writing this, that -r will be overkill in most cases, and will
      actually introduce many behavior inconsistencies.)

Example with list separators in option args

Consider the following command line (| is the cursor here):

command -f value1,|

and the following completions (with trailing spaces not in the completions themselves):

value2 value3 value4

Those values are probably invoked with either NoSpace() or NoSpace(','). Thus, similarly to paths:

  1. The SuffixMatcher does not match any value (if NoSpace(',')): add the trailing comma with -S instead of appending the values themselves.
  2. The -q flag in zsh here will ensure that:
    • If a space/blank char is then typed, the net result is nil: a space is left after value1
    • If a comma is inserted, the same behavior applies; net result is 0, comma is left, completion continues with value2, 3, etc ...
    • If any non-nil character is typed, it is assumed its another item of the list: keep the comma.

Hope this will be useful in some way or another !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant