@movq@www.uninformativ.de Nice, it’s coming together! Despite it being ages ago that I used a hex editor or viewer, these different representations of information appear very handy to me. If I had to mess around on binary formats, I’d definitely appreciate them. I can’t remember if the hex viewer back then had these options. Don’t even recall what software that was. :-)

I, too, only very, very rarely use the mouse in the terminal. Apart from selecting text to copy into the clipboard. But that probably has the potential for trouble and interference with button clicks, etc. If one isn’t careful.

How did the startup times develop?

another one would be to allow changing public keys over time (as it may be a good practice [0]). A syntax like the following could help to know what public key you used to encrypt the message, and which private key the client should use to decrypt it:

!<nick url> <encrypted_message> <public_key_hash_7_chars>

Also I’d remove support for storing the message as hex, only allowing base64 (more compact, aiming for a minimalistic spec, etc.)

[0] https://www.brandonchecketts.com/archives/its-2023-you-should-be-using-an-ed25519-ssh-key-and-other-current-best-practices

@kat@yarn.girlonthemoon.xyz i wound up with xcolor AND pastel at the same time, because xcolor does exactly what i want while pastel and its picker subcommand does the same thing, relying on xcolor, but brings up a nice graphic of the picked color and related colors, plus more than just the hex code. neat.

For some reason, I was using calc all this time. I mean, it’s good, but I need to do base conversions (dec, hex, bin) very often and you have to type base(2) or base(16) in calc to do that. That’s exhausting after a while.

So I now replaced calc with a little Python script which always prints the results in dec/hex/bin, grouped in bytes (if the result is an integer). That’s what I need. It’s basically just a loop around Python’s exec().

$ mcalc 
> 123
         123        0x[7b]    0b[01111011]

> 1234
        1234        0x[04 d2]    0b[00000100 11010010]

> 0x7C00 + 0x3F + 512
       32319        0x[7e 3f]    0b[01111110 00111111]

> a = 10; b = 0x2b; c = 0b1100101
          10        0x[0a]    0b[00001010]

> a + b + 3 * c
         356        0x[01 64]    0b[00000001 01100100]

> 2**32 - 1
  4294967295        0x[ff ff ff ff]    0b[11111111 11111111 11111111 11111111]

> 4 * atan(1)
3.141592653589793

> cos(pi)
-1.0

Oh boy, I’m looking for trapezoidal (like ACME thread) screws and nuts in left hand form. The rods are already expensive, but nuts feel like a total ripoff. A hex nut for Tr20x2 being 30mm long and 30mm in “diameter” costs me 22 bucks! O_o Just a single one, made of regular steel. A meter of rod is 21€. The more common Tr20x4 hex nut is just 7€ and the rod 17€, but 4mm pitch is a bit much for a leadscrew for semi-precision work I reckon.

Well, maybe I just use metric threads. I will sleep on this.

I learned a #Toronto #hex club just started! I’ve played since ‘98 or ‘99, but rarely in person. https://www.hexwiki.net/index.php/Hex_clubs

I’d love to read the original source code of this:

https://ecsoft2.org/t-tiny-editor

This was our standard editor back in the day, not an “emergency tool”. And it’s only 9kB in size … which feels absurd in 2023. 😅 The entire hex dump fits on one of today’s screens.

Being so small meant it had no config file. Instead, it came with TKEY.EXE, a little tool to binary-patch T.EXE to your likings.