Helix: Post-Modern Text Editor
helix-editor.com
helix-editor.com
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.
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.
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/
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.
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.
Also, I imagine that team size and existing diversity of choice plays a role as well.
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.
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.
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]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.
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...
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.
> 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 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 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.
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?
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.
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:
- 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
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 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!
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
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.
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.
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?
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
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
- 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.
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…)
> Warning: No available formula with the name "helix". Did you mean healpix, helib or helm?
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?
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...
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 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 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.
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.
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.
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 using an ADM-3A terminal
To pick more than one of these is nonsense.
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)