GNU bug report logs -
#69479
30.0.50; Attaching files to gnus fails
Previous Next
Reported by: Alexander Prähauser <ahprae <at> protonmail.com>
Date: Thu, 29 Feb 2024 18:53:01 UTC
Severity: normal
Found in version 30.0.50
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
Full log
Message #76 received at submit <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> "Eric Abrahamsen" <eric <at> ericabrahamsen.net> writes:
>
>> Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
>> of text editors" <bug-gnu-emacs <at> gnu.org> writes:
>>
>>> Alexander Prähauser <ahprae <at> protonmail.com> writes:
>>>
>>>> "Eric Abrahamsen" <eric <at> ericabrahamsen.net> writes:
>>>>
>>>>> Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
>>>>> of text editors" <bug-gnu-emacs <at> gnu.org> writes:
>>>>>
>>>>>> C-c C-a, as usual.
>>>>>
>>>>> What completion framework do you use? Crystal ball says icicles...
>>>>
>>>> No, Vertico, with Corfu for drop-down completion.
>>>
>>> Huh, it works if I disable Vertico. I'll file a bug report there.
>>
>> Thanks, I'll watch that report. There are other guards in this area of
>> the code against completion frameworks returning propertized strings, so
>> it may be that we end up adding one here (or in `gnus-completing-read').
>> I don't actually know if there's an explicit contract saying completion
>> strings should not have properties, but in this case at least it looks
>> like leakage of something internal.
>>
>> I'm going to close this report for now; please reopen if necessary.
>
> One more thing, I sent a report to Daniel Mendler and we found out that
> the issue is that minibuffer-allow-text-properties was set to t by
> something. He also wrote this:
>
> "While I insist that it is a mistake to set minibuffer-allow-text-properties globally, I still wonder why Gnus uses propertized
> candidates in the first place, in particular with a useless fontified=nil property. Ideally commands which pass propertized
> candidates can also handle propertized return values. So maybe a guard could be added to Gnus, but I would rather
> recommend to strip the properties properly before passing the candidates like text/plain to gnus-completing-read."
Yes, I saw that. I've looked through mml.el and mailcap.el, and don't
see anything that could be adding text properties to the list of
mailcap-mime-types. All the mimetypes are collected by the function
`mailcap-parse-mimetypes', which looks for a hardcoded list of files,
and parses any files that exist for potential mimetypes. Nothing in this
process add text properties to any of the strings.
If you run C-u M-: (mailcap-mime-types) in *scratch*, is everything
propertized or only some of the entries?
This bug report was last modified 1 year and 139 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.