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]