-
|
I'm not really sure whether this should be a feature request or a bug report. Let me ask this here first - maybe I've overlooked something. I'm a long time (25+ years) Emacs user that moved to Helix about a year ago. I'm really enjoying the experience and I find that Helix is a fantastic text editor, especially due to its out-of-the-box tree-sitter and lsp-integration. I find that Helix' improved-over-vi modal approach especially shines for sources that are structured like programming languages and where one frequently needs to navigate between units of text that have different structural properties about them (types, variable names, functions, etc.). When I edit longer text files (books chapters, readmes, etc.) I still find myself reaching for Emacs. In "letter-soup" everything is just a paragraph, a sentence, a word, or a letter, and Emacs's non-modal approach just works beautifully. Helix is especially lacking when it comes to reflowing text. There are two features that I especially miss. One is purely about the "user-interface" of Emacs' built-in Let me give you an example. Emacs is always in insert mode. Say I'm editing the following text. Emacs' cursor is over the "e" in "aute" (which I've indicated above with The cursor stays over the "e" in "aute". This is critical to preserve mental context!
The original cursor position I'm aware of Helix' If after step 1. above we insert a step 1b. where we hit (which never explicitly existed) and not as one could reasonably expect. I noticed this because I tried to define the key I tried a very large number of variations of And could not find one that gives me a good-enough approximation of Another problem was that I could not find a Helix command that corresponds to the key sequence There is another feature of Emacs that I really miss in Helix. Emacs' In Emacs results in Whereas Helix' which is just an abomination. Emacs' I realize that Helix does not aspire to become Emacs on purpose and by design. I completely agree with this. But when Emacs does something better, there is no reason to not seek inspiration there. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
I think the jump list may be a bug. It looks like the head of the range is preserved but the anchor gets reset to the start of the replacement range. But equally, that might be intentional/unavoidable/a unfortunate consequence of the current implementation. If you search past issues for reflow stuff, there have been a lot of complications with it over the years. Since the head seems still to be in the right place though, you could just I don’t think there’s a Putting it all together: As far as the abominable behaviour goes, it seems consistent to me:
If you tell it to |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your explanations, Waddie! Especially the last paragraph helped me get a better grasp of the Helix philosophy with regard to multiple selections. With your help I also managed to get a "good-enough" emulation of I had to put the following into my config: Note that they are not symmetrical! For some strange reason anchor and head need to be swapped in the first case, while they must not be swapped in the second. I suspect that this is a bug. |
Beta Was this translation helpful? Give feedback.
-
|
I filed a bug report. |
Beta Was this translation helpful? Give feedback.



I think the jump list may be a bug. It looks like the head of the range is preserved but the anchor gets reset to the start of the replacement range. But equally, that might be intentional/unavoidable/a unfortunate consequence of the current implementation. If you search past issues for reflow stuff, there have been a lot of complications with it over the years.
Since the head seems still to be in the right place though, you could just
<C-o><A-;>lto get back to your saved jump point:I don’t think there’s a
:command for tree-sitter matches, only themi/akeybindings. You can’t put an@sequence in a[":foo"]binding, but you can type anything in a@foosequence e.g.@mip:reflow<ret>Pu…