Highlighting cursor for char before

Highlighting cursor for char before

[Alexandre Garreau]

Hello,

TL;DR:  I know we can make the cursor so thin it becomes a bar like in 
other apps, instead of highlighted following char… but how to make it 
highlight the *previous* char? is there a way? that would be more logical 
and less confusing, especially when switching between ltr and rtl

Context: by default, emacs cursor highlights a character, instead of being 
a small vertical trait like in most applications today.  This is handy in 
overwrite mode, and logical as per the usage of the “suppr” key, but 
people hardly use these nowadays…  On the opposite, and pretty counter-
intuitively, the standard DEL command deletes the character *before* the 
one highlighted.  Furthermore, many unicode characters, character modifiers 
(hence the way to insert them) modify the character *before* them, which 
induce an even greater confusion: when for instance adding a diacritic 
this way, it will be added *not* on the character highlighted, but the one 
*before*.

Normally, anybody experienced with computers, hence anybody here, would 
not notice it, it would become “infraordinary” because we’re used to our 
ways of deleting chars, and seldom use separated diacritics (in my current 
main language, french, we have one key per modified letter, hence we don’t 
care, but for instance in italian, spanish and russian sometimes you want 
to mark tonic accent) in english and many languages…  and because of that, 
the fact you modify what’s “before” the highlighted character is unnoticed 
and goes smoothly.

What I have just noticed, is that the true semantic notion of “before” 
(that is correctly maintained in emacs common keybindings) is 
ergonomically a confusing notion once you write texts in both ltr and rtl 
languages.  There, your brain may have used to learn that you modify the 
left character, compared to the highlighted character, while of course it 
doesn’t: it keeps modifying the previous one, that is not even the 
highlighted character but the right one (that is, the wrong one: sorry for 
the confusion, I used “right” meaning direction, not expectedness (damn 
english for confusing notions, and yay for it for having the word 
“expectedness”)).

So that traditional way of highlighting cursor is already bogus and 
counterintuitive per se, but in certain context it becomes confusing and 
hard.  I’m not necessarily asking to change the default right now 
(although a solid thin trait would look more logical, appealing and 
familiar (that’s only one point among others) and less confusing to many, 
especially new users, without being incompatibly contradictory/confusion 
wrt the tradition), but how to reverse that? I’d like very much to do it, 
I’ve got acquainted to that highlighting block but I’d like something 
logical, not legacy (I never use overwrite mode, except with artist-mode 
(but that could be conditionally tweaked)).

A suggestion I propose that cursor-type may be equal to (box . -1) or 
(hollow . -1), or another variable such as cursor-

PS: sorry for verbosity, I really wanted to make all the points, but I 
feel that wasn’t optimal.  As always, I hope the fact it’s far faster to 
read than write will compensate… :/

PPS: I was unsure whether to post here or on help-gnu-emacs, but since I 
found nothing… I start thinking that there’s nothing implemented for that…

Re: Highlighting cursor for char before

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Mon, 18 Oct 2021 14:36:30 +0200
> 
> TL;DR:  I know we can make the cursor so thin it becomes a bar like in 
> other apps, instead of highlighted following char… but how to make it 
> highlight the *previous* char? is there a way? that would be more logical 
> and less confusing, especially when switching between ltr and rtl

Your assumptions and some facts are not entirely correct.

First, the default block cursor is displayed correctly both in LTR and
RTL context in Emacs.  I'm not aware of any problems there.

Next, which character will be erased by DEL is indeed
context-dependent, but experienced readers of bidirectional scripts
have no trouble knowing which one almost instinctively.

Most importantly, it is entirely non-trivial to determine which is the
"character before", in bidirectional text.  Look at the code of
move-point-visually to see how non-trivial it is to solve a similar,
but different problem: which character is the one to the right or to
the left of the current one.  So if someone wants to submit patches to
support such "before" cursor, I'm sure such patches will be welcome,
but it's a significant job to come up with something like that, IMO.

Re: Highlighting cursor for char before

[Alexandre Garreau]

Sorry I missed your mail:

Le lundi 18 octobre 2021, 15:26:24 CEST Eli Zaretskii a écrit :
> > From: Alexandre Garreau <galex-713@galex-713.eu>
> > Date: Mon, 18 Oct 2021 14:36:30 +0200
> > 
> > TL;DR:  I know we can make the cursor so thin it becomes a bar like in
> > other apps, instead of highlighted following char… but how to make it
> > highlight the *previous* char? is there a way? that would be more
> > logical and less confusing, especially when switching between ltr and
> > rtl
> Your assumptions and some facts are not entirely correct.

Which ones? I’m not sure you understood me correctly

> First, the default block cursor is displayed correctly both in LTR and
> RTL context in Emacs.  I'm not aware of any problems there.

I never said it was incorrect, in fact the display of the block cursor is 
totally consistent whatever the direction is, and follow the same legacy 
semantics.  What I’m questioning is the confuseness of that legacy 
semantic, and I ask/propose for an option to reverse that semantic.  I’d 
like the cursor to highlight the char before point instead of the char 
after.  Currently in emacs (and any program with a block cursor (with 
which emacs is consistent as well), for the matter), it’s the opposite.

> Next, which character will be erased by DEL is indeed
> context-dependent, but experienced readers of bidirectional scripts
> have no trouble knowing which one almost instinctively.

Wait no, DEL always erase the char *before* isn’t it? (then, the question 
of “where is displayed ‘before’ and ‘after’” is the context-changing 
thing, right?)

> Most importantly, it is entirely non-trivial to determine which is the
> "character before", in bidirectional text.  Look at the code of
> move-point-visually to see how non-trivial it is to solve a similar,
> but different problem: which character is the one to the right or to
> the left of the current one.

I do a distinction in phrasing between “before” and “to the left”, and 
“after” and “to the right”, for semantical and confusion-avoiding purpose.  
So, if I understand correctly (and I always though to understand that but 
maybe the terminology I don’t): the “character before” is trivial but 
what’s not trivial is “the character at left/right”, right?  I mean, 
before/after, for me, is only a matter of time and/or order in the buffer 
(most near to beginning = before, most near to end = after), and that 
stays linear and context-independent (like if I only use C-b and C-f, 
which follows not spatial direction but semantical order of chars as 
stored in the buffer), while only the visual thing is…

Do we understand each other correctly?

I mean, a blind user using emacspeak, and only using semantical commands 
such as C-b and C-f, and never the arrows (or other visual commands such 
as move-point-visually), should never see a difference between ltr and rtl, 
right? that’s purely a display/visual thing, all languages have 
“beginning” and “end” and serialized orally (remove “orally” in the 
exceptional case of sign languages) in a temporally linear way, afaik.

Anyway what I meant is that I find the current display of block cursor 
consistent and anti-confusing when you use a computer in erase/ovrwt-mode, 
while I find it confusing in insert-mode.  I only just found that this 
confusion is further increased when you switch text direction while you 
are a newbie at it

> So if someone wants to submit patches to
> support such "before" cursor, I'm sure such patches will be welcome,
> but it's a significant job to come up with something like that, IMO.

Ok that was precisely what I wanted to know (especially as I totally trust 
your opinion for that matter, as a beginning (is that treated in xdisp.c 
as well?)), except given the misunderstandment above I’m unsure you 
correctly understood what I meant… I meant the precise opposite of what 
the block cursor currently does… is that so complex?

Re: Highlighting cursor for char before

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 27 Oct 2021 16:44:35 +0200
> 
> > Most importantly, it is entirely non-trivial to determine which is the
> > "character before", in bidirectional text.  Look at the code of
> > move-point-visually to see how non-trivial it is to solve a similar,
> > but different problem: which character is the one to the right or to
> > the left of the current one.
> 
> I do a distinction in phrasing between “before” and “to the left”, and 
> “after” and “to the right”, for semantical and confusion-avoiding purpose.  
> So, if I understand correctly (and I always though to understand that but 
> maybe the terminology I don’t): the “character before” is trivial but 
> what’s not trivial is “the character at left/right”, right?  I mean, 
> before/after, for me, is only a matter of time and/or order in the buffer 
> (most near to beginning = before, most near to end = after), and that 
> stays linear and context-independent (like if I only use C-b and C-f, 
> which follows not spatial direction but semantical order of chars as 
> stored in the buffer), while only the visual thing is…
> 
> Do we understand each other correctly?

About what?  You ask so many questions, and OTOH say so little apart
of the questions, that I no longer understand what you are talking
about.

> Ok that was precisely what I wanted to know (especially as I totally trust 
> your opinion for that matter, as a beginning (is that treated in xdisp.c 
> as well?)), except given the misunderstandment above I’m unsure you 
> correctly understood what I meant… I meant the precise opposite of what 
> the block cursor currently does… is that so complex?

It is complex, yes.  That's what I tried to explain.

And I don't think it makes sense to display the cursor on the
character before point, because it will be terrible in bidirectional
context.  Are there any other editors that show the cursor that way?
But if someone wants such a feature as an option, why not?

Re: Highlighting cursor for char before

[Alexandre Garreau]

Le mercredi 27 octobre 2021 17:59:11 CEST, vous avez écrit :
> About what?  You ask so many questions, and OTOH say so little apart
> of the questions, that I no longer understand what you are talking
> about.

Oh noes :(

Ok, let’s start again more simply: what is that block underlining? what’s 
its meaning?

To me, in LTR, currently with the current behavior, in both insert and 
ovrwt mode, that block is underlining “the place where will appear the 
character I type” (first assertion), and that’s its meaning.  It also 
underlines the character that will be deleted if I press Suppr or C-d 
(second assertion), but since most of the time I use DEL, that’s 
irrelevant, because the character that would be deleted if I press DEL is 
not the one underlined.

In RTL, currently, the second assertion holds, but the first doesn’t… 
unless I’m in overwrt mode… but nobody use that anymore right? I only do 
while in artist-mode…

To me, block-cursor is most useful in overwrt mode, and since both most 
likely emerged at the same time, that’s a congruence that’s no longer 
useful, and that now can bring confusion (because of the assertion I 
proposed as a semantic for that kind of cursor).

> > Ok that was precisely what I wanted to know (especially as I totally
> > trust your opinion for that matter, as a beginning (is that treated
> > in xdisp.c as well?)), except given the misunderstandment above I’m
> > unsure you correctly understood what I meant… I meant the precise
> > opposite of what the block cursor currently does… is that so complex?
> 
> It is complex, yes.  That's what I tried to explain.

Isn’t it just a matter of taking the current behavior and reversing the 
way the block is drawed compared to the cursor position (the position 
between two chars that we would see if the cursor was just a line)?

and still: is that in xdisp.c?

> And I don't think it makes sense to display the cursor on the
> character before point, because it will be terrible in bidirectional
> context.

Why so?

> Are there any other editors that show the cursor that way?

I’m pretty sure there aren’t.  I never saw a such thing.  But I find it 
more logical.

> But if someone wants such a feature as an option, why not?

I would! I like when things I use have a meaning, more than when they have 
a history (and I see a historical explanation in the current behavior, but 
no semantical one).

Re: Highlighting cursor for char before

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Oct 2021 20:49:47 +0200
> 
> To me, in LTR, currently with the current behavior, in both insert and 
> ovrwt mode, that block is underlining “the place where will appear the 
> character I type” (first assertion), and that’s its meaning.  It also 
> underlines the character that will be deleted if I press Suppr or C-d 
> (second assertion), but since most of the time I use DEL, that’s 
> irrelevant, because the character that would be deleted if I press DEL is 
> not the one underlined.
> 
> In RTL, currently, the second assertion holds, but the first doesn’t… 

Only if you type RTL text inside a paragraph whose base direction is
left-to-right.  If you type RTL text in a paragraph with right-to-left
base direction, both assertions hold.

> > It is complex, yes.  That's what I tried to explain.
> 
> Isn’t it just a matter of taking the current behavior and reversing the 
> way the block is drawed compared to the cursor position (the position 
> between two chars that we would see if the cursor was just a line)?

I don't think I understand what you mean by "reversing" here.  The
function that decides where to draw the cursor is set-cursor_from_row;
please study it before talking about these details, because otherwise
we won't have a common understanding on which to build any meaningful
discussion.

> and still: is that in xdisp.c?

Most of it, yes.

> > And I don't think it makes sense to display the cursor on the
> > character before point, because it will be terrible in bidirectional
> > context.
> 
> Why so?

Because no other program does that.