# A survey of newer terminal editor projects **URL:** \ **Category:** Off Topic\ **Tags:** other-editors\ **Created:** [May 6, 2021, 2:09pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711 "2021-05-06T14:09:27Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![EpocSquadron](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/epocsquadron/32/78_2.png) [@EpocSquadron](https://discuss.kakoune.com/u/EpocSquadron)\ **Post date:** [May 6, 2021, 2:09pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/1 "2021-05-06T14:09:27Z")
Like many of you probably are, I’m very interested in terminal text editors. There’s an inexplicable draw to working with pure text in a pure text environment that just feels right to me. I did a little looking around for some experimental terminal editors that are in the vein of kakoune, or at least vim, which might have interesting properties. Here’s a list of ones that caught my eye along with short descriptions of the features that stood out to me. - [Breeze](https://github.com/dpc/breeze) - Compiles to WebAssembly, plugins in WebAssembly, |-shaped cursors, directly kakoune-inspired (breaks a little from kakoune in providing cursor movement without selection). - [Zee](https://github.com/mcobzarenco/zee) - Tree-sitter highlighting, rope data structure for buffers (like Xi), targets 100 FPS even with millions of lines. Emacs bindings though. - [Pepper](https://github.com/vamolessa/pepper) - Directly kakoune-inspired, custom syntax highlighter, lua command prompt and config, intends direct lsp integration - [Amp](https://amp.rs/) - Easymotion mode, sublime text syntax compatibility with jump to symbol based on it, yaml config. - [Sapling](https://github.com/kneasle/sapling) - Pure AST editing and highlighting. Very early stage but interesting. ---
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [May 6, 2021, 3:42pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/2 "2021-05-06T15:42:44Z")
For decades programmers have had to write structured data (“programs”) in plain, unstructured text files. To make life easier, editors grasped at what few structural markers were generally available: editors like `ed` let you insert, delete, or change entire lines; editors like Microsoft’s Notepad let you move around by word or by page; probably the most complete are editors like Vim and Kakoune that provide all sorts of fancy operations for working with sentences or string-literals or matching grouping symbols, but at this point we’re grasping for structures that might reasonably appear in a generic text file, or even a generic source-code file — anything more requires the editor to have syntax-specific understanding. Vim and Kakoune actually do have that, in a very simple way. In many situations, rather than using a predefined movement or selection pattern, you can write a regular expression that describes a small part of the file’s structure, and navigate like that. Regexes are not _easy_, especially beyond the most basic uses, but it’s a lot simpler to write a regex occasionally than it would be to update Kakoune’s C++ code and recompile it for every file-type you wanted to edit. This combination of built-in support for generic structures, and ad-hoc support for specific structures through regexes, is very powerful and is a good part of the reason why Vi-lineage editors are still around nearly fifty years after Vi was first invented. Powerful as it is, there’s still significant limitations. For example, the “jump to matching bracket” operation is [frequently confused](https://github.com/mawww/kakoune/issues/4188) by brackets inside string literals. Trying to work on text inside comments frequently gets the comment markers mixed up with the content. Are `<` and `>` grouping symbols or mathematical operators? Properly handling such things requires the editor to understand the specific file-format in question. At this point a lot of people start talking about giving the editor deep knowledge of syntax, like an AST editor, or a [JetBrains](https://www.jetbrains.com/) IDE, but it turns out this is a _lot_ of work. For all the experience and institutional knowledge JetBrains has about editing structured programs, they currently sell eleven specialised IDEs — there must be thousands or even millions of file-formats and syntaxes in the world, it’ll never be possible to write a JetBrains-tier IDE for every single one. A tool like [Tree Sitter](https://tree-sitter.github.io/tree-sitter/) is a lot simpler, but developing a Tree Sitter grammer [still requires](https://tree-sitter.github.io/tree-sitter/creating-parsers) writing a grammar in JavaScript, compiling it to C, then compiling the C into your program — orders of magnitude more effort than writing a regex. I definitely think the next killer feature of Vi-lineage editing will be structural knowledge, but I think it needs to be more like writing a regex or a Kakoune syntax highlighter than writing “real” code. I’d like to tell my editor that `comment = "//" not("\n")*` and then anywhere I write a regex I can write `$comment` to mean “text spans tagged as comments”. I’d like to try various structure patterns interactively, and when I find the ones I like, paste them directly into a file to make a grammar, like making a Kakoune plugin. I’d like to run an external program to generate a syntax tree in case the built-in structure pattern language isn’t flexible enough, in the same way that many Kakoune plugins generate `range-specs` highlighters. I’m pretty sure it would be possible to make an editor like that, and I’m pretty sure it would be great, but I think it would be too radical a change for Kakoune. And writing a brand new editor would take a _long_ time to reach the maturity and polish and ecosystem Kakoune already has. So I’m not sure that editor will ever arise, but I’m keeping an eye out just in case. ---
**Author:** ![prion](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/prion/32/404_2.png) [@prion](https://discuss.kakoune.com/u/prion)\ **Post date:** [May 6, 2021, 9:51pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/3 "2021-05-06T21:51:09Z")
Kinda sounds like you want a Parsing Expression Grammar (PEG) based editor. ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [May 7, 2021, 6:42pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/4 "2021-05-07T18:42:28Z")
> [@EpocSquadron](#): > > Tree-sitter highlighting, rope data structure I hope these two things will become more common across all editors. ---
**Author:** ![EpocSquadron](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/epocsquadron/32/78_2.png) [@EpocSquadron](https://discuss.kakoune.com/u/EpocSquadron)\ **Post date:** [May 7, 2021, 7:05pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/5 "2021-05-07T19:05:08Z")
I concur, and from what I’m seeing in that small list, and with neovim, it seems to be a lot of people want to make it happen. I’m pretty bullish about tree-sitter because it’s used across projects so the likelihood someone will come along and improve a parser for your language is much higher than say a PEG for vis, or breeze’s custom lua matchers, or even kak’s highlighting groups. ---
**Author:** ![EpocSquadron](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/epocsquadron/32/78_2.png) [@EpocSquadron](https://discuss.kakoune.com/u/EpocSquadron)\ **Post date:** [May 11, 2021, 2:15pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/6 "2021-05-11T14:15:18Z")
Went looking for more recently, this time by browsing go packages. It feels like there haven’t been many successful editor projects in go in general, and those that made it were pretty standard. Interesting contrast to rust. Anyway I did find one that has some interesting ideas, though I haven’t run it to see if it’s really that good: - [Glom](https://github.com/p9c/glom) - annotation of documents, structural drag and drop. Actually a gui editor, but including for lack of terminal editors in go, and interesting features. ---
**Author:** ![eyepatchOwl](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/eyepatchowl/32/735_2.png) [@eyepatchOwl](https://discuss.kakoune.com/u/eyepatchOwl)\ **Post date:** [May 17, 2021, 3:26pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/7 "2021-05-17T15:26:25Z")
I disagree that this is too radical for kakoune. Imo, this is totally feasible as a plugin that integrates with tree-sitter. Sure, you have to solve the distribution problem, and the pain threshold for adding a brand new grammar is higher, but I don’t think those are wildly difficult. There’s some required ui work for good integration. 1. You could provide a locked structured mode which uses all the usual binds, but in a structured context. e.g. sf for select function decl/def. if the user wants, you could swap the modes to make structured the default and normal mode bindings in a user mode. 2. tree-sitter parse trees aren’t asts and they differ from my mental model of the language, but that might be solvable in the pattern language. 3. The pattern language of tree-sitter could be massaged in the same way that kakoune massages structured regular expressions to be interactive. Kakoune is the editor that’s, imo, best equipped for this and the effort required to integrate kakoune with tree sitter seems likely to be far less than developing a new editor with that natively. Additionally, if I think about an editor, I think I’d prefer the vanilla editor to not require language specific information to be useful, e.g. regex. ---
**Author:** ![aec](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/aec/32/910_2.png) [@aec](https://discuss.kakoune.com/u/aec)\ **Post date:** [May 17, 2021, 10:27pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/8 "2021-05-17T22:27:26Z")
Like a chronic illness, once every few months I get an urge to find a structural code editor. Most of the languages I use primarily are less mainstream so I have yet to enjoy and explore kak-tree. I rarely limit that search to _terminal_ editor projects though. Like I think code editing shouldn’t be limited to movements conceived around text operations; we should also not be limited by what a char-grid can represent to edit codes. ---
**Author:** ![TeddyDD](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/teddydd/32/21_2.png) [@TeddyDD](https://discuss.kakoune.com/u/TeddyDD)\ **Post date:** [June 1, 2021, 6:48pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/9 "2021-06-01T18:48:31Z")
Just found this on orange site: [https://helix-editor.com/](https://helix-editor.com/) Looks like pre-alpha stage, but it’s interesting since it seems to follow Kakoune editing model pretty closely. ---
**Author:** ![eyepatchOwl](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/eyepatchowl/32/735_2.png) [@eyepatchOwl](https://discuss.kakoune.com/u/eyepatchOwl)\ **Post date:** [June 1, 2021, 10:07pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/10 "2021-06-01T22:07:42Z")
Important addition from the linked site: " **Syntax highlighting** and **code editing** using [Tree-sitter](https://tree-sitter.github.io/tree-sitter/). No more slow regex highlighting! Tree-sitter parses code into syntax trees much like a compiler, giving us a lot more information about code structure. We can track local variables, calculate indentation and manipulate selection to select syntax nodes." ---
**Author:** ![skewballfox](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/skewballfox/32/455_2.png) [@skewballfox](https://discuss.kakoune.com/u/skewballfox)\ **Post date:** [June 3, 2021, 2:39pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/11 "2021-06-03T14:39:49Z")
honestly the main problem I have with terminal based editors is the lack of dynamic windows(like the hovering docs from vscode), clippy(or other tool) showing over the top of the file being edited definitely gets in the way (especially with smaller window sizes) ---
**Author:** ![alexherbo2](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/alexherbo2/32/1140_2.png) [@alexherbo2](https://discuss.kakoune.com/u/alexherbo2)\ **Post date:** [June 10, 2021, 10:55pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/12 "2021-06-10T22:55:11Z")
> > > Helix takes a lot of inspiration from vim and kakoune, which are both great edit…ors in their own right. I'd like to suggest a couple of other editors that I think bring some interesting ideas to the table. > > However, please don't take this as a pushy "Helix should do things this way!" kind of thing--that's not how I intend it at all. I'm not specifically trying to push the project in any of these directions. Rather, these are a couple of lesser-known editors that people may not be aware of that I think might spark some useful ideas. > > > \## \[Zed\](https://github.com/zedapp/zed) > > Zed is a now-defunct code editor, started in 2013. I used this as my primary code-editor for a long time, and the thing that really set Zed apart (in my opinion) wasn't any particular feature, but rather the thoughtfulness with which the features were selected and combined. Very much a "the whole is greater than the sum of its parts" kind of situation. > > The best example of that, and the thing I loved most about Zed, really came down to these features in combination: > > \* Files are always auto-saved. > \* Opening a new file in a view simply closes the file that was there before. > \* All files have infinite, persistent undo. Even across closing the file or closing the entire editor. > \* Its hotkey-activated go-to-file dialogue, before typing any fuzzy-search terms, displays files in most-recently-opened order. > > Individually none of these are particularly unique or special. But combined, they really add up in terms of reducing the user's cognitive overhead: > > \* The only open files are the ones you can see. > \* You don't have to think about file/buffer state. (They're never "dirty", and views, undo stacks, cursors, etc. persist.) > \* The files you're currently working with are always at the top of the go-to-file dialogue. > > All of these things together free you from having to keep your editor's state in your head. Things like "what files do I have open?" or "what buffers are saved?" or "which files do I want to open in advance/keep open for what I'm working on right now?" etc. all just disappear, and you can focus on just coding. > > This was a brand new experience for me in Zed, and I have yet to experience it in any editor since. You can sort of get a similar experience via addons in editors like Sublime Text, VSCode, etc. But it never quite works right, and never fully relieves the cognitive burden in the same way. > > Again, none of these individual features are particularly special. It's just the way they were selected and combined that made Zed's UX really special. > > Having said all of that, Zed punted on some things in order to achieve this experience. For example, how do you handle temporary buffers that aren't associated with a file on disk? Or what if a file is really large and takes more than an instant to load/save? Etc. Zed just didn't address any of that. Nevertheless, I think there are some really cool ideas in there about how the code editing experience can be faster and less of a cognitive burden on the user. > > > \## \[Led\](https://github.com/cessen/led) > > Full disclosure: I wrote Led, and it's where Ropey originally came from. It's a super bare-bones editor, and is mostly useless (it doesn't even have search functionality!). > > However, one thing it's really good at is handling huge and weird files. For example, it can open a multi-gigabyte file that's all on one line, with word-wrapping on, and navigate and edit it buttery-smooth. As far as I know, Led is unique in this ability (and I've tested a lot of other editors--certainly the well known ones). > > Part of this is due to Ropey, of course. If Ropey couldn't handle it, obviously Led couldn't. But it's also because of the following two things: > > 1. How Led tracks where your view is in a file. > 2. A small compromise in how Led handles line/word wrapping of very long lines. > > The end result is an editor that, despite being almost useless in every other respect, I still find myself regularly using. Especially for text files generated by software rather than people. > > If Helix is interested in being similarly robust, I'm happy to walk through how Led accomplishes this (and possibly help implement in Helix as well). The approach is absolutely compatible with a full-featured editor like Helix. But I also realize that editing weird files like that isn't Helix's primary use-case, so no worries either way. ---
**Author:** ![TeddyDD](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/teddydd/32/21_2.png) [@TeddyDD](https://discuss.kakoune.com/u/TeddyDD)\ **Post date:** [June 12, 2021, 8:43am UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/13 "2021-06-12T08:43:38Z")
> **[Lesser-Known-Terminal-Editors](https://codeberg.org/CoopCoding/Lesser-Known-Terminal-Editors)** > > Lesser-Known-Terminal-Editors ---
**Author:** ![skewballfox](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/skewballfox/32/455_2.png) [@skewballfox](https://discuss.kakoune.com/u/skewballfox)\ **Post date:** [June 30, 2021, 7:41pm UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/14 "2021-06-30T19:41:47Z")
I’m curious whether you know of any attempts to address this problem with ordered super sets? like instead of defining the parsing logic(or syntax structure) from scratch, you build them from smaller sets of syntaxes, and potentially assign them a priority (for establishing an order of ops, and/or handling conflicts). ---
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [July 2, 2021, 11:44am UTC](https://discuss.kakoune.com/t/a-survey-of-newer-terminal-editor-projects/1711/15 "2021-07-02T11:44:36Z")
I know that combining grammars is not practical in general, but I’m not sure of the exact mathematical limits of the problem.