|
From: | Dmitry Gutov |
Subject: | bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting |
Date: | Mon, 16 Aug 2021 06:21:16 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
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?
[Prev in Thread] | Current Thread | [Next in Thread] |