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: Fri, 28 Jan 2022 12:54:39 +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> <2115dbe9-fc14-e21c-5a04-1a1c0c85ceef@yandex.ru> 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="11753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 22324@debbugs.gnu.org To: Dmitry Gutov , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 28 13:27:19 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 1nDQLX-0002sK-Ge for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Jan 2022 13:27:19 +0100 Original-Received: from localhost ([::1]:53690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nDQLW-0001Hn-9U for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Jan 2022 07:27:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nDPqI-0002bF-I8 for bug-gnu-emacs@gnu.org; Fri, 28 Jan 2022 06:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36511) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nDPqI-0003pt-3D for bug-gnu-emacs@gnu.org; Fri, 28 Jan 2022 06:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nDPqH-0006J7-Vr for bug-gnu-emacs@gnu.org; Fri, 28 Jan 2022 06:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jan 2022 11:55:01 +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.164337089024223 (code B ref 22324); Fri, 28 Jan 2022 11:55:01 +0000 Original-Received: (at 22324) by debbugs.gnu.org; 28 Jan 2022 11:54:50 +0000 Original-Received: from localhost ([127.0.0.1]:57647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDPq6-0006Ic-E9 for submit@debbugs.gnu.org; Fri, 28 Jan 2022 06:54:50 -0500 Original-Received: from server.qxqx.de ([178.63.65.180]:34473 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDPq4-0006IJ-1q for 22324@debbugs.gnu.org; Fri, 28 Jan 2022 06:54:48 -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=Va5HaylmAHC1pg0l2KG5RJrsZeOLd9boffpEsghQaDE=; b=oMAngLcMBk6EIR1fhMT6hjsEqO kDTv+8TSAuReV2grIEoGtnh7ljdSnhjfGC0pg7SdjqAgNg/YaAHsD9/JiGpeuTwLo60RyBTuuXfDh vrttF+3SbceaYstLnEkJM51pvqEzjtIGd/HgdwReprp81WqOiY2RIBBv4fDVgwymAvK8=; Content-Language: en-US In-Reply-To: <2115dbe9-fc14-e21c-5a04-1a1c0c85ceef@yandex.ru> 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:225441 Archived-At: On 1/28/22 03:35, Dmitry Gutov wrote: > Let's remove it, I think. > > IMHO, backward compatibility hacks are the reason of >50% of existing > CAPF's problems: you add one special case, then another, then another. > > Each step isn't bad by itself (just like Stefan's current suggestion > sounds workable), but every one of them complicates reading the code, > and writing code to it, even if by a little. > > If we were designing it from the ground up, we probably wouldn't add an > 'ignore' style. We could have added a special value like 't' which would > mean the opposite (*do* the fallback, for those users who would want > their configs to be just a little bit more terse), just like in the > local values of hook variables. But I'm not sure how kludgy the > implementation of this will turn out either, and terseness is not the > primary end goal for this part of user customization, I think. I agree with you. Removing the fail over seems better in the long term. For the users of Orderless and other custom documentation styles etc, we can document that the fail over mechanism has been removed and provide an advice in the documentation, which can be used to upgrade the behavior. The user base of Orderless etc is dynamic as you point out, so they will adapt to changes. If we assume that these users make up the majority of users who make use of the fail over, this should not be a blocker for this minor breaking change. Furthermore I've got multiple reports where people wondered about the failover, so the current behavior is more confusing than having no failover. Using `t` as last element to trigger fail over seems like a good idea. Daniel