From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: xml-parse-file and text properties Date: Fri, 21 Jul 2006 16:22:22 -0400 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1153513351 2145 80.91.229.2 (21 Jul 2006 20:22:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 Jul 2006 20:22:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 21 22:22:28 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G41Vw-0002BS-EC for ged-emacs-devel@m.gmane.org; Fri, 21 Jul 2006 22:22:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G41Vv-0004la-SK for ged-emacs-devel@m.gmane.org; Fri, 21 Jul 2006 16:22:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G41Vl-0004lV-U1 for emacs-devel@gnu.org; Fri, 21 Jul 2006 16:22:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G41Vj-0004lJ-FX for emacs-devel@gnu.org; Fri, 21 Jul 2006 16:22:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G41Vj-0004lG-AM for emacs-devel@gnu.org; Fri, 21 Jul 2006 16:22:11 -0400 Original-Received: from [209.226.175.97] (helo=tomts40-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G41WD-0000lw-Bl for emacs-devel@gnu.org; Fri, 21 Jul 2006 16:22:41 -0400 Original-Received: from localhost ([70.53.192.251]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060721202210.KLXP24981.tomts40-srv.bellnexxia.net@localhost>; Fri, 21 Jul 2006 16:22:10 -0400 Original-Received: by localhost (Postfix, from userid 20848) id 0DF0F90A6; Fri, 21 Jul 2006 16:22:22 -0400 (EDT) Original-To: JD Smith In-Reply-To: (JD Smith's message of "Fri, 21 Jul 2006 10:34:25 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57445 Archived-At: >>> 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