From: David Kastrup <dak@gnu.org>
To: emacs-bidi@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: Column numbering in bidirectional display
Date: Fri, 21 May 2010 11:30:12 +0200 [thread overview]
Message-ID: <87y6fdppp7.fsf@lola.goethe.zz> (raw)
In-Reply-To: 83tyq1pqov.fsf@gnu.org
Eli Zaretskii <eliz@gnu.org> 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
next prev parent reply other threads:[~2010-05-21 9:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-21 9:08 Column numbering in bidirectional display Eli Zaretskii
2010-05-21 9:30 ` David Kastrup [this message]
2010-05-21 11:17 ` Eli Zaretskii
2010-05-21 13:20 ` Yair F
2010-05-21 14:07 ` David Kastrup
2010-05-22 0:34 ` Stefan Monnier
2010-06-30 4:30 ` "Martin J. Dürst"
2010-06-30 17:22 ` Eli Zaretskii
2010-07-01 1:36 ` "Martin J. Dürst"
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y6fdppp7.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-bidi@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).