- archseer parenthttps://github.com/helix-editor/helix/pull/12527
- Author here. I listen to feedback, but it's hard to incorporate every possible requested feature without the codebase becoming an unmaintainable mess.
We're a small team with limited time and I've always emphasized that helix is just one version of a tool and it's perfectly fine if there's a better alternative for some users. Someone with a fully customized neovim setup is probably going to have a better time just using their existing setup rather than getting helix to work the same way.
Code editors in particular are very subjective and helix started as a project to solve my workflow. But users don't always respond well to having feature requests rejected because they don't align with our goals. Plugins should eventually help fit those needs.
- I think you're mistaken. See https://www.youtube.com/watch?v=3UAaky12REM for example.
- Both ZSTD and LZ4 were built by the same author. They have slightly different target goals: https://www.hackerneue.com/item?id=23211804
- There's also a dramatic video rendition by the author: https://youtube.com/watch?v=_lLm3a33WsE
- There's this config you might like: https://github.com/LGUG2Z/helix-vim
We can't invert the bindings though (wd -> dw) because that would require a big internal change to add operator pending mode:
When you press `d` in vim, that enters the operator pending mode, where it will wait for an object to be specified, in this case `w` and then delete it.
In a selection first model, `d` is very simple: it just always deletes the selection. So you select a word, then delete.
- 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.com/helix-editor/helix/wiki/Migrating-from-Vi...
- Our Matrix chat is always happy to help with questions :)
- 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 think you mean elastic tab stops https://nickgravgaard.com/elastic-tabstops/
- Maybe you need to update your homebrew cache? https://formulae.brew.sh/formula/helix
- 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://www.hackerneue.com/item?id=33158035
- > Helix cursor is bad and they refuse to fix it
What? Our cursor matches the default vim one (always 1-width, always bar). If you want to change cursor shapes, there's a config option too https://github.com/helix-editor/helix/wiki/FAQ#change-cursor...
- > it kind of falls apart
I'd like to point out that the editor is barely a year old and I'm working on it entirely during my free time. It takes time to sort out all the issues and provide excellent support for all languages. I primarily write Rust and Go so those are guaranteed to work well.
It's hard to do tree-sitter query based indentation with space based languages, because the indent has semantic meaning and the AST node is invalid until indentation is typed out. We do have a potential solution (https://github.com/helix-editor/helix/issues/763#issuecommen...), it just needs someone to go and implement it.
I don't consider tree-sitter niche though. Outside of VSCode it's widely adopted, but yes it's probably too soon to only rely on tree-sitter with no fallback. Of course we do implement fallback behaviours too: we try to use tree-sitter first, then provide a simpler fallback for cases where there's no grammar available (or like in this case, it's not a great fit).
Edit: this has prompted me to switch python to the fallback algorithm for now https://github.com/helix-editor/helix/commit/9ae70cc410bd042...
- > something that was unknown to be unsafe
The call they were using was deprecated and marked unsafe a while ago: https://github.com/solana-labs/solana/blob/7ba57e7a7c87fca96...