Kakoune: Proposal: subcommands

Created on 23 Sep 2018  路  9Comments  路  Source: mawww/kakoune

As I understand, and often experience, in my opinion, kakoune's scripting language would need a some additional level of structure; thus I propose the command variant def-command [<switches>] <scope> <name> [<command>:<name>], which would practically make the listed commands its subcommands - perhaps under alternative names

To make my idea clearer, I'd like to offer an example

def lsp-start %{ ... }
def lsp-hover %{ ... }
def lsp-defition %{ ... }
def lsp-references %{ ... }

This is a pseudo-excerpt from ul's kak-lsp plugin.

In this example, one would have to type the 'lsp-' part in the command line to get autocompletion for the commands. Everything's fine until lsp-inline-diagnostic-enable, lsp-inline-diagnostic-disable, and the alike enter the picture; and the intellisense becomes a jarbled mess with no structure or hierarchy.
However, if the definition of subcommands would be possible, a nice hierarchy of commands would also be, and typing 'lsp' would display a single command, that shows the possible subcommands, as well as a piece of documentation perhaps.

The syntax, I just realized wouldn't be quite ideal; the concept remains a proposal, however.

Most helpful comment

What do you think about the following solution for *-{enable,disable} mess: just define flags as options instead of commands and use *SetOption hooks to react to their change?

All 9 comments

Is the intention purely to reduce the number of candidates in intellisense? I would argue the current behavior is preferable, for example I can type :ref and immediately discover lsp-references, going through lsp command to find references subcommand would be slower.

Having a lsp user mode with all available commands could be useful though, cc @ul 馃槈

Didn't even consider that side of the situation...
The -enable, and -disable commands definitely need a new mechanism though

I agree there is some cluttering going in with commands, that said I think we already have (almost) all the necessary tools to make those commands:

def lsp -params 1.. -shell-candidates %{for cmd in start hovel definition...; do echo $cmd; done} %{ eval "lsp-%arg{1}" }

I added lsp umbrella command in 5.3.0, @EmmChriss feel free to test it. Though I understand that it has no much value for you without hiding lsp-* commands.

Also I added lsp user mode. @maximbaz list of available keys is here https://github.com/ul/kak-lsp/commit/1e940db8020232ce5a8ee1a36bc9fd2d65585661 I haven't put it into documentation yet because it would be nice to hear feedback on mnemonics choice and probably change them before people start using it actively.

@mawww Is it any way to make previously defined command hidden? This way lsp umbrella command could become useful for those who prefer that way and also rarely used enable/disable commands could be hidden individually by user.

mnemonics choice looks good to me

Looks really nice, this is just about what I wanted, thanks a lot @ul

What do you think about the following solution for *-{enable,disable} mess: just define flags as options instead of commands and use *SetOption hooks to react to their change?

That sounds a lot less messy, than what we have now; I definitely think it's a good idea

A similar "sub command" proposal with "masks": https://github.com/mawww/kakoune/issues/1081

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fennewald picture fennewald  路  3Comments

notramo picture notramo  路  3Comments

alexherbo2 picture alexherbo2  路  4Comments

lenormf picture lenormf  路  3Comments

1g0rb0hm picture 1g0rb0hm  路  3Comments