bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 14 Aug 2021 11:36:32 +0100
> Cc: Daniel Mendler <mail@daniel-mendler.de>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, 48841@debbugs.gnu.org,
>  47711@debbugs.gnu.org
> 
> > And in the example above, the values are those that the
> > lispref/objects.texi says we should not change (though it gives
> > (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC
> > the related discussions mentioned that modifying such values could
> > lead to a segfault in some previous Emacs versions. Maybe not anymore,
> > but it's still not a good idea.
> 
> You're extrapolating "change" to also include attaching properties to
> symbols.  I think that document just means that you can't do stuff like
> 
>     (aset "cons" 0 ?z)
> 
> or
> 
>     (aset (symbol-name 'cons) 0 ?z)
> 
> I don't think it means you can't
> 
>     (put-text-property 0 1 'joaot/muahahah 42 (symbol-name 'cons))
> 
> But maybe Eli or someone else more knowledgeable in the deep internals
> of Emacs can correct me.

Text properties are stored separately from the string, so I don't
think adding properties can in general be referred to as "change".

Whether in some particular situation that could count as a "change"
depends on that situation and on the particular property, of course.
I'm not sure in the context of completion there's any reason to count
as "change" adding properties that don't affect display.