Using other name than keys name in `execute-keys`, `map`, etc

Hello !

Anyone has remapped most of kakoune keybinding to a point where it’s difficult to write/read script using the execute-keys function ?

I feel like it would be more readable to have:

execute-keys <unselect> <go_down> <find> ) <insert_after> :
than
execute-keys <space>jf)a:
Even more if you remapped space to backspace, f to ^ etc…

1 Like

There is another issue I opened, but I don’t find it.

I usually refer to https://delapouite.github.io/kakoune-explain/keys.html when forgetting something.

Scripts would be more readable using names.

yeah but it’s a bit painfull to go see a ref. should be readable right away

I totally agree with you, just provided a link for reference.

In the issue you mention it’s about adding a help tool with clippy, which could be nice but its not really my point: I don’t understand the design choice of using the shortcut key for the function name instead of a explicit function name.

I think it would make much more sense to directly use proper function name: it improve readability and doesn’t punish people who remap default kakoune keybinding.

You can use with-maps option of execute-keys to take into account your remaps, and format a bit the sequence of keys in %{…} delimiters for readability.

1 Like

hmm yeah but then if I edit my remap in the future it can break my scripts. So proper function name are more stable

For better or for worse, Kakoune is a very punk-rock editor. It’s very much about letting users build things for themselves, rather than giving people a unified and harmonious Text Editing Environment. It is, if you will, the anti-Emacs. For example, Kakoune’s extension language is POSIX shell. Not because it’s an especially beautiful language, or simple, or powerful, but because it makes it easy to integrate with other tools people use, and because people already know it.

In the same way, Kakoune’s execute-keys feature uses ordinary normal-mode key mappings instead of human-readable names like “collapse-selections-to-cursor” or “previous-line”. Not because it’s especially beautiful or readable, but because people (who haven’t remapped all the keys) already know it.

It is really, really easy to write your first shell-script to automate a repetitive task: take all the commands you ran interactively, copy them out of your terminal’s scrollback, paste them into a text file, and make the text file executable.

It is very nearly as easy to write your first Kakoune command to automate a repetitive task: you have to add some define-command boiler-plate, and you might need learn the names of special keys like <lt> and <semicolon>, but mostly you can just type the same keys you would type to do the thing interactively.

I have been a professional programmer; I’m prepared to bring up a diagram showing the inheritance hierarchy of nodes in the document model and an API reference listing the methods available on each node, if I have to. But there’s something refreshing about writing :execute-keys <space>jf)a:<esc> and knowing there’s no additional scope for yak-shaving, so I can get on with whatever I was trying to do.

2 Likes

I can’t find anymore where I read it (somewhere in the docs), but execute-keys concatenates its arguments, so keys can be grouped, and the groups space-separated, without any need for bracket delimiters. For example:

execute-keys <space> j f) a:

will work as well as:

execute-keys <space>jf)a:

I think this increases legibility, especially when dealing with complicated regexes.

1 Like

‘Punk-rock’ is a beautiful way to describe kakoune, and this is why I love it too.

But for me remapping default keybinding to my needs also follow the same DIY editor philosophy. ( edit: just looking at this forum, the github etc… I feel that that remapping is already a big part of kakoune, even the “official” wiki suggest remapping space to enter user-mode )

In my opinion it’s not very punk rock to say “this is the ultimate keybinding for every user and every use case, therefore we use normal-mode key mapping as the function’s name” :stuck_out_tongue: .

I agree that it’s very easy to write your first repetitive task with kakoune, assuming one havn’t remapped default keybinding.

But I don’t think using proper function name would make it harder for two reasons:

  1. You could have execute-keys and execute-fn living together. execute-keys would act like execute-keys -with-maps that is perfect for quick automation, and execute-fn that use proper function name which is better for more complex, sharable and readable code ( inside a pluggin for example ).

  2. Also I can imaging a function key-to-fn that would transform key to function name.
    For example if I select
    jf)a:
    and run the command :key-to-fn<ret> then the selection would be transformed to

<go_down> <find> ) <insert_after> : 

Solution 1 and 2 are not incompatible.

Last point: IMO it make more sense and be more easy to transform customed keybind into a function using he above key-to-fn than to use a helper like #2358 or refer to https://delapouite.github.io/kakoune-explain/keys.html every time you want to make an automation.

Sorry, I may be thinking a bit too loud here:

  • I wonder what the added complexity that would be needed to the codebase just for that…
  • Unless I’m mistaken it goes against the original design: github.com/mawww/kakoune/blob/master/doc/design.asciidoc#unified-interactive-use-and-scripting, and with threads like “kakoune-needs-a-real-scripting-language”, I begin to smell the history of Vimscript (ex, execute, variable and control flow)… which triggers me (PTSD, sorry) toward this kind of reaction The Inner Platform Effect.
  • So that you have minimal execute-keys and evaluate-commands and hooks to deal with ,and/or when doing logic with sh become cumbersome, IMVHO IPC solidification to access the partial states of Kakoune like selections, registers, etc., and just enough abstraction like unification of registers-options-hooks, are inspiring.

I guess not much, I beleive you just need to change the parser to parse <delete> instead of d. Actually it might even make codebase more simple, since it’s more easy to parse <delete> than d ( d is ambigious, it could be a d from insert mode )

It does goes again the original design, but I think this original idea can be criticize. Think of people using non qwerty keyboard that need to remap the “hjkl;:” , it makes kakoun script hard to read/write .

and with threads like “kakoune-needs-a-real-scripting-language”, I begin to smell the history of Vimscript (ex, execute, variable and control flow)… which triggers me (PTSD, sorry) toward this kind of reaction The Inner Platform Effect.

I hate Vimscript too and I’m also against kakoune going this direction. But this is not about creating a scripting language for kakoune. It’s about using another naming convention for stuff that already exist : using full words instead of letter ( <delete> instead of d).

So inner platform effect at all ! No added complexity either, just a different naming convention.

2 Likes

Found this… Didnt understood the "would unfortunately decorelate the interactive keystroke from the scripting command name " but I agreed on “a good direction to explore”

just half-assed musing:
In lexicon.kak:

declare-option str sub_select s
declare-option str last_spaces \h+$
declare-option str delete d
declare-option str select_current_line x

in kakrc:

source lexicon.kak

then trim space at end of line:
eval %{exec %opt<select_current_line> %opt<sub_select> %opt<last_spaces> <ret> %opt<delete>}
obviously should be used for more complicated atoms…

2 Likes

This is indeed a good point.