Skip to content

some design quirks of Helix #3384

@adsick

Description

@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.

  1. 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.

  1. 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.

  1. 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)

  2. 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions