[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for passwor

From: J.P.
Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications
Date: Tue, 14 Sep 2021 02:20:55 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

"J.P." <jp@neverwas.me> writes:

> If that's a realistic concern, perhaps you should consider keeping the
> password param in its original position for the sake of compatibility.

Recent discussions have left me with the impression that at least one
consequential voice may be harboring reservations about the proposed
interface change to `erc-nickserv-identify'. I'd like to offer some
thoughts towards salvaging (at a minimum) the "prompting as a fallback"
portion of this patch, which I feel may be helpful to new users.

As a side note, the few changes that appear motivated mostly by
promoting a separation of concerns seem at worst benign and otherwise
potentially beneficial beyond maintenance matters (IMO). For example,
adding a helper, like the proposed `erc-nickserv-send-identify', to
encapsulate the actual request-making may improve this module's utility
as a traditional library. (A few bots may even appreciate that.)

Regarding the perceived minor bone of contention, my instincts favor the
bold move, as usual. But that's contingent on all things being equal,
which they likely aren't here (because passwords), meaning progressive
attitudes may have to take a back seat. So as a compromise, how about an
ugly chimera like the one in the attached example?

Attachment: 0000-NOT-A-PATCH-discussion-example.diff
Description: Text Data

Attachment: 0001-ERC-NickServ-Prompt-for-password-last-overall-simpli.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]