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#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Wed, 02 Jun 2021 04:19:32 -0700 Message-ID: <87o8coa4zf.fsf__31025.2579789207$1622632817$gmane$org@neverwas.me> References: <875yzakzvi.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="23472"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Kevin Brubeck Unhammer , emacs-erc@gnu.org To: 48598@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 02 13:20:11 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 1loOuu-0005ts-ME for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Jun 2021 13:20:08 +0200 Original-Received: from localhost ([::1]:44002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loOut-0005mb-Oq for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Jun 2021 07:20:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loOuo-0005mN-Cu for bug-gnu-emacs@gnu.org; Wed, 02 Jun 2021 07:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loOuo-0008Pp-4j for bug-gnu-emacs@gnu.org; Wed, 02 Jun 2021 07:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1loOun-0003bt-Ve for bug-gnu-emacs@gnu.org; Wed, 02 Jun 2021 07:20:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <875yzakzvi.fsf@neverwas.me> Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Jun 2021 11:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48598 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48598-submit@debbugs.gnu.org id=B48598.162263279213859 (code B ref 48598); Wed, 02 Jun 2021 11:20:01 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 2 Jun 2021 11:19:52 +0000 Original-Received: from localhost ([127.0.0.1]:39024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1loOua-0003bO-Bj for submit@debbugs.gnu.org; Wed, 02 Jun 2021 07:19:52 -0400 Original-Received: from dal3relay160.mxroute.com ([64.40.27.160]:43143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1loOuV-0003b8-Dv for 48598@debbugs.gnu.org; Wed, 02 Jun 2021 07:19:47 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by dal3relay160.mxroute.com (ZoneMTA) with ESMTPSA id 179cc7345040000ce6.001 for <48598@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 02 Jun 2021 11:19:36 +0000 X-Zone-Loop: e37363acb5cf81b867d64b55f6d27e0923e993fd46b4 X-Originating-IP: [149.28.56.236] X-AuthUser: 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" Xref: news.gmane.io gmane.emacs.bugs:207856 Archived-At: Hi, this is just a routine update/checkpoint rather than a bump for feedback. I fear that in the rush to cobble together my original report, I may have given the false impression I was prepared to move quickly on this. And that in turn may have triggered some frustration with folks eager for a fix or at least something test drivable amid the mass exodus from Freenode. For any callousness on my part re over-promising and under-delivering, please accept my apologies. Firstly, I wanted to highlight some prior art done in this area by Kevin (CC'd), who contacted me out of band. I've incorporated their latest update to erc-join.el in my proposed WIP patch set. It's based on these discussions [1]. My other changes primarily focus on implementing what I'd only previously provided half-baked placeholders for, namely 1. Network-based connection identities 2. Support for identical channel and query targets across networks Other changes are more or less minor tweaks, most reflecting shifts in my understanding of the living standard [2] and/or the library itself [3][4]. If I can sign off with an appeal to any and all interested folks: please step up and collaborate on this bug, even if that means my having to pass the baton or redo much of what's currently on offer. Thanks. Notes ~~~~~ [1] https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00088.html https://lists.gnu.org/archive/html/emacs-devel/2018-02/msg00664.html [2] Correction: in my original report, I mentioned possible problems with case mapping in ERC. After seeking out more informed opinions on the matter, I no longer feel my concerns were entirely justified. And in any case, they're not worth prioritizing, ATM. [3] Re my (perhaps wanton) deletion throughout the library of existing fallback-oriented logic for selecting connection identities. Currently, there's a lot of attention paid to graceful degradation in this department with questionable obvious benefit, IMO. Rather than splitting hairs over inferior/degenerate fallbacks, which ends up, for example, sewing confusion by shoehorning something like erc-session-server (the dialed address) into a value basically meant for networks, why not just opt for precision and blow up when met with lapses in our understanding of IRC (in hopes of encouraging quicker, cleaner fixes in the future)? In the discussion for bug#23438 "24.5; ERC autojoin should use erc-autojoin-domain-only searching channel keys" (which merged with bug#25349 "25.1.90; erc join -vs- passwords" and led to a patch), the participants make this problem pretty plain: > Nikolay Kudryavtsev writes: >> Though one thing - I'm not sure whether you even need to use "or" >> here. Would there ever be a case where erc-session-server is nil, >> but there is erc-server-announced-name? > I don't actually know, so I just swapped them out of paranoia. Not to pick on these fine folks (this kind of equivocal reasoning in this specific area predates their bug by a decade plus). But going forward, I think it makes sense to at least note such uncertainty in the code if not face it head on by dropping this convention of indiscriminately relying on fallbacks. Worst case scenario: our lack of IRC know how is betrayed (at everyone's expense, temporarily) and we're forced to up our game. With this set of WIP patches, I'm trying to somewhat upend this "fallback" trend by making a de facto hard dependency of the networks module (library wide) and delegating to it all duties concerned with identifying a specific connection. BTW, their bug itself was of course legitimate, but their solution didn't account for proxies (e.g., "localhost") or the concept of a network, really. [4] To any old timers still using this client: if you would be so kind as to explain the reasoning behind erc-default-recipients being a list rather than a single target, that'd be terrific (TIA).