11 ms·

Even more hindsight on Vim, Helix and Kakoune

163 points by cosmojg 3y ago

akho 3y ago
Weird how different people can be. The only thing I found compelling in the “great features” list is snappiness. Otherwise, - subject-verb isn’t a universal improvement; Vim provides both through visual mode with an extra keypress, kak/helix only make one easy; - git integration looks sub-par for anyone familiar with magit / fugitive; - the level of discoverability is at “much worse than Emacs, but proud of the achievement”; - system integration is on a table stakes level. The extensibility / composability topic is close to my heart, but the particular take does not sound right. Emacs, for one, is not extensible like vs code is extensible, it’s runtime modifiable via insane levels of “internal” composability that is not achieved by other tools. It also works well with outside tools. I don't see what prevents the author from running magit separately; you can absolutely eval a magit-status from your command line. You'll lose editor integration, but that seems to be the point of the exercise? In this particular case, the whole philosophical comparison reads like an excuse for Helix’s limitations. TOML config would just make me angry on a daily basis. It’s okay to like simple simple things. Just don’t compare them with Emacs — it's an entirely different kind of thing. Apples, oranges, kitchen sinks.
cosmojg 3y ago
The author, Dimitri Sabadie (@phaazon[1]), is a prominent Kakoune contributor[2]. In this article, he offers his thoughts on Helix[3], how it compares and contrasts with Kakoune, and how both Helix and Kakoune improve on the tried-and-true Vi-inspired formula which continues to drive the popularity of keyboard-centric editors like Vim and Neovim. [1] https://github.com/phaazon https://github.com/phaazon [2] https://github.com/phaazon/kak-tree-sitter https://github.com/phaazon/kak-tree-sitter [3] https://helix-editor.com/ https://helix-editor.com/
softirq 3y ago
All I care about when it comes to editors is availability (on every platform, can be used in a terminal), longevity, and the community for third party plugins. Vim still checks all of those boxes and the only real other contender is still Emacs. Vim is super crusty, Kakoune and helix have better takes on the unix philosophy, integrations. VSCode is easier for absolute beginners to click around in. IntelliJ has better semantic parsing. But none of that matters. None of that holds me back from being successful. I just need an editor I can type code in that I will never have to give up, that will just be there, and I can use at the next job. In fact Vim's quick editing is just a nice to have, it's never been the difference between me killing it and getting killed at work. That's why I'm sticking with Vim.
- eviks 3y ago
  Why do you care so much about availability of an app that is unusable without a lot of plugins? At which point, you can copy plugin code with the editor app to a place you need it available in
  - bee_rider 3y ago
    “Unusable without any plugins” is quite a description to throw in there as an assumption.
    - bourneavent 3y ago
      It's barely useable. I rely a lot on code completion, search capabilities and syntax checking while I code. It just saves a lot of time from having to execute the compiler and wait for it to check everything. With good "plugins" or "features" all of these things happen async.
      - offices 3y ago
        Like Godwin's Law, every discussion of Vim on HN will inevitably tend towards complaining that it doesn't have features that it has shipped with 10-30 years.
        bourneavent 3y ago
        It doesn't have code completion. You can install it as a feature, but vim itself doesn't have that feature. There needs to be a law for someone either flat out lying or not knowing what they're talking about because godwin's law doesn't apply here. Additionally installing these features on vim is a nightmare for various reasons. It can be done, and I've done it, but the experience is not as good as the more clunkier GUI IDEs. I'm all for a TUI IDE if the experience was as automated or seamless as jetbrains or M$, but such a app doesn't exist yet.
        3y ago
dang 3y ago
Related ongoing thread: Why Kakoune – The quest for a better code editor (2016) - https://news.ycombinator.com/item?id=36424256 https://news.ycombinator.com/item?id=36424256 - June 2023 (56 comments)
kemiller 3y ago
I really want to like helix. I do like helix. The batteries included ethos is awesome. Multi-select is tantalizingly close to something really interesting. Buts its macro/keybinding vocabulary isn’t quiiiiite there yet. And tbh I’m not sold on multi-selection as the only paradigm.
- knodi123 3y ago
  > something really inter ?
  - kemiller 3y ago
    esting.
    - knodi123 3y ago
      Thank y
lll-o-lll 3y ago
Argh! I’ve been finally getting around to learning vi (vim), and now you are telling me that is so last century, I need Kakoune? At least Vim “mode” seems to be supported everywhere. Surely I get more bang for “time investment” than these others?
- rgoulter 3y ago
  vi is ubiquitous, so it's still a useful thing to have learned. Especially for fresh linux installs, or in default VM environments, it's useful to be able to use vi. Though, IME the cost of learning something like kakoune or helix's motion (having already learned vi) is quite low. -- The value-add of vi's modal editing doesn't go away just because something even nicer comes along; it does mean you get the chance to use something even nicer.
bccdee 3y ago
I really don't like Kakoune's model of extensibility. It's one of the reasons I switched back to Vim after using Kakoune as my main editor for several months. The configuration system is esoteric, fiddly, and (as of 4 years ago or so, when I last used it) not thoroughly documented. I think Helix made a good choice by building in LSP support and other things that would otherwise require extensions, and by having a "you don't really need it" policy for things like panes, which you can just do with tmux. And I think Neovim made a good choice by exporting a configuration/extension API in a very standard, commonplace extension language like Lua. I disagree that Neovim's Lua API is really a different language. It's just an API; Kakoune has one too, albeit of a more esoteric sort. Incidentally, I started using Helix a month or two ago and I've been liking it a lot. Having the language server stuff already integrated is a fantastic convenience. I could probably switch to using hx exclusively if I really wanted, even with no extension system whatsoever. The only thing I want that they haven't implemented yet is easymotion jumps, and there's an MR for that already [0]. [0]: https://github.com/helix-editor/helix/pull/3791 https://github.com/helix-editor/helix/pull/3791
- chrismorgan 3y ago
  Wait, no panes? What about things like diffing two files? There are also plenty of other situations too where I’ve definitely wanted splits in the same client, so I can see multiple files at once but also copy between them (which requires shared registers), write macros that switch between the panes (which… well, I suppose Kakoune’s composability approach might be able to support such a concept, but I get the impression Helix really wouldn’t), &c. Wow, https://github.com/helix-editor/helix/issues/405 https://github.com/helix-editor/helix/issues/405, indeed no side-by-side diffing and the approach being suggested would be hopelessly crippled for even two-way diff (let alone three- or four-way diff, which are probably just total non-starters), since it would only support editing one of the documents! Seriously, my mind is boggling at considering a “you don’t really need it” policy for at least splits. I really do need it: even on my base task load, tmux would be inadequate in painful ways multiple times per month; and I regularly (sometimes daily for weeks, though other times not for months on end) do things for which it would be completely debilitating so that I couldn’t possibly use Helix and would have to go back to Vim.
eviks 3y ago
> However, if you type w, the cursor will move to the end of the word while the anchor will move to its beginning, visually selecting the word Would be cool, but all it does is move the cursor to the end, anchor remains in the middle of the word (if you start from the middle)
- lwhsiao 3y ago
  You're right. One way to select a word from the middle in helix is `miw`.
  - n8henrie 3y ago
    Yes, I'm using `miwc` a lot (used to `ciw` in nvim)
- yonatan8070 3y ago
  You can use `bw` or `be` to do that
- taeric 3y ago
  I'm amused, as I immediately think, "er/expand-region" covers this like a champ. Complete with C-g leaving the cursor where you started, if you change your mind.
celeritascelery 3y ago
I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools. You can't take magit to vim or helix, because it is an Emacs extension. And each tool has it's own way of extending it, which means you need to learn essentially a new API (if not an entire language) to extend a tool. However extensibility makes it much easier to move within a tool. The authors sample kakoune config for doing splits is a great example. Since Kak doesn't support splits natively, you have to learn 3 separate tools do the spliting in a WM. In something like Emacs there is only one thing to learn to manage splits on all platforms. And it is using the same extension mechanisms you use for everything else. I found this the paragraph just before the conclusion to be an interesting demonstration of these trade-offs: > All of that to say that, the take of Helix is pretty good here, because all of those UNIX problems are not there in that editor: everything runs in the same process, inside the same memory region. The author spends a lot of time praising composability over extensibility, but then admits that Helix has some real advantages because it is not composed with tree-sitter or lsp, it has those built in. Essentially it was extended with those features, they become part of editor, instead of trying to interact with them in a uniform way. This reminded me of the xi-retrospective section[1] on modular software. composability works better on the small scale, but struggles when you have many independent things interacting with each other. It is fine for simple things like "using the shell to sort lines" or "bring your own fuzzy finder", but with more complicated integration it starts to falter. [1]https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
- taeric 3y ago
  I found https://yarchive.net/comp/linux/everything_is_file.html https://yarchive.net/comp/linux/everything_is_file.html a very compelling read today, on similar topics. Specifically, having a base set of abstractions that everything "speaks" is a huge boon that is often hard to articulate. Annoying, as the drawbacks and sheer number of edges is often much more easily described. TO that end, Emacs' "everything is open to everything else" works surprisingly well, once you get used to it. Especially so if you go with not introducing new primitives to makes things happen in the process. Even "async" is relatively easy once you get used to the sentinel approach. Can you imagine a better way? Almost certainly. I have yet to see one survive the test of so many contributors, though.
eviks 3y ago
The text editing examples are great illustrations of the power of the editor, but hard to follow in this static format that doesn't show transition from one state to another, so a little pic going back&worth might be better; also the cursor should be highlighted more instead of being just hardly visible gray
rizky05 3y ago
I want terminal editor that does not need me remembering keyboard shortcuts to edit things. Mouse should be optional, and editing without mouse should be the default. But every editing operation should be easy to access and sensible - You don't have to read any docs to navigate/edit/search/replace. When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary. You can say, I want VSCode that runs in terminal, but one that does not hog my cpu/memory. It should feels instant to do anything, without any loading time if possible.
- DiggyJohnson 3y ago
  Nano supports mouse, right?
- u801e 3y ago
  > I want terminal editor that does not need me remembering keyboard shortcuts to edit things. Keyboard shortcuts are essential to increase efficiency and speed. For example, ctrl-c, ctrl-v, ctrl-z, ctrl-s, ctrl-p, ctrl-a etc. People learn these early on if they regularly have to input/edit text to speed up their workflow. Otherwise, they would have to resort to pointing and clicking through menus to accomplish the same thing. The longer you use an editor, the more of these shortcuts you commit to (muscle) memory, so, even if the commonly used editing operation is easily accessable via the GUI interface, people are going to choose the keyboard shortcut to do the same thing since it's faster. > When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary. You could navigate with the mouse or arrow keys in either vim or emacs. The only thing you would have to learn is how to save the file. You may not even have to learn that because both vim and emacs display a dialog box asking you whether or not you want to save the file if you try to exit the editor without saving first.
- taeric 3y ago
  Tutorial "optional" is just weasel words for "works like things I already know." Problem is, especially in expert tooling, that everyone seems to know something else.
- friend_and_foe 3y ago
qolop 3y ago
I really want to use helix but was turned off by the lack of Copilot support and the developers' contempt and holier than thou attitude towards people who use AI assisted coding.
- mumblingdrunk 3y ago
  I never got the impression that the developers had an attitude. The discussion I've seen has been mostly people making demands or saying Helix will fail if it doesn't support AI tool integration right now, but none of the devs are interested in using that kind of tooling with Helix, so they don't implement it. When they have poked fun at someone, it has been because that someone is very quick to demand the feature, but unwilling to submit a PR. There is an open PR for getting copilot support, though it's currently just a hotfix and likely won't be accepted into core. You can still patch your own version and compile it.
  - vulcan01 3y ago
    My understanding is that the devs think that AI-assistance should be plugins, as there's no open spec for communication with Copilot and others: https://github.com/helix-editor/helix/discussions/4037#discussioncomment-3766265 https://github.com/helix-editor/helix/discussions/4037#discu... And the plugin system is not done/released yet.
rewgs 3y ago
I arrived at modal editors via Helix. I had bounced off (neo)vim multiple times, primarily due to the verb-object editing scheme, and initially found Helix to be a godsend. That said, I had an editing paradigm too opinionated even for Helix, so I mangled my Helix config into what I thought at the time was my dream editor. Over time, though, I started to "see the light" of Vim's ways. I'd run into this or that use-case, realize that I had mapped the key for it to something that fit my custom paradigm ideas, and one by one, switched back to the defaults. Eventually, my Helix config became more Vim-y. So I switched to Neovim and didn't look back. I got really into the plugins and customization, and while yes, I still do have a good bit of plugins and a somewhat large config, it's become more and more stock with time. It took me a long time to get it, but the Vim model really is truly brilliant. I still appreciate Helix (and by extension, Kakoune), and I'm happy I went through the weird twisty road that I did, but ultimately I found that the ways in which those two differ from Vim were indicative of me "clinging" to old editing habits from more "standard" editors. It took truly diving in and accepting that maybe, just maybe, I didn't have better ideas than a 50-year old editor that's stood the test of time, to see it.
- anhner 3y ago
  Thank you for writing this. The last sentence really got me thinking.
reil_convnet 3y ago
I have been using Helix editor for last three months {was a sublime user earlier} and am really liking it. Its LSP is faster than Sublime, needs minimal setup and very similar to vim. I knew Vim from my engineering days but the configuration part of Vim kept me away from using it and thus using sublime. Helix solved that specific problem.
jhoechtl 3y ago
Where is Emacs? Version 29 will be an absolutely great release!
- wartijn_ 3y ago
  The author did mention emacs in the previous article where he talked about editors. > The reason I didn’t stick around Emacs was basically because of its runtime choice, and ultimately, its Lisp ecosystem. The Emacs community is one of the best I have been talking to, and they have really, really talented people working on insanely complex topics, like turning Elisp code into native code (via C), including Emacs itself. But even with all those optimizations, the editor was still feeling too slow, and has a lot of background that you can feel. All the abstraction layers, all the Lisp macros (oh no), etc. https://phaazon.net/blog/editors-in-2022 https://phaazon.net/blog/editors-in-2022
- Brentward 3y ago
  It already is! I've been building Emacs from the development branch for the last couple of years, and the improvements in 29 and now 30 have really been great. I barely remember the sluggishness the other comment mentions.
anthk 3y ago
On vis, there's a noticeable lag on pressing "ESC" on older systems.
- JdeBP 3y ago
  This is a problem common to all TUI programs that rely on the POSIX terminal paradigm.
  - anthk 3y ago
    But nvi (nvi2) it's fast.
dansalvato 3y ago
I gave Helix a shot, and I immediately ran into a wall due to an undocumented limitation where in a language configuration, indentation can only be up to 8 spaces. (I'm working on an Assembly project with an indentation of 12 spaces to make more room for labels.) I checked the source code to figure out what the heck was going on, and I found this: https://github.com/helix-editor/helix/blob/207829eefee51095d1c7b424cf11cab694fbf52b/helix-core/src/indent.rs#L39-L59 https://github.com/helix-editor/helix/blob/207829eefee51095d... Pretty often, my projects have weirdly specific needs like this. I think (Neo)Vim's greatest strength is that it always absolutely has some way of covering a weirdly specific need, whether a one-off command or a project configuration. But that seems to be against Helix's philosophy. If Helix can't be the editor, then I can't justify taking the time to learn it. It makes me sad, though, because I really like what it's going for.
- Sirenos 3y ago
  That looks very hacky. Is there a reason for this limitation that you've found makes sense?
  - otikik 3y ago
    It seems relatively easy to send a PR to allow supporting any number of spaces (or at least increase the upper limit to 16).
    - messe 3y ago
      > allow supporting any number of spaces As long as nothing is depending on 'static lifetime further down the line. (EDIT: ignore and see below) > (or at least increase the upper limit to 16) That should be doable for sure. Even something like (I'm not a rust developer, just have a passing familiarity, so my syntax may be off): IndentStyle::Spaces(n) if 0 < n && n <= 16 => &" "[0..n as usize], I think that would condense it all down into one line, rather than having special cases for all of 1 through 16. EDIT: after toying around in the rust playground, I think the following will support any indent level (within the bounds of the u8 type). At the top level: static INDENTS: [u8: 256] = [' '; 256]; And then in the as_str function: IndentStyle::Spaces(n) => std::str::from_utf8(&INDENTS[0..n as usize]).unwrap()
trabant00 3y ago
One thing I never see people talk about in these comparisons is file type support. Vim has everything from hosts file to apache, nginx, sudoers, etc, etc. And for general purpose languages it is still better than things like tree-sitter. Certainly the latter has more features but it is less reliable and consistent. After almost 20 years of vim I switched to doom emacs for development. But for sysadmin tasks I still use vim. And sometimes I miss its consistency even for GPLs.
hawski 3y ago
I like Helix, but I found it very laggy through ssh, where vim is quick enough.
gigatexal 3y ago
man all these new editors trying to fix problems with the old and I am just trying to master neovim (and for that matter just vim as I haven't even gotten to the benefits of neovim other than the LSP stuff). at this point I am so productive in vim/neovim that I more-or-less just glance and pass on announcements of new editors. For me to switch to anything at this point other than neovim would be for it as a project to go away.
perrygeo 3y ago
I really enjoy Helix. The toml configuration and built-in Treesitter and LSP support are stellar. It works well enough to be a daily driver. But after 20 years of Vim muscle memory, I can't deal with the keybindings. Not that they're inherently worse, just different - I'm perfectly happy with vim motions and relearning to type is pretty low on my list of priorities. Luckily there is a compatibility hack, not perfect but it's close enough: https://github.com/LGUG2Z/helix-vim https://github.com/LGUG2Z/helix-vim
asdajksah2123 3y ago
This writeup definitely makes me want to try Helix. But I am worried that it won't suit my needs because of 1 of the 2 issues I have faced with all non VIM/Emacs editors I have tried. It's largely focused on programming and won't be as smooth a writing and editing experience in non programming use cases. That seems to be the case for almost every editor I've tried.
PointyFluff 3y ago
[dead]
asylteltine 3y ago
[dead]

163 points by cosmojg 3y ago

akho 3y ago

Weird how different people can be. The only thing I found compelling in the “great features” list is snappiness. Otherwise, - subject-verb isn’t a universal improvement; Vim provides both through visual mode with an extra keypress, kak/helix only make one easy; - git integration looks sub-par for anyone familiar with magit / fugitive; - the level of discoverability is at “much worse than Emacs, but proud of the achievement”; - system integration is on a table stakes level. The extensibility / composability topic is close to my heart, but the particular take does not sound right. Emacs, for one, is not extensible like vs code is extensible, it’s runtime modifiable via insane levels of “internal” composability that is not achieved by other tools. It also works well with outside tools. I don't see what prevents the author from running magit separately; you can absolutely eval a magit-status from your command line. You'll lose editor integration, but that seems to be the point of the exercise? In this particular case, the whole philosophical comparison reads like an excuse for Helix’s limitations. TOML config would just make me angry on a daily basis. It’s okay to like simple simple things. Just don’t compare them with Emacs — it's an entirely different kind of thing. Apples, oranges, kitchen sinks.

cosmojg 3y ago

The author, Dimitri Sabadie (@phaazon[1]), is a prominent Kakoune contributor[2]. In this article, he offers his thoughts on Helix[3], how it compares and contrasts with Kakoune, and how both Helix and Kakoune improve on the tried-and-true Vi-inspired formula which continues to drive the popularity of keyboard-centric editors like Vim and Neovim. [1] https://github.com/phaazon https://github.com/phaazon [2] https://github.com/phaazon/kak-tree-sitter https://github.com/phaazon/kak-tree-sitter [3] https://helix-editor.com/ https://helix-editor.com/

softirq 3y ago

All I care about when it comes to editors is availability (on every platform, can be used in a terminal), longevity, and the community for third party plugins. Vim still checks all of those boxes and the only real other contender is still Emacs. Vim is super crusty, Kakoune and helix have better takes on the unix philosophy, integrations. VSCode is easier for absolute beginners to click around in. IntelliJ has better semantic parsing. But none of that matters. None of that holds me back from being successful. I just need an editor I can type code in that I will never have to give up, that will just be there, and I can use at the next job. In fact Vim's quick editing is just a nice to have, it's never been the difference between me killing it and getting killed at work. That's why I'm sticking with Vim.

eviks 3y ago
Why do you care so much about availability of an app that is unusable without a lot of plugins? At which point, you can copy plugin code with the editor app to a place you need it available in
- bee_rider 3y ago
  “Unusable without any plugins” is quite a description to throw in there as an assumption.
  - bourneavent 3y ago
    It's barely useable. I rely a lot on code completion, search capabilities and syntax checking while I code. It just saves a lot of time from having to execute the compiler and wait for it to check everything. With good "plugins" or "features" all of these things happen async.
    - offices 3y ago
      Like Godwin's Law, every discussion of Vim on HN will inevitably tend towards complaining that it doesn't have features that it has shipped with 10-30 years.
      - bourneavent 3y ago
        It doesn't have code completion. You can install it as a feature, but vim itself doesn't have that feature. There needs to be a law for someone either flat out lying or not knowing what they're talking about because godwin's law doesn't apply here. Additionally installing these features on vim is a nightmare for various reasons. It can be done, and I've done it, but the experience is not as good as the more clunkier GUI IDEs. I'm all for a TUI IDE if the experience was as automated or seamless as jetbrains or M$, but such a app doesn't exist yet.
        3y ago

dang 3y ago

Related ongoing thread: Why Kakoune – The quest for a better code editor (2016) - https://news.ycombinator.com/item?id=36424256 https://news.ycombinator.com/item?id=36424256 - June 2023 (56 comments)

kemiller 3y ago

I really want to like helix. I do like helix. The batteries included ethos is awesome. Multi-select is tantalizingly close to something really interesting. Buts its macro/keybinding vocabulary isn’t quiiiiite there yet. And tbh I’m not sold on multi-selection as the only paradigm.

knodi123 3y ago
> something really inter ?
- kemiller 3y ago
  esting.
  - knodi123 3y ago
    Thank y

lll-o-lll 3y ago

Argh! I’ve been finally getting around to learning vi (vim), and now you are telling me that is so last century, I need Kakoune? At least Vim “mode” seems to be supported everywhere. Surely I get more bang for “time investment” than these others?

rgoulter 3y ago
vi is ubiquitous, so it's still a useful thing to have learned. Especially for fresh linux installs, or in default VM environments, it's useful to be able to use vi. Though, IME the cost of learning something like kakoune or helix's motion (having already learned vi) is quite low. -- The value-add of vi's modal editing doesn't go away just because something even nicer comes along; it does mean you get the chance to use something even nicer.

bccdee 3y ago

I really don't like Kakoune's model of extensibility. It's one of the reasons I switched back to Vim after using Kakoune as my main editor for several months. The configuration system is esoteric, fiddly, and (as of 4 years ago or so, when I last used it) not thoroughly documented. I think Helix made a good choice by building in LSP support and other things that would otherwise require extensions, and by having a "you don't really need it" policy for things like panes, which you can just do with tmux. And I think Neovim made a good choice by exporting a configuration/extension API in a very standard, commonplace extension language like Lua. I disagree that Neovim's Lua API is really a different language. It's just an API; Kakoune has one too, albeit of a more esoteric sort. Incidentally, I started using Helix a month or two ago and I've been liking it a lot. Having the language server stuff already integrated is a fantastic convenience. I could probably switch to using hx exclusively if I really wanted, even with no extension system whatsoever. The only thing I want that they haven't implemented yet is easymotion jumps, and there's an MR for that already [0]. [0]: https://github.com/helix-editor/helix/pull/3791 https://github.com/helix-editor/helix/pull/3791

chrismorgan 3y ago
Wait, no panes? What about things like diffing two files? There are also plenty of other situations too where I’ve definitely wanted splits in the same client, so I can see multiple files at once but also copy between them (which requires shared registers), write macros that switch between the panes (which… well, I suppose Kakoune’s composability approach might be able to support such a concept, but I get the impression Helix really wouldn’t), &c. Wow, https://github.com/helix-editor/helix/issues/405 https://github.com/helix-editor/helix/issues/405, indeed no side-by-side diffing and the approach being suggested would be hopelessly crippled for even two-way diff (let alone three- or four-way diff, which are probably just total non-starters), since it would only support editing one of the documents! Seriously, my mind is boggling at considering a “you don’t really need it” policy for at least splits. I really do need it: even on my base task load, tmux would be inadequate in painful ways multiple times per month; and I regularly (sometimes daily for weeks, though other times not for months on end) do things for which it would be completely debilitating so that I couldn’t possibly use Helix and would have to go back to Vim.

eviks 3y ago

> However, if you type w, the cursor will move to the end of the word while the anchor will move to its beginning, visually selecting the word Would be cool, but all it does is move the cursor to the end, anchor remains in the middle of the word (if you start from the middle)

lwhsiao 3y ago
You're right. One way to select a word from the middle in helix is `miw`.
- n8henrie 3y ago
  Yes, I'm using `miwc` a lot (used to `ciw` in nvim)
yonatan8070 3y ago
You can use `bw` or `be` to do that
taeric 3y ago
I'm amused, as I immediately think, "er/expand-region" covers this like a champ. Complete with C-g leaving the cursor where you started, if you change your mind.

celeritascelery 3y ago

I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools. You can't take magit to vim or helix, because it is an Emacs extension. And each tool has it's own way of extending it, which means you need to learn essentially a new API (if not an entire language) to extend a tool. However extensibility makes it much easier to move within a tool. The authors sample kakoune config for doing splits is a great example. Since Kak doesn't support splits natively, you have to learn 3 separate tools do the spliting in a WM. In something like Emacs there is only one thing to learn to manage splits on all platforms. And it is using the same extension mechanisms you use for everything else. I found this the paragraph just before the conclusion to be an interesting demonstration of these trade-offs: > All of that to say that, the take of Helix is pretty good here, because all of those UNIX problems are not there in that editor: everything runs in the same process, inside the same memory region. The author spends a lot of time praising composability over extensibility, but then admits that Helix has some real advantages because it is not composed with tree-sitter or lsp, it has those built in. Essentially it was extended with those features, they become part of editor, instead of trying to interact with them in a uniform way. This reminded me of the xi-retrospective section[1] on modular software. composability works better on the small scale, but struggles when you have many independent things interacting with each other. It is fine for simple things like "using the shell to sort lines" or "bring your own fuzzy finder", but with more complicated integration it starts to falter. [1]https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...

taeric 3y ago
I found https://yarchive.net/comp/linux/everything_is_file.html https://yarchive.net/comp/linux/everything_is_file.html a very compelling read today, on similar topics. Specifically, having a base set of abstractions that everything "speaks" is a huge boon that is often hard to articulate. Annoying, as the drawbacks and sheer number of edges is often much more easily described. TO that end, Emacs' "everything is open to everything else" works surprisingly well, once you get used to it. Especially so if you go with not introducing new primitives to makes things happen in the process. Even "async" is relatively easy once you get used to the sentinel approach. Can you imagine a better way? Almost certainly. I have yet to see one survive the test of so many contributors, though.

eviks 3y ago

The text editing examples are great illustrations of the power of the editor, but hard to follow in this static format that doesn't show transition from one state to another, so a little pic going back&worth might be better; also the cursor should be highlighted more instead of being just hardly visible gray

rizky05 3y ago

I want terminal editor that does not need me remembering keyboard shortcuts to edit things. Mouse should be optional, and editing without mouse should be the default. But every editing operation should be easy to access and sensible - You don't have to read any docs to navigate/edit/search/replace. When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary. You can say, I want VSCode that runs in terminal, but one that does not hog my cpu/memory. It should feels instant to do anything, without any loading time if possible.

DiggyJohnson 3y ago
Nano supports mouse, right?
u801e 3y ago
> I want terminal editor that does not need me remembering keyboard shortcuts to edit things. Keyboard shortcuts are essential to increase efficiency and speed. For example, ctrl-c, ctrl-v, ctrl-z, ctrl-s, ctrl-p, ctrl-a etc. People learn these early on if they regularly have to input/edit text to speed up their workflow. Otherwise, they would have to resort to pointing and clicking through menus to accomplish the same thing. The longer you use an editor, the more of these shortcuts you commit to (muscle) memory, so, even if the commonly used editing operation is easily accessable via the GUI interface, people are going to choose the keyboard shortcut to do the same thing since it's faster. > When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary. You could navigate with the mouse or arrow keys in either vim or emacs. The only thing you would have to learn is how to save the file. You may not even have to learn that because both vim and emacs display a dialog box asking you whether or not you want to save the file if you try to exit the editor without saving first.
taeric 3y ago
Tutorial "optional" is just weasel words for "works like things I already know." Problem is, especially in expert tooling, that everyone seems to know something else.
friend_and_foe 3y ago

qolop 3y ago

I really want to use helix but was turned off by the lack of Copilot support and the developers' contempt and holier than thou attitude towards people who use AI assisted coding.

mumblingdrunk 3y ago
I never got the impression that the developers had an attitude. The discussion I've seen has been mostly people making demands or saying Helix will fail if it doesn't support AI tool integration right now, but none of the devs are interested in using that kind of tooling with Helix, so they don't implement it. When they have poked fun at someone, it has been because that someone is very quick to demand the feature, but unwilling to submit a PR. There is an open PR for getting copilot support, though it's currently just a hotfix and likely won't be accepted into core. You can still patch your own version and compile it.
- vulcan01 3y ago
  My understanding is that the devs think that AI-assistance should be plugins, as there's no open spec for communication with Copilot and others: https://github.com/helix-editor/helix/discussions/4037#discussioncomment-3766265 https://github.com/helix-editor/helix/discussions/4037#discu... And the plugin system is not done/released yet.

rewgs 3y ago

I arrived at modal editors via Helix. I had bounced off (neo)vim multiple times, primarily due to the verb-object editing scheme, and initially found Helix to be a godsend. That said, I had an editing paradigm too opinionated even for Helix, so I mangled my Helix config into what I thought at the time was my dream editor. Over time, though, I started to "see the light" of Vim's ways. I'd run into this or that use-case, realize that I had mapped the key for it to something that fit my custom paradigm ideas, and one by one, switched back to the defaults. Eventually, my Helix config became more Vim-y. So I switched to Neovim and didn't look back. I got really into the plugins and customization, and while yes, I still do have a good bit of plugins and a somewhat large config, it's become more and more stock with time. It took me a long time to get it, but the Vim model really is truly brilliant. I still appreciate Helix (and by extension, Kakoune), and I'm happy I went through the weird twisty road that I did, but ultimately I found that the ways in which those two differ from Vim were indicative of me "clinging" to old editing habits from more "standard" editors. It took truly diving in and accepting that maybe, just maybe, I didn't have better ideas than a 50-year old editor that's stood the test of time, to see it.

anhner 3y ago
Thank you for writing this. The last sentence really got me thinking.

reil_convnet 3y ago

I have been using Helix editor for last three months {was a sublime user earlier} and am really liking it. Its LSP is faster than Sublime, needs minimal setup and very similar to vim. I knew Vim from my engineering days but the configuration part of Vim kept me away from using it and thus using sublime. Helix solved that specific problem.

jhoechtl 3y ago

Where is Emacs? Version 29 will be an absolutely great release!

wartijn_ 3y ago
The author did mention emacs in the previous article where he talked about editors. > The reason I didn’t stick around Emacs was basically because of its runtime choice, and ultimately, its Lisp ecosystem. The Emacs community is one of the best I have been talking to, and they have really, really talented people working on insanely complex topics, like turning Elisp code into native code (via C), including Emacs itself. But even with all those optimizations, the editor was still feeling too slow, and has a lot of background that you can feel. All the abstraction layers, all the Lisp macros (oh no), etc. https://phaazon.net/blog/editors-in-2022 https://phaazon.net/blog/editors-in-2022
Brentward 3y ago
It already is! I've been building Emacs from the development branch for the last couple of years, and the improvements in 29 and now 30 have really been great. I barely remember the sluggishness the other comment mentions.

anthk 3y ago

On vis, there's a noticeable lag on pressing "ESC" on older systems.

JdeBP 3y ago
This is a problem common to all TUI programs that rely on the POSIX terminal paradigm.
- anthk 3y ago
  But nvi (nvi2) it's fast.

dansalvato 3y ago

I gave Helix a shot, and I immediately ran into a wall due to an undocumented limitation where in a language configuration, indentation can only be up to 8 spaces. (I'm working on an Assembly project with an indentation of 12 spaces to make more room for labels.) I checked the source code to figure out what the heck was going on, and I found this: https://github.com/helix-editor/helix/blob/207829eefee51095d1c7b424cf11cab694fbf52b/helix-core/src/indent.rs#L39-L59 https://github.com/helix-editor/helix/blob/207829eefee51095d... Pretty often, my projects have weirdly specific needs like this. I think (Neo)Vim's greatest strength is that it always absolutely has some way of covering a weirdly specific need, whether a one-off command or a project configuration. But that seems to be against Helix's philosophy. If Helix can't be the editor, then I can't justify taking the time to learn it. It makes me sad, though, because I really like what it's going for.

Sirenos 3y ago
That looks very hacky. Is there a reason for this limitation that you've found makes sense?
- otikik 3y ago
  It seems relatively easy to send a PR to allow supporting any number of spaces (or at least increase the upper limit to 16).
  - messe 3y ago
    > allow supporting any number of spaces As long as nothing is depending on 'static lifetime further down the line. (EDIT: ignore and see below) > (or at least increase the upper limit to 16) That should be doable for sure. Even something like (I'm not a rust developer, just have a passing familiarity, so my syntax may be off): IndentStyle::Spaces(n) if 0 < n && n <= 16 => &" "[0..n as usize], I think that would condense it all down into one line, rather than having special cases for all of 1 through 16. EDIT: after toying around in the rust playground, I think the following will support any indent level (within the bounds of the u8 type). At the top level: static INDENTS: [u8: 256] = [' '; 256]; And then in the as_str function: IndentStyle::Spaces(n) => std::str::from_utf8(&INDENTS[0..n as usize]).unwrap()

trabant00 3y ago

One thing I never see people talk about in these comparisons is file type support. Vim has everything from hosts file to apache, nginx, sudoers, etc, etc. And for general purpose languages it is still better than things like tree-sitter. Certainly the latter has more features but it is less reliable and consistent. After almost 20 years of vim I switched to doom emacs for development. But for sysadmin tasks I still use vim. And sometimes I miss its consistency even for GPLs.

hawski 3y ago

I like Helix, but I found it very laggy through ssh, where vim is quick enough.

gigatexal 3y ago

man all these new editors trying to fix problems with the old and I am just trying to master neovim (and for that matter just vim as I haven't even gotten to the benefits of neovim other than the LSP stuff). at this point I am so productive in vim/neovim that I more-or-less just glance and pass on announcements of new editors. For me to switch to anything at this point other than neovim would be for it as a project to go away.

perrygeo 3y ago

I really enjoy Helix. The toml configuration and built-in Treesitter and LSP support are stellar. It works well enough to be a daily driver. But after 20 years of Vim muscle memory, I can't deal with the keybindings. Not that they're inherently worse, just different - I'm perfectly happy with vim motions and relearning to type is pretty low on my list of priorities. Luckily there is a compatibility hack, not perfect but it's close enough: https://github.com/LGUG2Z/helix-vim https://github.com/LGUG2Z/helix-vim

asdajksah2123 3y ago

This writeup definitely makes me want to try Helix. But I am worried that it won't suit my needs because of 1 of the 2 issues I have faced with all non VIM/Emacs editors I have tried. It's largely focused on programming and won't be as smooth a writing and editing experience in non programming use cases. That seems to be the case for almost every editor I've tried.

PointyFluff 3y ago

[dead]

asylteltine 3y ago

[dead]