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

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Fri, 13 Aug 2021 14:56:38 +0200
> Cc: 47711@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
>  48841@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> 
> On 8/13/21 2:37 PM, João Távora wrote:
> > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler <mail@daniel-mendler.de> wrote:
> > 
> >> It is important to keep this property since this will preclude many bugs
> >> due to string mutation.
> > 
> > I am aware of this, of course.  Can you give examples of these "many bugs"?
> > Perhaps other than the one I already described and addressed?
> 
> No, João, this is not how it goes.  I don't have to prove to you that
> your idea introduces bugs.  You have to show that mutation of the
> completion table strings (which are not supposed to be mutated) will not
> lead to bugs, which are hard to find.

Please calm down, both of you.  No one has to prove anything to anyone
here, that's not how Emacs development works.  We need to see which
idea is better, and if none is significantly better, we will probably
have both of them living side by side.

And while asking for an example of potential bugs is reasonable,
asking for a proof that a change will NOT lead to bugs isn't.  So how
about a couple of examples where having original strings unchanged is
important, which could then be discussed?

> >> Note that your idea also does not address the other issues which are
> >> addressed by my patch.
> > 
> > That's for sure.  My patch idea addresses only that single problem.
> > I think this is a good property of patches: to solve one thing, not many.
> 
> No, this is not necessarily true.  This is only good if the problem is
> solved in a way which is future proof.  The idea of mutating the strings
> is a hack and not a solution.

Just to make sure we are on the same page: adding a text property to a
string doesn't mutate a string.  Lisp programs that process these
strings will not necessarily see any difference, and displaying those
strings will also not show any difference if the property is not
related to display.  So the assumption that seems to be made here,
that adding a property is the same as mutating a string, is IMO
inaccurate if not incorrect.

And once again: please tone down your responses, both of you.  TIA.