helix

helix copied to clipboard

This simple change makes it possible to set the default editing mode for newly opened editors to something other than normal mode. For example, to start in insert mode, just add

[editor]
initial-mode = "insert"

to the config.

I've always wished that Vim provided this option, since I find starting in insert mode more useful when I launch the editor to quickly write something down.

Seems to me this would also set any opened documents to change the mode? Say if you gd to another file?

Apologies if I did not read it correctly on my phone. I'll test it later today :)

EDIT: Yeah, it reverts to insert mode for all subsequent opens

newly opened editors

That statement is not currently correct, but I would love it to be! It would make it that much smoother using helix for my git editor. 👍🏻

@AlexanderBrevig

I can't reproduce that (or perhaps I'm misunderstanding you?). My steps are:

1. Set initial-mode = "insert" in the config.
2. Open two files.
3. Both are opened in insert mode, as desired.
4. Switch to normal mode in both files.
5. Switch back and forth between the files (I use gn, since I don't have LSP set up at the moment).
6. Both files remain in normal mode, as desired.

Try navigating to a new file. Use <spc>f or gd on a symbol. The new file is also insert mode. EDIT: granted, you found a bug in my POC implementation as only the first file will be INS with that. Should probably be moved to the handling of startup arguments/files then.

What I'm trying to say is that this feature is more like new-document-mode rather than initial-mode. I personally would love initial-mode but not at all a new-document-mode.

Keep in mind that I'm only a user and have no authority on this. 😊

Maybe @CBenoit should chime in? May I request this setting changes name to something like new-document-mode and I can make a PR for initial-mode? I just love not having to get to insert mode when writing git commits :D

I think I understand now. You would like only the first document opened in a Helix session to be opened in the specified mode.

That's not what I want, so as far as I'm concerned, this PR is working as intended. I'm also still happy with the name initial-mode, since it is the initial editing mode for documents. new-document-mode could be misleading, because it might wrongly suggest the mode applies only to newly created documents, rather than also documents opened from files.

If you are indeed making a PR for the alternate configuration you have proposed, may I suggest the configuration name launch-mode instead? I think launch-mode and initial-mode are simpler and more accurate than initial-mode and new-document-mode.

This simple change makes it possible to set the default editing mode for newly opened editors to something other than normal mode.

I really don't understand the use case for opening every document in INS mode. But "newly opened editors" makes a whole lot of sense.

I've spoken my mind (a few times already, sorry) and will wait with launch-mode till after this is merged.

initial /ɪˈnɪʃ(ə)l/ adjective existing or occurring at the beginning.

(it may be my vocabulary is a bit tied in with the code base, where the editor lives as long as what you call a session, and a document is what holds any visible buffer - from file or not)

I really don't understand the use case for opening every document in INS mode.

Long term, I want to make it possible to configure Helix as a modeless editor (just like some modeless editors can be configured for modal editing). Starting in insert mode (and never leaving it afterwards) is one of many puzzle pieces required for that to work.

As for the config name, I'm definitely still open to suggestions. "Initial" here refers to the initial state of each document, which IMO is logical since editing modes are defined on a per-document basis. I've also considered default-mode and standard-mode, but dislike them because the "default mode" is still normal mode, which we return to when Esc is pressed.

This is a bad idea in my opinion. Helix is not a modeless editor. If you want one, there are plenty of other options out there. We should not be encouraging more users to try to use helix as not-modal.

IMO this is too niche to warrant its own config option, especially since Helix is inherently modal as dead10ck says. I think this would be more elegant when scripting support comes - probably with some sort of hook mechanism that enters insert mode when on buffer creation. Until scripting support comes, this is a one-liner to maintain in a fork and merge conflicts should be trivial.

Since Helix suffers from the same fundamental bug as Vim and Kakoune, its default keymap is essentially unusable with many non-English keyboard layouts. So the user has the option to invent their own layout-independent modal bindings, or try to configure standard modeless bindings.

If you don't want to come up with your own bindings, and modeless configuration isn't supported, Helix effectively becomes a (keyboard) hardware-dependent editor, which would be an extremely sad limitation considering Helix's many other strengths.

I feel like I am saying this way more often than it should be said, but if you try to shoehorn a modal editor into a non-modal editor, you're gonna have a bad time. A non-exhaustive list of issues people have had that are a direct result of trying to make helix work in insert mode 100% of the time:

• https://github.com/helix-editor/helix/pull/2883#pullrequestreview-1029452126
• https://github.com/helix-editor/helix/issues/1381
• https://github.com/helix-editor/helix/issues/2409
• https://github.com/helix-editor/helix/issues/1583#issuecomment-1022812303
• surely others I do not have the time to comb through
• others reported in the chat room

I won't repeat myself about the reasoning again, feel free to read the issues. Helix is a modal editor, and we should not be encouraging its use as a non-modal editor.

The history of the world's software being heavily biased toward English and QWERTY is indeed unfortunate, but is a much much larger issue than this text editor, and we are not on a mission to solve the world's incompatibilities between locale, hardware, and software, and at this point in time in the project's life, we do not have the resources to provide a nice out of the box experience for every language and every physical keyboard layout. As frustrating as it may be to have to make your own key bindings, this is simply a resource issue.

Almost all source code in existence consists exclusively of ASCII symbols, yet Helix goes to enormous lengths to support Unicode, sacrificing simplicity and performance in the process. But the huge number of people who don't/can't use en-US keyboards get told to either figure out their own config or pound sand?

That makes no sense whatsoever.

Sure it does. Most of the heavy lifting with Unicode is done for us already in the form of well tested libraries that we don't have to maintain. Editing and displaying text in a single well defined international standard format is a much different beast than coming up with a key binding layout that works for the literal hundreds of physical keyboard layouts in existence. I'm not sure you're taking the time to appreciate the scope of that task before making demands of a loosely organized group of volunteers who work on this piece of software in their free time for no compensation. Kindly take your snark elsewhere.

This is also getting very off topic for this PR.

I'm not sure you're taking the time to appreciate the scope of that task before making demands of a loosely organized group of volunteers who work on this piece of software in their free time for no compensation.

Umm what? I created this PR. It's me who's working towards implementing a solution here. I make no demands from anybody. You commented here dropping a bunch of vaguely related issues that supposedly demonstrate why making the initial mode a config option is wrong, while offering nothing regarding the actual problem, besides "bad luck, that's how it is".

But whatever. If the attitude demonstrated in your comments is in any way representative of the Helix community as a whole, that's all I need to know.

Apologies, I've only seen this thread now. @p-e-w I'd like to apologize because this is certainly not the tone I'd like to set for the community. While I don't merge every PR, I think it's at least worth discussing proposals.

I'm not sure you're taking the time to appreciate the scope of that task before making demands of a loosely organized group of volunteers who work on this piece of software in their free time for no compensation. Kindly take your snark elsewhere.

I don't like the tone here. @p-e-w was just genuinely trying to fill a need they had, and none of the comments were snarky. We should strive to have a civilized discussion here rather than scaring away developers that are willingly trying to contribute.

While this specific PR is a one-line change, I, for one appreciated @p-e-w's input in https://github.com/helix-editor/helix/pull/1623#issuecomment-1042612811 for example, given the past experience with the Micro editor.

I suggest taking some time to reflect on the sense of entitlement you have about other people supporting the use cases you need. No one who works on this project owes you anything.

I also didn't see this implied anywhere. Your reply was far sharper.

---

Now, regarding the PR itself:

There is some precedent in set insertmode in Vim. Kakoune on the other hand supports it with a script: https://github.com/mawww/kakoune/issues/4123

I want to make it possible to configure Helix as a modeless editor (just like some modeless editors can be configured for modal editing). Starting in insert mode (and never leaving it afterwards) is one of many puzzle pieces required for that to work.

I don't hold this as a design goal myself and wouldn't ship modeless mappings out of the box, but we should at least strive to make commands flexible enough to make this work with a custom config. We are already mostly there because commands aren't mode dependent, select mode is just simply a second set of mappings overlayed. It gets a bit trickier with undo state handling though.

Thanks for the feedback, @archseer. FWIW, the roadmap I had in mind towards configuring Helix as a modeless editor is something like:

1. Reset all default keybindings since we want to pretty much start from scratch (made possible by #2733)
2. Allow starting in insert mode (this PR)
3. Add an option for time-batched undo handling
4. Add an option for allowing selections in insert mode

I don't think there is much more to it than those items. While 3 and 4 are by no means trivial, they don't seem like insurmountable obstacles either.

A "modeless" editor is just a modal editor with a single mode. The reason why Helix can not yet be used modelessly isn't that Helix is a modal editor, but that Helix hardcodes certain behaviors into specific modes, rather than making them options for configuration. With enough options, it might even be possible to remove all mentions of "insert mode", "normal mode" etc. from the code itself and make modes (including the number of modes!) configuration-only, which would enable radical experimentation with new editing models that are modal, but not based on Vim.

It's also worth noting that there are currently zero modeless TUI editors that support LSP, DAP, Tree-Sitter, and many of the other great features Helix has. Making it possible to use Helix modelessly could therefore unlock a substantial market of users who work in the terminal and are currently stuck with Nano or Micro, neither of which provide advanced language features.

With enough options, it might even be possible to remove all mentions of "insert mode", "normal mode" etc. from the code itself and make modes (including the number of modes!) configuration-only, which would enable radical experimentation with new editing models that are modal, but not based on Vim.

This is something I was thinking about too! Similar to how i3-wm allow the user to define his very own modes besides the "default" one.

I would greatly appreciate this PR.

Helix isn't just a good modal editor, it's also just a good editor regardless - and as @p-e-w went over, the additional changes needed to make Helix work in a non-modal fashion are rather small.

@p-e-w Do you have a fork where you’ve implemented this and/or are working towards this goal? I’d love to see it and possibly be involved. As you mentioned, there is a huge gap right now for a “modeless TUI editor that supports LSP, DAP, Tree-Sitter, and many of the other great features Helix has” and given that Helix is currently introducing barriers of entry instead of removing them, I believe there’s room here either for a Helix installer that seamlessly configures Helix with friendly defaults (what I’ll likely end up creating) or (very much a last option) a fork.

(Ideally, of course, I’d love it if Helix was configurable enough that you could achieve this without a fork as – speaking from prior experience – it’s no fun to maintain a fork.)

As someone brand new to this community, I am quite surprised by Helix being less hostile to newbies than Vim and Emacs traditionally happen to be, in my experience.

Helix is the first modal editor, that makes sense for me. Out of the box, and even after configuring it a bit for myself. I must say, in parts, that had been easier than with VSCode.

That is also, why I think its very sad, and potentially extremely damaging to the project, if hostile behavior is encouraged by simply watching it happening. Just saying

---

Now about the issue: I like to fire up my editor, and start writing. Has nothing to do with using the editor in a non-modal fashion. I like the modes, they make sense here. I just like to sit down, and start typing.

The mode in which the editor starts for me, is preferably insert. Can we make this happen?

@p-e-w Could you open this once again, please 😃