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

[Philip Kaludercic <philipk@posteo.net>]

Daniel Mendler <mail@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