Helix: Post-Modern Text Editor(helix-editor.com)
helix-editor.com
Helix: Post-Modern Text Editor
https://helix-editor.com/
168 comments
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.
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 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 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 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.
Is lua considered an esoteric language?
Yes. It uses 1 as the start of an array.
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.
The first thing I did on my vim setup was installing an extension which gave me very similar command completions.
> 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.?
How did you do that? Were you also able to replicate the small popups that open when you press `m`, `g`, etc.?
Just an extension.
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
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
If you're using Neovim you want this one: https://github.com/folke/which-key.nvim
New nvim api lets mappings add a desc which will get picked up automatically with this plugin.
New nvim api lets mappings add a desc which will get picked up automatically with this plugin.
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.
You need to enable true-color in your tmux config.
e: Huh, didn't even modify my tmux config and it worked on a restart of the terminal.
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/
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/
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?
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.
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'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.
Interesting language support [1]. I might try it for some of my Python/Node projects (though it's hard to see a Python IDE that better than PyCharm).
[1] https://docs.helix-editor.com/lang-support.html
[1] https://docs.helix-editor.com/lang-support.html
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.
Is LSP support for Python better than PyCharm's?
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.
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.
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.
That may be true but at least for JVM languages, intellij is better than LSP.
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.
I think there is a config that maps more to vim, try this https://github.com/LGUG2Z/helix-vim/raw/master/config.toml
Why is it not the default?
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.
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.
Am I the only one that doesn't have any strong preference for some editor?
I am always super impressed by all the comments stating how much of a night/day difference editors make to them.
I have to say that I have tried many (VSC, neovim, Emacs and Spacemacs mostly) in the last five years but at the end of the day I feel like none makes such a difference to me so I just default to whatever my colleagues use to make collaboration (fixing ide issuesm, exchanging configs and tips) easier.
I am always super impressed by all the comments stating how much of a night/day difference editors make to them.
I have to say that I have tried many (VSC, neovim, Emacs and Spacemacs mostly) in the last five years but at the end of the day I feel like none makes such a difference to me so I just default to whatever my colleagues use to make collaboration (fixing ide issuesm, exchanging configs and tips) easier.
Do you have strong opinions about what operating system you use? Makes me wonder what the most common area of the stack people's choices are for where their choice is strongly preferred in their computing experience.
Also, I imagine that team size and existing diversity of choice plays a role as well.
Also, I imagine that team size and existing diversity of choice plays a role as well.
You're stuck using things like that. For work, you're stuck choosing from what's available, because the work is to be done now, not later.
If choosing I'd go with Mac for work. They have hardware that is reliable, and software that is approachable. Unless it's 3-4 levels deep into MS tech, I'd be confident the Mac can handle it.
If I was starting a new project for myself, like a game or a SaaS thing, then I'd go with some Debian or Arch peppered with a RoFi search/command thing, and a window manager akin to i3. A development machine, entirely geared towards looking at and making of code.
But if time wasn't an issue I would not jump on any of the things available to me. They are all largely misguided with relation to my goals. None of them are particularly enabling. All of them are better than center-aligned Comic Sans in a Word.app document, but none of them integrate my prior knowledge, or even the projects I previously did. Every new project is entirely new anyways.
Computers kinda went the sellout route circa 2012, the PC makers do what they understand will sell well, and there aren't any projects that are different enough to warrant an interest. The commercial offering is geared towards the common journeyman programmer, in it's entirety. There are no niche computing devices, I'd expect to see thousands of those, but still there are a handful at best.
There is like one model of a 3-year old Thinkpad that I'd buy, but it doesn't get me excited enough to actually do that. I'd put some Linux on it, with flare.
I have strong opinions. I have the 20+ years of experience to have formed them.
If I were to take a job or a gig in coding ever again, I'd ask the employer for a machine and figure it out from there. I don't care what it is. As my employer, you make these decisions and suffer their consequences.
I'm just here to figure it out, clock out and go home, where you will never, ever call or message me. You got your 8 hours, and they are as you made them come out. Get screwed.
If choosing I'd go with Mac for work. They have hardware that is reliable, and software that is approachable. Unless it's 3-4 levels deep into MS tech, I'd be confident the Mac can handle it.
If I was starting a new project for myself, like a game or a SaaS thing, then I'd go with some Debian or Arch peppered with a RoFi search/command thing, and a window manager akin to i3. A development machine, entirely geared towards looking at and making of code.
But if time wasn't an issue I would not jump on any of the things available to me. They are all largely misguided with relation to my goals. None of them are particularly enabling. All of them are better than center-aligned Comic Sans in a Word.app document, but none of them integrate my prior knowledge, or even the projects I previously did. Every new project is entirely new anyways.
Computers kinda went the sellout route circa 2012, the PC makers do what they understand will sell well, and there aren't any projects that are different enough to warrant an interest. The commercial offering is geared towards the common journeyman programmer, in it's entirety. There are no niche computing devices, I'd expect to see thousands of those, but still there are a handful at best.
There is like one model of a 3-year old Thinkpad that I'd buy, but it doesn't get me excited enough to actually do that. I'd put some Linux on it, with flare.
I have strong opinions. I have the 20+ years of experience to have formed them.
If I were to take a job or a gig in coding ever again, I'd ask the employer for a machine and figure it out from there. I don't care what it is. As my employer, you make these decisions and suffer their consequences.
I'm just here to figure it out, clock out and go home, where you will never, ever call or message me. You got your 8 hours, and they are as you made them come out. Get screwed.
This is surely just the bias of those willing to make a comment one way or the other. If you are so-so about it, you probably don't make the effort to make a comment.
I think the real power is in learning keybindings, either emacs or vim. You'll be able to use those shortcuts everywhere -- your IDE, shell, web browser.
I just wrote an in-depth comment about why I don't think Helix needs an extension system (despite the historical precedence from other text editors) that I think folks interested in Helix might find interesting:
https://github.com/helix-editor/helix/discussions/3806#discu...
I see a lot of vim-to-helix comments, but I have been a helix user for a little while and decided to try neovim seriously for the first time. I've used it, but I never got into it.
I like the extensibility and customizability of neovim. I do not like the action-subject (verb-noun as some put it) model flow, but that could be just muscle memory and bias. I'm going to keep at it and see if I like it better, it might turn out to be more powerful. I don't like a lot of the default binds, helix's binds just seem to be more sensible, again could be bias since I used helix first, and I can always change them.
I like the extensibility and customizability of neovim. I do not like the action-subject (verb-noun as some put it) model flow, but that could be just muscle memory and bias. I'm going to keep at it and see if I like it better, it might turn out to be more powerful. I don't like a lot of the default binds, helix's binds just seem to be more sensible, again could be bias since I used helix first, and I can always change them.
Even in neovim you can select a region first (via 'v') and act on it later. E.g. to change till the end of the word: 'vec' (where idiomatic vi would be 'ce'), to delete the content of a block: 'vibd' (idiomatic: 'dib'), etc.
Started using helix as my $EDITOR a few weeks ago and so far I love it.
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.
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.
theme = "autumn"
[editor]
rulers = [80, 120]I liked autumn so much I copied it in IntelliJ and VS Code.
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.
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.
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.
I would've considered exploring Helix myself if it wasn't for this.
Remap capslock to CTRL when held and ESC when tapped. Good idea for vim too
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...)
(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...)
For Ubuntu/LinuxMint :
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
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
Actually, MacOS can do this out of the box with no extra software installed. It's in the keyboard settings
Do it now and your only regret will be not doing it sooner :)
Using caps lock to escape is close to the ergonomics of an early terminal used by Bill Joy where the escape key sat to the left of Q.
https://twobithistory.org/2018/08/05/where-vim-came-from.htm...
https://twobithistory.org/2018/08/05/where-vim-came-from.htm...
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 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.
What about holding spacebar to overheat the computer and exit emacs?
What about it?
CTRL+[ also sends ESC control code.
So you don't even need to map ESC on tap (I prefer to map layout switching to it).
So you don't even need to map ESC on tap (I prefer to map layout switching to it).
It's a matter of habit, I guess, but.
- 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...
- 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...
The one cool thing about CTRL+[ - it is universal in terminal and doesn't depend on configuration.
I tried that for a while, but having ESC on release instead of on press just didn't feel right for me
I use jj and jk to escape insert mode just fine...
Damn, I never thought of doing that!
no alt-l...?
Helix is cool if you want a terminal editor.
For a GUI editor, I am very interested in https://lapce.dev/
It is perhaps the only editor which for me seems as snappy as Sublime Text.
For a GUI editor, I am very interested in https://lapce.dev/
It is perhaps the only editor which for me seems as snappy as Sublime Text.
Lite XL (lite-xl.com) is also extremely fast. Also, because a lot of it is written in Lua, you can very easily extend it yourself; you can just monkey-patch many functions and do what you want!
It's kind of immature in some ways, for example, the current release version has some limitations in the native plugin interface (which you need for loading C libraries for Lua, as Lite may use a statically linked version), and there is a conflict between the linewrapping and projectsearch plugins where opening a file from it is bugged if you have linewrapping enabled by default.
Lapce does seem more advanced in some ways, but IMO the enormous hackability of Lite is also a nice advantage.
It's kind of immature in some ways, for example, the current release version has some limitations in the native plugin interface (which you need for loading C libraries for Lua, as Lite may use a statically linked version), and there is a conflict between the linewrapping and projectsearch plugins where opening a file from it is bugged if you have linewrapping enabled by default.
Lapce does seem more advanced in some ways, but IMO the enormous hackability of Lite is also a nice advantage.
Does lite xl support language server protocol though?
Yes, there is a plugin for it! https://github.com/lite-xl/lite-xl-lsp
It works quite decently, although again limitations regarding linewrapping apply; the inline lints from lint+ break linewrapping :/
Also, for Lapce I cannot find server integrations other than a few, namely Rust, JS/TS, YAML, C/C++, Go and Dart. No Python, for example. Adding Python support in Lite's LSP is as simple as adding lspconfig.pylsp.setup() to your config (and installing the server), if you already have the plugin set up correctly.
It works quite decently, although again limitations regarding linewrapping apply; the inline lints from lint+ break linewrapping :/
Also, for Lapce I cannot find server integrations other than a few, namely Rust, JS/TS, YAML, C/C++, Go and Dart. No Python, for example. Adding Python support in Lite's LSP is as simple as adding lspconfig.pylsp.setup() to your config (and installing the server), if you already have the plugin set up correctly.
We're planning to support multiple frontend too. The terminal one is just the main client.
Oh, this is good to know! May I suggest putting that in the FAQ? I looked for this information but didn't see it browsing the docs (perhaps I missed it though).
Under "Features", in the readme:
> It's a terminal-based editor first, but I'd like to explore a custom renderer (similar to Emacs) in wgpu or skulpin.
You're right though, it's nowhere to be found in the FAQ.
> It's a terminal-based editor first, but I'd like to explore a custom renderer (similar to Emacs) in wgpu or skulpin.
You're right though, it's nowhere to be found in the FAQ.
In addition, the developer of Neovide proposed collaboration a while back: https://github.com/helix-editor/helix/issues/39
This looks really cool, but I hope they go for the kakoune style commands like helix.
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.
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.
I often wonder what a modern emacs would look like. This feel like a step in that direction.
To be fair it is far closer to a modern vim (modal and with a lot of similar mappings), which also gives it quite a bit of competition.
Emacs is under constant improvement and so are it’s many packages. Emacs looks like modern Emacs
Doom Emacs looks like modern Emacs.
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.
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.
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.
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.
Look at Nicolas Rougier’s GitHub if you want to see what a “modern” Emacs looks like.
I assume you mean https://github.com/rougier/nano-emacs#readme
Yes. Also https://github.com/rougier/elegant-emacs and pretty much everything else in his Emacs section.
Define "modern".
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.
Could you give an example of an edit you couldn’t express?
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.
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`"
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:
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
Thank you for the great answer. I did not know that. I will try it out.
In Helix, you can use `maf` to mark the outer function and then press `d` to delete it.
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.
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.
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.
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 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'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!
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!
Alternatively Powerlevel10k[0] makes for a fast powerline implementation, especially with instant prompt enabled.
[0] https://github.com/romkatv/powerlevel10k
[0] https://github.com/romkatv/powerlevel10k
Note: this only supports Zsh.
Maybe I’m looking in the wrong place but whenever this is posted I’m always surprised there’s no deb package.
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.
I quite like it. I use my own fork of it that introduces a few things that make it more familiar for vim users. It’s definitely different but a lot of it is better.
It’s the first editor I’m seriously giving a try as a hardcore, many years vim user.
If you want a more vim like behavior you can play with my patches: https://github.com/helix-editor/helix/pulls/mitsuhiko
It’s the first editor I’m seriously giving a try as a hardcore, many years vim user.
If you want a more vim like behavior you can play with my patches: https://github.com/helix-editor/helix/pulls/mitsuhiko
Read the docs, I must say I like what I see. Seems focused, minimalistic and using existing technology well. Will give it a try!
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.
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.
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!
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!
This comment comes off as extremely patronizing. All they were saying is that vim is a step backwards in workflow, for them.
They are saying that their workflow is superior to the Vim workflow, which is what I was referring to. Didn’t mean to come off as patronizing
> 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.
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.
> 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.
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.
Huge thank you to the helix team and contributors.
Running `hx` for the first time is one of those experiences where you go simply go, "woah". I've since never looked back and it's slowly defeating how often I open up even larger things in VS Code.
The thing that always held me back from learning `[n]vim` was the huge amount of configuration variability between all the variants and the lack of instruction on just doing something out of default. Neovim is basically the best experience out of the box but even sometimes there you want to have extra functionality. It's really hard to beat the amazing defaults in `hx` and even better `hx -g fetch||build`.
The one thing I'm still missing is ease of running singular test cases or test groups in larger codebases. This still feels hard on Helix.
Running `hx` for the first time is one of those experiences where you go simply go, "woah". I've since never looked back and it's slowly defeating how often I open up even larger things in VS Code.
The thing that always held me back from learning `[n]vim` was the huge amount of configuration variability between all the variants and the lack of instruction on just doing something out of default. Neovim is basically the best experience out of the box but even sometimes there you want to have extra functionality. It's really hard to beat the amazing defaults in `hx` and even better `hx -g fetch||build`.
The one thing I'm still missing is ease of running singular test cases or test groups in larger codebases. This still feels hard on Helix.
It's interesting to me, reading comments in this thread, that this editor mostly seems to appeal to current vim/emacs users. It's like the first choice everyone makes when selecting an editor is deciding whether they want something that runs in the terminal, something that calls itself as an "IDE", or something in between.
Am I the only one who cares a lot more about functionality than branding or user interface?
The 80/20 rule means 20% of an editor's features are going to provide 80% of the value. Instead of focusing on an editor's presentation, why not try to identify an editor which has an unusual feature you consider valuable?
Am I the only one who cares a lot more about functionality than branding or user interface?
The 80/20 rule means 20% of an editor's features are going to provide 80% of the value. Instead of focusing on an editor's presentation, why not try to identify an editor which has an unusual feature you consider valuable?
I use Emacs. I love seeing people working on new editors, too. NeoVim looks awesome, Helix is cool, I wish Kakoune was still active. BUT I don't understand why we're still writing new full-featured editors like this that only run inside terminal emulators.* We've had GUIs for 40 years! They're good, actually! It's okay to have an interface based on pixels instead of grids of characters!
Yes, of course sometimes doing a bit of in-terminal editing is the best way to get something done, but that should be quick, basic, and exceptional, not something where you need an LSP client and project management.
* EDIT: I see now another thread where someone from the Helix project says they're planning other frontends, which is great! https://news.ycombinator.com/item?id=33497529
Yes, of course sometimes doing a bit of in-terminal editing is the best way to get something done, but that should be quick, basic, and exceptional, not something where you need an LSP client and project management.
* EDIT: I see now another thread where someone from the Helix project says they're planning other frontends, which is great! https://news.ycombinator.com/item?id=33497529
if there were indeed hundreds of thousands of text editors, then yes, the way your thinking flows would be warranted
but in reality there are less then a hundred alltogether for all time
each is a project of passion, and all are resultant in a peculiar, particular and special kind of thing to do a special kind of thing
you can't select a thing the VIM way and then do something to it the Emacs way
you can't eat Catholic while working Maori
or you can, but then it is just another special thing that you made up
text isn't a thing
code is a thing (many ways, depending on the approach), prose is a thing (many ways), poetry is a thing, legal writing is a thing
text is not a problem that can be solutioned, it is not a question that has an answer
but in reality there are less then a hundred alltogether for all time
each is a project of passion, and all are resultant in a peculiar, particular and special kind of thing to do a special kind of thing
you can't select a thing the VIM way and then do something to it the Emacs way
you can't eat Catholic while working Maori
or you can, but then it is just another special thing that you made up
text isn't a thing
code is a thing (many ways, depending on the approach), prose is a thing (many ways), poetry is a thing, legal writing is a thing
text is not a problem that can be solutioned, it is not a question that has an answer
Anyone else read the title as "post-mortem text editor"?
I want to love helix, but the transition from vim is too great with very few resources that explain how something that would be done in vim could be done in helix.
I use vim a lot. Here are my first impressions about Helix:
- It loads noticeably slower than vim on my old laptop. (Vim being immediate, Helix taking about 3 seconds).
- The default theme is purple, which I'm not a fan of.
- It's more "put together" than vim out of the box. I wish vim had a bunch of plugins installed out of the box.
- I get some vim shortcuts but not all, which I immediately miss. I guess I'll have to read the docs.
- The default theme is purple, which I'm not a fan of.
- It's more "put together" than vim out of the box. I wish vim had a bunch of plugins installed out of the box.
- I get some vim shortcuts but not all, which I immediately miss. I guess I'll have to read the docs.
Waiting on this PR to get through:
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…)
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…)
"brew install helix" gives me:
> Warning: No available formula with the name "helix". Did you mean healpix, helib or helm?
> Warning: No available formula with the name "helix". Did you mean healpix, helib or helm?
Same thing happened to me when this was posted last month.
Then I spent 15 minutes imagining my new editing bliss while it failed to compile from source. I thought I solved it, but nope.
I like it, but make it work before I get that excited?
Then I spent 15 minutes imagining my new editing bliss while it failed to compile from source. I thought I solved it, but nope.
I like it, but make it work before I get that excited?
Maybe you need to update your homebrew cache? https://formulae.brew.sh/formula/helix
Yes! I waited out the long `brew update` and now it works :)
This project looks awesome and as someone who’s used vim/neovim my whole career, I’m very excited for a modern modal editor. If it had an easy motion/sneak/leap/hop sort of thing (there’s an open PR), I’d switch right away. I keep checking on it every few weeks. Can’t wait for that and the plug-in functionality.
Helix supporters often cite the object-action paradigm as preferable to vi's action-object. I find this argument moot: you can work in object-action fashion in vi as well if you remember to begin your sequence with 'v' (possibly at the small cost of an additional keypress in some cases).
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.
Other than Kakoune, is there anything else in this vein? Preferably not written in Rust?
Fascinating stuff, thanks for the link.
I found this quote from the page linked by that repo's README about what "structural regexps" are:
“The current UNIX® text processing tools are weakened by the built-in concept of a line. There is a simple notation that can describe the `shape' of files when the typical array-of-lines picture is inadequate. That notation is regular expressions. Using regular expressions to describe the structure in addition to the contents of files has interesting applications, and yields elegant methods for dealing with some problems the current tools handle clumsily. When operations using these expressions are composed, the result is reminiscent of shell pipelines.”
Seems like a rather insightful understanding and domain-widening effort when it comes to manipulating programs. I've always wanted something like paredit, but for everything else besides lisps.
I found this quote from the page linked by that repo's README about what "structural regexps" are:
“The current UNIX® text processing tools are weakened by the built-in concept of a line. There is a simple notation that can describe the `shape' of files when the typical array-of-lines picture is inadequate. That notation is regular expressions. Using regular expressions to describe the structure in addition to the contents of files has interesting applications, and yields elegant methods for dealing with some problems the current tools handle clumsily. When operations using these expressions are composed, the result is reminiscent of shell pipelines.”
Seems like a rather insightful understanding and domain-widening effort when it comes to manipulating programs. I've always wanted something like paredit, but for everything else besides lisps.
"Not written in Rust"? Is Rust at that level on the hype-curve by now? :-D
It's just notably bad for beginners, and getting worse all the time. I've been in software for over three decades and I haven't seen the obsession this bad since Java, which has apparently come a long way towards UX, and also didn't ever put out new BS every six weeks that I can recall. Rust on the other hand, is an absolute nightmare for beginners. I've spent a lot of time throughout my career working with non-programming-inclined math and *-int people, and I've already seen one outfit crash and burn from trying to deal with it's complexity rather than just using Python/R/Matlab, because "safety" or because "performance" or whatever else somebody lied and told them.
This shouldn't become a Rust-bashing thread, I'm just genuinely curious if there's lesser-known "post-modern" text editors. It's crazy to think how many thousands of days I've accumulated in gedit... For how much we spend our time in editors, it still feels so primitive just typing things in a few bytes at a time and compiling, etc etc. Back in the early 2000s, I thought we were getting close to just Star-Trekking it, but alas. I have to read about whatever the shit a devcontainer is... to edit text...
This shouldn't become a Rust-bashing thread, I'm just genuinely curious if there's lesser-known "post-modern" text editors. It's crazy to think how many thousands of days I've accumulated in gedit... For how much we spend our time in editors, it still feels so primitive just typing things in a few bytes at a time and compiling, etc etc. Back in the early 2000s, I thought we were getting close to just Star-Trekking it, but alas. I have to read about whatever the shit a devcontainer is... to edit text...
I’m curious though how as a user of the editor the programming language even matters (beyond how complex it is to compile).
And if you do want to contribute I’m reasonably certain that helix by virtue of how it’s programmed is the easiest to contribute to I have come across.
And if you do want to contribute I’m reasonably certain that helix by virtue of how it’s programmed is the easiest to contribute to I have come across.
I see what you mean, I suppose I should have clarified.
I want to dig into one of these editors for a stronger understanding of how they work, and using something as obtuse as Rust is a total nonstarter for me.
I read through the source of micro over a few weekends during the 2020 lockdowns and really enjoyed the experience, though I was woefully underprepared with spending that much time looking at Go, which I wasn't familiar with at the time. Even still, I felt relatively confident within a few hours.
Conversely, I've seen things like: https://fasterthanli.me/articles/a-half-hour-to-learn-rust from Rusties that just made me sick to my stomach. It's just ridiculous how many syntactical elements there are, and how little is done for the end-user by way of ergonomics. To top it off, people who've spend dozens (!!!) of hours with Rust still struggle with it. With Go, Python, maybe C, and others, I can typically bring students or grads up to speed enough to at least have a decent conversation about crucial code within a single workday.
I do think that the Rust ecosystem is a brittle one, despite the grandiose claims of safety and security, in that few people whose time is valuable and whose experience is vast would be spending their time wisely coming up to speed with the language in any scenario, even outside of text editors. The
Again, I'm not starting a Rust-bashing thread, esp not with someone invested in Rust, but that's where I'm coming from.
I want to dig into one of these editors for a stronger understanding of how they work, and using something as obtuse as Rust is a total nonstarter for me.
I read through the source of micro over a few weekends during the 2020 lockdowns and really enjoyed the experience, though I was woefully underprepared with spending that much time looking at Go, which I wasn't familiar with at the time. Even still, I felt relatively confident within a few hours.
Conversely, I've seen things like: https://fasterthanli.me/articles/a-half-hour-to-learn-rust from Rusties that just made me sick to my stomach. It's just ridiculous how many syntactical elements there are, and how little is done for the end-user by way of ergonomics. To top it off, people who've spend dozens (!!!) of hours with Rust still struggle with it. With Go, Python, maybe C, and others, I can typically bring students or grads up to speed enough to at least have a decent conversation about crucial code within a single workday.
I do think that the Rust ecosystem is a brittle one, despite the grandiose claims of safety and security, in that few people whose time is valuable and whose experience is vast would be spending their time wisely coming up to speed with the language in any scenario, even outside of text editors. The
Again, I'm not starting a Rust-bashing thread, esp not with someone invested in Rust, but that's where I'm coming from.
> I want to dig into one of these editors for a stronger understanding of how they work, and using something as obtuse as Rust is a total nonstarter for me.
I would be absolutely amazed if the language is what makes an editor easy/hard to understand unless that thing is written in whitespace/brainfuck. In this particular case the helix codebase is incredible easy to understand and contribute to, definitely easier than vim, neovim and others _despite_ the fact that it's written in Rust.
I would be absolutely amazed if the language is what makes an editor easy/hard to understand unless that thing is written in whitespace/brainfuck. In this particular case the helix codebase is incredible easy to understand and contribute to, definitely easier than vim, neovim and others _despite_ the fact that it's written in Rust.
>new BS every six weeks
My project advances the state of the art, your project publishes updates, his project puts out new BS.[0]
Also, I'd like to know whoever's recommending Rust for _beginners_? Nobody should be doing that. Not even the most hardcore fan I know would push that.
[0]: https://en.wikipedia.org/wiki/Emotive_conjugation
My project advances the state of the art, your project publishes updates, his project puts out new BS.[0]
Also, I'd like to know whoever's recommending Rust for _beginners_? Nobody should be doing that. Not even the most hardcore fan I know would push that.
[0]: https://en.wikipedia.org/wiki/Emotive_conjugation
I don't think rust is particularly bad for beginners. It makes subtle bugs harder to write, so the bugs you get tend to be pretty straightforward and easy to diagnose.
There is obviously a bit of upfront investment, but it's comparable to most other languages (less than C++, for example). I have a much easier time writing rust than C, for example, and I'm a very mediocre programmer.
There is obviously a bit of upfront investment, but it's comparable to most other languages (less than C++, for example). I have a much easier time writing rust than C, for example, and I'm a very mediocre programmer.
Every time I see a "X: a [new/better/best/modern/postmodern/blazingly fast] Y" post on HN, I just know it's going to be written in Rust
Does it matter? I used Rust to write it but I don't claim it's "blazingly fast". The post-modern tagline is a joke. https://news.ycombinator.com/item?id=33158035
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?
;)
;)
Atwood law ran its course. Now we need a same law, except for Rust.
I get shiny new stuff syndrome vibes everytime there is a new editor that claims to be perfect and magically solve all problems.
I've recently started using helix as my daily editor, and would really like to see:
1. Git gutter.
2. Commands similar to * and # in vim.
I could give this a try. My current VSCode setup offers me nothing really. Just nice syntax highlighting.
>Modal editing
>Not using an ADM-3A terminal
To pick more than one of these is nonsense.
>Not using an ADM-3A terminal
To pick more than one of these is nonsense.
No deb packages unfortunately ( or generic x86-64 tarball)
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.
On HN "dupe" means "the story has had significant attention in the last year so. This is in the FAQ: https://news.ycombinator.com/newsfaq.html.
That doesn't mean it's a bad submission! it's a good submission, it just has also already happened recently.
That doesn't mean it's a bad submission! it's a good submission, it just has also already happened recently.
Agreed, but on the other hand it's the 3rd time I'm seeing this posted and there's no new releases or anything.
Thanks! Macroexpanded:
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)
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)
You can pull vim from my cold, dead hands.
Nobody is gonna try! Use what you like!
use what you like /shrug
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.