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.

Heh, yeah, that’s part of what’s currently keeping me on X. I use little more than a bunch of shells and Chrome, so there’s not many incentives for me to switch. All of my Ruby X tools are very light on the X11 API use, so they’ll eventually be fairly simple to migrate over, but the window manager vs. compositor situation is frustrating.

I’m somewhat tempted to hack together some FrankenCompositor based on wlroots that implements the bare minimum of the X11 protocol to allow an X11 window manager to to manage the windows. The X11 protocol itself is simple, and while making every WM run would be a ton of work, if you first have a Wayland compositor making it possible to run simpler WMs wouldn’t actually necessarily be so bad. Not likely to happen anytime soon, though, it’s not exactly necessary and I’m not that much of a masochist :)

A somewhat more sane variant might be FFI bindings for wlroots so it’s possible to use it to build a compositor, but that too seems an awful lot more work than an X window manager.

That’s an interesting one I’d missed. Thanks :)

It might just tempt me to ditch bspwm, or at least experiment. I use little enough of bspwm capabilities, so it might be feasible. I have also lightly toyed with the idea of writing my own, as since I don’t use menu bars etc. even on my floating screen (the “menu bars” in my desktop manager are just client rendered titles) I really need very few capabilities. Basically pretty much just a placement function similar-ish to bspwm, and the ability to move and resize and float windows.

On the other hand, a truly minimalist WM is <100 lines, so I might consider writing one from scratch too (I’d need to update the Ruby X11 binding to handle StructureNotify events and add a few more calls, but that’s pretty trivial). Though at this point we’re quickly approaching zealotry :) It would be fun, though. Maybe when I’m done replacing the terminal fully…

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.

This is basically the concept of a Webring, and used to be big. Some were fixed (as in the path through the ring was always the same), but some were more flexible or random or semi-random.

A decentralised approach would be new, and not necessarily too hard since the dataset for each ring would be small, so each member could just store all or a subset of the entries in their ring and submit updates to their “neighbours” in the ring that’d eventually spread out to everyone. The challenge is moderation - you’ll still end up with some entities that have a privileged position to weed out bad entries, because the appeal was always to a large extent to make discovery “someone else’s problem” and the moment you let someone put links on your site someone will try to abuse it.

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.