From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 12:37:17 +0100 Message-ID: References: <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> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5508"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , 47711@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 13:38:18 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 1mFawb-0001BZ-MG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 13:38:17 +0200 Original-Received: from localhost ([::1]:34878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFawZ-0007p5-Td for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 07:38:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFawP-0007oj-2G for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 07:38:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37114) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFawM-0005uE-0z for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 07:38:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFawL-0001sh-VM for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 07:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 11:38:01 +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.16291138587186 (code B ref 48841); Mon, 16 Aug 2021 11:38:01 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 11:37:38 +0000 Original-Received: from localhost ([127.0.0.1]:48659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFavx-0001rj-T5 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 07:37:38 -0400 Original-Received: from mail-pl1-f170.google.com ([209.85.214.170]:38758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFavv-0001rO-AX; Mon, 16 Aug 2021 07:37:36 -0400 Original-Received: by mail-pl1-f170.google.com with SMTP id a5so20376640plh.5; Mon, 16 Aug 2021 04:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PP4sRFsXGoPRO3HMfAeZVAdQ65nsBuQPmVZTfft17hA=; b=GoSaAsmAvDaJ2uEnFUQL2xDzpkjCEOWINaIWLQb4j4gnIQT1XIeWP15QWTop+vtWrL dIqyXjGuNSjWTDDIRcm+rc+qvpNOFBTaUa50EZ0knZaSAyqLTEHe+0D7YeafD/auQ5X2 RGKP9WaXJNwr3rFIgUo2eiYBkX/TPV9UyskbbMV9y9jkEXr/90eVe3j7sM1zqpV5/F2R sEAeJib5PBjWZ4elaJdCAyv7vRPZSPdvAn8JxOtmS8PjwAVgtnwE0mWXt99s7LZh3Xde JklCLkX8moxJ/d9NNSghPMprtnY3Ek7bHEBYuda8rUPe2EJWhiwj3b13giMQrvGSMq4H rfzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PP4sRFsXGoPRO3HMfAeZVAdQ65nsBuQPmVZTfft17hA=; b=DQ/vdrTLsgX8WvR6REAhrMlk+Zc2S53hChzhYTrRE3NU3Q1OhK0INHm3avRoSSHrRK cKtUbaATb0UvCf04ttBCdspBczfm0tDC/b1uyCRmPNTYPHMxdZxCJf8I1vofSsXkFCMo KiBRZEryMrydzoDVzmqw7oBE5b4VQSc9TvPkd97nMFuQKzl6YRhBsRfb/e0mq5r0ymhT bJkkWSk+LZSfV2oD4B0d8wtCofyxXgSaYgcosPV6GhARXRZtUb2HkmT/g93HSvFd2sem uoFdDWUQuUEfDuwKwMxkej3afL7yeUYRDSWNR+CdwkPRcRoNOyaL9UZAGW3IbnC5lqfZ i16A== X-Gm-Message-State: AOAM533DyepoAsd/XxbhrdehaJxKWlhYtH1ZnjfHNXiRhmemoTb1hQe0 b/1O+8nTXOLEsSRlf97XeuSfiCOOJIKpj8KzcCg= X-Google-Smtp-Source: ABdhPJw7BaRbhM71Xp9pUzVXJR+YVQTSu9Q0LemJBUf+41xxZ6Cjz3cWVrjUel5I3GCBaZtwjQzU2ns366mJJydGD10= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr15986526pfo.2.1629113849377; Mon, 16 Aug 2021 04:37:29 -0700 (PDT) In-Reply-To: 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:211983 Archived-At: On Mon, Aug 16, 2021 at 11:53 AM Daniel Mendler wr= ote: > >> There are serious drawbacks of attaching "private" string properties t= o > >> arbitrary strings. For once it complicates debugging seriously if ther= e > >> are suddenly string properties attached to symbol names. It also leads > >> to a potential memory leak. > > Please, in the name of the sanity of this discussion, justify these two > > statements with examples or follow them with a clause like "because..."= . > Jo=C3=A3o, I am giving hard examples here. If I say to you: "It's quite obvious your patch breaks all Git repositorie= s in Kathmandu, Nepal" I am expected to demonstrate how a patch to Emacs, leads to a obscure security flaw in the Linux operating system, that tickles a butterfly at a certain angle that causes an earthquake in the Kathmandu data center, literally breaking their Git repositories. This is the the kind of statement you are making to me and the kind of logical reasoning I'm looking for. Alternatively, you can provide an actual experiment I can run in my computer that demonstrates the bug. I am not a native English speaker, and maybe you don't understand my language. Another way to explain what I am talking is to talk about "bug reproduction". You say there's a bug in my patch, I am asking you for a "bug reproduction recipe" as defined by most, if not all, the result= s you get by searching "bug reproduction recipe" in the Google search engine. > goal is not to be right here just for the sake of being right. As Eli > said, nobody has to prove anything. This is clearly not what he said. > >> 3. The `completion-filter-completions` API is the fastest possible API > > > > Again that's quite a statement that I cannot evaluate the veracity of > > without hard proof. > > As I said, I will ensure that my API does not introduce performance > regressions. Not only that, to produce veracity on that statement you would need some much more demanding proof, which is somehow be able to evaluate all possible APIs to compellingly demonstrate that yours triumphs. > I have a patch for Vertico which shows > this. I can provide patches for 'icomplete-mode' separately later on. Yes, please do. The earlier, the better. > No, we should not merge this problematic patch of yours. See the many > arguments against this proposal. I'm sorry to speak this child-like language, but a problem is a "bad thing"= . An undesirable thing that happens when presumably safe and good action(s) is taken by some user. Can you explain how, given my patch, a user would take a sequence of innocent actions that would lead to a "bad thing" that would _not_ happen if the same sequence of innocent actions were taken in a version of Emacs without the patch applied? That, to me, is what constitutes "a bug/problem in the patch". Let me give you an example: if I make a patch that deletes `/lisp` in the Emacs source tree, the innocent action "make" would probably not work. That would be the problem/"bad thing"/bug in that patch. We cannot proceed this discussion without these explanations. Mind you, I'm not stating, because it is impossible to prove, that my patch cannot possibly generate problems, subtle or obvious (that, by the way, is my interpretation of what Eli meant). But since you so confidently state that it does, it's quite reasonable that I ask you for examples that demonstrate it. Once you do demonstrate these bugs, it's reasonable I will go about fixing them. Exactly as you say you are going to do. I demonstrated with code and numbers a regression in _your_ patch, and you say are going to fix it. That's great, and that's the way it should be. But you possibly wouldn't go about fixing it if I hadn't demonstrated the regression compellingly, just as I can't go about fixing a "memory leak" or "debugging difficulties" if you don't explain what these things mean to you or how my patch causes them. Jo=C3=A3o