mawww made an announce about a breaking-cleanups git branch a few day ago on IRC, but I think this work can get even more awareness via this forum:
2 majors breaking changes have already landed:
Make x just select the full lines
`x` is often criticized as hard to predict due to its slightly complex
behaviour of selecting next line if the current one is fully selected.
Change `x` to use the previous `<a-x>` behaviour, and change `<a-x>` to
trim to fully selected lines as `<a-X>` did.
Adapt existing indentation script to the new behaviour`
I’ve only been using this branch for a day, so far I really like the changes around x. I don’t really have an opinion about the change to p, but I also haven’t looked into the reasoning for the change.
I currently use ~12 QoL plugins (most of which I authored myself), and while I have noticed some breakages, they have all been easy to address. The thirteenth plugin (kak-lsp) is a little larger in scope, and will require some testing before I’m confident I managed to address the breaking changes.
Is this just an experiment, or is there some confidence this will be merged into master?
I am a huge fan of the x change. And if mawww is taking suggestions for breaking changes, I would love it if <esc> did not end macro recording. It’s not only unorthogonal, but makes it ridiculously easy to accidentally end a macro. IMO Q should be the only way to do it.
I think that the more difficult problem is for plugin authors. I’ve tried to write my exec's clean enough. But what is the transition algorithm? x -> <a-x> -> <a-X> -> ?
I think that ghGl performs a similar operation to the old <a-x> and the new <x> if you want to write plugins in a way that supports both mainline and this branch? I can’t speak to <a-X> as I don’t think I’ve used it much
New addition to this branch : swap the <space> and , keys
The fact of using <space> to trigger the user-mode was already spread in the community following the lead of the approach found in other projects like Spacemacs or Doom Emacs
BTW to make plugins compatible with swapped <space> and , while maintaining compatibility with the old behavior, you can replace
<space> with <space><esc>,<esc> and
<a-space> with <a-space><esc><a-,><esc>
Similarly, <a-x> can be replaced with <semicolon>x, which works across the breaking change
The thirteenth plugin (kak-lsp) is a little larger in scope, and will require some testing before I’m confident I managed to address the breaking changes.
Thanks. This is getting into nasty-hack territory though, unlike the above ghgl.
Also, I really don’t think plugin authors should have to keep up with breaking changes in basic keyboard functionality. Perhaps there should be real commands so one doesn’t have to “code” in cryptic exec sequences.
Haha yeah I think a day went by before kak-lsp had an update to address the breaking changes. I was considering upstreaming my changes after having tested them for a couple days, seems someone was much faster than I was
Also, I really don’t think plugin authors should have to keep up with breaking changes in basic keyboard functionality.
I agree that if it became a recurring issue it would be difficult to handle, but as it is breaking changes don’t happen frequently and these ones in particular are easy enough to address
Perhaps there should be real commands so one doesn’t have to “code” in cryptic exec sequences.
I don’t personally see how this would address breaking changes. It would add more surface area to the editor, which in turn would increase pressure for breaking changes because there is more room for mistakes. We would just have a new thread for feedback on the breaking changes to the “real commands”, not to mention hundreds of new issues for bugs
I mean add something like exec-command enter-user-mode alpha; then, exec <space> alpha (or exec , alpha or whatever “they” decide the “perfect” key-de-jour is) would be an exact mirror of exec-command enter-user-mode, in exec-script. I don’t see how this adds room for mistakes etc. It would make plugins easier to write (and read) and reduce keymapping dependencies.
Similarly, exec-command keep-selections ..., exec-command select-all etc. So, create readable exec-command alternatives to existing cryptic exec-script keys.
Ahh okay that definitely makes more sense. Personally I would prefer to read the cryptic exec sequences because to me those keys are the representation of the action, but I definitely wouldn’t be opposed to a change like you suggested being made if others feel differently. As long as it wouldn’t increase the maintenance burden, or have other side effects that haven’t occurred to me.
I’m more on that side too, with time it makes more sense to me to read that bunch of letters, but maybe there could exist a way to escape commands as keys, like lets say <builtin-command-select-line> would behave accordingly to what it “mean” for a given kakoune version. When the behavior doesn’t change, but the symbol does, I think this could be a way to handle this, speaking of language, maybe the notion of dialects could be parameterized with certain command like exec, in the end, each user ends up developing its own dialect of kakoune.
exec <space> is particularly hard to search for in the codebase and debug. The workaround is nasty. And there’s a precedent, in the already-existing enter-user-mode command. So I would be most interested in a clear-secondary-selections command which would do whatever <space> used to do.
Anyway, @Delapouite where exactly should feedback go to? Separate github issues, mentioning the branch…?
exec " " can indeed be somewhat tricky to find. I guess that’s another reason to write exec <space> instead, because that’s easy to grep.
I don’t think it takes long to adapt plugins to this change. Which script is causing troubles?
The nasty workaround is only temporary and there are alternatives (you can keep a separate branch that uses the new behavior).
I don’t see much use in adding a clear-secondary-selections to the stdlib now (also it goes against the design). Even if we do, we still have to search existing scripts for exec <space>, and it’s not like we’ll change another time.
I have been using this branch for a few weeks, and I am a huge fan of all of the changes. Converting my kakrc and plugins only took five minutes. Especially selecting pasted content, that one is very intuitive.
