Related ongoing thread:

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

I gave Helix a shot, and I immediately ran into a wall due to an undocumented limitation where in a language configuration, indentation can only be up to 8 spaces. (I'm working on an Assembly project with an indentation of 12 spaces to make more room for labels.)

I checked the source code to figure out what the heck was going on, and I found this: https://github.com/helix-editor/helix/blob/207829eefee51095d...

Pretty often, my projects have weirdly specific needs like this. I think (Neo)Vim's greatest strength is that it always absolutely has some way of covering a weirdly specific need, whether a one-off command or a project configuration. But that seems to be against Helix's philosophy.

If Helix can't be the editor, then I can't justify taking the time to learn it. It makes me sad, though, because I really like what it's going for.

That looks very hacky. Is there a reason for this limitation that you've found makes sense?

That doesn't look hacky, it looks written by someone with 3 months of programming experience. I would personally avoid relying on an editor written by programming newbies.

Something something logical fallacy [1].

[1] https://en.m.wikipedia.org/wiki/Ad_hominem

I always find it interesting how hostile some (many?) peoples take on source code can be. Rather than give benefit of doubt, they attack. But even if it is some stupid code, some late-night, tired-brain, foggy-flu-delirium .. so what?

I get it, don't run a project if you see some bad code and question the quality of the project. Quality that very well could, and likely will, impact you. From bugs to performance. Don't run it, of course. But to attack it, seemingly with such personal zeal.. can people not improve?

I dunno, i guess i just don't feel the software we write on average is actually good. We make compromises and mistakes constantly. Our house is the purist of glass and many of us are just chucking stones like there's no tomorrow.

Lets take a step back. Breathe. Point out flaws by all means, but maybe reduce the often apparent revelry in someone else's mistake.

... sorry for the high horse rant. I'm nursing coffee and i've just seen it a lot with Lemmy/Kbin recently. Also this isn't pointed at anyone here directly.. just a pattern i feel i frequently see.

What? No. An ad hominem is "I think your argument is wrong because your face is stupid". "This is bad software because it looks like it's made by amateurs" isn't attacking their character, it's attacking their ability to write good software, which is highly relevant.

"The code is bad because it was written by a novice dev" sounds like an ad hominem attack to me (as opposed to "the code is bad because of X attribute of the code itself").

It looks to me like it was written by someone quite intentionally to avoid allocations in the common case, and they punted on handling less common cases to later.

Maybe it's done like that for performance reasons?

I'm struggling to see how that function could be a bottleneck, and if it were, memoization would easily get rid of it without the ridiculous limitation.

It could be better for sure, but that function has been there for almost as long as the project has been open-source if I recall correctly. It probably hasn't been touched since then because it wasn't a high priority.

It seems relatively easy to send a PR to allow supporting any number of spaces (or at least increase the upper limit to 16).

> allow supporting any number of spaces

As long as nothing is depending on 'static lifetime further down the line. (EDIT: ignore and see below)

> (or at least increase the upper limit to 16)

That should be doable for sure. Even something like (I'm not a rust developer, just have a passing familiarity, so my syntax may be off):

    IndentStyle::Spaces(n) if 0 < n && n <= 16 => &"                "[0..n as usize],

I think that would condense it all down into one line, rather than having special cases for all of 1 through 16.

EDIT: after toying around in the rust playground, I think the following will support any indent level (within the bounds of the u8 type).

At the top level:

    static INDENTS: [u8: 256] = [' '; 256];

And then in the as_str function:

    IndentStyle::Spaces(n) => std::str::from_utf8(&INDENTS[0..n as usize]).unwrap()

The [0..n] slicing is what I was surprised to not see being done. As for what you're suggesting, using from_utf8 adds a overhead to check that you're giving it valid UTF-8 (this does not get optimized away). Dipping into unsafe can help here:

    const INDENTS: [u8; 256] = [b' '; 256];
    // ...
    IndentStyle::Spaces(n) => unsafe { std::str::from_utf8_unchecked(&INDENTS[0..n as usize]) },

But I would consider having INDENTS be a &str to get the cheap slicing without needing unsafe. Since putting in a string literal of 256 spaces is nasty I would use the const_format crate to generate the constant:

    const INDENTS: &str = str_repeat!(" ", 256);

Closing the loop, this is now implemented and on main, thanks to msdrigg: https://github.com/helix-editor/helix/pull/7429

This makes me happy, thanks for sharing

Nice!

I'm not sure I could justify bringing in a package for a one-liner, just to avoid an "unsafe" which could be easily documented in a comment as actually safe.

Its doing that to get a static str (no allocations). I assume it is for performance reasons, but I can’t speak to whether it’s actually a significant impact.

The real flaw here in my mind is the lack of comments :D

If this was a carefully observed decision, one that is prone to looking odd, it deserves an explanation for future selves to not chase the rabbit of understanding.

A sane implementation would be for the fallback to construct a string containing the desired number of spaces on the fly and memoize. Unfortunately, this is written in Rust, and the language makes it super awkward to implement caching patterns transparently as they involve passing around references to mutable state.

There’s a dozen ways to solve this… from arc to ref cell, the language provides all sorts of methods to solve this.

The great thing about Helix is that it is super easy to build locally. Make changes to the number of spaces allowed and it should work as expected, unless there is another reason they have such a limit.

> always absolutely has some way of covering a weirdly specific need

what's the (Neo)Vim way of covering the need for elastic tabstops, multicursor editing, differentiating left vs right modifiers and tap vs hold regular keys?

Multicursor editing, left/right modifiers, and tap/hold keys aren't "needs", they're methods/tools used to accomplish needs. The need is to make a specific edit on a file.

I respect those features, and I respect Helix as a great forward-thinking editor. I will just have to revisit it in the future once it's more configurable.

I arrived at modal editors via Helix. I had bounced off (neo)vim multiple times, primarily due to the verb-object editing scheme, and initially found Helix to be a godsend.

That said, I had an editing paradigm too opinionated even for Helix, so I mangled my Helix config into what I thought at the time was my dream editor.

Over time, though, I started to "see the light" of Vim's ways. I'd run into this or that use-case, realize that I had mapped the key for it to something that fit my custom paradigm ideas, and one by one, switched back to the defaults. Eventually, my Helix config became more Vim-y. So I switched to Neovim and didn't look back.

I got really into the plugins and customization, and while yes, I still do have a good bit of plugins and a somewhat large config, it's become more and more stock with time.

It took me a long time to get it, but the Vim model really is truly brilliant. I still appreciate Helix (and by extension, Kakoune), and I'm happy I went through the weird twisty road that I did, but ultimately I found that the ways in which those two differ from Vim were indicative of me "clinging" to old editing habits from more "standard" editors. It took truly diving in and accepting that maybe, just maybe, I didn't have better ideas than a 50-year old editor that's stood the test of time, to see it.

Thank you for writing this. The last sentence really got me thinking.

I really don't like Kakoune's model of extensibility. It's one of the reasons I switched back to Vim after using Kakoune as my main editor for several months. The configuration system is esoteric, fiddly, and (as of 4 years ago or so, when I last used it) not thoroughly documented.

I think Helix made a good choice by building in LSP support and other things that would otherwise require extensions, and by having a "you don't really need it" policy for things like panes, which you can just do with tmux. And I think Neovim made a good choice by exporting a configuration/extension API in a very standard, commonplace extension language like Lua. I disagree that Neovim's Lua API is really a different language. It's just an API; Kakoune has one too, albeit of a more esoteric sort.

Incidentally, I started using Helix a month or two ago and I've been liking it a lot. Having the language server stuff already integrated is a fantastic convenience. I could probably switch to using hx exclusively if I really wanted, even with no extension system whatsoever. The only thing I want that they haven't implemented yet is easymotion jumps, and there's an MR for that already [0].

[0]: https://github.com/helix-editor/helix/pull/3791

Wait, no panes? What about things like diffing two files? There are also plenty of other situations too where I’ve definitely wanted splits in the same client, so I can see multiple files at once but also copy between them (which requires shared registers), write macros that switch between the panes (which… well, I suppose Kakoune’s composability approach might be able to support such a concept, but I get the impression Helix really wouldn’t), &c.

Wow, https://github.com/helix-editor/helix/issues/405, indeed no side-by-side diffing and the approach being suggested would be hopelessly crippled for even two-way diff (let alone three- or four-way diff, which are probably just total non-starters), since it would only support editing one of the documents!

Seriously, my mind is boggling at considering a “you don’t really need it” policy for at least splits. I really do need it: even on my base task load, tmux would be inadequate in painful ways multiple times per month; and I regularly (sometimes daily for weeks, though other times not for months on end) do things for which it would be completely debilitating so that I couldn’t possibly use Helix and would have to go back to Vim.

Splits are provided, tabs and terminals aren't. Diff mode is work in progress.

What if I need to cut and paste things from one file to another? Registers wouldn't sync I'm guessing, so I'd have to do something hacky with the system clipboard

There are default keybinds for copy/paste to system clipboard, but as the parent said, tabs are a work in progress.

The lack of diff mode has been my biggest hangup in terms to trying helix out seriously. I'll keep an eye out for it to land.

Helix has splits and the issue you linked for side-by-side diffs is still open!

You can still use a dedicated diff tool for these situations if they come up regularly. In my experience they are better than vim anyhow.

Vim is not a very good diff tool (e.g. no word diff, tho there's a plugin) but it's good enough for most cases and it's nice to never have to switch the way you work.

> and by having a "you don't really need it" policy for things like panes, which you can just do with tmux.

They do panes, they don't have tabs. Although it looks like github user nrabulinski created a PoC[0]. Not having tabs is what made helix unusable for me, it just messes with my workflow too much.

And you are wrong about using tmux for this. It does not work with helix because it doesn't follow a client-server model, two instances do not share information between each other (someone please correct me if I'm wrong)

If you are using kakoune, you can actually use tmux (or any tiling window manager like i3wm) to recreate proper tabs since it does have a client-server model. Multiple kakoune instances can kakoune processes can share information. It's actually the most flexible system for windowing in my opinion. It allows you to do things like |kak|firefox|kak| with both kak instances sharing information.

[0] https://github.com/helix-editor/helix/issues/2295#issuecomme...

All I care about when it comes to editors is availability (on every platform, can be used in a terminal), longevity, and the community for third party plugins. Vim still checks all of those boxes and the only real other contender is still Emacs.

Vim is super crusty, Kakoune and helix have better takes on the unix philosophy, integrations. VSCode is easier for absolute beginners to click around in. IntelliJ has better semantic parsing. But none of that matters. None of that holds me back from being successful. I just need an editor I can type code in that I will never have to give up, that will just be there, and I can use at the next job. In fact Vim's quick editing is just a nice to have, it's never been the difference between me killing it and getting killed at work. That's why I'm sticking with Vim.

I was drawn to helix specifically because it is excellent without the need for plugins.

LSP and tree-sitter grammars carry so many of the features I had to add to vim and emacs—over years of configuring—that I feel like I’m not missing anything important; despite having an emacs config large enough to justify its own repo outside all my other dotfiles.

My whole helix config is telling helix what theme I want and the path to my nix formatter, and it feels nice.

Your points concern everything around text editing, but not editing itself. Emacs brings nothing new to the table with respect to editing model, it's essentially notepad (with different interface, plugins, yada yada yada — all the things you mention). Vim has a model with modal editing, much better than Emacs. Kakoune and Helix improve this model even further.

It's like comparing cars by the color of the trim and air conditioning, instead of… er… their car performance (power, speed, fuel usage, durability).

If you don't care about editing models, and just want to "type code", then Vim is hardly the best choice. Emacs and Intellij are much better than Vim at plugins, and are as available as anything else.

> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad

Emacs (1976) predates Notepad (1983).

I do understand what you mean, though. For people using Windows, Emacs needs to be sought out and installed, this effort needs to be justified (assuming one is permitted to install software at all), and hence the requirement for Emacs to "bring something new to the table" over the default option, Notepad, which is just /already there/.

The most basic, implicit, requirement, then, is exactly as GP says: availability. All else follows.

I meant Notepad as an example of something that implements the basic "move the cursor between the characters with arrow keys and type to insert text" way of interacting with text. In terms of this, Emacs is exactly Notepad + plugins. And plugins (unless they drastically change the way you interact with text, like Evil mode) are usually doing something that is orthogonal to the editing model, and can be slapped on top of any editor with any model.

I didn't mean that one is based on the other historically. Notepad was meant as the most minimal example that implements one of the Emacs'es aspects.

> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad

Wow, and here I thought I had seen all derogatives about Emacs ;-) But claiming that it doesn't bring anything new compared to Notepad is really strange.

1. Emacs predates Notepad by one or two decades. 2. Have you actually had a look at what is actually included in Emacs? I am not talking about mail readers and other "apps" inside emacs. I mean just for editing text in a non-mode specific way. Things like rectangular cut and paste, vertically aligning stuff, infinite undo, undo restricted to the selection (region) and many many more stuff. That Notepad doesn't have.

Chordal editing isn't as popular as modal editing, but I do like it and think it's something uncommon in other editors, at least to the same extant as emacs.

The thing I like about emacs is the integration and consistent experience. I can do everything in emacs (and use exwm as my window manager), so I have the same keybindings for everything.

As perhaps an extreme example, imagine having 1. A window manager like i3 2. tmux or screen 3. (n)vim or helix sessions with edited files, possibly inside tmux/screen

Each of these need to be configured separately, and each layer needs different keybindings so that uncaught ones can be forwarded from one layer to the next. Each layer is limited to only the subset of things it manages. E.g., i3 can let you switch between firefox and the terminal running tmux, but not the different sessions tmux manages, or views of any of the files in your nvim session. Etc.

Or I could just use emacs create tiles I can move between, and each of which that is capable of opening any of my x-windows, terminal sessions, or open files. You can even use the same autocomplete in your shell as when editing files.

I don't know of anything that gives the same simple, unified, workflow of EXWM (+ corfu&consult&...). It does have issues and could use a serious modernization -- still single threaded in 2023, with some commands blocking IO??? -- but perhaps it's simply much too ambitious for someone to try and make a competitor. These can have modal editing, tree sitter and lsp integration would be great, etc. The thing I want is the smooth integration of everything I may do on a computer into one interface that emacs, but no other software I'm aware of, offers.

What is chordal editing? Google search didn't give me any results.

I agree that having different programs on you computer integrated and consistent is a good thing. Sorry for the reference to the old joke, but wouldn't all the things you list look better in a wishlist for an operating system instead of a text editor?

By chordal editing, I just meant pressing combinations of keys at the same time. Lots of editors support this to some degree, but most (AFAIK) are either modal, or don't support keyboard-driven workflows. One of the other classic emacs jokes is about how it can take key-combinations to extremes, e.g. https://xkcd.com/378/

I agree that I'm looking for a tiling window manager. This is what EXWM (the Emacs X Window Manager) is. The problem with things like i3, is that it is not integrated enough with editing and navigation of files.

I wish there was more in this space, as Emacs has some limitations for this purpose (e.g. multithreading), but AFAIK emacs stands alone.

Why do you care so much about availability of an app that is unusable without a lot of plugins? At which point, you can copy plugin code with the editor app to a place you need it available in

The point of an editor having tons of plugins is captured in one phrase: the long tail [1]. A mature tool with a healthy ecosystem of plugins will have every user installing a unique (or nearly unique) suite of plugins. Attempting to have the base tool itself support all those millions of different use cases and configurations is a lost cause.

[1] https://en.wikipedia.org/wiki/The_Long_Tail_(book)

You're just reinforcing my point instead of addressing it, the tail of plugins you need is not available everywhere

The plug-ins are for the home environment, customized to be ideal and cover all bases. Like a home office.

The core functionality being available everywhere means a familiar and efficient, even if not ideal and complete, suite is available everywhere else: servers, other computers, a new system. For transient / temporary use. Like on a business trip, a flight, or the conference.

Except it's neither familiar nor efficient because, e.g., you're using your custom keybindings in your "home office" (and there are a dozen of more things that become integral to your editing experience), all of which would break down your basics.

Just like you wouldn't use a random laptop during a business trip and expect to be efficient, you'd bring your own!

A data point: I'm a plugin-heavy neovim user, and I wholeheartedly testify that familiarity with vi modal editing is incredibly useful when ssh-ing into remote systems, and I don't have my plugins.

Not to disagree, but these days vscode (and probably others, but vscode is the best I've tried) mostly alleviates that need with remote editing. It also has a few objective benefits, like eliminating typing latency (e.g. if your remote machine is on the other side of the globe), and letting you keep all your local settings and extensions (mostly).

I def wanna try that out sometime!

It does sound to me like that is not a consequence of the GUI-ness of VSCode, but just the man-hours that go into making it. In other words, it doesn't sound like that experience can't be replicated in terminal-only editors.

If anyone has experience with remote editing in a terminal editor, but not through an ssh shell (ie, the traditional way), I'm very interested in hearing your experience.

> If anyone has experience with remote editing in a terminal editor, but not through an ssh shell (ie, the traditional way), I'm very interested in hearing your experience.

As usual, emacs has a mode for everything:

https://www.emacswiki.org/emacs/TrampMode

Emacs’ TRAMP works well (it’s been available since at least '99, and has been built-in for as long as I can remember), and supports most everything (ssh, ftp, docker, whatever you can get at with rclone, ...). It also works fine with dired (the built-in file manager), eshell, whatever.

The mostly-single-threaded nature of Emacs gets in the way sometimes.

Except I'm sure that book fails to mention many examples where the long tail worked and instead focuses on where the long tail failed and biases it's own story around that.

Jetbrains suite of IDEs are basically long tails and they have huge utility in many areas that exceed other editors.

“Unusable without any plugins” is quite a description to throw in there as an assumption.

It's barely useable. I rely a lot on code completion, search capabilities and syntax checking while I code. It just saves a lot of time from having to execute the compiler and wait for it to check everything.

With good "plugins" or "features" all of these things happen async.

Like Godwin's Law, every discussion of Vim on HN will inevitably tend towards complaining that it doesn't have features that it has shipped with 10-30 years.

It doesn't have code completion. You can install it as a feature, but vim itself doesn't have that feature. There needs to be a law for someone either flat out lying or not knowing what they're talking about because godwin's law doesn't apply here.

Additionally installing these features on vim is a nightmare for various reasons. It can be done, and I've done it, but the experience is not as good as the more clunkier GUI IDEs. I'm all for a TUI IDE if the experience was as automated or seamless as jetbrains or M$, but such a app doesn't exist yet.

^n

Sometimes it's faster to fix the code where the bug is, rather than trying to recreate it in your cushy dev environment. Sometimes that means driving somewhere and working through at 9600 baud over an RS-232 cable. Do this a couple times and you'll find that vi is quite usable--you just have to want it to be.

>Sometimes it's faster to fix the code where the bug is, rather than trying to recreate it in your cushy dev environment

Sometimes, but with single powerful IDE solutions from companies like jetbrains, setting up a "cushy" environment is barely any work.

>Sometimes that means driving somewhere and working through at 9600 baud over an RS-232 cable. Do this a couple times and you'll find that vi is quite usable--you just have to want it to be.

Of course if your network connections completely fail you have to use the serial console to fix it. There's no going around that. But the majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.

Additionally a "cushy" environment doesn't preclude you from using serial console or using vim to do edits everywhere. VI in this sense is barely useable, it's basically the baseline necessity. You need it when all else fails. But it's not good to have it as your daily driver.

> Sometimes, but with single powerful IDE solutions from companies like jetbrains, setting up a "cushy" environment is barely any work.

I promise, installing a Jetbrains product on a traffic controller (which is what I was thinking of re: the field trip) would be a tremendous amount of work.

> The majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.

Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.

>I promise, installing a Jetbrains product on a traffic controller (which is what I was thinking of re: the field trip) would be a tremendous amount of work.

Jetbrains isn't installed on a traffic controller. It's installed on your local machine. Both VSCode and jetbrains have something called "remote development" which allow you to develop on a remote machine as if it was local. It's similar to ssh and vim.

>Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.

A geomagnetic storm will render everything useless, I don't see how a vim user will be more protected then a vscode user.

Not everything, just things hooked up to long enough wires to induce significant current. Pretty much just the power grid and the copper communication networks. For instance, I've got a raspberry pi hooked up to some solar panels handling some gardening stuff for me, it'll be just fine.

Editors are irrelevant to that conversation, but people who are accustomed to relying on stacks with many dependencies will definitely find that they struggle more without the internet than people who keep their dependencies minimal. And it's not a cherry picked example, there are all kinds of cases where minimal dependencies = resilience. It doesn't mean you have to go around using punch cards or something, it's really just the emotional attachment to complex tooling that I'm calling out as a hazard here. You end up cultivating skills that are easily invalidated.

>For instance, I've got a raspberry pi hooked up to some solar panels handling some gardening stuff for me, it'll be just fine.

You can remote ssh into the pi with Vscode or a jetbrains IDE with a laptop that likely won't be fried either under your description.

Python can run on the rasperry pi. Even high level interfaces will remain. Additionally GUI support exists on a Pi.

That’s your preference, which is fine. I started using extensions earlier this year, they were a little annoying to set up and don’t add much, I probably won’t do it again if I change machines.

Vim is not an "app".

I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools. You can't take magit to vim or helix, because it is an Emacs extension. And each tool has it's own way of extending it, which means you need to learn essentially a new API (if not an entire language) to extend a tool.

However extensibility makes it much easier to move within a tool. The authors sample kakoune config for doing splits is a great example. Since Kak doesn't support splits natively, you have to learn 3 separate tools do the spliting in a WM. In something like Emacs there is only one thing to learn to manage splits on all platforms. And it is using the same extension mechanisms you use for everything else.

I found this the paragraph just before the conclusion to be an interesting demonstration of these trade-offs:

> All of that to say that, the take of Helix is pretty good here, because all of those UNIX problems are not there in that editor: everything runs in the same process, inside the same memory region.

The author spends a lot of time praising composability over extensibility, but then admits that Helix has some real advantages because it is not composed with tree-sitter or lsp, it has those built in. Essentially it was extended with those features, they become part of editor, instead of trying to interact with them in a uniform way.

This reminded me of the xi-retrospective section[1] on modular software. composability works better on the small scale, but struggles when you have many independent things interacting with each other. It is fine for simple things like "using the shell to sort lines" or "bring your own fuzzy finder", but with more complicated integration it starts to falter.

[1]https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...

I found https://yarchive.net/comp/linux/everything_is_file.html a very compelling read today, on similar topics. Specifically, having a base set of abstractions that everything "speaks" is a huge boon that is often hard to articulate. Annoying, as the drawbacks and sheer number of edges is often much more easily described.

TO that end, Emacs' "everything is open to everything else" works surprisingly well, once you get used to it. Especially so if you go with not introducing new primitives to makes things happen in the process. Even "async" is relatively easy once you get used to the sentinel approach.

Can you imagine a better way? Almost certainly. I have yet to see one survive the test of so many contributors, though.

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

[1] https://github.com/phaazon

[2] https://github.com/phaazon/kak-tree-sitter

[3] https://helix-editor.com/

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

> something really inter

?

esting.

Thank y

I really enjoy Helix. The toml configuration and built-in Treesitter and LSP support are stellar. It works well enough to be a daily driver.

But after 20 years of Vim muscle memory, I can't deal with the keybindings. Not that they're inherently worse, just different - I'm perfectly happy with vim motions and relearning to type is pretty low on my list of priorities. Luckily there is a compatibility hack, not perfect but it's close enough: https://github.com/LGUG2Z/helix-vim

Weird how different people can be. The only thing I found compelling in the “great features” list is snappiness. Otherwise,

- subject-verb isn’t a universal improvement; Vim provides both through visual mode with an extra keypress, kak/helix only make one easy;

- git integration looks sub-par for anyone familiar with magit / fugitive;

- the level of discoverability is at “much worse than Emacs, but proud of the achievement”;

- system integration is on a table stakes level.

The extensibility / composability topic is close to my heart, but the particular take does not sound right.

Emacs, for one, is not extensible like vs code is extensible, it’s runtime modifiable via insane levels of “internal” composability that is not achieved by other tools. It also works well with outside tools. I don't see what prevents the author from running magit separately; you can absolutely eval a magit-status from your command line. You'll lose editor integration, but that seems to be the point of the exercise?

In this particular case, the whole philosophical comparison reads like an excuse for Helix’s limitations.

TOML config would just make me angry on a daily basis.

It’s okay to like simple simple things. Just don’t compare them with Emacs — it's an entirely different kind of thing. Apples, oranges, kitchen sinks.

This writeup definitely makes me want to try Helix. But I am worried that it won't suit my needs because of 1 of the 2 issues I have faced with all non VIM/Emacs editors I have tried.

It's largely focused on programming and won't be as smooth a writing and editing experience in non programming use cases. That seems to be the case for almost every editor I've tried.

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

One thing I never see people talk about in these comparisons is file type support. Vim has everything from hosts file to apache, nginx, sudoers, etc, etc. And for general purpose languages it is still better than things like tree-sitter. Certainly the latter has more features but it is less reliable and consistent.

After almost 20 years of vim I switched to doom emacs for development. But for sysadmin tasks I still use vim. And sometimes I miss its consistency even for GPLs.

> However, if you type w, the cursor will move to the end of the word while the anchor will move to its beginning, visually selecting the word

Would be cool, but all it does is move the cursor to the end, anchor remains in the middle of the word (if you start from the middle)

I'm amused, as I immediately think, "er/expand-region" covers this like a champ. Complete with C-g leaving the cursor where you started, if you change your mind.

You're right. One way to select a word from the middle in helix is `miw`.

Yes, I'm using `miwc` a lot (used to `ciw` in nvim)

You can use `bw` or `be` to do that

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

I never got the impression that the developers had an attitude. The discussion I've seen has been mostly people making demands or saying Helix will fail if it doesn't support AI tool integration right now, but none of the devs are interested in using that kind of tooling with Helix, so they don't implement it. When they have poked fun at someone, it has been because that someone is very quick to demand the feature, but unwilling to submit a PR.

There is an open PR for getting copilot support, though it's currently just a hotfix and likely won't be accepted into core. You can still patch your own version and compile it.

My understanding is that the devs think that AI-assistance should be plugins, as there's no open spec for communication with Copilot and others:

https://github.com/helix-editor/helix/discussions/4037#discu...

And the plugin system is not done/released yet.

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

The author did mention emacs in the previous article where he talked about editors.

> The reason I didn’t stick around Emacs was basically because of its runtime choice, and ultimately, its Lisp ecosystem. The Emacs community is one of the best I have been talking to, and they have really, really talented people working on insanely complex topics, like turning Elisp code into native code (via C), including Emacs itself. But even with all those optimizations, the editor was still feeling too slow, and has a lot of background that you can feel. All the abstraction layers, all the Lisp macros (oh no), etc.

https://phaazon.net/blog/editors-in-2022

It already is! I've been building Emacs from the development branch for the last couple of years, and the improvements in 29 and now 30 have really been great. I barely remember the sluggishness the other comment mentions.

man all these new editors trying to fix problems with the old and I am just trying to master neovim (and for that matter just vim as I haven't even gotten to the benefits of neovim other than the LSP stuff).

at this point I am so productive in vim/neovim that I more-or-less just glance and pass on announcements of new editors. For me to switch to anything at this point other than neovim would be for it as a project to go away.

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

Argh! I’ve been finally getting around to learning vi (vim), and now you are telling me that is so last century, I need Kakoune?

At least Vim “mode” seems to be supported everywhere. Surely I get more bang for “time investment” than these others?

vi is ubiquitous, so it's still a useful thing to have learned. Especially for fresh linux installs, or in default VM environments, it's useful to be able to use vi.

Though, IME the cost of learning something like kakoune or helix's motion (having already learned vi) is quite low. -- The value-add of vi's modal editing doesn't go away just because something even nicer comes along; it does mean you get the chance to use something even nicer.

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

This is a problem common to all TUI programs that rely on the POSIX terminal paradigm.

But nvi (nvi2) it's fast.

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

I want terminal editor that does not need me remembering keyboard shortcuts to edit things. Mouse should be optional, and editing without mouse should be the default. But every editing operation should be easy to access and sensible - You don't have to read any docs to navigate/edit/search/replace.

When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary.

You can say, I want VSCode that runs in terminal, but one that does not hog my cpu/memory. It should feels instant to do anything, without any loading time if possible.

> I want terminal editor that does not need me remembering keyboard shortcuts to edit things.

Keyboard shortcuts are essential to increase efficiency and speed. For example, ctrl-c, ctrl-v, ctrl-z, ctrl-s, ctrl-p, ctrl-a etc. People learn these early on if they regularly have to input/edit text to speed up their workflow. Otherwise, they would have to resort to pointing and clicking through menus to accomplish the same thing.

The longer you use an editor, the more of these shortcuts you commit to (muscle) memory, so, even if the commonly used editing operation is easily accessable via the GUI interface, people are going to choose the keyboard shortcut to do the same thing since it's faster.

> When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary.

You could navigate with the mouse or arrow keys in either vim or emacs. The only thing you would have to learn is how to save the file. You may not even have to learn that because both vim and emacs display a dialog box asking you whether or not you want to save the file if you try to exit the editor without saving first.

Well, then Helix/Kakouine/Vim/Neovim isn't for you.

Doing things with a mouse is accessible to you because you've already learned how to do it. It's not innately more intuitive or self describing in any way, the learning curve is just behind you.

I used GUI editors for a long time. I'd operate my computer with my right index finger and resisted any attempt to change that interface. I'd learn the usual Ctrl shortcuts and what not, that was about it. One day I finally dove into Helix specifically and not only am I not looking back, I am finding and using software specifically based on whether it uses vim like key interface. If it can't it takes like 50% points off the software, going back to the mouse is just so painful I don't know how I ever tolerated it. I feel like a chicken operating a typewriter.

How would you use a terminal editor without a mouse and without remembering keyboard shortcuts?

Nano is considered one of the smallest / simplest editors, and it shows you the keyboard shortcuts on the bottom of the window, is that what you're wanting?

Ooh, a menu-driven terminal editor? That sounds neat, you first select "copy" from the menu, then move a cursor to a certain point in the file where you want the copy selection to start (or end) and then you move a second cursor to the other end of the selection. Then you're back in the menu and you select "paste" and you move a cursor to where you want to paste the text. To insert you select "insert line", type out a line of text, and then move a cursor to the point where you want to insert the text.

It does sound like it would be a bit slow in operation, though.

You have described the Borland C++ 2.0 editor (from 1990, worked on DOS).

Nano supports mouse, right?

Tutorial "optional" is just weasel words for "works like things I already know." Problem is, especially in expert tooling, that everyone seems to know something else.

You want notepad in the terminal, then? There are a bunch of TUI editors like this, see the answers to this thread.

Terminal User Interfaces (TUI).

There aren't many editors like that around.

Check out micro and mcedit.

mcedit.

Better, "mcedit -b"

Or Jed: https://en.wikipedia.org/wiki/JED_(text_editor)