Why keep an extra VISUAL mode?

[python128]

Why is there a need of another made, namely visual?
Why not keep it simple, and allow <s-[key]> selections?
In Kakoune, it is like this. And I like this feature in kakoune. Likewise, I like features like space mode here, which is not available in Kakoune.
It may be okay to keep the visual mode. But I would suggest to add shift selections.

[pickfire]

Why is there a need of another made, namely visual?

It's actually extend but we haven't renamed it yet, it also have some issues which is why it wasn't very much documented.

So instead of doing shift, you do v.

<s-[key]> is very limited, you can't do c-s-f to extend to next page. And one of the design choices is we want to avoid is holding down shift or alt.

Likewise, I like features like space mode here, which is not available in Kakoune.

A few of the space features are based on doom emacs.

See #165 and https://github.com/helix-editor/helix/wiki/Keymap-brainstorm for more information behind the design choices.

[sudormrfbin]

They will have to copy it themselves to their own config.

[python128]

Alright then..
Thanks a lot. 👍

Will do the same.

[python128]

Is it possible to include a toml file in another toml file?
Eg:
In user's config.toml file,

import kak_keys.toml

or something like that?

Because it would be daunting to copy the file contents to the config.toml..

[sudormrfbin]

TOML doesn't support includes, so copying is pretty much the only thing that can be done.

[pickfire]

Copy is actually easy, since you can just copy the whole section in the keymap and paste it in your config.