Re: Re: Callbacks?

At 06:28 05/12/01, Eli Zaretskii wrote:
 >> Date: Wed, 30 Nov 2005 07:13:08 -0600
 >> From: Gregg Reynolds <[email protected]>
 >> Cc: [email protected]
 >>
 >> > - In our current approach, we not only change the properties of some
 >> >   characters, but also introduce additional embedding (or occasionally
 >> >   override) levels. Is this possible in your implementation?
 >> >
 >> Have you taken a look at the source for nxml mode?  You might be able to
 >> hack it up do do something like this.  As I understand it, in Emacs you
 >> can set whatever properties you like on each character in a buffer.  See
 >> node 32.19, "Text Properties", of the Elisp manual.
 >
 >There's a confusion here, I think: the term ``properties'' is used in
 >two different meanings (sorry, it's partly my blame, since I started
 >to talk about ``directional properties'' or some such).  The text
 >properties mentioned in the ELisp manuals have nothing to do with
 >directionality, they are a way to specify the typeface (color, font,
 >etc.,) used to display a portion of a buffer.

Yes. And what we are thinking about is making directionality
something that can be influenced in the same way as color
or font. Of course, if that's used the wrong way, it will
create a total mess, but if used the right way, e.g. from
a mode, it can clean things up.

 >With ingenious enough
 >usage of text properties, you can even display one character as
 >something else, e.g., display `a' as `b';

Yes, Ken-ichi Handa showed this to us when we discussed this
together.

 >but there's no way to use
 >text properties to reorder characters for display.

I understand that at the moment, there is no such thing.

 >(If there were a
 >way, I would not need to write the bidi reordering code in C.)

Well, not exactly. There is definitely a need for some
code that does the actual reordering, even if the directionality
can be defined as some text property. Same for colors; there
needs to be some C code that actually takes the color property
and produces the color on the screen.

 >> Now the interesting possibility presents itself, which is to add
 >> Unicode-related "special" (ie. built-in) text properties.  In
 >> particular, directional class.
 >
 >Not a good idea: text properties are considered part of the text, so
 >they are, e.g., copied together with the characters when you
 >copy/paste text.

If this is used with a mode, this should not be a problem:
The mode reanalyzes the pasted text and fixes things up.

 >Use of text properties as part of the reordering (specifically, to
 >store the Unicode bidi embedding levels) was discussed here in the
 >past, and the conclusion was that we should not use them.  Again,
 >please read past discussions.

I'll gladly do that. Can you point to the relevant section
of the mailing list archives?

And what you say is that you didn't want to store bidi embedding
levels as properties. I can understand that; it would mean that
you expose an intermediate result of the bidi algorithm as
properties, which could easily end up in a race of who's
faster to overwrite these properties, the internal bidi
implementation or some application-side emacs-lisp.


Regards,    Martin.