From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: Column numbering in bidirectional display Date: Fri, 21 May 2010 11:30:12 +0200 Organization: Organization?!? Message-ID: <87y6fdppp7.fsf@lola.goethe.zz> References: <83tyq1pqov.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1274434241 31603 80.91.229.12 (21 May 2010 09:30:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 May 2010 09:30:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: emacs-bidi@gnu.org Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Fri May 21 11:30:37 2010 connect(): No such file or directory Return-path: Envelope-to: gnu-emacs-bidi@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 1OFOYs-0003Xk-7Z for gnu-emacs-bidi@m.gmane.org; Fri, 21 May 2010 11:30:34 +0200 Original-Received: from localhost ([127.0.0.1]:58973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFOYr-0000Ph-I1 for gnu-emacs-bidi@m.gmane.org; Fri, 21 May 2010 05:30:33 -0400 Original-Received: from [140.186.70.92] (port=43965 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFOYn-0000PP-4T for emacs-bidi@gnu.org; Fri, 21 May 2010 05:30:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFOYl-0003os-Aw for emacs-bidi@gnu.org; Fri, 21 May 2010 05:30:29 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:57204) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFOYl-0003oA-0Y for emacs-bidi@gnu.org; Fri, 21 May 2010 05:30:27 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OFOYh-0003Pm-71 for emacs-bidi@gnu.org; Fri, 21 May 2010 11:30:23 +0200 Original-Received: from p5b2c1fb9.dip.t-dialin.net ([91.44.31.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 May 2010 11:30:23 +0200 Original-Received: from dak by p5b2c1fb9.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 May 2010 11:30:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 52 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c1fb9.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:XlLtIWSwssSLvVqnSaPCuj4NfxE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:614 gmane.emacs.devel:124984 Archived-At: Eli Zaretskii writes: > This might surprise at first, and might even look terribly wrong, but > it turns out that users expect that in bidirectional text. At least > MS Word behaves _exactly_ like this, AFAICS. > > Moreover, this makes a surprising number of basic Emacs features work > correctly even though the underlying Lisp code is entirely oblivious > to bidi reordering. One example is Dired, when file names include R2L > characters: I was pleasantly surprised to see that it puts the cursor > on the correct place within the file name. Another example is the > various features that manipulate indentation. > > If we decide that columns should be numbered in their screen order, > from left to right, then we will need: > > . Rewrite primitives in indent.c to be bidi-aware, i.e. advance by > calling functions from bidi.c rather than just incrementing > character positions. This would complicate the parts that move > backwards, because there's no code in bidi.c that can do that, and > it's not trivial to write such code. > > . Fix all the Lisp code that uses these primitives to not assume > that column zero is necessarily the first character of the line > that follows a newline. It is my opinion that bidi reordering should be kept strictly a display feature. The function move-to-column is sort of a hybrid ("The column of a character is calculated by adding together the widths as displayed of the previous characters in the line.") It is obvious that the quoted sentence from the description raises more questions than it answers: what are "previous characters" in this context? Does the "width as displayed" count positively? Should the relation (eq (<= (progn (move-to-column x) (point)) (progn (move-to-column y))) (<= x y)) be preserved? That would make table formatting complex. A command like vertical-motion acts on a display text presentation rather than a logical representation: it would heed bidi (where applicable). Programmatically, text manipulation should keep as far away from those display-oriented functions as possible (except where indeed the display representation should be manipulated). And all basic text manipulation should stay -- David Kastrup