That is just "past discussion", not a dupe. A dupe suggests there's a competing conversation happening right now that may be splintering the discussion.
It's very much a dupe by HN's rules of dupery. It's just that saying 'dupe' went a somewhat out of style since it can come off a little aggro. 'Past discussion' is often just the polite way to point out a dupe.
It's a delight to use it, opens in a few milliseconds, has everything I need, you can't and don't need to configure it much. It just works. No distractions.
Not a fan to be honest. I stick with vanilla so when it breaks I can read the manual. Although I know Doom works great and makes a lot of people happy, it doesn’t do anything you can’t do yourself by downloading packages and configuring them to your needs.
That is true. But it’s pretty overwhelming for a lot of folks. I was a spacemacs user. I tried to rebuild what I liked about it. It was a lot, and I didn’t quite get it there.
A modern Emacs would look like VSCode with an API that was lower level, with less built-in UI, a focus on pure text buffers, and incubated for a few years to build out more of a framework so every extension doesn’t feel completely unrelated. It’s unlikely VSCode will become that, but it’s even more unlikely to be a text editor pitched to Vim users.
I'm a huge fan of Helix, use it everyday. LSP works out of the box(if you install it with a package manager, otherwise you need to do a bit of config) .My configuration file has 5 lines or so, great defaults. No need for overly complicated configuration, or installing dozens of plugins, etc.. Did I mentioned is crazy fast? Opens in ms, and everything feels very snappy. The only thing I noticed, when I use it with tmux, the colorscheme get reverted, dunno if that is a tmux issue or not. But in general, great editor, thanks to the authors.
I recently got into neovim (from vscode) and it took me 1.5 weeks to get it to have similar functionality. I really like the vim commands though. What’s your opinion on that compared to helix?
Helix just has better out of the box experience. Will take you like 5 minutes to setup instead of 1.5 weeks. It is just so much easier to start a model editor if you havent used one before.
I've switched to helix, from neovim and I can say that I like the commands much more. It feels like they took vim commands and made them much more consistent. Plus the UX is so good, lsp out of the box and all. In neovim I always feelt like my config was missing something but helix feels good without even touching the config. Much recommended.
Tree-sitter and LSP (language server protocol) are both global standards. If you support them then you automatically support any language that has a tree-sitter grammar or implements an LSP.
My assumption has been JetBrains' implementations are better for languages that they support deeply since they have so many more man-hours of polish, but e.g. Rust is going to be better with LSP than JetBrains' plugin implementation.
I have not used the LSP directly, but Python's LSP uses Jedi under the hood, the same code as VS Code's official Python extension - it is very good.
JetBrains put in lots of effort but they are just one company - the power of LSP is that the whole community (including companies like Microsoft) are building a single tool that all IDEs and editors can use. Granted I hit a couple of bugs as it is under heavy development but I think they'll win out in the long term.
Not quite, it gets you about 90% there. Even with a grammar to use off the shelf, you still need to write queries to make use of it for highlighting, text object selection, auto indenting, etc. These have so far been particular to the editor.
I gave this a couple of tries but my vim muscle memory is actively hurting me the longer I try... I would love if this had a - at least somewhat closer to - vim-mode, because all the rest, LSP, startup speed, etc, is excellent.
Helix primarily follows the Kakoune model instead of Vim's. It can be confusing to switch from Vim, but Helix's model tends to be more intuitive if one does not already have Vim muscle memory.
Because it's not the same as vim, they've made some fundamentally different choices and their default binds reflect that. I genuinely think helix stands to be better, it lacks the community and thus the extensions of vim/neovim as well as decades of experience, so it's hard to replace it, but for me it's managed to nevertheless.
I love helix. It’s my daily driver at work (python) with occasional hops over to VS Code for a graphical debugger. Would love if anyone has tips for getting the python DAP working in Helix, though.
One thing I really liked about it was the UI experience where as soon as you typed the first character of some sequence it started showing you all the other option starting with the same character. (Try pressing space or Ctr-w in Normal mode)
It made the whole thing far more explorable and I really thought it was a good experience although clearly not yet on par with something as fully mature as vim (but also with far less technical baggage).
The first thing I did on my vim setup was installing an extension which gave me very similar command completions.
>Were you also able to replicate the small popups that open when you press `m`, `g`, etc.?
Yes, although 'm' has a totally different meaning in vim (placing a mark), so there is no popup for that. But it works where there are actually sensible choices, even for marks it works and shows you every available one, which is pretty cool
Helix is really great. If only it had a VIM (or VIM-like) mode available. I find the Kanoune shortcuts really limiting, as they fail to use the relative line numbers for anything except moving the cursor. Bidirectional selection, deletion, commenting, etc. is super useful when coding.
Say I am at the last line of a part of a function, that I would like to delete - maybe some debug output. In VIM, I will look at the relative line numbers and immediately see that I would like to delete up to the number 8. Then I simply write d8<up> or d8h, and I am done.
As far as I can tell - I may be wrong - in Helix, I would have to first do 8<up> and then 9xd. Note the number 9 in there. This is due to the fact that in Helix, I have to count the number of lines I want to delete, rather than just being able to look at the relative line numbers.
In Helix you'd have to x downward or use v to enter visual mode. But you initially said that you "found kakoune bindings limiting". In kakoune you can 8Kxd, or 8K<a-x>d on less recent versions. The vim approach is usually superior for simple commands like "delete N lines", the kakoune approach is superior when you want to compose commands, e.g. `%sif<ret>f(<a-i>(sand<ret>cor` is "select all `if`, find `(`, select inside `(`, select all `and`, change to `or`"
Agreed, but more often, I find myself in a situation, where I just want to delete, comment, or yank a few lines of a function, so I find that going by relative line numbers is a lot more flexible and useful for me.
Legit. You can do nicer than that in Helix’s defaults, but you're right that it won't match d-8-up’s concision: instead of 8-up-9-x-d ("8-move up-9-select whole lines below-delete"), you can do v-9-up-x-d, ("select-9-this line and above-the whole lines-delete").
If you're asking about what helix can do in general, though, as opposed to just the defaults, you can configure it to:
- use relative line numbering
- map a key (say, capital X) to the opposite of x’s behavior — or even better, to `[“extend_line_up”, “extend_to_line_bounds”]` ; the latter won't "eat" the first press by using it to select the current line.
- make the same tweak to lowercase x
Combined, that will get you back to 8-X-d (“8-select whole lines up from here-delete”) to delete up through where you can see 8 in the gutter (and 8-x-d in the other direction).
For anyone who's used to fd/jk/kj/jj/jf or the like in Vim as an alias to ESC to exit insert mode, it looks like Helix is not too usable as of today: https://github.com/helix-editor/helix/issues/2612
I would've considered exploring Helix myself if it wasn't for this.
The classic mapping is Alt/Meta to send escape when tapped, because terminals send Alt-q as `ESC q`.
I have no strong opinions about how people lay out their keyboards, other than that people should try a split key if they haven't. My layout sends ESC when Alt is tapped, capslock is for backspace.
I was just making a joke about how deep we can all get into configuring every little thing on a PC - no offense or point intended, I spend as much time configuring my boxes as using them if I'm being honest.
Looks interesting. I've always remapped capslock to CTRL myself, of course, but haven't thought of remapping tap-capslock to ESC. It looks like you need external software to do this though (like Karabiner Elements on mac, or xcape on linux, etc).
(That being said, if you're used to jk/kj/fd/jj/jf, many years of muscle memory would still take a while to erase...)
You can only map CapsLock to a single modifier in keyboard settings? Which is how I've always had it myself (caps->ctrl) but that's not what's being discussed here.
I'm a long time user of vim/nvim and have learnt so many great techniques from "practical vim". Helix looks good, and the speed is impressive.
It does seem very code-centric though, movements seem based with this in mind. I also find it inconsistent that some movements cannot be combined with actions but others can.
Having said that, there are certainly some ways that vim could be reimagined. I find beginning and end of line movements awkwardly placed by default, as is moving up and down by half and whole pages.
I have a feeling that movement-action paradigm as opposed to action-movement paradigm of vim will have some tradeoffs with visualisation being a plus, and more advanced repetitions bring a negative, but I haven't totally thought this through.
In my experience, as another longtime user of vim and now using helix as my daily driver, it does take a bit of getting used to. But once you grok the whole idea of "selection first, then action", it becomes a bit easier to deal with. Honestly I think Helix is a better editor for those who are looking for the features of Vim but don't want to learn its esoteric syntax. I had to learn Vi/Vim in order to work with FreeBSD machines back in the day, and I had a whole book to reference its commands, so for me it's kinda second-nature. But for new users, I can imagine Vim not being the easiest thing to figure out.
I chose to take the plunge and start using Helix most of the time because:
1. It's like Vim/NeoVim enough that I didn't constantly get stuck. Most of the modal commands are similar to Vim, and you can always fall back to mouse-based selection and using normal commands like Ctrl/Cmd+V and Ctrl/Cmd+C if you don't want to get into the registers just yet.
2. Built-in support for the stuff I actually care about. LSP, fuzzy file picking, inline docs, IDE-like features like "go to definition", it's all included. And unlike NeoVim, it doesn't crash half the time when I'm working on TypeScript files (thanks Rust!). Haven't needed CTags at all since I started using Helix.
3. It's fast. Like, way faster than NeoVim or Vim unless you don't use any plugins. And without plugins, it looks great. Tons of themes to choose from, easy to switch them in the config, etc.
> I have a feeling that movement-action paradigm as opposed to action-movement paradigm of vim will have some tradeoffs with visualisation being a plus, and more advanced repetitions bring a negative, but I haven't totally thought this through.
I think the "advanced repetition" side of this is just going to look different, more like Emacs or Sublime Text in its functionality IMO. For example, the "Migrating from Vim" guide mentions global replace (https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...). This doesn't really go into how it looks, but what happens looks a lot more like NeoVim than Vim. It's still just as fast as Vim to write these commands, albeit a different syntax that you have to get used to, but the benefit is being able to see what is happening to your file while it's happening, rather than after the fact or having to jump through every instance and "confirm" it (which is problematic on large files). In other words, I think this will be/is possible to do in Helix, but it will just look a little different than in Vim.
That's really interesting, thank you for the perspective. I'm amazed so many long in the tooth vim/nvim have moved over!
I do think the movement could be better arranged in nvim/vim - but that's really just an issue of remapping keys I guess. hjkl are in a great place, the equivalent of home/end/pageup/down are odd and not ergonomic.
I compiled helix on a 1Ghz single core processor, and it runs incredibly fast on that. Very impressive.
I really like helix. So much that I've switched from jetbrains to neovim.
I think hx is way more "discoverable" than vim with it's "whichkey" by default functionality and it's motion-first structure is way more attractive to me.
As someone used to an IDE, I just really want git integration and other things. As soon as they land on a plugin system, maybe it will be viable.
Long-time Vim/NeoVim user here...about 20 or so years with it being my daily driver for the last 8. As soon as I found Helix, I was unsure whether it would become my new editor, but I've been using it every day for a few months and haven't really looked back. The only thing I still use Vim for is `vimdiff` with Git, but I don't think I need to, just been lazy about configuring Helix to do the same thing.
Helix does everything I need, nothing I don't, and I don't have to learn a bunch of esoteric syntax. It's a great editor for people new to the world of shell editing, and I highly suggest trying it out.
I used vim as my daily driver probably for the same amount of time as you and couldn't make the switch . The lack of tabs and folding destroyed my workflow.
I like to set my splits up a certain way when I'm working on something specific and then make a new tab when I change context. Then I just change tabs to context-switch quickly.
I also immediately fold all when I open a file to get an "overview" and then slowly dig in deeper.
Both currently impossible in helix (at least last time I checked).
A lot of my muscle memory also doesn't work, specifically with shift+v and selecting/moving sections around quickly.
I got used to the different order of things fairly quickly, but I'm not convinced it's actually more efficient.
I also found the random pop-ups with hints really annoying and distracting. I'm guessing there's probably a config to disable them but I haven't looked into it.
I am contributor to helix that is working on bringing diff functionality to helix.
You can check the current progress on the first related PR on github (https://github.com/helix-editor/helix/pull/3890). The PR is pretty far along. A new gitoxide release is happening today and once that is out we will only be waiting for an upstream library to merge my fixes.
The machinery developed in that PR contains most of the heavy lifting for implementing a vimdiff tool. The only thing that is missing is support in the rendering system to display them. I will be collaborating with one of the maintainers to make that happen as well so we will get a diff mode in helix sooner rather then later.
I used it for a few days, but the not-quite-vim keybindings also destroyed my workflow - I'm a slow learner, took me a while to figure out the few vim commands I know and I hate to relearn everything a bit differently.
Having to switch between "normal" and "insert" modes all the time is one of the things that turns me off from vi and its family tree, and is consequently something that turns me off of Helix, too. There are a lot of neat ideas here, though, and I wonder how many could be hacked into other editors like Emacs.
I’m the same way- my MacBook trackpad is closer to my fingers than the escape key! Not to mention, in VSCode I can do anything with the command palette with cmd+P without the need for separate modes and without the need to memorize a million shortcuts.
If I know the first letter or two of the command, then it’s only 3 keystrokes away. For example, “Evaluate Math Expression” is “cmd+shift+p”+”ev”+”enter”. The command palette also provides great additional explorability with the fuzzy searchable menu + descriptions.
This is a far superior workflow because I have access to every possible command in the editor / installed extensions (very easily mapped to my own shortcuts of I want) without the need to memorize anything. I can even reverse-search commands by typing the shortcut and it will tell me the commands bound to that shortcut.
I could be missing something, but Vim and family feels like a huge step backwards in workflow for me.
> If I know the first letter or two of the command, then it’s only 3 keystrokes away. For example, “Evaluate Math Expression” is “cmd+shift+p”+”ev”+”enter”. The command palette also provides great additional explorability with the fuzzy searchable menu + descriptions.
Similar deal for me in Emacs, especially with things like ivy or helm. Pretty much anything more complex than an existing keystroke is a simple M(eta)-x and a couple letters (and spaces for wildcards). My setup even extends that to search results, opening files, you name it.
Something like Vim or Helix could probably get most of the way there by defaulting to "insert" mode and having some keystroke like Esc or M-x to temporarily switch into a "command" mode.
It is really great that your workflow works for you, and you enjoy working that way! It seems like you've spent time getting used to this workflow, and now get to reap the benefits.
Be careful though, just because you are used to doing something in a specific way, doesn't mean that your way of doing it is superior!
> They are saying that their workflow is superior to the Vim workflow
Yes, for our specific tastes. We're well aware that people have different tastes and might prefer Vim's or Helix's workflow; you can spare us the lecture.
You don't mean to argue that because there are potentially an infinite number of possible editor configurations, that they must all be equally valid, and that there is no objectivity in editor design?
If Helix added some kind of compatibility layer for Vim/Neovim plugins (much like Neovim's support for VimScript or the existence of things like Torch.jl in Julia), I'd switch in a heartbeat. As it stands, I simply rely on too much of the Vim/Neovim ecosystem to make the jump.
I'm a long-time user of Emacs, and although I don't see myself switching to Helix, one thing that I really liked when I looked at Helix was how good the out-of-the-box experience was. As I get older, I am annoyed at the amount of customization that I have for different programs, and I wish I had fewer dotfiles that to maintain and carry around. I recently started trying some of my daily drivers (alacritty, fish, tmux, git) without my configurations and though they're a bit less comfortable, they're pretty good nonetheless. I would probably put Helix in that category: I would probably be fine just using the thing without any customization, because the defaults are so well chosen and polished.
I write mostly in typescript, and being able to run eslint and tsserver is pretty important for my workflow. (I could just use this branch and build it from source though…)
I'm using alacritty all the time, and I'm thinking of switching to starship from powerline because powerline has noticeable startup time (I think it is python-based). Unfortunately neovim+plugins does too, probably as a result of plugins more than neovim.
I tried this and it is much nippier than my current neovim+plugins setup. I'll have to plug in a bunch more language servers to fully compare.
In a way I'm almost hoping they don't add a plugin system. There's something to be said for this all-rust future my terminal suddenly seems to have found itself in: it is quick!
Every text editor should support multiple cursors. In fact, every text field should support it. I often copy paste things into vs code just so I can use multiple cursors to edit something.
Also block indents. If you're going to require four spaces for a quote or a code block, don't make me copy paste between an editor just so I don't have to indent each line individually.
168 comments
[ 3.0 ms ] story [ 208 ms ] threadhttps://news.ycombinator.com/item?id=33147270
That doesn't mean it's a bad submission! it's a good submission, it just has also already happened recently.
Helix: A Neovim inspired editor, written in Rust - https://news.ycombinator.com/item?id=33147270 - Oct 2022 (306 comments)
Helix: A post-modern text editor - https://news.ycombinator.com/item?id=33039390 - Sept 2022 (2 comments)
Helix, Terminal Modal Editor - https://news.ycombinator.com/item?id=30847041 - March 2022 (2 comments)
Helix: a post-modern modal text editor - https://news.ycombinator.com/item?id=27358479 - June 2021 (365 comments)
I finally found a good compromise though. I started over with this confing: https://github.com/susam/emfy
From there, I only needed a handful of packages and a few dozen lines of config to get to an editor that was comfy.
Do you have any more information? Having a bit of difficulty figuring this out, found this for neovim [0] but doesn't seem to be working for me.
[0]: https://jdhao.github.io/2018/10/19/tmux_nvim_true_color/
[1] https://docs.helix-editor.com/lang-support.html
My assumption has been JetBrains' implementations are better for languages that they support deeply since they have so many more man-hours of polish, but e.g. Rust is going to be better with LSP than JetBrains' plugin implementation.
JetBrains put in lots of effort but they are just one company - the power of LSP is that the whole community (including companies like Microsoft) are building a single tool that all IDEs and editors can use. Granted I hit a couple of bugs as it is under heavy development but I think they'll win out in the long term.
The first thing I did on my vim setup was installing an extension which gave me very similar command completions.
How did you do that? Were you also able to replicate the small popups that open when you press `m`, `g`, etc.?
It is https://github.com/liuchengxu/vim-which-key if you are interested.
>Were you also able to replicate the small popups that open when you press `m`, `g`, etc.?
Yes, although 'm' has a totally different meaning in vim (placing a mark), so there is no popup for that. But it works where there are actually sensible choices, even for marks it works and shows you every available one, which is pretty cool
New nvim api lets mappings add a desc which will get picked up automatically with this plugin.
As far as I can tell - I may be wrong - in Helix, I would have to first do 8<up> and then 9xd. Note the number 9 in there. This is due to the fact that in Helix, I have to count the number of lines I want to delete, rather than just being able to look at the relative line numbers.
If you're asking about what helix can do in general, though, as opposed to just the defaults, you can configure it to:
Combined, that will get you back to 8-X-d (“8-select whole lines up from here-delete”) to delete up through where you can see 8 in the gutter (and 8-x-d in the other direction).I would've considered exploring Helix myself if it wasn't for this.
I have no strong opinions about how people lay out their keyboards, other than that people should try a split key if they haven't. My layout sends ESC when Alt is tapped, capslock is for backspace.
https://twobithistory.org/2018/08/05/where-vim-came-from.htm...
(That being said, if you're used to jk/kj/fd/jj/jf, many years of muscle memory would still take a while to erase...)
Ubunutu --> Gnome Tweaks --> Additional Layout options --> Make Caps Lock an additional ESC
Linux Mint --> Keyboard --> Layout --> Options --> Same
From the terminal : setxkbmap -option caps:escape
There are option to swap CapsLock and Escape too, or you can have CapsLock when pressing both shift keys and other worthwhile options
In Mac? Never.
Shame tho...
So you don't even need to map ESC on tap (I prefer to map layout switching to it).
- Ctrl-[ is a chord that you have to press with 4/5 fingers using both hands at once.
- Whereas jk/fd etc are next to each other on the home row and pressed with 2/3 of the same hand sequentially.
Given the number of times you would have to exit insert mode, the second option is arguably more ergonomic...
It does seem very code-centric though, movements seem based with this in mind. I also find it inconsistent that some movements cannot be combined with actions but others can.
Having said that, there are certainly some ways that vim could be reimagined. I find beginning and end of line movements awkwardly placed by default, as is moving up and down by half and whole pages.
I have a feeling that movement-action paradigm as opposed to action-movement paradigm of vim will have some tradeoffs with visualisation being a plus, and more advanced repetitions bring a negative, but I haven't totally thought this through.
I chose to take the plunge and start using Helix most of the time because:
1. It's like Vim/NeoVim enough that I didn't constantly get stuck. Most of the modal commands are similar to Vim, and you can always fall back to mouse-based selection and using normal commands like Ctrl/Cmd+V and Ctrl/Cmd+C if you don't want to get into the registers just yet.
2. Built-in support for the stuff I actually care about. LSP, fuzzy file picking, inline docs, IDE-like features like "go to definition", it's all included. And unlike NeoVim, it doesn't crash half the time when I'm working on TypeScript files (thanks Rust!). Haven't needed CTags at all since I started using Helix.
3. It's fast. Like, way faster than NeoVim or Vim unless you don't use any plugins. And without plugins, it looks great. Tons of themes to choose from, easy to switch them in the config, etc.
> I have a feeling that movement-action paradigm as opposed to action-movement paradigm of vim will have some tradeoffs with visualisation being a plus, and more advanced repetitions bring a negative, but I haven't totally thought this through.
I think the "advanced repetition" side of this is just going to look different, more like Emacs or Sublime Text in its functionality IMO. For example, the "Migrating from Vim" guide mentions global replace (https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...). This doesn't really go into how it looks, but what happens looks a lot more like NeoVim than Vim. It's still just as fast as Vim to write these commands, albeit a different syntax that you have to get used to, but the benefit is being able to see what is happening to your file while it's happening, rather than after the fact or having to jump through every instance and "confirm" it (which is problematic on large files). In other words, I think this will be/is possible to do in Helix, but it will just look a little different than in Vim.
I do think the movement could be better arranged in nvim/vim - but that's really just an issue of remapping keys I guess. hjkl are in a great place, the equivalent of home/end/pageup/down are odd and not ergonomic.
I compiled helix on a 1Ghz single core processor, and it runs incredibly fast on that. Very impressive.
I think hx is way more "discoverable" than vim with it's "whichkey" by default functionality and it's motion-first structure is way more attractive to me.
As someone used to an IDE, I just really want git integration and other things. As soon as they land on a plugin system, maybe it will be viable.
This is a very confusing statement. Helix caused you to drop JetBrains IDEs for another editor (that is not Helix) entirely?
Especially 'hx --health' and its built-in ability to use many language LSP's.
My helix config file is literally 3 lines long, and with that I get full language support.
Helix does everything I need, nothing I don't, and I don't have to learn a bunch of esoteric syntax. It's a great editor for people new to the world of shell editing, and I highly suggest trying it out.
I like to set my splits up a certain way when I'm working on something specific and then make a new tab when I change context. Then I just change tabs to context-switch quickly.
I also immediately fold all when I open a file to get an "overview" and then slowly dig in deeper.
Both currently impossible in helix (at least last time I checked).
A lot of my muscle memory also doesn't work, specifically with shift+v and selecting/moving sections around quickly.
I got used to the different order of things fairly quickly, but I'm not convinced it's actually more efficient.
I also found the random pop-ups with hints really annoying and distracting. I'm guessing there's probably a config to disable them but I haven't looked into it.
The machinery developed in that PR contains most of the heavy lifting for implementing a vimdiff tool. The only thing that is missing is support in the rendering system to display them. I will be collaborating with one of the maintainers to make that happen as well so we will get a diff mode in helix sooner rather then later.
If I know the first letter or two of the command, then it’s only 3 keystrokes away. For example, “Evaluate Math Expression” is “cmd+shift+p”+”ev”+”enter”. The command palette also provides great additional explorability with the fuzzy searchable menu + descriptions.
This is a far superior workflow because I have access to every possible command in the editor / installed extensions (very easily mapped to my own shortcuts of I want) without the need to memorize anything. I can even reverse-search commands by typing the shortcut and it will tell me the commands bound to that shortcut.
I could be missing something, but Vim and family feels like a huge step backwards in workflow for me.
Similar deal for me in Emacs, especially with things like ivy or helm. Pretty much anything more complex than an existing keystroke is a simple M(eta)-x and a couple letters (and spaces for wildcards). My setup even extends that to search results, opening files, you name it.
Something like Vim or Helix could probably get most of the way there by defaulting to "insert" mode and having some keystroke like Esc or M-x to temporarily switch into a "command" mode.
Be careful though, just because you are used to doing something in a specific way, doesn't mean that your way of doing it is superior!
Yes, for our specific tastes. We're well aware that people have different tastes and might prefer Vim's or Helix's workflow; you can spare us the lecture.
;)
https://github.com/helix-editor/helix/pull/2507
I write mostly in typescript, and being able to run eslint and tsserver is pretty important for my workflow. (I could just use this branch and build it from source though…)
I tried this and it is much nippier than my current neovim+plugins setup. I'll have to plug in a bunch more language servers to fully compare.
In a way I'm almost hoping they don't add a plugin system. There's something to be said for this all-rust future my terminal suddenly seems to have found itself in: it is quick!
[0] https://github.com/romkatv/powerlevel10k
Also block indents. If you're going to require four spaces for a quote or a code block, don't make me copy paste between an editor just so I don't have to indent each line individually.