V H

In the case of your example we’d do .map(&:unwrap) in Ruby (if unwrap was a method we’d actually want to call)

Notably, these are not the cases _1 and _2 etc are for. They are there for the cases that are not structurally “call this method on the single argument to the block” e.g. .map{ _1 + _2 } or .map { x.foo(_1) }

(_1 is reasonable, because iterating over an enumerable sequence makes it obvious what it is; _1 and _2 combined is often reasonable, because e.g. if we iterate over a key, value enumerable, such as what you get from enumerating a Hash, it’s obvious what you get; if you find yourself using _3 or above, you’re turning to the dark side and should rethink your entire life)

Frankly, I’ve seen it more often from Emacs users themselves, including while I used it myself for ~20+ years.

My own. My Emacs config grew over years to several thousand lines, and it got to a point where I decided I could write an editor in fewer lines that it took to configure Emacs how I liked it. It’s … not for everyone. I’m happy with it, because it does exactly only the things I want it to, and nothing else, but it does also mean getting used to quirks you can’t be bothered to fix, and not getting to blame someone else when you run into a bug.

That said, writing your own editor is easier than people think, as long as you leverage libraries for whichever things you don’t have a pressing need to customize (e.g. mine is written in Ruby, and I use Rouge for syntax highlighting, and I believe Rouge is more lines of code than the editor itself thanks to all the lexers)

As the old (bad) joke goes: Emacs is a great operating system. Shame it lacks a good editor.

My first “paid” programming project (I was paid in a used 20MB harddrive, which was equivalent to quite a bit of money for me at the time):

Automate a horse-race betting “system” that it was blatantly obvious to me even at the time, at 14 or so, was total bullshit and would just lose him money. I told the guy who hired me as much. He still wanted it, and I figured since I’d warned him it was utter bunk it was his problem.

Not trying to convince you - people have different preferences, but Ruby does exactly what you say and nothing else unless you start pulling in gems that do lots of monkey patching or metaprogramming cleverness.

This is one of the reasons I dislike Rails in particular - it twists people’s idea of what clean Ruby can be like and introduces a lot of “magic” conventions that makes the code hard to read for someone who doesn’t know Rails.

A lot of Ruby programmers do overdose on the “clever”, often inspired by Rails. You can do some truly insane things with metaprogramming in Ruby, but a lot of the time the cleverness is unnecessary and a bit of a footgun that people grab too early instead of thinking the problem through and realising there are simpler solutions.

My terminal is written in Ruby, and it uses a font-renderer that’s 100% Ruby ( https://github.com/vidarh/skrift - I didn’t write it from scratch, it’s a port from C ), and it’s definitely possible to get things “fast enough” for a surprising portion of code in Ruby these days, but you may end up writing Ruby code that is “surprising”. For faster Ruby, see e.g. Aaron Patterson’s walkthrough of speeding up a lexer which ends up doing things most Ruby devs would not usually do because at least some of the things he ends up doing goes against the readability (e.g. the TrueType renderer I linked above definitely sacrifices speed and assumes you’ll memoize heavily to maintain readability). For an interpreter, you’re probably right to drop to something lower level.

The most delciously evil part of INTERCAL is “COMEFROM” (though COMEFROM was proposed a number of times as a joke long before INTERCAL)

Ignoring the intentionally esoteric languages, of languages in actual use: J, K. Any descendant of APL, basically, and APL itself, though arguably APL is less obtuse than many of its descendants.

E.g, quicksort in J (EDIT: Note Lemmy seems to still garble it despite the code block; see the Wikipedia page on J for the original and other horrifying examples)

    quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

(No, I can not explain it to you)

Do it. It’s fun.

My advice is to start small, and look at some simple examples. E.g. I knew I wanted mine to run in a terminal, and I love Ruby, so I started with Femto which is a really tiny Ruby editor. By itself, it’s pretty useless (but beautifully written), but it was remarkably quick to get to something that was “tolerable” for light editing, and then I iterated from there.

There are many options for small ones for all kinds of different values of “small” that can serve as inspiration. E.g. Linus Torvalds has his own branch of MicroEmacs (as do many others, it’s a popular starting point, and the basis for e.g. Pico, mg, Vile). Antirez (of Redis fame) has Kilo, so named because it was written to be <1k lines excluding comments, and there’s an “instruction booklet” on how to write one that’s using Kilo to demonstrate approaches to writing one.

The first starting point, I think is deciding how general you want it to be. E.g. I early on decided I don’t care at all about being able to use it as my only editor ever, and that meant I could pick and choose use-cases that were out of scope. For example, I just want to edit “human-scale” files, not multi-GB datasets or log files - I’m happy to open that in Emacs if I ever need it - and so that gave me far more flexibility in terms of data structures because I don’t need it to scale beyond a few thousand lines, and that saved me a lot of effort.

That was my starting point, and I changed because it wasn’t easier.

I switched because my Emacs config was thousands of lines of code to try to wrangle it to do what I wanted. My editor is ~3.5k lines of code and is closer to things how I want them. It’s spartan, and you and most other people would hate it. That’s fine - I have no interest in writing a general-purpose editor.

Writing a good general-purpose editor is immensely hard, but writing a small editor for yourself is not.

I could absolutely manage to squeeze everything I want into any open-source editor and many proprietary ones via extensions, but there’s no value in that to me when I can write less code and get something that’s exactly adapted to my workflow.

For starters, I use a tiling window manager, and there are no editors that are designed with that in mind. That doesn’t mean they work badly with them, but that e.g. they spent a lot of code on window and tab/frame management that my window manager is already doing the way I want it, and so just by making my editor client-server (a few dozen lines of code with Ruby via DrB), I got that “for free”: When I split a view in two, I use the API of my window manager to halve the size of the actual top level window and insert a new editor instance that observes the same buffer. I could retrofit that on other editors too, but doing it from scratch means the “split a view in two” code in my editor is about a dozen lines of code.

Another example is that for my novels, the syntax highlighting dynamically adapts to highlight things I’ve taken notes about (e.g. characters, locations). I could do that with another editor too, but having full control over the way the rendering layer works meant it was trivial to have my custom workflow control the lexing.

I actually ditched Emacs because I realised I could write a text-editor that suited me better in fewer lines than my Emacs config took up…

My own custom text-editor, because it’s written to fit into my environment exactly how I want it.