Cursors are one of the most useful conceptual abstractions for information processing. Besides the concrete aspects of position and seriality, they form the building block of stateful selections which is a must-have for non-linear editing. Text editing feels fluid because the cursor is pretty smart at going where you want to be - or in the case of vi, it's good at being precise and explicit in skilled hands. I often start defining problems around editing tasks in terms of what cursors and selection are going to look like.
One of the things that I think gets lost easily in graphical interfaces is the cursor; it turns into some kind of ad-hoc mix of mouse pointer, "keyboard focus", touch inputs, IME, viewport state and other things filtered and shaped into some sort of behavior that depends entirely on the application code. These UIs have to be super-smart to work well, and they can be mostly consistent in the average case, but it's also unviable to automate them without great effort.
I'm pretty sure that there are some hardware terminals where the cursor cannot be hidden, and this might even include the hardwired PC/UEFI console. So this change ought to improve usability in these environments as well; since they're going to show a cursor either way, they might as well place it so it correctly indicates focus.
Cursor shape is important, because is plays into position/selections semantics.
In some terminal emulators, like Gnome Terminal and others, you can select whether your cursor is a block, "I beam" or underline.
Unfortunately, some editing software doesn't have the semantics adjustment for this.
For instance in Vim, when you make a visual selection from point A to point B, it is inclusive: it assumes that a block cursor is wiping over the selection, so it includes the originating character and terminating character. If you start a selection and do not move the cursor, and copy text, you are copying one character: the one covered by the block cursor.
If the cursor is an I-beam, this makes no sense. The I-beam cursor appears to be between characters. When you start a selection, and do not move it, you want it to be empty, rather than arbitrarily inclusive of the one character to the right of the I-beam. Only the characters that you move over, in either direction, should be included in the selection.
In the TXR Lisp REPL, you can toggle the semantics to match your cursor. If the special variable *listener-sel-inclusive-p* is true, it has endpoint-inclusive semantics (good for block cursors), otherwise exclusive (great with I-beam).
> For instance in Vim, when you make a visual selection from point A to point B, it is inclusive: it assumes that a block cursor is wiping over the selection, so it includes the originating character and terminating character. If you start a selection and do not move the cursor, and copy text, you are copying one character: the one covered by the block cursor.
Compare emacs, where you're using a block cursor, your selection will include the originating character -- but not the terminating character -- and starting a selection and then failing to move the cursor will result in a selection of zero characters.
You've described a Vim convention, not a block-cursor convention.
Doesn't this mean that semantically you are using an I-beam cursor? (Note I say this as someone who always uses block cursors, visually, not matter the semantics.) The reason this distinction is fun to talk about in vi is because, semantically, insert mode uses an I-beam cursor while normal mode uses a block cursor, and some people have everything configured to visually switch back/forth between the two cursor styles as you switch modes (though I don't).
7 comments
[ 2.4 ms ] story [ 29.7 ms ] threadOne of the things that I think gets lost easily in graphical interfaces is the cursor; it turns into some kind of ad-hoc mix of mouse pointer, "keyboard focus", touch inputs, IME, viewport state and other things filtered and shaped into some sort of behavior that depends entirely on the application code. These UIs have to be super-smart to work well, and they can be mostly consistent in the average case, but it's also unviable to automate them without great effort.
Goldfish Interesting facts https://www.interestingnews.club/2021/06/goldfish-interestin...
Teen catches world record paddlefish in Oklahoma lake https://www.interestingnews.club/2021/06/teen-catches-world-...
In some terminal emulators, like Gnome Terminal and others, you can select whether your cursor is a block, "I beam" or underline.
Unfortunately, some editing software doesn't have the semantics adjustment for this.
For instance in Vim, when you make a visual selection from point A to point B, it is inclusive: it assumes that a block cursor is wiping over the selection, so it includes the originating character and terminating character. If you start a selection and do not move the cursor, and copy text, you are copying one character: the one covered by the block cursor.
If the cursor is an I-beam, this makes no sense. The I-beam cursor appears to be between characters. When you start a selection, and do not move it, you want it to be empty, rather than arbitrarily inclusive of the one character to the right of the I-beam. Only the characters that you move over, in either direction, should be included in the selection.
In the TXR Lisp REPL, you can toggle the semantics to match your cursor. If the special variable *listener-sel-inclusive-p* is true, it has endpoint-inclusive semantics (good for block cursors), otherwise exclusive (great with I-beam).
Compare emacs, where you're using a block cursor, your selection will include the originating character -- but not the terminating character -- and starting a selection and then failing to move the cursor will result in a selection of zero characters.
You've described a Vim convention, not a block-cursor convention.
No. "I-beam cursor" is a description of a visual phenomenon; semantics are a separate concern.
You can render an I-beam on the right of its square just as easily as you can do it on the left.