From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Amin Bandali Newsgroups: gmane.emacs.bugs 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 Message-ID: <87v931cck5.fsf__10496.2533268676$1631770286$gmane$org@gnu.org> References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87sg01jzgk.fsf_-_@neverwas.me> <87ee9r4io8.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33522"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org To: "J.P." , Olivier Certner , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 16 07:31:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQjzS-0008Xs-2p for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Sep 2021 07:31:18 +0200 Original-Received: from localhost ([::1]:45508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQjzQ-00032Q-N2 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Sep 2021 01:31:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQjzC-000325-In for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 01:31:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42056) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQjzC-0001KT-9V for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 01:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQjzB-00064B-Pe for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 01:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Amin Bandali Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Sep 2021 05:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46777-submit@debbugs.gnu.org id=B46777.163177023023280 (code B ref 46777); Thu, 16 Sep 2021 05:31:01 +0000 Original-Received: (at 46777) by debbugs.gnu.org; 16 Sep 2021 05:30:30 +0000 Original-Received: from localhost ([127.0.0.1]:53602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQjyg-00063Q-2e for submit@debbugs.gnu.org; Thu, 16 Sep 2021 01:30:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQjyd-00063C-1H for 46777@debbugs.gnu.org; Thu, 16 Sep 2021 01:30:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40096) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQjyW-0000i7-4F; Thu, 16 Sep 2021 01:30:20 -0400 Original-Received: from [2607:fea8:3fdf:f2d9:7081:5e69:80c:403f] (port=52046 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQjyV-0007zP-Um; Thu, 16 Sep 2021 01:30:20 -0400 In-Reply-To: <87ee9r4io8.fsf@neverwas.me> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214444 Archived-At: Hi all, J.P. writes: > "J.P." 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?