Re: Re: improving bidi documents display

"Martin J. Dürst" <[email protected]> Fri, 04 Mar 2011 19:34:46 +0900
Newsgroups gmane.emacs.bidi,gmane.emacs.devel
Organization Aoyama Gakuin University
Message-ID <[email protected]>
Hello Eli,

On 2011/03/03 19:40, Eli Zaretskii wrote:
>> Date: Thu, 03 Mar 2011 15:11:06 +0900
>> From: "Martin J. D=C3=BCrst"<[email protected]>
>> CC: Miles Bader<[email protected]>, [email protected], [email protected]=
m,
>>          [email protected], [email protected]
>>
>>>> But isn't the "changed order" natural for the characters it's attach=
ed
>>>> to?
>>>
>>> Only in the context of the kind of text (e.g., TeX) it was copied
>>> from.
>>
>> The copying may work if the feature is switched on for all buffers.
>
> What feature is that?

Sorry to be unclear. The feature that makes bidi-containing LaTeX or=20
XML/HTML readable. It is a feature similar to syntax coloring.

>> The
>> reason for this is that things have to be reevaluated/fixed anyway eve=
ry
>> time some buffer changes (e.g. insertion or deletion of a character)
>> happens. So if the text is copied to a buffer that doesn't do any
>> explicit reordering on top of the bidi algorithm, the special
>> overlays/properties/whatever will just be purged out.
>
> This is probably a misunderstanding, prompted by the fact that we are
> discussing an imaginary feature.

Well, if you paste (yank in emacs terminology) text into a buffer,=20
syntax coloring gets updated as necessary. The same would happen (or=20
currently happens with our implementation) for the code that tweaks the=20
bidi display.

> I was talking about a special text property which tells the display
> engine to reorder the characters covered by the property.  By default,
> text properties are yanked together with the text.  And since yanking
> text (as any other insertion) triggers redisplay, the display engine
> _will_ notice this special property and _will_ reorder the text it
> covers.

Yes, but before that, there is some hook triggered that goes and tweaks=20
these properties to fix the context where the text was yanked.

Let's take an example. Let's say I copy some text from a buffer with XML=20
mode to a buffer with LaTeX mode. Then there will be some bidi tweaking=20
properties in the text that's copied, and they will be copied with the=20
text, but when they get yanked, the hook code will throw them out and=20
put in others to tweak the text according to what's thought best for LaTe=
X.

> As for a buffer that "doesn't do any explicit reordering", I'm not
> sure what you mean.

I mean e.g. a very simple plain text buffer that has no bidi fixing hook=20
activated (not even a simple one for cleaning out properties yanked in=20
from elsewhere).


> The current plans are to turn on the bidi
> reordering in all buffers by default.  Whether this constitutes
> "explicit reordering", I'm not sure, so I don't understand what you
> mean, and I also don't see how is that relevant to the effect of
> copying the text properties.

Turning the UAX #15 bidi reordering on in all buffers is just great. But=20
it's not what I mean. It's a layer on top of it (and we currently are=20
discussing how and what exactly to put it on top).

To go back to the syntax coloring example (which may not be perfect, but=20
I hope it gets the point across), the equivalent would be:
- Color display is switched on in all buffers
   <=3D> bidi reordering is switched on in all buffers
- Syntax coloring is switched  only in some buffers
   (e.g. not in plain text buffers)
   <=3D> Bidi fixup logic is switched on only in some buffers
- Copying text from a buffer with syntax coloring into a buffer without
   syntax coloring leaves leftovers of syntax coloring in the target
   buffer (*)
   <=3D> Copying text with bidi fixup properties from a buffer with bidi
   fixup enabled (e.g. LaTeX mode buffer or XML/HTML mode buffer) into
   a buffer without bidi fixup enabled will leave some leftovers of bidi
   fixup in the target buffer (#)

What (I'm thinking) you wrote in an earlier mail is that if we use=20
properties, we get the problem indicated at (#). What I tried to explain=20
in my previous mail was that you won't as long as the conditions are=20
similar as those for syntax coloring. [I'm not at all sure syntax=20
coloring uses properties, because I don't know the internals of emacs=20
well enough, but I hope that it can provide an example and serve as a=20
parallel.]

> If you suggest that this specific property should be stripped off by
> yanking, i.e. to add them to yank-excluded-properties, then it's
> possible, but not necessarily DWIM-ish, because yanking in the same
> buffer would need to leave these properties intact.

No, actually it wouldn't (necessarily) need to leave them intact,=20
because in a new context, it's easily possible that they need to be=20
fixed. Again here the parallel to syntax coloring should work.

Regards,   Martin.


--=20
#-# Martin J. D=C3=BCrst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email protected]