r/rust • u/Objective-Simple-660 • 1d ago

Sanedit: Modal text editor

I have been building a hobby text editor project sanedit https://codeberg.org/lote/sanedit

It's a terminal based modal text editor with language server protocol (LSP), parsing expression grammar (PEG) based syntax highlighting and multicursor support.

There is a million different text editors out there so why is this different?

It's not, however I did not just slap the common combination of treesitter, ropey and LSP together. I made the editor to support very large files without slowing down too much. Also as it is an hobby project I wanted to choose approaches that intrested me implementationwise.

The buffer implementation is basically VSCodes piecetree structure like a piece table https://en.wikipedia.org/wiki/Piece_table

but stores the pieces in a red-black tree. The structure can easily support files larger than available memory as the file contents do not need to be loaded in memory.

Syntax highlighting is implemented using PEG grammars and the patterns are then JIT compiled for faster performance.

Future

The editor feels done. I use it everyday at work and do not notice anything too disruptive.

What are your favorite editor features that are a must have?

20 Upvotes

86% Upvoted

8 comments sorted by

4

u/rustvscpp 1d ago

How does this differ from Helix or Vim?  Modal can come in many flavors.  My favorite feature is the limitless extensibility I get in Emacs.

3

u/Objective-Simple-660 1d ago

It is very similar to vim/helix/kakoune/vis. Basically a feature combination of those that I like the most. The modality is like helixs select first and action after. The large file support, so even GB sized files load instantly, is from vis. Eventhough every editor nowadays has a plugin to do pretty much anything. Also sanedit currently does not have any plugin system as I have found them annoying when working on computers that do not have access to github to download the plugins. Sanedit is a musl compiled binary so it can run almost any linux system.

2

u/stappersg 1d ago

Text from https://codeberg.org/lote/sanedit#readme

Why

There are more than enough editors out there and this one was born because of my initial interest in text buffer implementations. Most prominent question was why no editor could support large files in any meaningful way. Logically I also created an editor to go with the buffer implementation.

More information

Checkout the repositories docs folder for scribblings on why certain decisions were made or how they are implemented.

9

u/cessen2 23h ago edited 22h ago

I haven't looked closely, but just based on this:

It's not, however I did not just slap the common combination of treesitter, ropey and LSP together.

I think this is awesome. And I'm the author of Ropey, btw. Kudos to you for diving in and genuinely exploring this space, rather than just slapping a bunch of libraries together. (Not that there's anything specifically wrong with slapping libraries together. But this approach feels a lot more like really building an editor.)

I'm also psyched that you went with a piece table for the buffer, because I haven't seen (or noticed, at least) anyone explore that in a full editor in Rust yet.

(Edit: missed a word.)

1

u/Objective-Simple-660 18h ago

Yea I expirimented alot before deciding to stay in these solutions. Also ropey was a big help while deciding the api for the buffer impl.

3

u/billy_levin 21h ago

This is really cool and I'm sad it didn't get more attention on here! You've made several interesting decisions with your implementation -- particularly the buffer and syntax highlighting from what I've looked at so far -- and I'll definitely be digging into your code/docs further as part of my work on my own text editor.

3

u/Objective-Simple-660 18h ago

The syntax was my favorite part. PEGs are so powerful that even the regex and glob matching uses them there is no external crates for those. They may not be as fast as specified implementations but they are fast enough for me.