GNU bug report logs - #53897
28.0.91; regression: rcirc overwrites completion-cycle-threshold

Previous Next

Full log

Message #20 received at 53897 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 53897 <at> debbugs.gnu.org
Subject: Re: bug#53897: 28.0.91; regression: rcirc overwrites
 completion-cycle-threshold
Date: Mon, 14 Feb 2022 18:33:56 +0000

Daniel Mendler <mail <at> daniel-mendler.de> writes:

>>>> 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?
>
> That's an option too. But then you will still keep the old cruft around.
> I would rather break backward compatibility here and document that
> binding `completion-cycle-threshold=t` will restore the old behavior.
> Most users will appreciate that a Capf is directly available, which is
> more capable than `rcirc-complete`!

I honestly don't know.  I understand both sides, but cannot decide.  One
also has to consider the current stage of Emacs 28 development, and that
these kinds of changes aren't appreciated right now.  That means
disabling completion-cycle-threshold would have to be installed in 29.1.

-- 
	Philip Kaludercic

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.