From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#53897: 28.0.91; regression: rcirc overwrites completion-cycle-threshold Date: Mon, 14 Feb 2022 18:15:42 +0000 Message-ID: <87bkz9co1d.fsf@posteo.net> References: <2dd2216d-9ca0-c242-9681-985584e20dd3@daniel-mendler.de> <87v8xo2o9q.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39724"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53897@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 14 19:16: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 1nJfta-000A6E-SF for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Feb 2022 19:16:18 +0100 Original-Received: from localhost ([::1]:40304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nJftZ-0001V7-8v for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Feb 2022 13:16:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJftK-0001Uz-PA for bug-gnu-emacs@gnu.org; Mon, 14 Feb 2022 13:16:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48613) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nJftK-0008Vw-FV for bug-gnu-emacs@gnu.org; Mon, 14 Feb 2022 13:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nJftK-00027C-7r for bug-gnu-emacs@gnu.org; Mon, 14 Feb 2022 13:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Feb 2022 18:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53897 X-GNU-PR-Package: emacs Original-Received: via spool by 53897-submit@debbugs.gnu.org id=B53897.16448625568118 (code B ref 53897); Mon, 14 Feb 2022 18:16:02 +0000 Original-Received: (at 53897) by debbugs.gnu.org; 14 Feb 2022 18:15:56 +0000 Original-Received: from localhost ([127.0.0.1]:42510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJftD-00026r-Kb for submit@debbugs.gnu.org; Mon, 14 Feb 2022 13:15:55 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:45709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJft9-00026b-4m for 53897@debbugs.gnu.org; Mon, 14 Feb 2022 13:15:55 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id F1449240028 for <53897@debbugs.gnu.org>; Mon, 14 Feb 2022 19:15:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1644862545; bh=oAk+dpufKlziDbK2ihpcsAI29SV5vSpvXIf65GqTeIE=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=R3rUk5mW5n18iT2aRFH9QdbkaJQnMulblNQVRJ/Nfvq7p0tiF0127VfoNh31FgvkV U7DwSPFJ7m82C+N+KvYtaMcnaPndI24X7GFG7STn8XmCwPY7uTTcfX7K0p6VnJ8RYE QMTPc42+FlKadTaxZgG6wMD7ntFcOMu6XDC7K7DUUcDfaOa4gwm4+UQPy4a5FKmMZS coc/lqP65jQLZ8dpbxVfW8gMzKF/RdyaAx3xojL+PbbU+lvSePAT6YD14GrY3O1u/A 8NVEwqP65LOKJ7oFW6jVZqV31W54gXsnoA/3ov8mCo/JzLo+w2zTKpyJyVPKWws6s1 7JD73ePE9gzYQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JyC7z210Fz6tmQ; Mon, 14 Feb 2022 19:15:42 +0100 (CET) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: (Daniel Mendler's message of "Wed, 9 Feb 2022 15:18:45 +0100") 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:226911 Archived-At: Daniel Mendler writes: >> The change that introduced this was that the custom cycling >> implementation was replaced with one based on completion-at-point >> (0b367ec), mainly to simplify the code. The reason >> `completion-cycle-threshold' is set is to preserve the appearance of the >> previous behaviour, as a complete reversion to completion-at-point >> seemed like too much of a change. > > I agree with your change to remove rcirc-complete. I greatly appreciate > the simplicity of rcirc and it is good that you try to make it even > simpler! But rcirc-completion-at-point was already present as Capf on > Emacs 27 and there `completion-at-point` didn't lead to cycling. I would > not introduce a user configuration, it is easy enough to set > completion-cycle-threshold in a hook. Hmm, ok, I get your point. My rationale is that rcirc-complete (bound to TAB) used to cycle, and that it was that behaviour that was supposed to be preserved. > Furthermore there is the alternative to use completion-category-defaults > to specify the threshold per completion category. You could add the > override there. But personally I would avoid doing that. I usually > prefer if packages avoid intrusive and opinionated settings and instead > try to ensure consistency across Emacs. I agree. >> I could imagine introducing a user option to decide what you want to >> use. My inclination would be to set it to "cycle by default", but it >> doesn't need that way. Perhaps we could test non-cycling (regular capf) >> for a while, and see if there are any complaints or other feedback? > > Yes, I would go with normal Capf behavior, which is the usual behavior > across all of Emacs. If a user wants to restore rcirc-complete, it seems > easy enough to add this to a user configuration? > > (defun rcirc-complete () > (interactive) > (let ((completion-cycle-threshold t)) > (completion-at-point))) Or, this could be added as rcirc-complete, binding TAB back to this new command and documenting that if you want to complete using the default CAPF, you should rebind it to completion-at-point? > Thanks! -- Philip Kaludercic