From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs 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 Message-ID: <769c0ee0-6d6f-6177-7929-1ac4ada30951@yandex.ru> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> <83tujp8vd9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26560"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: mail@daniel-mendler.de, joaotavora@gmail.com, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 15:39:28 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mFcpp-0006cw-Cq for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 15:39:25 +0200 Original-Received: from localhost ([::1]:55260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFcpo-00071n-7G for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 09:39:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFcpS-0006fk-W3 for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 09:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37465) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFcpS-00081U-Oj for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 09:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFcpS-0001TO-Mc for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 09:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 13:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291211145621 (code B ref 48841); Mon, 16 Aug 2021 13:39:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 13:38:34 +0000 Original-Received: from localhost ([127.0.0.1]:49010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcp0-0001Sb-HZ for submit@debbugs.gnu.org; Mon, 16 Aug 2021 09:38:34 -0400 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:33578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcot-0001S9-SH; Mon, 16 Aug 2021 09:38:29 -0400 Original-Received: by mail-wr1-f49.google.com with SMTP id r7so23782499wrs.0; Mon, 16 Aug 2021 06:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SqI0rHgABZha2WvRm9Y8w2oaSldHqcSN+3/YdatFStM=; b=P3asAjLAFMnMQalTG7bE/JtxvtRSVYQrO1SO8ibPC68FgWWLijkIgEzFGRkLUP2rWa tMbUCkJugsQ4qIarmfIjj1PWoLhlYNgvAYV9wNwTNdW6OVBRiSUycs4kUA0OFWlyPpXT sO0Pba0/zS2F9MfmmCRocbHU7XNfjnjMbkqC4ufJd330VYNR+u88qcW6LPHzjZh+5ENa 2IfCnRxfnk03f4x03x9BMqOEEQZvbt2AZr2Oca2waE45jvhQOFcYLzoCbRagZn673Oqh VDfv/grSzZxbQIh9SrLVtdegvQ868Ok/dwJ01iXR47wNaW+Ft6oLaSqqgaG61KgifutI +Peg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SqI0rHgABZha2WvRm9Y8w2oaSldHqcSN+3/YdatFStM=; b=QB5A7bSEXh1zrowP8TpCIpUza44usXulBEwjSZxpOeybMnsKTY4i/b9TWfEhbMHpq/ G1bnDU/wTJcUFFNkFmMT3yd2gUORdRC6+u7fk/2rycZlBR9uw05aSrL5cGD4SWm4BqTr UZL7qJWMCzlnXTnmxZoj8siFD/lHfKgBNP1TJnbSCAEYJIhwK2fsl8rYE1ILnCuyibIg z5GIQ8FQyBztPNmJuCQWzyZJY66Ir522fy8gQuMsbxRyNB5U1u/LHVfU87VJHEO3dS6J yTOknHBmqxgK5mzakd7wj6kGYrxdHXIFUgH2QPCwSf1qGovjjKp5jezJs+4bSjOX5lrn 7a8A== X-Gm-Message-State: AOAM5315ZW6diOufYdM5GevSsitT+N4503MMIfsia+3GVa2/FAs0sa8/ YaeyMNmIJQY4+QusfTPoI3UU4DwA5tc= X-Google-Smtp-Source: ABdhPJzZKIM/o/bTUBPGReFn6m2jVcVa2wAgTqynCgT+U8mlc53Mkju/lc+p6FTVvnJZe0381ucgzA== X-Received: by 2002:a5d:534e:: with SMTP id t14mr18793923wrv.109.1629121101904; Mon, 16 Aug 2021 06:38:21 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v17sm13960685wro.45.2021.08.16.06.38.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 06:38:20 -0700 (PDT) In-Reply-To: <83tujp8vd9.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212021 Archived-At: 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.