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: arrow keys vs. C-f/b/n/p Date: Sat, 12 Jun 2010 22:55:24 +0300 Message-ID: <83fx0sjaab.fsf@gnu.org> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz> <87iq5py7xk.fsf@stupidchicken.com> <83fx0slhxn.fsf@gnu.org> <83pqzwjkn9.fsf@gnu.org> <83mxv0je2b.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1276372556 583 80.91.229.12 (12 Jun 2010 19:55:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 19:55:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 12 21:55:53 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ONWo2-00072m-BQ for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 21:55:50 +0200 Original-Received: from localhost ([127.0.0.1]:46611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONWo1-0002HU-O0 for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 15:55:49 -0400 Original-Received: from [140.186.70.92] (port=32957 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONWnu-0002HF-Ql for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:55:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONWnt-0007lc-Oh for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:55:42 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:54407) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONWnt-0007lR-I0 for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:55:41 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L3X00L003AEYI00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 12 Jun 2010 22:55:24 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.88.125]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L3X00I763CBLC80@a-mtaout20.012.net.il>; Sat, 12 Jun 2010 22:55:24 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125842 Archived-At: > From: Lennart Borgman > Date: Sat, 12 Jun 2010 20:58:18 +0200 > Cc: emacs-devel@gnu.org >=20 > > For users of R2L scripts, what you suggest is a disaster. =C2= =A0If cursor > > motion is visual by default, one cannot even mark text by holding > > Shift and moving point with the arrow keys. >=20 >=20 > I see no reason for this. The arrow keys will with visual motion mo= ve > just as they do if all the text where just L2R. So the visual part > will work as before (on the user side, implementation may have to > change). It's not just an implementation issue. Here's an example. A text in the buffer is abcde ABCDE xyz It will be displayed as=20 abcde EDCBA xyz Now, suppose I move cursor in visual order, as you suggest, holding the Shift key, starting at the first character `a' and ending at `C'. The underline below shows which characters I traversed: abcde EDCBA xyz --------- Now, what characters do you think should be displayed with the region face? Now I type "M-w". What text will that copy to the kill ring? > Converting the visual region you visually see on the screen to a > logical range is a bit difficult, but not impossible. It's impossible. There's no general algorithm to reverse the logical-to-visual reordering of text, i.e. produce the original logical-order text from its visual-order replica on the screen. Only relatively simple cases, without embeddings that push the bidirectional level beyond 2 or 3 (UAX#9 allows up to 60 levels) can be reversed. > The difficulty is of course to decide what the range on the screen > will be if the end points of the visual region happen to disagree > about the direction. That's the difficulty; what's your solution? I don't know of any solution that would make sense and would not complicate Emacs beyond any reason. > The answer to this is as far as I can see that the visual region in > this case no longer internally corresponds to a single range, but t= o > two noncontinuous ranges in the buffer. If I am correct on this, is > not this then a difficulty that must be handled to finish the bidi > support? Do you have _any_ idea what your suggestion means? Having a region with several non-contiguous ranges of text blows up so many Emacs features that I don't even know where to start explaining how wrong that is. > > And that's just the tip > > of the iceberg. =C2=A0Without logical-order motion keys, Emacs (a= nd every > > other editor of similar sophistication) is much less useful. >=20 > I think you are referring to the difficulty I suggested above. If n= ot, > what more problems do you see? Text properties and overlays all depend on contiguous regions of text in the logical order. What you suggest means a complete rewrite of all of them. Some "difficulty"!