From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: Highlighting cursor for char before Date: Wed, 27 Oct 2021 16:44:35 +0200 Message-ID: <2960319.aSkrYHcR6s@galex-713.eu> References: <1844951.jBraE47yQ0@galex-713.eu> <83fssyea67.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4452"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 27 17:39:46 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mfl1l-0000sI-TF for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Oct 2021 17:39:45 +0200 Original-Received: from localhost ([::1]:43052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfl1k-00040q-9o for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Oct 2021 11:39:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfkAa-0003Tu-LE for emacs-devel@gnu.org; Wed, 27 Oct 2021 10:44:49 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:49776 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfkAX-0004Jw-Tj; Wed, 27 Oct 2021 10:44:47 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1mfkAO-00014O-KL; Wed, 27 Oct 2021 16:44:36 +0200 In-Reply-To: <83fssyea67.fsf@gnu.org> Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:277985 Archived-At: Sorry I missed your mail: Le lundi 18 octobre 2021, 15:26:24 CEST Eli Zaretskii a =C3=A9crit : > > From: Alexandre Garreau > > Date: Mon, 18 Oct 2021 14:36:30 +0200 > >=20 > > TL;DR: I know we can make the cursor so thin it becomes a bar like in > > other apps, instead of highlighted following char=E2=80=A6 but how to m= ake 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=E2=80=99m 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=20 totally consistent whatever the direction is, and follow the same legacy=20 semantics. What I=E2=80=99m questioning is the confuseness of that legacy= =20 semantic, and I ask/propose for an option to reverse that semantic. I=E2= =80=99d=20 like the cursor to highlight the char before point instead of the char=20 after. Currently in emacs (and any program with a block cursor (with=20 which emacs is consistent as well), for the matter), it=E2=80=99s the oppos= ite. > 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=E2=80=99t it? (then, the qu= estion=20 of =E2=80=9Cwhere is displayed =E2=80=98before=E2=80=99 and =E2=80=98after= =E2=80=99=E2=80=9D is the context-changing=20 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 =E2=80=9Cbefore=E2=80=9D and =E2=80= =9Cto the left=E2=80=9D, and=20 =E2=80=9Cafter=E2=80=9D and =E2=80=9Cto the right=E2=80=9D, for semantical = and confusion-avoiding purpose. =20 So, if I understand correctly (and I always though to understand that but=20 maybe the terminology I don=E2=80=99t): the =E2=80=9Ccharacter before=E2=80= =9D is trivial but=20 what=E2=80=99s not trivial is =E2=80=9Cthe character at left/right=E2=80=9D= , right? I mean,=20 before/after, for me, is only a matter of time and/or order in the buffer=20 (most near to beginning =3D before, most near to end =3D after), and that=20 stays linear and context-independent (like if I only use C-b and C-f,=20 which follows not spatial direction but semantical order of chars as=20 stored in the buffer), while only the visual thing is=E2=80=A6 Do we understand each other correctly? I mean, a blind user using emacspeak, and only using semantical commands=20 such as C-b and C-f, and never the arrows (or other visual commands such=20 as move-point-visually), should never see a difference between ltr and rtl,= =20 right? that=E2=80=99s purely a display/visual thing, all languages have=20 =E2=80=9Cbeginning=E2=80=9D and =E2=80=9Cend=E2=80=9D and serialized orally= (remove =E2=80=9Corally=E2=80=9D in the=20 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=20 consistent and anti-confusing when you use a computer in erase/ovrwt-mode,= =20 while I find it confusing in insert-mode. I only just found that this=20 confusion is further increased when you switch text direction while you=20 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= =20 your opinion for that matter, as a beginning (is that treated in xdisp.c=20 as well?)), except given the misunderstandment above I=E2=80=99m unsure you= =20 correctly understood what I meant=E2=80=A6 I meant the precise opposite of = what=20 the block cursor currently does=E2=80=A6 is that so complex?