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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: João Távora <joaotavora@gmail.com>,
>   mail@daniel-mendler.de,
>   dgutov@yandex.ru,  monnier@iro.umontreal.ca,  48841@debbugs.gnu.org,
>   47711@debbugs.gnu.org
> Date: Sat, 14 Aug 2021 14:12:31 +0200
> 
> 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.
> 
> 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.

How can that work if at display time all the "planes" are combined?
It would mean that the code which produced the original strings will
get them displayed differently after completion.

Anyway, I'm not sure why you are talking about display here: the
properties which are supposed to store the information about
completion aren't supposed to affect display.