Current status as of December 2022:
There’s two prototypes we’re exploring that could potentially exist side by side: a typed list/ML-like implementation for scripting and a Rust based interface for things that require performance. Could potentially run both in wasm but I’m personally a bit unhappy with how big wasm implementations are, easily several orders of magnitude compared to the editor
Originally posted in https://github.com/helix-editor/helix/discussions/3806#discussioncomment-4438007
As of February 2024, this is being worked on in https://github.com/helix-editor/helix/pull/8675
When will the next release be?Releases don’t have exact timelines. The maintainers aim for a few releases per year and cut a release when they feel that enough changes have collected in master and the branch has stabilized.
Is a Vi/Vim keymap planned?We are not interested in supporting alternative paradigms. The core of Helix’s editing is based on Selection → Action, and it would require extensive changes to create a true Vi/Vim keymap. However, there is a third-party keymap: https://github.com/LGUG2Z/helix-vim
j/k bindings be changed to ignore soft wrapping when using a count like 3j
j and k are intentionally mapped to visual vertical movement. This is a more intuitive default that makes working with heavily soft-wrapped text (like this Markdown document) much easier. Textual vertical movement is bound to gk and gj. So you can use 3gj and 3gk instead of 3j and 3k to jump to a relative line number.
These commands are intentionally separate (with no special casing for count != 0) as they represent the fundamental vertical movement primitives. All other vertical movement behavior can be created by combining these commands using conditions. For example:
(if (!= count 0) (move_line_up count) (move_vertical_line_up 0))
If these fundamental primitives had such special handling built in, that would limit what could be implemented. Furthermore, helix is slightly opinionated towards unsurprising and consistent behavior.
Pressingx when on an empty line selects the next line, is that a bug/how do I change that?
This behavior is by design. Pressing x will extend the selection to the current line unless the current line is already selected. If the line is already selected it will extend the selection to the next line. This allows repeatedly pressing x to quickly select a few lines.
In the case of an empty line, the entire line is already selected (since there is only a newline character on the line). The intention is to use selections interactively so you would not press x in this case because the line is already selected. For example, if you wanted to delete an empty line you would just press d.
In cases where you always want to extend the selection to the line bounds and never want to extend to the next line you can use X. For example, if you want a key combination to blindly mash to delete a line that would be Xd.
You can :run-shell-command like this :sh echo "hello world!" and it’ll show the output in a pop-up. Examples:
:! cargo check
:! npm run build
:! make tests
We recommend running code (npm start, cargo run, etc…) in a separate terminal pane/tab or split, especially for TUI or GUI apps.
:w --no-format. Alternatively, you can temporarily toggle off formatting with :toggle auto-format, then toggle it back on again
Helix aims to support only the official parts of the LSP specification in its codebase.
Some language servers extend the LSP specification to add custom methods and notifications. For example rust-analyzer adds a custom rust-analyzer/expandMacro request to provide its macro expansion feature: https://rust-analyzer.github.io/manual.html#expand-macro-recursively.
Extensions to the LSP spec should be implemented in language-specific plugins once the plugin system is available.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4