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

[Eli Zaretskii]

> Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org,
>  47711@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 16 Aug 2021 06:17:32 +0300
> 
> On 14.08.2021 14:29, 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.

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

> > Whether in some particular situation that could count as a "change"
> > depends on that situation and on the particular property, of course.
> 
> I was talking in the general sense: modifying a value.
> 
> One can talk about whether a certain modification matters in certain 
> situations, but that's not the way to discount a general principle.

I didn't want to start a general philosophical discussion about string
mutability.  I hoped to provide input of specific practical use in the
context of this discussion.  If what I said is not useful, just
disregard it.

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