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.
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!
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!
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.
> 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.
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).
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)
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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).
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.
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)`
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.
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. :)
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.
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!