From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67231 Path: news.gmane.org!not-for-mail From: Reiner Steib Newsgroups: gmane.emacs.gnus.general Subject: Re: Bug with attachments including font information Date: Wed, 13 Aug 2008 21:47:03 +0200 Message-ID: <87ljz0bsug.fsf@marauder.physik.uni-ulm.de> References: <87r68t8jx3.fsf@gargoyle.datacom.co.nz> Reply-To: Reiner Steib NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1218657003 18919 80.91.229.12 (13 Aug 2008 19:50:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2008 19:50:03 +0000 (UTC) Cc: Daniel Dehennin , bugs@gnus.org To: Ian Swainson , ding@gnus.org Original-X-From: ding-owner+M15683@lists.math.uh.edu Wed Aug 13 21:50:42 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1KTMLV-0008Uy-2a for ding-account@gmane.org; Wed, 13 Aug 2008 21:49:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1KTMKH-0008Tm-Bu; Wed, 13 Aug 2008 14:48:09 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1KTMKG-0008Tc-3B for ding@lists.math.uh.edu; Wed, 13 Aug 2008 14:48:08 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1KTMK7-0006ri-JS for ding@lists.math.uh.edu; Wed, 13 Aug 2008 14:48:08 -0500 Original-Received: from mail.uni-ulm.de ([134.60.1.11]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1KTMK7-0001mm-00; Wed, 13 Aug 2008 21:47:59 +0200 Original-Received: from bridgekeeper.physik.uni-ulm.de (bridgekeeper.physik.uni-ulm.de [134.60.41.37]) by mail.uni-ulm.de (8.14.2/8.14.2) with ESMTP id m7DJl7uj022781; Wed, 13 Aug 2008 21:47:07 +0200 (MEST) Original-Received: from localhost (localhost [127.0.0.1]) by bridgekeeper.physik.uni-ulm.de (Postfix) with ESMTP id EDF5B131B2; Wed, 13 Aug 2008 21:47:06 +0200 (CEST) X-Face: 3Phac&+dw=IZHjhua]bp}LH<*p{qzj8u+ Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67231 Archived-At: On Wed, Aug 13 2008, Ian Swainson wrote: > No Gnus v0.11 > GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) > of 2008-08-13 on gargoyle > > When Icicles mode is enabled, attachment information includes font data > and is therefore invalid and the attachment fails. > > Attached is snippet of mml code from attachment when icicles is loaded, > and when it is not. > > I have emailed the maintainer of icicles - Drew Adams - and he asked me > to file a bug report, which is what I'm doing. > > His response to my querying this is as follows: Drew Adams wrote: > It's a known Gnus bug. (At least I hope that Daniel reported it.) (Daniel Dehennin reported it, cc-ing him.) > You might want to report it to Gnus yourself, just to make sure. Well, I don't want to go into finger pointing, but it's not clear to me who's bug it is. In http://article.gmane.org/gmane.emacs.devel/99559 Drew wrote: | I'd still like to pose the question here, however. Shouldn't | `read-file-name' just return the string that you choose, including | any text properties it might have? If we made that change, then some | code (e.g. GNUS)=20 BTW: It is called Gnus, not GNUS. | that expects there are no properties might need to be fixed to first | remove all properties. It seems to me that Drew is proposing some non-Emacs-standard behavior here (and he uses this behavior in icicles). IIUC, he couldn't convince the Stefan, though ). Debugging interaction problems between a non-Emacs package that fiddles with Emacs internal functions and Gnus is not really high on my priority list. Maybe some one other developer wants to look into it (not trimming quotes and cc-ing ding therefore). (There also seem to be some incompatibilities of icicles with bbdb and supercite. See ) > This bug report explains it and tells you a workaround until they fix the= bug: > > http://www.emacswiki.org/cgi-bin/wiki/IciclesIssuesClosed#GnusAttachmentB= ug > > The summary of the cause is that Gnus should remove text properties before > printing a string when it constructs an XML attribute - but it doesn't. X= ML > attribute values are not read by the Lisp reader (!) - XML knows nothing = about > Emacs text properties. It's MML, not XML. > Let me know if you still see a problem after trying the workaround. But p= lease > do report this to Gnus, since you shouldn't have to forego propertized > completion results by using the workaround. > > > Excerpt from the webpage cited: > > Both #("~/test" 0 6 (auto-composed t)) and "~/test" are strings. The > first just has the text property =E2=80=98auto-composed=E2=80=99 with va= lue > =E2=80=98t=E2=80=99. Icicles does not apply that text property; it must = come from > something else you are using =E2=80=93 perhaps GNUS. When GNUS or mml ca= lled > =E2=80=98read-file-name=E2=80=99, your input to =E2=80=98read-file-name= =E2=80=99 was apparently that > propertized string. > > I prefer to let =E2=80=98read-file-name=E2=80=99 return whatever string y= ou input, even > if it has text properties. That feature could be useful in certain > contexts. I introduced doing that for =E2=80=98completing-read=E2=80=99, = and that has > since been added to vanilla Emacs. In the case of =E2=80=98completing-rea= d=E2=80=99, it > is clearly an advantage. In the case of =E2=80=98read-file-name=E2=80=99,= I think it > could also be useful. > > However, I guess I=E2=80=99ll have to bend on this one, at least for now,= since > there is brain-dead code out there that assumes the string returned has > no properties. It seems that GNUS or mml or whatever blindly prints the > string out as the XML attribute value, without removing its > properties. That is, it uses the wrong Lisp print function when building > the code. It is amazing to me that it doesn=E2=80=99t verify the data it = plugs > into XML, but you can=E2=80=99t argue with the real world. ;-) > > I=E2=80=99ve therefore stripped the text properties in =E2=80=98read-file= -name=E2=80=99. Please > try the latest icicles-fn.el to see if it fixes your problem. Let me > know. > > But IMO it is the GNUS or mml or whatever code that is at fault > here. There is no reason to limit a general function such as > =E2=80=98read-file-name=E2=80=99 to returning a string with no properties= . It would be > nice if you grumbled on a GNUS mailing list that it shouldn=E2=80=99t ass= ume > that =E2=80=98read-file-name=E2=80=99 returns a string with no properties= =E2=80=93 send them > the XML snippet. There is really no excuse for code that naively plugs > in a string as an XML attribute value without checking it first. The fix > is for the GNUS code to use the proper Lisp print function when creating > the XML code. Anyway, thanks for your report, and let me know=E2=80=A6 = =E2=80=93 > DrewAdams > Bye, Reiner. --=20 ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/