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#42149: Substring and flex completion ignore implicit trailing =?UTF-8?Q?=E2=80=98any=E2=80=99?= Date: Mon, 28 Dec 2020 11:34:59 +0000 Message-ID: <87wnx2jh98.fsf@gmail.com> References: <87sgbsv7gg.fsf@gmail.com> <871rfal18a.fsf@gmail.com> 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="19937"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 42149@debbugs.gnu.org, Stefan Monnier To: Dario Gjorgjevski Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 28 12:36:15 2020 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 1ktqow-00056R-Jr for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Dec 2020 12:36:14 +0100 Original-Received: from localhost ([::1]:42846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktqov-0008U1-Jz for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Dec 2020 06:36:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35156) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktqok-0008Th-7K for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2020 06:36:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51077) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ktqoj-0004w4-VK for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2020 06:36:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ktqoj-0008LS-Rg for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2020 06:36:01 -0500 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, 28 Dec 2020 11:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42149 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 42149-submit@debbugs.gnu.org id=B42149.160915531132017 (code B ref 42149); Mon, 28 Dec 2020 11:36:01 +0000 Original-Received: (at 42149) by debbugs.gnu.org; 28 Dec 2020 11:35:11 +0000 Original-Received: from localhost ([127.0.0.1]:34390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktqnu-0008KL-Gs for submit@debbugs.gnu.org; Mon, 28 Dec 2020 06:35:10 -0500 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:40366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktqns-0008K3-IB for 42149@debbugs.gnu.org; Mon, 28 Dec 2020 06:35:08 -0500 Original-Received: by mail-wm1-f43.google.com with SMTP id r4so9564828wmh.5 for <42149@debbugs.gnu.org>; Mon, 28 Dec 2020 03:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=xIp6VH+/MCsh1D/21fuMlyFRGOSkUHQaZseFUTlAZhg=; b=MXY8KYvGWkblE1KoZJn80ghwK5daV0YqTPzCgsD9tF79BqMOKyds971kjHmQR6X7yh NozSp3lXRCuI8pzKigkR8BLGTg7BIJtu7I951lOR4CCqBUzc+gZibZTOzydm/lmFKAmC 3gJVdRMknmjrCJ58/c/GvBmkPFVwvV3Lmogw7XWRyDSHl01E20IsetK4Q0N6+tMcAgsv LPKYFiF0JkaJ543pDkVi9/++EWcjp4k2bK4X5synHc/M7CmlS/V/47D9/TBeYZuy7Obc x/nZiyegYXnlXOcQslmoUZkCDNMmztP3QZM1BYGJdvFOuJJWRxpSgFy5KA+tJilbDH6A Cfdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=xIp6VH+/MCsh1D/21fuMlyFRGOSkUHQaZseFUTlAZhg=; b=C617WozIwvrIQs0vGcD2hygwcxOixMd8pKx5rADGLrpywIztZaNhe/b+NBpAN3xXEU YJGzo1rz1n2Sm+jdyGf3IHuPN86t3EaQdBMvVOSktnU3CtD+tGRH4KCVXjASvemVD31P 7kHV8y9xZ2imcpB8L4EtUSnYtT5vM6SUbovRlYWx6D/jS2Hct+/siCKe3WObTZallF8o AAMMJx5A4P0MdHYIWkoomDuHNMGzi+1+wjiuiRy986mf6AwUyn7jXWfkb11GPx8h7Bqg xrs2rf/MzRug3ZTgqn90k/cloeyj+L98gRye6Jwak2A6JnIzr6A6ukZNTpqcW50QQoqu VC4g== X-Gm-Message-State: AOAM5339WN5g7BhAmm86Bme42kZ3FzOiCDawD4jXrIci/Y+BME2G0AYq ajSgJrgH+y7NMn0uZZdaCQNi/XtCCbo= X-Google-Smtp-Source: ABdhPJwvF3DBrnru8CEjWETaotD4+m9wrr/prvmXxgfjnxnjebZEFmL+REtZWHha9gmrttfCLt92Cw== X-Received: by 2002:a1c:4843:: with SMTP id v64mr20148335wma.186.1609155302264; Mon, 28 Dec 2020 03:35:02 -0800 (PST) Original-Received: from krug (222.201.137.78.rev.vodafone.pt. [78.137.201.222]) by smtp.gmail.com with ESMTPSA id j15sm57482964wrr.85.2020.12.28.03.35.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Dec 2020 03:35:01 -0800 (PST) In-Reply-To: (Dario Gjorgjevski's message of "Mon, 28 Dec 2020 11:22:18 +0100") 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:196862 Archived-At: Dario Gjorgjevski writes: >> Last time I looked it was too complex for me to follow, touches many >> lines, and created unnecessary consing. I'm convinced the current >> algorithm in completion-pcm--hilit-commonality is fine for these >> 1-char edge cases, given that the assumptions hold. > > I very much disagree with this My assertion that your solution is complex is comparative, of course, not absolute. It is _more_ complex that some other existing solution -- in this case my three-line solution -- and I say that because of the factual observation that it changes much more than three lines, introduces new code paths, etc.=20=20 For now, I believe the original problem that started this bug report, which dealt with flex and substring completion, is fixed by my patch. Your failed user experience of typing "R" to perform "M-x R" should now be correct, as far as I can tell. Of course, you say your current patch fixes _more_ things, but I've yet to understand what those presumably broken things are. Perhaps once all of this is understood we will come to the conclusion that your solution is indeed the simplest possible. Or perhaps we won't. > due to 1. the test cases The test cases should be independent of the implementation, so adding more tests doesn't make the implemented solution any simpler. It does make solutions _simpler to simplify_, which is why I welcome tests. However, tests themselves should map to real-world problems (you know, the ones that you describe in terms of Emacs -Q reproduction recipes). And I'm still having trouble understanding exactly what these are for some tests. But I'm spending time to work on that. > 2. the previous reply to Stefan where I tried to explain the shortcoming= s of > the current implementation of completion-pcm--hilit-commonality. I don't understand these shortcomings, yet. I think they should be evidenced more clearly, in terms of actual user-experienceable problems. > Also, could you point to the unnecessary consing? completion-pcm--count-leading-holes and completion-pcm--match-size both add consing. That is clear to see from their respective implementations. I don't know if they can be made non-consing, though I suspect they can. Anyway, using them as they are adds a small amount consing. > I believe my patch is faster than the current implementation. Why do you believe that? Do you have any benchmarks to demonstrate it? >> I'm not aware that it's not sound, but I do believe it's too complex and >> not well understood. In constrast, I can understand the three-line fix >> I did earlier and which covers all of Darios's test cases for the flex >> completion style. Previously it was failing 7 cases, now it is only >> failing these 3. > > Making the `any' explicit was also the very first thing I suggested, but > further testing pointed to problems it doesn=E2=80=99t solve, which are i= ndeed > parts of the tests that are failing. My latest proposal doesn't make the any explicit. I'll try to understand what the intention is behind the tests that are failing. > I can add more tests if you think that would help. Yes, it would. But any test that you add should bring about evidence of a real-world problem. I.e., to state the obvious but make my point clear, the assertion: (should (eq 'foo 'bar)) =20=20=20=20 fails spectacularly but doesn't bring about such evidence. Jo=C3=A3o