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#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior Date: Sun, 04 Jun 2023 14:36:21 -0700 Message-ID: <87r0qq7vvu.fsf__40933.4850542777$1685914658$gmane$org@neverwas.me> References: <87leiuy3cv.fsf@neverwas.me> <877csje0uz.fsf@neverwas.me> <837csj5jsh.fsf@gnu.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="15430"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, 62833@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 04 23:37:29 2023 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 1q5vPk-0003mT-Jx for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Jun 2023 23:37:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q5vPM-0005jI-RW; Sun, 04 Jun 2023 17:37:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5vPK-0005hb-Vy for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2023 17:37:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q5vPK-000480-NX for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2023 17:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q5vPJ-0007NF-Vq for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2023 17:37: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: Sun, 04 Jun 2023 21:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62833 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 62833-submit@debbugs.gnu.org id=B62833.168591459628303 (code B ref 62833); Sun, 04 Jun 2023 21:37:01 +0000 Original-Received: (at 62833) by debbugs.gnu.org; 4 Jun 2023 21:36:36 +0000 Original-Received: from localhost ([127.0.0.1]:47511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5vOu-0007MR-29 for submit@debbugs.gnu.org; Sun, 04 Jun 2023 17:36:36 -0400 Original-Received: from mail-108-mta177.mxroute.com ([136.175.108.177]:32977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5vOr-0007MD-IQ for 62833@debbugs.gnu.org; Sun, 04 Jun 2023 17:36:35 -0400 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta177.mxroute.com (ZoneMTA) with ESMTPSA id 1888857125900074ee.001 for <62833@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sun, 04 Jun 2023 21:36:27 +0000 X-Zone-Loop: 33bf30138cad7bbd1b3a8eeed9c91060823fd7420d15 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=TAN31W/64RqM3Q9hBtm2eSTLoRD9AL+CfWYYUmkeJpI=; b=OFgUjqScqpJaySIOFz2QVQn704 bnR3e7hgRfcPGGmmMSQFun2wUulsXkAcfS+KiZc1yTRfzXks7LukVt/miKRO4ZaYTG6QfeJ3Gp2ns LtXn73GGlfHeYEVhxM7VYqqruUF9oRLgxgKAhsKABJEDIZHBKCqv31k9OuS2PXsgA2Tsss87T1H9X T0jk1DQkYeZQpxVDehgF1+Wsf4SqYt8HhMVSGGJg/a1SbDw50pDrSQaInDBuZpkYwg0f2SxKEDPyb a6JEwTV9SQhjnlbYwabUivlEqFuDgeiOQK0sdamnbHiUFwhuX53XV+D+/Ltg8/vN0eH+rntkQryX2 lQkGzqdg==; In-Reply-To: <837csj5jsh.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 04 Jun 2023 18:28:14 +0300") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262988 Archived-At: Eli Zaretskii writes: >> From: "J.P." >> Cc: emacs-erc@gnu.org, 62833@debbugs.gnu.org >> Date: Sun, 04 Jun 2023 07:52:20 -0700 >> >> The solution to all this isn't straightforward, and we're making headway >> on it for ERC 5.6. In the meantime, I'm wondering if we might consider >> appeasing these disgruntled users somehow. Normally, I'd prefer just >> reverting back to `buffer', but because much has been made about its >> potential for causing mayhem via unintended sharing, I'm thinking we >> might change the default in Emacs 29 to `window-noselect'. This value >> tells ERC to show new buffers in a sibling window of the same vertical >> combination. > > I don't use ERC, but how does it make sense to change the default so > close to a release? Doing this is not without risk, but if it's any consolation, it's perhaps somewhat less fraught given that `window-noselect' has always been the default for `erc-auto-query', whose value is bound to `erc-join-buffer' when displaying direct private messages. Since these are not uncommon, we at least know that in one specific context, this display style has stood the test of time. > I could understand reverting back to 'buffer', which was used for a > long time, but switching to a new default that had no real testing > period? Are you absolutely sure this is a good idea? There are no good ideas here, and I'd say it's a wash between `buffer' and `window-noselect' depending on whose priorities we're intent on favoring. I'd feel better about going back to `buffer' if those who advocated for dropping it in bug#51753 would be willing to concede that user feedback has proven that solution insufficient. > And on top of that, change it only for Emacs 29? Yes only for Emacs 29. This problem doesn't exist in Emacs 30. In the end, this issue probably isn't worth much more of anyone's time. Come late July-ish, we'll hopefully have ERC 5.6 out the door and can just redirect folks there. And until then, this brief email exchange should prove useful enough in fending off any related FUD on IRC. To others listening in, I can only reiterate that this, along with other 20yr old UX bugs addressed in ERC 5.6 have been a major distraction that I should have, in retrospect, had the wherewithal to ignore in lieu of focusing on ERC's more existential problems, which I've been belaboring for the better part of three years. The most pressing of these is, of course, the adoption of essential protocol extensions, without which ERC will not long survive.