Thank you for your reply!
On Fri, 25 Dec 2020 at 12:44, Serj Kalichev <serj.k...@gmail.com
> Before dive deep into the problem there is some notes about it.
> "space" - must not output help or completion. Some time ago such problem
> was reported. And now I don't remember what I have done about it. May be
> nothing. But the right behavior to do nothing about help on pressing space.
Well, I don't know if it's because we have some special configuration,
but I see a bit different behavior. On our systems pressing space
results in one of α) if the command is unambiguous, it gets
autocompleted, β) otherwise, completions are shown.
Btw, I also figured there's a thing which was not present in the
original clish: in the β case a space is inserted (i.e. in addition to
completions being shown). It may not look like a problem if as you say
klish wasn't supposed to even try to autocomplete on space… But if I
want to replace older clish with the newer klish in our systems, I
gotta make sure not to break user experience, so I will need to figure
it out too.
Though, I grepped for "space" case-insentive over our clish/klish
configs and I see no relevant matches. So I'm not sure offhand, where
that difference in behavior is coming from…
> "tab" - must show completions but not help. So tab on free-form
> parameter must show nothing.
In our configuration I see no difference between tab and space behavior.
> "Shift^?" - must show help. It shows help on any type of parameters
> including free-form.
Yay, it works! This is amazing!
So, what conclusions can I make from that… The behavior we see/want is
not something you'd like, so it gotta be our local setup. That's okay,
but makes me wondering, what's the best way to achieve this? By "this"
I mean "always working autocompletion on pressing space/tab"? Is it
possible without modifying klish sources?