3 ms·

This is really interesting! Is your editor written is Ruby then? Is the code hosted somewhere public? I am also curious what advantage you found in putting the

This is really interesting! Is your editor written is Ruby then? Is the code hosted somewhere public? I am also curious what advantage you found in putting the buffers in a separate process. Is it just that a crash in the front end doesn’t cause you to loose changes? Why not just save at regular intervals instead? Is the idea to persistent undo or file revisions? I am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch.

vidarh 4y ago
It's on github [1], but the version on github hasn't been pushed to in ages and is a mess because, well, I haven't really cared about making it work for anyone else, so not sure how useful it is to look at. It's an ugly mess, and frankly the one downside of doing a project like this is that it's a bit embarrassing to show people - since I'm the only user I only clean things up when the mess starts hampering me, and since the codebase is so small, that's rare (my current iteration, not the Github one) is about 3.3k, with about 1k of that being syntax-highlighting stuff I'd like to try to get upstreamed to Rouge) I started out with Femto [2] and ended up quickly gutting it (there's next to nothing left now), and as an example of a minimalist Ruby editor, Femto is perhaps a better starting point - it's certainly both cleaner and smaller. I've started breaking a bunch of functionality into gems (termcontroller, file_writer, ansiterm, editor_core, keyboard_map) of various stages of usability for others, and my goal is to over time eventually be left with the editor as a tiny shell around reusable components + my personal config, but as per this article, I plod along and fix the things most pressing to me personally and nobody else so who knows when that will happen. As long as it keeps being useful to me, that's what matters. In that respect it's also a meditative experience of sort that takes my mind off work and having to work in a more professional manner. > I am also curious what advantage you found in putting the buffers in a separate process. Is it just that a crash in the front end doesn’t cause you to loose changes? Why not just save at regular intervals instead? Is the idea to persistent undo or file revisions? I also save at regular intervals, so you're right that if that was the only consideration I probably wouldn't have bothered. But the editor is a terminal application, and I use a tiling window manager (bspwm), and so I figured that if I could spawn another editor instance and have my wm open it in the right space and with access to the same buffer, I didn't need the editor itself to have any understanding of windows itself. Here's "split_vertical" that opens a second view of the same buffer: def split_vertical(buffer_id) system("split-vertical 2>/dev/null term -e e --buffer #{buffer_id}") end [EDIT: Should also clarify here that "term" is a wrapper for whichever terminal I currently favour, at the moment mlterm, and "e" is an alias for my editor; if I ever were to try to make this usable for anyone else, there'd be a whole lot of cleanups to make - the biggest concession towards this I've made has been to recently move most dependencies on my environment into a separate file] split-vertical is a helper (I split out a handful of things that depends on external tools) that just runs "bspc node -p south" to get bspwm to halve the height of the current window and "swallow" the next window being opened into the space freed up below the active window, and then exec's its argument. So meta-2/meta-3 works roughly like ctrl-x+2/ctrl-x+3 in Emacs (EDIT: fixed; already forgetting the Emacs keybindings...), except the frames end up in their own windows, running their own client. Had remoting the buffers been a lot of work, I wouldn't have, but the the Drb specific part of the code is <100 lines and the combined effect of the resilience (if an exception is thrown in the server code, I get thrown into a Pry repl in the client) and the extra abilities it enables makes it worthwhile. Similarly, I've avoided implementing my own directory handling, and just farmed that out to a wrapper that currently uses rofi, same for theme selection (for syntax highlighting), buffer selection, etc. The minimalism of delegating all of these things elsewhere appealed to me. > I am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch. Strongly disliking Lisp was high on the list (I like the concepts; hate the syntax intensely). Also, it wasn't so much a limiting factor, as realising that my Emacs config file was larger than toy editors I'd played with in the past, and a minimalist bent making it appeal to me to go for something smaller. Also seemed fun (and has been) [1] https://github.com/vidarh/re https://github.com/vidarh/re [2] https://github.com/agorf/femto https://github.com/agorf/femto

vidarh 4y ago

It's on github [1], but the version on github hasn't been pushed to in ages and is a mess because, well, I haven't really cared about making it work for anyone else, so not sure how useful it is to look at. It's an ugly mess, and frankly the one downside of doing a project like this is that it's a bit embarrassing to show people - since I'm the only user I only clean things up when the mess starts hampering me, and since the codebase is so small, that's rare (my current iteration, not the Github one) is about 3.3k, with about 1k of that being syntax-highlighting stuff I'd like to try to get upstreamed to Rouge) I started out with Femto [2] and ended up quickly gutting it (there's next to nothing left now), and as an example of a minimalist Ruby editor, Femto is perhaps a better starting point - it's certainly both cleaner and smaller. I've started breaking a bunch of functionality into gems (termcontroller, file_writer, ansiterm, editor_core, keyboard_map) of various stages of usability for others, and my goal is to over time eventually be left with the editor as a tiny shell around reusable components + my personal config, but as per this article, I plod along and fix the things most pressing to me personally and nobody else so who knows when that will happen. As long as it keeps being useful to me, that's what matters. In that respect it's also a meditative experience of sort that takes my mind off work and having to work in a more professional manner. > I am also curious what advantage you found in putting the buffers in a separate process. Is it just that a crash in the front end doesn’t cause you to loose changes? Why not just save at regular intervals instead? Is the idea to persistent undo or file revisions? I also save at regular intervals, so you're right that if that was the only consideration I probably wouldn't have bothered. But the editor is a terminal application, and I use a tiling window manager (bspwm), and so I figured that if I could spawn another editor instance and have my wm open it in the right space and with access to the same buffer, I didn't need the editor itself to have any understanding of windows itself. Here's "split_vertical" that opens a second view of the same buffer: def split_vertical(buffer_id) system("split-vertical 2>/dev/null term -e e --buffer #{buffer_id}") end [EDIT: Should also clarify here that "term" is a wrapper for whichever terminal I currently favour, at the moment mlterm, and "e" is an alias for my editor; if I ever were to try to make this usable for anyone else, there'd be a whole lot of cleanups to make - the biggest concession towards this I've made has been to recently move most dependencies on my environment into a separate file] split-vertical is a helper (I split out a handful of things that depends on external tools) that just runs "bspc node -p south" to get bspwm to halve the height of the current window and "swallow" the next window being opened into the space freed up below the active window, and then exec's its argument. So meta-2/meta-3 works roughly like ctrl-x+2/ctrl-x+3 in Emacs (EDIT: fixed; already forgetting the Emacs keybindings...), except the frames end up in their own windows, running their own client. Had remoting the buffers been a lot of work, I wouldn't have, but the the Drb specific part of the code is <100 lines and the combined effect of the resilience (if an exception is thrown in the server code, I get thrown into a Pry repl in the client) and the extra abilities it enables makes it worthwhile. Similarly, I've avoided implementing my own directory handling, and just farmed that out to a wrapper that currently uses rofi, same for theme selection (for syntax highlighting), buffer selection, etc. The minimalism of delegating all of these things elsewhere appealed to me. > I am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch. Strongly disliking Lisp was high on the list (I like the concepts; hate the syntax intensely). Also, it wasn't so much a limiting factor, as realising that my Emacs config file was larger than toy editors I'd played with in the past, and a minimalist bent making it appeal to me to go for something smaller. Also seemed fun (and has been) [1] https://github.com/vidarh/re https://github.com/vidarh/re [2] https://github.com/agorf/femto https://github.com/agorf/femto