[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bidi-display-reordering is now non-nil by default

From: Eli Zaretskii
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Thu, 04 Aug 2011 10:53:54 -0400

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden,
>     address@hidden
> Date: Thu, 04 Aug 2011 22:55:57 +0900
> Eli Zaretskii writes:
>  > Precisely and explicitly, I think that using lossy conversions is not
>  > a good idea, if there are practical alternatives.  Just visiting a
>  > file, then saving it without changes should produce the a byte stream
>  > that is identical to the original one.  I hope you agree with that.
> I don't.  Not in the context of Unicode.  It should produce a sequence
> of characters identical to the original one.  However, the user may
> have excellent reasons for doing, say, normalization, and therefore
> the sequence of bytes may be different.

Normalization is not relevant to directional control characters.
Let's stick to the issue at hand: do you consider it a good idea to
remove or add these characters in an otherwise unmodified buffer?

> I see no reason why a text-property-based implementation should be
> lossy.

Because the user could type directional controls, and there's no way
for Emacs to know at all levels which one is to be treated in which

> Regarding handling the splitting and joining of regions:
>  > I mean ugly on the implementation level.  This splitting (and the
>  > corresponding joining) need to be implemented,
> I don't understand.  If `put-text-property' and friends don't get that
> right already, more than bidi is in trouble, I should think.  What's
> special about bidi?

What is special is the fact that bidi needs nested regions with
different values for the same property.  Normally, if you put a
property with a value on a portion of text that has another value for
that property, the new value replaces the old one.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]