GNU bug report logs - #47711
27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 11 Apr 2021 20:52:01 UTC

Severity: normal

Found in version 27.1

Done: Daniel Mendler <mail <at> daniel-mendler.de>

Bug is archived. No further changes may be made.

Full log


Message #119 received at 47711 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, 47711 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 48841 <at> debbugs.gnu.org, João Távora <joaotavora <at> gmail.com>
Subject: Re: 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
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?




This bug report was last modified 172 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.