From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: arrow keys vs. C-f/b/n/p Date: Sat, 12 Jun 2010 12:16:29 -0700 Message-ID: <66ACC058967D467AAB8205475B4E2550@us.oracle.com> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz><87iq5py7xk.fsf@stupidchicken.com><83eigclgf0.fsf@gnu.org><89C16A134A024399A06EFE296DC6916F@us.oracle.com><83r5kcjkpp.fsf@gnu.org> <84bpbg9lln.fsf@cs.bham.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276370487 27118 80.91.229.12 (12 Jun 2010 19:21:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 19:21:27 +0000 (UTC) To: "'Uday S Reddy'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 12 21:21:24 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 1ONWGi-0002GT-4P for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 21:21:24 +0200 Original-Received: from localhost ([127.0.0.1]:39694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONWDN-0003Us-89 for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 15:17:57 -0400 Original-Received: from [140.186.70.92] (port=53173 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONWDH-0003QO-5t for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:17:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONWDF-0002pR-VS for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:17:51 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:59304) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONWDF-0002or-QW for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:17:49 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5CJHd7N004317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 19:17:41 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5CJHYhG027520; Sat, 12 Jun 2010 19:17:39 GMT Original-Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 320067201276370184; Sat, 12 Jun 2010 12:16:24 -0700 Original-Received: from dradamslap1 (/141.144.64.21) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jun 2010 12:16:24 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <84bpbg9lln.fsf@cs.bham.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsKWc5RmSuxEwjJQp6iZCSWFsApowAAvSiA X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4C13DD55.0101:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:125837 Archived-At: > > But I think you should also make it clear (clearer) that this > > "logical" order corresponds to buffer position, even if that might > > seem more programmer-oriented. Emacs users sooner or later have an > > understanding of buffer positions, so you might as well anchor the > > notion of "logical" order as being buffer order. > > Drew, I am not sure why you think this buffer order is so fundamental. > An Emacs user doesn't see a buffer order. There is an order in which > text is layed out on the screen. There is an order in which the > language flows in the text. These are the things that > matter. How the characters are stored inside the Emacs buffer is > an internal matter. > > If an Emacs user graduates to becoming a programmer then he/she will > figure out how things work internally. But it doesn't seem > right to me that the internal storage should dictate everybody's > view of the world. > > I notice that Lennart makes the same point later in the thread. > > In fact, I began to write a response to you last night. When > I checked things in the morning, there were comprehensive > explanations from Eli, which I thought settled the issues > quite satisfactorily. > > There is no harm in the users knowing that the buffer order > is the same as the logical, or reading, order. But, even > if the buffer order happened to be different, I don't think > the design issues would be any different. > > I am quite clear that the users should be given a clear > conceptual model that fits with their experience, not how > things are implemented internally. It's not about "internal" implementation. It is, as you say, about a user's conceptual model. Is `point' or character position "internal"? In Emacs, buffer order is part of a user model. Calling it "reading order" is fine, and can help, as long as the two notions correspond. Calling it the "logical" order doesn't really help. (Is a "visual" order illogical? is it physical?) But as Eli has pointed out, that is apparently the term used in the bidi literature. Calling it "character" order begs the question: wrt what? What's important is to explain what in fact it is, regardless of what you call it. What's the behavior? What reading/logical/buffer order means includes, in particular, how movement commands behave. What I was concerned about is the behavior of typical `forward-*' commands. That behavior is part of a user's conceptual model. (Not to mention part of a programmer's mental model. And in Emacs, users are also often Elisp programmers.) Anyway, it sounds like we are both happy with Eli's explanation and the design. Whether bidi users will also need/want some alternative (additional) kind of movement that respects "visual" order in some way is another question, which I can't speak to. I'm not a bidi user. I'm happy knowing that `forward-*' means forward through the buffer, from point-min toward point-max. Phrase that fact anyway you like, but it should be communicated to users.