Show HN: Iota – a text editor written in Rust(github.com)
github.com
Show HN: Iota – a text editor written in Rust
https://github.com/gchp/iota
10 comments
Back when I was learning to program with Java 1.0 (using the AWT, no Swing) I made a text editor that supported syntax highlighting. My first big mistake was to open my text editor's source code with my fledgling text editor and attempt to make a minor tweak, only to discover that saving had a bug and wiped out my entire program.
No I did not have any source control at the time. I just started over.
No I did not have any source control at the time. I just started over.
Thanks for checking it out!
> Text editors to me (a web programmer) look too intimidating to build from scratch.
Honestly, this was my thinking too before I started working on one! I, like you, work primarily on web applications and I had never really worked on "lower level" projects. I have always wanted to build a text-editor, though I thought it was much too big a task and didn't know where to even start.
Because of my background in web programming, I was most comfortable with Python and JavaScript. There were a couple of popular editors out there built with JS, (mainly brackets [0]) so I decided to try read through their source code. This helped a lot. Reading source code that I understood, or atleast could make a guess at understanding. I did some research into how brackets was built and found this sort-of useful architecture video [1].
Then, I heard about the Go language, and by accident came across a project called Vigo[0] which is a Vi clone written in Go. The codebase was pretty small, and I was able to easily implement a command for the editor and contribute it. From there I just spent as much time as I could in reading source code of different editors, and comparing them to eachother. Asking myself questions like "How does Vim handle buffers compared to Emacs?" - I have no idea, so I'd go look it up. It could take weeks to get an answer, and sometimes I couldn't figure it out. But I defintely learned Something in doing the research!
I also did some reading from the authors of popular editors like Stallman (Emacs)[3] and Pike (Acme)[4]
When I started building one of my own, I still didn't really (And still dont!) know what I was doing. If you look at the early commits of the project you'll see me totally rewriting pieces over and over until as I figured out better ways of doing it.
I wish I could point you to a single resource that helped me, but it was really a bunch of things that I did over time that helped me. I still don't know much about editors, and I'm sure there's people who can do a much better job than me, but I'm having fun doing it! And I think thats the most important part. Have fun in researching editors (or whatever you decide to build). If you're interested in it, it makes even the most boring and difficult ideas fun to work with. Feel free to reach out to me too if you need help, I'm happy to share what I've learned so far!
sidenote: I didn't know Rust before I started writing Iota, which made things even more interesting ;)
[0]: https://github.com/adobe/brackets [1]: https://www.youtube.com/watch?v=xm9kSWZyawg [2]: https://github.com/kisielk/vigo [3]: https://www.gnu.org/software/emacs/emacs-paper.html [4]: http://plan9.bell-labs.com/sys/doc/acme/acme.html
> Text editors to me (a web programmer) look too intimidating to build from scratch.
Honestly, this was my thinking too before I started working on one! I, like you, work primarily on web applications and I had never really worked on "lower level" projects. I have always wanted to build a text-editor, though I thought it was much too big a task and didn't know where to even start.
Because of my background in web programming, I was most comfortable with Python and JavaScript. There were a couple of popular editors out there built with JS, (mainly brackets [0]) so I decided to try read through their source code. This helped a lot. Reading source code that I understood, or atleast could make a guess at understanding. I did some research into how brackets was built and found this sort-of useful architecture video [1].
Then, I heard about the Go language, and by accident came across a project called Vigo[0] which is a Vi clone written in Go. The codebase was pretty small, and I was able to easily implement a command for the editor and contribute it. From there I just spent as much time as I could in reading source code of different editors, and comparing them to eachother. Asking myself questions like "How does Vim handle buffers compared to Emacs?" - I have no idea, so I'd go look it up. It could take weeks to get an answer, and sometimes I couldn't figure it out. But I defintely learned Something in doing the research!
I also did some reading from the authors of popular editors like Stallman (Emacs)[3] and Pike (Acme)[4]
When I started building one of my own, I still didn't really (And still dont!) know what I was doing. If you look at the early commits of the project you'll see me totally rewriting pieces over and over until as I figured out better ways of doing it.
I wish I could point you to a single resource that helped me, but it was really a bunch of things that I did over time that helped me. I still don't know much about editors, and I'm sure there's people who can do a much better job than me, but I'm having fun doing it! And I think thats the most important part. Have fun in researching editors (or whatever you decide to build). If you're interested in it, it makes even the most boring and difficult ideas fun to work with. Feel free to reach out to me too if you need help, I'm happy to share what I've learned so far!
sidenote: I didn't know Rust before I started writing Iota, which made things even more interesting ;)
[0]: https://github.com/adobe/brackets [1]: https://www.youtube.com/watch?v=xm9kSWZyawg [2]: https://github.com/kisielk/vigo [3]: https://www.gnu.org/software/emacs/emacs-paper.html [4]: http://plan9.bell-labs.com/sys/doc/acme/acme.html
The definitive book on implementing an EMACS, as of a long time ago, is Craig A. Finseth's The Craft of Text Editing -or- Emacs for the Modern World http://www.finseth.com/craft/
Although I can't say I used it for my work on various versions of EMACS in the '80s, I just dived into code. But everything I read in it (or its first version, I think his bachelors thesis polished into a technical memo or the like) sounded right.
As for what to do now ... well, buffer implementation tradeoffs are different, maybe ones other than buffer gap should get another look.
This is also worth looking at http://www.finseth.com/emacs.html and has a literature section.
ADDED: ah, I see tatterdemalion mentioned it elsewhere in this thread.
Although I can't say I used it for my work on various versions of EMACS in the '80s, I just dived into code. But everything I read in it (or its first version, I think his bachelors thesis polished into a technical memo or the like) sounded right.
As for what to do now ... well, buffer implementation tradeoffs are different, maybe ones other than buffer gap should get another look.
This is also worth looking at http://www.finseth.com/emacs.html and has a literature section.
ADDED: ah, I see tatterdemalion mentioned it elsewhere in this thread.
This is an absolutely awesome answer, and in the best tradition of old school hackers. This is why open source rules.
If you have some time - would you mind writing a high level overview of architecture/design choices that go into writing an editor?
If you have some time - would you mind writing a high level overview of architecture/design choices that go into writing an editor?
Sure, I could give it a go!
I've been thinking about writing a few articles on my experiences so far in writing the editor. Sorta covering what I wrote above. I could definitely work in some stuff on architecture and design choices. When I get around to it, I'll post it on my blog, and most likely submit it here too. Hopefully you'll find something useful in it!
I've been thinking about writing a few articles on my experiences so far in writing the editor. Sorta covering what I wrote above. I could definitely work in some stuff on architecture and design choices. When I get around to it, I'll post it on my blog, and most likely submit it here too. Hopefully you'll find something useful in it!
Thats a lot for the excellent answer, Greg! Really appreciate it :)
I fat-finger down-voted you. Sorry.
I upvoted purely because I saw your comment: so now the balance is restored :-)
Since he had intended to upvote but is now back at net zero, I have applied a proxy upvote.
Replying to a comment removes your vote on it, so you've put him at net +1.
I really hope that's not true. This is not Slashdot.
Any reference for that?
Any reference for that?
I took one off to restore the natural mistake.
[deleted]
For a cool introduction to the internals of text editors I always recommend finding the old docs for the LCC-Win32 compiler. That compiler comes with it's own IDE, and the author (Jacob Navia) did a great job of candidly documenting his mental process while developing the editor. I know the documents are kind of hard to find, so feel free to get it from my Google Drive: https://drive.google.com/file/d/0BxF_x9mBC-n1Q0VnR3BpN21iWmc...
This document is great, it explains the internals of not just the editor but some of the compiler/linker as well. It's a shame that it was removed from newer versions of the documentation package.
This document is great, it explains the internals of not just the editor but some of the compiler/linker as well. It's a shame that it was removed from newer versions of the documentation package.
Cool! Spent some time reading this last night, its very interesting. Hope to get more time in the coming days to read more of it. Thanks for sharing!
Don't wait! :)
AFAIK, there are no more planned syntactic changes before 1.0. (just library changes and some minor semantic changes)
Also, with Rustup (http://doc.rust-lang.org/guide.html#installing-rust), it is very easy to stay current with the latest rust.
With the holidays coming around the corner, now is the perfect time to dive in!
AFAIK, there are no more planned syntactic changes before 1.0. (just library changes and some minor semantic changes)
Also, with Rustup (http://doc.rust-lang.org/guide.html#installing-rust), it is very easy to stay current with the latest rust.
With the holidays coming around the corner, now is the perfect time to dive in!
> AFAIK, there are no more planned syntactic changes before
> 1.0.
I second this 100%! Jump in, you won't regret it! The rust guide is a great place to start: http://doc.rust-lang.org/guide.html
The folks on the IRC channel are supper helpful too. Don't be afraid to ask!
The folks on the IRC channel are supper helpful too. Don't be afraid to ask!
This[1] emacs inspired editor, written in Go, also uses termbox (pure go port: https://github.com/nsf/termbox-go) - great little library.
I'm rewriting a python command line utility using it and it makes writing text based interfaces much easier.
[1] https://github.com/nsf/godit (screenshot: http://nosmileface.ru/images/godit-linux1.png)
I'm rewriting a python command line utility using it and it makes writing text based interfaces much easier.
[1] https://github.com/nsf/godit (screenshot: http://nosmileface.ru/images/godit-linux1.png)
I actually contributed quite a bit to a fork of godit called vigo [0]. It gave me lots of insight into how text editors work.
When I went to start writing Iota, I found that there was no termbox-type library in Rust, so I created a wrapper [1]. My goal is to create a pure-Rust version, similar to termbox-go. It's a long way from that, but it will get there!
[0]: http://github.com/kisielk/vigo [1]: http://github.com/gchp/rustbox.
When I went to start writing Iota, I found that there was no termbox-type library in Rust, so I created a wrapper [1]. My goal is to create a pure-Rust version, similar to termbox-go. It's a long way from that, but it will get there!
[0]: http://github.com/kisielk/vigo [1]: http://github.com/gchp/rustbox.
Cool! So, you're a perfect position to compare your experiences writing text editors in both languages :)
(Although Go is more mature at this point)
(Although Go is more mature at this point)
I guess you could say that!
I initially found it much harder to work with Rust, as the language is more strict in a number of ways. But once I began to understand how it works, and began to grasp some of its concepts such as ownership and lifetimes I found it much more powerful than Go.
Go has a larger community right now, many more libraries and resources openly available. That's probably one of Rust's downsides right now however its catching up, especially with the launch of crates.io. I don't think it will be long in maturing following the 1.0 release.
Saying that, both are enjoyable to work with. But for me Rust wins out!
I initially found it much harder to work with Rust, as the language is more strict in a number of ways. But once I began to understand how it works, and began to grasp some of its concepts such as ownership and lifetimes I found it much more powerful than Go.
Go has a larger community right now, many more libraries and resources openly available. That's probably one of Rust's downsides right now however its catching up, especially with the launch of crates.io. I don't think it will be long in maturing following the 1.0 release.
Saying that, both are enjoyable to work with. But for me Rust wins out!
Well, I had an implementation of termbox for `bisschen` (a mail viewer on top of notmuch), but that was pre-cargo and I don't work on it anymore:
https://github.com/skade/bisschen/tree/master/src/libtermbox
https://github.com/skade/bisschen/tree/master/src/libtermbox
Makes me think, when guile-emacs will be done, rust will be mature enough so we (by we I mean they) can rewrite emacs c core in it.
What's the advantage of using the limited termbox interface over (n)curses, or just using the low-level terminfo library directly?
Termbox can be implemented on non-POSIX platforms, whereas terminfo/termcap do not. See https://github.com/nsf/termbox-go which runs on Windows.
NB: The C implementation doesn't support Windows, AFAIK, which means this Rust library doesn't either, at least as long as it is based on bindings and not a pure Rust implementation of termbox.
NB: The C implementation doesn't support Windows, AFAIK, which means this Rust library doesn't either, at least as long as it is based on bindings and not a pure Rust implementation of termbox.
This is cool & similar to a project I had thought about doing for a while. Have you read The Craft of Text Editing[1]? It's very informative.
[1]: http://www.finseth.com/craft/
[1]: http://www.finseth.com/craft/
I haven't, this is the first time I've heard of it. Will definitely check it out though, thanks!
A text editor writing itself makes me think of M.C. Esher's 'Drawing Hands' http://en.wikipedia.org/wiki/Drawing_Hands
Great work, thank you. I was awaiting for something like this for a while. Thanks for sharing.
As a side note: In the long term what I would really love to see - is Rust GUI for Neovim[1] (embedded library / service). Thus I would be able to both hack around my editor and get VIM's maturity and experience most of the times.
[1]: http://neovim.org/
* Update *: spelling and formatting
As a side note: In the long term what I would really love to see - is Rust GUI for Neovim[1] (embedded library / service). Thus I would be able to both hack around my editor and get VIM's maturity and experience most of the times.
[1]: http://neovim.org/
* Update *: spelling and formatting
Thanks! It's still very much a work-in-progress, but I like it so far. Plus its been really fun writing it.
[deleted]
I don't get what a Rust GUI would give you, in this case?
Nothing besides convenience. As a rule of thumb I would love to have editor I find suiting my needs and ideally it would be easy to me to contribute/adjust it to my needs.
Regarding [Neo]Vim - I don't think core is something I would touch a lot. Most likely UI/GUI stuff and plugins (vimscripts etc ..). Due to the nature of vimscripts I would prefer to hack around it in something like Python, Lua or Rust.
My personal subjective judgement:
- Disclaimer: I'm mostly Java, C#, Python developer
- I find C++ codebase too hard to follow and understand. I like C, but it lacks syntax sugar etc...
- I find Rust promising (hopefully it's something I will be able to read relatively easy and hopefully it would be easier to reason about,especially in regard to memory management).
Regarding [Neo]Vim - I don't think core is something I would touch a lot. Most likely UI/GUI stuff and plugins (vimscripts etc ..). Due to the nature of vimscripts I would prefer to hack around it in something like Python, Lua or Rust.
My personal subjective judgement:
- Disclaimer: I'm mostly Java, C#, Python developer
- I find C++ codebase too hard to follow and understand. I like C, but it lacks syntax sugar etc...
- I find Rust promising (hopefully it's something I will be able to read relatively easy and hopefully it would be easier to reason about,especially in regard to memory management).
[deleted]
You say on the readme:
"Iota was born out of my frustrations with existing text editors. Over the years I've tried combinations of simple text editors, IDEs and everything in between. None of them felt right to me, however. Some were too slow & bulky, others were too difficult to customise and still others were platform specific and I couldn't use them on all my machines."
So what is the advantage if Iota over Vim?
"Iota was born out of my frustrations with existing text editors. Over the years I've tried combinations of simple text editors, IDEs and everything in between. None of them felt right to me, however. Some were too slow & bulky, others were too difficult to customise and still others were platform specific and I couldn't use them on all my machines."
So what is the advantage if Iota over Vim?
That could be useful when you need an editor in a secure environment. Rustbox, though, still uses C code.
A reasonable goal is to re-implement the utilities in Busybox in Rust. Lots of embedded systems use Busybox, and it has vulnerabilities.
A reasonable goal is to re-implement the utilities in Busybox in Rust. Lots of embedded systems use Busybox, and it has vulnerabilities.
Its true that Rustbox uses C code right now. Its just a wrapper around the original termbox library. My goal for rustbox is to be a full Rust port of termbox, removing the reliance on C. Hadn't heard of busybox, will check it out. Thanks!
There's a core-utils in rust repo https://github.com/uutils/coreutils
Would totally love to build a side-project like this! Thanks!