Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications

[Amin Bandali]

Hi all,

J.P. writes:

> "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?

After a closer look, I am indeed hesitant about merging the original
patch, since it changes the interface of `erc-nickserv-identify' -- a
function as old as time, as far as ERC is concerned, and likely in use
by many -- especially since it deals with passwords.  Instead, I would
prefer one of the following approaches:

1. change the function's arguments in a backwards-compatible way
   (i.e. by adding new &optional args as needed), and ignore the
   arg we don't need anymore (the password in this case, and
   make sure we don't accidentally expose it instead of a nick);

2. gradually phase out the function if we must: either declare it
   obsolete and make it a wrapper around a new function with the
   desired API (I did this recently for one of Olivier's patches for
   erc-track) (this might very well involve option 1 as well), and
   remove the function at some later point after some major releases
   of Emacs; or

3. save the backward-incompatible interface change for a major ERC
   version bump.

We could do one or a mix of the above three options gradually, giving
users enough time and notice to adapt, and avoid putting them at risk.
For this case, option 1 seems straightforward to do, but so does 2.

>From a quick look at J.P.'s revised version of Olivier's patch, it
looks quite favourable to me, in its preserving backward compatibility
in erc-nickserv-identify's interface and obsoleting (rather than
deleting) erc-nickserv-call-identify-function and making it a wrapper
around erc-nickserv-identify, and could probably be merged with few
minor tweaks.

J.P., Olivier, Lars, thoughts?