Stop breaking users workflows on a whimp

[nkoehring]

Question

The last release just changed key mappings that are very commonly used. As a user who is using Kakoune productively it was very frustrating to learn, that my worklow now is completely broken and I have to spend time on figuring out what happened.

Why are such high impact changes happening? Why suddenly changing major key mappings like Space and ,? Why changing the behaviour of line selection (x) from a convenient "selects the next line on repeated pressing" to "selects a line, then ignores you, please use navigation keys"?

It would be really helpful to point out some reasoning behind those changes. Updating the editor should not suddenly break the whole workflow, and even less so without a good explanation.

[arrufat]

Hi! I might not be the best qualified person to answer you, but here my two cents, anyway.

• There was an explanation in the GitHub issues and even in the commit message that introduced the change: https://github.com/mawww/kakoune/commit/ef8a11b3dbefb8a1222974a8c34e15fa006d56e0, It was not a decision that was taken lightly.
• The goal of the change is to simplify the editing model of the editor by sticking to its core philosophy of orthogonal features.
• Finally, and on a humorous note, this repository description says: mawww's experiment for a better code editor. So, I am thankful that he keeps experimenting and improving the editor by simplifying it instead of further complicating it, which is a really hard thing to do.

I was also affected by this change, but I follow the changes closely by running the latest revision from master. It was a bit annoying at the beginning, due to the muscle memory, but it felt really natural after a couple of days. Now the behavior is more predictable, and we don't have this asymmetry of being able to select lines downwards but not upwards, for example.

And of course, you can always do:

map global normal X 'Jx'

[krobelus]

Thanks for a feedback. After upgrading, clippy will tell you what changed. It's easy (?) to add mappings to effectively restore the old behavior. Where would you have expected to find the rationale? For plugin authors, it could be helpful to provide recipes for upgrading in a forward-compatible way but most plugin authors already track master and have upgraded a while ago AFAIK.

[mawww]

@nkoehring I have hesitated quite a lot on whether it was worth it doing that breaking change. This was discussed on the IRC for a while, and when those changed were pushed I asked for feedback on them. I tried to get all the breaking changes I wanted to do in a single release, to minimize disruption.

It is quite hard to get a proper idea of how many people are using Kakoune and in particular what proportion of users do not interact through our communication channels (not that I expect users to, its just hard to predict how representative the IRC users are), so I assumed most users would be ok with those changes because feedback on IRC was positive.

There is a natural tension between backwards compatibility and having a clean design, I try not to break backwards compatibiliy without a good reason, but I do not want Kakoune to fossilize on decisions taken long ago that do not seem so good anymore.

All that to say, sorry for the frustration this caused, I am not sure how we could have improved communication on those breaking changes but suggestions are welcome, and I would not expect any more of those on the keymap in the near future.

[featherfurl]

This was very confusing for a few minutes and was the way I discovered kakoune had updated. Nice to see a new version!

[nkoehring]

Thank you for your honest answer. I can understand that it is hard to see users who are not directly interacting via IRC or Forums, etc. As a productive user of Kakoune I do not see those changes before because I do not expect this kind of changes. I also don't usually see the intro message because I directly open files with Kakoune most of the time. I really appreciate that there is a lot of discussion happening, and it is of course up to me to follow more closely. Unfortunately, I don't really have any better idea on how to improve this kind of situation without adding the bloat of some switches or similar. I would now close this ticket, because I guess all answers have been given.

[SolitudeSF]

@mawww just hijacking this issue to request help directly. its great that x/X is now consistant and im sure that its now more useful for scripting purposes, but for interactive use some people prefer old behaviour. you could (should) provide some migration notes that allow people to drop certain snippets into their configuration to restore previous interactive behaviour.

[asmarcz]

Hello, I am pretty indifferent to the discussed changes. I am, however, interested in the reasoning behind swapping <space> and ,. What advantages does it bring?

[arrufat]

@asmarcz you can read this https://github.com/mawww/kakoune/issues/2524, and in particular https://github.com/mawww/kakoune/issues/2524#issuecomment-438865177.

[DerSaidin]

This was very confusing for a few minutes, then I realized what happened.

I was in the habit of pressing <alt+x> and now I will only need to press x. After a week or so I'm about half-way on adapting to this change now, and I'm glad it was done. Thanks!

Do this breaking change next: https://github.com/mawww/kakoune/issues/1497 :D

[lobre]

I do like breaking changes, as long as they are sufficiently enlighted. Kakoune being clean/legacy-free is what has drawn me here from vim/neovim. I prefer an experimental editor that permits breaking changes to keep its core well-designed instead of preserving old behaviors just for compatibility reasons.

Orthogonality is the true power of Kakoune. If things remain there because of compatibility, they will rot and conflict with new design choices, and restrain people from quickly learning the editor in the future.

For something else such as a programming language, I would of course prefer compatibility so that my program keeps compiling as long as possible over time. But for an editor, I like that it is a clean and minimalist toy that I comprehend fully and that I can learn and teach rapidly, even if it changes over time.

I like that after all those years the pitch stays "experimentation for a better code editor". It means the experimentation phase is still ongoing and there are potentially things that are still to be discovered.

Some people could say that introducing breaking changes can be harmful to plugin maintainers. But I also like to think that Kakoune plugins are more personal plugins than published community plugins. Some plugins (such as kak-lsp) are actually well-known and broadly used. But to me, the selling point of kakscript is that it is an accessible playground that is just at hand for developers to quickly tweak the editor to their needs, compared to creating smooth and polished plugins that will be published and consumed by lots of other people.