Subject: bug#69479: 30.0.50; Attaching files to gnus fails

From: Alexander Prähauser <[email-masked]>
Date: Fri, 01 Mar 2024 22:04:52 +0000

"Eric Abrahamsen" <[email-masked]> writes:

> Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
> of text editors" <[email-masked]> writes:
>
>> Alexander Prähauser <[email-masked]> writes:
>>
>>> "Eric Abrahamsen" <[email-masked]> writes:
>>>
>>>> Alexander Prähauser via "Bug reports for GNU Emacs, the Swiss army knife
>>>> of text editors" <[email-masked]> 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."