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)

Funny thing is it’s not a proper lake, and not very old. It’s an artificial basin that was originally prepared to allow for control of the height of a canal dug all the way from the Thames a few miles away, for transport. But they finished it not long before the railway came, and it went bankrupt, and the canal path itself was sold off to a railway company and is now the path of one of the main London rail lines. As a result there are roads near me, nowhere near water, named things like Towpath Way and Canal Walk.

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.

The foxes are still more shy here for the most part. They’ll run if I open the door or if they see me move too much inside, while the cats will sometimes come to me and some of them (that one in particular) will come inside. But the gazebo is too tempting for both cats and foxes when I’m not out there.

That’s true. It’s been an issue near me as well. Thankfully in the most built up parts of London the foxes seems to mostly have enough food to not be particularly interested in cats. But I always keep an eye out when I see the cats here get close to foxes in case it turns nasty (not happened so far).

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 everything is on Github yet, and much of it is messy and with dependencies on my environment (in the process of cleaning that up), but if you click through the “cross-posted to:” link there are a bunch of links to repo’s of what I have pushed so far.

Thanks. I’m in no rush, but yeah, it’s all very small. They depend pretty much on a handful of X calls at the moment, and aiming to isolate that in a couple of very small classes, so should be very simple. Hoping to clean it up and push more of these to github soon.

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.