bug#69479: 30.0.50; Attaching files to gnus fails

[Eric Abrahamsen]

Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:

> "Eric Abrahamsen" <eric@ericabrahamsen.net> writes:
>
>> Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
>> of text editors" <bug-gnu-emacs@gnu.org> writes:
>>
>>> Alexander Prähauser <ahprae@protonmail.com> writes:
>>>
>>>> "Eric Abrahamsen" <eric@ericabrahamsen.net> writes:
>>>>
>>>>> Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
>>>>> of text editors" <bug-gnu-emacs@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?