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#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Date: Sat, 21 Aug 2021 10:40:49 +0100 Message-ID: <878s0vqgny.fsf@gmail.com> References: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> <871r6sw9iz.fsf@gmail.com> <87a6lfnld0.fsf@gmail.com> <87eearulft.fsf@gmail.com> <871r6pr8bk.fsf@gmail.com> <54e4e409-5525-b796-9e9c-582735995cc1@yandex.ru> <87r1epp6h9.fsf@gmail.com> <266d8a54-90de-e904-f548-8ec29e52923c@yandex.ru> <87pmu8qu8s.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="36141"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Mendler , 48545@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 21 11:42:12 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 1mHNVz-0009E1-70 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Aug 2021 11:42:11 +0200 Original-Received: from localhost ([::1]:55502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mHNVy-0005pq-38 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Aug 2021 05:42:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHNVq-0005pT-Hv for bug-gnu-emacs@gnu.org; Sat, 21 Aug 2021 05:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52540) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mHNVq-0008Ji-9N for bug-gnu-emacs@gnu.org; Sat, 21 Aug 2021 05:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mHNVq-0001xP-3Y for bug-gnu-emacs@gnu.org; Sat, 21 Aug 2021 05:42:02 -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: Sat, 21 Aug 2021 09:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs Original-Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16295388667462 (code B ref 48545); Sat, 21 Aug 2021 09:42:02 +0000 Original-Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 09:41:06 +0000 Original-Received: from localhost ([127.0.0.1]:35853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHNUs-0001wE-L6 for submit@debbugs.gnu.org; Sat, 21 Aug 2021 05:41:06 -0400 Original-Received: from mail-wm1-f42.google.com ([209.85.128.42]:50796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHNUn-0001vZ-OF for 48545@debbugs.gnu.org; Sat, 21 Aug 2021 05:41:01 -0400 Original-Received: by mail-wm1-f42.google.com with SMTP id u1so7354338wmm.0 for <48545@debbugs.gnu.org>; Sat, 21 Aug 2021 02:40:57 -0700 (PDT) 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=tHgd0SlgXpXGziCyz+U6PCtfuBqQY2vsgwYwidmQI1k=; b=bRagysNJ97Dw67SI/5lxmN7y9QXVJ4Hwom04QEA6AsplDJIPY164ee8YsjeP+YEI/L E916nSr0v1Ae8BxzkznpjigGyNiUGvPm10iGJuidysrLpONts70V8P83S6H7UOJh6au5 BJvAoHmBHgWrqni8+OsMpUFKvSjBfwdYwpTY3kOV1iD3UmS7FUd95KxYBrhOyYHOzqXr dV+T6LSBBPDmhRHOrmOBE2z1biLrPHe/GNU2RtdjW3//OC/TW0o3EXNsRLgWfpu412SI K9yyaJ33AO5B+MEqDlzEB/WLUY7bCj6XkOafXeN9NIO2JC5Zu0IM08W2Thk4s9WFBzez BXaQ== 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=tHgd0SlgXpXGziCyz+U6PCtfuBqQY2vsgwYwidmQI1k=; b=ob44wYQcIclLBme6SYtb2YxksBxv1GcwQBkDEEhwqtq/acrV9JMOIXYE8Jk7Ypg7zF 3boYS1mtIg3SfIwymsXD9Je82RGkiu7BtjqIEK7Qg9lDNLtQaRQHDVzM+stKR6PifZVT Fr8jMJxMM2Dg/2Y99AGYkEOLdtRpEZ4LsLHxTfHOQMYmDDUxxhEk+jFd1sXs0T1Nqj/F 0vA7XDAWm+gZbcnwHNb7uoECKIMQCLzrMOZ4Z9TJRThebKy1l8VkGYW4XRCPnpfGG8ds u+hh3P3OaAbVj7BXJOqJbgH6FuDmavMzI5uN2CeNGJD3CcZj0pFLMnAJVXEFbisAVb3D 2t4w== X-Gm-Message-State: AOAM532q2+weNyk1K5jz3oq2stuG2mcYdqKgNAwue8lBLr2aSpSfRvgE tLVpdzzRyuLN8l8Prr8WOeNmWQTdhm8= X-Google-Smtp-Source: ABdhPJxn7BrXGvz6TXQR3GIEpJjpZLLRQqo3msZmcKoxYp7dMO1BUP0YVDHgWdOkU5/Ko0/UDlcJwQ== X-Received: by 2002:a05:600c:2150:: with SMTP id v16mr7829973wml.143.1629538851319; Sat, 21 Aug 2021 02:40:51 -0700 (PDT) Original-Received: from krug (a94-133-228-229.cpe.netcabo.pt. [94.133.228.229]) by smtp.gmail.com with ESMTPSA id s17sm12853212wmj.12.2021.08.21.02.40.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Aug 2021 02:40:50 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Sat, 21 Aug 2021 05:09:40 +0300") 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:212323 Archived-At: Dmitry Gutov writes: > On 20.08.2021 13:35, Jo=C3=A3o T=C3=A1vora wrote: > Even if the constant factor is somehow significant (which would be a > surprise, but OK, some pathological cases might turn up), if you do > any kind of grouping at all, you will incur the same cost, won't you? Some tables and grouping strategies, like the xref table, seem to be "naturally" grouped by the way you harvest candidates. For others, we could make just make it so that they are. That "make it so" wouldn't necessarily mean calling `group-function` for every candidate. > Unless you only apply the grouping to the first V matches (where it's > the number of lines visible in the minibuffer). But even then my > suggestion can be adapted to this approach. Using the example from the > message I replied to, you would put all the matches in 'xref.el' into > the same group, not two groups. > > The cost of the grouping function doesn't matter when making this > choice. Yes, I think you see what you mean. But I also imagine it would be terrifyingly confusing for a user of a scrolling dropdown to see candidates jump back and forth into their groups as the user scrolls down to see a new candidate and hide another. If what I imagine isn't what you mean, maybe you could code something up and show what you mean. > I took an existing example of a grouping UI and suggested a slightly > different one. With no expected difference in performance. As I wrote, that's a fine presumption/intutition, though it is, IMHO, vunerable to the graces of whatever 'group-function' has been coded by the completion table author. You should now confirm your intuition with an actual patch and benchmarks. My original point about "doing too much work" is that it is almost impossible that it will somehow make the process _quicker_ than what it actually is right now. My suggestion to eliminate sorting _does_ makes it quicker, demonstrably. But maybe the two suggestions can even coexist: eliminate a+l+r sorting and add re-grouping. That is likely quicker than the current state. >> You suggestion, as far as I can see, has none of these three elements. >> So if you or someone else wants to experiment with the re-grouping (with >> whichever implemention), > > Why do you call it re-grouping? Grouping happens after sorting, there > is no prior grouping step. For example, in xref.el the matches provided by the completion table are, IIUC, already "naturally" grouped, because they are collected file by file, and the file is the group. That grouping is then completely destroyed by a+l+r sorting. Your proposal would, I presume, destroy that sorting to restore grouping. Hence "re-group". Note that I previously assumed, mistakenly, that the entries in C-x 8 RET were also naturally grouped. They're not. They could very easily be, and with no performance penalty. >>>> upfront, your're incurring in both the sorting cost and the grouping >>>> cost, when you could just be skipping both with little to no >>>> downsides, I would presume. >>> Right. I just don't think either is costly, most of the time. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Did you read my previous message where I reported that C-x 8 RET >> currently takes about a second to compute completions and only 0.6 >> seconds when sorting is removed? > I was talking about the grouping step, obviously. Not being costly. You wrote "I just don't think either is costly".=20=20 > Try disabling grouping. Is completion still slow? Then it's a problem > with sorting speed that needs to be solved separately anyway. icomplete.el doesn't do any grouping, it merely prints the grouping information as headers for the few matches that it will print. completion-all-sorted-completions also doesn't care about grouping. So there's nothing to disable in that regard. >> This is flex doing its thing. > Yup. This is what I suggested to change. As I explained two or three times now: you can. In a new dmitry-flex style. That style is only a few lines of code away, I suppose. Or a defcustom, if you prefer those. The current behaviour for 'flex' is the correct one. It was conceived like this. flex scoring trumps grouping, table orders, etc... If you don't like this you can change this, like everything in Emacs. Jo=C3=A3o