Replies: 13 comments 15 replies
-
|
Can we have a better title? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, suggestion? “Reintroduce movement bindings?” ← better? |
Beta Was this translation helpful? Give feedback.
-
|
Maybe: |
Beta Was this translation helpful? Give feedback.
-
|
Done :) |
Beta Was this translation helpful? Give feedback.
-
|
I don't have a lot of skin in the game here because I haven't used Helix extensively yet but I don't think it's okay to break an existing workflow simply because someone doesn't agree with how a software is being used by others. If a feature has been introduced and users rely on it, it shouldn't be removed. If the development team feels that they don't want to encourage navigation in insert mode, they can make it opt-in by default. |
Beta Was this translation helpful? Give feedback.
-
|
@ayushnix The existing workflow (as well as the muscle memory learned from basically every other app you use on a computer) is what this change breaks. But you’re right, the dev team are well within their rights to introduce rites of passage before you can use an app. We have countless examples of this in the free and open source world. Take a look at Arch Linux, for example, or SourceHut. What the dev team should decide is what sort of culture they want to encourage. The thing that drew me to Helix was that it just worked and that I could adapt to it slowly as I learned it. I’m pretty sure that if I used it without those navigation bindings to begin with we wouldn’t be having this conversation. Because I wouldn’t have started using Helix. (And I think it would be shame to lose folks like that.) |
Beta Was this translation helpful? Give feedback.
-
To be clear, I'm not in favor of introducing rites of passage at the cost of breaking existing workflows. If those rites would've been introduced before the navigation in insert mode feature was introduced, that would've been a different story. As you've said, there are now people out there who feel comfortable using Helix using a feature it introduced and alienating those users at this point isn't a good thing. |
Beta Was this translation helpful? Give feedback.
-
Helix is still new software and we do introduce breaking changes every once a while. That's why we use calver instead of more stable versioning. I do try to keep them to a minimum, but it's too early to ossify bindings. |
Beta Was this translation helpful? Give feedback.
-
|
I just want to mention that if it is decided that #3671 be reverted, #3811 should be reverted along with it. |
Beta Was this translation helpful? Give feedback.
-
|
I think at this stage of Helix development it is good to be breaking things for future clarity/simplification and benefit, in this case it is simple to copy paste the relevant config back in, the situation is documented and the old config provided in the main documentation. What makes Helix great is that it is highly opinionated, and those opinions are usually excellent. Otherwise we end up back in Neovim land where everything is 100% customizable and the user has this burden to create their own workflow, even choose their own key bindings in the case of many plugins. The dominant philosophy should be enforced in the defaults, this is a good thing, it makes for a strong editor with a strong mission. My only use for the arrow keys in insert was to overcome the auto pairs behaviour, but perhaps I am missing something obvious? If I type |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
@YangtseSu of course, |
Beta Was this translation helpful? Give feedback.
-
|
For autopairs you can type the closing pair, for example |
Beta Was this translation helpful? Give feedback.
-
|
I am the author of the PR. I encourage anyone who wants to discuss this to read through all the discussion in that PR in its full context before commenting. But for convenience, I'll repost some of my comments here: This isn't just a case of helix being able to do both modal and modeless editing equally well and us forcing our opinions on everyone. This doesn't have anything to do with creating "rites of passage." Helix is designed to work well with modal editing and not non-modal editing. The latter causes a bad experience for many who try to force helix to be what it isn't. We get many complaints from new users trying to use helix in a way that was never intended. It's better not to mislead new users into thinking they can use helix like VSCode or Sublime when they really can't. Providing users a way to move around with arrows in insert mode by default sets up the experience for new users coming from modeless editors to fall into the trap of thinking they can just do that they've done in other editors, thus users trying things like binding A non-exhaustive list of the issues that helix has that are a direct consequence of staying in insert mode:
I've lost count of the number of users running into these issues or some variation and bringing it up in the matrix room. This comment lays out a reasonable roadmap to good support for modeless editing, though it is a very nontrivial effort just to figure out the UX and expected behavior, let alone to implement it. I think I've made clear in other comments that personally I don't think it's worth the additional long term maintenance burden to try to retroactively change the internal mechanics to support both ways of editing, but if someone or some group of people put forth the effort and came up with something that worked well, didn't hinder the default kakoune-like experience, and didn't add significant maintenance burden, then the main author and other maintainers have expressed support for this. But I think until that happens, we shouldn't mislead the expectations of new users, as this will just lead to more frustration for everyone involved. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your explanation. It helps to understand the mindset. Managing the expectations of users coming from a modeless editor (like vscode) is honorable. But I think we should also manage the expectations of users coming from a modal editor like vim, neovim or kakoune, and those do support arrow-key motions in insert mode. The first thing we read about helix is:
Please don't forget users who come from either neovim or kakoune. But what puzzles me most is that you said here:
That is what makes the whole thing look like a rite of passage to me. Basically, you agree that it is good to have the motion in insert mode, but don't want to enable it by default. So new users have to deal with the fact that it is not supported by default (even if they come from another modal editor) until they figure out that it is actually normal and expected to configure the keymaps. The least I can say is that I disagree with this design philosophy. |
Beta Was this translation helpful? Give feedback.
-
It is normal and expected to configure the key maps. This isn't a rite of passage, this is just using a tool. Any tool, but especially a text editor meant for editing code. The default key map will not and cannot be suitable for every user. Even more generally speaking, every feature cannot and will not be suitable for every user out of the box. To come to a new tool as complicated as a code editor and to just expect everything to work just the way you need it to is not realistic. Configuration exists to give users the flexibility to make their tool work the way that suits them the best. It is not a rite of passage, it is a fact of life. |
Beta Was this translation helpful? Give feedback.
-
Yes, I agree... to some extent. But the editor should also come with good defaults. And I think a good default is when a new user can comfortably use the editor without configuring it at first. And then later, when the user becomes more proficient, they can leverage the configuration to get the most out of the editor. As the developers of any tool, we do want to minimize the amount of configuration needed. I hope helix will not unbind the escape key to enter the normal mode, just because "It is normal and expected to configure the key maps"... When it comes to the movement in insert mode, the current situation is not comfortable for a new user. Every new user is immediately asked to understand why things are the way they are and what are their options to work around the situation. To be honest, I don't understand how you can say at the same time "motion in insert mode is good I use it myself" and "new users should not have it until they configure it for themselves". I see nothing but a rite of passage. If you don't see it, we'll have to agree to disagree. |
Beta Was this translation helpful? Give feedback.
-
I don't see this is a particularly hard line stance. The editor as a whole is a far cry from the extreme stance of kakoune, where you have to use a plug-in to even insert spaces instead of hard tabs. And this isn't a slippery slope to such a place either. I also don't think it's a rite of passage to have to front load some research into a new tool with a novel model of editing when the editor advertises itself as such. There is a middle ground between "having to read a book and recite Elvish poetry to write hello world" and "this tool reads my mind, my deepest desires, and writes the code for me". It's not unreasonable to expect new users to learn a little bit about their tool. But yeah if you don't agree, that's okay too. I respect your opinion even if I don't agree with it. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this is a yes/no thing, I do vote yes for revert but I don't want movement keys with ctrl-*, I am fine with reverting arrow keys and special keys only (or non-control emacs style movement only keys), the other ctrl-* stuff I don't think so yet. |
Beta Was this translation helpful? Give feedback.
-
|
Default settings should not discourage beginners! Please keep the ability to use |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to state that movement was never intended to be supported in insert mode during the initial design and the fact that it does was a "happy accident". I was in surprise this even worked in the first place (and doesn't mess with the changeset/transaction logic) when the PR initially added these mappings. |
Beta Was this translation helpful? Give feedback.
-
|
Update: #3915 💕 |
Beta Was this translation helpful? Give feedback.
-
|
I would keep |
Beta Was this translation helpful? Give feedback.
-
|
Whatever decision will be made, please update the docs. If they say arrow keys work in Insert and then they are not, it certainly feels like a bug and bad experience. |
Beta Was this translation helpful? Give feedback.
-
|
The docs are for the stable release. |
Beta Was this translation helpful? Give feedback.
-
|
There is documentation for stable and master published separately: |
Beta Was this translation helpful? Give feedback.
-
|
I think it is important to note that on most keyboards, the arrow keys and home/end/pgup/pgdown are physically separated from the rest of the keyboard (or exist as smaller keys squished into the bottom right corner). Having those keys available for movement does not impact the process of typing in insert mode at all, but may provide many benefits. Anything more complex than moving a single char/line should be modal to not confuse newcomers about how to properly use the rest of the keymap/editor. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, stripping insert to the bone does not help with usage. It would be really nice if changing modes was something you do because one mode does the job better than another, and not because it is written on a wall that things should be one way or another. I don't say it as a criticism, but as something to think. Making rules more reasonable is always a good thing. |
Beta Was this translation helpful? Give feedback.
-
I’d highly recommend reverting #3671 and reintroducing movement bindings by default in “insert”/editing mode.
Top reason:
Do not create a rite of passage.
Even the author of the PR has reintroduced the bindings for themselves. If even the author of the PR is not willing to use the new defaults we shouldn’t have them as the defaults.
If there is a feature you know everyone will want to activate in your app, you do not deactivate it by default and make everyone change their config file, you implement it as a default.
(I won’t repeat everything I wrote here: #3671 (comment))
Thoughts?
78 votes ·
Beta Was this translation helpful? Give feedback.
All reactions