[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53897: 28.0.91; regression: rcirc overwrites completion-cycle-thresh
From: |
Daniel Mendler |
Subject: |
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