From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Date: Fri, 20 Aug 2021 02:51:15 +0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34328"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: Daniel Mendler , 48545@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 20 01:52:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mGrpT-0008g8-Tv for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Aug 2021 01:52:12 +0200 Original-Received: from localhost ([::1]:35290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGrpS-00044m-8b for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Aug 2021 19:52:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39388) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGrpJ-00044b-Uk for bug-gnu-emacs@gnu.org; Thu, 19 Aug 2021 19:52:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49415) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mGrpJ-0007Xs-KR for bug-gnu-emacs@gnu.org; Thu, 19 Aug 2021 19:52:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mGrpJ-0001gn-H4 for bug-gnu-emacs@gnu.org; Thu, 19 Aug 2021 19:52:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16294170856450 (code B ref 48545); Thu, 19 Aug 2021 23:52:01 +0000 Original-Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 23:51:25 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212244 Archived-At: 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.