From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#55540: 29.0.50; ERC launches autojoin-channels in current frame instead of original frame Date: Tue, 06 Sep 2022 06:53:34 -0700 Message-ID: <87o7vs38yp.fsf__12197.231785261$1662472693$gmane$org@neverwas.me> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9152"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 55540@debbugs.gnu.org, 51753@debbugs.gnu.org, emacs-erc@gnu.org, Pankaj Jangid To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 06 15:58:07 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVZ5a-0002Bs-1P for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Sep 2022 15:58:06 +0200 Original-Received: from localhost ([::1]:44740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oVZ5Y-00036g-Vb for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Sep 2022 09:58:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43642) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVZ1g-0004Cj-LD for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2022 09:54:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33284) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oVZ1e-0004X5-Mg for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2022 09:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oVZ1e-00010S-FL for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2022 09:54:02 -0400 X-Loop: help-debbugs@gnu.org 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 55540 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo patch Original-Received: via spool by 55540-submit@debbugs.gnu.org id=B55540.16624724303834 (code B ref 55540); Tue, 06 Sep 2022 13:54:02 +0000 Original-Received: (at 55540) by debbugs.gnu.org; 6 Sep 2022 13:53:50 +0000 Original-Received: from localhost ([127.0.0.1]:50213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVZ1S-0000zi-0d for submit@debbugs.gnu.org; Tue, 06 Sep 2022 09:53:50 -0400 Original-Received: from mail-108-mta90.mxroute.com ([136.175.108.90]:42425) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVZ1P-0000zK-1P for 55540@debbugs.gnu.org; Tue, 06 Sep 2022 09:53:47 -0400 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] mail-111-mta2.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta90.mxroute.com (ZoneMTA) with ESMTPSA id 1831313f120000dd1a.003 for <55540@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 06 Sep 2022 13:53:37 +0000 X-Zone-Loop: ee00fe405e1be48862f851fd6b2a0825fe2b65b528f9 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==; In-Reply-To: <87o7vsu5pc.fsf_-_@gnus.org> (Lars Ingebrigtsen's message of "Tue, 06 Sep 2022 13:01:51 +0200") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241658 Archived-At: 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.