Re: [dev] Fwd: st patches for more attrs

From: Anders Eurenius <>
Date: Mon, 23 Jun 2014 16:02:01 +0200

> Hey Anders,
> impressive patch. I see that it probably has taken some time to write.

Well, it was a lazy sunday afternoon, nothing serious.

>> The fast-blink support involves a bit of mucking about in the main
>> loop, and is a bit more debatable. I'm not entirely happy with it, but
>> it does separate things a bit. It also makes independent windows blink
>> synchronously, which makes me slightly less crazy.
> Tbh, I don't favor the fast-blink support, given blinking is not very
> common anymore. In fact, I struggle to find examples where it is being
> used at all.

Yeah. ^[[6m=>Fast blink isn't even on the (now) canonical reference

So, wth, let's use ^[[6m to mark URL:s or something.
(not in a hurry, but something to think a bit about)

> Thus, adding complexity to the program to support fast and slow
> blinking is in my opinion not a good choice.
> The patch weighs in at +84 LOC, so better get ready for some heavy
> debate ;).

I'm not really that enamored with the fastblink patch either, but I felt the
main loop needed to suck less. Not sure if it does with this patch, but,
well, it's at least a conversation piece.

Also, don't confuse low LOC count with simplicity. Splitting the main loop
has merit even without either fastblink or blink.

> I favor the INVISIBLE and STRUCK patches, because they are very simple.
> However, as before, I struggle to remember when I last saw struck text
> or text with the invisible attribute.
> Can somebody help me see where this is necessary?

INVISIBLE has real and useful use in kpcli, where passwords are written
out invisible, which means you can copy+paste without either
(a) mucking with x selection. (nice over ssh) or
(b) showing your password to shoulder surfers

STRUCK or CROSSED-OUT (as Dickey notes it's called in ISO-6429)
is right because you might want it to actually mark deletions.

It's also a legit, non-insane code from a standard, so if it doesn't add
too much, it should be included.

I might have a go the bizarre font-scaling+resizing behavior next
Received on Mon Jun 23 2014 - 16:02:01 CEST

This archive was generated by hypermail 2.3.0 : Mon Jun 23 2014 - 16:12:06 CEST