From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#22324: 25.0.50; completion-category-defaults style doesn't override completion-styles (gets prepended instead) Date: Wed, 26 Jan 2022 19:59:49 +0100 Message-ID: References: <868u41rv84.fsf@yandex.ru> <83fuy8p8oq.fsf@gnu.org> <568FA9D0.2040609@yandex.ru> <83egdsp88n.fsf@gnu.org> <568FABFC.3000205@yandex.ru> <87tufr74of.fsf@gnus.org> <87lf0yjwpw.fsf@gnus.org> <87r1aodus0.fsf@gnus.org> <66aa873d-5f5f-9024-efb6-e6110c27ab3a@yandex.ru> <87ilvy4m94.fsf@gnus.org> <87czklnqvs.fsf@gnus.org> <3045ca8b-f5d6-c85e-d170-3fe158fec64e@yandex.ru> <87ilu94gac.fsf@gnus.org> <43725c9f-1f0a-fb43-82a2-3f284791fdf5@yandex.ru> <875yq8ypmi.fsf@gnus.org> <184dffab-4fa4-e265-c8ef-0c088149b1b4@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31458"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 22324@debbugs.gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 26 20:07:50 2022 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 1nCne0-0007wZ-5u for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 Jan 2022 20:07:48 +0100 Original-Received: from localhost ([::1]:35026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCndz-0001Ye-5C for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 Jan 2022 14:07:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCnWW-0004q3-29 for bug-gnu-emacs@gnu.org; Wed, 26 Jan 2022 14:00:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60638) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCnWV-00026L-Hl for bug-gnu-emacs@gnu.org; Wed, 26 Jan 2022 14:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nCnWV-00014p-7B for bug-gnu-emacs@gnu.org; Wed, 26 Jan 2022 14:00:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Jan 2022 19:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22324 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 22324-submit@debbugs.gnu.org id=B22324.16432236014103 (code B ref 22324); Wed, 26 Jan 2022 19:00:03 +0000 Original-Received: (at 22324) by debbugs.gnu.org; 26 Jan 2022 19:00:01 +0000 Original-Received: from localhost ([127.0.0.1]:53541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCnWT-000146-5r for submit@debbugs.gnu.org; Wed, 26 Jan 2022 14:00:01 -0500 Original-Received: from server.qxqx.de ([178.63.65.180]:58139 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCnWQ-00013t-S3 for 22324@debbugs.gnu.org; Wed, 26 Jan 2022 13:59:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1DGYFsHR645NF8FFXYJG3jtRXdUd3WeIJ+/tQRJ4OT0=; b=PUy+GLTBHX7C8PyYI3MmO8gL/q F70WruWpqGkGuAZTwG9jMd124DSG/zj4frR29Pegmn3TwcwV4ZzAQNJKNpufFNGT9AcedNz5TEXc6 drIlxiWhAO2y5qJb69U7Scoo8IuzOnVmd4sHvpxs1UNZYy/uIzFywqCDti/xAdtb/UDA=; Content-Language: en-US In-Reply-To: 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:225309 Archived-At: On 1/26/22 18:19, Stefan Monnier wrote: > No, because `ignore` will return nil and so we'll just keep going to the > next style. We need try/all-completion functions for this style to > return a non-nil value but that is like "no completion". > > I suspect it can't be done quite right without changing `minibuffer.el`, > but we can probably get close enough to be tolerable with older Emacsen. > > E.g. for the try-completion case, I think we can return (STRING . POINT) > and for all-completions maybe returning `0` will do the trick. Okay, right. This makes the proposal a bit less appealing to be honest, since we end up with a hack, where the result is something like a non-nil invalid completion result. Hmm. So maybe we shouldn't do this and fix the problem at the root? Remove the failover mechanism? I am not fond of introducing a hack to work around the problematic failover design. > While we're here, let's not forget the other problem with > `completion-category-defaults` which is when a package puts something > like `substring` in it because `partial-completion` is not "good > enough": this can end up taking precedence over the users's > customization of the default to something like `flex` which is probably > not what's wanted. Exactly. This is the reason why I reset `completion-category-defaults` in my configuration and I also recommend this in the README of the packages. I should probably describe the problem more explicitly. Often users copy example configurations from packages without investigating the implications. Furthermore in the case of completion styles the implications are often not that obvious. One more reason to remove complexity if possible... > I'm not completely sure how to fix that one. An cheap solution would be > to allow `completion-category-defaults` to specify a function rather > than a list of styles, and then this function will return the list of > styles to use so it can dynamically adapt to the user's chosen default. > But it's kind of a cop out because that function will need to "guess" > what is the relationship between the various styles, which is the crux > of the matter. > > This problem doesn't apply to `completion-category-override` since we > can consider it to be the user's responsability to take `completion-styles` > into account when setting `completion-category-override`. My cheap proposal would be the removal of `completion-category-defaults` and the removal of the failover mechanism of `completion-category-overrides`. Then the user can adjust the `completion-styles` entirely in their configuration. This is maybe not the most user friendly solution in the first place. But as soon as you start to tweak the completion styles it makes things simpler and easier to understand. My opinion in this case is admittedly a bit radical since I propose that users adjust their completion styles heavily to unlock a lot of potential (for example look at orderless and the flexible orderless style dispatchers). But such adjustments may not be for everyone. Daniel