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#51753: ERC switches to channel buffer on reconnect Date: Thu, 02 Dec 2021 21:31:24 -0800 Message-ID: <87zgpicl03.fsf__3305.82036856271$1638509543$gmane$org@neverwas.me> References: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> <87bl2re5eg.fsf@gnus.org> <87lf1ve0m4.fsf@neverwas.me> <877ddf9sht.fsf@gnus.org> <87czmwjutj.fsf@neverwas.me> <87ilwnnvfs.fsf@neverwas.me> <87sfvp5dd5.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="12655"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 03 06:32:16 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 1mt1B8-00034V-W7 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Dec 2021 06:32:15 +0100 Original-Received: from localhost ([::1]:33368 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mt1B7-0004sH-4L for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Dec 2021 00:32:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mt1Ax-0004s8-6A for bug-gnu-emacs@gnu.org; Fri, 03 Dec 2021 00:32:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38337) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mt1Aw-0005DC-Tr for bug-gnu-emacs@gnu.org; Fri, 03 Dec 2021 00:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mt1Aw-0008SK-DX for bug-gnu-emacs@gnu.org; Fri, 03 Dec 2021 00:32: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, 03 Dec 2021 05:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163850950032470 (code B ref 51753); Fri, 03 Dec 2021 05:32:02 +0000 Original-Received: (at 51753) by debbugs.gnu.org; 3 Dec 2021 05:31:40 +0000 Original-Received: from localhost ([127.0.0.1]:49883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mt1Aa-0008Re-4P for submit@debbugs.gnu.org; Fri, 03 Dec 2021 00:31:40 -0500 Original-Received: from mail-108-mta129.mxroute.com ([136.175.108.129]:45853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mt1AY-0008RP-3W for 51753@debbugs.gnu.org; Fri, 03 Dec 2021 00:31:38 -0500 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta129.mxroute.com (ZoneMTA) with ESMTPSA id 17d7ec6a6f7000177f.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 03 Dec 2021 05:31:27 +0000 X-Zone-Loop: 8882ffca1d6a0a36e959f0d4258926af8d8c6cf56297 X-Originating-IP: [149.28.56.236] 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:In-Reply-To:Date:References: 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=vF+CxguO3qX7TBFeDgRiGUmg86nlO96k9aZJG019BLA=; b=ioBFOytITVMW8zotVidoOKzOMw NJ53ryImQQfdtmJ7xFoCLXC/TBBXhq6HwLFkqzPaeUEcE9+fUk6hwbL1JBV/TlKdCQtmclf/tVKKr c3K7F6WdTI+ex4d6+lcuWOav17nzVZhiYylFyiWS52A0ZqrX0/TkuiCN1Hxo0kboPJPhgw7OAUjIn j2Xn6r1ACtgWrtMP+sqJ0ie8oXhZ39FCNbRkC864Dj/u86sO7zJXfxOsO1ORMPAzWj2xDzYBHjV1m Q/f1OCcnUuXqIqh2W1ApVNTwiVTwRUO561vlCq/GVmxTZ1V1sum7cFCc6aCI0EJXTOkzJI5urSXgr 4/BEi4XA==; In-Reply-To: (Stefan Kangas's message of "Thu, 2 Dec 2021 11:43:03 -0800") X-AuthUser: masked@neverwas.me X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, RCPT_COUNT_FIVE=0, MID_RHS_MATCH_FROM=0, NEURAL_SPAM=0] 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:221374 Archived-At: These are just some related notes, mostly intended for posterity. Feel free to ignore. Thanks. I think at some point it'll be worth exploring the best time and place for forgetting the current connection's origins with respect to whether it sprang from an automated reconnect. The latest iteration of this patch does this via `erc-cmd-JOIN'. But that's a bit of a compromise and one that will hopefully be replaced with something smarter down the road. Ideally, resetting would occur immediately after all reconnect-related JOINs have happened. As might be obvious, doing this ultimately involves tracking more state, including but not limited to "JOINedness". In the case of server-initiated joins, that implies doing so across sessions [1]. For client-initiated ones, it means tracking request context. While IRCv3 features like "label responses" were designed specifically to assist with the latter [2], that doesn't mean we can't do so manually, given sufficient motivation. Indeed, when armed with a reliable way to uniquely identify a "logical" channel subscription across connections [3], it becomes possible to do this manually by stashing callbacks or continuation instructions. (Some people may know this as the "command" pattern.) The real question then becomes whether it's worth the added complexity. BTW, if anyone has alternative ideas for a temporary solution (other than `erc-cmd-JOIN'), please speak up. I originally thought about doing the resetting in a subset of /CMDs originating from typed user input, but that seemed more prone to inconveniencing users who may have long incorporated the underlying functions into custom code (firing on connection) [4]. One way around this would be to only do the resetting when a user actually enters something at the prompt, but unless you want that to happen on *any* /CMD, we'd need special handling [5] for the handful desired (possibly chosen via configurable option). ~~~ [1] A related issue is the means of detecting whether we're joined to a channel. With traditional pub/sub services (IRC channels are really just "topics"), it's in the client's interest to stay abreast of its subscription status. And the service API also typically exposes a way for a client to query for this out of band. ERC *does* track a channel's JOIN'd state, but it's a bit hampered by legacy features related to how targets are currently handled (via `erc-default-recipients' and functions that access/mutate it). [2] https://ircv3.net/irc/#labeled-responses [3] "Logical" meaning including serially, i.e., spanning disconnects. [4] In ERC's case, these commands aren't designated as being primarily intended for /interactive use (`erc-cmd-JOIN`, being one such function, naturally suffers from the same flaw). [5] Hopefully something more flexible than adding/removing properties, like `process-not-needed', which creates problems when trying to override /CMDs.