Zee: A modern text editor for the terminal written in Rust | Hacker News Reader

Zee: A modern text editor for the terminal written in Rust

github.com

143 pointssiraben85 comments

Looks nice. I do like tui editors, I like new editors, I like the "promise" of speed / rtc that comes with rust. I like new and interesting ways of doing things

This looks to be a hobby project, and it looks very professional and presentable, so good work! I like it!

But if you wanted to entice me to download and try it, I'd argue you have to give me something new. I would prefer more reasoning about why things are the way they are (keybinds are done because X). I'd prefer something that can be hacked upon (vim, Emacs, kak, etc all have scripts). I'd prefer something different (the entire window has physic simulation and typing too fast causes a massive loading force on the indents). Etc.

But this is your project, do what you want! well done!

Not the author, but you can hack on it - you just have to install Rust!

Another editor worth mentioning here is Micro (https://micro-editor.github.io/), written in Go, which is also a TUI editor, is hackable not only because open source but also in the sense you mentioned (with plugins written in Lua), and (exceptionally for a TUI editor) it has the "usual" default keybindings that all of us non-Vim and non-Emacs diehards are accustomed to (Ctrl+S for save, Ctrl+F for find etc. etc.).

Last time I tried micro as an alternative to vi, it didn't even implement search and replace. I find most of those alternatives quiet heavy and featureless compared to vi.

fwiw the current Micro (2.0.10) certainly has these...<Ctrl-f> for search, 'replace' [search] [value] [flags]' and 'replaceall [search] [value]'.

An issue with micro is, that you can’t use the mouse to select, copy, and paste text when SSHing in from a Windows host (easily). I never bothered to read up on why this is an issue for Micro but not Nano, but something is done different.

One thing I'd love to see, is a TUI editor that focuses on providing hooks for developers to build deeper integration with various frameworks into the editor and it's autocomplete.

This is something I've wanted back when I was doing professional PHP development, when life was still in black and white. I still reckon it would be useful today.

I started to build exactly that myself, in Nim, but got distracted building the editor itself and eventually moved on to other personal projects. Maybe I should revisit it.

An example, based on the current HN home page, would be htmx integration in HTML editing, that is aware of the rest of your project and how htmx works to give excellent, powerful autocomplete within your bindings. Maybe even have it be able to be aware of the backends route set!

> One thing I'd love to see, is a TUI editor that focuses on providing hooks for developers to build deeper integration with various frameworks into the editor and it's autocomplete.

But... Don't they already do that? I am a daily vim user and there is a million plugins that were created using those "hooks" you talk about. I guess that's the case with emacs too.

Just two days ago I jumped into a huge bazel project and needed a good way to navigate through 100s of files that are connected through @funny//labels/across/directories/and.files. By only reading vim's :help, I was able to write that 10lines of code which hooks into the existing "go-to-file" or "find-where-this-is-defined" functionality.

(In fact, after "implementing" this feature, I was wondering how I'd do this as a user (not as a plug in author) in any other editors.)

Vim and Emacs are the closest, but not quite what I had in mind either -- LSPs get closer, though have issues with mix-mode files (as does nearly every editor really). I have a design doc I wrote up somewhere, I should dig it out.

It was borne specifically out of my difficulty extending Vim to do what I was after when working with PHP frameworks!

Vim is amazing.

Consider taking a look at: https://orbitalquark.github.io/textadept/. It's a rather "old kid on the block" actually, it's quite minimal ("Relentlessly optimized for speed and minimalism over the years, the editor consists of less than 2000 lines of C code and less than 4000 lines of Lua code") and it is crazy extensible; actually in my experience trying it, I found it too much extensible - it was too easy for me to break it while trying to configure it. Anyway, IMO it's a project definitely worth taking a look at. (Note: if it's not immediately obvious from the website, it does have a terminal UI version.)

Indeed, Textadept was one of my go-to editors for this, and scripting it in Lua was fantastic! But again, it's not quite what I am after, and I'm obviously explaining it badly :)

Basically, I'd like the editor to understand the AST of the language(s, including mixed-language files, which is really hard) and be able to hook into parts of that AST to say "while this is a string, it's really this weird DSL that hooks into Javascript, so look for symbols here, here and here".

Its definitely possible to make Vim, Emacs and TA work this way, but its a lot more work than I had in mind, when I tried to extend them (well, not Emacs. It might be best at this, I'm just not a good emacs user) to achieve what I was after at the time, which was understanding the dependency injection annotation patterns from Symfony in PHP.

I think one could get pretty close with LSPs and the powerful AST parsers we have nowadays. Though doing it fast might be difficult!

See also: Lite, written in C and Lua https://news.ycombinator.com/item?id=23126458

I use the lite-xl fork https://lite-xl.com/

Shouldn't autocomplete be provided by LSP these days? It's an interoperable framework, so you can implement it just once for your preferred language/workflow and then just use it anywhere.

> One thing I'd love to see, is a TUI editor that focuses on providing hooks for developers to build deeper integration with various frameworks into the editor and it's autocomplete.

Neovim?

> One thing I'd love to see, is a TUI editor that focuses on providing hooks for developers to build deeper integration with various frameworks into the editor and it's autocomplete.

Sounds like emacs in text mode

I think a lot of these new text editors would be well served by making it easy to set emacs/vi/windows keyboard shortcuts if they're trying to reach a wider audience. Once their value is established then the people using them would be more likely to move to the native keyboard shortcuts. I'm talking about switch a flag like "shortcut_keys_config=vim" not setting a hundred shortcuts manually :)

Even though I am a fan of emacs keybindings, a really good example of this is when launching spacemacs for the first time where it prompts the user if they want Evil mode (vi keybindings) or Holy mode (emacs keybindings).

Just look at the readme. It says 100 FPS. Vim isn't even close to that, and Vim sucks with large files.

The only benchmark I could find is https://pavelfatin.com/typing-with-pleasure/#editor-benchmar... , showing GVim to be quite a bit better than that. For terminal Vim, terminal latency dominates.

That page doesn't list FPS at all.

What do you think FPS means in the context of a terminal text editor? The linked page is pretty clear in what the author means: “Cursor movement and edits render under 10ms”. So FPS = 1 / latency. The link I gave measures latency; < 10ms is > 100 FPS.

(Though I doubt the statement re: Zee < 10ms latency in practical terms. I think only xterm and Terminal.app are consistently below that in terms of pure terminal latency)

I said FPS, I didn't say latency. Please stop trying to argue against a point I'm not even making.

Fortunately, I don't type 100 characters per second.

Noob

As a British person, I love that two of the editors written in Rust are now called Zed [1] (how we pronounce 'z') and Zee (how Americans pronounce 'z') respectively.

[1]: https://zed.dev/

As a Kiwi, I am eagerly awaiting an editor written in Rust called Zid.

But you would still spell it "Zea" ...

And the neat part is that the Zed authors created Tree-Sitter, which Zee uses!

- Whose motorcycle is this? - It's a chopper, baby. - Whose chopper is this? - It's Zed's. - Who's Zed? - Zed's dead, baby. Zed's dead.

hah I thought that Zed had actually released and this was that

There's also Helix, a Vim/Kakoune-inspired text editor written in Rust: https://github.com/helix-editor/helix

Big fan of Helix and Kakoune-esque keybindings! I like that they have tree-sitter and LSP as first class citizens, both extremely nice.

I hope they figure out the plugin system, but honestly, if they'd just add something like Telescope(an absolutely amazing neovim plugin), I'd be more than happy enough.

I think there is something like Telescope, e.g. when you hit <space>-f to find files.

Ha, writing a minimalist editor is one of my "hello world" tasks and I've been meaning to redo it in Rust as so many things would be much easier than in C.

The major thing I would want differently, breaking tradition from emacs is not waste the bottom two lines for modeline and a usually-empty prompt line and instead only show it on demand. Emacs can sort of do this, but in my experience, it doesn't work very well.

ADD: I know some HNers feel there's too much Rust here, but let me just add how I love that I can do `cargo install zee` on macOS, FreeBSD, and Linux (AMD64, Arm64, RISC-V) and it just works. Cargo is my favorite package manager (where available).

Can I please keep all my Emacs workflow and packages but have something faster? Please?

Are you on Emacs 28? Native-comp is enabled by default and it's Just Worked™ for me. Or are you on at least Emacs 27? Emacs 27 added native JSON parsing; stuff like lsp-mode works a lot better now.

(Personally running Emacs 29 built from source on an M1 Pro; everything is instant! Even on my old dumpy i5 machine, everything except startup was pretty snappy, with the exception of startup which took ~4 seconds.)

If it's startup you're concerned about, try the esup[1] package to figure out what's taking so long.

[1]: https://github.com/jschaf/esup

I am on latest Emacs master with native-comp enabled on a i7 32GB machine. While generally it is fast, it is not fast enough for me for things like editing with LSP enabled. After like an hour of LSP mode on, it becomes jarring and I need to restart it.

Give the feedback to your language server processor, probably not an emacs bug.. might be.. but i think you need to measure, you might be blaming your editor when its not.

I use to have this problem as well. It turns out that I had set

    (setq lsp-print-io t)

while debugging a configuration problem. That setting was basically filling up a buffer with _enormous_ amounts of text. I guess that appending frequently to that massive buffer slowed things to a halt.

After disabling this, LSP inside emacs has been flawless.

Just use a persistent Emacs server and forget about startup profiling.

If your Emacs is slow then there is probably something wrong with your config that can be fixed. When do you notice it being slow?

Have you tried using the gcmh package? I'd gotten emacs 28 snappy and without performance issues on my desktop, but laptop was still laggy; gcmh with auto set fixed it for me.

Please add binary to releases on github. Probably most of the users won't be Rust devs with cargo already available in path.

The README sounded very good, until

> The following keybindings are available:

Sigh. Could software please stop being so opinionated when it comes to keybindings? Let me configure my own keybindings please. Emacs bindings are terrible for people suffering from RSI and the like.

So the next time I ssh into a machine, fire up vim and `dd` to delete a line I find myself cooking coffee because the admin thought that would be the right thing to?

Your keybindings and the admin's keybindings don't have to be the same. Also yes as someone with RSI I will bother syncing those bindings to every machine I work on because if I don't I will experience physical pain.

Should all software come with no assigned key bindings? I think it is good to have a list of existing key bindings, so that you can start using the software without guessing which keys you need to hit. The don't-know-how-to-quit-vi-jokes are very old by now.

And there's probably some way you can configure the key bindings to your liking.

> And there's probably some way you can configure the key bindings to your liking.

AFAICT there is no such way, hence my original comment.

> Should all software come with no assigned key bindings?

Personally, I find it very annoying having to re-bind all the keys to my liking / to what I'm used to whenever I start using a new piece of software. But to answer your question: Probably not. Most people seem to be happy to go with whatever are the default keybindings, so I guess it works for them.

evil mode is a lifesaver in emacs :)

I see a bunch of editors using ropes. Are they in any way superior to RRB trees? My gut tells me no, but ai might be missing something.

Pragmatically, there is a nice rust crate that implements a rope [1]. I think that has a lot to do with it. And it is a nice data structure for editors.

[1] https://docs.rs/ropey/latest/ropey/

Of course. The rrb tree implementation in im.rs handles inserts in a way that might lead to the same problems of ropes, but without doing any rebalancing.

That would make it unsuitable for text editor usage.

Are there any accessible explanations of RRB trees? I tried implementing them a while ago but all I could find was a something-hundred pages thesis and a paper with some Scala code that I didn't fully grasp ;)

The simple explanation is "take the bit partitioned immutable vectors and relax the leftwise dense requirement" and then sprinkle some magic implementation dust in between that and the finished implementation.

On a more serious note: the only complex piece of code to write is the merge and split operations, but since the structure of the tree is given it isn't theoretically hard. It is just a pain in the ass.

There are two high quality implementations. One for c++ (immer) and the one in scala.

Bagwell did a talk about it on YouTube as well.

Those new editors gross like weed. Every month there is a new shiny one which promises to be the new vim.

What makes this a “modern” editor? When does it cease to be a modern editor?

One of these days I’m going to write a modern HN headline generator, in Rust!

Comments like these reminds me how huge number of vegan recipes went from word 'vegan' to 'plant based' because of omnipresent harassment. And I already saw Rust project here that instead of mentioning 'Rust' in title went for 'oxidized'.

I find the "Some New Non-Library Whatever Project, in Rust" annoying because it usually seems like being written in rust is the main selling point. It just comes of as more garish advertising from the Rust Evangelism Strike Force. I don't care if my editor is written rust or c or haskell or whatever. Does it offer advantages to my workflow that my current editor does not? I often reach for ripgrep because it's fast and has convenient defaults. That it happens to be written in rust is a footnote.

Of the Rust, by the Rust, for the Rust.

It seems like lately every new(ish) piece of software is labeled as modern, fast and simple.

Rust in peace.

https://github.com/mcobzarenco/zee#features

Stuff like use of tree-sitter seems neat.

"rust"

I guess because it's non-modal.

https://kakoune.org/ is modal, and imo it would be reasonable to call it modern.

Perhaps "modern" in the terminal editor space is just a codebase that does not have 30 years of cruft (where cruft may include various legacy support and fixes for subtle/obscure/legacy bugs).

Emacs isn't modal

Very cool looking editor. Even this vim diehard will give it a shot. I’m always looking for anything new or an improvement that could make life better.

I don’t love the emacs bindings but I’m open minded.

Again kudos to the author.

so ... Zee Emulates Emacs?

Supporting Emacs keybindings is like 1% of “emulating Emacs”.

Sure, but that makes the name Zeopoe, which isn't quite so snappy.

In rust!

I wonder where is the x86_64/elf bootstrap rust optimizing compiler written in rust (user space "profile" for now).

I love text editors. Can someone create one which can also work with the vs code extension API? I would pay for something like that.

You can sponsor CoC.

https://github.com/neoclide/coc.nvim

plugin support? pretty much required for accessibility reasons for me to try an editor

I wanted to give this a try but...

   Compiling zee-grammar v0.2.0 (/tmp/zee/grammar)                                                                                                               
   Compiling crossclip v0.7.0                                                                                                                                                         
   Compiling phf_codegen v0.8.0                                                                                                                                                       
   Compiling futures v0.3.17                                                                                                                                                          
   Compiling palette v0.5.0                                                                                                                                                           
   Compiling zi-term v0.2.0

The following warnings were emitted during compilation:

warning: cc: error: languages/tree-sitter-css/src/parser.c: No such file or dire ctory warning: cc: fatal error: no input files warning: compilation terminated. warning: cc: error: languages/tree-sitter-css/src/scanner.c: No such file or directory warning: cc: fatal error: no input files warning: compilation terminated.

error: failed to run custom build command for `zee-grammar v0.2.0 (/tmp/zee/grammar)`

Caused by: process didn't exit successfully: `/tmp/zee/target/release/build/zee-grammar-38a42fe479d4b0dd/build-script-build` (exit status: 1) --- stdout cargo:rustc-link-lib=static=tree-sitter-css TARGET = Some("x86_64-unknown-linux-gnu") OPT_LEVEL = Some("3") HOST = Some("x86_64-unknown-linux-gnu") CC_x86_64-unknown-linux-gnu = None CC_x86_64_unknown_linux_gnu = None HOST_CC = None CC = None CFLAGS_x86_64-unknown-linux-gnu = None CFLAGS_x86_64_unknown_linux_gnu = None HOST_CFLAGS = None CFLAGS = None CRATE_CC_NO_DEFAULTS = None DEBUG = Some("false") CARGO_CFG_TARGET_FEATURE = Some("fxsr,lzcnt,pclmulqdq,popcnt,rdrand,sse,sse2,sse3,sse4.1,sse4.2,ssse3") running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "languages/tree-sitter-css/src" "-Wall" "-Wextra" "-w" "-o" "/tmp/zee/target/release/build/zee-grammar-76ca683c42d5d7dd/out/languages/tree-sitter-css/src/parser.o" "-c" "languages/tree-sitter-css/src/parser.c" cargo:warning=cc: error: languages/tree-sitter-css/src/parser.c: No such file or directory cargo:warning=cc: fatal error: no input files cargo:warning=compilation terminated. exit status: 1 running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "languages/tree-sitter-css/src" "-Wall" "-Wextra" "-w" "-o" "/tmp/zee/target/release/build/zee-grammar-76ca683c42d5d7dd/out/languages/tree-sitter-css/src/scanner.o" "-c" "languages/tree-sitter-css/src/scanner.c"

Not interested enough... :/ Took long enough to compile with its ~260 dependencies. Each Rust project I want to cargo build, I end up fetching & compiling >200 dependencies (the same ones, not sure if different versions though), and then by the end of it all it fails.

I am going to rm -rf it, I need the space anyways.

you probably forgot to init the git submodules: https://github.com/mcobzarenco/zee#building-from-source

Rust is the new Javascript... (I am joking)

anyone have a link to hackernews .. but in rust? thanks

Looks cool but Zee is a registered trademark and it operates TV channels, OTT platform in India. May be check this again because you shouldn't get into any troubles in the future. :)

Most trademarks only apply to a given, well, trade. These are specified when filing for a trademark.

For example, the Unix line of washing solutions (http://www.washing-solution.de/en/washing-machines/unix/ ) and the Unix line of curtains (https://www.kvadrat.dk/en/kinnasand/products/curtains/6704-u...! ) and the Unix line of liquid chromatography products (https://www.sepax-tech.com/Unix.php ) do not infringe on the Unix trademark related operating systems.

According to TESS, the US trademark search system, Unix in the category "IC 009. US 021 023 026 036 038. G & S: COMPUTER PROGRAMS, * NAMELY, TEST SUITES USED TO DETERMINE COMPLIANCE WITH CERTAIN SPECIFICATIONS AND STANDARDS *. FIRST USE: 19721214. FIRST USE IN COMMERCE: 19721214"

There is no trademark conflict to use that term for a far different product or service area.

FWIW, TESS says the following are three of the many existing trademarks for "Zee" in the US:

"IC 009. US 021 023 026 036 038. G & S: Camera hardware systems for IP (Internet protocol) video surveillance; IP (Internet protocol) cameras. FIRST USE: 20130809. FIRST USE IN COMMERCE: 20130809"

"IC 041. US 100 101 107. G & S: Educational services, professional educational orientation services, organization of expositions with educational or cultural purposes"

"IC 009. US 021 023 026 036 038. G & S: Portable chargers, namely, batteries with multiple ports for charging electronics; Portable power station, namely, batteries with multiple ports for charging electronic devices; Portable battery power station, namely, rechargeable batteries with multiple ports for charging electronics; Battery charge devices; Batteries, electric"

You'll notice they are in different areas of trade, hence no trademark conflict.

Maybe check out trademark law again. :)

Every word is a trademark somewhere.

Irrelevant not only because it's a foreign country but because it's two different fields (television channel vs. computer software).

Reply on news.ycombinator.com