Interesting Links for 23-05-2025

[andrewducker]

1. Why are Scotland's councils so short of cash when tax is going up?

(tags:scotland tax )

2. Greenland Signs Lucrative Minerals Deal with Europe in Blow to Trump

(tags:Europe USA materials Greenland trade )

3. How I Beat NES Mario in 0.000005 Seconds (the nerdiest video I have ever watched. If you've seen something nerdier then do let me know)

(tags:video games programming technology mario )

4. Trump's image of dead 'white farmers' came from Reuters footage in Congo, not South Africa

(tags:USA politics Africa southafrica )

5. Programmers spend 5% of their time editing code, the rest is mostly understanding it/the issue they're trying to solve..

(tags:programming research )

6. Which word made you old? (Mine was GOAT)

(tags:language age change comic )

7. Explaining "what a species is" turns out to be very very tricky

(tags:video ontology life )

Comments

[simont]

The toot where I announced it.

The inspiration was that a friend with anomalous colour vision said, elsewhere on Mastodon, "I find red on black text hard to read, but authors of colourful terminal software use it a lot. It would be nice if I could change it to be white on red, which I can read easily".

They didn't want to do this by hacking on their actual terminal program (which is perhaps the most obvious approach, at least if you're a programmer), because carrying a downstream patch to a program like xterm is a pain, especially if the program is constantly receiving updates from your distro.

I had the idea that you could do the same job by means of a separate program that sits between xterm and your shell session and just rewrites colour-setting control sequences, eliminating the problem of merging two sets of changes to the same source code. So I threw one together, and there it is (in a pointless demo mode where it just changes the colours). It has the key feature that it can think about both the foreground and background colours together, and rewrite them as a pair, so that it could map "red on black" into "white on red" as specified.

But at the moment, it's a starting point for experimentation: it doesn't have a built-in set of colour translations intended for any given type of unusual colour vision, and it also doesn't have a convenient configuration language. Anyone wanting to try it out at the moment will have to edit the C source code and recompile (which I know the friend in question is capable of). If it turns out to be useful in the long term then maybe I can change that, but I'd want to get some input from potential users first, because I don't even know what kind of configuration language would be convenient.