all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Amin Bandali <bandali@gnu.org>
To: "J.P." <jp@neverwas.me>, Olivier Certner <olce.emacs@certner.fr>,
	Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org
Subject: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications
Date: Thu, 16 Sep 2021 01:30:18 -0400	[thread overview]
Message-ID: <87v931cck5.fsf__10496.2533268676$1631770286$gmane$org@gnu.org> (raw)
In-Reply-To: <87ee9r4io8.fsf@neverwas.me>

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?





  reply	other threads:[~2021-09-16  5:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 17:33 bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Olivier Certner
2021-02-25 17:38 ` Olivier Certner
2021-02-25 17:47   ` Basil L. Contovounesios
2021-02-25 18:22     ` Olivier Certner
2021-06-08  2:23 ` J.P.
     [not found] ` <878s3l6qms.fsf@neverwas.me>
2021-06-09 13:30   ` Olivier Certner
2021-06-10  3:59     ` J.P.
2021-07-06 14:52 ` bug#46777: Updated patch Olivier Certner
2021-07-22 12:29   ` bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Lars Ingebrigtsen
2021-07-30 12:27     ` Amin Bandali
2021-07-30 12:43       ` Lars Ingebrigtsen
2021-07-26  7:39   ` J.P.
     [not found]   ` <87sg01jzgk.fsf_-_@neverwas.me>
2021-09-14  9:20     ` J.P.
2021-09-16  5:30       ` Amin Bandali [this message]
     [not found]       ` <87v931cck5.fsf@gnu.org>
2021-09-16 12:42         ` Lars Ingebrigtsen
2021-09-17  4:45           ` Amin Bandali
     [not found]           ` <87a6kbn72z.fsf@gnu.org>
2021-09-17  7:57             ` Olivier Certner
2021-09-19 15:26               ` Amin Bandali
2021-09-17  2:16         ` J.P.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='87v931cck5.fsf__10496.2533268676$1631770286$gmane$org@gnu.org' \
    --to=bandali@gnu.org \
    --cc=46777@debbugs.gnu.org \
    --cc=emacs-erc@gnu.org \
    --cc=jp@neverwas.me \
    --cc=larsi@gnus.org \
    --cc=olce.emacs@certner.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.