|
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 16:38:19 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |