some design quirks of Helix

[adsick]

I am trying to use Helix for a couple of days and there is no day when I don't open some new strange and nonsense behavior.
Before the fellow maintaners reply that "this is intentional" or "we are not copying vim here!!" or better "you are holding it wrong".
I want to tell that these things make no sense to me and I suppose that they will be undesirable to 80% of other users as well.

Besides lack of functionality (that will get better in the future updates) I think there are things that are "simply wrong" about the program.
Now I will list some of the aspects I don't like. These are just examples which should point out the importance of caring about UX stuff and designing the program in a more sensible way (without pointing out how to do that).

Judge it as you are, it is my personal opinion but I feel that I am not as lazy as those who will be pushed away by Helix and leave it without bothering writing the feedback.

1. word-wise navigation in insert mode ('C-left', 'C-right')
   it works different (and awkward) compared to everything I've seen in long years of using pc's
   the issue is that it always lands on the wrong char (compared to what you see in 99% of text editing fields out there) and I didn't had much luck figuring out how to fix that while reading the docs.
   I think that Helix should follow some basic and well established ideas like this one, or it at least should be configurable to be like that (currently I don't see how can I fix those word-wise movements)

2. multiple cursors (and even worse) - their wrapping
   first I want to say that pushing for multiple cursor and selection is not good because these type of features require a big brains and extremely easy to mess up. These are unnecessarily complicated way of dealing with text and you have to be really cautious when pushing them forward - many people simply won't get it and it might be a disappointing UX for them.
   It is quite hard to explain all the ways in which multiple cursors are bad, but I will try to mention a few:

• Works only for well aligned texts. A one char left or right? rip multiple cursors.
• Wraps around line endings/beginnings. I don't know a single scenario when that would be useful, correct me if I'm wrong.
• Is really hard to reason about
• Bad "recoverability" when you mess it up - if you know a way

summary: focus on functionality that is used often and by the most users, suppress functionality that is used once a week and by the minority of users.

Maybe we can have some telemetry to track what features are actually used or simply make polls about it.
Or simply put: listen more to the users.

3. the keybindings are not perfect a.k.a. the universal problem of these types of programs
   there is only one solution - enforce configuration, experiment with it and. The app should be as configurable as possible so you can express any type of UX inside your config.toml (and share it with the community).
   maybe we could build some kind of tool that would allow to "vote" for specific keybinding solutions and share/obtain

It would be really great to have different "control schemes" built in similar to color themes so we people just pick what they like more (e.g. vim-style) and work without fighting the Helix/kakoune/whatever mindset. I'm aware of Helix-vim, but I feel like having such things built (and specifically designed to work well) is better than building and using workarounds all the time.

4. append mode and it's selection
   any reason why this can be useful?
   I've been trying to find a use for it by doing such thing (spoiler, I didn't succeeded)
   let's say you have

alpha something
beta else
gamma here

and you want to paste a fancy delimiter string between your the first and the second words like so:

alpha fancy delimiter string something
beta fancy delimiter string else
gamma fancy delimiter string here

you put the cursor on the last 'a' in alpha, press a for append mode, type in your fancy delimiter string, press 'esc' and now you want to use your extra-mega-cool "append" selection text (yank it and paste elsewhere) but there is a catch - the the last 'a' in alpha is still selected too, for no sensible reason (imho). I don't know maybe you can explain why it can be useful but I don't get it.

5. pickers are a bit weak now (but I hope they get better in the future)
   I personally prefer if there was JK navigation by default and then you can search using /
   also they lack tree view (like neotree)

6. lack of commands can break the user flow
   Idk why you can change dir (cd), open and write files, but can't delete, move (and rename) or create dirs. Yes you can use sh or external terminal, but wouldn't it be nice to just have this as normal commands.

I think that borrowing successful ideas from popular editors like Vim, VS Code and others is a good thing because their design is time proven (still not perfect so you can even improve on that, yeah) it is not a shame to "copy Vim" by setting 'C' to change the rest of the line, the other way around - it is a useful keybinding that many people recognize and find nice so no shame in that one.

The point of this issue is that I think that Helix's mindset is just broken and has no use in real world scenarios, you may say that I'm wrong but that's what I see&feel and others will find coping with Helix problematic too therefore it's traction is questionable.

I'm mostly talking not about the real bugs and other issues that (hopefully) will be fixed at some point in time, but rather some awkward design solutions (which I feel like not going to be fixed in the way other than hard-forking/modding/hard-configuring).

[AceofSpades5757]

IMHO...

I think this might be better broken up into a couple of issues and a discussion. I've found some of the design decisions different, but not inherently bad.

For 1, I couldn't replicate the issue. It feels the same as any other editor, although I never use ctrl-right or ctrl-left.
For 4, hitting a runs the append_mode command, which starts a selection. I've actually found this useful to rubber band around using the selection, although I wouldn't say this is a good or bad decision.

Also, I think Helix is more in line with Vim in terms of learning curve, where it takes time to ingest the style of the editor. I don't think it's possible to even begin to grasp Helix, even if you used it for a few days non-stop. Unless you have some background using something similar, which is really only Kakoune at this point.

[CptPotato]

I personally want to disagree with the point about multiple cursors being too complicated or niche.

Multiple cursors & selections is a feature that I use frequently and would not want to miss. Helix' implementation of this seems very straightforward to me (multiple cursors behave exactly like a single one) and the editor can be used perfectly fine without them if desired.

[carlosvigil]

Not sure, why my comment was marked as spam. I just started taking a look at and trying Helix but of the issues I search for there is often an attitude of alienation and unhelpfulness from some maintainers.

[archseer]

What comment are you talking about? I don't see it in this thread.

[carlosvigil]

I deleted it, it was a single sentence so I added more to not be seen as spamming by whatever marked it as such. I also didn't realize commenting would make this thread bubble up to the default view of discussions.

[dannylongeuay]

I switched to Helix from Neovim about 6 months ago and haven't looked back since.

1. I don't have much to say on this. I hardly do any navigation in insert mode. Overall, since I switched from Neovim to Helix, I feel I navigate faster in general.
2. First class support for multiple cursors are a major reason why I enjoy using Helix so much. This feature saves me tons of time.
3. I think for the most part, the default keybindings are pretty sensible and don't cause a lot of mental overhead. I would say stick with Helix for at least a week of daily use and see if you still feel the same way. A week was all it took for me unlearn the vim muscle memory.
4. I don't come across this particular scenario often. Maybe I just use Helix differently, but I've not had big issues with how append currently works.
5. This point I agree with, the pickers are still immature and could use improvements. The ability to toggle hidden/ignored files temporarily, better previews, save a picker to a "register", so that it could be re-called later, enhanced filtering, etc...
6. I agree with this point as well. The lack of some fundamental OS commands causes me to context switch quite a bit, but I believe this will be remedied over time.

[adsick]

@AceofSpades5757 first I thought you mean Rust's macros... btw I used rust programs to parse&generate large routine codes.

[joegm]

I just don't get how you guys use it

Here's a fun example for inspiration smiley:
click to expand

yeah, definitely every user does that, totally agree (jk)

The point is not that every user does things like this all the time, and most people wouldn't be able to do it that fluently and quickly (I assume this was rehearsed beforehand), but it more demonstrates its power to do more complex things quickly and visually. It is versatile and has plenty of regular use cases besides large routine code, and it gets easier if you force yourself to use it when you get an opportunity.

[CptPotato]

How did you do that? Are there key presses to go along with this?

@AceofSpades5757
Overall, to use multiple cursors effectively, I'd say these are some of the important moves:

• Selecting larger parts of code (x, %, mip, mif, ...)
• Splitting you selection into multiple ones
  • By line: Alts
  • By pattern: s + some regex
• Growing the selection downwards ShiftC
  • Works nicely with horizontally aligned or at least overlapping text
• Word/syntax based movements and selections in general
  • These allow you to work with text that has the same structure but doesn't necessarily line up
• Yanking and pasting y/p works per cursor

Here's a (too detailed) step by step of what's happening in the video:

---

1. So, I start by just pasting the relevant code of a vim theme from the clipboard SpaceP.

2. I check which lines I need and look for a common sequence to select them: In this case it's '#.

   • To get all those I select everything % and split the selection using s + '#<return>.
   • X will select each whole line, I manually go back one char because I don't want the newline (X_ would have been easier)
   • Small copy-paste trick: SpaceY to join and copy to the system clipboard, then select everything %, delete d and paste again SpaceP.
   • Now only relevant lines are left

3. Now I isolate what I need on each line.

   • I do the selection split like 2. again %s#<return>.
   • On the hex color codes, md' removes the next surrounding ' from each cursor.
   • I select and remove the end of each line (using visual mode and jumping to the end using gl or End)
   • I move backwards to the #, then in VIS mode ShiftF + : to select backwards up to the colon.
   • c to change it.
   • ... the rest of this step works similarly

4. Adding some comments (for no good reason but to show what's possible)

   • I select the theme key and copy it (again, yank works separately per selection)
   • ShiftO creates a line above
   • I type the comment and paste the theme key

5. I convert each hex code to an rgb float color. This is admittedly pretty hacky but showcases the :pipe command.

   • I move to the hex code.
   • miw to select, then ms( to surround with braces.
   • In INS mode, I split it into three separate bytes.
   • I select the line and split the selection again for each hex var Xs0x<return>.
   • I modify the hex code into a mathematical expression to do the hex -> dec -> divide by 255 transformation.
     (this is now meant to be the input command for an external application)
   • After selecting the command I pipe it through fend
     • fend can evaluate that expression and I get the final result
   • I remove the newline that fend added as well as the approx. text
   • Lastly I just add the Color::rgb_f32 function call

[Ed1123]

I just don't get how you guys use it

Here's a fun example for inspiration smiley:
click to expand

yeah, definitely every user does that, totally agree (jk)

I do those kinds of edits with multiple cursors and I don't think I'm writing bad code...

[Zoybean]

delete d and paste again SpaceP

you might like to know about R and SpaceR to replace selection content with clipboard content. If you were using the internal clipboard and tried dP you'd notice that you just pasted back what you deleted, but R maintains your clipboard.

[joegm]

lack of commands can break the user flow
Idk why you can change dir (cd), open and write files, but can't delete, move (and rename) or create dirs. Yes you can use sh or external terminal, but wouldn't it be nice to just have this as normal commands.

The reason :cd is its own command is because it changes cwd directory of the editor. :sh opens a separate process in which cd would have no lasting effect once the command finished.

What advantage would having come from having these as top level commands instead of :sh rm|mv|mkdir? That is the reason :sh was made in the first place.

[adsick]

hat advantage would having come from having these as top level commands instead of :sh rm|mv|mkdir? That is the reason :sh was made in the first place.

1. it is quicker to write :rm file than :sh rm file
2. Helix will be then aware of changes without need to "watch" dirs and files
3. I meant that if you have 'cd' then it is expected to have mv/rm/mkdir as well. imo.

[joegm]

1. If you are using that command so often that three keystrokes makes a significant impact then you should either set up a keybind for it or have a separate terminal open. I don't see the need to add more commands without some useful side effect related to editing (see below).

2. A :mv file.txt ... which changes the buffer name of file.txt as well as the file name could be desirable. A :rm file.txt which deletes and closes the buffer of and file.txt if it is open is another idea, and the only good use I can think of such a command. The problem with that is a new user may not expect it to close the buffer, and might have intended to keep it around to, say, copy a portion of it somewhere else, which could be damaging if it was an important file. I still can't think of any good reason for a :mkdir.

3. That's true. The distinction between :cd and :sh .. isn't obvious at first but think the difference isn't really confusing once you know, maybe we should work to make that a bit more obvious.

[AceofSpades5757]

This is extremely common in editors and environments like this. People write shortcuts and plugins to add similar functionality, for convenience, but I don't think it makes any sense putting shell commands directly into the editor commands. They're two different environments, with two different contexts. I do understand how people coming from Sublime, VS Code, etc. get confused.

[antoyo]

I tried Helix for a couple weeks, but I don't daily drive it yet since I'm missing some features.

Anyway, I wanted to contribute to the discussion regarding word navigation:
I don't use it in insert mode, but I've had issues in normal mode.
The issue is different there, and I'm not sure if I'm just not used to Helix yet, but I felt like when I move the cursor, I don't end up at the optimal location, meaning I can't immediately do the action I intended to do.
It's just a feeling for now since I haven't investigated yet, so if other people have a similar issue, please contribute your thoughts.
If not, I'll post my thoughts when I have investigated this, which make take a couple months since I need to implement some features I'm missing in Helix before completely switching to using it.

[adsick]

check out my new issue regarding cursor positioning in word navigation: #3395 (it is still about insert mode)

[antoyo]

Yeah, I wasn't sure if it would be the right place to talk about this.
I wanted to know if you had any thoughts regarding movement in normal mode.

[ghost]

Try this in your configuration:

 [keys.normal]
  w = ["move_next_word_start","move_char_right"]
  e = ["move_next_word_end","move_char_right"]
  b = ["move_prev_word_start","collapse_selection"]

[adsick]

I think that it makes sence, but probably won't fix all of the problems. Thanks anyway.

[ghost]

This might.

[archseer]

The point of this issue is that I think that Helix's mindset is just broken and has no use in real world scenarios, you may say that I'm wrong but that's what I see&feel and others will find coping with Helix problematic too therefore it's traction is questionable.

I find blanket statements like this hurtful, given that there's a whole userbase that genuinely prefers the way things are. As you can imagine, being told you spent hundreds of hours building something that is broken and has no use in real world scenarios is great. I appreciate trying to start a constructive discussion about the design, I just don't appreciate the tone.

it's traction is questionable

It doesn't seem like it so far? Since this is open source I'm also not striving for mass adoption, I'm just working on an editor I like to use.

As per vision.md: "Don't try to be everything for everyone. There are many great editors out there to choose from. Let's make Helix one of those great options, with its own take on things."

If helix was a 1:1 vim clone but written in rust, what's the point of using it then?

1. Feel free to submit a patch. I don't use movements in insert mode and I personally wouldn't recommend using them either since they go against modal editing and will produce weird undo states.

2. It's a defining feature of Kakoune / Helix and something users prefer.

   Works only for well aligned texts. A one char left or right? rip multiple cursors.

   You're probably only using the C mapping, I recommend s etc to sub-filter a selected area. For example sfoocbar after selecting an entire function will rename all foo occurrences within that function.

Maybe we can have some telemetry to track what features are actually used

As we've seen with the hyper terminal release, that's a guaranteed way to get your users upset and stop trusting your project.

3. A full vim-style mode is impossible because we have no equivalent to vim's operator pending mode. Helix commands operate on selections (e.g. d deletes an existing selection), but in vim they need to wait for an object (d waits for w which then becomes the text object that's getting deleted)

4. /

5. There was j k navigation before but someone removed it for consistency (Resolve conflicts between prompt/picker bindings #1792). I personally also preferred those mappings. I'd also argue tree views and pickers are a different thing (there's also an open PR here File explorer and tree helper #2377)

6. Feel free to contribute. I personally don't do file management in the editor, but even having a way to define new user :commands would be nice, so you could alias :sh rm as :rm.

setting 'C' to change the rest of the line

You can do that in your user config. We map C to copy selection since that's what kakoune does. We follow kakoune behaviour, not vim.

I think there are things that are "simply wrong" about the program.

Everyone has different opinions of course. I imagine even if I addressed all your points exactly as you wanted, for example the C mapping, someone would open an issue saying "helix is unintuitive, I expect C to work as in kakoune".

[Bruflot]

If helix was a 1:1 vim clone but written in rust, what's the point of using it then?

/r/rust would like to have a word with you

[sicher]

As we've seen with the hyper terminal release, that's a guaranteed way to get your users upset and stop trusting your project.

How about allowing users to keep a local log of the command history? You can then ask if anyone wants to share it.