From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bandali@gnu.org, bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Nov 2021 15:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 51753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 51753@debbugs.gnu.org Cc: Amin Bandali X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: Amin Bandali Received: via spool by submit@debbugs.gnu.org id=B.163655697119485 (code B ref -1); Wed, 10 Nov 2021 15:10:01 +0000 Received: (at submit) by debbugs.gnu.org; 10 Nov 2021 15:09:31 +0000 Received: from localhost ([127.0.0.1]:39038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkpEA-00054D-Su for submit@debbugs.gnu.org; Wed, 10 Nov 2021 10:09:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:52698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkpE7-00053x-T2 for submit@debbugs.gnu.org; Wed, 10 Nov 2021 10:09:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkpE7-0003uB-Pz for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 10:09:27 -0500 Received: from mail-pg1-f172.google.com ([209.85.215.172]:34405) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mkpE6-0001j4-2M for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 10:09:27 -0500 Received: by mail-pg1-f172.google.com with SMTP id 200so2543876pga.1 for ; Wed, 10 Nov 2021 07:09:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=cGEcjGmE7QqGUbDDd+GawYF7QtE3K70OT2frKf+17Ic=; b=GiteP8U+EFBp7QJgaP1euxBy8g6uQG8Sruk6/0HWe5gxGl9+kAzGQ41VMPG1G4TzpZ qMV1tkurqc98B/Of6EdTc+GC38304zBqkguyHCM3+OjEaKKD7e8ofdaD0z2a51sAyeKm fZd06uyxEQ1ogtek26LKKWgDfqPhvkpuJEIA/+8P2NF6kgFCGGI8Pd01jibmeINVSLVs HvjYaBxMgf9qTwzjGlw7R1O3WeZaOLdZXHV94htt+gpTbEuRLSsDwla4p3/VtMUq0z2v Yousmv62OQmlNTZoEDwyCCs2hmc8WOXxFYJXj9Z7p+lhV6LVGZnHxjzYw2d/4CSFG2WW Yzyw== X-Gm-Message-State: AOAM532fyds/6RONa+ENPWxmA363HjGNns9LDwUbSnEFF+qoS0YpuzlA RxXO7gwSHa9IyPHLVhOxPKI8/OuyCJ2JG8P8wvKa4mU1 X-Google-Smtp-Source: ABdhPJxXnmdVb71BYXALTN4aICSSmQlpP4Z7BhANJT77E0kZ9l012FEYSrsTRWWw/e9PErs5CtBrBC6/OEycZZU8VFM= X-Received: by 2002:a05:6a00:244d:b0:44d:c279:5155 with SMTP id d13-20020a056a00244d00b0044dc2795155mr3558pfj.0.1636556964724; Wed, 10 Nov 2021 07:09:24 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Nov 2021 07:09:24 -0800 From: Stefan Kangas MIME-Version: 1.0 Date: Wed, 10 Nov 2021 07:09:24 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=209.85.215.172; envelope-from=stefankangas@gmail.com; helo=mail-pg1-f172.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) Severity: important When ERC reconnects, it switches buffer to the channel buffers. This is *very* dangerous. Consider the situation when the user is about to paste a password and hit enter with a quick "C-y RET", when all of a sudden the ERC buffer pops up a fraction of a second before you hit those keys. Now your password is on IRC. At the very least, this behavior should be disabled by default, and preferably also come with a big warning sign for anyone that intends to enable it. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Nov 2021 03:15: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: To: Stefan Kangas Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org, Amin Bandali Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163660048521938 (code B ref 51753); Thu, 11 Nov 2021 03:15:02 +0000 Received: (at 51753) by debbugs.gnu.org; 11 Nov 2021 03:14:45 +0000 Received: from localhost ([127.0.0.1]:39652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml0Y1-0005hm-I8 for submit@debbugs.gnu.org; Wed, 10 Nov 2021 22:14:45 -0500 Received: from mail-108-mta144.mxroute.com ([136.175.108.144]:44769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml0Xw-0005hG-LT for 51753@debbugs.gnu.org; Wed, 10 Nov 2021 22:14:44 -0500 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta144.mxroute.com (ZoneMTA) with ESMTPSA id 17d0cfd61ea0000b55.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 11 Nov 2021 03:14:32 +0000 X-Zone-Loop: c66a96115934e4e6ffe5aba249a813e9ba878a1335d7 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=TOvhXXd7VzoKyrABQU2Px9umdwVNueP8XUVCyPr839E=; b=mTeXPuuBJfLKmzGlGZfa4Joia0 f4D45E+Nx024xQ++udhJE7tg0a4dW8GGG6p6PcrBepRreNdwikBkRZ5RpvmdcAAhbXCpyR09nJ8L3 PDKUxQM1DsbqXevGp4t3qXzxvrGUXqh74z2mrPQl5xgj+99v2M1Xv8lEQxAmRslzu7eejhkqH4FmX Zp4Vyqm3iyOymZxij3gHef6M2b4dScx7++f3BD3dyaCjKVhJOhDagbMfYHyBdcGoyR3pXFwU3YLaX /0vOgYkltgYgaKmP64++IkhF7iZUNZYUZL6BFlZlwFeByLDuiJsj1xjCMXd4wSlaYSq4DIVP3oON9 4LtA34/w==; From: "J.P." References: Date: Wed, 10 Nov 2021 19:14:29 -0800 In-Reply-To: (Stefan Kangas's message of "Wed, 10 Nov 2021 07:09:24 -0800") Message-ID: <877ddfgz8q.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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, RCPT_COUNT_THREE=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0, MID_RHS_MATCH_FROM=0] X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Kangas writes: > Severity: important > > When ERC reconnects, it switches buffer to the channel buffers. This is > *very* dangerous. Hi Stefan. Any idea if this is a recent phenomenon or more along the lines of traditional behavior, perhaps involving `erc-join-buffer', for example? I ask this mostly out of self interest re commit 17e7cab1507a185d2c493548494abcad6a55d159 Normalize usage of variable erc-server-reconnecting and its followup commit ec9ddd6eaf3f1b118d3ce95a69e1d046166362d3 Deprecate instead of redefine erc-server-reconnecting (both recent and both mine). Regardless, there's a solid chance what you're experiencing is `erc-setup-buffer' related, which comes into play whenever `erc-open' runs. For reconnects, this happens both during `erc-server-reconnect' and again whenever `erc-server-JOIN' runs (for channels you join). It'd also be nice to know how these JOIN replies are being triggered (server-initiated, erc-join.el, manual /join, etc.). With the join module, they'd likely be the result of a JOIN command (request) sent by `erc-autojoin-channels', which runs on 376/422. This matters when trying to pinpoint problematic interplay with the reconnect logic, if such a thing exists. > Consider the situation when the user is about to paste a password and > hit enter with a quick "C-y RET", when all of a sudden the ERC buffer > pops up a fraction of a second before you hit those keys. Now your > password is on IRC. > > At the very least, this behavior should be disabled by default, and > preferably also come with a big warning sign for anyone that intends to > enable it. I don't think many would argue that this behavior isn't at least annoying. While specific scenarios (like accidentally broadcasting creds to a channel) are important to confront, we should also remember to take in the long view whenever possible (IMO). And in doing so, I think we'll find that the many downsides of interfacing with a services bot have over time compelled the IRC world to embrace SASL (part of the IRCv3 initiative) as the preferred means of authentication. Thanks. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Nov 2021 03:30: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: To: "J.P." Cc: Amin Bandali , 51753@debbugs.gnu.org, emacs-erc@gnu.org, Stefan Kangas Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163660139923475 (code B ref 51753); Thu, 11 Nov 2021 03:30:02 +0000 Received: (at 51753) by debbugs.gnu.org; 11 Nov 2021 03:29:59 +0000 Received: from localhost ([127.0.0.1]:39670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml0ml-00066Z-J9 for submit@debbugs.gnu.org; Wed, 10 Nov 2021 22:29:59 -0500 Received: from quimby.gnus.org ([95.216.78.240]:48892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml0mf-00066E-5z for 51753@debbugs.gnu.org; Wed, 10 Nov 2021 22:29:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; 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=427bOdj2PZx4omAfzf/aCiJfKqPfZady3mTLwCzgqz8=; b=Wcx97DTSn8A0U1rcc3+jQM5d+x TWhFnGF+OfZJ3Tyl0k7lJRrbkQQp6vkwMB7rwLsohH0N1zgUmnYG4hFCOHkwUVhDPUmaDvoi5n/6j L+pxsMFCWVQ88eIgclQBuQTtSIdXZTBI2ma8Ui+scLRRWvulUyoziDSWmBKBWsyd3gxk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ml0mW-0001rN-9S; Thu, 11 Nov 2021 04:29:46 +0100 From: Lars Ingebrigtsen References: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEVKLCVPLCORZE60 ln7///8IGfnBAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+ULCwIsAv43SG0AAAF7SURBVDjLnZPbecMg DIUFXQBpAkss0MD+u+UIgQ1t+lISXz5+ju4m8sXMheJtPsfKGiBtYDxaA+CUBbu3EueMzBWcK+5S SEoA6larmTWr+GM1NQ1Qe++ttZe11jvAq9sAr3FcrSXDfayhsG9iQVwFLljhazmvl6cB8NWrtQ1g pUGG7iMIYfkDMH0AttVsAYEDMfsB2PeUkQCuEkenwsG8gkwgSC5ylgOQ+AaKCHMs1wHuJSgURdO8 JSYakKetUGQPKVudTnbnEEgNSZiaecC5aDRCd4DzHi5a2ZzeILHXW7zDw1q5o0KdFNNVretSBMiY J0qXR9Rsz8PfvegiHu71APhIiCp5cWWWdzo33KIksyEBxEEMo6luCo9FvYO1rX6EjyLjuAfBuyni 0Tux7atJtI0JIJ+K2IcGfnifRFpjpc/E7abQimfinn1vCK5TwZnHRyMo12nKR45H1Kct7wnT+g5O gn2Jz2CBmRDj5xlS+qUow9YqxgbudP+53hVgPjdMzr2BAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIx LTExLTExVDAyOjQ0OjAyKzAwOjAwzg6UZAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0xMS0xMVQw Mjo0NDowMiswMDowML9TLNgAAAAASUVORK5CYII= X-Now-Playing: Fairport Convention's _Come All Ye (5)_: "Flowers of the Forest" Date: Thu, 11 Nov 2021 04:29:43 +0100 In-Reply-To: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> (J. P.'s message of "Wed, 10 Nov 2021 19:14:29 -0800") Message-ID: <87bl2re5eg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "J.P." writes: > Hi Stefan. Any idea if this is a recent phenomenon or more along the > lines of traditional behavior, perhaps involving `erc-join-buffer', for > example? erc has behaved this way as long as I can remember, and it's really annoying (especially when a server bounces and erc reconnects, popping up windows everywhere while I'm trying to get some work done) [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) "J.P." writes: > Hi Stefan. Any idea if this is a recent phenomenon or more along the > lines of traditional behavior, perhaps involving `erc-join-buffer', for > example? erc has behaved this way as long as I can remember, and it's really annoying (especially when a server bounces and erc reconnects, popping up windows everywhere while I'm trying to get some work done). So I'm all for making erc stopping doing this. erc does not pop up windows when somebody messages you (but just displays something in the mode line), and I think that's what erc should do for all buffers (by default; there could be a user option to allow it to pop up windows, of course). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Nov 2021 05:14:01 +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: To: Lars Ingebrigtsen Cc: Stefan Kangas , 51753@debbugs.gnu.org, emacs-erc@gnu.org, Amin Bandali Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163660760230189 (code B ref 51753); Thu, 11 Nov 2021 05:14:01 +0000 Received: (at 51753) by debbugs.gnu.org; 11 Nov 2021 05:13:22 +0000 Received: from localhost ([127.0.0.1]:39844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml2Oo-0007qr-0l for submit@debbugs.gnu.org; Thu, 11 Nov 2021 00:13:22 -0500 Received: from mail-108-mta18.mxroute.com ([136.175.108.18]:35185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml2Ol-0007qb-OP for 51753@debbugs.gnu.org; Thu, 11 Nov 2021 00:13:21 -0500 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta18.mxroute.com (ZoneMTA) with ESMTPSA id 17d0d6a014e0000b55.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 11 Nov 2021 05:13:10 +0000 X-Zone-Loop: 8b4f81d4381fc88eb4e26341024fbc56c52e322c6d21 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=m4eeA+PjNL1dkuf3HF/+GeNjerXXjdDWA0fwNbKpyy8=; b=Cx/jkC/lIq1Fdn6mxk+D+y4rlu FhQjFXCK2cxRIkzVPz+hNvl5il4lZiQ1GD6HjS5gmLY3wruceq5AwWPnPu3pLCzLdy6AeevMOn4U9 dULRRlXCQmw4GRJc9dpHVxVcxlGwKG49goPIaeY2buNjqqfeC94T2Fk+Avue2LOl6W19OJUisFwW8 S2iCJJXxceR8dxRkk7KMM5TqcGJQE9JgVjA3IGh36M9jpZmLPjhdjW50B5i278QwgycpLzP1wcRPr ig97Fsv7mvByYOaFK07xEkfTq/iAR8L08XjQj2nf+tYRqEk4A2E1qV+QkkfMhYTPCeUrU1BCjBHVN 5to61mgw==; From: "J.P." References: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> <87bl2re5eg.fsf@gnus.org> Date: Wed, 10 Nov 2021 21:13:07 -0800 In-Reply-To: <87bl2re5eg.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 11 Nov 2021 04:29:43 +0100") Message-ID: <87lf1ve0m4.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > erc does not pop up windows when somebody messages you (but just > displays something in the mode line), and I think that's what erc should > do for all buffers (by default; there could be a user option to allow it > to pop up windows, of course). The simplest approach might be to just change the default values of `erc-join-buffer' and `erc-auto-query' to 'bury. However, if people want something different to happen when automatically reconnecting, we'd probably have to remember whether `erc-server-reconnect-count' was ever positive before crossing the logical connection threshold for the current session. This may come down to having `erc-connection-established' record the count prior to resetting it (perhaps in a new, internal variable). And then, during re-JOINs, `erc-setup-buffer' could weigh that recorded value against some new option, like an `erc-display-reconnect' (or whatever), and proceed accordingly. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Nov 2021 05:23: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: To: "J.P." Cc: Stefan Kangas , 51753@debbugs.gnu.org, emacs-erc@gnu.org, Amin Bandali Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.16366081386988 (code B ref 51753); Thu, 11 Nov 2021 05:23:02 +0000 Received: (at 51753) by debbugs.gnu.org; 11 Nov 2021 05:22:18 +0000 Received: from localhost ([127.0.0.1]:39858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml2XS-0001oe-7Y for submit@debbugs.gnu.org; Thu, 11 Nov 2021 00:22:18 -0500 Received: from quimby.gnus.org ([95.216.78.240]:50056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml2XQ-0001oP-2V for 51753@debbugs.gnu.org; Thu, 11 Nov 2021 00:22:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; 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=cOwTGtW4u0ElIp9PpPtmZDys2KHDiw+YmzJ9miwjVso=; b=gaY8XoWBwK3zP5bDl4IPIHlhJv zoOTj0cf7bG9NdPBu58H23dXEv3iibbtGRr/Bf1+FbJhJ5N34NDXwcte7TTsF0HZ0EHAvwgTZJSw1 89XEles92ExZkhn4jd3yd9vDLOuS0JaZW4TMuz9CTlNVsgDINtdgDT0jqP8awx8LCVLc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ml2XH-0002b4-9u; Thu, 11 Nov 2021 06:22:09 +0100 From: Lars Ingebrigtsen References: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> <87bl2re5eg.fsf@gnus.org> <87lf1ve0m4.fsf@neverwas.me> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEXtzbHTsJnOsZu8 kHCnb06oXTV6Uj3///+a7gE0AAAAAWJLR0QHFmGI6wAAAAd0SU1FB+ULCwUUOV3sCzcAAAGYSURB VDjLdZJhksIgDIXBEwC9gNATWOoJCv5fLV5gV+5/hH0JRVtaMzrTyUfy8gJCNCHPWo/xRzdZ/OwR OGltrNkCHEZWm35wbkzbCiWM1Obi3DU9WoCiwQ/hU6HQSnIrV1p1JS01strq3jgCIW3FSysadw8U g1aDK7TlVl21ABloUCvn+ljFl9DiRCtxLjYGtTBCHlao4sOvAIvDB45779sKbBetWoMLYOfXfYWs zju6BR5IqqKBqdwY7+24SghUXNP904qnMvhgg3e/AerEoK+AdlXug52Tj4dfSWC7qDgAooCBwZHz pQI25LKrszBm2dWulXT9cASMXgH5AbJzBNyiQWHlyWrOUsT462mJMKDoHQKUi7rNRYP3W0A/UNGt aCD1rqDzPuT8yxq4G0vviQXGKYQ8P8YqThzvAzH58fma6lSYQOO2e2hP0MhvYH3HfcZAccsQDyXS M+eUcnrFvzi/aCocC4EUwxRqsPMQ5rALegzpMPASv4DuO/DTuO0/efwvnVilZowzR/ogkOY6VeR5 AnUK3v8DqpuS1kRgI7QAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMTEtMTFUMDU6MjA6NTcrMDA6 MDBI+9nGAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTExLTExVDA1OjIwOjU3KzAwOjAwOaZhegAA AABJRU5ErkJggg== X-Now-Playing: King Crimson's _The Complete 1969 Recordings (26): BBC Sessions_: "I Talk To The Wind" Date: Thu, 11 Nov 2021 06:22:06 +0100 In-Reply-To: <87lf1ve0m4.fsf@neverwas.me> (J. P.'s message of "Wed, 10 Nov 2021 21:13:07 -0800") Message-ID: <877ddf9sht.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "J.P." writes: > The simplest approach might be to just change the default values of > `erc-join-buffer' and `erc-auto-query' to 'bury. Yup. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) "J.P." writes: > The simplest approach might be to just change the default values of > `erc-join-buffer' and `erc-auto-query' to 'bury. Yup. > However, if people want something different to happen when > automatically reconnecting, we'd probably have to remember whether > `erc-server-reconnect-count' was ever positive before crossing the > logical connection threshold for the current session. > > This may come down to having `erc-connection-established' record the > count prior to resetting it (perhaps in a new, internal variable). And > then, during re-JOINs, `erc-setup-buffer' could weigh that recorded > value against some new option, like an `erc-display-reconnect' (or > whatever), and proceed accordingly. Sounds good to me. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Nov 2021 10:37:01 +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: To: Lars Ingebrigtsen Cc: Stefan Kangas , 51753@debbugs.gnu.org, emacs-erc@gnu.org, Amin Bandali Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163731821616292 (code B ref 51753); Fri, 19 Nov 2021 10:37:01 +0000 Received: (at 51753) by debbugs.gnu.org; 19 Nov 2021 10:36:56 +0000 Received: from localhost ([127.0.0.1]:38167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mo1GK-0004Ei-AZ for submit@debbugs.gnu.org; Fri, 19 Nov 2021 05:36:56 -0500 Received: from mail-108-mta1.mxroute.com ([136.175.108.1]:33647) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mo1GI-0004EQ-9a for 51753@debbugs.gnu.org; Fri, 19 Nov 2021 05:36:54 -0500 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta1.mxroute.com (ZoneMTA) with ESMTPSA id 17d37c51a74000177f.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 19 Nov 2021 10:36:44 +0000 X-Zone-Loop: 1fff201c1f01186f20230320652282322cf5beb6dd80 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=gbQyTSHdOqntVd/EB8nNcy26pFx7UNxKBVEmqR+c7rc=; b=iiseloqpHYydprl1iNDA7ypyC9 3Cb8gzoncfFvbGdmXItChyPU0wTj3lNxlSGI+5uZIGPo3TcI3nuVwqyfhMQMOTtiq+KVAsTfiVidp ozimx+S5SrlC5vDp35+iI4bwMBKu5LxKkZwFN+z2AEVLBNKtD+05eviOu0Zin8yi1AJIZzm6q2has jSIqOG8IYhAziyhR7agHRtfy4b2UwAFLZA33V4UhiW6Br+beFQ2ZoKyyuFuQ1Qv7XzjLa8aC+884s 0Ingaz/eChsJs/dxTZ/1Lenwwu7IK7IF9vlCd5PubPkOClcEXDkUmka0RtUWHYP2s68A+rSu6BWfK 9rcZQLBA==; From: "J.P." References: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> <87bl2re5eg.fsf@gnus.org> <87lf1ve0m4.fsf@neverwas.me> <877ddf9sht.fsf@gnus.org> Date: Fri, 19 Nov 2021 02:36:40 -0800 In-Reply-To: <877ddf9sht.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 11 Nov 2021 06:22:06 +0100") Message-ID: <87czmwjutj.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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, HAS_ATTACHMENT=0, FROM_EQ_ENVFROM=0, MIME_TRACE=0, MIME_GOOD=-0.1, RCPT_COUNT_FIVE=0, MID_RHS_MATCH_FROM=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Lars Ingebrigtsen writes: >> However, if people want something different to happen when >> automatically reconnecting, we'd probably have to remember whether >> `erc-server-reconnect-count' was ever positive before crossing the >> logical connection threshold for the current session. >> >> This may come down to having `erc-connection-established' record the >> count prior to resetting it (perhaps in a new, internal variable). And >> then, during re-JOINs, `erc-setup-buffer' could weigh that recorded >> value against some new option, like an `erc-display-reconnect' (or >> whatever), and proceed accordingly. > > Sounds good to me. I wasn't sure if that meant I was supposed to work on this. If not, please disregard. Otherwise, the tests are in #48598 [1]. As for the name of the option itself, I basically punted by going with `erc-reconnect-buffer' to try and stay close to `erc-join-buffer'. If that doesn't matter, perhaps `erc-reconnect-display' would be a better fit since we already have an `erc-query-display' (even though that one's not as closely related). Anyone with an opinion, please advise. Thanks. [1] Around line 4736: https://gitlab.com/jpneverwas/erc-tools/-/raw/master/bugs/48598/patches/wip/0013-Update-ERC-scenarios-with-session-centric-naming.patch Or browsable (JS): https://gitlab.com/jpneverwas/erc-v3/-/blob/1333bda3c0d11ff06b1b2acbb27864c90d5ba303/test/erc-scenarios.el#L1668 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch >From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Thu, 18 Nov 2021 23:39:54 -0800 Subject: [PATCH 01/29] Customize displaying of ERC buffers on reconnect * lisp/erc/erc-backend.el (erc--server-last-reconnect-count): Add variable to record last reconnect tally. * lisp/erc/erc.el (erc-reconnect-buffer): Add option to specify channel-buffer display behavior on reconnect. (erc-setup-buffer): Use option `erc-reconnect-buffer' if warranted. (erc-connection-established): Record reconnect count in internal var before resetting. --- lisp/erc/erc-backend.el | 3 +++ lisp/erc/erc.el | 24 ++++++++++++++++++++++-- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/lisp/erc/erc-backend.el b/lisp/erc/erc-backend.el index 69f63dfbc4..4b39bd8a30 100644 --- a/lisp/erc/erc-backend.el +++ b/lisp/erc/erc-backend.el @@ -193,6 +193,9 @@ erc-server-connected (defvar-local erc-server-reconnect-count 0 "Number of times we have failed to reconnect to the current server.") +(defvar-local erc--server-last-reconnect-count 0 + "Snapshot of reconnect count when connection established.") + (defvar-local erc-server-quitting nil "Non-nil if the user requests a quit.") diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index c5a4fbe5a0..21ae25d920 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1521,6 +1521,22 @@ erc-join-buffer (const :tag "Use current buffer" buffer) (const :tag "Use current buffer" t))) +(defcustom erc-reconnect-buffer nil + "How (and whether) to display a channel buffer upon reconnecting. + +This only affects automatic reconnections and is ignored when issuing a +/reconnect command or reinvoking `erc-tls' with the same args (assuming +success, of course). See `erc-join-buffer' for a description of +possible values." + :group 'erc-buffers + :type '(choice (const :tag "Use value of `erc-join-buffer'" nil) + (const :tag "Split window and select" window) + (const :tag "Split window, don't select" window-noselect) + (const :tag "New frame" frame) + (const :tag "Bury in new buffer" bury) + (const :tag "Use current buffer" buffer) + (const :tag "Use current buffer" t))) + (defcustom erc-frame-alist nil "Alist of frame parameters for creating erc frames. A value of nil means to use `default-frame-alist'." @@ -1950,7 +1966,10 @@ erc-update-modules (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." - (pcase erc-join-buffer + (pcase (if (zerop (erc-with-server-buffer + erc--server-last-reconnect-count)) + erc-join-buffer + (or erc-reconnect-buffer erc-join-buffer)) ('window (if (active-minibuffer-window) (display-buffer buffer) @@ -4722,7 +4741,8 @@ erc-connection-established (nick (car (erc-response.command-args parsed))) (buffer (process-buffer proc))) (setq erc-server-connected t) - (setq erc-server-reconnect-count 0) + (setq erc--server-last-reconnect-count erc-server-reconnect-count + erc-server-reconnect-count 0) (erc-update-mode-line) (erc-set-initial-user-mode nick buffer) (erc-server-setup-periodical-ping buffer) -- 2.31.1 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Nov 2021 11:46: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: To: "J.P." , Lars Ingebrigtsen Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org, Amin Bandali Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163732232224641 (code B ref 51753); Fri, 19 Nov 2021 11:46:02 +0000 Received: (at 51753) by debbugs.gnu.org; 19 Nov 2021 11:45:22 +0000 Received: from localhost ([127.0.0.1]:38243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mo2KX-0006PN-U6 for submit@debbugs.gnu.org; Fri, 19 Nov 2021 06:45:22 -0500 Received: from mail-pf1-f174.google.com ([209.85.210.174]:45654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mo2KW-0006P5-R9 for 51753@debbugs.gnu.org; Fri, 19 Nov 2021 06:45:21 -0500 Received: by mail-pf1-f174.google.com with SMTP id x131so9160762pfc.12 for <51753@debbugs.gnu.org>; Fri, 19 Nov 2021 03:45:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=DYTKuxr16cXwP/GETHJq7dcVY7dR5byMAlWGcr+jOcM=; b=WbjmQmyuRKQekZD/41etW2xj+44Gd2bT2QTCrTNDUTU62ww8fNy2rocF2AHiGnAQdI B7Ao83HSKe3ic98o2CSK+OXABND0nACVgW1biPJq5+jt0m9B14IxYcY3VWewbJXyAmVr Xp2ie9TVxTGOuIXTSOEJidjhS8csQtpe/aCGPpWfSIgm20O+J70KNfKfrkS48+6Vs6kH wZW7QtWTrz2/e+6XOcS+bsKs2V1nYbuxfWlEygSntrNTHEgoL0vAHHGobj0Pj67JB/aK k7VEisCvPOLYS1LaNtABp9nMSwKglomP2WObmsK/lWWnFYUdF1mGhguECQ+0iIGl5KD/ Ywig== X-Gm-Message-State: AOAM532/tKtz/ZLuschA4yTAkLS2o9VGQgJtOh1DLZIeCTbdOR6fujgv WSNhv1wP/NsSw+V7Z/a4jC6wapozW/ik5FgXE4c= X-Google-Smtp-Source: ABdhPJypAe2DQM8cIP3TOffo6+jHDXZwglsfJznwR5ZMQSVmZNkeWxp749ENinqE01xvy7ypeBUu91c5R9WOxogY4Bo= X-Received: by 2002:a63:370c:: with SMTP id e12mr16570969pga.359.1637322314979; Fri, 19 Nov 2021 03:45:14 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 19 Nov 2021 12:45:14 +0100 From: Stefan Kangas In-Reply-To: <87czmwjutj.fsf@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> MIME-Version: 1.0 Date: Fri, 19 Nov 2021 12:45:14 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) tags 51753 + patch thanks "J.P." writes: > I wasn't sure if that meant I was supposed to work on this. If not, > please disregard. You did exactly the right thing here. Thank you for working on this! > Otherwise, the tests are in #48598 [1]. As for the name of the option > itself, I basically punted by going with `erc-reconnect-buffer' to try > and stay close to `erc-join-buffer'. If that doesn't matter, perhaps > `erc-reconnect-display' would be a better fit since we already have an > `erc-query-display' (even though that one's not as closely related). > Anyone with an opinion, please advise. Thanks. On balance, I don't have a strong opinion either way. (I do like `erc-reconnect-display' slightly better, because many variables that end with `-buffer' have to do with the _name_ of some buffer. But it is true that it is also nice to have a name similar to `erc-join-buffer'.) I just have some minor nits below: > +(defvar-local erc--server-last-reconnect-count 0 > + "Snapshot of reconnect count when connection established.") "when the connection was established", perhaps? > +(defcustom erc-reconnect-buffer nil > + "How (and whether) to display a channel buffer upon reconnecting. > + > +This only affects automatic reconnections and is ignored when issuing a > +/reconnect command or reinvoking `erc-tls' with the same args (assuming > +success, of course). See `erc-join-buffer' for a description of > +possible values." > + :group 'erc-buffers > + :type '(choice (const :tag "Use value of `erc-join-buffer'" nil) > + (const :tag "Split window and select" window) > + (const :tag "Split window, don't select" window-noselect) > + (const :tag "New frame" frame) > + (const :tag "Bury in new buffer" bury) > + (const :tag "Use current buffer" buffer) > + (const :tag "Use current buffer" t))) What is the difference between `buffer' and t? Should they really have the same :tag? If they are just two names for the same thing, I suggest we drop one of them. Other than that, LGTM (but I didn't test it). From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Nov 2021 13:15: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 To: Stefan Kangas Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163732765120647 (code B ref 51753); Fri, 19 Nov 2021 13:15:02 +0000 Received: (at 51753) by debbugs.gnu.org; 19 Nov 2021 13:14:11 +0000 Received: from localhost ([127.0.0.1]:38378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mo3iV-0005Mx-BQ for submit@debbugs.gnu.org; Fri, 19 Nov 2021 08:14:11 -0500 Received: from mail-108-mta62.mxroute.com ([136.175.108.62]:45709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mo3iT-0005Mg-F1 for 51753@debbugs.gnu.org; Fri, 19 Nov 2021 08:14:10 -0500 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta62.mxroute.com (ZoneMTA) with ESMTPSA id 17d3855200a000177f.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 19 Nov 2021 13:14:02 +0000 X-Zone-Loop: 6326f686473d14bb7ea9f0686743b6b84cd8cd8de0c9 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=Ya6YSBxhT1MJJ/xeLYMhB27nsUdKZCfHjwkFRKERN9I=; b=g/vluah3GN8Y9q7oVryLzw4dCH vLmlAojH9U9tjFvWt9q7Wc/BPbiu5exKa3Hkb4JIIf8qsyq3/1gqgLqjRSgzLrd+SxknjDwJdDXfD jXOFuCg1BsAKHH/Ce2ymBaVw3YGv2DPzRzhwM/0jEkmMqd4dRRrDXWiG7A5t95VGjLbZcJ/wxVaH6 Rgj/zXCJuSMY8EF9TNsKqi1TeteA0aCxCH9fPz3BnoBuEhbtQx9y+NdhXd29brx8VJ2DgEiixvW44 B1j1UCyKHySZ/ZChEl0T7eqZQJcyk69wjabMXkQe7jlghdsqJxfLfD14vQ+pxcGTppkR4lTxfT/to Q0DfbxaA==; From: "J.P." 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> Date: Fri, 19 Nov 2021 05:13:58 -0800 In-Reply-To: (Stefan Kangas's message of "Fri, 19 Nov 2021 12:45:14 +0100") Message-ID: <875ysothih.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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, HAS_ATTACHMENT=0, FROM_EQ_ENVFROM=0, MIME_TRACE=0, MIME_GOOD=-0.1, RCPT_COUNT_FIVE=0, MID_RHS_MATCH_FROM=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Stefan Kangas writes: > On balance, I don't have a strong opinion either way. (I do like > `erc-reconnect-display' slightly better, because many variables that end > with `-buffer' have to do with the _name_ of some buffer. But it is > true that it is also nice to have a name similar to `erc-join-buffer'.) Screw it. Let's go with `erc-reconnect-display'. > I just have some minor nits below: > >> +(defvar-local erc--server-last-reconnect-count 0 >> + "Snapshot of reconnect count when connection established.") > > "when the connection was established", perhaps? Now reads as ^. > What is the difference between `buffer' and t? Should they really have > the same :tag? No idea to both, unfortunately. But since the option is only used in that one function (`erc-setup-buffer'), and since we don't claim like-for-like compatibility with `erc-join-buffer' (which we've already deviated from anyway by offering a choice of nil) ... > I suggest we drop one of them. Agreed. Thanks. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0000-v1-v2.diff >From d7e9871283cfc6f0e841adf99251ae7057d39d7b Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Fri, 19 Nov 2021 04:41:50 -0800 Subject: NOT A PATCH F. Jason Park (1): Customize displaying of ERC buffers on reconnect lisp/erc/erc-backend.el | 3 +++ lisp/erc/erc.el | 23 +++++++++++++++++++++-- 2 files changed, 24 insertions(+), 2 deletions(-) Interdiff: diff --git a/lisp/erc/erc-backend.el b/lisp/erc/erc-backend.el index 4b39bd8a30..0d586268e9 100644 --- a/lisp/erc/erc-backend.el +++ b/lisp/erc/erc-backend.el @@ -194,7 +194,7 @@ erc-server-reconnect-count "Number of times we have failed to reconnect to the current server.") (defvar-local erc--server-last-reconnect-count 0 - "Snapshot of reconnect count when connection established.") + "Snapshot of reconnect count when the connection was established.") (defvar-local erc-server-quitting nil "Non-nil if the user requests a quit.") diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 21ae25d920..01be8ed397 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1521,7 +1521,7 @@ erc-join-buffer (const :tag "Use current buffer" buffer) (const :tag "Use current buffer" t))) -(defcustom erc-reconnect-buffer nil +(defcustom erc-reconnect-display nil "How (and whether) to display a channel buffer upon reconnecting. This only affects automatic reconnections and is ignored when issuing a @@ -1534,8 +1534,7 @@ erc-reconnect-buffer (const :tag "Split window, don't select" window-noselect) (const :tag "New frame" frame) (const :tag "Bury in new buffer" bury) - (const :tag "Use current buffer" buffer) - (const :tag "Use current buffer" t))) + (const :tag "Use current buffer" buffer))) (defcustom erc-frame-alist nil "Alist of frame parameters for creating erc frames. @@ -1969,7 +1968,7 @@ erc-setup-buffer (pcase (if (zerop (erc-with-server-buffer erc--server-last-reconnect-count)) erc-join-buffer - (or erc-reconnect-buffer erc-join-buffer)) + (or erc-reconnect-display erc-join-buffer)) ('window (if (active-minibuffer-window) (display-buffer buffer) -- 2.31.1 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch >From d7e9871283cfc6f0e841adf99251ae7057d39d7b Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Thu, 18 Nov 2021 23:39:54 -0800 Subject: [PATCH 1/1] Customize displaying of ERC buffers on reconnect * lisp/erc/erc-backend.el (erc--server-last-reconnect-count): Add variable to record last reconnect tally. * lisp/erc/erc.el (erc-reconnect-buffer): Add option to specify channel-buffer display behavior on reconnect. (erc-setup-buffer): Use option `erc-reconnect-buffer' if warranted. (erc-connection-established): Record reconnect count in internal var before resetting. --- lisp/erc/erc-backend.el | 3 +++ lisp/erc/erc.el | 23 +++++++++++++++++++++-- 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/lisp/erc/erc-backend.el b/lisp/erc/erc-backend.el index 69f63dfbc4..0d586268e9 100644 --- a/lisp/erc/erc-backend.el +++ b/lisp/erc/erc-backend.el @@ -193,6 +193,9 @@ erc-server-connected (defvar-local erc-server-reconnect-count 0 "Number of times we have failed to reconnect to the current server.") +(defvar-local erc--server-last-reconnect-count 0 + "Snapshot of reconnect count when the connection was established.") + (defvar-local erc-server-quitting nil "Non-nil if the user requests a quit.") diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index c5a4fbe5a0..01be8ed397 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1521,6 +1521,21 @@ erc-join-buffer (const :tag "Use current buffer" buffer) (const :tag "Use current buffer" t))) +(defcustom erc-reconnect-display nil + "How (and whether) to display a channel buffer upon reconnecting. + +This only affects automatic reconnections and is ignored when issuing a +/reconnect command or reinvoking `erc-tls' with the same args (assuming +success, of course). See `erc-join-buffer' for a description of +possible values." + :group 'erc-buffers + :type '(choice (const :tag "Use value of `erc-join-buffer'" nil) + (const :tag "Split window and select" window) + (const :tag "Split window, don't select" window-noselect) + (const :tag "New frame" frame) + (const :tag "Bury in new buffer" bury) + (const :tag "Use current buffer" buffer))) + (defcustom erc-frame-alist nil "Alist of frame parameters for creating erc frames. A value of nil means to use `default-frame-alist'." @@ -1950,7 +1965,10 @@ erc-update-modules (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." - (pcase erc-join-buffer + (pcase (if (zerop (erc-with-server-buffer + erc--server-last-reconnect-count)) + erc-join-buffer + (or erc-reconnect-display erc-join-buffer)) ('window (if (active-minibuffer-window) (display-buffer buffer) @@ -4722,7 +4740,8 @@ erc-connection-established (nick (car (erc-response.command-args parsed))) (buffer (process-buffer proc))) (setq erc-server-connected t) - (setq erc-server-reconnect-count 0) + (setq erc--server-last-reconnect-count erc-server-reconnect-count + erc-server-reconnect-count 0) (erc-update-mode-line) (erc-set-initial-user-mode nick buffer) (erc-server-setup-periodical-ping buffer) -- 2.31.1 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 07:23: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 To: Stefan Kangas Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163739293017524 (code B ref 51753); Sat, 20 Nov 2021 07:23:02 +0000 Received: (at 51753) by debbugs.gnu.org; 20 Nov 2021 07:22:10 +0000 Received: from localhost ([127.0.0.1]:41484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moKhO-0004YY-H5 for submit@debbugs.gnu.org; Sat, 20 Nov 2021 02:22:10 -0500 Received: from mail-108-mta168.mxroute.com ([136.175.108.168]:36327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moKhM-0004Y3-Fc for 51753@debbugs.gnu.org; Sat, 20 Nov 2021 02:22:09 -0500 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta168.mxroute.com (ZoneMTA) with ESMTPSA id 17d3c393685000177f.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sat, 20 Nov 2021 07:22:02 +0000 X-Zone-Loop: 86dc3ce2d57484e84e3cfee51c2244c1169dee37e27c 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=4d/mpmOVdlRXDnBB+2g0Pdwq1uJrUrgDbmhCPWlilxs=; b=gS/VWeSqelQNL4TaLr9aAK0QeY Mn4WUAF1RgcVNwvRJbXYUu5NtGpjNNErEIHd/s1ryKmz0Hrpw3h7rFs43w+I+Zu54KIdVeGEw8qkx 13tTgrrhLZjLbuyrjl0Z/XJsHt4OpWsJvdi6521VzJX8K2tSboh6owx1uJkpbccP7VkoLcxhIanir 5I9gKr3aTSlIhVy5fnxYLOnDlBMcXV14zapDXmHvfHGca7jr7aq/Qlpd0cFxSTFsmw6uFGu0+8dnj HrtFlarzCgi6m+TePCcBHIhd3gy1i9s7DzOaI5n5nC5K3y5NKNRHLokKJn0R+9jEIj++2igof1xp1 ipTtfJiQ==; From: "J.P." 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> Date: Fri, 19 Nov 2021 23:21:59 -0800 In-Reply-To: (Stefan Kangas's message of "Fri, 19 Nov 2021 12:45:14 +0100") Message-ID: <87ilwnnvfs.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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, NEURAL_SPAM=0, RCPT_COUNT_FIVE=0, RCVD_COUNT_ZERO=0, FROM_EQ_ENVFROM=0, MIME_TRACE=0, MID_RHS_MATCH_FROM=0] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) It just occurred to me that we may also want to reset `erc--server-last-reconnect-count' at some point after all (re)JOINing is done with (both client- and server-initiated) so that the option `erc-join-buffer' regains precedence over `erc-reconnect-display' for the remainder of the connection. Doing so in `erc-cmd-JOIN' would cover manually issued /JOINs as well as invocations of `erc-join-channel'. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 09:10:01 +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 To: "J.P." Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163739935730666 (code B ref 51753); Sat, 20 Nov 2021 09:10:01 +0000 Received: (at 51753) by debbugs.gnu.org; 20 Nov 2021 09:09:17 +0000 Received: from localhost ([127.0.0.1]:41660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moMN3-0007yX-II for submit@debbugs.gnu.org; Sat, 20 Nov 2021 04:09:17 -0500 Received: from mail-pf1-f180.google.com ([209.85.210.180]:35629) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moMN1-0007yJ-3v for 51753@debbugs.gnu.org; Sat, 20 Nov 2021 04:09:16 -0500 Received: by mail-pf1-f180.google.com with SMTP id c4so11436593pfj.2 for <51753@debbugs.gnu.org>; Sat, 20 Nov 2021 01:09:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=a4puzxJFW/mzNnF/ANlbjOZQywDNULoYWx6evKPcEhw=; b=6SfhR5pP4hRlj5UjkILHFdK0F5qt0qJ/pB7Qlc/bP1DC/nIdBmbKTXk/ASS6I0I9oJ Mp+GZmeXChKWKzOOUYz6a1jZVxx5XzLe/YD069a1n9sUDzS+I+eGrySSy0Vo5Zx/INsz 2pSH246cQ1kdbS8XzIiScz14UHFR5hv00Krx5ZQRshkeUupSZ9vc/pG0yIF/O04WUpXl yyQLfsZcw0hZLRcpUUtXYqPaTXjLdalpyncc0wFMBO+uYbo+nt3SgI/xUzhA4HOGlOx1 N3NFPHQo0Ko7EjRn6iM+looGKL6EglzAgI07CToz022Pswpq8+XVQ9+1eENkN7Y4H8uD A54g== X-Gm-Message-State: AOAM532+Kosr72aTVbJSqo2eUdBNmccKi4RqCMRatrFIsy1Uts7UFibE ezqAiQ6TXK47tNw3kqaeq2VlaJp/lwT+2vfEBbg= X-Google-Smtp-Source: ABdhPJxANivHnH248qLP9cGY1Ts2DN1hHLSZ6zwZRp+z/lZs0ugsWLyVYxgOkEIdfLw6GrJjlfTGxSoFJtmsFj426Y0= X-Received: by 2002:a05:6a00:1909:b0:49f:a0d0:abcf with SMTP id y9-20020a056a00190900b0049fa0d0abcfmr69969039pfi.70.1637399349433; Sat, 20 Nov 2021 01:09:09 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 20 Nov 2021 10:09:08 +0100 From: Stefan Kangas In-Reply-To: <87ilwnnvfs.fsf@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> MIME-Version: 1.0 Date: Sat, 20 Nov 2021 10:09:08 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) "J.P." writes: > It just occurred to me that we may also want to reset > `erc--server-last-reconnect-count' at some point after all (re)JOINing > is done with (both client- and server-initiated) so that the option > `erc-join-buffer' regains precedence over `erc-reconnect-display' for > the remainder of the connection. Doing so in `erc-cmd-JOIN' would cover > manually issued /JOINs as well as invocations of `erc-join-channel'. Sounds good to me. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Nov 2021 22:55: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 To: Stefan Kangas Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.16375352685640 (code B ref 51753); Sun, 21 Nov 2021 22:55:02 +0000 Received: (at 51753) by debbugs.gnu.org; 21 Nov 2021 22:54:28 +0000 Received: from localhost ([127.0.0.1]:46289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1movj9-0001Su-GZ for submit@debbugs.gnu.org; Sun, 21 Nov 2021 17:54:27 -0500 Received: from mail-108-mta145.mxroute.com ([136.175.108.145]:46497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1movj7-0001Sg-Lq for 51753@debbugs.gnu.org; Sun, 21 Nov 2021 17:54:26 -0500 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta145.mxroute.com (ZoneMTA) with ESMTPSA id 17d44b51350000177f.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sun, 21 Nov 2021 22:54:17 +0000 X-Zone-Loop: 31472274994f7f27c37b398e7619c22d31b6de333851 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=ESR1uVjdMM2m+DLxAs5YSqdzZTpz2LKsFlryZtMHK5U=; b=BWJ2oVrUfMqAwnG4eK5P/pTrRc jhCgtS/Bj/0+tEhAhr1DUoYeDZV6c7lfk7iFbCYcGv8YmT+KkiIGAWvFa3M6tjhLPyhesGIWqMYdI BH5RWDtb9eTLakhPnHyqF+HXeLXPdEgv94RIwj+CLsxUKR79Z53j4AEQbTQ1RT/RTkHc1mq3W/KBF 3NSUmYBZHArnja56VLq70eDCfLd0rDfQXOKqLtZYFAP58oAjz7kFIcCUtbOPtZxLx/y6uAhJ25T1r A4f/6tqgfQXQWevg0inwLThpS1urEqbQvyu+hSBmVjFO66us2ekCTqAH2cM0zPk1sUZ4i7vVN+MoB pG6pzdRQ==; From: "J.P." 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> Date: Sun, 21 Nov 2021 14:54:14 -0800 In-Reply-To: (Stefan Kangas's message of "Sat, 20 Nov 2021 10:09:08 +0100") Message-ID: <87sfvp5dd5.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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, HAS_ATTACHMENT=0, FROM_EQ_ENVFROM=0, MIME_TRACE=0, MIME_GOOD=-0.1, RCPT_COUNT_FIVE=0, MID_RHS_MATCH_FROM=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Stefan Kangas writes: > "J.P." writes: > >> It just occurred to me that we may also want to reset >> `erc--server-last-reconnect-count' at some point after all (re)JOINing >> is done with (both client- and server-initiated) so that the option >> `erc-join-buffer' regains precedence over `erc-reconnect-display' for >> the remainder of the connection. Doing so in `erc-cmd-JOIN' would cover >> manually issued /JOINs as well as invocations of `erc-join-channel'. > > Sounds good to me. Great. Added. Thanks. Updated tests: https://gitlab.com/jpneverwas/erc-v3/-/blob/454ef4674af3d784bb47a81db5e7d526fb30a705/test/erc-scenarios.el#L1642 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0000-v2-v3.diff >From a9c084d4dbfad1e34e23f1d2451a34beadfdc258 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Sun, 21 Nov 2021 00:40:31 -0800 Subject: NOT A PATCH F. Jason Park (1): Customize displaying of ERC buffers on reconnect lisp/erc/erc-backend.el | 3 +++ lisp/erc/erc.el | 24 ++++++++++++++++++++++-- 2 files changed, 25 insertions(+), 2 deletions(-) Interdiff: diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 01be8ed397..181da76f8e 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -3243,6 +3243,7 @@ erc-cmd-JOIN (switch-to-buffer (if (get-buffer chnl-name) chnl-name (concat chnl-name "/" server))) + (setq erc--server-last-reconnect-count 0) (erc-server-join-channel server chnl key))))) t) -- 2.31.1 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Customize-displaying-of-ERC-buffers-on-reconnect.patch >From a9c084d4dbfad1e34e23f1d2451a34beadfdc258 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Thu, 18 Nov 2021 23:39:54 -0800 Subject: [PATCH 1/1] Customize displaying of ERC buffers on reconnect * lisp/erc/erc-backend.el (erc--server-last-reconnect-count): Add variable to record last reconnect tally. * lisp/erc/erc.el (erc-reconnect-buffer): Add option to specify channel-buffer display behavior on reconnect. (erc-setup-buffer): Use option `erc-reconnect-buffer' if warranted. (erc-connection-established): Record reconnect count in internal var before resetting. (erc-cmd-JOIN): Forget last reconnect count when issuing a manual /JOIN command. --- lisp/erc/erc-backend.el | 3 +++ lisp/erc/erc.el | 24 ++++++++++++++++++++++-- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/lisp/erc/erc-backend.el b/lisp/erc/erc-backend.el index 69f63dfbc4..0d586268e9 100644 --- a/lisp/erc/erc-backend.el +++ b/lisp/erc/erc-backend.el @@ -193,6 +193,9 @@ erc-server-connected (defvar-local erc-server-reconnect-count 0 "Number of times we have failed to reconnect to the current server.") +(defvar-local erc--server-last-reconnect-count 0 + "Snapshot of reconnect count when the connection was established.") + (defvar-local erc-server-quitting nil "Non-nil if the user requests a quit.") diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index c5a4fbe5a0..181da76f8e 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1521,6 +1521,21 @@ erc-join-buffer (const :tag "Use current buffer" buffer) (const :tag "Use current buffer" t))) +(defcustom erc-reconnect-display nil + "How (and whether) to display a channel buffer upon reconnecting. + +This only affects automatic reconnections and is ignored when issuing a +/reconnect command or reinvoking `erc-tls' with the same args (assuming +success, of course). See `erc-join-buffer' for a description of +possible values." + :group 'erc-buffers + :type '(choice (const :tag "Use value of `erc-join-buffer'" nil) + (const :tag "Split window and select" window) + (const :tag "Split window, don't select" window-noselect) + (const :tag "New frame" frame) + (const :tag "Bury in new buffer" bury) + (const :tag "Use current buffer" buffer))) + (defcustom erc-frame-alist nil "Alist of frame parameters for creating erc frames. A value of nil means to use `default-frame-alist'." @@ -1950,7 +1965,10 @@ erc-update-modules (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." - (pcase erc-join-buffer + (pcase (if (zerop (erc-with-server-buffer + erc--server-last-reconnect-count)) + erc-join-buffer + (or erc-reconnect-display erc-join-buffer)) ('window (if (active-minibuffer-window) (display-buffer buffer) @@ -3225,6 +3243,7 @@ erc-cmd-JOIN (switch-to-buffer (if (get-buffer chnl-name) chnl-name (concat chnl-name "/" server))) + (setq erc--server-last-reconnect-count 0) (erc-server-join-channel server chnl key))))) t) @@ -4722,7 +4741,8 @@ erc-connection-established (nick (car (erc-response.command-args parsed))) (buffer (process-buffer proc))) (setq erc-server-connected t) - (setq erc-server-reconnect-count 0) + (setq erc--server-last-reconnect-count erc-server-reconnect-count + erc-server-reconnect-count 0) (erc-update-mode-line) (erc-set-initial-user-mode nick buffer) (erc-server-setup-periodical-ping buffer) -- 2.31.1 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Dec 2021 19:44:01 +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 To: "J.P." Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.16384741946698 (code B ref 51753); Thu, 02 Dec 2021 19:44:01 +0000 Received: (at 51753) by debbugs.gnu.org; 2 Dec 2021 19:43:14 +0000 Received: from localhost ([127.0.0.1]:49363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1msrz8-0001jy-Do for submit@debbugs.gnu.org; Thu, 02 Dec 2021 14:43:14 -0500 Received: from mail-pj1-f49.google.com ([209.85.216.49]:46842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1msrz3-0001jg-KL for 51753@debbugs.gnu.org; Thu, 02 Dec 2021 14:43:13 -0500 Received: by mail-pj1-f49.google.com with SMTP id np6-20020a17090b4c4600b001a90b011e06so585500pjb.5 for <51753@debbugs.gnu.org>; Thu, 02 Dec 2021 11:43:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=LrL76t9t96JN4QwjYgCy5CU1qB6aMOb8PH0grEJvRow=; b=m0wTNgEqmN9FiuUohDDtQ8QNlJJdS0tKYz8Bw+COA60hopUmoB6V7ioW/AbwBO6U6p i5RK3BUfKTMacbV+G5rrZocvwirNandj/6PWWY3dqeCDI/keYhqXf7cosZvAczcqvqr0 QdznflKchMz5d0EIdfCsqRuU10UznCMflHDoIgE4mNO0kiHKJP5LKf8dEsRk7w+qAcS3 ttaScQssmyRG7nAgEKiIh7mzWiuf8/dvYBwPE4l4qq13pvvhfQRf/REb+RBHxBABYB75 KpNardmEsvA4ISZaD4VHxENMJPZDCxrLoKCqe2E6eML209y6GOBZtiUuDposJsv8XdUR +Dnw== X-Gm-Message-State: AOAM530Vfy0Sf9nNsUAIwdWLNPF6q7PXJh9p6EWjP0Ejjk8rriagJh8B LnJSRKYxpAqYz9UGBh5q+Hu1LCUc/tJw4mqKK1k= X-Google-Smtp-Source: ABdhPJwhRVYpS7vup4Z1JEiUWgaF/X8fy+YTCJZKMrQhyt0ng7PW/kfDiRP1wOSumG4hbKa9xZEnD5fpu9oCNkp++10= X-Received: by 2002:a17:90a:be10:: with SMTP id a16mr8143153pjs.133.1638474183874; Thu, 02 Dec 2021 11:43:03 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 2 Dec 2021 11:43:03 -0800 From: Stefan Kangas In-Reply-To: <87sfvp5dd5.fsf@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 Date: Thu, 2 Dec 2021 11:43:03 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) "J.P." writes: > Great. Added. Thanks. Amin, what do you think of this patch? From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect 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 To: Stefan Kangas Cc: Lars Ingebrigtsen , emacs-erc@gnu.org, Amin Bandali , 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163850950032470 (code B ref 51753); Fri, 03 Dec 2021 05:32:02 +0000 Received: (at 51753) by debbugs.gnu.org; 3 Dec 2021 05:31:40 +0000 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 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 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==; From: "J.P." 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> Date: Thu, 02 Dec 2021 21:31:24 -0800 In-Reply-To: (Stefan Kangas's message of "Thu, 2 Dec 2021 11:43:03 -0800") Message-ID: <87zgpicl03.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri May 20 11:57:25 2022 Received: (at control) by debbugs.gnu.org; 20 May 2022 15:57:26 +0000 Received: from localhost ([127.0.0.1]:39946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ns50H-0004vc-Pe for submit@debbugs.gnu.org; Fri, 20 May 2022 11:57:25 -0400 Received: from mail-pl1-f173.google.com ([209.85.214.173]:38588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ns50F-0004vN-8C for control@debbugs.gnu.org; Fri, 20 May 2022 11:57:24 -0400 Received: by mail-pl1-f173.google.com with SMTP id n18so7716193plg.5 for ; Fri, 20 May 2022 08:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeisgreat-org.20210112.gappssmtp.com; s=20210112; h=from:to:subject:date:message-id:mime-version; bh=B5djrfwJsmPxxyJ90XfyQMzf5WmbEPTKOmFmI6Icm14=; b=EMPKxrAfAeDFLAVybE8bHIKtzpyxqG3rcsH7xUuca+v56D1/DcZgugHa8aGi6pUZ6p 5qNA11HmkfJGlvyA17b0tk4lSZbNF3erZTpU4kCZ7hc5A++W/JBwZx4nxoaPuE3xCqKR sME6aaoPcxCd6tH8+yaTOAF8x7AGMal8cmY8jiMOTMh1CqV6qrPGAT6WcO7xFMJ2gaca Ega1DdzLhHX3QoZJ7iQmoP5VDgHXR8J4lo3mjzwEFuwBqG9P56hJbZTaNbXB6l8WK7g4 8sWkv3toZlNkyKm0JJ506ZLhHxvNS0yFx97c3W5djdbOrChoOi/d9Ipirewu9HNKgWn+ BbBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=B5djrfwJsmPxxyJ90XfyQMzf5WmbEPTKOmFmI6Icm14=; b=mBQV9lTak/XMUffkZFOtn7QF7SpzuYIRpJJuwCtoHei/gBWbmFpBMbFEAhQL7gi0RG 1UudSnSNNzIP6ouVqGK/ENhRkj47BURPWkWfpgEz8WAZs/z4or8uhaOBrWl7hiImadrr LjdqMQMdEXEvGGbimQBe7UIhIpta0OmiyiozdW8FYrxR+rToHnyTw0FkpYZQiR1L50K8 +2jxYTlTrYhIBUDHk7nZQStcTR/F+wTm2IdzhG88c6aAdejpqFyIIkyd+a5fBRouCWlv emPH3C0CL7Vd7Da9CCnDhp9x+caKSuHA6WDyYRAB37o2lFDps9RFpqDnQBH1gKkfeZkG sYuw== X-Gm-Message-State: AOAM533UB3wBLETWHsVxf2XpkZyRd8qMHmQD171mcX/GMcKmMyDMV3dI gwsXcaon+DrVyqk/F70HL6W0mNcWmBj15w== X-Google-Smtp-Source: ABdhPJzbfncm4SNHCNN7hH1GLujNivues3DbnrdDj4Dn7sHJK/s2yFWqZ98+1bhtfRtKW28NizY80w== X-Received: by 2002:a17:902:f784:b0:161:e9f7:2b0b with SMTP id q4-20020a170902f78400b00161e9f72b0bmr6024837pln.9.1653062237201; Fri, 20 May 2022 08:57:17 -0700 (PDT) Received: from anant ([49.36.236.57]) by smtp.gmail.com with ESMTPSA id y18-20020a626412000000b0050dc762819fsm1974825pfb.121.2022.05.20.08.57.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 May 2022 08:57:16 -0700 (PDT) From: Pankaj Jangid To: control@debbugs.gnu.org Subject: control message for bug #51753 Date: Fri, 20 May 2022 21:27:14 +0530 Message-ID: <87pmk8i4dh.fsf@codeisgreat.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) forcemerge 51753 55540 quit From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 May 2022 01:57: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 To: Pankaj Jangid Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.165327097919956 (code B ref 51753); Mon, 23 May 2022 01:57:02 +0000 Received: (at 51753) by debbugs.gnu.org; 23 May 2022 01:56:19 +0000 Received: from localhost ([127.0.0.1]:46756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsxIx-0005Bn-2B for submit@debbugs.gnu.org; Sun, 22 May 2022 21:56:19 -0400 Received: from mail-108-mta27.mxroute.com ([136.175.108.27]:38323) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsxIu-0005BZ-Gh for 51753@debbugs.gnu.org; Sun, 22 May 2022 21:56:17 -0400 Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta27.mxroute.com (ZoneMTA) with ESMTPSA id 180eea10095000c327.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 23 May 2022 01:56:10 +0000 X-Zone-Loop: 0a917dc88435fe3fbfd4eeb97bbd1fd5c0d5b4c66c61 X-Originating-IP: [140.82.40.27] 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=XYMb77mCsm4RjmBjtXFfJXuTP6AFRrdIcMnahtbe/YI=; b=ebognFYFTBwzvxJ4zJB1PNCiVV Psq84E/sxhh8I2QHoR9WiVIp18svSAD+POO4+43FdFRw6XRCXvG8Y7X4pfHIs4SsLjspuOzW8l0yo HRG2g68PvNNaOKh/7weSNXazQjVTVoCaIbKNf4MKVpYuNSDXKDEsk+ZHG9Qe3FGJ/nspjUkT5Gkvv HMkTau/ysrgxS8fDHszyPjPAQAFiUSgzc4Jy0tOSBasCyddu3JltRuyO/pRcR795BPZB59TiRdaLj oWvR4j2t4HHrOgk2XwErQ4l/Q20+5wiAfTuj1TNn7gHdSlt+BP7kl/JPREcAAFtmJu6tXWstFeaVZ EGIRVSOw==; From: "J.P." References: <878rqwjqua.fsf@codeisgreat.org> Date: Sun, 22 May 2022 18:56:07 -0700 In-Reply-To: <878rqwjqua.fsf@codeisgreat.org> (Pankaj Jangid's message of "Fri, 20 May 2022 18:36:37 +0530") Message-ID: <87a6b92ers.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-AuthUser: masked@neverwas.me X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hi Pankaj, Pankaj Jangid writes: > 5. While it is connecting to the server, switch to the other frame to > work on other stuff > > Result: After the ERC connects to the server, it opens the autojoin > channels in the current frame. Ideally, it should open the channels in > the (dedicated) original frame where ERC was launched. Are you saying ERC ought to remember the frame in which an entry-point command, like `erc-tls', was originally invoked? Or might it be enough to make a best effort attempt at finding such a "dedicated" frame? If it's door #2, what if we used the first frame found containing a buffer belonging to the same connection (and if no such frame exists, just leave it up to the display-buffer gods)? This way, we could rely more fully on window.el facilities and avoid having to wrangle yet more state. Or, if really necessary, we could maybe fall back on a strategy that uses `window-prev-buffers' (or whatever) to find the most recently used frame for that connection (overkill, IMO). Either way, any solution would need to address not just autojoined channels but also server-initiated JOINs, PMs, etc. The attached patch claims to do something like I've described. If you're able to try it, please set these options beforehand: (setq erc-join-buffer 'frame erc-auto-query 'frame erc-query-display 'frame erc-reuse-frames 'displayed) If you're unable to try it, please let me know, and I can maybe add it temporarily to one of ERC's installable bug packages. Thanks, J.P. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Allow-erc-reuse-frames-to-favor-connections.patch >From be5ec788ea9fa4375b7d0c96b7d646796daf56d0 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Sat, 21 May 2022 00:04:04 -0700 Subject: [PATCH] Allow erc-reuse-frames to favor connections * lisp/erc/erc.el (erc-reuse-frames): Add alternate value to favor existing frames already displaying other buffers from the same connection. (erc-setup-buffer): Add case for "displayed" variant of `erc-reuse-frames'. --- lisp/erc/erc.el | 39 ++++++++++--- test/lisp/erc/erc-tests.el | 115 +++++++++++++++++++++++++++++++++++++ 2 files changed, 146 insertions(+), 8 deletions(-) diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index ff482d4933..f82fb07a66 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1536,12 +1536,17 @@ erc-frame-dedicated-flag :type 'boolean) (defcustom erc-reuse-frames t - "Determines whether new frames are always created. -Non-nil means that a new frame is not created to display an ERC -buffer if there is already a window displaying it. This only has -effect when `erc-join-buffer' is set to `frame'." + "Non-nil means only create a frame for undisplayed buffers. +For new target buffers, a value of 'displayed' extends this to mean use +the frame of any buffer from the same server connection, visible or not. +When this option is nil, a new frame is always created. Regardless of +its value, this option is ignored unless `erc-join-buffer' is set to +`frame'. Note that like most options in the `erc-buffer' customize +group, this has no effect on server buffers while reconnecting." + :package-version '(ERC . "5.4.1") ; FIXME update when publishing to ELPA :group 'erc-buffers - :type 'boolean) + :type '(choice boolean + (const displayed))) (defun erc-channel-p (channel) "Return non-nil if CHANNEL seems to be an IRC channel name." @@ -1943,6 +1948,19 @@ erc-update-modules (funcall sym 1) (error "`%s' is not a known ERC module" mod)))))) +(defun erc--setup-buffer-frame-displayed (buffer) + "Maybe display BUFFER in an existing frame for the same connection. +If performed, return window used; otherwise, return nil." + (when-let* + ((bs (erc-buffer-list nil erc-server-process)) + (visit (lambda (w) (when (memq (window-buffer w) bs) (throw 'found t)))) + (test (lambda (fr) (catch 'found (walk-windows visit 0 fr)))) + ((or (cdr (frame-list)) (funcall test (selected-frame))))) + (display-buffer buffer `((display-buffer-use-some-frame) + (inhibit-switch-frame . t) + (inhibit-same-window . t) + (frame-predicate . ,test))))) + (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." (pcase erc-join-buffer @@ -1955,15 +1973,20 @@ erc-setup-buffer ('bury nil) ('frame - (when (or (not erc-reuse-frames) - (not (get-buffer-window buffer t))) + (cond + ((and (eq erc-reuse-frames 'displayed) + erc-default-recipients ; change this to `erc--target' after bug#48598 + (not (get-buffer-window buffer t)) + (erc--setup-buffer-frame-displayed buffer))) + ((or (not erc-reuse-frames) + (not (get-buffer-window buffer t))) (let ((frame (make-frame (or erc-frame-alist default-frame-alist)))) (raise-frame frame) (select-frame frame)) (switch-to-buffer buffer) (when erc-frame-dedicated-flag - (set-window-dedicated-p (selected-window) t)))) + (set-window-dedicated-p (selected-window) t))))) (_ (if (active-minibuffer-window) (display-buffer buffer) diff --git a/test/lisp/erc/erc-tests.el b/test/lisp/erc/erc-tests.el index 520f10dd4e..1eac6b22c9 100644 --- a/test/lisp/erc/erc-tests.el +++ b/test/lisp/erc/erc-tests.el @@ -171,6 +171,121 @@ erc--switch-to-buffer (dolist (b '("server" "other" "#chan" "#foo" "#fake")) (kill-buffer b)))) +(ert-deftest erc-reuse-frames () + ;; TODO run this in a pseudo terminal subprocess for EMBA + (skip-unless (not noninteractive)) + (should-not erc-frame-dedicated-flag) + (let ((erc-join-buffer 'frame) + (erc-reuse-frames t) + (orig-frame (selected-frame)) + erc-kill-channel-hook erc-kill-server-hook erc-kill-buffer-hook) + + (ert-info ("Value: t") + (with-current-buffer (generate-new-buffer "server") + (erc-mode) + (setq erc-server-process (start-process "server" (current-buffer) + "sleep" "1") + erc-frame-alist (cons '(name . "server") default-frame-alist)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; New frame created and raised + (should (equal "server" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)) + + (with-current-buffer (generate-new-buffer "#chan") + (erc-mode) + (setq erc-server-process erc-server-process + erc-frame-alist (cons '(name . "#chan") default-frame-alist) + erc-default-recipients '("#chan")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Another frame was created just for #chan + (should (equal "#chan" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)) + (delete-frame)) + + (select-frame-by-name "server") + (pop-to-buffer "#chan") + ;; The server frame contains two vertical windows + (let ((tree (window-tree))) + (should (memq (get-buffer-window "server" t) (car tree))) + (should (memq (get-buffer-window "#chan" t) (car tree)))) + (should (eq (get-buffer "#chan") (window-buffer (selected-window)))) + (should (eq (get-buffer "server") (window-buffer (next-window)))))) + + (ert-info ("Value: displayed, scratch frame selected") + (select-frame orig-frame) + (with-current-buffer "*scratch*" + (with-current-buffer (generate-new-buffer "#spam") + (erc-mode) + (setq erc-server-process (buffer-local-value 'erc-server-process + (get-buffer "server")) + erc-reuse-frames 'displayed + erc-frame-alist (cons '(name . "#spam") default-frame-alist) + erc-default-recipients '("#spam")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window shows up in other frame + (should (eq (selected-frame) orig-frame)) + (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) + (should (equal "server" (frame-parameter fr 'name))) + (with-selected-frame fr + (should (memq (get-buffer-window "#spam" t) + (car (window-tree)))))))) + + (with-current-buffer "server" + (ert-info ("Value: displayed, server frame selected") + (select-frame-by-name "server") + (select-window (get-buffer-window "#spam")) + (with-current-buffer (generate-new-buffer "bob") + (erc-mode) + (setq erc-server-process (buffer-local-value 'erc-server-process + (get-buffer "server")) + erc-frame-alist (cons '(name . "bob") default-frame-alist) + erc-default-recipients '("bob")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window shows up in this frame + (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) + (should (eq fr (selected-frame))) + (should (equal "server" (frame-parameter fr 'name))) + (with-selected-frame fr + (should (memq (get-buffer-window "bob" t) + (car (window-tree))))) + ;; `inhibit-same-window' respected + (should-not (eq (get-buffer-window "bob") (selected-window)))))) + + (ert-info ("Value: displayed, other frames deleted") + (with-selected-frame orig-frame + (delete-frame)) + (should-not (cdr (frame-list))) + (select-window (get-buffer-window "bob")) + (with-current-buffer (generate-new-buffer "alice") + (erc-mode) + (setq erc-server-process (buffer-local-value 'erc-server-process + (get-buffer "server")) + erc-frame-alist (cons '(name . "alice") default-frame-alist) + erc-default-recipients '("alice")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) + (should (eq fr (selected-frame))) + (should (equal "server" (frame-parameter fr 'name))) + (with-selected-frame fr + (should (memq (get-buffer-window "alice" t) + (car (window-tree))))) + (should-not (eq (get-buffer-window "alice") + (selected-window))))))))) + + (should-not (cdr (frame-list))) + (delete-other-windows) + (kill-buffer "server") + (kill-buffer "bob") + (kill-buffer "alice") + (kill-buffer "#spam") + (kill-buffer "#chan")) + (ert-deftest erc-lurker-maybe-trim () (let (erc-lurker-trim-nicks (erc-lurker-ignore-chars "_`")) -- 2.36.1 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: Pankaj Jangid Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 May 2022 02:51:01 +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 To: "J.P." Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.165327424425387 (code B ref 51753); Mon, 23 May 2022 02:51:01 +0000 Received: (at 51753) by debbugs.gnu.org; 23 May 2022 02:50:44 +0000 Received: from localhost ([127.0.0.1]:46779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsy9c-0006bP-Fy for submit@debbugs.gnu.org; Sun, 22 May 2022 22:50:44 -0400 Received: from mail-pj1-f42.google.com ([209.85.216.42]:42734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsy9Z-0006bA-9F for 51753@debbugs.gnu.org; Sun, 22 May 2022 22:50:43 -0400 Received: by mail-pj1-f42.google.com with SMTP id a23-20020a17090acb9700b001df4e9f4870so12418831pju.1 for <51753@debbugs.gnu.org>; Sun, 22 May 2022 19:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeisgreat-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:references:mail-followup-to:date:in-reply-to :message-id:user-agent:mime-version; bh=fT8LXlYVwx4yDK2HuLQWMZu4SxpFr+Be5IOsez1DiFs=; b=spV/32+/YdPPAJ/K7UsWeIJYm922clxWc30/c7HqfZQiDa7vg6Zbr3CT8POiF7/6+U uyQmDq6QPTTn535NkAW51DgBTc6uNjfSSQe11MHHvDXg5j0zdo3e0+0KNVltVps5JzpU DAEHWgaWN1tDnkRqgoMYhbN9gHYHpogGkN//RR/tRn+dzf4eMZg3ifSNUPEAsU+bwLaA uVyF4T3whfM4wMeccN9yaKD8XhaQNq4M1nXSrlGr778idaAnATT1mKanH9UNPMjZAWKJ woaiykmoGH+AKI7GBbIXiqV+nTkzeF6n5S/J+WnOpE9GXxRvzeDwcmTPJ06npsPbGyhD VPkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:mail-followup-to :date:in-reply-to:message-id:user-agent:mime-version; bh=fT8LXlYVwx4yDK2HuLQWMZu4SxpFr+Be5IOsez1DiFs=; b=wflc0JHbkKYekF1sMKYLLfHFOTkEovxH1vDc9mm4God5VBvf8Vm/1CQ2SWje8JprbT lm2VDEfsX+cRgSNllV9CttHQ2yAyMjGwW2pMOjklhbFXBnxGWLOBa3fbSTUdfc0b9LHv BS3vBOttxpxXTWaXpOYyhVCE+eVQjs/v1OFbjsFlicdOV4KPsflV3wSPARYfM/p69Gwc 9ba22vJ7F4iwJX+Sc1Red+hWU7mQ+5gjh0g8s66FxgFLCTsR+z93OaIlEIJPcgUdBpjd tEUFiFssvEuGYwUuv8jtVZyyIKeHWCjcLqoxQ/vaq8wBXMRKSBSdtjPBDxFEDqJm4wV1 PSbQ== X-Gm-Message-State: AOAM532B3PraIdEbbNtcnr1upXNOWMSZwC7icwsKEXtPkMjCGyJLzJ/7 wG550G+1FGIwQdhylpwfclqqWA== X-Google-Smtp-Source: ABdhPJzDmaYput0+2I/O1kU2zs3mEXvQqpCWyb5EXW087B44bECugknyBhMF2ujhWwRBgLYQnHpzGw== X-Received: by 2002:a17:902:c412:b0:161:af8b:f478 with SMTP id k18-20020a170902c41200b00161af8bf478mr21092064plk.67.1653274235293; Sun, 22 May 2022 19:50:35 -0700 (PDT) Received: from anant ([49.36.236.57]) by smtp.gmail.com with ESMTPSA id i5-20020a170902eb4500b0015e8d4eb248sm858872pli.146.2022.05.22.19.50.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 May 2022 19:50:34 -0700 (PDT) From: Pankaj Jangid References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> Mail-Followup-To: "J.P." , 51753@debbugs.gnu.org, emacs-erc@gnu.org Date: Mon, 23 May 2022 08:20:32 +0530 In-Reply-To: <87a6b92ers.fsf@neverwas.me> (J. P.'s message of "Sun, 22 May 2022 18:56:07 -0700") Message-ID: <875ylxm07b.fsf@codeisgreat.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) "J.P." writes: > Are you saying ERC ought to remember the frame in which an entry-point > command, like `erc-tls', was originally invoked? Or might it be enough > to make a best effort attempt at finding such a "dedicated" frame? I have tried the #2 as specified below. I kind of agree that #1 will result in the desired behaviour. > If it's door #2, what if we used the first frame found containing a > buffer belonging to the same connection (and if no such frame exists, > just leave it up to the display-buffer gods)? This way, we could rely > more fully on window.el facilities and avoid having to wrangle yet more > state. Or, if really necessary, we could maybe fall back on a strategy > that uses `window-prev-buffers' (or whatever) to find the most recently > used frame for that connection (overkill, IMO). Either way, any solution > would need to address not just autojoined channels but also > server-initiated JOINs, PMs, etc. > > The attached patch claims to do something like I've described. If you're > able to try it, please set these options beforehand: > > (setq erc-join-buffer 'frame > erc-auto-query 'frame > erc-query-display 'frame > erc-reuse-frames 'displayed) > > If you're unable to try it, please let me know, and I can maybe add it > temporarily to one of ERC's installable bug packages. I tried this and here is what is happening. I launched emacs then I launched another frame and M-x erc-tls and come back to the 1st frame for other work. "erc-tls" running fine in the other frame but when it starts to join autojoin channels after connecting, it creates one more frame for each channel instead of reusing the 2nd frame. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: ERC switches to channel buffer on reconnect Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 May 2022 07:50: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 To: 51753@debbugs.gnu.org Cc: emacs-erc@gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.16532921559685 (code B ref 51753); Mon, 23 May 2022 07:50:02 +0000 Received: (at 51753) by debbugs.gnu.org; 23 May 2022 07:49:15 +0000 Received: from localhost ([127.0.0.1]:47188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nt2oU-0002W8-Ek for submit@debbugs.gnu.org; Mon, 23 May 2022 03:49:15 -0400 Received: from mail-108-mta169.mxroute.com ([136.175.108.169]:38791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nt2oS-0002Vq-4S for 51753@debbugs.gnu.org; Mon, 23 May 2022 03:49:13 -0400 Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta169.mxroute.com (ZoneMTA) with ESMTPSA id 180efe409cd000c327.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 23 May 2022 07:49:01 +0000 X-Zone-Loop: 17aff427bfd381026be68b2db7e8941a02350bff10eb X-Originating-IP: [140.82.40.27] 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=Rd12fv+wInqTgqP80gGA7TaFH3gDhMrfQFF65Kiwd2Y=; b=KP70VvZP8UWPb9DG/ivxVEDvC7 WtQSebAll7ZS/0icuGTLguRiRRORzrpPTKMabP2/pZlcGZ1w8qI4zeSrCzxfx/puPgV/A1v3I0Sfd QJvo0BoYYEi2cX+YwwyiD56Kjglqpv77vmACfVK36l0jITMGQ+lOw6Qk9P+3R7bHRNxukWV7HZDNL AhgDgigVeD95qzZag2bEIitiiHki3EMVfHqvskSMCMLZevnqviQqTXA/5NsM6w8dgExtzPGye1+iC H1yGlnQ0cc2qN6a+HpnjCplDLifn0dBC4Whn6DBGXPk6RxwOBCZXhY6oUlir02ZFig9XC0VLW1W7y tXXAfhWA==; From: "J.P." References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> Date: Mon, 23 May 2022 00:48:57 -0700 In-Reply-To: <875ylxm07b.fsf@codeisgreat.org> (Pankaj Jangid's message of "Mon, 23 May 2022 08:20:32 +0530") Message-ID: <87fsl0zo2e.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-AuthUser: masked@neverwas.me X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Pankaj Jangid writes: > "J.P." writes: > >> Are you saying ERC ought to remember the frame in which an entry-point >> command, like `erc-tls', was originally invoked? Or might it be enough >> to make a best effort attempt at finding such a "dedicated" frame? > > I have tried the #2 as specified below. I kind of agree that #1 will > result in the desired behaviour. Thanks for trying out that patch. Basically, I bungled a few things that prevented it from faithfully representing #2, even though I claimed otherwise (sorry). IOW, I'm saying the approach may be salvageable and only the implementation flawed. > I tried this and here is what is happening. > > I launched emacs then I launched another frame and M-x erc-tls and come > back to the 1st frame for other work. "erc-tls" running fine in the > other frame but when it starts to join autojoin channels after > connecting, it creates one more frame for each channel instead of > reusing the 2nd frame. Right, it seems I blindly fixated on the segregation aspect of your description (again, apologies) and glossed over the obvious fact that you don't want ERC creating frames, period. I've adapted the existing patch with this in mind in hopes you're willing to try again. One thing to be aware of is that even if we pivot to #1, the connection-detection and buffer-association stuff will still be unreliable in many cases. However, that should change after bug#48598 lands. That said, if you still feel strongly about #1, then please say so (others following along as well). And likewise if you have suggestions on the implementation or would like to try taking the wheel. Thanks. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0000-v1-v2.diff >From 7155fbd9f4afe9c9fd9dd2c89e28830a9d6612d7 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Mon, 23 May 2022 00:15:18 -0700 Subject: [PATCH 0/1] *** NOT A PATCH *** *** BLURB HERE *** F. Jason Park (1): Allow erc-reuse-frames to favor connections lisp/erc/erc.el | 52 +++++++++++++--- test/lisp/erc/erc-tests.el | 119 +++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+), 8 deletions(-) Interdiff: diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index f82fb07a66..13ac0ec979 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1538,11 +1538,12 @@ erc-frame-dedicated-flag (defcustom erc-reuse-frames t "Non-nil means only create a frame for undisplayed buffers. For new target buffers, a value of 'displayed' extends this to mean use -the frame of any buffer from the same server connection, visible or not. -When this option is nil, a new frame is always created. Regardless of -its value, this option is ignored unless `erc-join-buffer' is set to -`frame'. Note that like most options in the `erc-buffer' customize -group, this has no effect on server buffers while reconnecting." +the frame of any buffer from the same server connection, visible or not, +or, as a last resort, a frame showing any ERC buffer. When this option +is nil, a new frame is always created. Regardless of its value, this +option is ignored unless `erc-join-buffer' is set to `frame'. Note that +like most options in the `erc-buffer' customize group, this has no +effect on server buffers while reconnecting." :package-version '(ERC . "5.4.1") ; FIXME update when publishing to ELPA :group 'erc-buffers :type '(choice boolean @@ -1948,18 +1949,30 @@ erc-update-modules (funcall sym 1) (error "`%s' is not a known ERC module" mod)))))) -(defun erc--setup-buffer-frame-displayed (buffer) +(defun erc--setup-buffer-first-win (frame a b) + (catch 'found + (walk-window-tree + (lambda (w) + (when (eq (buffer-local-value a (window-buffer w)) b) + (throw 'found t))) + frame nil 0))) + +(defun erc--display-buffer-use-some-frame (buffer alist) "Maybe display BUFFER in an existing frame for the same connection. -If performed, return window used; otherwise, return nil." +If performed, return window used; otherwise, return nil. Forward ALIST +to display-buffer machinery." (when-let* - ((bs (erc-buffer-list nil erc-server-process)) - (visit (lambda (w) (when (memq (window-buffer w) bs) (throw 'found t)))) - (test (lambda (fr) (catch 'found (walk-windows visit 0 fr)))) - ((or (cdr (frame-list)) (funcall test (selected-frame))))) - (display-buffer buffer `((display-buffer-use-some-frame) - (inhibit-switch-frame . t) - (inhibit-same-window . t) - (frame-predicate . ,test))))) + ((same-proc-p (lambda (fr) + (erc--setup-buffer-first-win fr 'erc-server-process + erc-server-process))) + (same-mode-p (lambda (fr) + (erc--setup-buffer-first-win fr 'major-mode 'erc-mode))) + ((or (cdr (frame-list)) (funcall same-mode-p (selected-frame)))) + (frame (car (or (filtered-frame-list same-proc-p) + (filtered-frame-list same-mode-p)))) + (window (get-lru-window frame nil t))) + ;; FIXME don't rely on internal window.el function (tab-bar also does it) + (window--display-buffer buffer window 'reuse alist))) (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." @@ -1975,9 +1988,9 @@ erc-setup-buffer ('frame (cond ((and (eq erc-reuse-frames 'displayed) - erc-default-recipients ; change this to `erc--target' after bug#48598 - (not (get-buffer-window buffer t)) - (erc--setup-buffer-frame-displayed buffer))) + (not (get-buffer-window buffer t))) + (display-buffer buffer `((erc--display-buffer-use-some-frame) + (inhibit-same-window . t)))) ((or (not erc-reuse-frames) (not (get-buffer-window buffer t))) (let ((frame (make-frame (or erc-frame-alist diff --git a/test/lisp/erc/erc-tests.el b/test/lisp/erc/erc-tests.el index 1eac6b22c9..686db3bb2e 100644 --- a/test/lisp/erc/erc-tests.el +++ b/test/lisp/erc/erc-tests.el @@ -173,6 +173,10 @@ erc--switch-to-buffer (ert-deftest erc-reuse-frames () ;; TODO run this in a pseudo terminal subprocess for EMBA + ;; + ;; TODO case that simulates automatic reconnecting, with an + ;; existing, unselected frame containing two windows, one with a + ;; dead ERC buffer and the other a non-ERC buffer (skip-unless (not noninteractive)) (should-not erc-frame-dedicated-flag) (let ((erc-join-buffer 'frame) -- 2.36.1 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Allow-erc-reuse-frames-to-favor-connections.patch >From 7155fbd9f4afe9c9fd9dd2c89e28830a9d6612d7 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Sat, 21 May 2022 00:04:04 -0700 Subject: [PATCH 1/1] Allow erc-reuse-frames to favor connections * lisp/erc/erc.el (erc-reuse-frames): Add alternate value to favor existing frames already displaying other buffers from the same connection. (erc-setup-buffer): Add case for "displayed" variant of `erc-reuse-frames'. --- lisp/erc/erc.el | 52 +++++++++++++--- test/lisp/erc/erc-tests.el | 119 +++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+), 8 deletions(-) diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index ff482d4933..13ac0ec979 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1536,12 +1536,18 @@ erc-frame-dedicated-flag :type 'boolean) (defcustom erc-reuse-frames t - "Determines whether new frames are always created. -Non-nil means that a new frame is not created to display an ERC -buffer if there is already a window displaying it. This only has -effect when `erc-join-buffer' is set to `frame'." + "Non-nil means only create a frame for undisplayed buffers. +For new target buffers, a value of 'displayed' extends this to mean use +the frame of any buffer from the same server connection, visible or not, +or, as a last resort, a frame showing any ERC buffer. When this option +is nil, a new frame is always created. Regardless of its value, this +option is ignored unless `erc-join-buffer' is set to `frame'. Note that +like most options in the `erc-buffer' customize group, this has no +effect on server buffers while reconnecting." + :package-version '(ERC . "5.4.1") ; FIXME update when publishing to ELPA :group 'erc-buffers - :type 'boolean) + :type '(choice boolean + (const displayed))) (defun erc-channel-p (channel) "Return non-nil if CHANNEL seems to be an IRC channel name." @@ -1943,6 +1949,31 @@ erc-update-modules (funcall sym 1) (error "`%s' is not a known ERC module" mod)))))) +(defun erc--setup-buffer-first-win (frame a b) + (catch 'found + (walk-window-tree + (lambda (w) + (when (eq (buffer-local-value a (window-buffer w)) b) + (throw 'found t))) + frame nil 0))) + +(defun erc--display-buffer-use-some-frame (buffer alist) + "Maybe display BUFFER in an existing frame for the same connection. +If performed, return window used; otherwise, return nil. Forward ALIST +to display-buffer machinery." + (when-let* + ((same-proc-p (lambda (fr) + (erc--setup-buffer-first-win fr 'erc-server-process + erc-server-process))) + (same-mode-p (lambda (fr) + (erc--setup-buffer-first-win fr 'major-mode 'erc-mode))) + ((or (cdr (frame-list)) (funcall same-mode-p (selected-frame)))) + (frame (car (or (filtered-frame-list same-proc-p) + (filtered-frame-list same-mode-p)))) + (window (get-lru-window frame nil t))) + ;; FIXME don't rely on internal window.el function (tab-bar also does it) + (window--display-buffer buffer window 'reuse alist))) + (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." (pcase erc-join-buffer @@ -1955,15 +1986,20 @@ erc-setup-buffer ('bury nil) ('frame - (when (or (not erc-reuse-frames) - (not (get-buffer-window buffer t))) + (cond + ((and (eq erc-reuse-frames 'displayed) + (not (get-buffer-window buffer t))) + (display-buffer buffer `((erc--display-buffer-use-some-frame) + (inhibit-same-window . t)))) + ((or (not erc-reuse-frames) + (not (get-buffer-window buffer t))) (let ((frame (make-frame (or erc-frame-alist default-frame-alist)))) (raise-frame frame) (select-frame frame)) (switch-to-buffer buffer) (when erc-frame-dedicated-flag - (set-window-dedicated-p (selected-window) t)))) + (set-window-dedicated-p (selected-window) t))))) (_ (if (active-minibuffer-window) (display-buffer buffer) diff --git a/test/lisp/erc/erc-tests.el b/test/lisp/erc/erc-tests.el index 520f10dd4e..686db3bb2e 100644 --- a/test/lisp/erc/erc-tests.el +++ b/test/lisp/erc/erc-tests.el @@ -171,6 +171,125 @@ erc--switch-to-buffer (dolist (b '("server" "other" "#chan" "#foo" "#fake")) (kill-buffer b)))) +(ert-deftest erc-reuse-frames () + ;; TODO run this in a pseudo terminal subprocess for EMBA + ;; + ;; TODO case that simulates automatic reconnecting, with an + ;; existing, unselected frame containing two windows, one with a + ;; dead ERC buffer and the other a non-ERC buffer + (skip-unless (not noninteractive)) + (should-not erc-frame-dedicated-flag) + (let ((erc-join-buffer 'frame) + (erc-reuse-frames t) + (orig-frame (selected-frame)) + erc-kill-channel-hook erc-kill-server-hook erc-kill-buffer-hook) + + (ert-info ("Value: t") + (with-current-buffer (generate-new-buffer "server") + (erc-mode) + (setq erc-server-process (start-process "server" (current-buffer) + "sleep" "1") + erc-frame-alist (cons '(name . "server") default-frame-alist)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; New frame created and raised + (should (equal "server" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)) + + (with-current-buffer (generate-new-buffer "#chan") + (erc-mode) + (setq erc-server-process erc-server-process + erc-frame-alist (cons '(name . "#chan") default-frame-alist) + erc-default-recipients '("#chan")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Another frame was created just for #chan + (should (equal "#chan" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)) + (delete-frame)) + + (select-frame-by-name "server") + (pop-to-buffer "#chan") + ;; The server frame contains two vertical windows + (let ((tree (window-tree))) + (should (memq (get-buffer-window "server" t) (car tree))) + (should (memq (get-buffer-window "#chan" t) (car tree)))) + (should (eq (get-buffer "#chan") (window-buffer (selected-window)))) + (should (eq (get-buffer "server") (window-buffer (next-window)))))) + + (ert-info ("Value: displayed, scratch frame selected") + (select-frame orig-frame) + (with-current-buffer "*scratch*" + (with-current-buffer (generate-new-buffer "#spam") + (erc-mode) + (setq erc-server-process (buffer-local-value 'erc-server-process + (get-buffer "server")) + erc-reuse-frames 'displayed + erc-frame-alist (cons '(name . "#spam") default-frame-alist) + erc-default-recipients '("#spam")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window shows up in other frame + (should (eq (selected-frame) orig-frame)) + (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) + (should (equal "server" (frame-parameter fr 'name))) + (with-selected-frame fr + (should (memq (get-buffer-window "#spam" t) + (car (window-tree)))))))) + + (with-current-buffer "server" + (ert-info ("Value: displayed, server frame selected") + (select-frame-by-name "server") + (select-window (get-buffer-window "#spam")) + (with-current-buffer (generate-new-buffer "bob") + (erc-mode) + (setq erc-server-process (buffer-local-value 'erc-server-process + (get-buffer "server")) + erc-frame-alist (cons '(name . "bob") default-frame-alist) + erc-default-recipients '("bob")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window shows up in this frame + (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) + (should (eq fr (selected-frame))) + (should (equal "server" (frame-parameter fr 'name))) + (with-selected-frame fr + (should (memq (get-buffer-window "bob" t) + (car (window-tree))))) + ;; `inhibit-same-window' respected + (should-not (eq (get-buffer-window "bob") (selected-window)))))) + + (ert-info ("Value: displayed, other frames deleted") + (with-selected-frame orig-frame + (delete-frame)) + (should-not (cdr (frame-list))) + (select-window (get-buffer-window "bob")) + (with-current-buffer (generate-new-buffer "alice") + (erc-mode) + (setq erc-server-process (buffer-local-value 'erc-server-process + (get-buffer "server")) + erc-frame-alist (cons '(name . "alice") default-frame-alist) + erc-default-recipients '("alice")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) + (should (eq fr (selected-frame))) + (should (equal "server" (frame-parameter fr 'name))) + (with-selected-frame fr + (should (memq (get-buffer-window "alice" t) + (car (window-tree))))) + (should-not (eq (get-buffer-window "alice") + (selected-window))))))))) + + (should-not (cdr (frame-list))) + (delete-other-windows) + (kill-buffer "server") + (kill-buffer "bob") + (kill-buffer "alice") + (kill-buffer "#spam") + (kill-buffer "#chan")) + (ert-deftest erc-lurker-maybe-trim () (let (erc-lurker-trim-nicks (erc-lurker-ignore-chars "_`")) -- 2.36.1 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Aug 2022 13:17:01 +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 To: Pankaj Jangid Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166013737111597 (code B ref 51753); Wed, 10 Aug 2022 13:17:01 +0000 Received: (at 51753) by debbugs.gnu.org; 10 Aug 2022 13:16:11 +0000 Received: from localhost ([127.0.0.1]:46892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLlZB-00030x-M1 for submit@debbugs.gnu.org; Wed, 10 Aug 2022 09:16:11 -0400 Received: from mail-108-mta247.mxroute.com ([136.175.108.247]:42897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLlZ7-00030A-7f for 51753@debbugs.gnu.org; Wed, 10 Aug 2022 09:16:07 -0400 Received: from filter006.mxroute.com ([140.82.40.27] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta247.mxroute.com (ZoneMTA) with ESMTPSA id 18287e5bd800000261.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 10 Aug 2022 13:15:56 +0000 X-Zone-Loop: bfbcf897e94ef6ed6fb59e36499ba7d7a0466be1e9ad X-Originating-IP: [140.82.40.27] 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=OJCAm5kqDXac6/B7u9z3WzESkSZJh+Hsr96MndQTyn0=; b=DQOXp6bSFyvySze9oQyIU+v0jv 5/Km+XYxy9yBhf2CX57lKgn4RyUcpdaYSDM+b1RF6DwRi+JzGWTEf+5Hr4C6SIhJOQRPq9QYo89DY KB2YnTRSYIm9M5KNL8NI84GAV8WMVHX0W2yNzxK2fnM2ArIAXA4NibR12Qd8vNcIkcaU4B8XmpWI3 nRal78PcBeGwfTJZZjkM88CYHvFQy5QdshTykWgwPHM/9xRzvci8kByP7QZIm0RdrHu/6c7TFnbd9 GFtt9NajA/EiyyWH38J9EgoTvbDDnnSIW07YYahVWcq3CVAE2kn7f8Dyz/siLM3M7bzJ4MILPRyhI 4jsf36OQ==; From: "J.P." References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> Date: Wed, 10 Aug 2022 06:15:52 -0700 In-Reply-To: <87fsl0zo2e.fsf@neverwas.me> (J. P.'s message of "Mon, 23 May 2022 00:48:57 -0700") Message-ID: <87a68cnss7.fsf_-_@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hi Pankaj, "J.P." writes: > One thing to be aware of is that even if we pivot to #1, the > connection-detection and buffer-association stuff will still be > unreliable in many cases. However, that should change after bug#48598 > lands. The changes I was referring to have been on HEAD for over a month now, but I've been slow in getting back around to this bug (sorry). In case you or anyone else is interested, I've reworked things a bit to leverage the new buffer-association stuff, which should make finding a suitable frame more reliable. You still have to set the options as initially described up thread. Thanks. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0000-v2-v3.diff >From 5098c91eb6176e217f590bfa3da965cbe84653dc Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Wed, 10 Aug 2022 00:40:22 -0700 Subject: [PATCH 0/1] *** NOT A PATCH *** *** BLURB HERE *** F. Jason Park (1): Allow erc-reuse-frames to favor connections lisp/erc/erc.el | 61 +++++++- test/lisp/erc/erc-tests.el | 294 +++++++++++++++++++++++++++++++++++++ 2 files changed, 348 insertions(+), 7 deletions(-) Interdiff: diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 79091e18d5..c3bb30368a 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1701,14 +1701,20 @@ erc-frame-dedicated-flag :type 'boolean) (defcustom erc-reuse-frames t - "Non-nil means only create a frame for undisplayed buffers. -For new target buffers, a value of 'displayed' extends this to mean use -the frame of any buffer from the same server connection, visible or not, -or, as a last resort, a frame showing any ERC buffer. When this option -is nil, a new frame is always created. Regardless of its value, this -option is ignored unless `erc-join-buffer' is set to `frame'. Note that -like most options in the `erc-buffer' customize group, this has no -effect on server buffers while reconnecting." + "Determines whether new frames are always created. + +A value of t means only create a frame for undisplayed buffers. +`displayed' means use any existing, potentially hidden frame +already displaying a buffer from the same network context or, +failing that, a frame showing any ERC buffer. As a last resort, +`displayed' defaults to the selected frame, except for brand new +connections, for which the invoking frame is always used. When +this option is nil, a new frame is always created. + +Regardless of its value, this option is ignored unless +`erc-join-buffer' is set to `frame'. And like most options in +the `erc-buffer' customize group, this has no effect on server +buffers while reconnecting because those are always buried." :package-version '(ERC . "5.4.1") ; FIXME update when publishing to ELPA :group 'erc-buffers :type '(choice boolean @@ -2143,11 +2149,13 @@ erc-update-modules (funcall sym 1) (error "`%s' is not a known ERC module" mod)))))) -(defun erc--setup-buffer-first-win (frame a b) +(defun erc--setup-buffer-first-window (frame a b) (catch 'found (walk-window-tree (lambda (w) - (when (eq (buffer-local-value a (window-buffer w)) b) + (when (cond ((functionp a) (with-current-buffer (window-buffer w) + (funcall a b))) + (t (eq (buffer-local-value a (window-buffer w)) b))) (throw 'found t))) frame nil 0))) @@ -2156,17 +2164,19 @@ erc--display-buffer-use-some-frame If performed, return window used; otherwise, return nil. Forward ALIST to display-buffer machinery." (when-let* - ((same-proc-p (lambda (fr) - (erc--setup-buffer-first-win fr 'erc-server-process - erc-server-process))) - (same-mode-p (lambda (fr) - (erc--setup-buffer-first-win fr 'major-mode 'erc-mode))) - ((or (cdr (frame-list)) (funcall same-mode-p (selected-frame)))) - (frame (car (or (filtered-frame-list same-proc-p) - (filtered-frame-list same-mode-p)))) - (window (get-lru-window frame nil t))) - ;; FIXME don't rely on internal window.el function (tab-bar also does it) - (window--display-buffer buffer window 'reuse alist))) + ((idp (lambda (value) + (and erc-networks--id + (erc-networks--id-equal-p erc-networks--id value)))) + (procp (lambda (frame) + (erc--setup-buffer-first-window frame idp erc-networks--id))) + (ercp (lambda (frame) + (erc--setup-buffer-first-window frame 'major-mode 'erc-mode))) + ((or (cdr (frame-list)) (funcall ercp (selected-frame))))) + ;; Workaround to avoid calling `window--display-buffer' directly + (or (display-buffer-use-some-frame buffer + `((frame-predicate . ,procp) ,@alist)) + (display-buffer-use-some-frame buffer + `((frame-predicate . ,ercp) ,@alist))))) (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." @@ -2187,6 +2197,7 @@ erc-setup-buffer ((and (eq erc-reuse-frames 'displayed) (not (get-buffer-window buffer t))) (display-buffer buffer '((erc--display-buffer-use-some-frame) + (inhibit-switch-frame . t) (inhibit-same-window . t)))) ((or (not erc-reuse-frames) (not (get-buffer-window buffer t))) diff --git a/test/lisp/erc/erc-tests.el b/test/lisp/erc/erc-tests.el index 11c501ea84..0986fa6b8f 100644 --- a/test/lisp/erc/erc-tests.el +++ b/test/lisp/erc/erc-tests.el @@ -336,124 +336,299 @@ erc--switch-to-buffer (dolist (b '("server" "other" "#chan" "#foo" "#fake")) (kill-buffer b)))) -(ert-deftest erc-reuse-frames () - ;; TODO run this in a pseudo terminal subprocess for EMBA - ;; - ;; TODO case that simulates automatic reconnecting, with an - ;; existing, unselected frame containing two windows, one with a - ;; dead ERC buffer and the other a non-ERC buffer - (skip-unless (not noninteractive)) - (should-not erc-frame-dedicated-flag) - (let ((erc-join-buffer 'frame) - (erc-reuse-frames t) - (orig-frame (selected-frame)) - erc-kill-channel-hook erc-kill-server-hook erc-kill-buffer-hook) +(defun erc-tests--run-in-term (&optional debug) + (let* ((default-directory (getenv "EMACS_TEST_DIRECTORY")) + (emacs (expand-file-name invocation-name invocation-directory)) + (process-environment (cons "ERC_TESTS_SUBPROCESS=1" + process-environment)) + (name (ert-test-name (ert-running-test))) + (temp-file (make-temp-file "erc-term-test-")) + (cmd `(let ((stats 1)) + (setq enable-dir-local-variables nil) + (unwind-protect + (setq stats (ert-run-tests-batch ',name)) + (unless ,debug + (let ((buf (with-current-buffer (messages-buffer) + (buffer-string)))) + (with-temp-file ,temp-file + (insert buf))) + (kill-emacs (ert-stats-completed-unexpected stats)))))) + ;; `ert-test' object in Emacs 29 has a `file-name' field + (file-name (symbol-file name 'ert--test)) + (default-directory (expand-file-name (file-name-directory file-name))) + ;; Make subprocess terminal bigger than controlling. + (buf (cl-letf (((symbol-function 'window-screen-lines) + (lambda () 20)) + ((symbol-function 'window-max-chars-per-line) + (lambda () 40))) + (make-term (symbol-name name) emacs nil "-Q" "-nw" + "-L" (file-name-directory (locate-library "erc")) + "-l" file-name "-eval" (format "%S" cmd)))) + (proc (get-buffer-process buf)) + (err (lambda () + (with-temp-buffer + (insert-file-contents temp-file) + (message "Subprocess: %s" (buffer-string)) + (delete-file temp-file))))) + (with-current-buffer buf + (set-process-query-on-exit-flag proc nil) + (with-timeout (10 (funcall err) (error "Timed out awaiting result")) + (while (process-live-p proc) + (accept-process-output proc 0.1))) + (while (accept-process-output proc)) + (goto-char (point-min)) + ;; Otherwise gives process exited abnormally with exit-code >0 + (unless (search-forward (format "Process %s finished" name) nil t) + (funcall err) + (ert-fail (when (search-forward "exited" nil t) + (buffer-substring-no-properties (point-at-bol) + (point-at-eol))))) + (delete-file temp-file) + (when noninteractive + (kill-buffer))))) + +(defun erc-tests--servars (source &rest vars) + (unless (bufferp source) + (setq source (get-buffer source))) + (dolist (var vars) + (should (local-variable-if-set-p var)) + (set var (buffer-local-value var source)))) + +(defun erc-tests--erc-reuse-frames (test &optional debug) + (if (and (or debug noninteractive) (not (getenv "ERC_TESTS_SUBPROCESS"))) + (progn + (when (memq system-type '(windows-nt ms-dos)) + (ert-skip "System must be UNIX")) + (erc-tests--run-in-term debug)) + (should-not erc-frame-dedicated-flag) + (should (eq erc-reuse-frames t)) + (let ((erc-join-buffer 'frame) + (erc-reuse-frames t) + (erc-frame-alist nil) + (orig-frame (selected-frame)) + erc-kill-channel-hook erc-kill-server-hook erc-kill-buffer-hook) + (delete-other-frames) + (delete-other-windows) + (set-window-buffer (selected-window) "*scratch*") + (funcall test orig-frame) + (delete-other-frames orig-frame) + (delete-other-windows)))) + +;; TODO add cases for frame-display behavior while reconnecting + +(defun erc-tests--erc-reuse-frames--t (_) + (ert-info ("New server buffer creates and raises second frame") + (with-current-buffer (generate-new-buffer "server") + (erc-mode) + (setq erc-server-process (start-process "server" + (current-buffer) "sleep" "10") + erc-frame-alist (cons '(name . "server") default-frame-alist) + erc-network 'foonet + erc-networks--id (erc-networks--id-create nil) + erc--server-last-reconnect-count 0) + (set-process-buffer erc-server-process (current-buffer)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should (equal "server" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)))) - (ert-info ("Value: t") - (with-current-buffer (generate-new-buffer "server") + (ert-info ("New channel creates and raises third frame") + (with-current-buffer (generate-new-buffer "#chan") + (erc-mode) + (erc-tests--servars "server" 'erc-server-process 'erc-networks--id + 'erc-network) + (setq erc-frame-alist (cons '(name . "#chan") default-frame-alist) + erc-default-recipients '("#chan")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should (equal "#chan" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)) + (should (cddr (frame-list)))))) + +(ert-deftest erc-reuse-frames--t () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (erc-tests--erc-reuse-frames--t orig-frame) + (dolist (b '("server" "#chan")) + (kill-buffer b))))) + +(defun erc-tests--erc-reuse-frames--displayed-single (_ server-name chan-name) + + (should (eq erc-reuse-frames 'displayed)) + + (ert-info ("New server buffer shown in existing frame") + (with-current-buffer (generate-new-buffer server-name) + (erc-mode) + (setq erc-server-process (start-process server-name (current-buffer) + "sleep" "10") + erc-frame-alist (cons `(name . ,server-name) default-frame-alist) + erc-network (make-symbol server-name) + erc-server-current-nick "tester" + erc-networks--id (erc-networks--id-create nil) + erc--server-last-reconnect-count 0) + (set-process-buffer erc-server-process (current-buffer)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should-not (equal server-name (frame-parameter (window-frame) 'name))) + ;; New server buffer window appears in split below ERT/scratch + (should (get-buffer-window (current-buffer) t)))) + + (ert-info ("New channel shown in existing frame") + (with-current-buffer (generate-new-buffer chan-name) + (erc-mode) + (erc-tests--servars server-name 'erc-server-process 'erc-networks--id + 'erc-network) + (setq erc-frame-alist (cons `(name . ,chan-name) default-frame-alist) + erc-default-recipients (list chan-name)) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should-not (equal chan-name (frame-parameter (window-frame) 'name))) + ;; New channel buffer replaces server in lower window + (should (get-buffer-window (current-buffer) t)) + (should-not (get-buffer-window server-name t))))) + +(ert-deftest erc-reuse-frames--displayed-single () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (let ((erc-reuse-frames 'displayed)) + (erc-tests--erc-reuse-frames--displayed-single orig-frame + "server" "#chan") + (should-not (cdr (frame-list)))) + (dolist (b '("server" "#chan")) + (kill-buffer b))))) + +(defun erc-tests--assert-server-split (buffer-or-name frame-name) + ;; Assert current buffer resides on one side of a horizontal split + ;; in the "server" frame but is not selected. + (let* ((buffer-window (get-buffer-window buffer-or-name t)) + (buffer-frame (window-frame buffer-window))) + (should (equal frame-name (frame-parameter buffer-frame 'name))) + (should (memq buffer-window (car-safe (window-tree buffer-frame)))) + (should-not (eq buffer-window (frame-selected-window))) + buffer-frame)) + +(defun erc-tests--erc-reuse-frames--displayed-double (_) + (should (eq erc-reuse-frames 'displayed)) + + (make-frame '((name . "other"))) + (select-frame (make-frame '((name . "server"))) 'no-record) + (set-window-buffer (selected-window) "*scratch*") ; invokes `erc' + + ;; A user invokes an entry point and switches immediately to a new + ;; frame before autojoin kicks in (bug#55540). + + (ert-info ("New server buffer shown in selected frame") + (with-current-buffer (generate-new-buffer "server") + (erc-mode) + (setq erc-server-process (start-process "server" (current-buffer) + "sleep" "10") + erc-network 'foonet + erc-server-current-nick "tester" + erc-networks--id (erc-networks--id-create nil) + erc--server-last-reconnect-count 0) + (set-process-buffer erc-server-process (current-buffer)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should (equal "server" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)))) + + (select-frame-by-name "other") + + (ert-info ("New channel shown in dedicated frame") + (with-current-buffer (generate-new-buffer "#chan") + (erc-mode) + (erc-tests--servars "server" 'erc-server-process 'erc-networks--id + 'erc-network) + (setq erc-frame-alist (cons '(name . "#chan") default-frame-alist) + erc-default-recipients '("#chan")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (erc-tests--assert-server-split (current-buffer) "server") + ;; New channel buffer replaces server in lower window of other frame + (should-not (get-buffer-window "server" t))))) + +(ert-deftest erc-reuse-frames--displayed-double () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (let ((erc-reuse-frames 'displayed)) + (erc-tests--erc-reuse-frames--displayed-double orig-frame)) + (dolist (b '("server" "#chan")) + (kill-buffer b))))) + +;; If a frame showing ERC buffers exists among other frames, new, +;; additional connections will use the existing IRC frame. However, +;; if two or more frames exist with ERC buffers unique to a particular +;; connection, the correct frame will be found. + +(defun erc-tests--erc-reuse-frames--displayed-full (orig-frame) + (erc-tests--erc-reuse-frames--displayed-double orig-frame) + ;; Server buffer is not displayed because #chan has replaced it in + ;; the "server" frame, which is not selected. + (should (equal "other" (frame-parameter (window-frame) 'name))) + (erc-tests--erc-reuse-frames--displayed-single orig-frame "ircd" "#spam") + (should (equal "other" (frame-parameter (window-frame) 'name))) + + ;; Buffer "#spam" has replaced "ircd", which earlier replaced + ;; "#chan" in frame "server". But this is confusing, so... + (ert-info ("Arrange windows for second connection in other frame") + (set-window-buffer (selected-window) "ircd") + (split-window-below) + (set-window-buffer (next-window) "#spam") + (should (equal (cddar (window-tree)) + (list (get-buffer-window "ircd" t) + (get-buffer-window "#spam" t))))) + + (ert-info ("Arrange windows for first connection in server frame") + (select-frame-by-name "server") + (set-window-buffer (selected-window) "server") + (set-window-buffer (next-window) "#chan") + (should (equal (cddar (window-tree)) + (list (get-buffer-window "server" t) + (get-buffer-window "#chan" t))))) + + ;; Select original ERT frame + (ert-info ("New target for connection server finds appropriate frame") + (select-frame orig-frame 'no-record) + (with-current-buffer (window-buffer (selected-window)) + (should (member (buffer-name) '("*ert*" "*scratch*"))) + (with-current-buffer (generate-new-buffer "alice") + (erc-mode) + (erc-tests--servars "server" 'erc-server-process 'erc-networks--id) + (setq erc-default-recipients '("alice")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window created in frame "server" + (should (eq (selected-frame) orig-frame)) + (erc-tests--assert-server-split (current-buffer) "server")))) + + (ert-info ("New target for connection ircd finds appropriate frame") + (select-frame orig-frame 'no-record) + (with-current-buffer (window-buffer (selected-window)) + (should (member (buffer-name) '("*ert*" "*scratch*"))) + (with-current-buffer (generate-new-buffer "bob") (erc-mode) - (setq erc-server-process (start-process "server" (current-buffer) - "sleep" "1") - erc-frame-alist (cons '(name . "server") default-frame-alist)) - (set-process-query-on-exit-flag erc-server-process nil) + (erc-tests--servars "ircd" 'erc-server-process 'erc-networks--id) + (setq erc-default-recipients '("bob")) (should-not (get-buffer-window (current-buffer) t)) (erc-setup-buffer (current-buffer)) - ;; New frame created and raised - (should (equal "server" (frame-parameter (window-frame) 'name))) - (should (get-buffer-window (current-buffer) t)) - - (with-current-buffer (generate-new-buffer "#chan") - (erc-mode) - (setq erc-server-process erc-server-process - erc-frame-alist (cons '(name . "#chan") default-frame-alist) - erc-default-recipients '("#chan")) - (should-not (get-buffer-window (current-buffer) t)) - (erc-setup-buffer (current-buffer)) - ;; Another frame was created just for #chan - (should (equal "#chan" (frame-parameter (window-frame) 'name))) - (should (get-buffer-window (current-buffer) t)) - (delete-frame)) - - (select-frame-by-name "server") - (pop-to-buffer "#chan") - ;; The server frame contains two vertical windows - (let ((tree (window-tree))) - (should (memq (get-buffer-window "server" t) (car tree))) - (should (memq (get-buffer-window "#chan" t) (car tree)))) - (should (eq (get-buffer "#chan") (window-buffer (selected-window)))) - (should (eq (get-buffer "server") (window-buffer (next-window)))))) - - (ert-info ("Value: displayed, scratch frame selected") - (select-frame orig-frame) - (with-current-buffer "*scratch*" - (with-current-buffer (generate-new-buffer "#spam") - (erc-mode) - (setq erc-server-process (buffer-local-value 'erc-server-process - (get-buffer "server")) - erc-reuse-frames 'displayed - erc-frame-alist (cons '(name . "#spam") default-frame-alist) - erc-default-recipients '("#spam")) - (should-not (get-buffer-window (current-buffer) t)) - (erc-setup-buffer (current-buffer)) - ;; Window shows up in other frame - (should (eq (selected-frame) orig-frame)) - (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) - (should (equal "server" (frame-parameter fr 'name))) - (with-selected-frame fr - (should (memq (get-buffer-window "#spam" t) - (car (window-tree)))))))) - - (with-current-buffer "server" - (ert-info ("Value: displayed, server frame selected") - (select-frame-by-name "server") - (select-window (get-buffer-window "#spam")) - (with-current-buffer (generate-new-buffer "bob") - (erc-mode) - (setq erc-server-process (buffer-local-value 'erc-server-process - (get-buffer "server")) - erc-frame-alist (cons '(name . "bob") default-frame-alist) - erc-default-recipients '("bob")) - (should-not (get-buffer-window (current-buffer) t)) - (erc-setup-buffer (current-buffer)) - ;; Window shows up in this frame - (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) - (should (eq fr (selected-frame))) - (should (equal "server" (frame-parameter fr 'name))) - (with-selected-frame fr - (should (memq (get-buffer-window "bob" t) - (car (window-tree))))) - ;; `inhibit-same-window' respected - (should-not (eq (get-buffer-window "bob") (selected-window)))))) - - (ert-info ("Value: displayed, other frames deleted") - (with-selected-frame orig-frame - (delete-frame)) - (should-not (cdr (frame-list))) - (select-window (get-buffer-window "bob")) - (with-current-buffer (generate-new-buffer "alice") - (erc-mode) - (setq erc-server-process (buffer-local-value 'erc-server-process - (get-buffer "server")) - erc-frame-alist (cons '(name . "alice") default-frame-alist) - erc-default-recipients '("alice")) - (should-not (get-buffer-window (current-buffer) t)) - (erc-setup-buffer (current-buffer)) - (let ((fr (window-frame (get-buffer-window (current-buffer) t)))) - (should (eq fr (selected-frame))) - (should (equal "server" (frame-parameter fr 'name))) - (with-selected-frame fr - (should (memq (get-buffer-window "alice" t) - (car (window-tree))))) - (should-not (eq (get-buffer-window "alice") - (selected-window))))))))) - - (should-not (cdr (frame-list))) - (delete-other-windows) - (kill-buffer "server") - (kill-buffer "bob") - (kill-buffer "alice") - (kill-buffer "#spam") - (kill-buffer "#chan")) + ;; Window created in frame "other" + (should (eq (selected-frame) orig-frame)) + (erc-tests--assert-server-split (current-buffer) "other"))))) + +(ert-deftest erc-reuse-frames--displayed-full () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (let ((erc-reuse-frames 'displayed)) + (erc-tests--erc-reuse-frames--displayed-full orig-frame)) + (dolist (b '("server" "ircd" "bob" "alice" "#spam" "#chan")) + (kill-buffer b))))) (ert-deftest erc-lurker-maybe-trim () (let (erc-lurker-trim-nicks -- 2.36.1 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Allow-erc-reuse-frames-to-favor-connections.patch >From 5098c91eb6176e217f590bfa3da965cbe84653dc Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Sat, 21 May 2022 03:04:04 -0700 Subject: [PATCH 1/1] Allow erc-reuse-frames to favor connections * lisp/erc/erc.el (erc-reuse-frames): Add alternate value to favor existing frames already displaying buffers from the same connection. (erc--setup-buffer-first-window, erc--display-buffer-use-some-frame): Add helpers to support 'display' variant of `erc-resuse-frames' (erc-reuse-frames, erc-tests--servars, erc-tests--assert-server-split, erc-tests--erc-reuse-frames, erc-tests--run-in-term): Add test case and supporting helpers. (Bug#55540) --- lisp/erc/erc.el | 61 +++++++- test/lisp/erc/erc-tests.el | 294 +++++++++++++++++++++++++++++++++++++ 2 files changed, 348 insertions(+), 7 deletions(-) diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 151d75e7ce..c3bb30368a 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1702,11 +1702,23 @@ erc-frame-dedicated-flag (defcustom erc-reuse-frames t "Determines whether new frames are always created. -Non-nil means that a new frame is not created to display an ERC -buffer if there is already a window displaying it. This only has -effect when `erc-join-buffer' is set to `frame'." + +A value of t means only create a frame for undisplayed buffers. +`displayed' means use any existing, potentially hidden frame +already displaying a buffer from the same network context or, +failing that, a frame showing any ERC buffer. As a last resort, +`displayed' defaults to the selected frame, except for brand new +connections, for which the invoking frame is always used. When +this option is nil, a new frame is always created. + +Regardless of its value, this option is ignored unless +`erc-join-buffer' is set to `frame'. And like most options in +the `erc-buffer' customize group, this has no effect on server +buffers while reconnecting because those are always buried." + :package-version '(ERC . "5.4.1") ; FIXME update when publishing to ELPA :group 'erc-buffers - :type 'boolean) + :type '(choice boolean + (const displayed))) (defun erc-channel-p (channel) "Return non-nil if CHANNEL seems to be an IRC channel name." @@ -2137,6 +2149,35 @@ erc-update-modules (funcall sym 1) (error "`%s' is not a known ERC module" mod)))))) +(defun erc--setup-buffer-first-window (frame a b) + (catch 'found + (walk-window-tree + (lambda (w) + (when (cond ((functionp a) (with-current-buffer (window-buffer w) + (funcall a b))) + (t (eq (buffer-local-value a (window-buffer w)) b))) + (throw 'found t))) + frame nil 0))) + +(defun erc--display-buffer-use-some-frame (buffer alist) + "Maybe display BUFFER in an existing frame for the same connection. +If performed, return window used; otherwise, return nil. Forward ALIST +to display-buffer machinery." + (when-let* + ((idp (lambda (value) + (and erc-networks--id + (erc-networks--id-equal-p erc-networks--id value)))) + (procp (lambda (frame) + (erc--setup-buffer-first-window frame idp erc-networks--id))) + (ercp (lambda (frame) + (erc--setup-buffer-first-window frame 'major-mode 'erc-mode))) + ((or (cdr (frame-list)) (funcall ercp (selected-frame))))) + ;; Workaround to avoid calling `window--display-buffer' directly + (or (display-buffer-use-some-frame buffer + `((frame-predicate . ,procp) ,@alist)) + (display-buffer-use-some-frame buffer + `((frame-predicate . ,ercp) ,@alist))))) + (defun erc-setup-buffer (buffer) "Consults `erc-join-buffer' to find out how to display `BUFFER'." (pcase (if (zerop (erc-with-server-buffer @@ -2152,15 +2193,21 @@ erc-setup-buffer ('bury nil) ('frame - (when (or (not erc-reuse-frames) - (not (get-buffer-window buffer t))) + (cond + ((and (eq erc-reuse-frames 'displayed) + (not (get-buffer-window buffer t))) + (display-buffer buffer '((erc--display-buffer-use-some-frame) + (inhibit-switch-frame . t) + (inhibit-same-window . t)))) + ((or (not erc-reuse-frames) + (not (get-buffer-window buffer t))) (let ((frame (make-frame (or erc-frame-alist default-frame-alist)))) (raise-frame frame) (select-frame frame)) (switch-to-buffer buffer) (when erc-frame-dedicated-flag - (set-window-dedicated-p (selected-window) t)))) + (set-window-dedicated-p (selected-window) t))))) (_ (if (active-minibuffer-window) (display-buffer buffer) diff --git a/test/lisp/erc/erc-tests.el b/test/lisp/erc/erc-tests.el index 0f222edacf..0986fa6b8f 100644 --- a/test/lisp/erc/erc-tests.el +++ b/test/lisp/erc/erc-tests.el @@ -336,6 +336,300 @@ erc--switch-to-buffer (dolist (b '("server" "other" "#chan" "#foo" "#fake")) (kill-buffer b)))) +(defun erc-tests--run-in-term (&optional debug) + (let* ((default-directory (getenv "EMACS_TEST_DIRECTORY")) + (emacs (expand-file-name invocation-name invocation-directory)) + (process-environment (cons "ERC_TESTS_SUBPROCESS=1" + process-environment)) + (name (ert-test-name (ert-running-test))) + (temp-file (make-temp-file "erc-term-test-")) + (cmd `(let ((stats 1)) + (setq enable-dir-local-variables nil) + (unwind-protect + (setq stats (ert-run-tests-batch ',name)) + (unless ,debug + (let ((buf (with-current-buffer (messages-buffer) + (buffer-string)))) + (with-temp-file ,temp-file + (insert buf))) + (kill-emacs (ert-stats-completed-unexpected stats)))))) + ;; `ert-test' object in Emacs 29 has a `file-name' field + (file-name (symbol-file name 'ert--test)) + (default-directory (expand-file-name (file-name-directory file-name))) + ;; Make subprocess terminal bigger than controlling. + (buf (cl-letf (((symbol-function 'window-screen-lines) + (lambda () 20)) + ((symbol-function 'window-max-chars-per-line) + (lambda () 40))) + (make-term (symbol-name name) emacs nil "-Q" "-nw" + "-L" (file-name-directory (locate-library "erc")) + "-l" file-name "-eval" (format "%S" cmd)))) + (proc (get-buffer-process buf)) + (err (lambda () + (with-temp-buffer + (insert-file-contents temp-file) + (message "Subprocess: %s" (buffer-string)) + (delete-file temp-file))))) + (with-current-buffer buf + (set-process-query-on-exit-flag proc nil) + (with-timeout (10 (funcall err) (error "Timed out awaiting result")) + (while (process-live-p proc) + (accept-process-output proc 0.1))) + (while (accept-process-output proc)) + (goto-char (point-min)) + ;; Otherwise gives process exited abnormally with exit-code >0 + (unless (search-forward (format "Process %s finished" name) nil t) + (funcall err) + (ert-fail (when (search-forward "exited" nil t) + (buffer-substring-no-properties (point-at-bol) + (point-at-eol))))) + (delete-file temp-file) + (when noninteractive + (kill-buffer))))) + +(defun erc-tests--servars (source &rest vars) + (unless (bufferp source) + (setq source (get-buffer source))) + (dolist (var vars) + (should (local-variable-if-set-p var)) + (set var (buffer-local-value var source)))) + +(defun erc-tests--erc-reuse-frames (test &optional debug) + (if (and (or debug noninteractive) (not (getenv "ERC_TESTS_SUBPROCESS"))) + (progn + (when (memq system-type '(windows-nt ms-dos)) + (ert-skip "System must be UNIX")) + (erc-tests--run-in-term debug)) + (should-not erc-frame-dedicated-flag) + (should (eq erc-reuse-frames t)) + (let ((erc-join-buffer 'frame) + (erc-reuse-frames t) + (erc-frame-alist nil) + (orig-frame (selected-frame)) + erc-kill-channel-hook erc-kill-server-hook erc-kill-buffer-hook) + (delete-other-frames) + (delete-other-windows) + (set-window-buffer (selected-window) "*scratch*") + (funcall test orig-frame) + (delete-other-frames orig-frame) + (delete-other-windows)))) + +;; TODO add cases for frame-display behavior while reconnecting + +(defun erc-tests--erc-reuse-frames--t (_) + (ert-info ("New server buffer creates and raises second frame") + (with-current-buffer (generate-new-buffer "server") + (erc-mode) + (setq erc-server-process (start-process "server" + (current-buffer) "sleep" "10") + erc-frame-alist (cons '(name . "server") default-frame-alist) + erc-network 'foonet + erc-networks--id (erc-networks--id-create nil) + erc--server-last-reconnect-count 0) + (set-process-buffer erc-server-process (current-buffer)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should (equal "server" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)))) + + (ert-info ("New channel creates and raises third frame") + (with-current-buffer (generate-new-buffer "#chan") + (erc-mode) + (erc-tests--servars "server" 'erc-server-process 'erc-networks--id + 'erc-network) + (setq erc-frame-alist (cons '(name . "#chan") default-frame-alist) + erc-default-recipients '("#chan")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should (equal "#chan" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)) + (should (cddr (frame-list)))))) + +(ert-deftest erc-reuse-frames--t () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (erc-tests--erc-reuse-frames--t orig-frame) + (dolist (b '("server" "#chan")) + (kill-buffer b))))) + +(defun erc-tests--erc-reuse-frames--displayed-single (_ server-name chan-name) + + (should (eq erc-reuse-frames 'displayed)) + + (ert-info ("New server buffer shown in existing frame") + (with-current-buffer (generate-new-buffer server-name) + (erc-mode) + (setq erc-server-process (start-process server-name (current-buffer) + "sleep" "10") + erc-frame-alist (cons `(name . ,server-name) default-frame-alist) + erc-network (make-symbol server-name) + erc-server-current-nick "tester" + erc-networks--id (erc-networks--id-create nil) + erc--server-last-reconnect-count 0) + (set-process-buffer erc-server-process (current-buffer)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should-not (equal server-name (frame-parameter (window-frame) 'name))) + ;; New server buffer window appears in split below ERT/scratch + (should (get-buffer-window (current-buffer) t)))) + + (ert-info ("New channel shown in existing frame") + (with-current-buffer (generate-new-buffer chan-name) + (erc-mode) + (erc-tests--servars server-name 'erc-server-process 'erc-networks--id + 'erc-network) + (setq erc-frame-alist (cons `(name . ,chan-name) default-frame-alist) + erc-default-recipients (list chan-name)) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should-not (equal chan-name (frame-parameter (window-frame) 'name))) + ;; New channel buffer replaces server in lower window + (should (get-buffer-window (current-buffer) t)) + (should-not (get-buffer-window server-name t))))) + +(ert-deftest erc-reuse-frames--displayed-single () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (let ((erc-reuse-frames 'displayed)) + (erc-tests--erc-reuse-frames--displayed-single orig-frame + "server" "#chan") + (should-not (cdr (frame-list)))) + (dolist (b '("server" "#chan")) + (kill-buffer b))))) + +(defun erc-tests--assert-server-split (buffer-or-name frame-name) + ;; Assert current buffer resides on one side of a horizontal split + ;; in the "server" frame but is not selected. + (let* ((buffer-window (get-buffer-window buffer-or-name t)) + (buffer-frame (window-frame buffer-window))) + (should (equal frame-name (frame-parameter buffer-frame 'name))) + (should (memq buffer-window (car-safe (window-tree buffer-frame)))) + (should-not (eq buffer-window (frame-selected-window))) + buffer-frame)) + +(defun erc-tests--erc-reuse-frames--displayed-double (_) + (should (eq erc-reuse-frames 'displayed)) + + (make-frame '((name . "other"))) + (select-frame (make-frame '((name . "server"))) 'no-record) + (set-window-buffer (selected-window) "*scratch*") ; invokes `erc' + + ;; A user invokes an entry point and switches immediately to a new + ;; frame before autojoin kicks in (bug#55540). + + (ert-info ("New server buffer shown in selected frame") + (with-current-buffer (generate-new-buffer "server") + (erc-mode) + (setq erc-server-process (start-process "server" (current-buffer) + "sleep" "10") + erc-network 'foonet + erc-server-current-nick "tester" + erc-networks--id (erc-networks--id-create nil) + erc--server-last-reconnect-count 0) + (set-process-buffer erc-server-process (current-buffer)) + (set-process-query-on-exit-flag erc-server-process nil) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (should (equal "server" (frame-parameter (window-frame) 'name))) + (should (get-buffer-window (current-buffer) t)))) + + (select-frame-by-name "other") + + (ert-info ("New channel shown in dedicated frame") + (with-current-buffer (generate-new-buffer "#chan") + (erc-mode) + (erc-tests--servars "server" 'erc-server-process 'erc-networks--id + 'erc-network) + (setq erc-frame-alist (cons '(name . "#chan") default-frame-alist) + erc-default-recipients '("#chan")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + (erc-tests--assert-server-split (current-buffer) "server") + ;; New channel buffer replaces server in lower window of other frame + (should-not (get-buffer-window "server" t))))) + +(ert-deftest erc-reuse-frames--displayed-double () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (let ((erc-reuse-frames 'displayed)) + (erc-tests--erc-reuse-frames--displayed-double orig-frame)) + (dolist (b '("server" "#chan")) + (kill-buffer b))))) + +;; If a frame showing ERC buffers exists among other frames, new, +;; additional connections will use the existing IRC frame. However, +;; if two or more frames exist with ERC buffers unique to a particular +;; connection, the correct frame will be found. + +(defun erc-tests--erc-reuse-frames--displayed-full (orig-frame) + (erc-tests--erc-reuse-frames--displayed-double orig-frame) + ;; Server buffer is not displayed because #chan has replaced it in + ;; the "server" frame, which is not selected. + (should (equal "other" (frame-parameter (window-frame) 'name))) + (erc-tests--erc-reuse-frames--displayed-single orig-frame "ircd" "#spam") + (should (equal "other" (frame-parameter (window-frame) 'name))) + + ;; Buffer "#spam" has replaced "ircd", which earlier replaced + ;; "#chan" in frame "server". But this is confusing, so... + (ert-info ("Arrange windows for second connection in other frame") + (set-window-buffer (selected-window) "ircd") + (split-window-below) + (set-window-buffer (next-window) "#spam") + (should (equal (cddar (window-tree)) + (list (get-buffer-window "ircd" t) + (get-buffer-window "#spam" t))))) + + (ert-info ("Arrange windows for first connection in server frame") + (select-frame-by-name "server") + (set-window-buffer (selected-window) "server") + (set-window-buffer (next-window) "#chan") + (should (equal (cddar (window-tree)) + (list (get-buffer-window "server" t) + (get-buffer-window "#chan" t))))) + + ;; Select original ERT frame + (ert-info ("New target for connection server finds appropriate frame") + (select-frame orig-frame 'no-record) + (with-current-buffer (window-buffer (selected-window)) + (should (member (buffer-name) '("*ert*" "*scratch*"))) + (with-current-buffer (generate-new-buffer "alice") + (erc-mode) + (erc-tests--servars "server" 'erc-server-process 'erc-networks--id) + (setq erc-default-recipients '("alice")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window created in frame "server" + (should (eq (selected-frame) orig-frame)) + (erc-tests--assert-server-split (current-buffer) "server")))) + + (ert-info ("New target for connection ircd finds appropriate frame") + (select-frame orig-frame 'no-record) + (with-current-buffer (window-buffer (selected-window)) + (should (member (buffer-name) '("*ert*" "*scratch*"))) + (with-current-buffer (generate-new-buffer "bob") + (erc-mode) + (erc-tests--servars "ircd" 'erc-server-process 'erc-networks--id) + (setq erc-default-recipients '("bob")) + (should-not (get-buffer-window (current-buffer) t)) + (erc-setup-buffer (current-buffer)) + ;; Window created in frame "other" + (should (eq (selected-frame) orig-frame)) + (erc-tests--assert-server-split (current-buffer) "other"))))) + +(ert-deftest erc-reuse-frames--displayed-full () + :tags '(:unstable) + (erc-tests--erc-reuse-frames + (lambda (orig-frame) + (let ((erc-reuse-frames 'displayed)) + (erc-tests--erc-reuse-frames--displayed-full orig-frame)) + (dolist (b '("server" "ircd" "bob" "alice" "#spam" "#chan")) + (kill-buffer b))))) + (ert-deftest erc-lurker-maybe-trim () (let (erc-lurker-trim-nicks (erc-lurker-ignore-chars "_`")) -- 2.36.1 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame Resent-From: Pankaj Jangid Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Aug 2022 02:56:01 +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 To: "J.P." Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166018655630202 (code B ref 51753); Thu, 11 Aug 2022 02:56:01 +0000 Received: (at 51753) by debbugs.gnu.org; 11 Aug 2022 02:55:56 +0000 Received: from localhost ([127.0.0.1]:51076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLyMW-0007r3-Aw for submit@debbugs.gnu.org; Wed, 10 Aug 2022 22:55:56 -0400 Received: from mail-pj1-f49.google.com ([209.85.216.49]:45580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLyMS-0007qo-1G for 51753@debbugs.gnu.org; Wed, 10 Aug 2022 22:55:55 -0400 Received: by mail-pj1-f49.google.com with SMTP id p14-20020a17090a74ce00b001f4d04492faso3894951pjl.4 for <51753@debbugs.gnu.org>; Wed, 10 Aug 2022 19:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeisgreat-org.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:message-id:date:mail-followup-to:references :in-reply-to:subject:cc:to:from:from:to:cc; bh=3OArxJGdqJSIih4NJ6peJkTWRbiU5SAGQfjuyV2mnpk=; b=x92bDDLZiqnNFgLw4DpOSapfnJSzKzfaJViXe9KoZiezio0wSpkn5o24uhSFrNYoo+ EbDl+dTEtN2Duv6qwngt8eIMc4I0jyRbBnTxd9w8gdTSDqxQLew7pFZhMr6m2ncEzBiz kMkoGXzN9rPkdezLurqh1xq18hP8Yd50vDnsG4RH8vQMnC8Sb7/xCrmtpqfCgSMFrGiD 2rDcd+A+/7RpNml3fIIGYpdj6yT+GM5wHYdmVTXKS0uqL5mDDy2qXsDNvd/NPjOoQMi8 OohpXZfp1Pzv4SOgLku8wOUtPNKmb4LexAjdILbafDSswmZnwFRhnePwPnCmRiHwiPt/ nn7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:mail-followup-to:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=3OArxJGdqJSIih4NJ6peJkTWRbiU5SAGQfjuyV2mnpk=; b=wOGjn6G/5NDGfn9554aqw+XUPiQtjn15vo2P2oU8Pqd5OFZ/Z+jbMjyD5g4Kv4XfRl sb9mX3N/LB5JBjhNfBIqbOe+8zw4p63XR5kmAmQcGXpoHQZsilibUgJir8eaPR1jixTD +uOc7oVVCTVUioRnpTxUppVenGUJf+v/xcZ/QWmbEOZP21CdrZXaZaYBQx3m1t5tDSHY +JINOE1WtxT1l8+WFLcDStusWmbvskT+gMJd5Pt9d6I5rFCExcLuAu0QcyOlcYsaaN5j +jqHAaFWqRxZOrRS6aeRpShcd5N8WhGYaZNoM/L7y2DBVRe2TF+fb0c+P2bARaPOrQNk st5g== X-Gm-Message-State: ACgBeo3iIdsFa6dLScvsjS7mrOTmRxB7gbc3X/5CnJy5dVilKHI+KqeS My3ZO7euoetnp1B9sQXoFfMTPuGLkJAtdw== X-Google-Smtp-Source: AA6agR6FKItlO1kmRpOtnzy9k31dw1nb3ENSlH3CPwGUpNubhSz4DLsgQ1Jc25IJ4BY09IxNHj7nxA== X-Received: by 2002:a17:902:e394:b0:171:47c8:fe5f with SMTP id g20-20020a170902e39400b0017147c8fe5fmr1324547ple.82.1660186546040; Wed, 10 Aug 2022 19:55:46 -0700 (PDT) Received: from anant ([49.36.236.45]) by smtp.gmail.com with ESMTPSA id n6-20020aa79846000000b0052e6c073a3csm2894455pfq.142.2022.08.10.19.55.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 19:55:45 -0700 (PDT) From: Pankaj Jangid In-Reply-To: <87a68cnss7.fsf_-_@neverwas.me> (J. P.'s message of "Wed, 10 Aug 2022 06:15:52 -0700") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> Mail-Followup-To: "J.P." , emacs-erc@gnu.org, 51753@debbugs.gnu.org Date: Thu, 11 Aug 2022 08:25:42 +0530 Message-ID: <87sfm3tro1.fsf@codeisgreat.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) "J.P." writes: > The changes I was referring to have been on HEAD for over a month now, > but I've been slow in getting back around to this bug (sorry). In case > you or anyone else is interested, I've reworked things a bit to leverage > the new buffer-association stuff, which should make finding a suitable > frame more reliable. You still have to set the options as initially > described up thread. Thanks. I will try this change tomorrow, and report. Thanks for the updated. Thanks for your work. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2022 11:03:01 +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 To: Pankaj Jangid Cc: 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org, "J.P." Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166246212223221 (code B ref 51753); Tue, 06 Sep 2022 11:03:01 +0000 Received: (at 51753) by debbugs.gnu.org; 6 Sep 2022 11:02:02 +0000 Received: from localhost ([127.0.0.1]:49738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVWLC-00062S-6n for submit@debbugs.gnu.org; Tue, 06 Sep 2022 07:02:02 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVWLA-00061r-Vv; Tue, 06 Sep 2022 07:02:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; 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=E3O1m2qp3XWqF9TBknFHEuJZx75IrVaVpYP+pRna0+4=; b=tTImkBYPRxmyZBTdGjomtBlxyp ahdylK3XoTO670PWdXwuwodFCy9VxdD8T6Q7fKP54+M+luT0cjN17btWG6s2B5ak8OwL0yWT3tI4L WO95wBJ3/bK//2/3lLyScD7PX0sSan/qEw/gsWKMxivU5ZV465I1ToojBEiEKxP6niUg=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVWL1-0003mS-MG; Tue, 06 Sep 2022 13:01:53 +0200 From: Lars Ingebrigtsen In-Reply-To: <87sfm3tro1.fsf@codeisgreat.org> (Pankaj Jangid's message of "Thu, 11 Aug 2022 08:25:42 +0530") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> X-Now-Playing: David Bowie's _"Heroes"_: "Sons Of The Silent Age" Date: Tue, 06 Sep 2022 13:01:51 +0200 Message-ID: <87o7vsu5pc.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: erc still pops up the buffer by default, I think? I don't think it should do that, because it's both pretty annoying and a security issue -- you may suddenly be typing a password into an erc buffer. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) erc still pops up the buffer by default, I think? I don't think it should do that, because it's both pretty annoying and a security issue -- you may suddenly be typing a password into an erc buffer. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 06 07:02:05 2022 Received: (at control) by debbugs.gnu.org; 6 Sep 2022 11:02:05 +0000 Received: from localhost ([127.0.0.1]:49743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVWLF-00062o-ML for submit@debbugs.gnu.org; Tue, 06 Sep 2022 07:02:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVWLD-00061v-NR for control@debbugs.gnu.org; Tue, 06 Sep 2022 07:02:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nGPAcURC/dvRSo47AXg9eW87htdnnVQd73OOsXgcbeU=; b=LUnbrmyqs3bm38TEQzRGjqo4LC iTQzNdx0y5b33gjw4n7TYpZIymIRcO0Y5F9v30F0NQMNHpOWK6jdk2x38yA7X+v8dLhR9lUEgCYhH gEEexAo4SSaCRDnlYCwtKsvJk2YnGqCrECginrMFlgqI2ApSqNVVbznw2AYML57KSwMQ=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVWL6-0003mb-7M for control@debbugs.gnu.org; Tue, 06 Sep 2022 13:01:58 +0200 Date: Tue, 06 Sep 2022 13:01:55 +0200 Message-Id: <87mtbcu5p8.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #55540 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 55540 + moreinfo quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 55540 + moreinfo quit From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2022 13:54: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 moreinfo To: Lars Ingebrigtsen Cc: 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org, Pankaj Jangid Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.16624724303828 (code B ref 51753); Tue, 06 Sep 2022 13:54:02 +0000 Received: (at 51753) by debbugs.gnu.org; 6 Sep 2022 13:53:50 +0000 Received: from localhost ([127.0.0.1]:50211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVZ1R-0000ze-H0 for submit@debbugs.gnu.org; Tue, 06 Sep 2022 09:53:49 -0400 Received: from mail-108-mta84.mxroute.com ([136.175.108.84]:33555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVZ1P-0000zJ-65 for 51753@debbugs.gnu.org; Tue, 06 Sep 2022 09:53:47 -0400 Received: from mail-111-mta2.mxroute.com ([136.175.111.2] mail-111-mta2.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta84.mxroute.com (ZoneMTA) with ESMTPSA id 1831313f120000dd1a.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 06 Sep 2022 13:53:37 +0000 X-Zone-Loop: a62f320d8d608154cfb9ea7fb974cbbc21c2de286aba 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: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=9WOsywh+e2Xyaj/ZYU7yAT7GsJXRPaH+QPHioyc6KdE=; b=cAdK1BcZJFaWCshBVxdleJwqUz GoD9Kqgf3KMy1uKT/im/wV3W+WKVutLXaBGdaxBrWgpz1YJHHepM/1zQliwsi/9gOy+499YqHMALC 6jzfDi/3mmwh8ekS1igjMnvHSRuIIDX/5npGhp8F5N3gGX+fGnd22Sg/l9wg0Xf1fGoohAw7ov7Jh kvC65FHMgHqlPrZlXFJReExezrlKuqjLeFwlVwtZntFam8tDSzJ9vlWbdaaLpmAsT/XJQ8G7tLr6A 0gR0JFVnqZ0+X4EhmFzyTUK1WlEp/oVr7Hbk8/wjCs9n2wlFYso9McNujYF5S3A5Aij1uQ+9O98Eb Uu3tiujQ==; From: "J.P." References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> Date: Tue, 06 Sep 2022 06:53:34 -0700 In-Reply-To: <87o7vsu5pc.fsf_-_@gnus.org> (Lars Ingebrigtsen's message of "Tue, 06 Sep 2022 13:01:51 +0200") Message-ID: <87o7vs38yp.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Lars, Lars Ingebrigtsen writes: > erc still pops up the buffer by default, I think? I don't think it > should do that, because it's both pretty annoying and a security > issue -- you may suddenly be typing a password into an erc buffer. Are you concerned about the behavior during initial connections as well as automatic reconnections? Regardless, as you say, the default value of `buffer' for `erc-join-buffer' (and `erc-reconnect-display') causes the buffer in the selected window to be replaced with the just-(re)initialized ERC buffer. Also, depending on various factors, values other than `buffer' can exhibit similar behavior. For example, in a dual-window split, a value of `window-noselect' can result in a newly (re)joined channel replacing the buffer in the selected window when the connection's server buffer is showing in the other window. Plain `window' is much the same, but at least there's somewhat of an expectation that the selected window's buffer may change. Really, the only safe option is `bury' (well, maybe also the proposed frame stuff in Pankaj's patch, but only when an extra, ERC-specific frame already exists, which we can't count on). That said, there's no reason we'd have to stick with existing options/behavior when choosing a new default. I guess it just comes down to what users want to happen. If we're talking both `erc-join-buffer' and `erc-reconnect-display', one idea would be to make `window-noselect' the default but change it to mean the selected window is always left unmolested, no matter what. The justification for the breaking change would be that the existing doc string in (const :tag "Split window, don't select" window-noselect) has always implied as much, namely that a window displaying the new buffer will always be shown and never selected. Although, if this only concerns `erc-reconnect-display', we could just go with `bury' since (among the available options) that best minimizes the disruption of a reestablished connection. Hopefully folks have stronger opinions and/or better ideas. Thanks. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2022 14:03: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 moreinfo To: "J.P." Cc: 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org, Pankaj Jangid Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.16624729686783 (code B ref 51753); Tue, 06 Sep 2022 14:03:02 +0000 Received: (at 51753) by debbugs.gnu.org; 6 Sep 2022 14:02:48 +0000 Received: from localhost ([127.0.0.1]:52187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVZA7-0001lK-Oj for submit@debbugs.gnu.org; Tue, 06 Sep 2022 10:02:48 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVZA5-0001l2-E4; Tue, 06 Sep 2022 10:02:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; 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=YPvbzeEiTslEYcAoLO3EodK6bRg2q3bXPoMBi++6Oag=; b=C5jGNOjll7RUVlkBbD+R71tQB+ R2Mhupch+H1ElsgSXleBEeibReiZeAqHf/TeOz82B6X+MyPmm5P7FOXImRvs3G0bplN7TGxR6xLHW /52OaYwTehr+alVz6NlAu9bfFgj13ipyf3cf3oFDPeC/u5wRegqd2qzybp4AQ/AN355o=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVZ9v-0005I0-GQ; Tue, 06 Sep 2022 16:02:37 +0200 From: Lars Ingebrigtsen In-Reply-To: <87o7vs38yp.fsf@neverwas.me> (J. P.'s message of "Tue, 06 Sep 2022 06:53:34 -0700") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEWvPDZcRDIRCwrX son///9/75/RAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YJBg4AMX/yQqIAAAHDSURBVDjLjZPrsesg DIQFNICgAYQbMFb/vd1d+ZE4c35cJhPb+mD1RKTK5BLJ83sJFh5pnM8voNhqU2oe0l4gJ51CoZHe JzLVMo9JektRPfPvB8BaqSOi+gJDIiKZbzvCEeH29DZHXvzpr33CIxLQNv8Af6+fQnyBOa39L6gX 0PomVR+ALfbYzdsJLE/f2iePzaNjYuNQL2t9lLzRq2jX6r6nx4/u8S+pVlX3eWtZ05q0ddG8Lfc1 1wO6u+cuzQde1I4b4DikizQbvruPfIPdY2E0NoeWTZPTjV/AjZp7Q3waldZCexHdKLrmhniNel2p 4MIXRxU6i0KxfpxSeOkE0XTWtRvtS+B78wNRsr293eAg2HFgIN/SCrLZ5ALYgM9htSAt5D8CzAAQ 0KgEtxhj8iZmiBVf7fQJ7+VyrosZJNN+gXEDY6BqZXndU/SWpbiAqTkSTVSNGiUCSs0ACtCMHVWO /wWg3Q9rbQBU3OVwYVHu1bFNLfnSLvPuNhusUxO87ZgFoSjtrbLVk03pyxTOr9HtiAXFJdiy4Z7d w9kjOxQZWpyg53qUM21akVlt3+CI6QkgHxBtjCg0HH1uWr9mkXaAf5OiilE4aSzrAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIyLTA5LTA2VDE0OjAwOjQ5KzAwOjAw43qbggAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMi0wOS0wNlQxNDowMDo0OSswMDowMJInIz4AAAAASUVORK5CYII= X-Now-Playing: The Police's _Outlandos d'Amour_: "Hole in my Life" Date: Tue, 06 Sep 2022 16:02:32 +0200 Message-ID: <87y1uwr47b.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "J.P." writes: > Are you concerned about the behavior during initial connections as well > as automatic reconnections? Yes. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) "J.P." writes: > Are you concerned about the behavior during initial connections as well > as automatic reconnections? Yes. > Really, the only safe option is `bury' (well, maybe also the proposed > frame stuff in Pankaj's patch, but only when an extra, ERC-specific > frame already exists, which we can't count on). That said, there's no > reason we'd have to stick with existing options/behavior when choosing a > new default. I guess it just comes down to what users want to happen. I think the default action should be to do nothing to the window setup at all, and just add the notification to the mode line. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2022 03:11:01 +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 moreinfo To: Lars Ingebrigtsen Cc: 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org, Pankaj Jangid Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166252023932208 (code B ref 51753); Wed, 07 Sep 2022 03:11:01 +0000 Received: (at 51753) by debbugs.gnu.org; 7 Sep 2022 03:10:39 +0000 Received: from localhost ([127.0.0.1]:53075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVlSY-0008NN-MK for submit@debbugs.gnu.org; Tue, 06 Sep 2022 23:10:39 -0400 Received: from mail-108-mta158.mxroute.com ([136.175.108.158]:45895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVlSU-0008Mv-Hg for 51753@debbugs.gnu.org; Tue, 06 Sep 2022 23:10:37 -0400 Received: from mail-111-mta2.mxroute.com ([136.175.111.2] mail-111-mta2.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta158.mxroute.com (ZoneMTA) with ESMTPSA id 18315ed78af000dd1a.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 07 Sep 2022 03:10:28 +0000 X-Zone-Loop: 6301184a049097961c7cfaab1db1874b9bc6e928b159 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: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=Y9yBcVSqrEmte5ZgV3THgrVWy5wPJIewXM34E7HPg5I=; b=ZxwXpD236OJzb7JIrpGfPx0dch xEgh7VHaw8AwSsQMeW9Ky3eMWhy1meeT6+KA4NnMaGCeVd85KXWXfTf0H7Tabcvl1hplCtUJuvAa6 ghlj0xkukHh1mEMr90BtdxHaJ8LX4tkquDnXL9WLOfNciOJ9QxJK+bP82e0uRK8bsFm/ZVTWjbhVc b6pTtoas029FVzf2iBh0j4Rk4tSNQ45dLRCe04l1T9iEGdTBgEjRveY6VPf97y6wxc7luXlWABo/P ZlqxkjpdvNxrbT6tDfLCeIJ7TG/cDWFS0l/8MZJ+ywKr8mCOSAJ1jEYCxeIzmmqqCpO70+YeUxepD 8D5l93HQ==; From: "J.P." References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> <87y1uwr47b.fsf@gnus.org> Date: Tue, 06 Sep 2022 20:10:23 -0700 In-Reply-To: <87y1uwr47b.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 06 Sep 2022 16:02:32 +0200") Message-ID: <874jxj282o.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Authenticated-Id: masked@neverwas.me X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Lars Ingebrigtsen writes: > "J.P." writes: > >> Really, the only safe option is `bury' (well, maybe also the proposed >> frame stuff in Pankaj's patch, but only when an extra, ERC-specific >> frame already exists, which we can't count on). That said, there's no >> reason we'd have to stick with existing options/behavior when choosing a >> new default. I guess it just comes down to what users want to happen. > > I think the default action should be to do nothing to the window setup > at all, and just add the notification to the mode line. I believe changing the default for `erc-join-buffer' (alone) to `bury' is the easiest way to achieve that. Thus, if no one objects within the next week or so, I will add the patch below or similar to trunk (and what will become ERC 5.5), along with a related NEWS entry. Thanks. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Bury-new-ERC-buffers-by-default.patch >From 8b4edbca2771227d4e6ee464ddd210080339f63b Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Tue, 6 Sep 2022 19:09:54 -0700 Subject: [PATCH] Bury new ERC buffers by default * lisp/erc/erc.el (erc-join-buffer): Change default value to `bury'. * test/lisp/erc/erc-scenarios-base-reconnect.el (erc-scenarios-common-base-reconnect-options): Update helper to handle new default value for option `erc-join-buffer'. (erc-scenarios-base-reconnect-options--buffer): Update and rename function `erc-scenarios-base-reconnect-options--default'. (erc-scenarios-base-reconnect-options--default): Update and rename function `erc-scenarios-base-reconnect-options--bury'. --- lisp/erc/erc.el | 3 +- test/lisp/erc/erc-scenarios-base-reconnect.el | 45 ++++++++++--------- 2 files changed, 25 insertions(+), 23 deletions(-) diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 151d75e7ce..657ef8cdb3 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -1651,7 +1651,7 @@ erc-default-port-tls "IRC port to use for encrypted connections if it cannot be \ detected otherwise.") -(defcustom erc-join-buffer 'buffer +(defcustom erc-join-buffer 'bury "Determines how to display a newly created IRC buffer. The available choices are: @@ -1662,6 +1662,7 @@ erc-join-buffer `bury' - bury it in a new buffer, `buffer' - in place of the current buffer, any other value - in place of the current buffer." + :package-version '(ERC . "5.4.1") ; FIXME increment upon publishing to ELPA :group 'erc-buffers :type '(choice (const :tag "Split window and select" window) (const :tag "Split window, don't select" window-noselect) diff --git a/test/lisp/erc/erc-scenarios-base-reconnect.el b/test/lisp/erc/erc-scenarios-base-reconnect.el index 30d692058d..49298dc594 100644 --- a/test/lisp/erc/erc-scenarios-base-reconnect.el +++ b/test/lisp/erc/erc-scenarios-base-reconnect.el @@ -99,10 +99,11 @@ erc-scenarios-common--base-reconnect-options (funcall test) + ;; A manual /JOIN command tells ERC we're done auto-reconnecting (with-current-buffer "FooNet" (erc-cmd-JOIN "#spam")) - (erc-d-t-wait-for 5 "Channel #spam shown when autojoined" - (eq (window-buffer) (get-buffer "#spam"))) + (erc-d-t-ensure-for 1 "Newly joined chan ignores `erc-reconnect-display'" + (not (eq (window-buffer) (get-buffer "#spam")))) (ert-info ("Wait for auto reconnect") (with-current-buffer erc-server-buffer @@ -114,43 +115,43 @@ erc-scenarios-common--base-reconnect-options (with-current-buffer (erc-d-t-wait-for 10 (get-buffer "#spam")) (funcall expect 10 "her elves come here anon"))))) -(ert-deftest erc-scenarios-base-reconnect-options--default () +(ert-deftest erc-scenarios-base-reconnect-options--buffer () :tags '(:expensive-test) - (should (eq erc-join-buffer 'buffer)) + (should (eq erc-join-buffer 'bury)) (should-not erc-reconnect-display) ;; FooNet (the server buffer) is not switched to because it's ;; already current (but not shown) when `erc-open' is called. See ;; related conditional guard towards the end of that function. - (erc-scenarios-common--base-reconnect-options - (lambda () - (pop-to-buffer-same-window "*Messages*") + (let ((erc-reconnect-display 'buffer)) + (erc-scenarios-common--base-reconnect-options + (lambda () + (pop-to-buffer-same-window "*Messages*") - (erc-d-t-ensure-for 1 "Server buffer not shown" - (not (eq (window-buffer) (get-buffer "FooNet")))) + (erc-d-t-ensure-for 1 "Server buffer not shown" + (not (eq (window-buffer) (get-buffer "FooNet")))) - (erc-d-t-wait-for 5 "Channel #chan shown when autojoined" - (eq (window-buffer) (get-buffer "#chan")))))) + (erc-d-t-wait-for 5 "Channel #chan shown when autojoined" + (eq (window-buffer) (get-buffer "#chan"))))))) -(ert-deftest erc-scenarios-base-reconnect-options--bury () +(ert-deftest erc-scenarios-base-reconnect-options--default () :tags '(:expensive-test) - (should (eq erc-join-buffer 'buffer)) + (should (eq erc-join-buffer 'bury)) (should-not erc-reconnect-display) - (let ((erc-reconnect-display 'bury)) - (erc-scenarios-common--base-reconnect-options + (erc-scenarios-common--base-reconnect-options - (lambda () - (pop-to-buffer-same-window "*Messages*") + (lambda () + (pop-to-buffer-same-window "*Messages*") - (erc-d-t-ensure-for 1 "Server buffer not shown" - (not (eq (window-buffer) (get-buffer "FooNet")))) + (erc-d-t-ensure-for 1 "Server buffer not shown" + (not (eq (window-buffer) (get-buffer "FooNet")))) - (erc-d-t-ensure-for 3 "Channel #chan not shown" - (not (eq (window-buffer) (get-buffer "#chan")))) + (erc-d-t-ensure-for 3 "Channel #chan not shown" + (not (eq (window-buffer) (get-buffer "#chan")))) - (eq (window-buffer) (messages-buffer)))))) + (eq (window-buffer) (messages-buffer))))) ;; Upon reconnecting, playback for channel and target buffers is ;; routed correctly. Autojoin is irrelevant here, but for the -- 2.37.2 --=-=-=-- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2022 12:56: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 moreinfo To: "J.P." Cc: 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org, Pankaj Jangid Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166255535810748 (code B ref 51753); Wed, 07 Sep 2022 12:56:02 +0000 Received: (at 51753) by debbugs.gnu.org; 7 Sep 2022 12:55:58 +0000 Received: from localhost ([127.0.0.1]:53962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVuaz-0002nH-S6 for submit@debbugs.gnu.org; Wed, 07 Sep 2022 08:55:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:41686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVuay-0002n1-Hp; Wed, 07 Sep 2022 08:55:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; 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=hFpQhSMP5A05x/0wxyzE/C3XMUuNamVmlgyWxhZTXk0=; b=Baomum+KpihsP2Oo1D8My/8qWr FCQeTbx2QwRyCXhqecqCW8EjikZYDvgQApYf4krxC/O9Kt2O+MXRFxRzH9hWvthlTWLZTGNkSkzrt kBnBKm7at9PUkXT5sdcUruOirDql8AaaeT+95C5iNMBtHM+vhyAEAmyHJdt7psbWeS5M=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVuap-0006vf-Iv; Wed, 07 Sep 2022 14:55:49 +0200 From: Lars Ingebrigtsen In-Reply-To: <874jxj282o.fsf@neverwas.me> (J. P.'s message of "Tue, 06 Sep 2022 20:10:23 -0700") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> <87y1uwr47b.fsf@gnus.org> <874jxj282o.fsf@neverwas.me> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEWhlEBJRSr////o CFXIAAAAAWJLR0QCZgt8ZAAAAAlwSFlzAAABLAAAASwAc4jpUgAAAAd0SU1FB+YJBhYCMCj24n4A AADgSURBVCjPdZLRCgQhCEUVxneD/J+CejfI//+VtWxmdx9GmMHDvZlKAO+BdqKcXG/4U9AUqDEt oF+F0r/tR3kFfAXg0Ut5musi30Yzj6/CYz4CjJ7KA/XqkWxI0h+lpbTu4OXFBmukAL4AJwNyO6Db vsA/5QMrSI/trvoDDNz4htZS1kgzSascgF0HVw24xGQ03b1zrdV6juGv7OvIqe4Ta0E6B22lqBjV HqWzFDSxPQNQ8Q3aPNvz7Yhp1XONhwSg22xaiQ6WQoanUS8gdmz+p/UaQvBbux+7h55kou9v6gPB V0n+mfEx0AAAAFplWElmTU0AKgAAAAgABQESAAMAAAABAAEAAAEaAAUAAAABAAAASgEbAAUAAAAB AAAAUgEoAAMAAAABAAEAAAITAAMAAAABAAEAAAAAAAAAAAEsAAAAAQAAASwAAAABYCqauwAAACV0 RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOS0wNlQyMjowMjo0NyswMDowMGs0yuQAAAAldEVYdGRhdGU6 bW9kaWZ5ADIwMjItMDktMDZUMjI6MDI6NDcrMDA6MDAaaXJYAAAAF3RFWHRleGlmOllDYkNyUG9z aXRpb25pbmcAMawPgGMAAAAASUVORK5CYII= X-Now-Playing: Ash Walker - =?UTF-8?Q?=E2=80=98There=E2=80=99s?= Nothing Like =?UTF-8?Q?This=E2=80=99?= (Exclusive track)'s _Late Night Tales: Version Excursions (Selected By Don Letts)_: "Originally recorded by Omar " Date: Wed, 07 Sep 2022 14:55:47 +0200 Message-ID: <87mtbbmjho.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "J.P." writes: > I believe changing the default for `erc-join-buffer' (alone) to `bury' > is the easiest way to achieve that. > > Thus, if no one objects within the next week or so, I will add the patch > below or s [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) "J.P." writes: > I believe changing the default for `erc-join-buffer' (alone) to `bury' > is the easiest way to achieve that. > > Thus, if no one objects within the next week or so, I will add the patch > below or similar to trunk (and what will become ERC 5.5), along with a > related NEWS entry. Thanks. Thanks; makes sense to me. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Sep 2022 13:12: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 moreinfo To: Pankaj Jangid Cc: 55540@debbugs.gnu.org, Lars Ingebrigtsen , emacs-erc@gnu.org, 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166367948621932 (code B ref 51753); Tue, 20 Sep 2022 13:12:02 +0000 Received: (at 51753) by debbugs.gnu.org; 20 Sep 2022 13:11:26 +0000 Received: from localhost ([127.0.0.1]:56580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oad25-0005hZ-Gm for submit@debbugs.gnu.org; Tue, 20 Sep 2022 09:11:25 -0400 Received: from mail-108-mta74.mxroute.com ([136.175.108.74]:36105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oad23-0005hD-13 for 51753@debbugs.gnu.org; Tue, 20 Sep 2022 09:11:24 -0400 Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta74.mxroute.com (ZoneMTA) with ESMTPSA id 1835b062f580002b7a.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 20 Sep 2022 13:11:15 +0000 X-Zone-Loop: cfe2664d55a769781a67aa578f7536766aa4a75efa0c 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=wjB2jzrr4P9V8sBnefTH/Miv/yP6vgOX4TRYOIusgsI=; b=CiUr+0vZ9movbsbNlZi/LCBSb7 bpv2G/UMPDMNLv0achRkr2pcQ45h/+8R1iacoc012kHtYs6Lm96jDVmB5wT+KrhHS4HAzD5u8bH7U BGsx3pwbbcYLblLL5FmDThF/Rk+kfDnIw8btuBGn5x11pjYQ9nQODBM0pSiANTEi2aTy/u0UDcL5X 1715EKXsSPD4IQYEZ8yqMXISEuad6Af4ebdjRLkhVVthO/DxniVOHG4L+xgb3gD5XxEEhbtTkmEiI 58syF8AdOSUpru1Zw6g0QtwLC4HAVNuxVFpkxtYOpbQuMTnW6uCqT8ACQ6Hf3lktrJvzj5YOThn64 xAkDPgXA==; From: "J.P." In-Reply-To: <87mtbbmjho.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Sep 2022 14:55:47 +0200") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> <87y1uwr47b.fsf@gnus.org> <874jxj282o.fsf@neverwas.me> <87mtbbmjho.fsf@gnus.org> Date: Tue, 20 Sep 2022 06:11:11 -0700 Message-ID: <87pmfq198w.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> Thus, if no one objects within the next week or so, I will add the patch >> below or similar to trunk (and what will become ERC 5.5), along with a >> related NEWS entry. Thanks. This has been carried out. Pankaj, all that remains is your frame stuff. If problems persist and/or you've lost interest, please let us know, so I can act accordingly. Thanks. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: Pankaj Jangid Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Sep 2022 03:08:01 +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 moreinfo To: "J.P." Cc: 55540@debbugs.gnu.org, Lars Ingebrigtsen , emacs-erc@gnu.org, 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166381603630995 (code B ref 51753); Thu, 22 Sep 2022 03:08:01 +0000 Received: (at 51753) by debbugs.gnu.org; 22 Sep 2022 03:07:16 +0000 Received: from localhost ([127.0.0.1]:35682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obCYV-00083p-PW for submit@debbugs.gnu.org; Wed, 21 Sep 2022 23:07:16 -0400 Received: from mail-pg1-f175.google.com ([209.85.215.175]:46724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obCYT-00083O-F6 for 51753@debbugs.gnu.org; Wed, 21 Sep 2022 23:07:13 -0400 Received: by mail-pg1-f175.google.com with SMTP id 78so7826024pgb.13 for <51753@debbugs.gnu.org>; Wed, 21 Sep 2022 20:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeisgreat-org.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:message-id:date:mail-followup-to:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=VEDWHzKdJYmlZcyZEvUE1guWhegaDZqMYGg+Xf5b2l0=; b=UNKXmqlAGZBQGfLbLVCR1FDWh5d86Bk4z4cijZSQdutDvuIYgCYir34N40LpMxGsWk Llc8Ra+72uYBZy/OoZJCrT4gynszKrxjcfsoCUkW+aSEKnuHDM64djeGg6EdOXxIEKBp BsNbY3IqTls8b4P42p27I0mZ+9V+LRhQUZMQUCjOh8K5TeHofmK63KNW2kTaqnbcKOkG bERXsZ1vhKfBvo3DXoCCU98mOuDSszNDavb+PyVd1KIdBUYLxpHKt11PU8ckOGP6T89t nlCQcSpPZVUOkvSIZiQ8fn00niPF8jBD4x71/AVt6NTNp9cTSH5L0u7mKYyYnrdAfkI4 mi8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:mail-followup-to:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=VEDWHzKdJYmlZcyZEvUE1guWhegaDZqMYGg+Xf5b2l0=; b=e7ric0b+2n3WJeKSlT4eQTWmbSyOCm+4gLTuBHPsQslGh9QpevgMKx7qqPOHOVz76d VEgbUNQs8/rN0L3mLJH66FkpEgpN11orH0OATBiZCXr/B7w5k5AP28NA7eM4yFzbdSBB 14ssb/5qesWXUbP9noGHH/wMwIc7sk80DVsf9FX0uzpfUY1ksjnayxZsDQNS7rLyTUEr HQcl9u9vyGegyyFeBEeET7Wt1PuaczP0HvDPtdGksskDBCwu2bcLWrhIPIy46azsb1pI qIRe5HJAtLqE6GiLXsoG6MDzSZRKbCkmx9QGdm38UE2jTohEPIdg4a34A93SMC8VopEI n7PQ== X-Gm-Message-State: ACrzQf2Jn82AQ/rF5Wf9Yrs5s1rJPUq47C9hsacofEuov7vfPgbZRzVy MlRdN47xR7UjSxXvXhCqrXm4Yg== X-Google-Smtp-Source: AMsMyM6VNepHpAHbtH1r+SOVPtrAhVElYn/J/tfCH2BeJITE91SFtHo8U0SH4bbE3Ml4ZvH8Ra9o8w== X-Received: by 2002:aa7:8704:0:b0:542:5288:5e32 with SMTP id b4-20020aa78704000000b0054252885e32mr1363195pfo.84.1663816027662; Wed, 21 Sep 2022 20:07:07 -0700 (PDT) Received: from anant ([49.36.236.45]) by smtp.gmail.com with ESMTPSA id l15-20020a17090a384f00b001fd8316db51sm2643868pjf.7.2022.09.21.20.07.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 20:07:06 -0700 (PDT) From: Pankaj Jangid In-Reply-To: <87pmfq198w.fsf@neverwas.me> (J. P.'s message of "Tue, 20 Sep 2022 06:11:11 -0700") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> <87y1uwr47b.fsf@gnus.org> <874jxj282o.fsf@neverwas.me> <87mtbbmjho.fsf@gnus.org> <87pmfq198w.fsf@neverwas.me> Mail-Followup-To: "J.P." , Lars Ingebrigtsen , 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org Date: Thu, 22 Sep 2022 08:37:02 +0530 Message-ID: <87y1uc150p.fsf@codeisgreat.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) "J.P." writes: >>> Thus, if no one objects within the next week or so, I will add the patch >>> below or similar to trunk (and what will become ERC 5.5), along with a >>> related NEWS entry. Thanks. > > This has been carried out. > > Pankaj, all that remains is your frame stuff. If problems persist and/or > you've lost interest, please let us know, so I can act accordingly. > Thanks. Now the behaviour is acceptable when "erc-autojoin-channels-alist" is set to nil. i.e. the frame in which I launched "erc-tls" opens the erc window instead of occupying the current frame. But when I have few channels in "erc-autojoin-channels-alist" then the channels are still openning in the current frame instead of the dedicated frame that I started for "erc-tls". Is there some setting that I missed in the conversation for this? My current "erc" related settings are: --8<---------------cut here---------------start------------->8--- (setq erc-prompt-for-password nil erc-prompt (lambda () (concat "[" (buffer-name) "]"))) (eval-when-compile (require 'erc-services)) (setq erc-prompt-for-nickserv-password nil erc-use-auth-source-for-nickserv-password t) (setq erc-server "irc.libera.chat") (setq erc-port 6697) (setq erc-nick "my-nick") (setq erc-user-full-name "My Full Name") (eval-when-compile (require 'erc-join)) (setq erc-autojoin-channels-alist '(("libera.chat" "#emacs" "#erc" "#gnus"))) --8<---------------cut here---------------end--------------->8--- From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Sep 2022 06:24:03 +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 moreinfo To: Pankaj Jangid Cc: 55540@debbugs.gnu.org, Lars Ingebrigtsen , emacs-erc@gnu.org, 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.166382778528133 (code B ref 51753); Thu, 22 Sep 2022 06:24:03 +0000 Received: (at 51753) by debbugs.gnu.org; 22 Sep 2022 06:23:05 +0000 Received: from localhost ([127.0.0.1]:35929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obFc0-0007Jg-MO for submit@debbugs.gnu.org; Thu, 22 Sep 2022 02:23:05 -0400 Received: from mail-108-mta30.mxroute.com ([136.175.108.30]:35957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obFby-0007Ir-DA for 51753@debbugs.gnu.org; Thu, 22 Sep 2022 02:23:02 -0400 Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta30.mxroute.com (ZoneMTA) with ESMTPSA id 18363dd0c690002b7a.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 22 Sep 2022 06:22:54 +0000 X-Zone-Loop: 8fe811b9acdda1d3da7100b037493c67c7205a3a9a61 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=JuUNziPiWXY0xJRYnX68TPsuBUWYwOxg//vRiv+NDIg=; b=jE72GN+c7KXCcbye5azHxEYtDJ le1xGinyqxpfREJTseA0x5xBszYjJ1mqyENpJjyGlyx0Rn36AXistj7hIW4FnWhD11LqMoWkrqruq /OAgB+tA2bVrOwTwow1xkyZnXPDo+v/xf3snNdzxcZVFAqlnWPlrRttiIzymZ+w+RN51NMelCdUit 6xCtsKHrT1NKfusR2uJqBAnyEslZnDbXBzgFzlA/sUsa8mySEfD3Qj1TOB1BrbZF62iE9tvBFqKWI 6ogevQ5xqnvuAqpJ+XFumoq18bU7EAjVCuO1w71Vat5ZX3f6PeWvUa1gtdoALtcdzh4ouDuiBQf/s 3B161GhQ==; From: "J.P." In-Reply-To: <87y1uc150p.fsf@codeisgreat.org> (Pankaj Jangid's message of "Thu, 22 Sep 2022 08:37:02 +0530") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> <87y1uwr47b.fsf@gnus.org> <874jxj282o.fsf@neverwas.me> <87mtbbmjho.fsf@gnus.org> <87pmfq198w.fsf@neverwas.me> <87y1uc150p.fsf@codeisgreat.org> Date: Wed, 21 Sep 2022 23:22:50 -0700 Message-ID: <877d1wgc79.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Pankaj, Pankaj Jangid writes: > Now the behaviour is acceptable when "erc-autojoin-channels-alist" is > set to nil. i.e. the frame in which I launched "erc-tls" opens the erc > window instead of occupying the current frame. Hm, right, but I think that was always the baseline behavior, no? If not, I wonder if the recent change to the default for `erc-join-buffer' somehow affected this. > But when I have few channels in "erc-autojoin-channels-alist" then the > channels are still openning in the current frame instead of the > dedicated frame that I started for "erc-tls". Is there some setting > that I missed in the conversation for this? Looks like it, but I should have re-summarized either way. So that's my bad. > (setq erc-prompt-for-nickserv-password nil > erc-use-auth-source-for-nickserv-password t) This is unrelated (so feel free to skip ahead), but are you sure auth-source is even being consulted here? I ask because `services' isn't a default module, and your snippet doesn't modify `erc-modules', AFAICT. Regardless, adding services to the repro mix at this point would only complicate matters, so please forget I said anything. I mean, if really necessary, you can just use Libera's server-password kludge while testing (everything will still be encrypted): (erc-tls :password "$myaccount:$mypass" ...) > [...] > (setq erc-autojoin-channels-alist > '(("libera.chat" "#emacs" "#erc" "#gnus"))) Ah, looks like we're missing (setq erc-join-buffer 'frame erc-auto-query 'frame erc-reuse-frames 'displayed) Also, you *did* apply the patch and rerun make (or at least delete the .elc), right?: https://lists.gnu.org/archive/html/emacs-erc/2022-08/txtAqY2ukHPun.txt (Yeah, those changes aren't on trunk.) Anyway, please let me know if something doesn't add up. Thanks, J.P. P.S. If you want, you can use the symbol `Libera.Chat' instead of the string "libera.chat" in `erc-autojoin-channels-alist'. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Apr 2023 23:26: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 moreinfo To: Pankaj Jangid Cc: 55540-done@debbugs.gnu.org, Lars Ingebrigtsen , emacs-erc@gnu.org, 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.168099633230786 (code B ref 51753); Sat, 08 Apr 2023 23:26:02 +0000 Received: (at 51753) by debbugs.gnu.org; 8 Apr 2023 23:25:32 +0000 Received: from localhost ([127.0.0.1]:59863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plHw0-00080Q-Tk for submit@debbugs.gnu.org; Sat, 08 Apr 2023 19:25:32 -0400 Received: from mail-108-mta209.mxroute.com ([136.175.108.209]:32925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plHvw-0007zw-H7 for 51753@debbugs.gnu.org; Sat, 08 Apr 2023 19:25:25 -0400 Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta209.mxroute.com (ZoneMTA) with ESMTPSA id 18763303c41000edb4.002 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sat, 08 Apr 2023 23:25:18 +0000 X-Zone-Loop: 2a3cd4db81b66dcdf104917bda6c1135e192ef225cab 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=+ji4SvNalvsXRJSNyyxPLyoiscdmkfJIr87VBIhUUAQ=; b=lJYL+/VY1tdAMsvsDIh0Xiemct 3wPuSueaqDPd8gJ7KhdDU3eLEhpAghYjYU5RNZcAObhqHlYoGkEQVhPihvEpSvXB272IklvENomRZ HxRu7u2bmoXsUR9n2EcBc3SnN4FH56LDkEKFtaMSEFYeqy6qtfkp5BkctkZK5kbt0RV/QJa5TcHb9 8GCyeYKS1eVz0LhRuD9ByVKNLHWY+CceNOSrlreGjWjBxqRMXqiaFnlFkClAi18Xaja5wPlprjwcy FFVrbadfCe4C8UUXSOOxHn9hZ42w8fob10Ab6e+nVjdW24AFsqV0BRU8ZAeEPEDvs2fnPocQkstrf zLrJ8/kw==; From: "J.P." In-Reply-To: <877d1wgc79.fsf@neverwas.me> (J. P.'s message of "Wed, 21 Sep 2022 23:22:50 -0700") References: <878rqwjqua.fsf@codeisgreat.org> <87a6b92ers.fsf@neverwas.me> <875ylxm07b.fsf@codeisgreat.org> <87fsl0zo2e.fsf@neverwas.me> <87a68cnss7.fsf_-_@neverwas.me> <87sfm3tro1.fsf@codeisgreat.org> <87o7vsu5pc.fsf_-_@gnus.org> <87o7vs38yp.fsf@neverwas.me> <87y1uwr47b.fsf@gnus.org> <874jxj282o.fsf@neverwas.me> <87mtbbmjho.fsf@gnus.org> <87pmfq198w.fsf@neverwas.me> <87y1uc150p.fsf@codeisgreat.org> <877d1wgc79.fsf@neverwas.me> Date: Sat, 08 Apr 2023 16:25:13 -0700 Message-ID: <877cum2bza.fsf_-_@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) I've added a version of the frames patch as well as an option to control buffer-display behavior for interactive entry-point invocations. https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0e4c07dc https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3a012d1d Thanks and closing. From unknown Sun Jun 22 11:41:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51753: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 14:13:01 +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 moreinfo To: 51753@debbugs.gnu.org Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.168148152517928 (code B ref 51753); Fri, 14 Apr 2023 14:13:01 +0000 Received: (at 51753) by debbugs.gnu.org; 14 Apr 2023 14:12:05 +0000 Received: from localhost ([127.0.0.1]:47208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnK9k-0004f6-Ox for submit@debbugs.gnu.org; Fri, 14 Apr 2023 10:12:04 -0400 Received: from mail-108-mta34.mxroute.com ([136.175.108.34]:43187) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnK9j-0004ea-2S for 51753@debbugs.gnu.org; Fri, 14 Apr 2023 10:12:03 -0400 Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta34.mxroute.com (ZoneMTA) with ESMTPSA id 187801bb9ef000becb.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 14 Apr 2023 14:11:53 +0000 X-Zone-Loop: 58250c0f0cdc0b80ccc227ac1c7a1cf1f283291dc379 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:To:From:Sender:Reply-To:Cc: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=3YkQ8oMG+Tf8j9kWRpPCe3d8Af2X8FH6A7/bUUHYx+w=; b=nkB9sNBRncA92w3rx2mwuCt7eI d/JTbBNd7bRxBpbAFilKg8Azc/3z3TAgDHzlxk+/T9aycjJ8nNBsze0dqX5vw45hzg8yrgh0XhyYf boGtjBLUBu2cRgygKkopZxSWgllSNB8C31u23TwgI8LiX4nqiYG5we8A+BXMpT1L6iyw89iBsdV+S Kwx/I8Lxd6Z3i4DjqhZqI/DTXbKMq3iR11sVphMfRqbeXrbVF3iEdEgA+AWpsfbZdjZKqaZP1/KWe 7634W9iZOhK2uz/Zr4zCE9jRohZYcuIpO/Vz5fsXFEqNip+L0sZC5/4OTat/TgAD6NLad8cxvTNuh b09SBlXQ==; From: "J.P." In-Reply-To: (Stefan Kangas's message of "Wed, 10 Nov 2021 07:09:24 -0800") References: Date: Fri, 14 Apr 2023 07:11:49 -0700 Message-ID: <87cz46wo2i.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Just a breadcrumb for posterity: I've opened a related bug that picks up where this one left off: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior