Remove default insert mode movement bindings #3671
Conversation
There was a problem hiding this comment.
I agree with this, this should be a user-friendly modal editor, and it's not user-friendly to allow people to do something that is counter-intuitive to how a modal editor works and conflicts with other things like autocomplete suggestions that also use the arrow keys in insert mode. I always found it strange that Vim allowed you to use the arrow keys in insert mode, I don't think that should be repeated here
|
Also needs to update https://github.com/helix-editor/helix/blob/master/book/src/keymap.md#insert-mode (I'd also remove the |
dead10ck
force-pushed
the
helix-is-modal
branch
from
50c0679 to
e6c86a6
Compare
Helix is first and foremost a modal editor. Willingness to support non-modal editing is there, but it is not one that should be encouraged with the default settings. There are an increasing number of users who are stumbling because they are trying to use Helix as a non-modal editor, so this is an effort to encourage new users to stop and take notice that Helix has a different paradigm than VSCode, Sublime, etc. Users can still add these bindings back to their own configs if they wish.
dead10ck
force-pushed
the
helix-is-modal
branch
from
e6c86a6 to
c8481a6
Compare
|
Done |
|
Why not introduce a configure people can remove instead of doing this dramatic change to how the editor behaves? This increases the barrier of entry and forces people to add a whole configuration if they like the normal behaviour (in all apps and editors) being a modal editor should be something you take advantage of and not an imposition. As a power user it is up to you to turn off what you don't like or just not use it. IMO it doesn't make any sense to remove this for everybody based on your personal view of what a modal/non-modal editor should behave like. |
|
As you can see in the linked issue above #3762, people will likely not know this can be turned on and off. I would suggest reverting this change and introducing a configuration that turns off navigation for yourself rather than forcing everyone into this opinionated view of what navigation should be |
Maybe turn off for default, then a configuration that turns on navigation. |
This isn't just a case of helix being able to do both equally well and us forcing our opinions on everyone. 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. |
Do you have some examples of those complaints? Can you also elaborate on why it's not ready for non modal editing? Also I think we're talking about navigate in insert mode and not editing from outside insert mode right? I'm struggling to understand the underlying problem, this feels like a heavy handed solution that affects barrier to entry, that's why I would like to understand the issue better, maybe there is a more subtle solution to the problem? |
|
@mangas a non-exhaustive list:
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 @archseer has 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. |
Just reading through those, the only one stands out to me is the autocomplete one as being related to navigation while in insert mode. I do see the point you are making on the others as they seem mostly wrong usage (undo, save, on insert). None of that seems to really be directly related to navigation. Perhaps adjusting binds to not support commands (:w) or undo would be a solution without removing navigation by default? Thoughts? Another aspect could be adding some FAQ type thing that can be linked to in these types of issues? |
|
@mangas it's not necessarily that navigation in insert mode in and of itself is buggy (though that auto complete pop-up is one), but that 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 I understand it's inconvenient to have this break when it worked before and to have to add these bindings back to your config (I had to add them back to my own config too), but this really is just about setting expectations for new users that are not coming from other modal editors that they will not just be able to keep doing what they're used to and still have a good experience. At least until other bigger roadblocks to that are fixed. |
|
I really disagree with supporting modeless editing like those global bindings as it defeats a lot of the purpose of this type of editor but I also don't think removing these bindings will do a lot for adoption. It doesn't really solve the issue, eventually someone will be sharing the old config that we've added back and people will do the same. This seems to be a technical solution to an education/people problem IMO and that's why I wanted to raise it. |
|
I fully agree with you, I don't think it will be in the best interest of the project to try to be everything for everyone; I worry doing a bunch of post-facto engineering to staple on modeless editing will make it harder to support both ways of editing. This could very well be selection bias, as this is the only editor I've ever been closely involved with in the code and the community, but it seems to me that for whatever reason, helix is drawing a lot of folks from non-modal editors who want it to support the workflow they're used to, and get surprised, frustrated, and demanding when it doesn't work well, even though the project has never advertised itself as anything but modal. I've never seen such complaints about vim or kakoune. And I think you're absolutely right that this won't truly solve the problem of users trying to make helix what it is not, but my thinking was that for the users who just download and start trying it without reading any docs, it would at least make them aware of this right up front, instead of trying it out for a little bit with some success, but then hitting one of these other issues and going straight to the issue tracker or chat room to report a "bug". The project has quite a lot of legitimate work that needs tracking, and having users ask for the thousandth time why undo isn't working just makes it more difficult for the maintainers to keep up with triaging, which is already a tedious and thankless task. If the user wants to go ahead with using helix in a way that it was not intended, they can make a conscious effort to do so. My expectation is that this will cause a temporary uptick of complaints from users who were used to using their arrow keys, but my hope is that it will help over time by reducing the number of repeat complaints by making it clear up front that you should not be staying in insert mode 100% of the time. I could be wrong. But if that's the case, this change need not be permanent. |
|
While I understand the desire to emphasize modal editing and discourage staying in insert mode more than is necessary, I worry that disabling arrow keys by default is extreme. Consider typing a new line containing a matched pair of delimiters, like Maybe my pinkies will thank me one day, but I'm not convinced this is a better workflow. The key insight of a modal editor is that we usually spend more time reading and editing text than composing it, but the experience of composing text shouldn't be ignored either. Having to drop and reenter insert mode just to move the cursor past a delimiter creates a drag on composing at the "speed of thought." We also all make typos, and often (IMO) it's more convenient to use arrow keys to fix one or two characters than to leave insert mode. Note also that backspace still works fine in insert mode, and I hope this doesn't change either. I don't think it's a crime against modal editors to admit that, nor do I think making an insert mode as austere as humanly possible is a necessary condition or goal of modal editing. But maybe I'm misunderstanding Helix's goals here. Finally, I know the original behavior is achievable by remapping the keys, which I've done. (I made this comment in the first place because I was annoyed enough by the behavior while trying to navigate quotation marks editing my config). But if the ship's really sailed on this being the default, perhaps there should be an easy opt-in option to get the old behavior back ( |
|
Could we just add the full block keymaps needed to replicate this to the doc/faq? That way we don't need yet another config option but the users can just copy-paste the whole block as needed. |
|
I think that's necessary but I think it will just bring the old problem back because once people find the keys they will go back to misusing them but I guess it's either that or adding an FAQ section of helix does not support modeless operations (saving, undo, etc) |
You can actually just type the second quotation mark; helix will skip over it instead of inserting another one.
Sure, I can put that on my to do list.
That's true, but this way at least they're making a conscious decision to misuse them, and they've been made aware that this isn't how it was designed to be used. If they want to come forth and contribute to the discussion or implementation of how to better support modeless editing, this would be welcome, but my hope is that it will at least reduce the number of users who might come to the hasty but logical conclusion that "this should work, but it doesn't" |
|
@mangas I think it's still better than having them built-in or behind a single flag. It's a stronger statement: "we don't think you should use these by default, but if you really want to, here's the user config". Not everyone is prepared to do it "the proper way" |
Mostly worried about the newcomer experience although I do think it's a step in the right direction |
|
I added all the removed bindings back to the example config in the book: #3827 |
I have been using helix for one week and I just want to share my opinion on this topic as a "new user coming from modeless editors". Until recently I never succeeded to get on board modal editing. I was interested to find out what the fuss was about and I tried vi and vim a couple of times but never managed to type anything useful and ended up having to reboot my PC because I could not exit the editor -- I am barely exaggerating. Then I experienced helix as a aha! moment. I could move around and type stuff AND I could start using powerful key combinations as well. It is precisely because helix provided navigation in edit mode out of the box that I could get on board as a newcomer. In that configuration helix is a midway point that provides a starting point for newcomers to explore modal editing. That is maybe why you are seeing so many of them around. I have now reached a point where I understand why edit mode should be used for editing and not navigation and I may not re-enable navigation in edit mode (and if I want to do it after all, I know how). But for those new users that will arrive after the default has changed, they will have to climb a much steeper learning curve and may never find out that the option to navigate in edit mode exists to help them get on board. |
So you know that we will add these 4 lines back, and you insist on deleting them. |
Who is "we"? I don't plan on adding those 4 lines back. Using the arrow keys in insert mode is counter-intuitive to how a modal editor works. There's the saying "just because you can do something, doesn't mean you should", but if you really want to, why not use a modeless editor that has LSP support and lots of keyboard shortcuts? What are the advantages of using arrow keys over navigation in normal mode? I think a lot of people new to modal editors who want to learn how to get the most out of a modal editor (like me) will appreciate this change. It's very easy to get into bad habits, especially when your editor allows you to do them by default. If people can add these back in via the config, I fail to see the issue. The release notes will acknowledge this change so people using the release version won't be caught off guard. |
I strongly disagree. Modes are about changing keybindings to suit the task you're currently doing. Those keybindings change to support faster, more ergonomic operations than one global keybinding pool. Using e.g. arrow keys in insert mode can be faster and more ergonomic than dropping into normal mode, moving, then entering insert mode again. Most importantly, in my experience this is a very common situation and we should make it easy to optimize for. There is nothing counter intuitive here. If your movement operation is very complex, then it might make more sense to activate normal mode for the movement. But it very much depends on what you want to do. |
|
There's also the argument for consistency. If you follow the Helix :tutor, it will tell you that it's better to use the HJKL keys for movement even though the arrow keys work. But HJKL doesn't work in insert mode effectively disabling navigation, it's only the arrow key users who still have this capability. I can't see there being many people (if any?) who use HJKL and switch to the arrow keys in insert mode. The only "bug" right now relating to using arrow keys in insert mode is the autocomplete but there could be more in the future as the devs aren't expecting people to use the arrow keys in insert mode as much as some people are. At a later point we may have plugin support where some plugins could also cause conflicts when using arrow key navigation in insert mode. |
Not really the topic here: I remember an external repo with a non-modal
Default settings should not discourage beginners! Please keep the ability to use [keys.insert]
up = "move_line_up"
down = "move_line_down"
left = "move_char_left"
right = "move_char_right"Being more more papist than the Pope here is not helpful for easing the first Edit: Besides, I fully agree with @dylrich arrow keys in insert mode can be faster and more ergonomic than dropping into normal mode, moving, then entering insert mode again.. I am using Vim for ages and still need the arrow keys to be productive. Edit 2: My issue is about the arrow keys only. Removing all other insert mode bindings is fine for me. |
I don't see how this discourages beginners. People new to the editor will either go to the documentation or the in-editor tutor. The default mode is normal mode, which can be scrolled with the arrow keys, the tutor will tell them the rest. Beginners will either know that it's a modal editor and they need to learn how to use it, or once they learn it's a modal editor they will look for something else.
I'm not really sure what this means. The defaults should be logical, sensible and allow you to get the most out of the editor. There is no "education" aspect but at the same time if the user configures the application in an unusual way, it's possible they will run into issues that might not necessarily be considered bugs (e.g. like this autocomplete issue). GIven it's a modal editor with a specific mode for navigation, and that navigating via HJKL wouldn't allow you to navigate in insert mode either, I don't see how being able to navigate with the arrow keys in insert mode is a sensible default aside from matching Vim/Kakoune functionality or that up-arrow is quicker than doing |
The patch was just needed to fix a panic with the repeat operator tracking. We fixed that in the last release.
Well, the arrow keys are there in normal mode for the same reason they were in insert mode: some users complained/wanted them. I personally don't use these keybinds in either mode. |
|
Looking at how my colleagues uses vim, pressing i then do everything like a normal editor esc makes me rethink whether to remove the arrow keys in insert mode, I think it's fine having it since advanced users won't be using it but at the very least users who don't care about modal editing can still use it too, like they can just press i, do anything they want and press esc, I personally won't use arrow keys too. I think we should have the arrow keys back for those who need it, helix at the very least have way better defaults compared to vi and vim, for those users that don't care and just need an editor, helix could be a drop-in replacement. |
In normal mode it's fine, the arrow keys on the keyboard are primarily designed for navigation, even if they aren't the best option for a modal editor. Insert mode is for entering and removing text, but not for navigating around text. Once some users realize they can navigate around Helix in insert mode like they could do in Nano, then they will just try to use the editor like Nano. At least if the defaults stop them from doing it, they will either look to the documentation to figure out the correct way to do it, find a way of reversing it, or simply move to a modeless editor rather than trying to shoehorn modeless functionality into a modal editor. |
Advanced users won't need it and is useful for beginners. Revert part of helix-editor#3671.
This comment was marked as abuse.
This comment was marked as abuse.
|
@Zykino Comparing an open source project that is maintained by volunteers on their free time (one that no one is forcing you to use) to a government suppressing protest through violence comes across as ridiculous at best. You are welcome to start a civil discussion, but it doesn't seem like it is your intention to do so. Hurling insults and using inflammatory language will not get you anywhere, and this is the last response you will be getting on this front. |
|
You are right, I should have skipped the rant entirely. I edited it out. I apologize for what I said. |
|
I feel this kind of decision is really bad for the future of Helix, and honestly I am disappointed. But who cares? I am not a core contributor. |
* Keep arrow and special keys in insert Advanced users won't need it and is useful for beginners. Revert part of #3671. * Change text for insert mode section Co-authored-by: Blaž Hrastnik <blaz@mxxn.io> * Remove ctrl-up/down in insert * Reorganize insert keys and docs * Improve page up experience on last tutor The last tutor page can page down multiple times and it will break the heading on the 80x24 screen paging when reaching the last page, this keeps the style the same and make sure page up and down won't break it. Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
|
vim is such a niche editor that discussions like this are akin to a group of street thugs arguing about the finer points of a language no one alive today even remembers. These kinds of discussions don't do anything enamour more those whore are more productive with the mouse and |
@airtonix lol. Thanks for that, that was a pretty good chuckle. |
* Keep arrow and special keys in insert Advanced users won't need it and is useful for beginners. Revert part of helix-editor#3671. * Change text for insert mode section Co-authored-by: Blaž Hrastnik <blaz@mxxn.io> * Remove ctrl-up/down in insert * Reorganize insert keys and docs * Improve page up experience on last tutor The last tutor page can page down multiple times and it will break the heading on the 80x24 screen paging when reaching the last page, this keeps the style the same and make sure page up and down won't break it. Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
* Keep arrow and special keys in insert Advanced users won't need it and is useful for beginners. Revert part of helix-editor#3671. * Change text for insert mode section Co-authored-by: Blaž Hrastnik <blaz@mxxn.io> * Remove ctrl-up/down in insert * Reorganize insert keys and docs * Improve page up experience on last tutor The last tutor page can page down multiple times and it will break the heading on the 80x24 screen paging when reaching the last page, this keeps the style the same and make sure page up and down won't break it. Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
Helix is first and foremost a modal editor. Willingness to support non-modal editing is there, but it is not one that should be encouraged with the default settings. There are an increasing number of users who are stumbling because they are trying to use Helix as a non-modal editor, so this is an effort to encourage new users to stop and take notice that Helix has a different paradigm than VSCode, Sublime, etc. Users can still add these bindings back to their own configs if they wish.