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: Fri, 18 Jun 2021 20:04:20 -0700 Message-ID: <87v96asggb.fsf__9392.76695005304$1624071921$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="16183"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: unhammer@fsfe.org, emacs-erc@gnu.org, bandali@gnu.org, ocert.dev@free.fr To: 48598@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 19 05:05:14 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 1luRIH-00042C-Q0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Jun 2021 05:05:13 +0200 Original-Received: from localhost ([::1]:48854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luRIG-0005WQ-IV for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Jun 2021 23:05:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luRI6-0005WF-St for bug-gnu-emacs@gnu.org; Fri, 18 Jun 2021 23:05:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46857) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1luRI6-0002Ym-LT for bug-gnu-emacs@gnu.org; Fri, 18 Jun 2021 23:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1luRI6-00052u-FT for bug-gnu-emacs@gnu.org; Fri, 18 Jun 2021 23:05:02 -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: Sat, 19 Jun 2021 03:05:02 +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.162407187519360 (code B ref 48598); Sat, 19 Jun 2021 03:05:02 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 19 Jun 2021 03:04:35 +0000 Original-Received: from localhost ([127.0.0.1]:58403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luRHf-00052C-A3 for submit@debbugs.gnu.org; Fri, 18 Jun 2021 23:04:35 -0400 Original-Received: from mail-108-mta4.mxroute.com ([136.175.108.4]:45115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luRHd-00051x-1j for 48598@debbugs.gnu.org; Fri, 18 Jun 2021 23:04:34 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta4.mxroute.com (ZoneMTA) with ESMTPSA id 17a2239fae0000c20d.001 for <48598@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sat, 19 Jun 2021 03:04:23 +0000 X-Zone-Loop: 6584cd86abcdc8cfdf0d18a464cf188826ebc43eedab 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:208708 Archived-At: Hi, This is update #2. I've taken Olivier's suggestions to heart regarding up-front session identifiers and have attempted to rework my changes around them [1]. This comes in the form of (yet) another keyword parameter to the `erc' and `erc-tls' entry points. It's currently called :id, for lack of imagination [2], and it can only be specified in lisp code (rather than via M-x). When non-nil, it's stored as a symbol in a new session variable called `erc-session-id'. This value takes precedence over network display names and dialed/announced servers when identifying connections and grouping buffers. What remains are unambiguous, permanent associations completely disinterested in other session properties, even those given as authoritative by a remote service [3]. To opt in, a user need only avail themselves of :id. While the only concrete use case I've found for this so far is multiple connections to the same network, providing full support across the board ensures we leave a lifeline for folks with other edge cases. However, for normal, everyday use, the interface remains unchanged, and there's really no reason to take notice of this feature. The general user experience has improved in terms of associations being fortified with permanent network designations, meaning they survive disconnection and decapitation (killing of a server buffer). Among other things, this means reengaging someone in a reused query buffer is now doable, assuming the other party is still around and hasn't changed their nick [4]. Additionally, swapping out TCP endpoints (for example, moving from proxy to direct connection) or being dealt a different regional server by a network load balancer should no longer confuse ERC. Buffers from previous sessions are found and reused. I'd be happy to expand on anything above or explain any other changes in detail [5]. If you can, please try these patches. And let me know if it would make things easier to have the latest set present in thread as attachments, which I'll gladly make happen [6]. Thanks, J.P. Notes ~~~~~ [1] About their other suggestion, which involved decoupling the means of connection from all protocol logic: I now feel pursuing that here, in this bug, strays too far off mission. It's quite an endeavor because it would mean touching everything everywhere, so it'll have to wait unless someone else wants to take up the call (in which case, by all means). [2] Grepping the ERC libraries for \bid\b didn't return anything of note, so I figured it was free for the taking (suggestions welcome). [3] IOW, you can sustain multiple simultaneous sessions to the same network using the same nick, if your network supports multiple client/device connections. [4] As I've noted elsewhere, IRCv3 account tags and related features should improve the situation here. [5] I've also attempted to unify the auth-source interface a bit. In doing so, I felt the need to include one of Olivier's patches, bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46777 [6] My prior misgivings on that front were based on not wanting to further clutter people's inboxes and overburden gmane. However, these fears were probably misplaced. I've since found change sets of similar size (still under 1 MiB) that didn't seem to elicit much in the way of complaints.