[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xml-parse-file and text properties

From: Stefan Monnier
Subject: Re: xml-parse-file and text properties
Date: Fri, 21 Jul 2006 16:22:22 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]