From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 May 2021 18:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 48545@debbugs.gnu.org Cc: Gregory Heytings X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16215369741922 (code B ref -1); Thu, 20 May 2021 18:57:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 May 2021 18:56:14 +0000 Received: from localhost ([127.0.0.1]:35214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ljnqA-0000Uw-G0 for submit@debbugs.gnu.org; Thu, 20 May 2021 14:56:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:52774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ljnq9-0000Up-9n for submit@debbugs.gnu.org; Thu, 20 May 2021 14:56:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljnq9-0001wB-16 for bug-gnu-emacs@gnu.org; Thu, 20 May 2021 14:56:13 -0400 Received: from server.qxqx.de ([2a01:4f8:121:346::180]:37925 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljnq7-0001JN-L0 for bug-gnu-emacs@gnu.org; Thu, 20 May 2021 14:56:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rKNFO4t4dGjdIDlpg09/nNEbgZiwQ/3kNXs6/n/Xy9E=; b=lznWf4u7go45VCAuXZf0Rg3OMl Ywufe9D0eyKHTTEZJOIyhc+3dotmPHPOAQztncMMf8wlCIaFshjxE1ZBW//hoegYeCdGzzAv7vdug i5aNjqXV3Ufb9s4m0TDyC2ijb0FaQnSp0qrpAYmutS3R6FubhyeT73xFNjk+HQOXOLQ0=; From: Daniel Mendler Message-ID: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> Date: Thu, 20 May 2021 20:56:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) The recently introduced `icomplete-vertical-mode` should support the `group-function`, which can be specified by the completion metadata. The group function allows grouping the completion candidates by group titles. Additional to the default completion UI, support for group functions is already present in the following vertical minibuffer UIs, which are similar to `icomplete-vertical-mode`: Vertico (GNU ELPA), Selectrum (MELPA) and Icomplete-vertical (MELPA). From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Tue, 17 Aug 2021 12:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Gregory Heytings , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162920263811654 (code B ref 48545); Tue, 17 Aug 2021 12:18:01 +0000 Received: (at 48545) by debbugs.gnu.org; 17 Aug 2021 12:17:18 +0000 Received: from localhost ([127.0.0.1]:52018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFy1u-00031u-CY for submit@debbugs.gnu.org; Tue, 17 Aug 2021 08:17:18 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:56189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFy1r-00031e-Kd for 48545@debbugs.gnu.org; Tue, 17 Aug 2021 08:17:16 -0400 Received: by mail-wm1-f51.google.com with SMTP id w24so5799700wmi.5 for <48545@debbugs.gnu.org>; Tue, 17 Aug 2021 05:17:15 -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=Ighq9oQ/MFSOmpmzW+dmNK/G/Kj7GwqoAQ6xrI8ocUA=; b=XuzvJTftbmaDFQm/UcWNOzKDYz3ZJr0drpOQvafqCv8swD81M8hQuIy4LviBlPYrbD oU7MlwYuWwDKUdPzCsT5L4JCt66HOLYfH8keuNzYX+wQackyKQB/Ld34e4ECQiUB+sv0 EYcSUQg+BxozXLHcIRPF23GupByMc8bu3lulekU+8k1lNxSZ6kcL5rQZh8MVQ/7OX8Sg i/PrPJAYZ33v9ecYCXTZTgGkCJsK/OAj7rXComsDDVIPnJ1mNXiwTzsv7EkJeUmxj+et oUhqpcCp0oyvlIszNSTywJt8wmM5O+8AY6/NO55zi1+XM7jdOHqCjslHEtp8uXubaUX7 0wVw== 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=Ighq9oQ/MFSOmpmzW+dmNK/G/Kj7GwqoAQ6xrI8ocUA=; b=P2pdO84AzWTKcuvT5HAt3kacu8wMEt3fCERP8hQjeNe2CHrZ0vspXZs8F9yooonOv4 Dmlwlw2ZDoTwx8gY2amwylbXlpDib4Q3Nq/uobAm11KMZmDLsjYkq+CVEGvhqSyI5WHc 4jgxVBkMcaUOXi23s8LFKLAxJOrRBe9JI86qyLIQjJy2QJvakwZUit5sQQ3LzBg7OnIl SrYUgwvnkMLSWk2F2cd5ObgIiop5zfc40QWNuf/idzD71yO9+fLuXdOHOzGkb+E0U+QO 7scdqoiuvPnCGnM1GtJnyRYahvpHaUYgy/3GJ85TEtHDIONLkx+USa7HNNXNvn2OLVmy Cg7A== X-Gm-Message-State: AOAM532PI1QQacvpV1DAdBt+p2ZRioTXMwKKV0XkxlMmU+4E+YPOfXh9 tutqa2NAZc3nV4YMpK5MbsNwZ9RcnYY= X-Google-Smtp-Source: ABdhPJw0KTdzC3L9RxfDDxMu+9de5fjB8sHDVGtBx0+/I8hPTTGazt8hTCst7huBBNfz89+pgYdUgw== X-Received: by 2002:a1c:804a:: with SMTP id b71mr3032225wmd.141.1629202630096; Tue, 17 Aug 2021 05:17:10 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id e11sm2216960wrm.80.2021.08.17.05.17.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 05:17:09 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> Date: Tue, 17 Aug 2021 13:17:08 +0100 In-Reply-To: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> (Daniel Mendler's message of "Thu, 20 May 2021 20:56:07 +0200") Message-ID: <871r6sw9iz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Daniel Mendler writes: > The recently introduced `icomplete-vertical-mode` should support the > `group-function`, which can be specified by the completion metadata. The > group function allows grouping the completion candidates by group titles. > > Additional to the default completion UI, support for group functions is > already present in the following vertical minibuffer UIs, which are > similar to `icomplete-vertical-mode`: Vertico (GNU ELPA), Selectrum > (MELPA) and Icomplete-vertical (MELPA). I just tried (setq xref-show-definitions-function 'xref-show-definitions-completing-r= ead) To enable what seems to be the only table in Emacs core that has this feature with fido-vertical-mode. It seemed to do the right thing, prepending each entry with the name of its associated "group". Is this what it means to support this? If so, I'll close. Else, please explain what support you're looking for. Thanks, Jo=C3=A3o From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Aug 2021 09:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Gregory Heytings , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162927952726632 (code B ref 48545); Wed, 18 Aug 2021 09:39:01 +0000 Received: (at 48545) by debbugs.gnu.org; 18 Aug 2021 09:38:47 +0000 Received: from localhost ([127.0.0.1]:54901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGI22-0006vU-SV for submit@debbugs.gnu.org; Wed, 18 Aug 2021 05:38:47 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:37516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGI1z-0006vC-6l for 48545@debbugs.gnu.org; Wed, 18 Aug 2021 05:38:45 -0400 Received: by mail-wr1-f47.google.com with SMTP id l11so2502974wrx.4 for <48545@debbugs.gnu.org>; Wed, 18 Aug 2021 02:38:43 -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=WBq1nMXCuchMR7gDYXCzcNxkbyf8/A37Fv5vco3vMiM=; b=EGRPl8aThMNM5MjWZo5xyz800lS0GVsSQlPKcsmOE68ndU7M4dH6xmsCRFzm66AeYs qRNkYwFz9I3kz6cL084PCnUOqxrGEbJcoAyMZvDt+3X4BuK3tklK/GFa8/bRaAtZey/m bRykdHZRmHKfNC2PZkEFh9bGh8mQUJ/vRQ8M17VB1sLF1u3RgDLXR2ootTL7FBaEw3qi A7PO69bF++sxDN8EdN1GdHE6VZ3kz0lQEq6IWFe+d1eGn3/64D0+/SGuRAcsMKU+yrG2 3NzN2nlUx682JgUlmrzqoPGwGgJ++zP8/OTdMvbY33s+8CMTQViYGzQe8E9rpG7dfkRT 2JEg== 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=WBq1nMXCuchMR7gDYXCzcNxkbyf8/A37Fv5vco3vMiM=; b=R89JUy+mExBHcQcEwga2vxL81bhyJYm/kurE7Jut8TOsSo7qf7Fwc1wegZtXUEwvZz a7u1M6oyVU+eRNW7jzUGGpHrRplAUfcNTmjWSoYpFxCeUUqLp0Dcxy8PCAcI+W6cQIte PLHZ9mt/cJN+IUKbo6jDMhPVj3UCXpokRt6649qoaxpmLlndTH0ller5aBBOtf3Dbyub jP/T+jSGh8zXWugm5Bebn9QNxNeT5f/rlxLk4P6iYDhOLlmPWQ6l3T+RzuCqI6/a/kfb k2akbjgMfHONLPSyddcg258S9iWzRLLr8r3PiZSzlaWH79IdeAfONp4RaNGrWp1o5ych 1mwA== X-Gm-Message-State: AOAM530SduJQGLRil/Liasha4jT8dhamuPMiX7HOoZmzY6zx4qSek+ha wtrC+zpqrP6pYEH9Duvf0nEepUtJme4= X-Google-Smtp-Source: ABdhPJy/+wFJxNZgnTRM45eiWxxFlIiEZTkucy/w4AViHbZoEB4fOMGPk5sLlrKNP3bQmBaWiW26wA== X-Received: by 2002:a5d:620d:: with SMTP id y13mr9332405wru.45.1629279516974; Wed, 18 Aug 2021 02:38:36 -0700 (PDT) Received: from hirondell (static-136-181-62-95.ipcom.comunitel.net. [95.62.181.136]) by smtp.gmail.com with ESMTPSA id g11sm5379392wrd.97.2021.08.18.02.38.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Aug 2021 02:38:36 -0700 (PDT) From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec References: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> <871r6sw9iz.fsf@gmail.com> Date: Wed, 18 Aug 2021 11:38:35 +0200 In-Reply-To: <871r6sw9iz.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 17 Aug 2021 13:17:08 +0100") Message-ID: <87a6lfnld0.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > It seemed to do the right thing, prepending each entry with the name of > its associated "group". Is this what it means to support this? If so, > I'll close. Else, please explain what support you're looking for. I think Daniel is referring to what happens if you set completions-group to t and type e.g. C-x 8 RET ROMAN TAB TAB (without icomplete): you will see two "sections" titled 'symbol' and 'ancient-symbol'. Right now icomplete-vertical-mode does not make use of this information, AFAICT (unlike e.g. Vertico). From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Wed, 18 Aug 2021 09:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Cc: Daniel Mendler , Gregory Heytings , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162928051428240 (code B ref 48545); Wed, 18 Aug 2021 09:56:02 +0000 Received: (at 48545) by debbugs.gnu.org; 18 Aug 2021 09:55:14 +0000 Received: from localhost ([127.0.0.1]:54915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGIHy-0007LQ-Ei for submit@debbugs.gnu.org; Wed, 18 Aug 2021 05:55:14 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:44796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGIHw-0007L6-JK for 48545@debbugs.gnu.org; Wed, 18 Aug 2021 05:55:13 -0400 Received: by mail-wm1-f52.google.com with SMTP id l7-20020a1c2507000000b002e6be5d86b3so1388130wml.3 for <48545@debbugs.gnu.org>; Wed, 18 Aug 2021 02:55:12 -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=oVo23lSHLMzBxZmgMyi9vryc8cZn7qhAH9QNZUjExdw=; b=XSOyWFEEyCWXHJ2lQ6wmzVnWFr/74OeDUAQo8oc2qlLB4NoQ/nUeLC6LGxKUpbfOes AA2g8j8jeudMETCnctx0Z8f7xNNCTNIKgwCInMXWVZnOtdnaLAKPGK7EqO0kfYS5SjdU no3l910A/ldXa//Ry54/8mpOUHnFTeGILmTBmuMR/WzIy0c0Tsw4Bu05AY/qwhvG3t/1 qq/IQOvivV3x9Jn3jIPeA3O53OnTy4gnQiQUZGkDqbvj9fPm13o1cPvymiUpMlvxv8xZ PhVxJyqCxA9asSsx1v2Hj3aaxUxFXyGPqY8jhamuF+IUtIqfruWZLjj3IT6iEyUBoSd6 s8zg== 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=oVo23lSHLMzBxZmgMyi9vryc8cZn7qhAH9QNZUjExdw=; b=A1ZoDI5y6BF+DFD8A/Tr3ye7HjedSSedphPUZeFQze1/PTNINoqAhw3ESJKOrhbJPm zY1l9Ar+bupg2fE3To8WpFsQAaBDxcPkD512BgaGLtxhJiXlbe2wOKL/TydOOMtAYDOn nuaWpndiR6tlsQaVwKJVpwDBKlRXY8kIzU+bLyJIZTRXKeU2aouVP4q/i0B9M8RZhkh5 OS7k53ZSQFv0Dwyhut714pUrihBJS5fiuqBKJxxt6O6Rn0weK4WJoKz9tmZviebAi0n9 oa2iiLKtQ4fpWG5JwLMebLR72EjDXPjcvIaChNrSVl+KiN8M92cABGvBy2DpcCFG8Ylx JWNw== X-Gm-Message-State: AOAM532mI0BBS38BxhfmnFFBR+E21p/uFcJJr4fzFGa01uAGJIYWOOIR fC7fNtCdnZrLyVAWsnMWARxvF3MBLYcOAA== X-Google-Smtp-Source: ABdhPJx3Y+FO3m08HIGfHqDNuM9JlkDlmlyJvIPK0TJRLFUc0EJWDk6qF/NouxSaBBJ1ZixI3bL3MA== X-Received: by 2002:a7b:c1d7:: with SMTP id a23mr7755654wmj.69.1629280506176; Wed, 18 Aug 2021 02:55:06 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id k26sm5530505wrc.33.2021.08.18.02.55.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Aug 2021 02:55:05 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> <871r6sw9iz.fsf@gmail.com> <87a6lfnld0.fsf@gmail.com> Date: Wed, 18 Aug 2021 10:55:02 +0100 In-Reply-To: <87a6lfnld0.fsf@gmail.com> ("=?UTF-8?Q?K=C3=A9vin?= Le Gouguec"'s message of "Wed, 18 Aug 2021 11:38:35 +0200") Message-ID: <87eearulft.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) K=C3=A9vin Le Gouguec writes: > Jo=C3=A3o T=C3=A1vora writes: > >> It seemed to do the right thing, prepending each entry with the name of >> its associated "group". Is this what it means to support this? If so, >> I'll close. Else, please explain what support you're looking for. > > I think Daniel is referring to what happens if you set completions-group > to t and type e.g. C-x 8 RET ROMAN TAB TAB (without icomplete): you will > see two "sections" titled 'symbol' and 'ancient-symbol'. Thanks you, easy to reproduce and see clearly what you mean now that you've filled the missing information in this bug report. > Right now icomplete-vertical-mode does not make use of this information, > AFAICT (unlike e.g. Vertico). That's right. I guess I'll copy Vertico's UI here, it seems reasonable. Jo=C3=A3o From unknown Fri Aug 15 16:24:27 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Daniel Mendler Subject: bug#48545: closed (Re: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function`) Message-ID: References: <871r6pr8bk.fsf@gmail.com> <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> X-Gnu-PR-Message: they-closed 48545 X-Gnu-PR-Package: emacs Reply-To: 48545@debbugs.gnu.org Date: Thu, 19 Aug 2021 11:20:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1629372002-28564-1" This is a multi-part message in MIME format... ------------=_1629372002-28564-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-func= tion` which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 48545@debbugs.gnu.org. --=20 48545: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D48545 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1629372002-28564-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 48545-done) by debbugs.gnu.org; 19 Aug 2021 11:19:07 +0000 Received: from localhost ([127.0.0.1]:58652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGg4g-0007PS-S9 for submit@debbugs.gnu.org; Thu, 19 Aug 2021 07:19:07 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:53078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGg4f-0007Oy-I0 for 48545-done@debbugs.gnu.org; Thu, 19 Aug 2021 07:19:06 -0400 Received: by mail-wm1-f45.google.com with SMTP id f10so3625513wml.2 for <48545-done@debbugs.gnu.org>; Thu, 19 Aug 2021 04:19:05 -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=i4DvC/ck90L/Sp/P5rMpnFOYI6QWg+tDLB1+xdcStGA=; b=DSIUezm4YjeHINT6DCfAK5PxQnORWM9xITtDlRi4zm2GUyCfLJVWmVgwvsIYxaeeFj cCMUG9KdU0nUEgj6E2Fi7mnvBB8ZkCm+Hv6RCFKCjHzZOCqnwkxLyvQ7qamXG2VTXiDm m7UU0jggTp3x/1OnYxUEjngLDV5ESsR2SwU07MuE8Bg0V5pdKHljOVHw+5FS6V4FNcI+ PPRC/7mtYIsz8XTcMcsKM0s/OKK5DEvNx91qfnMyoPpvagEm6oFjsai4ZlG8CKTj0Aap ZvdvB8/KxE8eZNcnki+0vd/6lBtzTf/HvsDrI3KQzfBdg1SFYNKiJjBrbvDW63jdiM6V I4Zg== 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=i4DvC/ck90L/Sp/P5rMpnFOYI6QWg+tDLB1+xdcStGA=; b=Uh8wzQs9UzBRL4IHE8aUJVeesL6oQpZCK2fXgTnylY0nXHQL0oW7FWzO9kP5cvgK/v Q9lvk0rO3RR8E46HpLBzHfA1/R3UruKPTLUQhn1wrKqCeCoO6GrBElwoaU5yB5b0t3A9 HiOKk/d4LALssgrwcNtKWY8Xx0NYSDVTq8VHLu5518kupzNOxfSqaCQpIcovbf7dEpaZ rzHlsanNVjmTzgG8xGIesiGnXpExAbyAJHVJwB2cy8O1PvF+oyjJytUAYAMixE0UAs+y WBDEVzQtqDN6OvVkU5gb2SkcBbDjkiTNKOYzV8qf35kyGI8Rs01ULcnbi30jV1IR52k6 qitg== X-Gm-Message-State: AOAM532R3420rMRFpyD5+pAvOi9ua/zFVa5tvUp5qZ76tmKfnworxYA2 3uOqrFA7uopIXqi6IBBgHPw= X-Google-Smtp-Source: ABdhPJz5cW2xQGY+7oPdjfscgQrA7ethOXi5WNAjabpTAUU/k7PGxFENRe0n/4U/p3yTx8cAm9xfnQ== X-Received: by 2002:a05:600c:358c:: with SMTP id p12mr4006390wmq.173.1629371939640; Thu, 19 Aug 2021 04:18:59 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id c8sm2579631wrx.53.2021.08.19.04.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 04:18:58 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: =?utf-8?Q?K=C3=A9vin?= Le Gouguec Subject: Re: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` References: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> <871r6sw9iz.fsf@gmail.com> <87a6lfnld0.fsf@gmail.com> <87eearulft.fsf@gmail.com> Date: Thu, 19 Aug 2021 12:18:55 +0100 In-Reply-To: <87eearulft.fsf@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 18 Aug 2021 10:55:02 +0100") Message-ID: <871r6pr8bk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48545-done Cc: Daniel Mendler , Gregory Heytings , dgutov@yandex.ru, 48545-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [Dmitry, I've tagged you since you're generally interested in this stuff.] Jo=C3=A3o T=C3=A1vora writes: > K=C3=A9vin Le Gouguec writes: >> I think Daniel is referring to what happens if you set completions-group >> to t and type e.g. C-x 8 RET ROMAN TAB TAB (without icomplete): you will >> see two "sections" titled 'symbol' and 'ancient-symbol'. > Thanks you, easy to reproduce and see clearly what you mean now=20 I've pushed this feature. This is how I tested: src/emacs -Q --eval '(setq completions-group t)' \ --eval '(setq xref-show-definitions-function (quote xref-sho= w-definitions-completing-read))' -f fido-vertical-mode C-U M-. xref-location-marker RET This should produce 5 locations. It shows, with section headers, how 4 of these belong to xref.el and 1 belongs to elisp-mode.el. When typing a pattern which leads to filtering (e.g. with flex) sections are preserved. Sane scrolling should also be maintained, though this was complicated to get right and may still have some bugs (I haven't noticed any yet.) I noticed a quirk, though. If I add '-l etags' to the 'emacs -Q' line, one gets 6 matches instead of 5 (due to etags having another xref-location-marker). That's fine, but due to the default alphanumeric/length sorting, it gets shoved into the group of xref.el matches and thus we get two xref.el groups. I.e. it looks like xref.el (cl-defgeneric xref-location-marker)=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 (cl-defmethod xref-location-marker ((l xref-file-location)))=20=20 (cl-defmethod xref-location-marker ((l xref-bogus-location)))=20 etags.el (cl-defmethod xref-location-marker ((l xref-etags-location)))=20 xref.el (cl-defmethod xref-location-marker ((l xref-buffer-location))) elisp-mode.el (cl-defmethod xref-location-marker ((l xref-elisp-location))) I don't use completions-group so I don't care strongly for this, but I believe that this is generally undesired, for non-filtering scenarios. All the entries from the xref.el group should probably be clumped together. If a user were flex-matching and thus expecting certain sort score-based order, it _would_ make sense to me, but here no flexy things were happening at all. To fix this, perhaps the default sorting methods should be turned off in completion-all-sorted-completions in minibuffer.el if a table supplies `group-function`. A patch for this is after my sig. Alternatively, tables that do support `group-function` could also start specifying: (display-sort-function . identity) I've tested both alternatives and they seem to do the right thing. But this may be the subject for some other bug, if someone cares. Anyway, I'm marking this closed this bug since its main work is done. Feedback welcome, of course. Jo=C3=A3o diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index ffcd5d88ab..20fbc326a2 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1506,17 +1506,18 @@ completion-all-sorted-completions (setq all (delete-dups all)) (setq last (last all)) =20 - (if sort-fun - (setq all (funcall sort-fun all)) - ;; Sort first by length and alphabetically. - (setq all (minibuffer--sort-by-length-alpha all)) - ;; Sort by history position, put the default, if it - ;; exists, on top. - (when (minibufferp) - (setq all (minibuffer--sort-by-position - (minibuffer--sort-preprocess-history - (substring string 0 base-size)) - all)))) + (cond (sort-fun + (setq all (funcall sort-fun all))) + ((not (completion-metadata-get all-md 'group-function)) + ;; Sort first by length and alphabetically. + (setq all (minibuffer--sort-by-length-alpha all)) + ;; Sort by history position, put the default, if it + ;; exists, on top. + (when (minibufferp) + (setq all (minibuffer--sort-by-position + (minibuffer--sort-preprocess-history + (substring string 0 base-size)) + all))))) ------------=_1629372002-28564-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 20 May 2021 18:56:14 +0000 Received: from localhost ([127.0.0.1]:35214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ljnqA-0000Uw-G0 for submit@debbugs.gnu.org; Thu, 20 May 2021 14:56:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:52774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ljnq9-0000Up-9n for submit@debbugs.gnu.org; Thu, 20 May 2021 14:56:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljnq9-0001wB-16 for bug-gnu-emacs@gnu.org; Thu, 20 May 2021 14:56:13 -0400 Received: from server.qxqx.de ([2a01:4f8:121:346::180]:37925 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljnq7-0001JN-L0 for bug-gnu-emacs@gnu.org; Thu, 20 May 2021 14:56:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rKNFO4t4dGjdIDlpg09/nNEbgZiwQ/3kNXs6/n/Xy9E=; b=lznWf4u7go45VCAuXZf0Rg3OMl Ywufe9D0eyKHTTEZJOIyhc+3dotmPHPOAQztncMMf8wlCIaFshjxE1ZBW//hoegYeCdGzzAv7vdug i5aNjqXV3Ufb9s4m0TDyC2ijb0FaQnSp0qrpAYmutS3R6FubhyeT73xFNjk+HQOXOLQ0=; To: bug-gnu-emacs@gnu.org From: Daniel Mendler Subject: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Message-ID: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> Date: Thu, 20 May 2021 20:56:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Gregory Heytings X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) The recently introduced `icomplete-vertical-mode` should support the `group-function`, which can be specified by the completion metadata. The group function allows grouping the completion candidates by group titles. Additional to the default completion UI, support for group functions is already present in the following vertical minibuffer UIs, which are similar to `icomplete-vertical-mode`: Vertico (GNU ELPA), Selectrum (MELPA) and Icomplete-vertical (MELPA). ------------=_1629372002-28564-1-- From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 12:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 48545@debbugs.gnu.org Cc: mail@daniel-mendler.de, Gregory Heytings , joaotavora@gmail.com, dgutov@yandex.ru Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162937671920078 (code B ref 48545); Thu, 19 Aug 2021 12:39:02 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 12:38:39 +0000 Received: from localhost ([127.0.0.1]:58773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGhJf-0005Dm-3C for submit@debbugs.gnu.org; Thu, 19 Aug 2021 08:38:39 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:38736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGhJd-0005DZ-4o for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 08:38:37 -0400 Received: by mail-wr1-f52.google.com with SMTP id u16so8908782wrn.5 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 05:38:37 -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=WSOgQt1EhrA3Ib5OHY7h9Qnr8G0yV6mqEKacgOD2q/U=; b=sCe4d+KFF0dwzKbP0TbCKm6wwiMvu/SP1rxb9839Bxoja+X6d8XwaNLPuRG8rvH9MI CD/uBU2FFgHPG9KvF9zT2LqJLASEgiYSrEDq5VclKxSnydApyVqj6T5cegzjEuJxAtCp lSKeRPI7l1ZDEp6qM6UbL1pgQ9FAPiO4ZS5vYTc96vY1uNlKGT2pa9xfq570kPnns1mt OKtQoyVu33dsN9ufGmaz1zXtKzf6uSIEXaMFgS8GRX7R7guzhoiNwC+S7kz9Es/uc9y7 08Nfgvj8iekBTKSVEvZBbbaMW/Yfz+fbkeLcs3J0LWYtjVa3AQndmOK0FkzpHglTQ9/l Y7Lg== 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=WSOgQt1EhrA3Ib5OHY7h9Qnr8G0yV6mqEKacgOD2q/U=; b=L6puRAdEJbFkALWLopguM2wJzSoOCt4yTFVZPLG75JmhEuvIpCE290rTJ9cKWs4pLO M3XQ2KNEM6ZEjlo7p7LLLdwXlUtR3F4M2oCwgrRnXl2k7kaHD98kkh66z2WRN6PqX3XK zp+GFpTqlyQ1eiEb6ii3RmkYH4S9IS8zLxR2yMwnjjxQJO/KJLB4TvU3IN+XgyAMF85k AfaX2TnpWMvJ5AK9F+hfu77HJX5BnGRye3/n46kpllCU7dkP5lFf1Zjs53KzhfY5eJuH /ZSh3GhEBM0m/DBQmU4JuO3G2mHq/oo4IeDf3sfyXrDipWR5PQb//3WaCYAoIpqGX1E+ m1vA== X-Gm-Message-State: AOAM530inV/mU/rO3bDj6+EKuc6yLzlvHICKH8y+g9l6xHE8Q/usDIKE DCE3KVs3qD+bVOgSvBKyXw4= X-Google-Smtp-Source: ABdhPJyuIxIjRTF3zw0p+aa5hdHSzQFRkojDaYlu5jJ1IHzK2HTfNIHXaKNzi2PX2jcu3VxSAo/Scw== X-Received: by 2002:adf:e507:: with SMTP id j7mr3708602wrm.113.1629376711254; Thu, 19 Aug 2021 05:38:31 -0700 (PDT) Received: from hirondell (static-136-181-62-95.ipcom.comunitel.net. [95.62.181.136]) by smtp.gmail.com with ESMTPSA id b10sm3478208wrn.9.2021.08.19.05.38.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 05:38:30 -0700 (PDT) From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec 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> Date: Thu, 19 Aug 2021 14:38:29 +0200 In-Reply-To: <871r6pr8bk.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Thu, 19 Aug 2021 12:18:55 +0100") Message-ID: <87zgtdd2yi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > To fix this, perhaps the default sorting methods should be turned off in > completion-all-sorted-completions in minibuffer.el if a table supplies > `group-function`. A patch for this is after my sig. FWIW (I didn't take the time to understand the ins and outs of the completion system nor the changes that are being made; sorry about that), with this tentative patch, Icomplete seems to honour read-char-by-name-sort. With icomplete enabled and read-char-by-name-sort set to 'code, try C-x 8 RET CLOCK FACE - with the current master branch, the completions are sorted alphabetically, - with the tentative patch applied, the completions are sorted by code point. This seems to compose well with completions-group AFAICT (see e.g. C-x 8 RET ROMAN). At any rate, thanks for teaching icomplete-vertical about group-function! From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Thu, 19 Aug 2021 13:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Cc: Daniel Mendler , Gregory Heytings , Dmitry Gutov , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.1629379777705 (code B ref 48545); Thu, 19 Aug 2021 13:30:03 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 13:29:37 +0000 Received: from localhost ([127.0.0.1]:58855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGi6z-0000BJ-3n for submit@debbugs.gnu.org; Thu, 19 Aug 2021 09:29:37 -0400 Received: from mail-pg1-f175.google.com ([209.85.215.175]:36768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGi6x-0000B5-KU for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 09:29:36 -0400 Received: by mail-pg1-f175.google.com with SMTP id t1so5909818pgv.3 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 06:29: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; bh=4ZI+hELIcG7H2ldPx/0jfqWDeNIpSBfBgCHJEkbEm1k=; b=ZXY8Lzl/932Bsy3XTOQrP1xwOpYbVuMdmYNHde3tK4wGNqqPLsqdzuarfEpN+t8n6R Wpb8aBMSpw16viXqfMCn5BxrLTSY5hN8IIvklphybJGU1T9zGEyAIawa5RoIqZp2sPQh yWjDF6FnbF1BwL+CCvlega6dBiybjiJ/3KULNNchi90Z6npT5o6qh+5/zPidkAFZa+Jk YfuCZ3HIBAbADTSlJhUkbiHDFxXWaClgzeFpRcF4uX17uYfZYFEgWG5PWpSFG9teFQ+3 lJfHb2yEb5Nkwa7iDrMqMc0jgvm3l286T9/gYG3er12ejKkhPdTDJzX4pnjftvsT4d/x ejGA== 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; bh=4ZI+hELIcG7H2ldPx/0jfqWDeNIpSBfBgCHJEkbEm1k=; b=EXFvGSxTbE5Sl33NXCzMqM8TeZrtErl8wBsx3dLTFnFNDIzA0jwnpaezniX49Lh4Kj a3h6ME0EgBIYNUCHB9tmHKkiTVGoo10hcCL7OfMI9MP4SInHbi3vqTJq3FQsIYikaPmx QyN/+hmv1vPU7ZKUSgP2R/u+5sO8cXod2Q+XcnQzyZ9HRkOeEtwV0DZgj/m0NqUGEwqf fG+RzagwPwRuvSeCQVufuaJw8N5E3+OefJD7OWLC380zAe0PYqwzUoVNNh1Z1F4SqMrV f6C80VZjIBp0kvJiaVIdrTuy/PKlMPWpHBwbKU3HLoAtsVAafOzSLaAJnrvTqdcN+lQD +7bw== X-Gm-Message-State: AOAM532HZg+QKRvs2CawZroP5PfwmTetj1vf+c+SWp65fJSGZgYfGIrk ntWlsy7CKfXig6sGbMTp8rVKlqgfia9MtIkOkQM= X-Google-Smtp-Source: ABdhPJy3zvDTcOh8V5lgkm5dEvqPPEpf2wD1TVElg3DJx7dUkRyGW2/OmVKCXFnYS9hma21RCMO78LrYD7Pp+8ia5L8= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr14701115pfo.2.1629379769657; Thu, 19 Aug 2021 06:29:29 -0700 (PDT) MIME-Version: 1.0 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> <87zgtdd2yi.fsf@gmail.com> In-Reply-To: <87zgtdd2yi.fsf@gmail.com> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Thu, 19 Aug 2021 14:29:17 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000005febf005c9e98ab4" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000005febf005c9e98ab4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 19, 2021, 13:38 K=C3=A9vin Le Gouguec wrote: > Jo=C3=A3o T=C3=A1vora writes: > > FWIW (I didn't take the time to understand the ins and outs of the > completion system nor the changes that are being made; sorry about > that), Don't beat yourself over it, it's not an easy or pleasent thing to understand. with this tentative patch, Icomplete seems to honour > read-char-by-name-sort. With icomplete enabled and > read-char-by-name-sort set to 'code, try > > C-x 8 RET CLOCK FACE > > - with the current master branch, the completions are sorted > alphabetically, > - with the tentative patch applied, the completions are sorted by code > point. > Yes I think that's the idea. But do you think that's good or bad? This seems to compose well with completions-group AFAICT (see e.g. C-x 8 > RET ROMAN). > This is good, right? Jo=C3=A3o > --0000000000005febf005c9e98ab4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 19, 2021, 13:38 K=C3=A9vin Le Gouguec <kevin.legouguec@gmail.com> wro= te:
Jo=C3=A3o T=C3=A1vora <joa= otavora@gmail.com> writes:

FWIW (I didn't take the time to understand the ins and outs of the
completion system nor the changes that are being made; sorry about
that),

Don't beat yourself over it, it's not an easy or pleasent thing = to understand.

with this tentative patch,= Icomplete seems to honour
read-char-by-name-sort.=C2=A0 With icomplete enabled and
read-char-by-name-sort set to 'code, try

=C2=A0 =C2=A0 C-x 8 RET CLOCK FACE

- with the current master branch, the completions are sorted
=C2=A0 alphabetically,
- with the tentative patch applied, the completions are sorted by code
=C2=A0 point.

Yes I think that's the idea. But do you think that's good or bad= ?

=
This seems to compose well with completions-group AFAICT (see e.g. C-x 8 RET ROMAN).

=C2=A0This is good, right?

Jo=C3=A3o
--0000000000005febf005c9e98ab4-- From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 15:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 48545@debbugs.gnu.org, joaotavora@gmail.com, mail@daniel-mendler.de Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162938538720012 (code B ref 48545); Thu, 19 Aug 2021 15:04:02 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 15:03:07 +0000 Received: from localhost ([127.0.0.1]:60622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGjZT-0005Cg-1Q for submit@debbugs.gnu.org; Thu, 19 Aug 2021 11:03:07 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:34644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGjZR-0005CD-Dx for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 11:03:05 -0400 Received: by mail-wr1-f44.google.com with SMTP id h13so9641492wrp.1 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 08:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Voix9ZxoIQKodYOZ2v5rjl2PAgNMEiejwcRHYq6guWY=; b=XydnGIArw799qaDckQEbUKxexxLJ4NhSo1NjuxI4d5Law6d9/TbPrB3FthGD1VOzFW t5RAtHADJKqVX2GmWJYilLPLjCAJyPdLCMo+Yal0+nSk8bCyIKkAwzG2fWjwrWE5lJNy PXfcnhB8flll3Rzen7glJZ3SuejIO025hsGtDk59iXrV91Yf4b/tFIKj8yOhgpEdSppm afp+Fo+HRhRmMFd+TnpeDzPHB6nOrtebGAWP5vSxFkdvMgiEiNM3FGmXWflgMaRvIyRO 1vrebzSFxFdycf17Q5bVtPwFlisrfXiWExHaTde8/w+miu8wB6RvN3EWu2zpfyO1Eym/ 3gBw== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Voix9ZxoIQKodYOZ2v5rjl2PAgNMEiejwcRHYq6guWY=; b=EMWevYy0k2IDVUK/z5En53CE5XUMcvbeh4RuE6+OjQimrPXbomrYaktMTFYve33G31 W5oZeTok6N8MqBHYWU369NxTw4T6GGBtrLnQwx5nqZA9+vosIAPelHSCWOJY+iIZTWsq XFISWmjroDrhRlUx4U4falDt1mIxjzFeGYh89sqNPnMNlKYQPihm4k2qmu2mo7b/FQ0y D2Jhn0V1LyYFcv5SczG5C061Hf1dNCQDM64ieGN7DGjxUTNtdcIHsaUuEDP7T+sEOzTb m11LQwhQCwVNxhdtw/GuurdomcpoBQYNsCDc1fIIqwHkpaMOxtnUeriR546Kj7fr+tZF ZNcw== X-Gm-Message-State: AOAM532TTP+BSQkQJJAQ87YfZM1ZqF9ro9w75vpE30lPrp7eWrP5mJeU M+5Wr5AXs/DPJ9C/O39Vq+0= X-Google-Smtp-Source: ABdhPJzkfSWnuHtGCFhBEvc0hAyWIxbSE5BaiTXgwsiIsvoTHYgnGGLVqOaKjTTEcRfblCTFcc5avQ== X-Received: by 2002:adf:f4cf:: with SMTP id h15mr4436021wrp.67.1629385379567; Thu, 19 Aug 2021 08:02:59 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id x18sm3140740wrw.19.2021.08.19.08.02.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 08:02:58 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: <54e4e409-5525-b796-9e9c-582735995cc1@yandex.ru> Date: Thu, 19 Aug 2021 18:02:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <871r6pr8bk.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 19.08.2021 14:18, João Távora wrote: > I noticed a quirk, though. If I add '-l etags' to the 'emacs -Q' line, > one gets 6 matches instead of 5 (due to etags having another > xref-location-marker). That's fine, but due to the default > alphanumeric/length sorting, it gets shoved into the group of xref.el > matches and thus we get two xref.el groups. I.e. it looks like > > xref.el > (cl-defgeneric xref-location-marker) > (cl-defmethod xref-location-marker ((l xref-file-location))) > (cl-defmethod xref-location-marker ((l xref-bogus-location))) > etags.el > (cl-defmethod xref-location-marker ((l xref-etags-location))) > xref.el > (cl-defmethod xref-location-marker ((l xref-buffer-location))) > elisp-mode.el > (cl-defmethod xref-location-marker ((l xref-elisp-location))) > > I don't use completions-group so I don't care strongly for this, but I > believe that this is generally undesired, for non-filtering scenarios. > All the entries from the xref.el group should probably be clumped > together. If a user were flex-matching and thus expecting certain sort > score-based order, it_would_ make sense to me, but here no flexy things > were happening at all. > > To fix this, perhaps the default sorting methods should be turned off in > completion-all-sorted-completions in minibuffer.el if a table supplies > `group-function`. A patch for this is after my sig. We discussed this problem when group-function was introduced. Another approach is to just change the method of grouping: first the completions are sorted, and then they are sorted into groups. The group that goes first is the group to which the first completion in the sorted list belongs to. It doesn't matter whether some of the subsequent items in it are sorted at the end of the list: as long as they return the same value for "group", they get put into that first group. I wonder which strategy Daniel ultimately chose to use in Consult. Perhaps we should document it in the API, so that the implementations stay consistent. From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` In-Reply-To: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 19:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Gregory Heytings , Dmitry Gutov , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162940181815045 (code B ref 48545); Thu, 19 Aug 2021 19:37:01 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 19:36:58 +0000 Received: from localhost ([127.0.0.1]:60818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGnqT-0003ub-O0 for submit@debbugs.gnu.org; Thu, 19 Aug 2021 15:36:57 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:46758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGnqQ-0003uM-U4 for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 15:36:55 -0400 Received: by mail-wr1-f48.google.com with SMTP id f5so10643322wrm.13 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 12:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=B5hCNHYRO6EnGaBf3PL6ho6RYKu7PDVse1W1wLXbWvg=; b=oXdKHgLitD5EpZg4KHYuz35hY6PfK+2EEg1VXimRoGL+ZUSGPzRxnOlCBGgVT/Rd6X AqvF5zkz/vdctdbAPAki1OkQEtUxy8maoO0i7I0tlaQgiEKe/9eXZumyYV+2tDhzDvMb A0eqppUV1SGFWXnm0rePTwnI38KVq7+Xrc9uvWnDA2Q5LERkiFSi91SXyNlMV2UNXUFK 0yxQ0kGmmcrJVYwULBMubwO2yrmzZnhYXSvxSOUPHnpXSSb7bGjc7WWZlxg57zIM+CN/ cEeAyxLvHlzSeoTB7+X2ubNbRzwQkQ98SNwzvkU/xc34yLe1bmoH+ZWLxOqhFst2oZUo YNeA== 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:message-id :user-agent:mime-version:content-transfer-encoding; bh=B5hCNHYRO6EnGaBf3PL6ho6RYKu7PDVse1W1wLXbWvg=; b=D9tfPLOLCSZYIWhxtT1p7wD2ZRZqKfMirJ8QehxZ09blXt1uDh8P3yG7HQQ3ZAEnM7 berffrEGRyvDUkX4La9/YsXxtyQZzKlACpLSZ0w57ECZEhlsfhv+r187mkfdTYlqxqUp frzDZYMO7fhvuHtc+zBED4K7jd1bP+ZswbZ3Y+HNV4yRwCneJFRs3wu2rr1mQCkqv7Pt eeP6j6CN4WZckbdnt3bmNEy+ZgWoANU3K1uujR0MHBD8NoLjow6xTxDuubp5LIis4kIy 2ceS3gZ0FqDFHXHV1+lznlv3G6rvDCUiCHK1y88b9QRsucqj2AmZ9edGu8CBV2Ic8AoT fMqg== X-Gm-Message-State: AOAM531Vw8g7da36MQ/C5DOyAR8ikkB+HQnicFCU3r8pBel5sbCW6Wlq luzyAchQM1CUT3NxXT31ruk= X-Google-Smtp-Source: ABdhPJyDMGUR8s34x4aGUyeOTiKravqUaEqec21bH/rEVXaaVv6sa0/04jcgiCcMuB2+vzARGh6z1w== X-Received: by 2002:a5d:4fc9:: with SMTP id h9mr5866379wrw.2.1629401808985; Thu, 19 Aug 2021 12:36:48 -0700 (PDT) Received: from hirondell (static-136-181-62-95.ipcom.comunitel.net. [95.62.181.136]) by smtp.gmail.com with ESMTPSA id h126sm8770579wmh.1.2021.08.19.12.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 12:36:48 -0700 (PDT) From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec 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> <87zgtdd2yi.fsf@gmail.com> Date: Thu, 19 Aug 2021 21:36:47 +0200 Message-ID: <87k0khteeo.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > FWIW (I didn't take the time to understand the ins and outs of the > completion system nor the changes that are being made; sorry about > that),=20 > > Don't beat yourself over it, it's not an easy or pleasent thing to unders= tand. (It's not for lack of trying either *cough*bug#40152*cough*) > with this tentative patch, Icomplete seems to honour > read-char-by-name-sort. With icomplete enabled and > read-char-by-name-sort set to 'code, try > > C-x 8 RET CLOCK FACE > > - with the current master branch, the completions are sorted > alphabetically, > - with the tentative patch applied, the completions are sorted by code > point. > > Yes I think that's the idea. But do you think that's good or bad? Apologies, my message was fairly clinical and lacked emphasis. Icomplete heeding read-char-by-name-sort? Yes please! =F0=9F=91=8D for th= is tentative patch. > This seems to compose well with completions-group AFAICT (see e.g. C-x 8 > RET ROMAN). > > This is good, right? Yes, also good =F0=9F=91=8D From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Thu, 19 Aug 2021 19:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: mail@daniel-mendler.de, 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162940210915492 (code B ref 48545); Thu, 19 Aug 2021 19:42:02 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 19:41:49 +0000 Received: from localhost ([127.0.0.1]:60822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGnvB-00041n-9a for submit@debbugs.gnu.org; Thu, 19 Aug 2021 15:41:49 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:52135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGnv9-00041Y-UL for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 15:41:48 -0400 Received: by mail-wm1-f41.google.com with SMTP id u15so4499945wmj.1 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 12:41:47 -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=sZ3OZo6f+zKjjLtAYZh7S86fTvQuECWXAKQhuTnmOvQ=; b=UG9cBDapNtohqd6PgehLgeSwpKGdNPJt+5bGmEu7SAA19oVgVIMLeV5U6f/2VfdQ71 oeJv4p1uqtts2ArThpazHRcp/XEkIOBcla1ChT7v0T7VKqWfvUvOVPub779qhgg+J+9v brULCgp/BdJnV8iCmpPd4eCZwo8hBOu4JBl8lEuYor+RNXIY2zVThSHXqQCOluVs2Sah wN3OECaOQylcJt/vDDifjls85sOfP49uT7QuWsUvfKiXw4hHbldrqTBvlFGwFcAVLr1Z pJP80u8Nb9KSJKZfTNs9OSLoELWCtvCdVAGwOwF51+xCGOxPWakoXSVpvymgm7HrvKZa 4mNw== 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=sZ3OZo6f+zKjjLtAYZh7S86fTvQuECWXAKQhuTnmOvQ=; b=KqfhCbWhOkK766ZGhPeovtdk5R4C+Foji6Yi60TvCFbZn7/jKzg1hAoFI+uKHfMHCJ idRIV0dZkf+A6jB/OjOqOaHdGO04n77L9PWXpujmIt4ZLdijcM+sHhyQhLXQ5mbAFmgB veaGdKBLTanJzastx5HkB3gXkZxv6Fe6b2GGs1l/2ey0Rxdxld+jWTdFq2qN5VDwSySm 39qXNUjIEAd9FQxGt2DeyEtiC1wwn1vGWUzOxq/Za2La3x298o9f2UwYdmdQJHljnUm5 +2KkUJKZ0IAZgtFrB0KOm+KokrVL5mBBKcKiOfYfpigYeh5ea3qY/pU29w0B17q6CyOi BA1g== X-Gm-Message-State: AOAM533rsJ23EMGmdUzfM3njMOwiPkpfpSF6LROzp8q3U6UC0vN1IKaq DgJa3CmHjxMHHGO3bW0XO58= X-Google-Smtp-Source: ABdhPJz8F3AtltFHoHjHRjyBq3tn32qfi36QH9sRqQ29el/mmaZYyhSAaEUKGV7/zedW42kN80s/bA== X-Received: by 2002:a1c:7719:: with SMTP id t25mr299359wmi.130.1629402102270; Thu, 19 Aug 2021 12:41:42 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id k13sm2964378wms.33.2021.08.19.12.41.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 12:41:41 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> Date: Thu, 19 Aug 2021 20:41:38 +0100 In-Reply-To: <54e4e409-5525-b796-9e9c-582735995cc1@yandex.ru> (Dmitry Gutov's message of "Thu, 19 Aug 2021 18:02:57 +0300") Message-ID: <87r1epp6h9.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 19.08.2021 14:18, Jo=C3=A3o T=C3=A1vora wrote: >> completion-all-sorted-completions in minibuffer.el if a table supplies >> `group-function`. A patch for this is after my sig. > > We discussed this problem when group-function was introduced. Another > approach is to just change the method of grouping: first the > completions are sorted, and then they are sorted into groups. That's a possiblity. But it might be performing too much work, at least at first sight. For the C-x 8 RET case and the xref table (the only tables I know which use this) things seem to be naturally put into groups already. So sorting them alphabetically, by length, by history, and _then_ destroying most (but not all) with the grouping could be not so interesting if the there's a big a price to pay. I recommend whatever is done that some quantitative benchmarking is performed to the before/after. Enabling fido-vertical-mode and pressing C-u C-x C-e C-m after (benchmark-run (call-interactively 'insert-char)) Seems to be a decent way to measure. Currently, with the alpha/length/history sorting, it takes about 1 second in my machine. Without any sorting (and the natural grouping), takes about 0.6 seconds. You should measure what the re-grouping sorting does. Jo=C3=A3o From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 22:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: mail@daniel-mendler.de, 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162941268432300 (code B ref 48545); Thu, 19 Aug 2021 22:39:01 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 22:38:04 +0000 Received: from localhost ([127.0.0.1]:60926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGqfk-0008Ou-Gj for submit@debbugs.gnu.org; Thu, 19 Aug 2021 18:38:04 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:40750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGqfi-0008OQ-4M for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 18:38:03 -0400 Received: by mail-wm1-f46.google.com with SMTP id x2-20020a1c7c02000000b002e6f1f69a1eso7775914wmc.5 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 15:38:02 -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=iLMfRo+gKaK0U6gJPLm5EJLfb9FFDFK4xWg1VnOavL4=; b=rLQX7gNahwYBKbInjQvLKmXMNG1OkozqESb37eZq5BijciUhJKK6mCrZg4/0nqam5w TvayCAUSsvC1QqC9L1Swi52SNtT91jnsnnzDEsUR3El4uTYlwP06afp+Dxbgy8WYDdjd yMSclf7kJ3UCxfrVJ2/GRsR1/dq9dHIyV+z357QILuUsgPZwKCmnR0AZGwkEeKPIjamQ mMyQHVCdjZELqNZNllNXpw797v8vjm0cX3VrndpfDugGDEF2F+G0nlZe9QtApCJN7551 vTp2mqrkVMNUMH8l5DRwcn+n5Z+FON8p0uYB/qvqoU/Tw9ONPFFuiM2fi6Aq/49RHXAT 5NAA== 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=iLMfRo+gKaK0U6gJPLm5EJLfb9FFDFK4xWg1VnOavL4=; b=nqIioFpLuJwQuH5K2fee8+of5Bi8LBrkOo79xa1tHSFPuDMrKEJppMTdMSDf766jlp Xr1CawpM0krUlja6hNhfRwayeB/FsnWDQxlQrOiBAKI3feefQLs7ArRW/WsrS3AAXwAC yGmwCxUbebeilGofFKRNAMYsrEy5kxaXO63aRj2xVwN1C/25c94/7SYgzADt+Nkpp3Ns MPPT68kBjz5yGWKkC8AKBHGB9WYAMQ2SoBWdYBphuUL4zhXf8jEWvqh01U77NVFg7vQb wDy+/AD11kOLR9y5wD2y2A2J9O5Lq2xF9qpcHS03VnONTgfftQ6PqyoodDaDGddA/xqR 5opA== X-Gm-Message-State: AOAM5313r2oacAItWdvHPea8mjkOeVek408stQDqXnYi+w4qR+ZH+BSq EgAEaSOPgra/m1/8SBuaPe30bhjf+X4= X-Google-Smtp-Source: ABdhPJzL8VxDS3C5U3sIq++9Vls/PxCd2DSmWS0pIjMsXFNuwl+8T+ERDjDFDmLuRzcX25hB1LE5yA== X-Received: by 2002:a7b:c309:: with SMTP id k9mr841412wmj.48.1629412676312; Thu, 19 Aug 2021 15:37:56 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u10sm4045520wrt.14.2021.08.19.15.37.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 15:37:55 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: <266d8a54-90de-e904-f548-8ec29e52923c@yandex.ru> Date: Fri, 20 Aug 2021 01:37:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87r1epp6h9.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 19.08.2021 22:41, João Távora wrote: >> We discussed this problem when group-function was introduced. Another >> approach is to just change the method of grouping: first the >> completions are sorted, and then they are sorted into groups. > > That's a possiblity. But it might be performing too much work, at least > at first sight. Not sure I understand. Grouping is a linear operation, isn't it? O(N). Which is generally cheaper than the sorting step that came before. > For the C-x 8 RET case and the xref table (the only > tables I know which use this) things seem to be naturally put into > groups already. So sorting them alphabetically, by length, by history, > and _then_ destroying most (but not all) with the grouping could be not > so interesting if the there's a big a price to pay. Could be it misses information. OTOH, if you split completions belonging to the same group apart, you can end up with a list where there as as many group headers, as there completions (in the extreme case). What behavior does (setq completions-group t) have? It affects the default UI, IIUC. From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Thu, 19 Aug 2021 23:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16294163895406 (code B ref 48545); Thu, 19 Aug 2021 23:40:01 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 23:39:49 +0000 Received: from localhost ([127.0.0.1]:60952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGrdV-0001P7-E7 for submit@debbugs.gnu.org; Thu, 19 Aug 2021 19:39:49 -0400 Received: from mail-pg1-f178.google.com ([209.85.215.178]:36551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGrdT-0001Ow-Bb for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 19:39:48 -0400 Received: by mail-pg1-f178.google.com with SMTP id t1so7415742pgv.3 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 16:39:47 -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; bh=UzoCgnCKTH/14P8JDvfq5m39jMwDyvGUKnVuafg4ZU4=; b=ehqcnknBuzGc/Qlf0Czo1rrDPoe7bbnTAO9F+2X8SBMEQiajFnmQee4C1rpma7IdMS ZeaISVhpfdKdKm2G9y2KF+qghVbEZb4/+iPR0xJbMczqU5gZSsuBsjZN0IbMl1JO7CMw 6vzjz+j8KAP4Td/jByK92OYOz8jsE3v0cKAOEtRLMX56ZaQ/AcRGp/iPp3tbyM5E9NYa LkaPKOOMIQ0WrWVgqEBdlUYExU5t3jJsm0hhPdN0ruEFO7LxkqULKqp7c9VMUMX8T6yi JSRvoYyWKEc4kXfeeedPAWi+42YRXxsDSvfRqpWp55guKHcCjGBd7CdJfYZm4q8i/mC/ LEKg== 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; bh=UzoCgnCKTH/14P8JDvfq5m39jMwDyvGUKnVuafg4ZU4=; b=T8C/YyXvJj8TB4CNwsy5lxKAV1yO8QiRFr7TLmcMB9LrYKdq8MLz+CRh+qWZDAUkdw UXy8U0M4VK6V3Fn5ECYZ8bGEQnX9E8FV1DyX9QwuBFbgGc+VMYUklVYUi+YT/igL/9e1 WKGIra20M1pEpG5KXsFfs47A1C4xrGyVbRKRUp3/CG8u8oXZ3om0cWiffi4Pv6o1x3lN tUGu3C7K9daLUxmbzxWefS6S3a3cQ10zJKd06t10INMK7h8wJEUirb4fpj+1+bz/KkRe 7sb2g9697QMStxELwn2O26wTBp1QX+54WnhZNBsZ/HTVWEN1Omcr9tNzojpERygBka1V GJqQ== X-Gm-Message-State: AOAM5326qrLC9b0rJNsdxkGw6x7cY3IhNvT2lEmKYtc6R2O8Qf5XnPSu P+OnLp39eQarCdlJJffwe8MFgzdbsCwJ4uJbmj8= X-Google-Smtp-Source: ABdhPJzMVOcHXT7JESPHW5OzYhGrKNX8CCxpgNYsl6gRzGdoHyO88hgtja6Ptmx8HopqkxvUULj5yIOS0ANtuhmm+Qw= X-Received: by 2002:a63:c0a:: with SMTP id b10mr16021913pgl.447.1629416381516; Thu, 19 Aug 2021 16:39:41 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <266d8a54-90de-e904-f548-8ec29e52923c@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Fri, 20 Aug 2021 00:39:29 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000009c90b605c9f2106a" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000009c90b605c9f2106a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 19, 2021, 23:37 Dmitry Gutov wrote: > On 19.08.2021 22:41, Jo=C3=A3o T=C3=A1vora wrote: > > > That's a possiblity. But it might be performing too much work, at least > > at first sight. > > Not sure I understand. Grouping is a linear operation, isn't it? O(N). > Which is generally cheaper than the sorting step that came before. > Yes, but you'd be adding to it and that is always worse than _not_ adding to it. And there's a constant factor in front of that O(N). So that's why I think measurements should be taken, always. Not to mention that if the table is already "naturally" grouped 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. Of course, maybe I presume wrong, but K=C3=A9vins report, who does use completions-group, seems to confirm it. > For the C-x 8 RET case and the xref table (the only > > tables I know which use this) things seem to be naturally put into > > groups already. So sorting them alphabetically, by length, by history, > > and _then_ destroying most (but not all) with the grouping could be not > > so interesting if the there's a big a price to pay. > > Could be it misses information. > ? Don't understand this... OTOH, if you split completions belonging to the same group apart, you > can end up with a list where there as as many group headers, as there > completions (in the extreme case). > That's true. That's why my idea is to skip sorting altogether when tables have a group-function, under the assumption that good speed matters much more than applying the default sorting within each group. For example, what does it matter to have a recently chosen UTF-8 completion bubble up to the top of a group that's buried deep down in the long list of groups? Not much, I think. And largely the same for the length and lexicographical sorting. I'd even venture to say it's like this for any table with a group-function, though I only know two such tables. And that's why I proposed that generic minibuffer.el patch. But, the alternative, to do it per table, could also be fine and is reasonably short, too. What behavior does (setq completions-group t) have? Seems to be a flag that controls the presence of 'group-function' in some tables. Can't speak of the other UIs, but icomplete just honors 'group-function' and does not double check the flag. It could, if it were relevant, I guess. It affects the default UI, IIUC. Yes, I believe so. But what is the relevance? Jo=C3=A3o --0000000000009c90b605c9f2106a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 19, 2021, 23:37 Dmitry Gutov <dgutov@yandex.ru> wrote:
On 19.08.2021 22:41, Jo=C3=A3o T=C3=A1vora wrote:=

> That's a possiblity. But it might be performing too much work, at = least
> at first sight.

Not sure I understand. Grouping is a linear operation, isn't it? O(N).<= /blockquote>

Which is generally cheaper than the sorting step that came before.

Yes, but = you'd be adding to it and that is always worse than _not_ adding to it.= And there's a constant factor in front of that O(N). So that's why= I think measurements should be taken, always.

<= /div>
Not to mention that if the table is already "na= turally" grouped upfront, your're incurring in both the sorting co= st and the grouping cost, when you could just be skipping both with little = to no downsides, I would presume.

Of course, maybe I presume wrong, but K=C3=A9vins report, who doe= s use completions-group, seems to confirm it.=C2=A0=C2=A0

> For the C-x 8 RET case and the xref table (the only
> tables I know which use this) things seem to be naturally put into
> groups already.=C2=A0 So sorting them alphabetically, by length, by hi= story,
> and _then_ destroying most (but not all) with the grouping could be no= t
> so interesting if the there's a big a price to pay.

Could be it misses information.

? Don't understand this...

OTOH, if you split completions belonging to the same group apart, you
can end up with a list where there as as many group headers, as there
completions (in the extreme case).

That's true. That's why my idea i= s to skip sorting altogether when tables have a group-function, under the a= ssumption that good speed matters much more than applying the default sorti= ng within each group.

Fo= r example, what does it matter to have a recently chosen UTF-8 completion b= ubble up to the top of a group that's buried deep down in the long list= of groups? Not much, I think. And largely the same for the length and lexi= cographical sorting.

I&#= 39;d even venture to say it's like this for any table with a group-func= tion, though I only know two such tables. And that's why I proposed tha= t generic minibuffer.el patch. But, the alternative, to do it per table, co= uld also be fine and is reasonably short, too.

<= /div>
What behavior does (setq completions-group t) have?=C2=A0

Seems to be a flag that controls the presence of 'group-function'= in some tables. Can't speak of the other UIs, but icomplete just honor= s 'group-function' and does not double check the flag. It could, if= it were relevant, I guess.


Yes, I believe so. But what is the = relevance?
=
Jo=C3=A3o

--0000000000009c90b605c9f2106a-- From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 23:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16294170856450 (code B ref 48545); Thu, 19 Aug 2021 23:52:01 +0000 Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 23:51:25 +0000 Received: from localhost ([127.0.0.1]:60961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGroi-0001fy-Tr for submit@debbugs.gnu.org; Thu, 19 Aug 2021 19:51:25 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:41770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGroi-0001fn-7R for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 19:51:24 -0400 Received: by mail-wm1-f46.google.com with SMTP id c129-20020a1c35870000b02902e6b6135279so5005569wma.0 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 16:51:24 -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=VoOUTfu2rn1ctOv2Y/u8Fahex+l0cfzXCzNeJ3LCKAE=; b=PbtPU95fThhpdeZGI2gtho6+Ij9hX/FrtaYC5pjYnAYOWK44Q+ZhAGWOkoc3fJo/+j Olbi2F4H7v9euY3k9uno2QosPaW8BUGu/kiOLnu36wYCqs5TCxqGnHUUQR9Fkk9o6pUr NvsyCPdxPXEsEIHhPdmHdtgcNGJAxcaeH0e93XQsPERXxc0uevHnuoZmBzIW9AzlvvWR umOEHqLeX/kGNSNeGtiZE3yy4CDIJygLB3M9k6AYd/O61jJh+MxmjQX8MznnnyGVyLQ3 tTkIZ8ygkDXvlnla6OXLoXL2mFpiIMM21fQW4xd+qvfsl923f0RLKcbcB+ULwT56XcMV ePqA== 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=VoOUTfu2rn1ctOv2Y/u8Fahex+l0cfzXCzNeJ3LCKAE=; b=COTxTlj8Iok9RedWHvL4mAb+uXVGsSCfaCDa4FFEsK43mNNki4Hv4Ldtocr/m6oyB7 VG1MrHaU4lLcL+HjkrIuhigY5lA4N3ycl6dywOMSKQsr2bnvzH03IrJfQuR3MNEEn9a6 iAZTi97Avrkz4+cF1u+Ay7aSELrV46qdJNIf8e7/op2vZngyfAINFN/C5JcOaZ2s03Pf j+kZ0apY5Av0cnxt6gzLWzrUQxLaXSuRBTEtPV6dauaSc9yWCkJUhpLRTi1WlhgTJjEm /bms/3RvYqB3Fee1qrrMTNhstOkXolCwtvxsehZ5vjqw9tbABAtWNk2jul/EoVo6ohUn f+xg== X-Gm-Message-State: AOAM533kwM2NXJF4hiAn6UGsd9AOGffA8IjSJD/Z47cuJ9GcjZJkksRh UBIZMDp+g9Bv1ju0Iuu3qez3bGikBZ0= X-Google-Smtp-Source: ABdhPJwWMbuFZchNl6mQ87GkRjTYekkpmhQ9bKtmk6XmWpf+bT4CDZwMMHNh8mSiz0sGU/ZkGVfYfg== X-Received: by 2002:a1c:f019:: with SMTP id a25mr1011213wmb.96.1629417078265; Thu, 19 Aug 2021 16:51:18 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t14sm8738837wmj.2.2021.08.19.16.51.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 16:51:17 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: Date: Fri, 20 Aug 2021 02:51:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 20.08.2021 02:39, João Távora wrote: > Not sure I understand. Grouping is a linear operation, isn't it? O(N). > > > Which is generally cheaper than the sorting step that came before. > > > Yes, but you'd be adding to it and that is always worse than _not_ > adding to it. True, but since sorting has higher complexity, for large N it should take much longer, and for small N anything is fast anyway. > And there's a constant factor in front of that O(N). So > that's why I think measurements should be taken, always. Please go ahead, if you like. I just wanted to make a couple of suggestions here. > Not to mention that if the table is already "naturally" grouped 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. > Of course, maybe I presume wrong, but Kévins report, who does use > completions-group, seems to confirm it. Performance degradation? Guess I missed it. > Could be it misses information. > > > ? Don't understand this... Maybe I should say: destroys information. One conveyed by the original sorting order. > OTOH, if you split completions belonging to the same group apart, you > can end up with a list where there as as many group headers, as there > completions (in the extreme case). > > > That's true. That's why my idea is to skip sorting altogether when > tables have a group-function, under the assumption that good speed > matters much more than applying the default sorting within each group. > > For example, what does it matter to have a recently chosen UTF-8 > completion bubble up to the top of a group that's buried deep down in > the long list of groups? Not much, I think. And largely the same for the > length and lexicographical sorting. Suppose the sorting was performed by the 'flex' style (as one example). Then, at the very least, you will see at the top of the first group the best available match for your input. That's useful, I think. Even if the remaining items in that group are much worse matches. > What behavior does (setq completions-group t) have? > > > Seems to be a flag that controls the presence of 'group-function' in > some tables. Can't speak of the other UIs, but icomplete just honors > 'group-function' and does not double check the flag. It could, if it > were relevant, I guess. > > It affects the default UI, IIUC. > > > Yes, I believe so. But what is the relevance? icomplete's grouping behavior should probably match the default UI's behavior in that regard. Or, if people actually don't like it, see it changed in both places. From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Fri, 20 Aug 2021 10:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162945572512450 (code B ref 48545); Fri, 20 Aug 2021 10:36:01 +0000 Received: (at 48545) by debbugs.gnu.org; 20 Aug 2021 10:35:25 +0000 Received: from localhost ([127.0.0.1]:33014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mH1rw-0003Ek-QK for submit@debbugs.gnu.org; Fri, 20 Aug 2021 06:35:25 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:44013) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mH1rv-0003EW-0X for 48545@debbugs.gnu.org; Fri, 20 Aug 2021 06:35:23 -0400 Received: by mail-wm1-f49.google.com with SMTP id k5-20020a05600c1c85b02902e699a4d20cso5792854wms.2 for <48545@debbugs.gnu.org>; Fri, 20 Aug 2021 03:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=tdfUGpqL4skWL2wAqf3Cj/x/B2RXw0CYKLF60WtZa+w=; b=Bil/+bnlHR68R5ELKg/nLiymbmggU65j97HOutVuWKU/Twc7EwN9/a7+ujDgdSmgEW 15E336YKAV/vx3SZV4uhlqpA+tKr7HmL8NSfWIWC0Sy98uJFZsB6duq09BRHgJmkxY95 1n41HixSDhF/04SaHf7yz5/oydC32J7tZOkZSIxPjAuSLd2uRNomGiCdLideFJsflUAE 36/1nIhIj469vaRomq/QKII8tcJfZfUaZU0MrrCcvmcC63+ds9xi9ecj+qJOR11v3QgS H2mNQ5vzfbPUWxyPT+M6xn6TmWv0XwfqY/0tbJOH3wPGiVb6vBWDPhKDQw65NFOlN3RR wu3g== 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:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=tdfUGpqL4skWL2wAqf3Cj/x/B2RXw0CYKLF60WtZa+w=; b=djlyI8lJIwF0ys8IQY7NZ5CzIUZX7jIAvWWbMPhuwhie8kgeVvMUt+5gLajzFXsotn IDjkPnebTQ0p7LoeTvfkAC5qt84u9E3zbH9VsUrxiba1+BXnvUrNI8wRLnOmTpLtvK6t 8rTOUlQyjaPSx8mWRcfe3j0nS7QdECZTkLu6Wkf0TH2PIyZgqDfB9RtIeRVAymOBDjzy RX8y6cHf9I+tzE7N0oBziIV1EdRZIyxipMJx5KuI5ZPIbXWw2Vv1xJ4lltal0svjGWIM EXrJLanjLPXnnhCci/MZVyN143ZhBpF9Yj0Z+fN3/4bmt7Pc5xYN7GYAjOLEj2e/r4bw CFxQ== X-Gm-Message-State: AOAM5301wKaB+oNH3EjE/Pk9jT4Cw1DbWgICbOZgOJ9RYpkxMlcSFWIi G857OLBiLaC+HTpuJMns/FHxO/D9F0k= X-Google-Smtp-Source: ABdhPJzeSYSCWwl+MvS+Lx8IUzxsp44rTYswNhrNzOnXXmI+5OnIC8z4kznlIaBdeGlnFKonR/qFgw== X-Received: by 2002:a1c:27c2:: with SMTP id n185mr3106762wmn.20.1629455717092; Fri, 20 Aug 2021 03:35:17 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id s1sm9794842wmh.46.2021.08.20.03.35.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Aug 2021 03:35:16 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= In-Reply-To: (Dmitry Gutov's message of "Fri, 20 Aug 2021 02:51:15 +0300") 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> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Date: Fri, 20 Aug 2021 11:35:15 +0100 Message-ID: <87pmu8qu8s.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 20.08.2021 02:39, Jo=C3=A3o T=C3=A1vora wrote: > >> Not sure I understand. Grouping is a linear operation, isn't it? O(N= ). >> Which is generally cheaper than the sorting step that came >> before. >> Yes, but you'd be adding to it and that is always worse than _not_ >> adding to it. > > True, but since sorting has higher complexity, for large N it should > take much longer, and for small N anything is fast anyway. This is IME a common misunderstanding, that is usually cleared up by the phrase "constant factors matter". In k1 * O(NlogN) + k2 * O(N) which is our example, Big-O notation can drop the constants to describe the growth rate of functions, but in the real world and for a real N, k1 and k2 matter. In the particular case we're discussing k2 isn't even under "our" (meaning minibuffer.el or "the framework") control. It is determined by whatever the completion table author put into `group-function`. So eliding the second term from that equation may be premature. >> And there's a constant factor in front of that O(N). So that's why I >> think measurements should be taken, always. > > Please go ahead, if you like. I just wanted to make a couple of > suggestions here. I don't think we understand each other. If I understand correctly, your suggestions is to add a re-grouping, meaning grouping on top the current sorting, under the presumption that it will not significantly slow things down. That's fine. My suggestion, however, is different. It is to skip the current sorting for these cases altogether. My suggestion has an actual implementation in the form of a patch, has been tested by K=C3=A9vin and has been benchmarked to show that it speeds up the process. 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), then it is you or that someone who should perform these measurements. I can't imagine or guess what re-grouping implementation you or anyone else has in mind, and if even I could I wouldn't be able to take measurements from my imagination. >> Not to mention that if the table is already "naturally" grouped >> 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 takes currently takes about a second to compute completions and only 0.6 seconds when sorting is removed? > Maybe I should say: destroys information. One conveyed by the original > sorting order. Yes, both the current sorting and your proposed sorting-and-regrouping implementation will do that. > Then, at the very least, you will see at the top of the first group > the best available match for your input. That's useful, I think. Even > if the remaining items in that group are much worse matches. I thought we weren't discussing pattern-matching scenarios here, but OK, this is what currently happens (meaning, you can try it yourself!). As always with flex the best available match globally is sorted to the top, along with its group. Icomplete will chose about, say, 10 best matches to display. If two first ones happen happens to have same group, Icomplete will shown under the same section. If the third has another group, another section header. If the fourth global best has again the same group as the first two, another section header. This is flex doing its thing. > icomplete's grouping behavior should probably match the default UI's > behavior in that regard. Or, if people actually don't like it, see it > changed in both places. Anything and everything could be interesting, I guess. If you want to propose changes to icomplete, propose changes to icomplete, as in with actual code. Then things can be evaluated against reality Jo=C3=A3o From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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 00:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162950550321254 (code B ref 48545); Sat, 21 Aug 2021 00:26:02 +0000 Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 00:25:03 +0000 Received: from localhost ([127.0.0.1]:35692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHEoo-0005Wk-Ki for submit@debbugs.gnu.org; Fri, 20 Aug 2021 20:25:02 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:44699) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHEoj-0005W0-Tk for 48545@debbugs.gnu.org; Fri, 20 Aug 2021 20:25:01 -0400 Received: by mail-wr1-f48.google.com with SMTP id x12so16428192wrr.11 for <48545@debbugs.gnu.org>; Fri, 20 Aug 2021 17:24: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=4SNt4MUIHswcqheP2otxNJL7AoJ4z9p4dj83UWSOVuk=; b=eGF55jL1lUF1uAb1Yyp1ZVn/Orks2dYzwrw9SN3gFBN8iUGlBCl900HjD6zAI32rHN lh2MFgj0y/z88OhT+iuPQbD38/L5QRpMaXQk8zHrKZnYhK/qH+oBPxRMBI3GI8CE4Tct VzevFKfPLWjDf3n1MhfVTRIuh7Wtx6XP7GsHkRVzyvSEkk3ZFG1t+WboAbfhKIUjZn7i kdPSnv9KpzgHQYa452NVbNMfIPb9K9JVeCxuGhhpu4H+1AFymANCMB7urZ2LQclH6BLr m9MxLP5eyBTqfR1kEUPRFgJ2t5QDIF3Aa4z+kLxAdQozRtEZ1msr7AcakWohaLRljXzN YYxQ== 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=4SNt4MUIHswcqheP2otxNJL7AoJ4z9p4dj83UWSOVuk=; b=nspVRd4qLrEzOMIXnLhVmERS6XxET7EzQagMQYnOKQeXr6hFAUFtd3SdX0OQBGYl8p OithFULruGAggtJS/Gh7RvDwJ5wM0T/21GZPlACAlDvz91bddDlIkLTMcOI5GP97D7EP b+sM77OeeSG0G/nP9L/cAv0rFQJq2SKaReIJ/BsgMNDSe8ShHluVWp5HLBfvozSSuOrI InkveP6ETE7rVu/hglwOWtFygUiLERI1qSpCFI706GxAcwkbX26xPY9mxozERW00Hwru HiwaQxChCDaEDD7Q5MLJtJCmyBXSSh7kaUz/4EC848WOL8MZt9QP44IVSoeTLu6AIB8d HxWg== X-Gm-Message-State: AOAM531N9Gz2IxvQWgsmIqKRnBjBDSMhdVxveCzY34T+0yRHLuy//db7 U/xpIuZ15sQlZgSUVSuG87qLErtXh/o= X-Google-Smtp-Source: ABdhPJwLorS8nDqthLPrbR/XVy1bJhCftqZobBvu636qbtELielkwPaHLnjhiYpucV3vCoofeKlg+w== X-Received: by 2002:adf:a29c:: with SMTP id s28mr1287171wra.318.1629505491775; Fri, 20 Aug 2021 17:24:51 -0700 (PDT) Received: from krug (a94-133-228-229.cpe.netcabo.pt. [94.133.228.229]) by smtp.gmail.com with ESMTPSA id f17sm6283497wmq.17.2021.08.20.17.24.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Aug 2021 17:24:51 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> Date: Sat, 21 Aug 2021 01:24:47 +0100 In-Reply-To: (Dmitry Gutov's message of "Fri, 20 Aug 2021 02:51:15 +0300") Message-ID: <87lf4vr6eo.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 20.08.2021 02:39, Jo=C3=A3o T=C3=A1vora wrote: > icomplete's grouping behavior should probably match the default UI's > behavior in that regard. Or, if people actually don't like it, see it > changed in both places. Because it was fairly easy to, i tested the default UI with grouping and C-x 8 RET. It seems that it doesn't use completion-all-sorted-completions, and hence doesn't do the normal alphabetical+length+recency sorting (let's call it a+l+r from now on) at all by default. It does do the re-grouping though. And it takes a long time, about 3-4 seconds (when one presses TAB at the prompt) to see the first page of the completions list. This is versus Icomplete which about a second (or even less if you skip the a+l+r). So whatever the default completion UI does, I don't think Icomplete should imitate it if it means the same slow behaviour. The default UI can do some sorting on top of regrouping if you set yet another variable completions-group-sort, but then it will be only alphabetical, not a+l+r. No idea why. However, I've also discovered that my previous assumption that C-x 8 RET returns naturally grouped chars is also wrong. They are _not_ naturally grouped. Jo=C3=A3o From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Aug 2021 02:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162951179130428 (code B ref 48545); Sat, 21 Aug 2021 02:10:01 +0000 Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 02:09:51 +0000 Received: from localhost ([127.0.0.1]:35708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHGSF-0007ui-Di for submit@debbugs.gnu.org; Fri, 20 Aug 2021 22:09:51 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:34664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHGSD-0007uT-6g for 48545@debbugs.gnu.org; Fri, 20 Aug 2021 22:09:50 -0400 Received: by mail-wr1-f42.google.com with SMTP id h13so16753740wrp.1 for <48545@debbugs.gnu.org>; Fri, 20 Aug 2021 19:09:49 -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=2tcFN5KlTeQl4F2SDGA/WwMCT9SvK7qiW3xQLSFYJcw=; b=tDYaAWTlw2tJuob+smuFoBd1GzOrehmGVblNIkSgzQICvg5T/OJKS700FzUOxAnTQB cjx3J+5jK22zosIfqIlz9YjvV6pjwHYHQq3XF/e3+McS9FEr6OzrBLvIUz5/iY+En25c S24/0AYVd2oYo1dnwYE5EVzlZRHeemYdPmF/TPn3HMYsVhIBNMnVkTntZgB/dfdLmnkS RdJAGahgkz+kwcQPekN/NYVVkjVI0mRzwi2qwqKIiSaGsGofp2BMXC8Jy3QGryqytaZ5 QE708fXBsAT31KkhjVL3IvnyFoGvQcgeAA4ZZPjN9RDaswaWffouO3UfVyldEKJUEA7s TthA== 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=2tcFN5KlTeQl4F2SDGA/WwMCT9SvK7qiW3xQLSFYJcw=; b=mpsyRI3r2nskqnxLV+uhEy3MXi7BDzYp7F5kLlfQrvd8cNJ8k6h74N8FCM2GGwc9H4 drducnFqbLV5R3Sssm6Lyr2hLDuMKnYqzb7pAeUC00wqhSeEbV1pF6ItsA+FgujBkd5s DS5+XZcs2oO2EPQ5Ukos2VrxHDJxQsJlk8jCIRRKGF3qnMJRRlcYOSravUkPA1v+X3gd /mnhvbCN5GCgM3IUuDeSBFojLkUokzGT2f9MM03CSAtQtDvjtbUOfhQDN70eAMDF1tuE DFmsiE8MDiEm1lhnDy680XCI5/7xnJX5OoRKPEYvqCltLnonHFPe/OEsb884ga+NiyPK GPVA== X-Gm-Message-State: AOAM531hZql7NeE5Rv777weLszRNcVOIRvJFT1oCasFNvn3DoT/CtiJB rDl64itB84e+GLxnnBGe2PZ0Ol+N2ik= X-Google-Smtp-Source: ABdhPJxTQhp8lSLrlBpVGT+NLEaQ12iaDCHfDMfi5iuuQajv4oH2QbcHV7W1mLZUuOmPtGY3/5itQQ== X-Received: by 2002:a5d:6483:: with SMTP id o3mr1551259wri.197.1629511783422; Fri, 20 Aug 2021 19:09:43 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y1sm6792868wmq.43.2021.08.20.19.09.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Aug 2021 19:09:42 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: Date: Sat, 21 Aug 2021 05:09:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87pmu8qu8s.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 20.08.2021 13:35, João Távora wrote: >> True, but since sorting has higher complexity, for large N it should >> take much longer, and for small N anything is fast anyway. > > This is IME a common misunderstanding, that is usually cleared up by the > phrase "constant factors matter". <...> > > In the particular case we're discussing k2 isn't even under "our" > (meaning minibuffer.el or "the framework") control. It is determined by > whatever the completion table author put into `group-function`. So > eliding the second term from that equation may be premature. 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? 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. >>> And there's a constant factor in front of that O(N). So that's why I >>> think measurements should be taken, always. >> >> Please go ahead, if you like. I just wanted to make a couple of >> suggestions here. > > I don't think we understand each other. If I understand correctly, your > suggestions is to add a re-grouping, meaning grouping on top the current > sorting, under the presumption that it will not significantly slow > things down. I took an existing example of a grouping UI and suggested a slightly different one. With no expected difference in performance. > That's fine. My suggestion, however, is different. It is > to skip the current sorting for these cases altogether. My suggestion > has an actual implementation in the form of a patch, has been tested by > Kévin and has been benchmarked to show that it speeds up the process. And I offered a reason for why people might still want that sorting. That reason is not related to performance. > 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. >>> Not to mention that if the table is already "naturally" grouped >>> 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 takes > 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. Try disabling grouping. Is completion still slow? Then it's a problem with sorting speed that needs to be solved separately anyway. >> Then, at the very least, you will see at the top of the first group >> the best available match for your input. That's useful, I think. Even >> if the remaining items in that group are much worse matches. > > I thought we weren't discussing pattern-matching scenarios here, but OK, > this is what currently happens (meaning, you can try it yourself!). As > always with flex the best available match globally is sorted to the top, > along with its group. Icomplete will chose about, say, 10 best matches > to display. If two first ones happen happens to have same group, > Icomplete will shown under the same section. If the third has another > group, another section header. If the fourth global best has again the > same group as the first two, another section header. This is flex doing > its thing. Yup. This is what I suggested to change. From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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 X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16295388667462 (code B ref 48545); Sat, 21 Aug 2021 09:42:02 +0000 Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 09:41:06 +0000 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 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 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) 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) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> Date: Sat, 21 Aug 2021 10:40:49 +0100 In-Reply-To: (Dmitry Gutov's message of "Sat, 21 Aug 2021 05:09:40 +0300") Message-ID: <878s0vqgny.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.162954727729923 (code B ref 48545); Sat, 21 Aug 2021 12:02:02 +0000 Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 12:01:17 +0000 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 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 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) 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) 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> From: Dmitry Gutov Message-ID: <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> Date: Sat, 21 Aug 2021 15:01:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <878s0vqgny.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) 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. From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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 12:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16295497791401 (code B ref 48545); Sat, 21 Aug 2021 12:43:01 +0000 Received: (at 48545) by debbugs.gnu.org; 21 Aug 2021 12:42:59 +0000 Received: from localhost ([127.0.0.1]:35979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHQKw-0000MW-G3 for submit@debbugs.gnu.org; Sat, 21 Aug 2021 08:42:58 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:43889) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHQKu-0000MJ-PA for 48545@debbugs.gnu.org; Sat, 21 Aug 2021 08:42:57 -0400 Received: by mail-wm1-f42.google.com with SMTP id o39-20020a05600c512700b002e74638b567so51818wms.2 for <48545@debbugs.gnu.org>; Sat, 21 Aug 2021 05:42:56 -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=ikuXexwb32swGlu3eGMl+0RH3R6Td0MQomZuT+Qv9RU=; b=OT1OcY+WE2xBfOaBtHn2d3Z9+mrUBPO3ohKYIgeqWydSg7c4Wmp7WZHhV888hR5FDW CbaAW/TyBkREG2YFzPl/SIuWAuoVf18nIPTOoRLO+4yepN+J5Y76o4KBdKvgqHOgbqDi phjmahXgYN8MhLOZmQhHopcF/h7UTJRnSAREFjQ/+My1ty7l1+mMmNEfsapw2Lg7tY4Q 9s/hU00Ig52ebqM+iRF+6ilXpVM4xTAwTDQV0Ekj6U8lNuB6vQVYHq3rXbznG1hV9Fok xRCSfkRoPVxD+sXzD15jl0syRA28VgcYE2WIQAF76z0wakBflOLDKZ/HfX5FJKYiX317 MldQ== 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=ikuXexwb32swGlu3eGMl+0RH3R6Td0MQomZuT+Qv9RU=; b=cJtdLih+xVs4bEFy8wElPq06MvNcLI5M5wH64PtH/YhTXCXrE5ZMEMFO1mgaf0rLs3 lJHWm2KdCMRAoVoJOqT7oKCNeAKM/XapuAEQF6a1LhHU+Ts8jSFNpu5fgbFTwyiCsTUO nWuMKP3yP17L2shfOnizP8l/8BLm7lgnPcjXybpv+eBCfn2A21xqLHIgdq82hkwY04O/ lVYYbqapIEv5luIlcgNEPZxAlXal0r1yklKNcVNBvxacEgA2DxO6R4La2oQa3IBGMuN9 IFFo4BHSQmPh4dcrDJDCY03yV+7m7FLZLKfpZ/OMXskmHJGk7DAonx30s5TuqazsGLo4 ZzcQ== X-Gm-Message-State: AOAM5311v6IzPGNZ9EzfJhwyjsZ3lylr7URZtFX0M09JMa6uloc9kKui 0pUf2/Rd1PKAntQ0KBF9CV1dJsbfZqo= X-Google-Smtp-Source: ABdhPJwDBSzPhhN3UiSJ0Ykeu8AqIsxmW5e4NTiQ3cECljhMBhL+ngZBrMV7jVZc32Q/zSbXSxacBA== X-Received: by 2002:a7b:cf16:: with SMTP id l22mr8429158wmg.185.1629549770487; Sat, 21 Aug 2021 05:42:50 -0700 (PDT) Received: from krug (a94-133-228-229.cpe.netcabo.pt. [94.133.228.229]) by smtp.gmail.com with ESMTPSA id r20sm298512wrr.47.2021.08.21.05.42.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Aug 2021 05:42:49 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> Date: Sat, 21 Aug 2021 13:42:46 +0100 In-Reply-To: <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> (Dmitry Gutov's message of "Sat, 21 Aug 2021 15:01:06 +0300") Message-ID: <874kbjq88p.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 21.08.2021 12:40, Jo=C3=A3o T=C3=A1vora wrote: >> 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. Then do. Go back to that experiment and its drawbacks and actually prototype it the way you envision it. Then share results here. > 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. If you sort the groups but not _inside_ the groups, you can skip the expensive sorting and still keep some order. Though in xref nothing is particularly expensive anyway. > Okay. Sorting seems to indeed be costly in this case (if I trust your > measurements). You can do them yourself. I posted what I measured from. If it's not clear, you should let me know. > Sorting is part of the default completion behavior (with grouping or > not). You want to remove it instead of fixing? It's very simple: As I've explained some times already, I contend, and K=C3=A9vin at least seems to agree, is that when there grouping the current slow 'a+l+r' sorting is not particularly useful. At least the "r =3D=3D=3D recently" part seems completely useful there. But the 'a+l' also seem to be kinda lame, at least for xref and C-x 8 RET. Now, if one agrees that sorting not particularly useful when there is grouping and that is significantly slows things down, then there is a good case for removing it when there is grouping. It's super simple. >>> 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. How in heck could I adress the remaining ones which refer to the first three if those three were nonsense?=20=20 Look, you're asking me to do vaguely worded experiments that you can perfectly run yourself. If you understand what you mean, go run them yourself, document your findings and share them here for others to work from. It'll save us all time. >>>> 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. Then I misunderstood, again. You did suggest changes to the 'flex' completion style in another bug thread, I naturally though you meant that. Here, you wrote "this is what I suggested to change" after I described how the flex completion style worked. You provide no accurate description or code of what you want changed. If you weren't a programmer or especially versed in Elisp, I would comprehend. Given that you are, it is baffling, time-wasting and quite tiring. I'll just stop answering your hypothetical questions. Jo=C3=A3o From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Aug 2021 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16296403376772 (code B ref 48545); Sun, 22 Aug 2021 13:53:02 +0000 Received: (at 48545) by debbugs.gnu.org; 22 Aug 2021 13:52:17 +0000 Received: from localhost ([127.0.0.1]:38328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHntZ-0001l9-4R for submit@debbugs.gnu.org; Sun, 22 Aug 2021 09:52:17 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:35809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHntT-0001kt-Qu for 48545@debbugs.gnu.org; Sun, 22 Aug 2021 09:52:15 -0400 Received: by mail-wm1-f48.google.com with SMTP id q11-20020a7bce8b0000b02902e6880d0accso12229637wmj.0 for <48545@debbugs.gnu.org>; Sun, 22 Aug 2021 06:52:11 -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=S2wNXrYsMo6sTbk3c1pqO+Si+N0DJmSTqDC4S+d/n00=; b=atY2KkGmOQ3qgXUD4p+L9nATe1eZtb2dukI1xsEHjhwkUWBBlUwqa76+NhGn3O+jAh O8DjNifb5fqxR5VOYdy0ZNRVsmeZGaCX5b1EvwBxWbj7uxeS6nmZbY+vv5EFvMAjAeho Nj7UEllDbSBUcFh8Rc8J8QjukhKpMAlICgjuEml3vNVtUtMBgLBaeZXfoXuVyv0pXqBu RC3YDfTNAmAlF7/RGxvAXQLuLqWKusq9kB1HfqydXuFdaewVxTU11QHuKMqu3pIn+XAA vy+IN0jltdSbrCtrQclDwFMwZzsG5SeST0Pr56HHtApb1ksIeLDFauf25pzaNo6GWXum mOCQ== 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=S2wNXrYsMo6sTbk3c1pqO+Si+N0DJmSTqDC4S+d/n00=; b=TpbfzjfZooe6pogETw/DsmF9tnDQHrG6AKKWvHIgsipopVOZAWS8KJyBfaYWBmQEKc D8H1B+ueMUCcVp38yTZOFAPx3AgBwSd/YW80loVTYmHjF78c1SANiuu0+u0kMcllRW7C 7045X7/zhlFCKz8RtsRV98pJODUqdATSRB3KgfNRqCYQcrOjk1pyRAfCp5uajkCFm4kd b4DpLMfPVe32iSA/dS9jpzaAPtprZoIAGHgUmYFksdf4APL2lXYiJVgiFnys1HD8Xn2F pMztck3TyXsRyEZVfFFura3jMhTKj9H2rDeQ1qqNMmvOjMNSorEr47gDW+DITjHkDM+o wR6Q== X-Gm-Message-State: AOAM532AVhTAXujxaAHmt3RmK9CxXZKLXd86svtvdmVkaY/QeblGyuUp QpggkxmgIXArwr7HyVP1xF0AZ8HTsR8= X-Google-Smtp-Source: ABdhPJwWop0wbm3KiJ2OOgr8tDavo9xmbZUaSbhDBv13epnaSq2Ab+ik56lnjFoifao87PO7RBgdGA== X-Received: by 2002:a1c:29c3:: with SMTP id p186mr12309340wmp.22.1629640325946; Sun, 22 Aug 2021 06:52:05 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r4sm15031295wmq.34.2021.08.22.06.52.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Aug 2021 06:52:04 -0700 (PDT) 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> <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> <874kbjq88p.fsf@gmail.com> From: Dmitry Gutov Message-ID: <09afb635-ca5d-cee5-2ea9-b119e2720cec@yandex.ru> Date: Sun, 22 Aug 2021 16:52:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <874kbjq88p.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 21.08.2021 15:42, João Távora wrote: > Dmitry Gutov writes: > >> On 21.08.2021 12:40, João Távora wrote: >>> 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. > Then do. Go back to that experiment and its drawbacks and actually > prototype it the way you envision it. Then share results here. I don't think I'm obligated to support every trivial suggestion with a patch and a benchmark. Or explain, from various POVs, why removing the sorting step "because it's expensive" is faulty reasoning. Or why the grouping approach in icomplete mode should match what the default UI does and what other completion UIs (from which the grouping feature was extracted) do as well. Whatever, do what you like. I'm out of this thread. From unknown Fri Aug 15 16:24:27 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` 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: Sun, 22 Aug 2021 15:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , 48545@debbugs.gnu.org Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16296470672775 (code B ref 48545); Sun, 22 Aug 2021 15:45:02 +0000 Received: (at 48545) by debbugs.gnu.org; 22 Aug 2021 15:44:27 +0000 Received: from localhost ([127.0.0.1]:39717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHpe3-0000ie-Dv for submit@debbugs.gnu.org; Sun, 22 Aug 2021 11:44:27 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:39572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHpdy-0000iO-Q8 for 48545@debbugs.gnu.org; Sun, 22 Aug 2021 11:44:23 -0400 Received: by mail-wr1-f52.google.com with SMTP id z4so6621240wrr.6 for <48545@debbugs.gnu.org>; Sun, 22 Aug 2021 08:44:18 -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=KOTlaTnmOE3pTDVHdkOT4vyqZyUvlGP2afQCOHnWDuM=; b=Rdy6006f8fzskQlUXFOXR+2kHHdRrVpVR7M5ALGuyCMMrckZoZSzsxpvmqxAp7wyuv ztpmUB+FX6MN67VfSV0fzYup/Io0dfRjukrJswlJ8Ovw7ke+8DfI7AG5WrtkPLp/1DyI 7iG288D/9MIAQUXLApeXOd9htgprjGDuht/2mbgrI3ewXz3LgR7PyQRoZ3UQtOdXWqcS 5IgcfpAHzEGwf3PirxkAvRCwwvwKChx131y5IjqDhGF+CFqx090ZCOu0AjW1GZUu69O9 NW8B8nTi9GRr5AVcLoE2j8Hb5EPgK+Otw2vj7rcihTkAsq4CnNxO5WMdSbz1ujJDEvVn jKPg== 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=KOTlaTnmOE3pTDVHdkOT4vyqZyUvlGP2afQCOHnWDuM=; b=CHw9/CxtoqZaDDN+Zb/goiAxmGPkKnKlQjAhjSZ03mzs6BFDtVvUxsjIk2QhkJT3LG 04aHXddBsbE/hFayhmzq/gb7ijcxGy9wDsbDdxlui5LTEItNqlOWLeo+CvWIwc7kTr5H 7EcmraCINTieTS671ytwCXZsQUz7CH7Vvl8jOfF5B/xHW28VFZVY/qB7lNpbffVL0Emx bK75D4B1SJNlOc2Dtdj2Tjwqbof0kZDv72yit9NEf2hhm7AEknBX8JNCuMcbkXTKoy4V dPgZOvGWj9Ywy/kRPptvUZBcFvvqthCss6wIKd58I+VOs3xdlxzmgslfyXpn9OvZeFl0 hQzA== X-Gm-Message-State: AOAM533/NlD3iVX8WGTu5dUK2hz1Rvm76nAYlR9jbfNb2iL4q8Lith2k 34qjTW8Off3GwNlNxtgD4LIPw3e9W84= X-Google-Smtp-Source: ABdhPJz70Vfgh1UOMHHcEINoizPYYwi4a4FjBH2Eqqg6dGXPe6Dy9/RqRKOKg17PDgutG0bC+Vxlww== X-Received: by 2002:adf:fd8c:: with SMTP id d12mr5375564wrr.21.1629647052552; Sun, 22 Aug 2021 08:44:12 -0700 (PDT) Received: from krug (a83-132-128-184.cpe.netcabo.pt. [83.132.128.184]) by smtp.gmail.com with ESMTPSA id y16sm6495961wmo.20.2021.08.22.08.44.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Aug 2021 08:44:11 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> <874kbjq88p.fsf@gmail.com> <09afb635-ca5d-cee5-2ea9-b119e2720cec@yandex.ru> Date: Sun, 22 Aug 2021 16:44:09 +0100 In-Reply-To: <09afb635-ca5d-cee5-2ea9-b119e2720cec@yandex.ru> (Dmitry Gutov's message of "Sun, 22 Aug 2021 16:52:02 +0300") Message-ID: <87o89peb7a.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > I don't think I'm obligated to support every trivial suggestion with a > patch and a benchmark. Of course you're not obliged to, but the fact that you won't code up your own "trivial suggestion" is eloquent. > Or explain, from various POVs, why removing the sorting step "because > it's expensive" is faulty reasoning. Could be, if it _were_ the reasoning. But it's not, as is quite easy to read here. > Or why the grouping approach in icomplete mode should match what the > default UI does and what other completion UIs (from which the grouping > feature was extracted) do as well. The sorting in the default completion UI is already discrepant to completions-all-sorted-completions, regardless of grouping. It's also quite slow, as reported. I doubt we want Icomplete to "match" that (not to mention the fact that Icomplete is a different type of UI). > Whatever, do what you like. I'm out of this thread. I've pushed ba852512f23fdab674086e35d4207e3970dd0912 to fix the described bugs and wrap this up. Left a TODO in minibuffer.el for anyone to experiment with "trivial suggestions" (or complex ones at that). Jo=C3=A3o