all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: emacs-bidi@gnu.org, dak@gnu.org, emacs-devel@gnu.org
Subject: Re: Handling invisible text in bidirectional display
Date: Sun, 17 Jan 2010 21:29:33 +0200	[thread overview]
Message-ID: <833a248r8i.fsf@gnu.org> (raw)
In-Reply-To: <E1NWXcd-0005Sg-Mj@fencepost.gnu.org>

> From: Richard Stallman <rms@gnu.org>
> CC: dak@gnu.org, emacs-bidi@gnu.org, emacs-devel@gnu.org
> Date: Sun, 17 Jan 2010 11:05:03 -0500
> 
> Your description of the interaction of invisible with bidi seems right
> to me, but I was surprised by your response to this
> 
>     > I think a reasonable model is to display the text as if the invisible
>     > characters are not there.
> 
>     I think the resulting change of the visual order will surprise the
>     users.  It also complicates implementation, which for me is an
>     important downside.
> 
> because I don't see a differnce between "display the text as if the
> invisible characters are not there" and what you described (in the
> no-ellipsis case).  What you described
> 
>     One consequence is that a run of invisible characters can now be split
>     into several non-contiguous runs.  For example, this text:
> 
>       abcABCxyz
> 
>     with c and A covered by an invisible property will be displayed as
> 
>       abCBxyz
> 
> seems to agree entirely with that description.  Is there something I
> have misunderstood?

It's just that the example I showed is a simple one, where the
distinction doesn't show.  However, in general, the bidirectional
reordering can cause simple insertion to have non-local effect on the
visual order.  This is because so-called weak characters (digits,
plus, minus, punctuation, etc.) and neutral characters (blanks, tabs,
etc.) change their directionality depending on the surrounding text.

Here's an example.  Suppose the buffer contains this text:

  ABCD(4+5)*3

(As usual, capital letters are strong right-to-left characters.)  This
text will be displayed as

  3*(5+4)DCBA

By contrast, the same text with `+' removed will display as

  3*(45)DCBA

As you see, 4 and 5 switched their visual order.  This means that if
we first remove the invisible characters and then reorder, the 4 and 5
will appear in a different order when `+' is invisible than when it is
visible.  With my suggestion, we _first_ reorder and _then_ hide
invisible characters, so the display with `+' invisible will be

  3*(54)DCBA

which I think is less surprising.

  reply	other threads:[~2010-01-17 19:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-16 16:54 Handling invisible text in bidirectional display Eli Zaretskii
2010-01-16 18:43 ` martin rudalics
2010-01-16 20:32   ` Eli Zaretskii
2010-01-17  8:59     ` martin rudalics
2010-01-17 19:06       ` Eli Zaretskii
2010-01-18  8:11         ` martin rudalics
2010-01-18  9:54           ` Eli Zaretskii
2010-01-18 10:39             ` martin rudalics
2010-01-18 12:35               ` Eli Zaretskii
2010-01-16 19:15 ` David Kastrup
2010-01-16 20:37   ` Eli Zaretskii
2010-01-17 16:05     ` Richard Stallman
2010-01-17 19:29       ` Eli Zaretskii [this message]
2010-01-17 20:17         ` David Kastrup
2010-01-17 20:39           ` Ehud Karni
2010-01-17 20:51           ` Eli Zaretskii
2010-01-18  6:42             ` David Kastrup
2010-01-18  8:52               ` Eli Zaretskii
2010-01-16 19:56 ` Stefan Monnier
2010-01-16 20:53   ` Eli Zaretskii
2010-01-17 16:04     ` Richard Stallman
2010-01-17 18:24       ` Eli Zaretskii
2010-01-18 11:56         ` Richard Stallman
2010-01-22 13:41       ` Bidi TODO (was: Handling invisible text in bidirectional display) Eli Zaretskii
2010-02-01 14:48         ` [emacs-bidi] " Ehud Karni
2010-01-18  1:27     ` Handling invisible text in bidirectional display Kenichi Handa
2010-01-18  4:00       ` Eli Zaretskii
2010-01-18  7:40         ` Kenichi Handa
2010-01-18  8:56           ` Eli Zaretskii
2010-01-18 11:09             ` Kenichi Handa

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=833a248r8i.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dak@gnu.org \
    --cc=emacs-bidi@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.