9 ms·

I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. Helix is built from the ground up around Tree-Sitter and LSP. This mea

by p-e-w 4y ago

I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. Helix is built from the ground up around Tree-Sitter and LSP. This means you get the best syntax highlighting available, and IDE-like functionality, with zero configuration required other than installing the appropriate language server. Those are by far the most important features for a text editor to have, and crucially, they are fully integrated into Helix, but are an afterthought in (Neo)vim and Kakoune. The quality difference is obvious the moment you try it side by side. Nothing else really matters. Vim's and Kakoune's syntax highlighting is terrible, and while Neovim can now use Tree-Sitter as well, there always seem to be some additional hoops the user needs to jump through in order to get it to work. Not so with Helix. Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts, but all other Vim derivatives share this flaw as well so I don't see that stopping Helix from steamrolling the competition once it matures and the word spreads.

elromulous 4y ago
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. I hope this doesn't come off as flippant: I thought your comment was sarcastic at first. While I love seeing newer / better software displacing the old and crusty, this seems a little unlikely, no? It seems like somewhat of a miracle that neovim has taken as much share as it has. P.s. I'm hoping to eat my words one day.
- p-e-w 4y ago
  > It seems like somewhat of a miracle that neovim has taken as much share as it has. It's not a miracle but rather a testament to how much Neovim improves upon Vim. The number of useful features, among them Tree-Sitter and LSP, that Neovim has introduced has ended what feels like decades of stagnation in Vim development. Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. That's essentially what Helix is. The Vim -> Neovim improvement is nothing compared to what Helix will deliver (and already is delivering in many aspects).
  - pg999w 4y ago
    > Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. User inertia is strong. Neovim has its success because of its improvement, but more importantly, the keymap and config language is based on Vim7. Vim7 users can painlessly switch to Neovim with all config preserved. That's the main reason why Neovim can gain a large number of users initially. Conversely, Helix has no keymap nor configuration compatibility with Vim or other mainstream editors. Given this, I see no hope that Helix will become mainstream.
    - thebeastie 4y ago
      If by keymap you are referring to default key bindings then it’s extremely similar. I’ll definitely be giving it a whirl.
    - polotics 4y ago
      Based on my observation of colleagues' dominant usage of IntelliJ-originated editors, I think that modal-editors users are far enough from the mainstream that some rules dont apply: Heliy may end up dominant in our pocket-universe, based on merit alone.
- bee_rider 4y ago
  IMO it is not that surprising that neovim has had some success, in the same way that it isn't very surprising that SwayWM has had some success. They both have the benefit of, in many cases, being completely compatible with the tool they want to replace. Being almost completely compatible with the old tool, while integrating a popular new technology (LSP or wayland) seems to be the only way to win over users who already have a strong connection to their tools of choice. My vimrc already has a bunch of configuration in it, I'll give Helix a try when it is able to parse that (so, probably never, I guess).
ratorx 4y ago
Do you have any specific examples of things helix does better than neovim? I think the neovim implementation of LSP and treesitter is quite nice. It was not that polished when I tried it last, but I think once it becomes mature, it will be really flexible. Tree sitter specifically is still considered experimental, but I think the timeline for that to be better integrated will be significantly faster than it takes for any new editor to get a decently sized community around it. The zero config part of it is nice, but I think you’d be competing with e.g. VSCode with modal bindings on that note. Vim/Neovim have always had a fairly steep learning curve, and I can’t see that aspect of it mattering as significantly, especially since I only see LSP/Treesitter support improving in neovim.
- rjzzleep 4y ago
  Sometimes treesitter has problems. Indenting has gotten worse and configuration is a lot more complex. I have the same config with some neovim / vim specifics and I find myself using vim more often even though the neovim features are "cooler". I wonder if it will ever become "mature". It doesn't crash for that matter, but you have to keep everything updated constantly. Vim doesn't really have that problem. Helix looks cool too, but I was looking for what it has that the others don't have and I can't figure it out. The website just makes it seem like it's cooler than the others.
  - ratorx 4y ago
    Treesitter is still a bit iffy. LSP is a bit better, but is still not amazingly mature (but some of this is to do with the LSP servers themselves not being that mature). Other than that, I haven’t had any problems with Neovim. Everything else has been rock solid, and I haven’t needed to update frequently for anything else. Have you experienced other issues? However, these are the larger “killer” features of neovim, so at this point there’s not that much over Vim. However, there aren’t any Vim features I use that are missing in Neovim either. There are a couple of minor things that push Neovim over though (`inccommand`, Lua is marginally nicer, Neovim plugin scene has exploded recently). So since Neovim (for me) has feature parity and equal reliability, with some really nice added frills and some moderately reliable, but maybe not incredibly mature, killer features it still beats Vim in my book.
luispauloml 4y ago
>Those are by far the most important features for a text editor to have I'd say that those features are useful for source code editing, not text in general.
- Version467 4y ago
  I'd say that has been true in the past (and is still mostly true today), but I think this will change in the future. I have been using lsp+treesitter for markdown editing and it's been an excellent experience. It's still early days, but with treesitter and lsp being as universal as they are I've been seeing a lot of people just experimenting with what's possible. So yes, they are essential only for source code editing, but it's quite exciting to see what they can do for general text editing.
  - nine_k 4y ago
    I'm looking forward to seeing Org Mode implemented as a language server. It's unfortunate that such a great general text organization tool is locked into the relatively small Emacs user community.
    - medo-bear 4y ago
      orgmode is so not a markup language and cant be served via lsp. its a whole ecosystem built on top of emacs. short of rewriting it, implementing it fully in another editor would require a sort of virtual emacs machine running in the background
      - nine_k 4y ago
        Typescript or Rust are also not markup languages, and language servers for them allow for many interesting, non-trivial operations, so the model is capable. Ergonomic keybindings would be a challenge though.
        medo-bear 4y ago
senko 4y ago
> Helix is built from the ground up around Tree-Sitter and LSP. Sadly, that achievement is compromised by having to call into unsafe code.
- tmdh 4y ago
  Unsafe code is not bad code.
- atoav 4y ago
  Have you checked what that unsafe code does? Unsafe code is not bad per se, there has been quite a bit of discussion about the naming of unsafe and many are of the opinion that it should have better been called something like trustme to clarify that the code must not be necessarily unsafe, just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary. As long as the content of those blocks has been carefully checked there is no problem with using unsafe.
  - funklute 4y ago
    > just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary Why is that? Does this imply that there are certain algorithms you simply can't write (efficiently) when using the borrow-checker? (I don't know Rust btw, but have plans to start learning very soon)
    - sushibowl 4y ago
      Missing some nuance, but that description is not too far off. The ownership/borrowing concept is based on the idea that every piece of data has a single owner. Particularly in cyclical data structures, it's not very clear who should have final ownership over what. This can make graph-like data structures somewhat difficult to express.
  - p-e-w 4y ago
    > just that the borrow checker doesn't fully check here That's incorrect. The borrow checker performs the same checks inside `unsafe` blocks as everywhere else. `unsafe` blocks can perhaps best be summarized as areas of code where memory safety rules are relaxed. The borrow checker deals with ownership, and ownership rules are still fully enforced inside `unsafe` constructs.
isatty 4y ago
> Those are by far the most important features for a text editor to have The most important feature of a text editor is that it can edit text well. Vim is popular because it’s the best _text editor_ not because it has a bunch of plugins making it an IDE.
- discreteevent 4y ago
  > the best _text editor_ Code is text. So it is good to have a very good text editor for manipulating it as text. But code is also very different from plain text. It is highly structured. When I think about code I think about it as some kind of syntax tree (call hierarchies etc) . I don't think about it as character buffers. So if I am programming and I can have something that supports good text editing but also good tree editing then I will take that over something that only does good text editing.
  - Myrmornis 4y ago
    I agree with this. I have never been a vim/neovim/helix user, so there's little I can contribute here. But I have always used paredit commands as much as possible, in all languages, not just lisps, and that's still true now that I've switched to vscode from emacs. I'm curious whether any vim/helix editing operations are "tree-based" in a similar way to paredit, and also whether anyone's building a paredit-like editing system based on treesitter.
dmortin 4y ago
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. Is there anything preventing other editors from integrating LSP and making it work out of the box without any configuration other than adding a language server?
- p-e-w 4y ago
  What's preventing it is their existing codebases, mostly. IIRC, one of the first things Neovim did was throw out literally tens of thousands of lines of legacy code from Vim. Meanwhile, Helix can just add the `lsp-types` crate as a dependency and they're already a quarter of the way to making LSP work. The difference between adding something to a 30-year-old C project and a new Rust project is so massive that it can actually be the difference between "fairly straightforward" and "essentially impossible".
  - sullyj3 4y ago
    Right, but Neovim does in fact have LSP support. That part is done, that's not a blocker for the It Just Works experience. It's that the editor currently doesn't come with the relevant configuration (in vimscript or lua).
  - chipotle_coyote 4y ago
    While the Mac-only editor BBEdit isn’t open source, it is a 30-year-old C++/Objective-C project, and BBEdit 14 added LSP support which is largely exactly what the comment you’re replying to suggested: install a language server somewhere on your path and BBEdit will find it and use it. It’s preconfigured for a couple dozen popular ones, and adding ones it doesn’t know about out of the box is usually just as as easy as filling in a couple fields in a dialog box. I agree with you in principle, but in practice I’m not convinced this is an insurmountable hurdle for other editors.
usrnm 4y ago
> Helix is built from the ground up around Tree-Sitter and LSP And what happens in ten or twenty years, when both are obsolete? I don't really care, what technologies my text editor is built on top of, but I sure would like to be able to still use it for writing my memoirs when I'm old.
- p-e-w 4y ago
  LSP will not become obsolete, it will evolve. The entire industry is rallying around LSP, and Microsoft is constantly improving the protocol. In "ten or twenty years" LSP will have become a required feature for every programming language and every text editor. It will be essentially impossible to replace it with any other technology because of the massive investment already made in the ecosystem. I can imagine Tree-Sitter slowly losing importance because LSP is integrating semantic highlighting, but Tree-Sitter will still be an easy option for writing grammars in the absence of a full-featured language server.
  - deleted 4y ago
    [deleted]
  - _k9eq 4y ago
    I can easily imagine a comment like this being written 30 years ago where "LSP" was replaced by "tags files".
    - deleted 4y ago
      [deleted]
    - bee_rider 4y ago
      I mean you still wouldn't use an editor without ctags support, right? That's just a bad smell.
  - b3morales 4y ago
    Unless the protocol changes to specifically address this, I find it unlikely that LSP will ever be a full solution for real-time syntax highlighting. The amount of JSON that has to be slung interprocess on each edit is just too much. Providing extra semantic highlighting on top of a built in option, absolutely, but I don't think it can replace an in-process, specifically incremental option like Tree-sitter or Sublime/TextMate language defs (or a completely custom solution like JetBrains, Nova, etc.).
BaculumMeumEst 4y ago
I think you're overestimating the likelihood that Tree-sitter is going to gain enough traction to be reliable for general purpose text editing. It's great for popular modern languages, but not for everything, and there's no fallback in Helix. I'm not convinced that's ever going to change.
- p-e-w 4y ago
  Reliable? I trust Tree-Sitter's grammars a hundred times more than the underspecified regex monstrosities that power highlighting in other editors. Tree-Sitter grammars are unit tested, have usable primitives for precedence and associativity, and are generally far more predictable than previous highlighting systems. Also, name a language for which there is no Tree-Sitter grammar yet. The only remaining ones are so obscure that the missing "fallback" is irrelevant for 99% of users.
  - BaculumMeumEst 4y ago
    Python, Janet, Haskell, and Hare were the filetypes I remember either being unsupported or not working well. I need to be able to depend on basic language support from my text editor, even when I work with niche languages.
    - WhyNotHugo 4y ago
      I've been using Python with tree-sitter on neovim for many months. It's great, and has a lot of improvements when compared with the old syntax system. Re Hare: I haven't even set that one up. Setting up a new tree-sitter on neovim requires extra work for each tree-sitter, and that's definitely a flaw that needs to be addressed.
  - albertoCaroM 4y ago
    Is there Asciidoctor tree-sitter grammar? I can't find one.
skavi 4y ago
I like Helix, but it feels slow compared to Neovim. As in the actual scrolling performance. No one else has mentioned this, so I wonder if that’s an issue on my machine.
- sph 4y ago
  Might it be your terminal that too slow to render? You might want to try one of the many GPU accelerated terminals like Kitty, alacritty, wezterm, etc
  - skavi 4y ago
    I use alacritty. And I use Neovim on the same terminal.
Accacin 4y ago
I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch, well they might go to Helix but there's a lot of vim resources out there, so I'm not sure all of them will go to Helix. Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
- least 4y ago
  > I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. I would think that helix probably is better because I'm certain that the verb->text object paradigm in vim could be much better. It may in fact make more sense to do the 'text object' first like it seems to do in both helix and kakoune. But is it better enough for me to switch off something that I've used for years now? Only if it sees mass adoption and you see many developers adopting it. Like if you see it in VS Code as an option to use helix bindings, then it is probably safe to consider adopting it. > Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue. I've been pleasantly surprised with how much better LSP setup in neovim has gotten, as I've transitioned over to the native LSP from CoC, which is also excellent. It's still not pain-free to setup, but it's much easier than it was and I suspect you're right that it'll continue to get easier... though I doubt it'll get anywhere close to how easy VS Code is to use any time soon.
  - HowardStark 4y ago
    While I was going through the effort to set up DAP support, I discovered [mason.nvim](https://github.com/williamboman/mason.nvim https://github.com/williamboman/mason.nvim) which has been a game-changer for LSP, DAP, and linter setups. There had previously been fragmented plugins (williamboman/nvim-lsp-installer was Mason's predecessor and is a good example) that solved the problem of installation and management for each of these. With Mason, I feel that the story for managing different language environments has jumped to be extremely close to VSCode's extensions.
jeksn 4y ago
Can someone elaborate on why Vim doesn’t work well on non-english keyboards. I use Vim occasionally using a Nordic layout but would like to know why English is superior.
- luplex 4y ago
  All the hotkeys are more accessible on English. Things like / are just one keystroke instead of two, and so on.
- unsafecast 4y ago
  It's really not, so long as you map hjkl to the appropriate key sequence on your keyboard. Everything else is based on mnemonics, not locations, so I is just I. Maybe some stuff might be quicker because it's on the first layer, but if it's so bad you can map those specific keys.
- mnsc 4y ago
  I'm a nordic-layout user as well and whenever I look at the actual differences side-by-side I get reminded about how much easier it would be to code if I had all those symbols that close. https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Different-National-Layouts/#sv https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Diff... And for me I'm pretty sure that this "remap everything and translate every tutorial" barrier is why I never have been able to get into vim.
  - gunnihinn 4y ago
    I grew up with the Icelandic layout. When I started programming professionally I taught myself the en-us layout and stared using that instead. It is much easier on my hands and fingers; it really does show that the people who came up with the syntax for most of the programming languages in use picked things that were easy to type on a US layout and didn't give any thought to the rest of us.
    - least 4y ago
      I do not think there's a particularly feasible way to facilitate every keyboard layout out there, so it makes sense that they are at least built with one keyboard layout in mind, much like I think it makes sense that programming in general is overwhelmingly done in English. It increases interoperability significantly.
renox 4y ago
> Those are by far the most important features for a text editor to have The most important feature of an IDE is to be easy to use, having powerful functionalities is important too, but that's goes after.. VSCode has nailed the first point. Wake me up when (neo)vim/kakoune/Helix has a "list of tab view" similar to VSCode..
- drekipus 4y ago
  (neo)vim/kakoune/Helix are not IDEs so you're going to be asleep for a long while yet.
- stackbutterflow 4y ago
  What's a list of tabview?
  - renox 4y ago
    VSCode has a vertical 'subwindow' on the left which list all the opened tabs. I call this 'a tab view/list', I don't know what's the real name. Usually I have between 10 and 20 tab opened, so the tablist is very helpful for navigating between tabs. Unfortunately (AFAIK) the 'fast' editors (vim, kakoune, etc) don't provide such feature. Some have a tree list but not a tab list :-(
    - da_rob 4y ago
      Built something like this a few years ago: https://github.com/roblillack/vim-bufferlist https://github.com/roblillack/vim-bufferlist
      - renox 4y ago
        Thanks a lot, I don't know why I haven't been able to find it..
    - kagevf 4y ago
      In vim, you can list open buffers with :b Edit: sorry, it’s actually :ls
darrenf 4y ago
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. I feel like I am definitely not in the "most users" group here. > syntax highlighting ... IDE-like functionality > Those are by far the most important features for a text editor to have. The most important features for me are the ability to navigate around and manipulate whatever's in the buffer(s) efficiently. I'm a 30 year vi/elvis/vim user and ... I'm not going to be able to use this. The deviations from vim's keybindings are much too widespread and tbh I find improved syntax highlighting and (especially) IDE-like functionality significantly too weak a draw to invest any effort in learning the Helix way - only to context switch between local Helix and remote vi(m) throughout my day anyway. I tried, really I did. Opened up a file I'm actively working on. First thing I needed was `dd` and to my horror it didn't delete a line, but two characters. Turns out vim's `x` is Helix's `d` - except not quite; `5d` doesn't do what `5x` did, in fact the 5 does ... nothing? OK fine, well, I regularly use `V` to highlight groups lines and delete those (or pipe them through my equalprg, or `:'<,'>!`) so I tried that ... nope. Though imagine my surprise when I tried `5x` and it highlighted 5 lines. Why didn't 5 apply to `d` but did to `x`? I tried `:r!<some cmd>` but alas, no `:r` and in fact no `:!`. All these examples are things I do tons of times every day. So I read the "Migrating from vim"[0] document really hoping there was a "activate vim compatibility mode" thing but instead all I saw were the new sequences I'd need to learn, especially ones which require more keypresses such as: go to line first non-blank character: vim: ^ helix: gs go to line end: vim: $ helix: gl delete to line end: vim: D helix: vgld or t<ret>d Investigating more, I found `:insert-output` is the same as `:r!` - tried to map the latter to the former to no avail. I kept finding other things that pissed me off just while I was editing the config file (with helix itself). I want to turn off all the menus which pop up everywhere as soon as I hit `:`. I hated that every time I typed a double quote, it inserted two - I literally never want that, in any language, ever. So many showstoppers for me, which is a shame. Perhaps I could configure the hell out of it - going against what many other folk are proclaiming as sensible, sane defaults - but then I'm back to where I came in. All the effort to make it be like vim except with some syntax stuff I don't really need... no sale. [0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vim https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...
- e12e 4y ago
parentheses 4y ago
The existence of multiple editors of varying ages still in use today shows that tool choice is not a hard and fast X > Y thing. This personal choice is multi faceted and complex. In software engineering, the proliferation of OSS is at the heart of what makes this craft great. Many passionate people create and recreate tools for the same “job”. All this happens with strong pressure towards public, inclusive and open communities around them. The fact that the method and medium require the same general skills means we can think very deeply about tool choice.
WhyNotHugo 4y ago
If find motions in neovim a lot easier to reason about than those in helix. A lot of actions that are pretty easy on neovim are a huge pain on helix. I do appreciate Helix as a research project investing in new ideas, but I do feel it a lot more limited. Everything keyboard/motions related just feels much more limited than Vim. For example, re-doing actions makes little to no sense because most actions tend to be split in two. `3dw` can be redone just fine on neovim, but not on Helix.
e12e 4y ago
> Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation? FWIW I work on a Norwegian layout on a Mac, which is rather horrible for programming and shell use (option-7 for pipe, shift-option-k+space for tilde (!?), shift-option-7 for backslash, shift/option/alt + 8,9 for brackets ...). I do miss "leader" from vim/neovim - and autocompletion from buffer (when there is no language support, like configuration files).
- Liquid_Fire 4y ago
  > How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation? Try it with a non-Latin script language. It's borderline unusable. Nothing works in Normal mode. You have to manually switch back to English any time you switch to Normal mode and back to the other language in Insert/Replace mode, or when typing parameters to things like :s. No other editor requires you to switch language back and forth just to use the editor's commands.
0xbeefeed 4y ago
You’re only saying this because it’s written in Rust, aren’t you?
dahfizz 4y ago
> Those are by far the most important features for a text editor to have To you, maybe. The most important features of an editor for me, and for many people, is that it is stable, dependable, and ubiquitous. There is no way I am going to re-learn years of muscle memory for a "post-modern" editor. Cool and trendy is the exact opposite of what I want in my tools. What happens with the authors get bored and move on to the next shiny thing? Vim is available on ~every machine I could possibly interact with. There is a vim mode in every single mainstream editor / IDE. My Vim muscle memory will keep me productive for the rest of my life. IMO, making something slightly nicer to configure is never going to overcome the inertia of a project like Vim. The new editor would have to be like 3x better to convince everyone to make the switch, not 1.1x better in some specific areas.
- BanazirGalbasi 4y ago
  > Vim is available on ~every machine I could possibly interact with. This is my exact reasoning for sticking with Vim. I use Neovim on my desktop, but I work with servers and have a homelab where I just want the greatest common factor. Nano is also an option, but just like you, my Vim muscle memory is embedded and I end up with :wq everywhere. Is Helix cool? Absolutely. Will it replace [Neo]Vim? Not until it's installed by default everywhere, and that won't happen unless it has a compatibility mode for Vim shortcuts.
- kovac 4y ago
  Exactly. The features OP described are IDE like features that many vim users like myself don't want in my basic text editor. Adding extra features via plugins is not an afterthought but design. He clearly doesn't understand the vim/neovim crowd and the design philosophy. Small correction though, vi is available on every machine, not vim. But indeed this is big reason why I use vim for my own stuff.
BeFlatXIII 4y ago
Even as a Colemak user, the ergonomic benefits of hjkl navigation are utterly lost on me. It’s left me stuck as an arrow keys plebeian.
- TobTobXX 4y ago
  Just remap them?
Test0129 4y ago
I can see Helix replacing Vim and Neovim for the most "normal" user. It's great, and it's a better alternative than VSCode for Vim users that aren't quite power users but also not exactly the most basic user either. However, until I can fire up a new installation of *nix and type `helix` to begin editing things it will never replace good 'ole Vim.
bee_rider 4y ago
I don't see it. If you want IDE features in a text editor, you can use VSCode, it even has vim bindings that are at least trying (with middling success) to match the originals. The addressable market for Helix seems to be (neo)vim users who aren't picky about keybindings and new users who want a terminal editor in 2022. So... on the bright side the developers can probably have one-to-one conversations with all 10 of these people.
deleted 4y ago
[deleted]
alwillis 4y ago
I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. Yeah, that’s not going to happen. It’s cool to have choices, but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there. I’ve been super impressed with the progress of Neovim and the team behind it. It’s only at version 0.8 but they’ve done some amazing things already. I expect Neovim will get to the “batteries included” stage with Treesitter and LSP; it’s not far from there right now. And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Helix sounds like it’s similar to one of these Neovim distributions. Again, Neovim gives you choices: you can configure and tweak it to your heart’s content if you want or you can get something pre-configured with all the goodies installed and configured. Or you can use it headless from a different frontend (VS Code, browser, etc.) if that’s what’s needed. Perhaps the best thing about Neovim is how great it is for both longtime Vim/Vi users and brand new users who are ready to graduate from Notepad and Nano.
- kamaal 4y ago
  >>And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Problem with distributions is as the contributions decrease they start becoming abandonware with time. Leaving you with with vim and having to work through the configuration hell on the long term for yourself. >>Again, Neovim gives you choices: you can configure and tweak it to your heart’s content Trust me this is negative thing, not exactly something most programmers want. Most programmers don't enjoy configuring their IDE/Editors as a full time project together with your regular day job.
  - Corrado 4y ago
    I agree with this. I spend most of my days on newly created systems (AWS EC2 instances) that are bone stock. I don't use any vim plugins at all because they wouldn't be the same everywhere and it's not worth configuring a system I'll only use for 2 hours. If I could get a full featured IDE installed by default on my systems I would ditch vim in a heartbeat.
opan 4y ago
99% of my neovim usage is not programming, and either way I have never found syntax highlighting and similar to be all that important. Text editors need to view and edit text, and do it well. That's about it.
lenkite 4y ago
"Helix is built from the ground up around Tree-Sitter and LSP..Those are by far the most important features for a text editor to have," Well..you just made the argument to stick to Neovim which already does this.

by p-e-w 4y ago

elromulous 4y ago

> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. I hope this doesn't come off as flippant: I thought your comment was sarcastic at first. While I love seeing newer / better software displacing the old and crusty, this seems a little unlikely, no? It seems like somewhat of a miracle that neovim has taken as much share as it has. P.s. I'm hoping to eat my words one day.

p-e-w 4y ago
> It seems like somewhat of a miracle that neovim has taken as much share as it has. It's not a miracle but rather a testament to how much Neovim improves upon Vim. The number of useful features, among them Tree-Sitter and LSP, that Neovim has introduced has ended what feels like decades of stagnation in Vim development. Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. That's essentially what Helix is. The Vim -> Neovim improvement is nothing compared to what Helix will deliver (and already is delivering in many aspects).
- pg999w 4y ago
  > Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. User inertia is strong. Neovim has its success because of its improvement, but more importantly, the keymap and config language is based on Vim7. Vim7 users can painlessly switch to Neovim with all config preserved. That's the main reason why Neovim can gain a large number of users initially. Conversely, Helix has no keymap nor configuration compatibility with Vim or other mainstream editors. Given this, I see no hope that Helix will become mainstream.
  - thebeastie 4y ago
    If by keymap you are referring to default key bindings then it’s extremely similar. I’ll definitely be giving it a whirl.
  - polotics 4y ago
    Based on my observation of colleagues' dominant usage of IntelliJ-originated editors, I think that modal-editors users are far enough from the mainstream that some rules dont apply: Heliy may end up dominant in our pocket-universe, based on merit alone.
bee_rider 4y ago
IMO it is not that surprising that neovim has had some success, in the same way that it isn't very surprising that SwayWM has had some success. They both have the benefit of, in many cases, being completely compatible with the tool they want to replace. Being almost completely compatible with the old tool, while integrating a popular new technology (LSP or wayland) seems to be the only way to win over users who already have a strong connection to their tools of choice. My vimrc already has a bunch of configuration in it, I'll give Helix a try when it is able to parse that (so, probably never, I guess).

ratorx 4y ago

Do you have any specific examples of things helix does better than neovim? I think the neovim implementation of LSP and treesitter is quite nice. It was not that polished when I tried it last, but I think once it becomes mature, it will be really flexible. Tree sitter specifically is still considered experimental, but I think the timeline for that to be better integrated will be significantly faster than it takes for any new editor to get a decently sized community around it. The zero config part of it is nice, but I think you’d be competing with e.g. VSCode with modal bindings on that note. Vim/Neovim have always had a fairly steep learning curve, and I can’t see that aspect of it mattering as significantly, especially since I only see LSP/Treesitter support improving in neovim.

rjzzleep 4y ago
Sometimes treesitter has problems. Indenting has gotten worse and configuration is a lot more complex. I have the same config with some neovim / vim specifics and I find myself using vim more often even though the neovim features are "cooler". I wonder if it will ever become "mature". It doesn't crash for that matter, but you have to keep everything updated constantly. Vim doesn't really have that problem. Helix looks cool too, but I was looking for what it has that the others don't have and I can't figure it out. The website just makes it seem like it's cooler than the others.
- ratorx 4y ago
  Treesitter is still a bit iffy. LSP is a bit better, but is still not amazingly mature (but some of this is to do with the LSP servers themselves not being that mature). Other than that, I haven’t had any problems with Neovim. Everything else has been rock solid, and I haven’t needed to update frequently for anything else. Have you experienced other issues? However, these are the larger “killer” features of neovim, so at this point there’s not that much over Vim. However, there aren’t any Vim features I use that are missing in Neovim either. There are a couple of minor things that push Neovim over though (`inccommand`, Lua is marginally nicer, Neovim plugin scene has exploded recently). So since Neovim (for me) has feature parity and equal reliability, with some really nice added frills and some moderately reliable, but maybe not incredibly mature, killer features it still beats Vim in my book.

luispauloml 4y ago

>Those are by far the most important features for a text editor to have I'd say that those features are useful for source code editing, not text in general.

Version467 4y ago
I'd say that has been true in the past (and is still mostly true today), but I think this will change in the future. I have been using lsp+treesitter for markdown editing and it's been an excellent experience. It's still early days, but with treesitter and lsp being as universal as they are I've been seeing a lot of people just experimenting with what's possible. So yes, they are essential only for source code editing, but it's quite exciting to see what they can do for general text editing.
- nine_k 4y ago
  I'm looking forward to seeing Org Mode implemented as a language server. It's unfortunate that such a great general text organization tool is locked into the relatively small Emacs user community.
  - medo-bear 4y ago
    orgmode is so not a markup language and cant be served via lsp. its a whole ecosystem built on top of emacs. short of rewriting it, implementing it fully in another editor would require a sort of virtual emacs machine running in the background
    - nine_k 4y ago
      Typescript or Rust are also not markup languages, and language servers for them allow for many interesting, non-trivial operations, so the model is capable. Ergonomic keybindings would be a challenge though.
      - medo-bear 4y ago

senko 4y ago

> Helix is built from the ground up around Tree-Sitter and LSP. Sadly, that achievement is compromised by having to call into unsafe code.

tmdh 4y ago
Unsafe code is not bad code.
atoav 4y ago
Have you checked what that unsafe code does? Unsafe code is not bad per se, there has been quite a bit of discussion about the naming of unsafe and many are of the opinion that it should have better been called something like trustme to clarify that the code must not be necessarily unsafe, just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary. As long as the content of those blocks has been carefully checked there is no problem with using unsafe.
- funklute 4y ago
  > just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary Why is that? Does this imply that there are certain algorithms you simply can't write (efficiently) when using the borrow-checker? (I don't know Rust btw, but have plans to start learning very soon)
  - sushibowl 4y ago
    Missing some nuance, but that description is not too far off. The ownership/borrowing concept is based on the idea that every piece of data has a single owner. Particularly in cyclical data structures, it's not very clear who should have final ownership over what. This can make graph-like data structures somewhat difficult to express.
- p-e-w 4y ago
  > just that the borrow checker doesn't fully check here That's incorrect. The borrow checker performs the same checks inside `unsafe` blocks as everywhere else. `unsafe` blocks can perhaps best be summarized as areas of code where memory safety rules are relaxed. The borrow checker deals with ownership, and ownership rules are still fully enforced inside `unsafe` constructs.

isatty 4y ago

> Those are by far the most important features for a text editor to have The most important feature of a text editor is that it can edit text well. Vim is popular because it’s the best _text editor_ not because it has a bunch of plugins making it an IDE.

discreteevent 4y ago
> the best _text editor_ Code is text. So it is good to have a very good text editor for manipulating it as text. But code is also very different from plain text. It is highly structured. When I think about code I think about it as some kind of syntax tree (call hierarchies etc) . I don't think about it as character buffers. So if I am programming and I can have something that supports good text editing but also good tree editing then I will take that over something that only does good text editing.
- Myrmornis 4y ago
  I agree with this. I have never been a vim/neovim/helix user, so there's little I can contribute here. But I have always used paredit commands as much as possible, in all languages, not just lisps, and that's still true now that I've switched to vscode from emacs. I'm curious whether any vim/helix editing operations are "tree-based" in a similar way to paredit, and also whether anyone's building a paredit-like editing system based on treesitter.

dmortin 4y ago

> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. Is there anything preventing other editors from integrating LSP and making it work out of the box without any configuration other than adding a language server?

p-e-w 4y ago
What's preventing it is their existing codebases, mostly. IIRC, one of the first things Neovim did was throw out literally tens of thousands of lines of legacy code from Vim. Meanwhile, Helix can just add the `lsp-types` crate as a dependency and they're already a quarter of the way to making LSP work. The difference between adding something to a 30-year-old C project and a new Rust project is so massive that it can actually be the difference between "fairly straightforward" and "essentially impossible".
- sullyj3 4y ago
  Right, but Neovim does in fact have LSP support. That part is done, that's not a blocker for the It Just Works experience. It's that the editor currently doesn't come with the relevant configuration (in vimscript or lua).
- chipotle_coyote 4y ago
  While the Mac-only editor BBEdit isn’t open source, it is a 30-year-old C++/Objective-C project, and BBEdit 14 added LSP support which is largely exactly what the comment you’re replying to suggested: install a language server somewhere on your path and BBEdit will find it and use it. It’s preconfigured for a couple dozen popular ones, and adding ones it doesn’t know about out of the box is usually just as as easy as filling in a couple fields in a dialog box. I agree with you in principle, but in practice I’m not convinced this is an insurmountable hurdle for other editors.

usrnm 4y ago

> Helix is built from the ground up around Tree-Sitter and LSP And what happens in ten or twenty years, when both are obsolete? I don't really care, what technologies my text editor is built on top of, but I sure would like to be able to still use it for writing my memoirs when I'm old.

p-e-w 4y ago
LSP will not become obsolete, it will evolve. The entire industry is rallying around LSP, and Microsoft is constantly improving the protocol. In "ten or twenty years" LSP will have become a required feature for every programming language and every text editor. It will be essentially impossible to replace it with any other technology because of the massive investment already made in the ecosystem. I can imagine Tree-Sitter slowly losing importance because LSP is integrating semantic highlighting, but Tree-Sitter will still be an easy option for writing grammars in the absence of a full-featured language server.
- deleted 4y ago
  [deleted]
- _k9eq 4y ago
  I can easily imagine a comment like this being written 30 years ago where "LSP" was replaced by "tags files".
  - deleted 4y ago
    [deleted]
  - bee_rider 4y ago
    I mean you still wouldn't use an editor without ctags support, right? That's just a bad smell.
- b3morales 4y ago
  Unless the protocol changes to specifically address this, I find it unlikely that LSP will ever be a full solution for real-time syntax highlighting. The amount of JSON that has to be slung interprocess on each edit is just too much. Providing extra semantic highlighting on top of a built in option, absolutely, but I don't think it can replace an in-process, specifically incremental option like Tree-sitter or Sublime/TextMate language defs (or a completely custom solution like JetBrains, Nova, etc.).

BaculumMeumEst 4y ago

I think you're overestimating the likelihood that Tree-sitter is going to gain enough traction to be reliable for general purpose text editing. It's great for popular modern languages, but not for everything, and there's no fallback in Helix. I'm not convinced that's ever going to change.

p-e-w 4y ago
Reliable? I trust Tree-Sitter's grammars a hundred times more than the underspecified regex monstrosities that power highlighting in other editors. Tree-Sitter grammars are unit tested, have usable primitives for precedence and associativity, and are generally far more predictable than previous highlighting systems. Also, name a language for which there is no Tree-Sitter grammar yet. The only remaining ones are so obscure that the missing "fallback" is irrelevant for 99% of users.
- BaculumMeumEst 4y ago
  Python, Janet, Haskell, and Hare were the filetypes I remember either being unsupported or not working well. I need to be able to depend on basic language support from my text editor, even when I work with niche languages.
  - WhyNotHugo 4y ago
    I've been using Python with tree-sitter on neovim for many months. It's great, and has a lot of improvements when compared with the old syntax system. Re Hare: I haven't even set that one up. Setting up a new tree-sitter on neovim requires extra work for each tree-sitter, and that's definitely a flaw that needs to be addressed.
- albertoCaroM 4y ago
  Is there Asciidoctor tree-sitter grammar? I can't find one.

skavi 4y ago

I like Helix, but it feels slow compared to Neovim. As in the actual scrolling performance. No one else has mentioned this, so I wonder if that’s an issue on my machine.

sph 4y ago
Might it be your terminal that too slow to render? You might want to try one of the many GPU accelerated terminals like Kitty, alacritty, wezterm, etc
- skavi 4y ago
  I use alacritty. And I use Neovim on the same terminal.

Accacin 4y ago

I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch, well they might go to Helix but there's a lot of vim resources out there, so I'm not sure all of them will go to Helix. Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.

least 4y ago
> I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. I would think that helix probably is better because I'm certain that the verb->text object paradigm in vim could be much better. It may in fact make more sense to do the 'text object' first like it seems to do in both helix and kakoune. But is it better enough for me to switch off something that I've used for years now? Only if it sees mass adoption and you see many developers adopting it. Like if you see it in VS Code as an option to use helix bindings, then it is probably safe to consider adopting it. > Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue. I've been pleasantly surprised with how much better LSP setup in neovim has gotten, as I've transitioned over to the native LSP from CoC, which is also excellent. It's still not pain-free to setup, but it's much easier than it was and I suspect you're right that it'll continue to get easier... though I doubt it'll get anywhere close to how easy VS Code is to use any time soon.
- HowardStark 4y ago
  While I was going through the effort to set up DAP support, I discovered [mason.nvim](https://github.com/williamboman/mason.nvim https://github.com/williamboman/mason.nvim) which has been a game-changer for LSP, DAP, and linter setups. There had previously been fragmented plugins (williamboman/nvim-lsp-installer was Mason's predecessor and is a good example) that solved the problem of installation and management for each of these. With Mason, I feel that the story for managing different language environments has jumped to be extremely close to VSCode's extensions.

jeksn 4y ago

Can someone elaborate on why Vim doesn’t work well on non-english keyboards. I use Vim occasionally using a Nordic layout but would like to know why English is superior.

luplex 4y ago
All the hotkeys are more accessible on English. Things like / are just one keystroke instead of two, and so on.
unsafecast 4y ago
It's really not, so long as you map hjkl to the appropriate key sequence on your keyboard. Everything else is based on mnemonics, not locations, so I is just I. Maybe some stuff might be quicker because it's on the first layer, but if it's so bad you can map those specific keys.
mnsc 4y ago
I'm a nordic-layout user as well and whenever I look at the actual differences side-by-side I get reminded about how much easier it would be to code if I had all those symbols that close. https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Different-National-Layouts/#sv https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Diff... And for me I'm pretty sure that this "remap everything and translate every tutorial" barrier is why I never have been able to get into vim.
- gunnihinn 4y ago
  I grew up with the Icelandic layout. When I started programming professionally I taught myself the en-us layout and stared using that instead. It is much easier on my hands and fingers; it really does show that the people who came up with the syntax for most of the programming languages in use picked things that were easy to type on a US layout and didn't give any thought to the rest of us.
  - least 4y ago
    I do not think there's a particularly feasible way to facilitate every keyboard layout out there, so it makes sense that they are at least built with one keyboard layout in mind, much like I think it makes sense that programming in general is overwhelmingly done in English. It increases interoperability significantly.

renox 4y ago

> Those are by far the most important features for a text editor to have The most important feature of an IDE is to be easy to use, having powerful functionalities is important too, but that's goes after.. VSCode has nailed the first point. Wake me up when (neo)vim/kakoune/Helix has a "list of tab view" similar to VSCode..

drekipus 4y ago
(neo)vim/kakoune/Helix are not IDEs so you're going to be asleep for a long while yet.
stackbutterflow 4y ago
What's a list of tabview?
- renox 4y ago
  VSCode has a vertical 'subwindow' on the left which list all the opened tabs. I call this 'a tab view/list', I don't know what's the real name. Usually I have between 10 and 20 tab opened, so the tablist is very helpful for navigating between tabs. Unfortunately (AFAIK) the 'fast' editors (vim, kakoune, etc) don't provide such feature. Some have a tree list but not a tab list :-(
  - da_rob 4y ago
    Built something like this a few years ago: https://github.com/roblillack/vim-bufferlist https://github.com/roblillack/vim-bufferlist
    - renox 4y ago
      Thanks a lot, I don't know why I haven't been able to find it..
  - kagevf 4y ago
    In vim, you can list open buffers with :b Edit: sorry, it’s actually :ls

darrenf 4y ago

> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. I feel like I am definitely not in the "most users" group here. > syntax highlighting ... IDE-like functionality > Those are by far the most important features for a text editor to have. The most important features for me are the ability to navigate around and manipulate whatever's in the buffer(s) efficiently. I'm a 30 year vi/elvis/vim user and ... I'm not going to be able to use this. The deviations from vim's keybindings are much too widespread and tbh I find improved syntax highlighting and (especially) IDE-like functionality significantly too weak a draw to invest any effort in learning the Helix way - only to context switch between local Helix and remote vi(m) throughout my day anyway. I tried, really I did. Opened up a file I'm actively working on. First thing I needed was `dd` and to my horror it didn't delete a line, but two characters. Turns out vim's `x` is Helix's `d` - except not quite; `5d` doesn't do what `5x` did, in fact the 5 does ... nothing? OK fine, well, I regularly use `V` to highlight groups lines and delete those (or pipe them through my equalprg, or `:'<,'>!`) so I tried that ... nope. Though imagine my surprise when I tried `5x` and it highlighted 5 lines. Why didn't 5 apply to `d` but did to `x`? I tried `:r!<some cmd>` but alas, no `:r` and in fact no `:!`. All these examples are things I do tons of times every day. So I read the "Migrating from vim"[0] document really hoping there was a "activate vim compatibility mode" thing but instead all I saw were the new sequences I'd need to learn, especially ones which require more keypresses such as: go to line first non-blank character: vim: ^ helix: gs go to line end: vim: $ helix: gl delete to line end: vim: D helix: vgld or t<ret>d Investigating more, I found `:insert-output` is the same as `:r!` - tried to map the latter to the former to no avail. I kept finding other things that pissed me off just while I was editing the config file (with helix itself). I want to turn off all the menus which pop up everywhere as soon as I hit `:`. I hated that every time I typed a double quote, it inserted two - I literally never want that, in any language, ever. So many showstoppers for me, which is a shame. Perhaps I could configure the hell out of it - going against what many other folk are proclaiming as sensible, sane defaults - but then I'm back to where I came in. All the effort to make it be like vim except with some syntax stuff I don't really need... no sale. [0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vim https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...

e12e 4y ago

parentheses 4y ago

The existence of multiple editors of varying ages still in use today shows that tool choice is not a hard and fast X > Y thing. This personal choice is multi faceted and complex. In software engineering, the proliferation of OSS is at the heart of what makes this craft great. Many passionate people create and recreate tools for the same “job”. All this happens with strong pressure towards public, inclusive and open communities around them. The fact that the method and medium require the same general skills means we can think very deeply about tool choice.

WhyNotHugo 4y ago

If find motions in neovim a lot easier to reason about than those in helix. A lot of actions that are pretty easy on neovim are a huge pain on helix. I do appreciate Helix as a research project investing in new ideas, but I do feel it a lot more limited. Everything keyboard/motions related just feels much more limited than Vim. For example, re-doing actions makes little to no sense because most actions tend to be split in two. `3dw` can be redone just fine on neovim, but not on Helix.

e12e 4y ago

> Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation? FWIW I work on a Norwegian layout on a Mac, which is rather horrible for programming and shell use (option-7 for pipe, shift-option-k+space for tilde (!?), shift-option-7 for backslash, shift/option/alt + 8,9 for brackets ...). I do miss "leader" from vim/neovim - and autocompletion from buffer (when there is no language support, like configuration files).

Liquid_Fire 4y ago
> How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation? Try it with a non-Latin script language. It's borderline unusable. Nothing works in Normal mode. You have to manually switch back to English any time you switch to Normal mode and back to the other language in Insert/Replace mode, or when typing parameters to things like :s. No other editor requires you to switch language back and forth just to use the editor's commands.

0xbeefeed 4y ago

You’re only saying this because it’s written in Rust, aren’t you?

dahfizz 4y ago

> Those are by far the most important features for a text editor to have To you, maybe. The most important features of an editor for me, and for many people, is that it is stable, dependable, and ubiquitous. There is no way I am going to re-learn years of muscle memory for a "post-modern" editor. Cool and trendy is the exact opposite of what I want in my tools. What happens with the authors get bored and move on to the next shiny thing? Vim is available on ~every machine I could possibly interact with. There is a vim mode in every single mainstream editor / IDE. My Vim muscle memory will keep me productive for the rest of my life. IMO, making something slightly nicer to configure is never going to overcome the inertia of a project like Vim. The new editor would have to be like 3x better to convince everyone to make the switch, not 1.1x better in some specific areas.

BanazirGalbasi 4y ago
> Vim is available on ~every machine I could possibly interact with. This is my exact reasoning for sticking with Vim. I use Neovim on my desktop, but I work with servers and have a homelab where I just want the greatest common factor. Nano is also an option, but just like you, my Vim muscle memory is embedded and I end up with :wq everywhere. Is Helix cool? Absolutely. Will it replace [Neo]Vim? Not until it's installed by default everywhere, and that won't happen unless it has a compatibility mode for Vim shortcuts.
kovac 4y ago
Exactly. The features OP described are IDE like features that many vim users like myself don't want in my basic text editor. Adding extra features via plugins is not an afterthought but design. He clearly doesn't understand the vim/neovim crowd and the design philosophy. Small correction though, vi is available on every machine, not vim. But indeed this is big reason why I use vim for my own stuff.

BeFlatXIII 4y ago

Even as a Colemak user, the ergonomic benefits of hjkl navigation are utterly lost on me. It’s left me stuck as an arrow keys plebeian.

TobTobXX 4y ago
Just remap them?

Test0129 4y ago

I can see Helix replacing Vim and Neovim for the most "normal" user. It's great, and it's a better alternative than VSCode for Vim users that aren't quite power users but also not exactly the most basic user either. However, until I can fire up a new installation of *nix and type `helix` to begin editing things it will never replace good 'ole Vim.

bee_rider 4y ago

I don't see it. If you want IDE features in a text editor, you can use VSCode, it even has vim bindings that are at least trying (with middling success) to match the originals. The addressable market for Helix seems to be (neo)vim users who aren't picky about keybindings and new users who want a terminal editor in 2022. So... on the bright side the developers can probably have one-to-one conversations with all 10 of these people.

deleted 4y ago

[deleted]

alwillis 4y ago

I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run. Yeah, that’s not going to happen. It’s cool to have choices, but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there. I’ve been super impressed with the progress of Neovim and the team behind it. It’s only at version 0.8 but they’ve done some amazing things already. I expect Neovim will get to the “batteries included” stage with Treesitter and LSP; it’s not far from there right now. And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Helix sounds like it’s similar to one of these Neovim distributions. Again, Neovim gives you choices: you can configure and tweak it to your heart’s content if you want or you can get something pre-configured with all the goodies installed and configured. Or you can use it headless from a different frontend (VS Code, browser, etc.) if that’s what’s needed. Perhaps the best thing about Neovim is how great it is for both longtime Vim/Vi users and brand new users who are ready to graduate from Notepad and Nano.

kamaal 4y ago
>>And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Problem with distributions is as the contributions decrease they start becoming abandonware with time. Leaving you with with vim and having to work through the configuration hell on the long term for yourself. >>Again, Neovim gives you choices: you can configure and tweak it to your heart’s content Trust me this is negative thing, not exactly something most programmers want. Most programmers don't enjoy configuring their IDE/Editors as a full time project together with your regular day job.
- Corrado 4y ago
  I agree with this. I spend most of my days on newly created systems (AWS EC2 instances) that are bone stock. I don't use any vim plugins at all because they wouldn't be the same everywhere and it's not worth configuring a system I'll only use for 2 hours. If I could get a full featured IDE installed by default on my systems I would ditch vim in a heartbeat.

opan 4y ago

99% of my neovim usage is not programming, and either way I have never found syntax highlighting and similar to be all that important. Text editors need to view and edit text, and do it well. That's about it.

lenkite 4y ago

"Helix is built from the ground up around Tree-Sitter and LSP..Those are by far the most important features for a text editor to have," Well..you just made the argument to stick to Neovim which already does this.