[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 18 Feb 2022 06:07:20 -0800
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Emanuel Berg via General discussion about ERC <email@example.com>
>> If the latter constitutes a bug, then would it be responsible to
>> change the existing commands rather than add new ones?
Perhaps that was confusing. What I meant was: given that the behavior of
these user-facing command has become so ingrained after all these years,
under what circumstances would changing it be justified?
>> But what about applying this exclusively to interactive invocations?
>> That may still be unwise because of the added complexity and possible
>> confusion arising from the disparity. But I suppose some discussion
>> regarding that would be warranted.
> For interactive use, they could be called from the buttons
> function and placed in the same file [...]
> It won't add complexity/confusion IMO, one would just add to
> the docstring "For interactive use, the ERC prompt is
> considered a button; also, cycling is in effect both ways."
Actually, I think I managed to confuse you because you appear to argue
for changing the existing commands but then continue to offer outright
replacements. Obviously, we can't have both. If we were only concerned
with the "unresponsive at prompt" issue affecting `erc-button-previous',
I'd say it's worth considering a "fix." But with the changes in behavior
(visiting prompt and cycling), I think we'd more than likely want to
introduce completely new variants.
> I wrote a better version just now that cycles the buttons and
> prompt both on next and on prev.
Hmm, guess I didn't look closely enough at the original because I just
assumed they were symmetrical. IMO, that's only sane. Anyway, I'll save
my the implementation questions till you'd had a say re the above.