From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: `C-b' is backward-char, `left' is left-char - why? Date: Tue, 07 Jun 2011 10:51:13 +0200 Organization: Organization?!? Message-ID: <874o42yqgu.fsf@fencepost.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1307436714 5579 80.91.229.12 (7 Jun 2011 08:51:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Jun 2011 08:51:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 07 10:51:50 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 1QTs0s-0006R3-68 for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2011 10:51:50 +0200 Original-Received: from localhost ([::1]:33724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTs0r-0000HR-7V for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2011 04:51:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTs0Z-0000Gs-LS for emacs-devel@gnu.org; Tue, 07 Jun 2011 04:51:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTs0X-0000cY-P5 for emacs-devel@gnu.org; Tue, 07 Jun 2011 04:51:31 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:33466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTs0X-0000cP-8M for emacs-devel@gnu.org; Tue, 07 Jun 2011 04:51:29 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QTs0V-0006H6-8Q for emacs-devel@gnu.org; Tue, 07 Jun 2011 10:51:27 +0200 Original-Received: from p508ede10.dip.t-dialin.net ([80.142.222.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Jun 2011 10:51:27 +0200 Original-Received: from dak by p508ede10.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Jun 2011 10:51:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 86 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ede10.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:S5/hqgGbjVbV4rfZAAV1KJQn+OI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:140259 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Sun, 05 Jun 2011 20:26:01 +0200 >> >> > The problems with this are not logical, they are with implementing it >> > (both the movement itself and the resulting selection and highlight). >> > Patches are welcome. >> >> The resulting selection and highlight appear to do just what is needed >> already and don't seem to have a problem with visual discontinuity. >> >> So only the movement itself would appear to be an issue. > > Only if you accept the way the region is currently highlighted, as > several disjoint stretches of text. People who want strict visual > operations might want something else, like contiguous regions. > >> If one has text like >> >> llllllllRRRRRRRRllllll > > That's the easy use case. Try figuring out the more complicated ones > with embeddings and directional overrides. UAX#9 allows up to 62 > levels of nested embeddings, with or without directional overrides, > and Emacs supports them all. Logical movement through that is clear, > but visual one... last time I tried my mind boiled. [...] >> Actually, I've just tried entering mixed L2R and R2L stuff with the >> keyboard and bidi-display-reordering set, and I find it quite >> distracting that the insertion point for "reversed" text (with regard to >> the current paragraph direction) gets increasingly distant from the >> cursor itself. > > I just did the minimal change in the original redisplay > design, whereby the cursor is placed on the character _after_ the > insertion point in the logical order. Even that required a total > rewrite of the function that figures out where to draw the cursor. > Patches are welcome to rewrite it again so as to keep the cursor > closer to the insertion point. 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. For a block or underline cursor, the ambiguity gets worse: LLL£RRRR can mean that the cursor is next before last in the L2R passage, or last in the R2L passage. 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. > 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. > 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. -- David Kastrup