bug#69479: 30.0.50; Attaching files to gnus fails

[Alexander Prähauser]

"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."