31–40 of 51 posts
I've been learning a lot lately by following along with the development of xi[1], a new text editor written in Rust. Through reading that project's RFCs I've then come across other interesting projects, like swiobe[2] and wi[3]. What are the other canonical resources on this topic? It feels like tons of the interesting thought is scattered around various blogs and usenet posts and the like. I'd love to create a nice…
Kakoune[1] has been posted recently here on HN to great reception. As a C++ developer, I think it has a very high quality codebase, especially considering how non-trivial it is. As a user, it's been my main text editor for over a year. It also has a vibrant community, jump in on IRC if you have questions or ideas. [1] https://github.com/mawww/kakoune
Earlier quoted context omitted.
I believe Rust is too young a language to replace C in Emacs. I'd be happier if it was a standardised, time-tested language with a large user base and lots of docs.
Rust is standardized with lots of docs. The rest two will come with time.
I've been learning a lot lately by following along with the development of xi[1], a new text editor written in Rust. Through reading that project's RFCs I've then come across other interesting projects, like swiobe[2] and wi[3]. What are the other canonical resources on this topic? It feels like tons of the interesting thought is scattered around various blogs and usenet posts and the like. I'd love to create a nice…
https://sourceforge.net/p/joe-editor/mercurial/ci/default/tr...
I once build a text editor using a rope[1] data structure where every line was a node. The tree was augmented[2] with information about line numbers, titles in the document... for very fast navigation. I don't think primitive data structures like a gap buffer are useful anymore. They come from a time where saving on memory was more important than it is now. EDIT: I forgot it was also a self balancing tree! Very cool…
A dissent: Saving memory isn't strictly orthogonal to editing performance. A paged gap buffer (as described with an array index) remains ideal when you need to make a small number of surgical changes (insertions, deletions, etc) to a very large file, especially given the fact that all modern systems have page mapping hardware, so anything you implement is effectively on top of a paged gap buffer anyway. What we're re…
Earlier quoted context omitted.
Looks great on my phone. Symantic HTML is responsive by default.
It's a bit awkward to read on large screens. Long lines and whatnot
For years and years and years I always had a half-screen-width browser window, precisely because it's easier to read text that way. But then site authors started assuming that I'd have a full-width window, and using CSS to waste half the window width.
I still think that the correct response to 'window too wide' is 'shrink the window,' but it's a losing battle.
Earlier quoted context omitted.
Kakoune[1] has been posted recently here on HN to great reception. As a C++ developer, I think it has a very high quality codebase, especially considering how non-trivial it is. As a user, it's been my main text editor for over a year. It also has a vibrant community, jump in on IRC if you have questions or ideas. [1] https://github.com/mawww/kakoune
I think getting Kakoune UI support into Xi would be a very interesting project…
Earlier quoted context omitted.
I think getting Kakoune UI support into Xi would be a very interesting project…
Are you talking about Xi as a frontend for kakoune? If it's the UI part that you're interested in, there is also kakoune-qml[1] made by one of the regular uses. [1] https://github.com/doppioandante/kakoune-qml
Earlier quoted context omitted.
It's a bit awkward to read on large screens. Long lines and whatnot
> It's a bit awkward to read on large screens. Long lines and whatnot For years and years and years I always had a half-screen-width browser window, precisely because it's easier to read text that way. But then site authors started assuming that I'd have a full-width window, and using CSS to waste half the window width. I still think that the correct response to 'window too wide' is 'shrink the window,' but it's a lo…
Earlier quoted context omitted.
A dissent: Saving memory isn't strictly orthogonal to editing performance. A paged gap buffer (as described with an array index) remains ideal when you need to make a small number of surgical changes (insertions, deletions, etc) to a very large file, especially given the fact that all modern systems have page mapping hardware, so anything you implement is effectively on top of a paged gap buffer anyway. What we're re…
How would a gap buffer handle distributed editing operations like search-and-replace, or multi-cursor typing? The data structure seems optimized for editing in one place at a time.
A paged gap buffer is actually more like a tree, so instead of a single gap in the middle of a file, you have a gap in the middle of a block, and one block mapped per modified space. Cost of insert/delete is limited to the cost of a memmove within a block (cheap!), and your extent map never grows beyond 2x the number of changes. These upper bounds are incredibly good for edits, and there are only pathological cases that do better.
But what about search?
Search is faster too! Because virtual memory has your entire file contiguous, a search is as fast as a scan[1], which might embolden you to try indexing your file, which might really impress your users.
[1]: https://en.wikipedia.org/wiki/Rabin%E2%80%93Karp_algorithm