Missing completions/help for free-form arguments

[Yagamy Light]

Hi! Last day or so I spent trying to solve this problem, and it now seems complicated to me, hopefully I'm wrong. I figured I might as well just ask a question, in case someone knows this part of code, and could give me directions offhand.

Current klish behavior: a user types a command "mycommand arg " (with trailing space), presses a space or tab, and gets a help message. Problem: this stops working whenever there is an argument that is a free-form word. For example: given a command "clients modify ips clientname", the last argument that is a client name will not trigger help message if one typed a "clients modify ips " and pressed space again.

Worth noting, this is a regression compared to the original clish 0.7.3. In 0.7.3 the help message does get shown. Original problem I worked on (before I found this maintained fork of clish) was that the help-message is only missing if the argument is marked as optional (for example, you may type "clients modify ips clientname 1.1.1.1" to set IPs of clientname to 1.1.1.1, or you can omit the IP completely, thus resetting their list to nothing). But I suspect, both the regression and the original problem should have a similar fix.

For reference: here's how such command is defined in a XML:

        <COMMAND name="clients modify ips" help="Modify client IP addresses">

          <PARAM name="name" help="Client name" ptype="CLIENT_NAME"/>

          <PARAM name="ips" help="Client IP addresses list (comma separated)" ptype="CLIENT_IPS" optional="true" default=""/>

          <ACTION>

            […commands…]

          </ACTION>

        </COMMAND>

My current thoughts, I need to:

1. add a bool "free_form_word" to `lub_arg_s`

2. at `find_next_completion` or higher the stack: for each space-separated arg in `line`, skip all free-form args and find appropriate completion based on positions of constant args only

But at this point I have no idea if it's the correct thinking, and details are vague to me as well. Completions are currently searched in some tree that seems to only have constant args, so apparently I need to stop using this tree, and instead get a posible completion from elsewhere?

In case anybody curious, log of my current research on how completion seems to work is here https://github.com/Hi-Angel/notes-backup/blob/master/klish.md#completion

[Hi-Angel]

Update: I figured, fixing that might be easier than I thought. Current
completion routine searches for possible completions over a tree with
all possible arguments, and this tree seems to lack arguments with
free-form names (and perhaps optional ones too).

So, what I need to do is to figure out where this tree is created, and
make sure that free-form arguments are included in the tree. If anyone
knows offhand where this happens in the code, I'd appreciate a
comment.

To clarify what I'm talking about: the tree is the one that the
function `lub_bintree_findnext` searches over, before returning a
`void*` which is actually a `clish_command_t*`. In this flow the
`lub_bintree_findnext` is in turn being called by
`find_next_completion`.

> --
> You received this message because you are subscribed to the Google Groups "klish-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to klish-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/klish-dev/c7ef253b-1707-4af8-b11c-afbc5a725580n%40googlegroups.com.

[Serj Kalichev]

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.

"tab" - must show completions but not help. So tab on free-form
parameter must show nothing.

"Shift^?" - must show help. It shows help on any type of parameters
including free-form.

Does it work so?


24.12.2020 17:14, Hi-Angel пишет:

[Hi-Angel]

Thank you for your reply!

On Fri, 25 Dec 2020 at 12:44, Serj Kalichev <serj.k...@gmail.com> wrote:
>
> 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?

[Hi-Angel]

On Fri, 25 Dec 2020 at 14:57, Hi-Angel <hiang...@gmail.com> wrote:
> 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?

Sorry, that sounds odd since completion does works, except in case of
free-form parameters there's, like, nothing to complete. Let me
rephrase this: "How make klish show help whenever completion hook is
triggered, but there's nothing meaningful to complete, i.e. because
the parameter has a free form"

[Serj Kalichev]

I need to re-inspect current state of klish to answer. I will take time

25.12.2020 14:57, Hi-Angel пишет:

[Hi-Angel]

Thank you very much! Your recent reply really helped me to figure out
how to implement all of that.

What I did for now is this commit
https://github.com/npobaum/klish/commit/d7e01a38c3ebf0605cc269b241a94b3aee384b6d
It's a bit dirty because it hardcodes behavior you're not interested
in, but otherwise it works for us.

While at it, I also figured out the other problem I mentioned, which
was that along with completions a space was inserted. Turned out I had
to un-comment one line of code:
https://github.com/npobaum/klish/commit/283b472d35dae07b6f38826de3847f1767cb6eef

Let me know if you have any comments.

> --
> You received this message because you are subscribed to the Google Groups "klish-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to klish-dev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/klish-dev/f6fc96cc-a585-2aaa-027e-32db45f8c819%40gmail.com.