Re: xml-parse-file and text properties

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> xml-parse-file now includes text properties in its returned list, ala:
>> 
>>> ((name . #("WV_APPLET" 0 9 (fontified nil))) (link . #("WV_APPLET.html"
>>> 0 14 (fontified nil))))
>> 
>>> when global-font-lock-mode is on, whereas before it did not.  Was this
>>> intended?  Any way to temporarily avoid fontification on loaded buffers
>>> (aside from turning global-font-lock-mode off prior to xml-parse-file)?
>> 
>> Could you explain why the text properties cause problems?

> I'm parsing a very large XML file (a document link and calling syntax
> catalog for IDLWAVE), trimming it and making slight modifications, and
> then writing it out to file as a big set of sexp's for later recovery,
> primarily for reasons of speed.  This file is read whenever IDLWAVE
> mode is first entered.

> With text properties (amounting simply to #(" " 0 5 (fontified nil))'
> constructs), the file is almost three times as large, erasing much of
> the speed advantage of translating to a LISP form in the first place.
> I use `prin1' to write the lists.  I suppose I could spin through the
> list first and remove any text properties on strings, but it seems
> silly that parsing an XML file never loaded into an active buffer
> should be laden with inert properties like '(fontified nil).  If there
> were a simple way to prevent that (other than turning global-font-lock
> off), that would suffice for my purposes, though not of course address the
> larger issue of text properties in XML parsed lists in general.

Clearly, in the case of xml-parse-file, I see no reason why we shouldn't
strip all properties.  After all, it's supposed to parse the *file*, not the
buffer, and files don't have those text properties.

The argument that we need to preserve the `composition' property doesn't
seem valid: this property can be computed from the sequence of chars.


        Stefan