From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#29108: 25.3; ERC SASL support Date: Thu, 17 Nov 2022 18:26:52 -0800 Message-ID: <878rk9576b.fsf__7754.22398453287$1668738500$gmane$org@neverwas.me> References: <87h8ud92zl.fsf@gmail.com> <874jx4h6sk.fsf@neverwas.me> <875yhifujk.fsf_-_@neverwas.me> <87edw4swdk.fsf@neverwas.me> <878rljxfxs.fsf@neverwas.me> <87k04m4th8.fsf@neverwas.me> <87o7thlepf.fsf@neverwas.me> <87o7taoohd.fsf@neverwas.me> <87a64unifk.fsf@neverwas.me> <87y1sdk1fg.fsf@neverwas.me> <875yfflzps.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="33982"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, bandali@gnu.org To: 29108@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 18 03:28:12 2022 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 1ovr6x-0008eV-Hc for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Nov 2022 03:28:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovr6q-0007vq-JN; Thu, 17 Nov 2022 21:28:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovr6o-0007vU-In for bug-gnu-emacs@gnu.org; Thu, 17 Nov 2022 21:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovr6o-0003ZI-AZ for bug-gnu-emacs@gnu.org; Thu, 17 Nov 2022 21:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ovr6o-0004Ba-6h for bug-gnu-emacs@gnu.org; Thu, 17 Nov 2022 21:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Nov 2022 02:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29108 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 29108-submit@debbugs.gnu.org id=B29108.166873843016030 (code B ref 29108); Fri, 18 Nov 2022 02:28:02 +0000 Original-Received: (at 29108) by debbugs.gnu.org; 18 Nov 2022 02:27:10 +0000 Original-Received: from localhost ([127.0.0.1]:34795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovr5x-0004AT-K6 for submit@debbugs.gnu.org; Thu, 17 Nov 2022 21:27:09 -0500 Original-Received: from mail-108-mta3.mxroute.com ([136.175.108.3]:43049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovr5u-00049q-EB for 29108@debbugs.gnu.org; Thu, 17 Nov 2022 21:27:08 -0500 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta3.mxroute.com (ZoneMTA) with ESMTPSA id 184888f7c230006e99.001 for <29108@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 18 Nov 2022 02:26:55 +0000 X-Zone-Loop: b57335790aeb41f27a538d79c672c86c55117d05ade5 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VBd3wG6u4dUoX75OXaKdraYTg1wI/beFOLVAhLSKm7c=; b=Sete4NH6jMBgAoeEbfewvSEGog tbjcLiwHTHB7NbBBjmybvnxANKn0WglDFIIl1ExR2aziWZDVN+wy1Uku772lvlXTyhqanYy27zC9i 6ZuOXZLAL73wEHMo8vRJfDx3yf3MgJUc+32CQlpxqaA+lJxDpRBC1xAp1onY6nSj8JMLicLmehzK7 MHYpCqLz2664ZGzug5Cj8pJeiS3HRQG8QxM81uyUL9bbIm/aAeia0WdIksLM3UlavMiX1bkwoRUkp 2A3rL/iGu3Fvt36Z7ag5FEuy7KqOA/AIa1QKGnI8I38jtG0PxgSe4YIOvsycv2fL2ITwVWny7cN0b ykSfoWdg==; In-Reply-To: <875yfflzps.fsf@neverwas.me> (J. P.'s message of "Wed, 16 Nov 2022 06:51:27 -0800") X-Authenticated-Id: masked@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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248157 Archived-At: "J.P." writes: > An earlier version mentioned that users can customize per-network SASL > settings by let-binding `erc-sasl-*' options and `erc-modules' around > `erc-tls' invocations. I'm doubtful this is a sustainable approach and > would guess that a more declarative solution is the likeliest way > forward, perhaps something based on connection-local variables. > > That said, I think users still need a practical solution to tide them > over in the short term, one that doesn't involve hooks or timers. Actually, now I'm thinking an even earlier version (from bug#49860) had the most sensible approach for per-network SASL settings all along, and that's simply recognizing `:user' and `:password' symbols as values for `erc-sasl-user' and `erc-sasl-password' (possibly even as defaults). The module then just uses whatever's stored in `erc-session-username' and `erc-session-password' (and obviously inhibits the sending of a server password). > And since this module already takes a snapshot of its own options on > initialization (for reconnection purposes), we might as well revert to > mentioning let-binding, but this time also stress (maybe in an > Advanced chapter) that local modules are still being fleshed out and > that third-party implementations aren't yet encouraged. Given the other realization above, I guess it's no surprise that I've again flip-flopped on mentioning let-binding and have reverted to the opinion that we shouldn't officially commit to local modules at all and should minimize advertising their presence and behavior until we've arrived at a workable solution for granular (network/nick/channel-aware) user options.