From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: `C-b' is backward-char, `left' is left-char - why? Date: Tue, 07 Jun 2011 13:54:17 +0300 Message-ID: <83d3ipdi92.fsf@gnu.org> References: <6F4054004B154CFB8E2753172D316C13@us.oracle.com> <4DE4F8D0.7010800@lanl.gov> <82y61l16bg.fsf@gmail.com> <87vcwo40tn.fsf@fencepost.gnu.org> <834o48f6sa.fsf@gnu.org> <8762on3rvj.fsf@fencepost.gnu.org> <83lixjdkae.fsf@gnu.org> <201106051651.p55GpANm013542@beta.mvs.co.il> <83oc2ccign.fsf@gnu.org> <201106051719.p55HJDMZ023870@beta.mvs.co.il> <87y61g195p.fsf@fencepost.gnu.org> <83mxhwcgvn.fsf@gnu.org> <87pqms16fa.fsf@fencepost.gnu.org> <83lixgccd7.fsf@gnu.org> <874o42yqgu.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1307444133 18224 80.91.229.12 (7 Jun 2011 10:55:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Jun 2011 10:55:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 07 12:55:28 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QTtwT-0006uO-H7 for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2011 12:55:25 +0200 Original-Received: from localhost ([::1]:34022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTtwS-0000hU-IM for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2011 06:55:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTtw8-0000fj-7E for emacs-devel@gnu.org; Tue, 07 Jun 2011 06:55:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTtw6-0003Sl-Bb for emacs-devel@gnu.org; Tue, 07 Jun 2011 06:55:03 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:60230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTtw2-0003S0-Oh; Tue, 07 Jun 2011 06:54:59 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LMF00D0029R5500@a-mtaout21.012.net.il>; Tue, 07 Jun 2011 13:54:17 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.223.140]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LMF00D0L2AF4B30@a-mtaout21.012.net.il>; Tue, 07 Jun 2011 13:54:17 +0300 (IDT) In-reply-to: <874o42yqgu.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140260 Archived-At: > From: David Kastrup > Date: Tue, 07 Jun 2011 10:51:13 +0200 > > I have thought about it, and I guess the key point is ambiguity of > cursor display. The cursor is usually displayed just after the last > inserted character. Which means to the left in R2L contexts, and to the > right in L2R contexts. For a vertical cursor between characters, this > means that > > LLLL^RRRR > > is ambiguous: we are either at the end of the LLLL passage, or at the > end of the RRRR passage. Right. As I wrote, there are two places on the screen where we could display the cursor in these cases, and TRT would be to display something in each one of them. It would also make sense to make the whole range of characters between these two spots stand out in color or something. There's some discussion of these issues here: http://www-01.ibm.com/software/globalization/topics/bidiui/index.jsp > I think what is needed in this particular case is a virtual fill > character (perhaps the direction switch glyph, but displayed with a > different face?) at the insertion point when we are inserting in reverse > paragraph direction and the cursor would be displayed on a forward > paragraph character (including newline), not logically adjacent to the > insertion point. Either that, or generally switch cursor type for > reverse direction insertion, so that one knows whether one has an L2R or > R2L facing cursor. Sorry, I don't understand the details of your proposals. It would help if you show some pictures. (What are "direction switch glyph" and "forward paragraph character"? what "cursor type" do you want to switch to? etc.) > > Actually, TRT would be to split the cursor in two, because it plays > > two different roles whose correct positions in this case do not > > coincide. > > They diverge only on borders between L2R and R2L, and a virtual padding > like described above gives the cursor a buffer that allows it to never > split. IIUC, your "virtual padding" is just one possible implementation of a split cursor. But what does "gives the cursor a buffer" mean? > > That would need an even deeper surgery, including in terminal-specific > > parts -- xterm.c, w32term.c, etc. And what to do on a TTY with its > > hardware cursor? > > The virtual padding approach should work on a tty since it requires only > one cursor to display. Maybe I'll agree once I understand what you propose. Right now, I cannot judge if everything you propose can work on a TTY. In any case, the redisplay interface for displaying the cursor would need to change, because we will now compute 2 locations, not 1.