Honest questions about blinking

[Soulsuke]

I know this has been discussed in some issues (which devolved in heated up discussions), but please bear with me.

I'm not asking for this feature, rather about some informations... Why does the blinking text adds a lot of overhead, but the blinking cursor does not? And if I wanted to try to give it a try, where should I start looking in the codebase? Gotta add, I'm very rusty with c and I'm mostly curious about what does what in kitty :p

@kovidgoyal I'd be really grateful for an answer, and I swear this won't turn into a "plz add this" (at least on my end)

[kovidgoyal]

Blinking text means the event loop has to keep ticking as long as the text is on screen, which means you either need to a) somehow track whether blinking text is on screen which is very difficult since there are myriad operations that can change screen contents b) scan the entire screen contents on each event loop tick to decide whether to continue ticking c) stop blinking the text after some time of inactivity such as is done for the cursor. (c) is really the only acceptable answer performance and energy use wise but then it will lead to bug reports that waste *my* time along the lines of blinking text stops blinking after some time. Finally, blinking text is a highly undesirable feature, visually and from a UI perspective. This makes blinking text simply not worth it. There is a reason the <blink> tag was abandoned in HTML. I am not going to entertain blinking in kitty so I am not bothering to tell you where you would go to implement it.

[Soulsuke]

Thanks for your reply, it cleared up some misconceptions I had.

I thought point c would have been moot, and more akin to "blink max x times" rather than after a timer.

Most importantly, it never occurred to me to keep the text blinking forever nor to have any previous output on screen blinking, all those things break what imho is its intended usage: to point the user's focus in a way that's hard to miss (no matter the theme he's using) to very few important lines in the last output (and I'll be honest here, that's usually past me cursing at present me or at interns for doing something messy).

then it will lead to bug reports that waste my time along the lines of blinking text stops blinking after some time.

I'm with you there, and honestly I see why you wouldn't take that kindly. That's a big waste of time for a feature misuse.

Finally, blinking text is a highly undesirable feature, visually and from a UI perspective. This makes blinking text simply not worth it. There is a reason the tag was abandoned in HTML.

Just to humor me, how would you see it if only the last rendered command output (or it last N lines, or its last N blinking tags) were allowed to blink?? I'm not asking to have it in the project, I just wonder if you think such a feature would still be bad/useless, a hit on performance or just be too messy to keep up code-wise.

I am not going to entertain blinking in kitty so I am not bothering to tell you where you would go to implement it.

After what you said I understand why you don't want to entertain that thought. But... Pretty please? I'm not asking for a code walkthrough, just one or two greppable words to know where to start lookinging (hopefully that aren't part of the languages' statements :p).

I won't bother you anymore if you say no, but I can say I won't propose a patch nor fork kitty given this is your project and you're against this feature, and it's mostly a me issue. And that's if I could even get a patch out of it.

Again, thanks for finding time to reply and for all the work you put on kitty.

[kovidgoyal]

On Tue, Feb 11, 2025 at 12:39:33AM -0800, Maurizio Oliveri wrote: Thanks for your reply, it cleared up some misconceptions I had. I thought point c would have been moot, and more akin to "blink max x times" rather than after a timer. Most importantly, it never occurred to me to keep the text blinking forever nor to have any previous output on screen blinking, all those things break what imho is its intended usage: to point the user's focus in a way that's hard to miss (no matter the theme he's using) to very few important lines in the last output (and I'll be honest here, that's usually past me cursing at present me or at interns for doing something messy).

Reverse video works fine for that and has no issues associated with blinking.

Just to humor me, how would you see it if only the last rendered command output (or it last N lines, or its last N blinking tags) were allowed to blink?? I'm not asking to have it in the project, I just wonder if you think such a feature would still be bad/useless, a hit on performance or just be too messy to keep up code-wise.

How would kitty know what the last command output is? That is only feasible if the user is using a shell with shell integration. And scanning N lines is basically the same as scanning the screen its not something I would like to do on every event loop tick. And doing that means more bug reports along the lines of "blinking text works in shell but not in editor" or "in shell but not in scrollback". Basically all these are hacks.

> I am not going to entertain blinking in kitty so I am not bothering to tell you where you would go to implement it. After what you said I understand why you don't want to entertain that thought. But... Pretty please? I'm not asking for a code walkthrough, just one or two greppable words to know where to start lookinging (hopefully that aren't part of the languages' statements :p).

It's not a one word thing you would need to add an attribute to GPUCell, then modify the shaders to check that attribute and also the blink state which CPU code would set as it does for the blinking cursor.

[Soulsuke]

Reverse video works fine for that and has no issues associated with blinking.

I'm probably gonna fallback to that, it sounds like the best options all around, thanks.

How would kitty know what the last command output is? That is only feasible if the user is using a shell with shell integration. And scanning N lines is basically the same as scanning the screen its not something I would like to do on every event loop tick. And doing that means more bug reports along the lines of "blinking text works in shell but not in editor" or "in shell but not in scrollback". Basically all these are hacks.

Thanks for replying to that, you made some excellent points and I understand much better why you said it was really too much hassle for such a niche feature. Blinking now really sounds as something that should be avoided moving onwards.

It's not a one word thing you would need to add an attribute to GPUCell, then modify the shaders to check that attribute and also the blink state which CPU code would set as it does for the blinking cursor.

Thanks a lot! I'll take a look at that mostly out of curiosity and as a learning experience, but I'll definitely ditch blinking in my scripts.

Thanks a lot for finding the time to reply to all of that :)