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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

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.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no