Re:A Cursory Look at Cursors
by Joker_vD on Tuesday May 28, 2024 @09:47AM
(#40500721)
> It would be hard to imagine a program for editing text that doesn't have a cursor.
Ed is the standard text editor. It doesn't waste precious kilobytes on cursor positioning code.
Speaking seriously, this inherent need for the feedback from the user presentation layer back into the internals is why writing a decent multi-line editor with non-monospace fonts is such a nuisance.
Re:A Cursory Look at Cursors
by amitp on Tuesday May 28, 2024 @11:11AM
(#40501465)
I use a solid box in a terminal and for coding, and a vertical bar for writing in emacs org-mode. But I recently tried out a one-third box[1] in emacs and I am really loving it! It's partway between a box and an underline. Some software has a half-box option but I don't think MacOS Terminal or iTerm2 have that. [Edit: I was wrong — iTerm2 has an advanced setting for "underline cursor width"]
I used to use flashing but have that turned off right now, for reasons I can't remember.
Re:A Cursory Look at Cursors
by PhilipRoman on Tuesday May 28, 2024 @12:16PM
(#40502333)
I used a bar until getting into vim, whose semantics are more box-like (with the cursed exception of the cursor moving one position back upon exiting insert mode, as if it were a bar)
Nowadays I like a box because it stands out on any color combination.
Re:A Cursory Look at Cursors
by gcassie on Tuesday May 28, 2024 @11:53AM
(#40502016)
I'd really like my cursor to kind of glow but my graphics programming skills are not at that level yet.
For editing, a block has more potential than a vertical bar because you always have context of a selected character to perform operations on (e.g. `x` to delete current char in vim). You can also do operations before and after that character (e.g. `i` vs `a` in vim).
Re:A Cursory Look at Cursors
by netmare on Tuesday May 28, 2024 @11:18AM
(#40501548)
I still prefer it the way it was when I started using computers with DOS 6.x and Windows 3.1: underline in console, bar in GUIs, block in both with overwrite mode. Always blinking of course. My problems with modern programs are 1) overwrite mode is usually not implemented and 2) moving the cursor does not reset the blink timer. The first I can understand (although it's trivial to do), but the second results in the cursor getting invisible when moving while pressing the arrow keys. It's the little things...
Re:A Cursory Look at Cursors
by tomjen3 on Tuesday May 28, 2024 @11:40AM
(#40501832)
Box if you are overwriting the next char, vertical bar if you are inserting. Dunno whenever you would use underline (I guess if it doesn't work with box for some reason)?
Thats the standard, anyway, so if you don't follow that, you are confusing your users.
Re:A Cursory Look at Cursors
by dexen on Tuesday May 28, 2024 @11:43AM
(#40501873)
I particularly like how in Acme, when selection is zero-width ("empty"), it is the cursor. Conversely selection can be extended from cursor in any direction.
As a side effect, this greatly simplifies the API for manipulating both.
Re:A Cursory Look at Cursors
by gcassie on Tuesday May 28, 2024 @11:50AM
(#40501964)
I actually used this pattern as well and I really like it. I store another property called `mark_idx`. When `cursor_idx` and `mark_idx` are the same then it's just a cursor. When they differ, the range between them is the selection.
Ed is the standard text editor. It doesn't waste precious kilobytes on cursor positioning code.
Speaking seriously, this inherent need for the feedback from the user presentation layer back into the internals is why writing a decent multi-line editor with non-monospace fonts is such a nuisance.
I used to use flashing but have that turned off right now, for reasons I can't remember.
[1] (setq-local cursor-type '(hbar . 8))
Nowadays I like a box because it stands out on any color combination.
For editing, a block has more potential than a vertical bar because you always have context of a selected character to perform operations on (e.g. `x` to delete current char in vim). You can also do operations before and after that character (e.g. `i` vs `a` in vim).
i just remember where the cursor is supposed to be :P
Thats the standard, anyway, so if you don't follow that, you are confusing your users.
As a side effect, this greatly simplifies the API for manipulating both.
http://acme.cat-v.org/ https://www.youtube.com/watch?v=dP1xVpMPn8M