Feature request: Disable shell file comparative at the end of the command about kong-completion HOT 3 CLOSED

The -o default -o bashdefault options in the shell initialization procedures are responsible for enabling default shell completions.

Some context around this topic:

This repo is/was originally based on https://github.com/WillAbides/kongplete. There are two main differences between kongplete and kong-completion:

• kongplete has default shell file completions disabled, whereas kong-completion has them enabled (“globally”).
  • For enabling file completions in kongplete, you have to configure it with PredictFiles as shown in their example. PredictFiles comes from the posener/complete library. Unfortunately, PredictFiles doesn’t seem to be properly able to expand things like ~ or ../. (There are PRs for this, 1, 2, but they seem stale.)
• The public API of both libraries is different, i.e. the way how you’d add and initialise the completions in your kong app.

In regards to file completions, I found it superior to have ~ or ../ working reliably, even at the expense of losing fine-granular control over the shell’s default completion behaviour.

Potential solutions

These are potential solutions that come to my mind:

• (a) The code paths around the shell initialization procedures could be refactored and parametrised, to allow opting out of the -o default -o bashdefault options when registering kong-completion in a kong app. When using such an opt-out, you’d then have to use PredictFiles if you wanted file completions – but of course you’d also “suffer” from its limitations.
• (b) I’m also no expert on shell completions, but I’m pretty sure that it would be possible to achieve something like cobra’s ShellCompDirectiveNoFileComp. However, it’s probably not trivial to implement, and the implementations would probably be shell-specific. As an example, this is how cobra handles the ShellCompDirectiveNoFileComp directive for zsh. To have a similar mechanism in kong-completion, it might be necessary to also make adjustments to the underlying posener/complete library, though I’m not 100% sure about that.
• (c) https://github.com/posener/complete seems abandoned, but of course it could be forked, in order to address the ~ and ../ limitations, as that’s the root cause.
• (d) If the limitations of PredictFiles wouldn’t affect you, you could also consider using kongplete.

Regarding contributions, let me add that I’ve initially created kong-completion to satisfy my requirements in another project. I’m currently maintaining kong-completion on a minimum-effort basis, and I try to keep it aligned with https://github.com/WillAbides/kongplete as much as possible, to reduce the maintenance burden on my end.

That being said, if it’s possible to do (a) without too much overhead or complexity, I’d be down for that.

from kong-completion.

Thanks for the quick and detailed response. It's perfectly understandable that this library meets your exact requirements, so no worries there.

I think I might give a) a try. In my use case I do not deal much with files. In fact, only one command even takes a file as an input, so I can probably live with the limitations. I can try to spin up a PR.

As a side-node, It looks like there is a v2 of the posener/complete library, did you have a look at that? I did a very botchy job of upgrading kong-complete to the v2 version of complete. Unfortunately, some of the code regarding Args has changed, so the positional predictor in your repo does not work any more at all. Also there is some confusion about - and -- args, so either I am doing something fundamentally wrong or v2 is supporting less features than v1.

I was also considering forking the v1 version of complete, since it seemed more approachable and then fix other issues, such as the usage of the new Go 1.20 error packages (which are used in the v2 version...)

from kong-completion.

It looks like there is a v2 of the posener/complete library, did you have a look at that?

I noticed the v2, but I haven’t really looked much into the library at all (i.e., neither version). But it’s probably good to keep track of this, so I’ve created #4.

from kong-completion.