From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yair F Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: Column numbering in bidirectional display Date: Fri, 21 May 2010 16:20:01 +0300 Message-ID: References: <83tyq1pqov.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1274448251 18472 80.91.229.12 (21 May 2010 13:24:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 May 2010 13:24:11 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Fri May 21 15:24:10 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 1OFSCr-0005LM-NC for gnu-emacs-bidi@m.gmane.org; Fri, 21 May 2010 15:24:06 +0200 Original-Received: from localhost ([127.0.0.1]:46221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFSCq-00080Q-VD for gnu-emacs-bidi@m.gmane.org; Fri, 21 May 2010 09:24:05 -0400 Original-Received: from [140.186.70.92] (port=43985 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFSCm-0007wt-6Z for emacs-bidi@gnu.org; Fri, 21 May 2010 09:24:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFS8y-0002oh-Gq for emacs-bidi@gnu.org; Fri, 21 May 2010 09:20:06 -0400 Original-Received: from mail-ww0-f41.google.com ([74.125.82.41]:65296) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFS8y-0002nx-6e; Fri, 21 May 2010 09:20:04 -0400 Original-Received: by wwi14 with SMTP id 14so718859wwi.0 for ; Fri, 21 May 2010 06:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B/6QUS8txcC5jKQuJT/RlS6d7uoCRdWL//Lnbdw7cj4=; b=TpTj2NuRSdjzPT2O0IVbhCy20hdbF496tqc/6zoH6u6kGAjmC1TtD0ZDIDXtRheaPr g9JIyiApW7/be6Nc7zw6eJ9wBBYUKKcmUHSwgGbXijtvCwKXvrMyZO4RjNN5fj8eHgKO OnpVX2gg3j4E0j+AVmMBugl9+QEiHcF9hORCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y0jXqs3iq2T7ENVqObJQMHjdAwu98ehFHPaxJ1Hi/Jf6oywe9t/wcNbsvYZk6xEKVF yAYUA7Rwol5vdZ67Ynta/EaPxq2N8/07DELWtojIG/Eymz6fya4Aqbf3J4rCS9zbLoqp vRE1ZYhNkbNcIrEsFe8cF5Kpe7hJC8RfvOduo= Original-Received: by 10.216.172.204 with SMTP id t54mr825183wel.44.1274448001924; Fri, 21 May 2010 06:20:01 -0700 (PDT) Original-Received: by 10.216.188.67 with HTTP; Fri, 21 May 2010 06:20:01 -0700 (PDT) In-Reply-To: <83tyq1pqov.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:616 gmane.emacs.devel:124989 Archived-At: I would stick to logical ordering and have previous/next-line more accordingly. In the long tem there is no escape - think of region copying and yanking. Kepping to strict logical model prevents surprises in the long term - See Mozilla for a confusing mixed logical/visual implementation. On Fri, May 21, 2010 at 12:08 PM, Eli Zaretskii wrote: > With most of basic features needed for displaying bidirectional text > out of my way (the notable omission so far is reordering display > strings), development now enters the application level, albeit on a > very basic level for now. > > One of the major issues on this level is the semantics of the column > numbering. =A0In the unidirectional case, this is trivial: column > numbers start at zero at the left margin and increase linearly as we > move to the right. > > In the bidirectional case, we have two complications. =A0First, there > are right-to-left (R2L) lines made entirely of R2L characters. =A0They > are displayed starting at the right margin of the window, like this: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0ZYX WVU TSRQ PONMLKJIH GFEDCBA > > What should current-column return when point is before A, i.e. at the > first character of the line in the reading order, which is at the > right margin of the window on display? > > The other complication is mixed L2R and R2L text. =A0Example of how we > display a L2R line that includes some R2L characters: > > =A0EDCBA abcde fghij > > Here A is the first character of the line in buffer's logical order. > What should current-column return when point is before A? > > A similar example for displaying a R2L line that includes some L2R > text: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 JIHGF EDCBA abcde > > and we have the same dilemma regarding the value of current-column > when point is before a. > > Currently, current-column (and move-to-column, and other primitives in > indent.c) work in buffer's logical order, disregarding the reordering > of characters for display. =A0That is why current-column returns zero > for all the situations I described above. =A0It also counts column in > strict logical order. =A0For example, here are the column numbers for > each character of the last example (numbers that need more than one > digit are written vertically): > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 JIHGF EDCBA abcde > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 11111111987612345 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 76543210 > > This might surprise at first, and might even look terribly wrong, but > it turns out that users expect that in bidirectional text. =A0At 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. =A0One 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. =A0Another 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: > > =A0. Rewrite primitives in indent.c to be bidi-aware, i.e. advance by > =A0 =A0calling functions from bidi.c rather than just incrementing > =A0 =A0character positions. =A0This would complicate the parts that move > =A0 =A0backwards, because there's no code in bidi.c that can do that, and > =A0 =A0it's not trivial to write such code. > > =A0. Fix all the Lisp code that uses these primitives to not assume > =A0 =A0that column zero is necessarily the first character of the line > =A0 =A0that follows a newline. > > Admittedly, there are some features which need to be fixed even if we > keep the current semantics of column numbering. =A0C-e (just fixed 2 > days ago) is one example. =A0But I think the number of such features is > much smaller than if we number columns in visual screen order. > > So on balance, I think we should keep the current semantics of the > line numbering, whereby columns are numbered in strict logical order. > > If we decide to go that way, we will need to provide primitives or > subroutines to get to the visually first and last characters of a > visual line. =A0That's because some features need that; see the thread > Re: Hl-line and visual-line for one example. =A0beginning-of-visual-line > and end-of-visual-line sound like a good starting point. > > Comments are welcome. > > _______________________________________________ > emacs-bidi mailing list > emacs-bidi@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-bidi >