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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: 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, joaotavora <at> gmail.com
Subject: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting
Date: Mon, 16 Aug 2021 16:38:19 +0300

On 16.08.2021 14:46, Eli Zaretskii wrote:

>>> Text properties are stored separately from the string, so I don't
>>> think adding properties can in general be referred to as "change".
>>
>> Are you thinking of C strings?
> 
> No, about the implementation of Lisp strings in Emacs.

I was talking about their behavior.

>> Lisp strings carry text properties in addition to the array of
>> characters. It doesn't really matter where in the memory the properties
>> and the characters reside.
> 
> Well, it does, at least in some situations.  The string text is not
> affected, and so the code which processes the string will not notice
> that it has a property about which that code has no idea.  Only
> properties that are known to the processing code can affect it;
> non-standard properties private to some other code will generally pass
> unnoticed.

I don't think anybody was suggesting that changing text properties 
changes the character codes inside the "C string" part of the Lisp string.

>>> I'm not sure in the context of completion there's any reason to count
>>> as "change" adding properties that don't affect display.
>>
>> For the context in question, whether the properties affect display is
>> not particularly important. Properties affecting display just make it
>> easier to notice that something's wrong. Bug involving other properties
>> should be more difficult to investigate.
> 
> Once again, if some code invents its private property, not used
> anywhere else and not documented anywhere else, then putting such a
> property on a string has very high chances of going unnoticed.  I hope
> this consideration helps this discussion, because saying that
> properties change a string blurs the distinction between actually
> changing the string text or its properties that affect many parts in
> Emacs, and adding some obscure property that is not known to anyone.

What muddies the water is arguing against a solid engineering principle 
with statements like "those mutations are not mutations".

Yes, when the properties are prefixed, the damage is reduced. Even then, 
that increases the possibility of introducing bugs in the very code that 
sets those properties (like having different code paths where one branch 
sets them and another does not; forgetting to clear them in the other 
branch; having subsequent code use the property values set by some 
previous invocation of the code in question where it took another 
branch; not to mention the potential troubles with parallel execution, 
which is not a real concern these days, but we're designing for years 
ahead, and someday it can be). Memory leaks, too.

Our completion pipeline has multiple interchangeable/pluggable parts, so 
we have to be on the lookout even for problems which do not reproduce 
with stock Emacs, and that requires solid abstractions.

And speaking of "only private properties", the completion-score property 
can be used by downstream code, with all the associated potential for 
trouble.

Previous Next

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