helix

Also checkout Helix for those who want Vim with nice defaults (like LSP). https://helix-editor.com https://github.com/helix-editor/helix

That "exhaustive" list doesn't include Helix[1], an editor with more than 400 contributors and 17k GitHub stars, which has been in development for close to three years, and which is probably more widely used already than 95% of the editors on that list ever were. [1] https://github.com/helix-editor/helix

This guy here [0] articulates my thoughts about tabs perfectly. If all you care about is buffers, what do you miss about them in vscode or IntelliJ? Their idea of buffers is the same as vim, as far as I can tell. Or is the problem that the IDE functionality is not implemented as buffers? So you can't use your normal keys in non-text places? That was what I was referring in the second part of the comment. [0] https://github.com/helix-editor/helix/issues/2295#issuecomme...

VSCode was my to-go for years but I had to force alternatives due to the increasingly bad practices I’ve seen by Microsoft. So I switched to vim. It has a large learning curve for me & the habits I have, and a lot or it requires work, but I have liked the change a lot — especially for remoting and working directly on other systems. It isn’t as convenient or easy, but the freedom is important. Anyway, with regards to Rust, I was using https://github.com/helix-editor/helix for a bit as an editor. I ran into an issue with keymapping that was pretty basic but still an involved feature and so I set it down, but it is still very functional. A few years and it will be solid. And I agree with you, new offerings will come from Rust that will outcompete.

If the bindings were the same, then what's the point? We're not a "vim ported to rust", instead we got our own take on things. (from the vision doc: "Don't try to be everything for everyone. There are many great editors out there to choose from. Let's make Helix one of those great options, with its own take on things.") > helix wants to get much wider adoption I've stated this before: I just want to make a good editor that I like using daily. There's a growing community of users with similar preferences that are very happy with it, but I'm not aiming to corner the market -- this isn't a startup. Much in the same way as vim isn't trying to become more like VSCode to increase it's market share. That said, thanks for giving it a try! For keybinds, we do have a couple of guides: - `hx --tutor` is the equivalent to vimtutor - https://github.co

needs more newlines still, blocker for me https://github.com/helix-editor/helix/issues/4274

A contributor of Helix is working on the implementation of a file tree view [1]. However, the contributor seems busy at the moment. [1] https://github.com/helix-editor/helix/issues/200

1) there's a pull request that fixes this but needs a bit of polish (https://github.com/helix-editor/helix/pull/1819) 3) There's also a discussion for this, we hoped to include it in this release but it's instead going to be in the next cycle (https://github.com/helix-editor/helix/pull/4439)

I gave Helix a try the other day and really enjoyed the "feel" of things. I'm also generally impressed with their philosophy / approach, after having spent way too much time tuning my Neovim configuration. However, I ran into several blockers for it being my daily driver, I thought I'd share them: 1. It's generally janky whenever the language server is slow, in ways that Neovim is not. The most visible one of these is that completion does not take into account the characters that were typed between when the completion request started and when the completion was selected. For example, if I type "abc", and the LSP suggests "abcdef" after having only observed the "a" keystroke, Helix will end up with "abcdefbc" as the final output. This is annoying. 2. The posted directions (https://github.com/helix-editor/helix/wiki/External-binary-f...) fo

I’m really impressed by Helix and would love to use it, but re-wiring Vim muscle memory developed over a decade or using it feels such a pain. The problem is also not even that if I stop using Helix I’ll have to re-learn Vim bindings, but the fact that I also use Vim bindings whenever I open VSCode, too. The subtle differences are both good (many things out of Vim work out of the box in Helix) and painful (the ones that don’t give an awkward feeling. Awkward take on that is that I think if Helix came up a completely different key bindings it would be easier to switch to… Edit: the differences are not way too dramatic but slightly annoying since many of those are very frequent actions - https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...

There is a pending pull request partially addressing this: https://github.com/helix-editor/helix/pull/4204 It would be nice to have a comprehensive and convincing explanation in the documentation which sheds lights at the advantages of helix's treating lines. Maybe we vim old timers could learn something new and make a more informed decision about switching to helix.

helix, just switched from nvim :) it is very promising https://helix-editor.com/ https://github.com/helix-editor/helix

In addition, the developer of Neovide proposed collaboration a while back: https://github.com/helix-editor/helix/issues/39

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 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.