Feature request: add a "check" command to check config

[teto]

Is your feature request related to a problem? Please describe.

hi,

thanks for writing this complex of a software. This is my first time dealing with this kind of software.

I was expecting it to be hard, because I didn't know (still dont) what mappings I wanna use.
But I had some trouble with the configuration itself.
The main thing I would like to have may be a command that can check the config without running kanata, just to be able to test a few things without incapacating the keyboard (eevn though one can do lctrl+space+esc). It would also help shorten the feedback loop in systems like nixos, where nixos builds the full system (slow) then starts services and I end up discovering errors at runtime. If I could check the config statically earlier, the error could appear earlier in the process.

Describe the solution you'd like.

adding a kanata check command

Describe alternatives you've considered.

start kanata and kill it fast, but no way to know when to kill it apart from waiting.

Additional context

I'ev also noted some things along the way

1. deflayer bigger than defsrc doesn't seem to create errors ? (I haven't tried to recreate)
2. the following error message in "help: Unknown key/action: right" could be improved by mentioning how to add a "right" key (add one to defsrc ?)
3. In the readme, you could recommand https://github.com/kmonad/kmonad-vim for vim users to get selection
4. I like that kanata developers show their commitement to support users with this message:

Dec 29 20:53:43 teto kanata[815522]:         For more info, see the configuration guide or ask in GitHub
Dec 29 20:53:43 teto kanata[815522]:         discussions.
Dec 29 20:53:43 teto kanata[815522]:             guide : https://github.com/jtroo/kanata/blob/main/docs/
Dec 29 20:53:43 teto kanata[815522]:         config.adoc
Dec 29 20:53:43 teto kanata[815522]:             ask   : https://github.com/jtroo/kanata/discussions

but with all the errors I had, it was detrimental to readibility, would be best to keep it in 1/2 lines IMO or on improing error messages (they could have a number and dedicated pages like shellcheck)
5. the nixos service for kanata looks complex: NixOS/nixpkgs#278135 might be worth having one upstream to see the recommended configuration

Maybe some of my comments are misguided. Just wanted to give a noob perspective. Understanding that I didn't need to map every key in defsrc was a "wow" moment as well.

[rszyma]

It's always great to hear feeback, especially from new users.

+1 to the kanata check, I've also wished something like this existed multiple times in the past. And it should be trivial to implement.

If you're after that quick feeback loop to see what works and doesn't I can't recommend my vscode-kanata extension enough, even if you normally don't use vscode.

I'll let others comment on other parts of your feedback.

[jtroo]

deflayer bigger than defsrc doesn't seem to create errors ? (I haven't tried to recreate)

I can't reproduce this, having mismatched counts generates errors for me.

the following error message in "help: Unknown key/action: right" could be improved by mentioning how to add a "right" key (add one to defsrc ?)

I think it's fine to add a default name for right here:

https://github.com/jtroo/kanata/blob/080f1f9bd56466324bd7b4a6c3db88f735e22f55/parser/src/keys/mod.rs#L101C16

In the readme, you could recommand https://github.com/kmonad/kmonad-vim for vim users to get selection

Do you mean syntax highlighting? I haven't tested this myself and have some concerns about how well it would work since kanata does not aim to be compatible with kmonad. But maybe it's fine to add to the related projects section with a warning note that it's not intended for kanata.

but with all the errors I had, it was detrimental to readibility, would be best to keep it in 1/2 lines IMO or on improving error messages (they could have a number and dedicated pages like shellcheck)

It's intended to be 3 lines today, but I guess since the lines are too long, they're getting reflowed by your logging system. I'm happy to accept PRs to improve the error messaging - what exists now is a balance I was personally happy to accept between discoverability of documentation+help, verbosity, and ease of implementation.

I guess some easy improvements would be:

• make the first sentence shorter to fit on one line
• the link to GitHub discussions can be removed and instead be in the introduction of the configuration guide
• find a way to make the first sentence along with the link to config.adoc fit on two lines

For numbering and dedicated pages or other adjacent improvements, I think it would be an improvement but not one I will be personally making any time soon.

the nixos service for kanata looks complex

I see jian-lin has responded on that thread. They are much more knowledgeable than I on the topic of nixos (I have zero experience with it). I am the primary maintainer of the kanata software itself, but I don't manage any of the package repositories.

[jtroo]

For the main request, as rszyma mentioned, it should be fairly simple to implement.

Would need to call:
https://github.com/jtroo/kanata/blob/080f1f9bd56466324bd7b4a6c3db88f735e22f55/parser/src/cfg/mod.rs#L217C40-L217C40

from somewhere around here (or maybe somewhere else is better, but it's at least fine to have here) based on a some new clap arg logic:
https://github.com/jtroo/kanata/blob/080f1f9bd56466324bd7b4a6c3db88f735e22f55/src/main.rs#L162C1-L172C6

[teto]

If you're after that quick feeback loop to see what works and doesn't I can't recommend my vscode-kanata extension enough, even if you normally don't use vscode.

I confess I kinda skipped that since I favor nvim. Just tried it since I have vscode too. The plugin asked for my variant "Local Keys Variant" but I think it could autodetect this from my platform or scan the file ?

I can't reproduce this, having mismatched counts generates errors for me.

ok sry to have made you lose time, if I can reproduce I will open a dedicated issue. Might have been my imagination.

I opened this to add "right" #690

I will let more competent users see how to implement a "check" command.

[rszyma]

Just tried it since I have vscode too. The plugin asked for my variant "Local Keys Variant" but I think it could autodetect this from my platform or scan the file ?

Surely automatic detection could be done. I just haven't gotten yet to implement it.

If you have any further suggestions regarding vscode-kanata, it's better to continue discussion in a new issue in extension repo, not here.