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

Previous Next

Full log

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

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

>>> 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`!

Daniel

Previous Next

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