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#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Date: Sat, 21 Aug 2021 15:01:06 +0300 Message-ID: <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> 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> <878s0vqgny.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25401"; 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: Daniel Mendler , 48545@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 21 14:02:20 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 1mHPhc-0006NC-Fz for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Aug 2021 14:02:20 +0200 Original-Received: from localhost ([::1]:41272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mHPhb-0000Fr-E6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Aug 2021 08:02:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49970) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHPhK-0000F8-PQ for bug-gnu-emacs@gnu.org; Sat, 21 Aug 2021 08:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52641) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mHPhK-0008BN-FZ for bug-gnu-emacs@gnu.org; Sat, 21 Aug 2021 08:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mHPhK-0007ns-E3 for bug-gnu-emacs@gnu.org; Sat, 21 Aug 2021 08:02: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: Sat, 21 Aug 2021 12:02: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.162954727729923 (code B ref 48545); Sat, 21 Aug 2021 12:02:02 +0000 Original-Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 12:01:17 +0000 Original-Received: from localhost ([127.0.0.1]:35951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHPgb-0007mY-5H for submit@debbugs.gnu.org; Sat, 21 Aug 2021 08:01:17 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:46732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHPgZ-0007mK-Gi for 48545@debbugs.gnu.org; Sat, 21 Aug 2021 08:01:15 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id f5so18088591wrm.13 for <48545@debbugs.gnu.org>; Sat, 21 Aug 2021 05:01:15 -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=GKSIaLUWP6YXc9wleP6HyxzpSepwHQCwCPqtLTHqB/E=; b=rVDajQV1RDr3aLQgJmApZuPG4MZHMAHUpryOR3dOH/GIznPoQ6Sy7GXkFu5aikkIdT DYiEdKF9GXb53/A4DKyYvVKpMvIuyJjFVKhlphx2ZIPlS9YWJ9ah7e1y1f17qQJ+6VGf X0nKCmZLiin1ST0BB7wUYiMPMunmuvQzkK0fz20dXcrncBBaycsax6fMIdiTFsfeVR4J oZodX10BzVclx/01VmGMEBhvDZNHhny6TszapiLBPs5vwhYpyeke7Vnc0Z9V+OoDIRb4 +uWKEzRwbC+UkpIpycNqk2XM4Kglb4CorLZV7mrFvPhlk7UZYEvzAjd9RCqoLeKxlCO9 tbKQ== 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=GKSIaLUWP6YXc9wleP6HyxzpSepwHQCwCPqtLTHqB/E=; b=GFkskxRcve/tUcVgBzZAKbM3izTsGPy72bAlHcsm0vqdwAaJ88bTIwhwgwGucqzhQw hj6bPnNM1CrX6v4ps1sVepRKh7ULGcWjQunG31zKWdirROMXIbpAG5jEkG53MA6srLPd iqoUBiDAhg+EIuMFQF6B5ai5S5P6B0UjDo2/F+oVOmvbr45aEXUSf5bbsGp7NfgOvg4l J8E6AXQwogrNPenIo77t+wI7/pe0A9ge4GiyDn1cwXbdk/BRNyWEJsVxhV8LM5b1fj2C BGXfl7uSoEED0TiWQDR3dibDN/mSDlXWNnW4wBY1gAU979VhvYWL6FOVxyUmK0J7SXEg w5Ww== X-Gm-Message-State: AOAM531qhpyqSuARUwT96ziU3s58ks++kRnl82oWmviSMqK2tBlOafUu d3IIwTFmcchHjhJRelYGf1OeXwIL2As= X-Google-Smtp-Source: ABdhPJzenPUeJtIgG+gNfAJAyYw8cAYHRwwmyf2w/3D8b+IgTzN1HGO9a/kz44KVer1XnaU5S2e2AA== X-Received: by 2002:adf:e6c4:: with SMTP id y4mr3590096wrm.220.1629547269622; Sat, 21 Aug 2021 05:01:09 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id o17sm12289022wmp.13.2021.08.21.05.01.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Aug 2021 05:01:08 -0700 (PDT) In-Reply-To: <878s0vqgny.fsf@gmail.com> 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:212332 Archived-At: On 21.08.2021 12:40, João Távora wrote: > 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. Whether it's called for every candidate, is a UI/design choice. >> 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 suppose yes, if you only group candidates that are visible on the screen, it could lead to jumping. Good point. Then I would suggest to go back to "global" grouping. >>> 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". I see. The order of completions coming from xref is essentially random. Yes, they are grouped by files (usually), but the files are not coming in any particular order. So I would prefer not to skip the sorting step. Of course, there might be different scenarios and preferences in that regard. > 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". Okay. Sorting seems to indeed be costly in this case (if I trust your measurements). Sorting is part of the default completion behavior (with grouping or not). You want to remove it instead of fixing? >> 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. That addressed 3 words out of 20. >>> 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. Nothing I suggested should call for a change in completion style.