Discussion of Emacs support for multi-directional text

Re: Callbacks?

At 06:14 05/12/01, Eli Zaretskii wrote:
 >> Date: Wed, 30 Nov 2005 16:04:18 +0900
 >> From: Martin Duerst <duerst <at> it.aoyama.ac.jp>
 >> Cc: emacs-bidi <at> gnu.org
 >>
 >>  >2. When the created file is read (again) for editing, these strings
 >>  >   should be seen (on screen) EXACTLY as it was when it was entered.
 >>
 >> If using the same editor, definitely. But we also found that there
 >> can be some personal preferences, so if you changed your preferences,
 >> the display would change.
 >
 >That's actually a bad idea, IMHO: the text should be saved so that any
 >other bidi-enabled editor will display it the same.

For plain running text, this is definitely true. I'm not sure
this applies also for structured stuff such as XML.

 >That is why
 >fiddling with Unicode character properties is something I feel we
 >should not do: those properties are the only common denominator of all
 >bidi editors.

I definitely understand your feeling. But I just want to mention
that the Unicode bidi algorithm explicitly allows things like this.
If you look e.g. at:
http://www.unicode.org/reports/tr9/#HL3 and
http://www.unicode.org/reports/tr9/#HL5,
you won't see changing of properties mentioned explicitly,
but you'll be able to figure out that "Provide artificial

(Continue reading)

headers

Eli Zaretskii | 2 Dec 11:44

Re: Callbacks?

> Date: Thu, 01 Dec 2005 20:21:07 +0900
> From: Martin Duerst <duerst <at> it.aoyama.ac.jp>
> Cc: ehud <at> unix.mvs.co.il, emacs-bidi <at> gnu.org
> 
>  >That's actually a bad idea, IMHO: the text should be saved so that any
>  >other bidi-enabled editor will display it the same.
> 
> For plain running text, this is definitely true. I'm not sure
> this applies also for structured stuff such as XML.

This applies in general, IMO.  We could make exceptions in specific
cases, but only if there's no other reasonable way to solve the
problem.  Interoperability with other software is a very important
goal, otherwise we wouldn't be considering strict compliance with
UAX#9 (which clearly made wrong choices at some strategic points).

>  >That is why
>  >fiddling with Unicode character properties is something I feel we
>  >should not do: those properties are the only common denominator of all
>  >bidi editors.
> 
> I definitely understand your feeling. But I just want to mention
> that the Unicode bidi algorithm explicitly allows things like this.
> If you look e.g. at:
> http://www.unicode.org/reports/tr9/#HL3 and
> http://www.unicode.org/reports/tr9/#HL5,
> you won't see changing of properties mentioned explicitly,
> but you'll be able to figure out that "Provide artificial
> context" does very much equivalent things.

(Continue reading)

headers

Benjamin Riefenstahl | 3 Dec 16:24

Re: Callbacks?

Hi Eli, Martin,

> Martin Duerst wrote:
>> In this specific case, there are two other possible positions for
>> the [LRM] (logical):
>>     <x y='ABC[LRM]'>DEF ghi</x>   and
>>     <x y='ABC'>[LRM]DEF ghi</x>
>> But now, we have made the [LRM] part of the attribute value or the
>> element content. In both cases, we have changed the content of our
>> *data* just to solve some display problems of the *markup*. It
>> should be clear that this is completely out of question

Eli Zaretskii wrote:
> I'm not sure why.  LRM and its ilk are just characters, albeit
> normally invisible ones.  Why is it ``absolutely out of the
> question'' to have them as part of the strings in XML?

You can have them as part of the values in XML.  But we also want to
be able to store data that doesn't have them in the same XML format.
We don't want to change the data just so that the XML looks right in
an editor.  Display of the XML in a text editor is usually not the
primary purpose of using XML.  Even though it is usefull, for
debugging applications that use XML, that XML is just text.

>> In any case, we are still left with two problems: Generic XML does
>> not have these directives
>
> Then generic XML is inappropriate for bidi text,

If I understand the issue right, it may currently be inappropriate to

(Continue reading)