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

Request: _argmatcher::hideargs() function #413

Open
mjcarman opened this issue Jan 29, 2023 · 4 comments
Open

Request: _argmatcher::hideargs() function #413

mjcarman opened this issue Jan 29, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@mjcarman
Copy link

Feature request: Add a new hideargs() function to argmatchers. It should behave like hideflags() but apply to arguments instead of flags. This would be useful for commands that have multiple versions (abbreviations and/or aliases) of the same sub-command. For example, SVN has shorthand versions of most sub-commands (checkout/co, status/stat/st) as well as aliases for some (blame, praise, annotate). It would be nice to be able to hide most of these in suggestions while still recognizing them in linked argmatchers.

@chrisant996
Copy link
Owner

I agree.

If you look in the clink-completions repo, at the file completions/winget.lua, there's an example of how to accomplish it via clink.onfiltermatches().

But it's a little messy and takes more effort than it should. I'm slowly working on some API changes to make it easier and more intuitive to define fancy argmatchers. I'm wrestling with several design decisions, so it's been slow going (on the design side).

@chrisant996 chrisant996 added the enhancement New feature or request label Jan 29, 2023
@chrisant996
Copy link
Owner

chrisant996 commented Jan 30, 2023

@mjcarman The modules\arghelper.lua module has a bunch of helpers for creating argmatchers, with automatic backward compatibility.

It has to be used with require(), as local arghelper = require("arghelper"), and that means it has to be in a separate directory. See the !init.lua script in clink-completions for details about how to hook up a modules directory.

But if you use clink-completions and if your scripts are loaded after the clink-completions scripts (or are in the same directory) then you can simply use local arghelper = require("arghelper").

New: I've added an arghelper.make_arg_hider_func(args_to_hide) function. See comments in the top of modules\arghelper.lua for usage info. See the completions\winget.lua script for an example of how to use it. (I've revised the winget.lua script to use the new make_arg_hider_func() function.)

Backward compatibility is of course the biggest challenge when making syntax changes to how argmatchers are constructed. That's what is impeding certain kinds of enhancements to argmatchers right now. The arghelper.lua module automatically deals with backward compatibility issues, which is something that of course Clink cannot do on its own.

@mjcarman
Copy link
Author

@chrisant996 I appreciate your efforts to enhance argmatchers. Thank you! I'll have to update my fork of clink-completions and try arghelper.make_arg_hider_func(). That companion project has already done a lot to alleviate the pain points for me.

I sympathize with the difficulties of backward compatibility. I expect you've already thought of this, but how feasible would it be to add a new optional argument allowing argmatchers to declare their expected API version? (With the default being the current API, of course.) e.g. if an argmatcher declared version=2, the addflags() method would accept a table in the format used by arghelper._addexflags().

@chrisant996
Copy link
Owner

I sympathize with the difficulties of backward compatibility. I expect you've already thought of this, but how feasible would it be to add a new optional argument allowing argmatchers to declare their expected API version? (With the default being the current API, of course.) e.g. if an argmatcher declared version=2, the addflags() method would accept a table in the format used by arghelper._addexflags().

@mjcarman The main problem is that if for example Clink v1.4.15 adds some kind of minversion syntax, then the syntax would still not be recognized by v1.4.14 and lower. So it's kind of too late to implement something like that. :(

@chrisant996 chrisant996 self-assigned this Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants