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

[Dmitry Gutov]

On 14.08.2021 15:12, Lars Ingebrigtsen wrote:
> It is a destructive change, but we may just declare that completion
> functions are allowed to destructively change the inputs in certain very
> prescribed ways.  I'd rather avoid that, though, if at all possible,
> because it may lead to subtle bugs all over the place.

That would be a breaking change, but it's a possibility, of course.

If we couldn't find a better way to implement this.

> Stefan just reminded me (in a different bug report) that we've long
> meant to extend the text property machinery with a "namespace" or
> "plane" concept.  The impetus for this is really the font locking
> machinery which wants to manage some text properties that other packages
> also want to manage.

"Planes" for text properties are just prefixed properties, I guess? 
That's different from the situation with font-lock.

> The idea is that the display machinery would combine all the planes
> before displaying, but each package would just manage its own "plane".
> If we had something like this, then using this mechanism in the
> completion context would make sense -- we could then say that completion
> isn't allowed to alter anything except text properties in its private
> plane.

Yes, if the code makes sure to only use prefixed properties, that would 
limit the damage. It could still affect repeated (parallel?) uses of the 
same values in the same piece of code.

And even if the effects are usually not serious, are we really okay with 
evaluating (symbol-name 'car) someday and seeing lots of properties 
attached to it?