Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blinking Cursor Turns 54

hackaday.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Blinking Cursor Turns 54

#41

Post by perihelions »

tpmx wrote: post #3

I've been using Emacs since 1996. One of the many reasons I like it is the default non-blinking full block cursor. It brings a certain calmness to the editing process. No stress or distraction. It feels so clean. It's interesting how very subtle design decisions like these matter so much.

My perception is the opposite: it's stressful to see a non-blinking block cursor, because that's what emacs looks like when it locks up. Frozen cursors are the very first visible indication. Switching to a "calm" cursor, to me, would feel a bit like an Apple user setting their default mouse cursor to a pinwheel of doom [0].

(Background: emacs is a single-threaded lisp program, and "blink the cursor" is just another lisp function [1] running on an event timer. (At least that's the case in GTK emacs). So if any lisp function hard-crashes, the cursor will immediately crash too).

[0] https://en.wikipedia.org/wiki/Spinning_pinwheel

[1] https://github.com/emacs-mirror/emacs/blob/emacs-28/lisp/fra...

Re: Blinking Cursor Turns 54

#42

Post by SLWW »

I love the blinking cursor; the only time i have reason to revile it's existence was with the late Terry Davis' Temple OS.

Though with a quick Kernel patch you can slow it down. I just know that if the cursor blinks faster than what we are used to, I find it causes anxiety and is greatly distracting.

Re: Blinking Cursor Turns 54

#43

Post by lttlrck »

fxtentacle wrote: post #24
jpe90 wrote: post #20

Earlier quoted context omitted.

“A blinking cursor can have a significant effect on battery life, as such we decided to change the default to non-blinking.” Sublime Text 4 Update FAQ, May 2021 https://forum.sublimetext.com/t/sublime-text-4-update-faq/58...

Haha, that's probably an electron app. Or they use a really buggy UI framework. Otherwise, I wouldn't know why updating a 4x8 pixel block would cause a significant amount of power usage. Especially if a 286 could do it no problemo.

A 286 didn't do anything to flash a cursor in e.g. VGA text mode - the graphics adapter did using a counter controlled by the refresh rate.

Re: Blinking Cursor Turns 54

#44

Post by abecedarius »

The popularity is strange to me. (In this comment thread: "good old blinking cursor", blinking as default, and the reason to change the default not being that anyone hates it but just to save power.)

It's like it's jumping up and down yelling "look at me, look at me!", tirelessly. Who can think with that going on? I guess this is not a neurotypical reaction.

Re: Blinking Cursor Turns 54

#45

Post by JdeBP »

As I wrote at https://retrocomputing.stackexchange.com/a/11032/1932 Charles A. Kiesling is the best that my research turns up, but xe might not have been the first.

More importantly, however, and also as I wrote there, the blinking cursor has existed since at least 1965, and has not just turned 54 this year.

Re: Blinking Cursor Turns 54

#46

Post by JdeBP »

bokchoi wrote: post #25

The hackaday article doesn't add much. The actual article is: https://www.inverse.com/innovation/blinking-cursor-history

... and the history professor from the University of Reading has the history wrong. As I wrote at https://retrocomputing.stackexchange.com/a/11032/1932 , whilst Charles S. Kiesling's patent was filed in August 1967, the blinking cursor had actually been around since at least the Datanet-760 from General Electric coming out in 1965. The patent filing date is not its birth date. It has not turned 54 this year.

Re: Blinking Cursor Turns 54

#47

Post by hulitu »

323 wrote: post #40
fxtentacle wrote: post #24

Earlier quoted context omitted.

Haha, that's probably an electron app. Or they use a really buggy UI framework. Otherwise, I wouldn't know why updating a 4x8 pixel block would cause a significant amount of power usage. Especially if a 286 could do it no problemo.

No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU. There are ways around it, but it requires direct interaction with the compositor, which while supported by the APIs, it's more complicated.

> No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU.

So evolution. Does this mean that a laptop with lower screen resolution has better battety life ? It explaines why Win 10 is so crappy with screen and cursor updates.

Re: Blinking Cursor Turns 54

#48

Post by [deleted] »

323 wrote: post #40
fxtentacle wrote: post #24

Earlier quoted context omitted.

Haha, that's probably an electron app. Or they use a really buggy UI framework. Otherwise, I wouldn't know why updating a 4x8 pixel block would cause a significant amount of power usage. Especially if a 286 could do it no problemo.

No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU. There are ways around it, but it requires direct interaction with the compositor, which while supported by the APIs, it's more complicated.

[deleted]

Re: Blinking Cursor Turns 54

#49

Post by Akronymus »

badRNG wrote: post #29
jareklupinski wrote: post #16

Earlier quoted context omitted.

every time I use this trick, I think of how running diagonally in some games is faster than running in one direction...

I think that's just because those games are written poorly and don't account for the differences in moving diagonally. If you are moving on a grid, moving forward one tile moves you the length of a tile. Moving diagonally one tile moves you sqrt(2) ~1.4 tile lengths.

More often it is because both inputs apply some speed. Like in doom.

https://doom.fandom.com/wiki/Straferunning

Re: Blinking Cursor Turns 54

#50

Post by salamandersauce »

hulitu wrote: post #47
323 wrote: post #40

Earlier quoted context omitted.

No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU. There are ways around it, but it requires direct interaction with the compositor, which while supported by the APIs, it's more complicated.

> No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU. So evolution. Does this mean that a laptop with lower screen resolution has better battety life ? It explaines why Win 10 is so crappy with screen and cursor updates.

A laptop with a lower screen resolution has entered battery life but that has more to do with the fact you need brighter backlights to get the same brightness from a more dense panel. Pretty common to see 1080p versions of laptops that also have 4K options have significantly more battery life.
Post reply on HN