Re: xml-parse-file and text properties

[Kenichi Handa]

In article <address@hidden>, Richard Stallman <address@hidden> writes:

>     ;; Note that {buffer-substring,match-string}-no-properties were
>     ;; formerly used in several places, but that removes composition info.

>     but neither of us were clear on the meaning of the statement, or why
>     retaining text properties in any XML parsed data would be desirable.  

> I think I see why.  Losing the composition info could mean that the
> composed characters turn into other sequences of characters.  It
> literally would change the text!

??? Composition is just a text property.  It doesn't change
the character sequence.  It just changes how characters are
displayed.  In that sense, it's the same as `display'
property.

> This is an ugly problem.  Many things want to get rid of most text
> properties, but they don't want to forget about composition.
> Logically speaking, composition is really part of the characters in
> the text.  Using text properties to encode it is fundamentally
> inconsistent.

I don't understand why `composition' property is that
special compared with other properties such as `display',
`fill-space'.

In addition, I don't understand why XML parsed data wants to
get rid of text properties.  What's the problem of strings
in the returned list containing text properties?

Anyway, logically speaking, composition should be internal
to display engine and should be hidden from any other place.
In emacs-unicode-2, loosing of composition property has no
problem because I've implemented a code to construct
composition automatically in display engine.

> We have been lucky so far, in that this inconsistency has not caused a
> lot of problems -- but now our luck is running out.

> I can see only two kinds of approaches:

> 1. Distinguish composition properties from others, and make functions
> like buffer-substring-no-properties preserve composition properties,
> even as they discard all other properties.

> 2. Change the representation of composition so it uses something other
> than text properties.

> #2 would be a big maintenance trouble.  It would take us a long time
> to get everything working again after such a change.  We certainly
> should not install such a change now, and I hope we won't need to do
> it ever.

> Can #1 work?

I don't know.  If text properties causes a problem in XML,
#1 doesn't solve the current problem.  If text properties is
not a problem, we don't need #1.

---
Kenichi Handa
address@hidden