Re: Bug with attachments including font information

Re: Bug with attachments including font information

[Reiner Steib]

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) 

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
<http://thread.gmane.org/gmane.emacs.devel/99559>).

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 <http://search.gmane.org/?query=icicles
Gnus&group=emacs.*>)

> This bug report explains it and tells you a workaround until they fix the bug:
>
> http://www.emacswiki.org/cgi-bin/wiki/IciclesIssuesClosed#GnusAttachmentBug
>
> 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. XML
> 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 please
> do report this to Gnus, since you shouldn't have to forego propertized
> completion results by using the workaround.
> </snip>
>
> Excerpt from the webpage cited:
> <snip>
>  Both #("~/test" 0 6 (auto-composed t)) and "~/test" are strings. The
>  first just has the text property ‘auto-composed’ with value
>  ‘t’. Icicles does not apply that text property; it must come from
>  something else you are using – perhaps GNUS. When GNUS or mml called
>  ‘read-file-name’, your input to ‘read-file-name’ was apparently that
>  propertized string.
>
> I prefer to let ‘read-file-name’ return whatever string you input, even
> if it has text properties. That feature could be useful in certain
> contexts. I introduced doing that for ‘completing-read’, and that has
> since been added to vanilla Emacs. In the case of ‘completing-read’, it
> is clearly an advantage. In the case of ‘read-file-name’, I think it
> could also be useful.
>
> However, I guess I’ll 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’t verify the data it plugs
> into XML, but you can’t argue with the real world. ;-)
>
> I’ve therefore stripped the text properties in ‘read-file-name’. 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
> ‘read-file-name’ to returning a string with no properties. It would be
> nice if you grumbled on a GNUS mailing list that it shouldn’t assume
> that ‘read-file-name’ returns a string with no properties – 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… –
> DrewAdams
> </snip>

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/