[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [emacs-bidi] Re: improving bidi documents display
From: |
Martin J. Dürst |
Subject: |
Re: [emacs-bidi] Re: improving bidi documents display |
Date: |
Fri, 04 Mar 2011 19:34:46 +0900 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 |
Hello Eli,
On 2011/03/03 19:40, Eli Zaretskii wrote:
Date: Thu, 03 Mar 2011 15:11:06 +0900
From: "Martin J. Dürst"<address@hidden>
CC: Miles Bader<address@hidden>, address@hidden, address@hidden,
address@hidden, address@hidden
But isn't the "changed order" natural for the characters it's attached
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
XML/HTML readable. It is a feature similar to syntax coloring.
The
reason for this is that things have to be reevaluated/fixed anyway every
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,
syntax coloring gets updated as necessary. The same would happen (or
currently happens with our implementation) for the code that tweaks the
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
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
mode to a buffer with LaTeX mode. Then there will be some bidi tweaking
properties in the text that's copied, and they will be copied with the
text, but when they get yanked, the hook code will throw them out and
put in others to tweak the text according to what's thought best for LaTeX.
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
activated (not even a simple one for cleaning out properties yanked in
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
it's not what I mean. It's a layer on top of it (and we currently are
discussing how and what exactly to put it on top).
To go back to the syntax coloring example (which may not be perfect, but
I hope it gets the point across), the equivalent would be:
- Color display is switched on in all buffers
<=> bidi reordering is switched on in all buffers
- Syntax coloring is switched only in some buffers
(e.g. not in plain text buffers)
<=> 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 (*)
<=> 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
properties, we get the problem indicated at (#). What I tried to explain
in my previous mail was that you won't as long as the conditions are
similar as those for syntax coloring. [I'm not at all sure syntax
coloring uses properties, because I don't know the internals of emacs
well enough, but I hope that it can provide an example and serve as a
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,
because in a new context, it's easily possible that they need to be
fixed. Again here the parallel to syntax coloring should work.
Regards, Martin.
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:address@hidden
- Re: [emacs-bidi] Re: improving bidi documents display, Martin J. Dürst, 2011/03/01
- Re: [emacs-bidi] Re: improving bidi documents display, Martin J. Dürst, 2011/03/01
- Message not available
- Re: [emacs-bidi] Re: improving bidi documents display, Eli Zaretskii, 2011/03/01
- Message not available
- [emacs-bidi] Re: improving bidi documents display, Eli Zaretskii, 2011/03/02
- Message not available
- [emacs-bidi] Re: improving bidi documents display, Eli Zaretskii, 2011/03/02
- Re: [emacs-bidi] Re: improving bidi documents display, Martin J. Dürst, 2011/03/03
- Re: [emacs-bidi] Re: improving bidi documents display, Eli Zaretskii, 2011/03/03
- Re: [emacs-bidi] Re: improving bidi documents display,
Martin J. Dürst <=
- Message not available
- [emacs-bidi] Re: improving bidi documents display, Eli Zaretskii, 2011/03/04
- Message not available
- [emacs-bidi] Re: improving bidi documents display, Eli Zaretskii, 2011/03/04
Re: [emacs-bidi] Re: improving bidi documents display, James Cloos, 2011/03/02