re

i window" simply by virtue of spawning new separate instance of itself. It's then multi-pane/frame by relying on me running a tiling wm, so splitting the buffer horizontally and vertically is "just" a matter of a tiny helper script ensuring the window opens below/to the right of the current window respectively. But some other things, like the syntax highlighting (using Rouge) is in need of a number of bugfixes and cleanups; I keep meaning to modify the server to keep metadata about the lines and pull the syntax highlighting out so it runs in a separate process, talking directly to the server, for example. [1] https://github.com/vidarh/re

ub and is also most likely to cause problems for others, so that might take a bit of time, not least because I'm in the middle of a fairly significant overhaul of the way the views and models works. Here's some of what is out there, though: * Skrift: This is a Ruby port of libschrift, a TTF font renderer. It's heavily cut down, and currently stands at about 680 lines of code. I intended to tidy up the API as it's still a bit messy after my rewrite: https://github.com/vidarh/skrift * X11 bindings for Skrift: https://github.com/vidarh/skrift-x11 - these are messy, and I have significant updates to them (including basic fontset support and a mechanism for pixel-perfect boxdrawing characters at any reasonable scale) that have not yet been pushed: https://github.com/vidarh/skrift-x11 * Pure-X11: This is a form and significant overhaul of pure X11 client bindings for Ruby (as in not Xlib or XCB needed): https://github.com/vidarh/ruby-x11 - it's not terribly out of date, but it's a bit in flux as I don't like the initial mechanism, used for the protocol and so I'm thinking about how to trim it down and make it easier to use. * This is the starting point for my terminal. My terminal is nothing like that any more, but this is the repo that will get all the updates, eventually: https://github.com/vidarh/rubyterm - this initial prototype used a C extension and server-side fonts, while the current version uses Pure-X11 and Skrift * This was the very first version of my WM I used, a few hours into the switch (from bspwm). It's a straight port from TinyWM. My current one has tiling and some EWMH support and multiple desktops and adds about 700 lines of code - it'll start appearing on Github soon: https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55... * This is a script I used to feed into a 9menu style popup menu script from my file manager to generate folder-contextual actions based on the folder contents: https://gist.github.com/vidarh/323204137de5293bfe216ec751646... -- the current version is quite a bit slicker and will eventually show up * This is a very dated and broken version of my editor, and odds are you'll struggle to get it to work at all, as it depends on various helper scripts that are not yet packaged up, as have been massive updated since that version; I'm hoping to maybe bring the repo a bit more up to date over the holidays: https://github.com/vidarh/re * This is a gem that handles the input processing: https://github.com/vidarh/termcontroller * This does keyboard mapping from symbols from termcontroller to higher level user-defined sequences: https://github.com/vidarh/keyboard_map * This is layered on top of Rouge (which I use for syntax highlighting), to load GTK sourceview themes into Rouge: https://github.com/vidarh/rouge-gtk_theme_loader

e 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 [2] https://github.com/agorf/femto

ch again recurses into Rouge's Ruby mode. The "LayeredLexer" class it shows is used to enable that. EDIT: It's my main editor, by the way, and it persists open buffers, and shares them between the user interfaces using Drb. Currently I have 1969 buffers open... [1] https://github.com/vidarh/re [2] https://imgur.com/a/1mTLAPs

sons). The server process holds all the buffers, and snapshots them to a json file frequently. As a result every single file I've opened in Re the last several years - all 1600 of them - are retained as buffers and loaded into memory when I restart my laptop. I've not gotten around to adding a way to kill a buffer because they take up "only" 68MB total. The client-server approach meant I could switch to use it long before it stopped crashing, since as long as my changes don't corrupt the server-side buffers, it usually only crashes the client (even server-side exceptions gets passed along by Drb to the client) - I rely on it calling out to a script to split panes, since I use a tiling vm (bspwm), so I have emacs like keybinding to split horizontally and vertically that uses bspc to control bspwm (I have a script for i3 as well) to split the pane accordingly and start another copy of Re that opens a view to the same serverside buffer. E.g. "split-vertical" just does "bspc node -p south ; exec #{cmd}" where "cmd" is a command line passed from re that will typically be <full path to re.rb> --buffer <numeric id of the buffer to open>. - To open files or switch between buffers, or select themes, I use rofi rather than build a selector into Re. But it calls rofi by calling out to a script so anything that can take a list of buffers and open a dialog to select one will work (such as e.g. dmenu). E.g. here's the "select-buffer" script that is executed when I do ctrl x + b: re --list-buffers | rofi -dmenu -filter `pwd`/ -p "buffer" Part of the idea is to make the editor itself as minimal as possible, and farm out everything that can be farmed out to either separate tools or separate gems. [1] https://github.com/agorf/femto [2] https://github.com/vidarh/re

look nicer. One thing I find is that with respect to things like this it's very much a 20% of the time to get 80% there thing, but if you write software mostly for your own use, getting 80% there is often sufficient. E.g. I haven't added a "safe" extension mechanism - my editor will crash if I decide to customize something, because the "extensions" are modifying the core of the editor rather than get treated as an embedded language. That'd not really be acceptable as a general purpose editor. But as my editor for my personal use, it's quite ok (and loss of any substantial amount of data is easy enough to protect against). It's shortcuts like that which makes it viable. E.g. I also know that trying to open a gigantic file with it would be silly, but I very rarely do that, and can resort to a "grown up" editor when I need to. [1] https://github.com/agorf/femto [2] https://github.com/vidarh/re