From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.bugs Subject: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior Date: Wed, 10 May 2023 16:43:42 -0500 Message-ID: References: <87leiuy3cv.fsf@neverwas.me> <87jzxie9yf.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28037"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-erc@gnu.org, 62833@debbugs.gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 10 23:45:40 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 1pwrcx-00077V-Cv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 May 2023 23:45:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pwrcf-0002cP-BB; Wed, 10 May 2023 17:45:21 -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 1pwrcc-0002bx-GI for bug-gnu-emacs@gnu.org; Wed, 10 May 2023 17:45:18 -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 1pwrcM-0002J0-J8 for bug-gnu-emacs@gnu.org; Wed, 10 May 2023 17:45:17 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pwrcM-0003bi-2K for bug-gnu-emacs@gnu.org; Wed, 10 May 2023 17:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Corwin Brust Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 May 2023 21:45:02 +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.168375504313785 (code B ref 62833); Wed, 10 May 2023 21:45:02 +0000 Original-Received: (at 62833) by debbugs.gnu.org; 10 May 2023 21:44:03 +0000 Original-Received: from localhost ([127.0.0.1]:49158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwrbO-0003aG-HF for submit@debbugs.gnu.org; Wed, 10 May 2023 17:44:02 -0400 Original-Received: from mail-oa1-f45.google.com ([209.85.160.45]:49283) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwrbK-0003Zc-RD for 62833@debbugs.gnu.org; Wed, 10 May 2023 17:44:01 -0400 Original-Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-19290ad942aso5942032fac.2 for <62833@debbugs.gnu.org>; Wed, 10 May 2023 14:43:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683755033; x=1686347033; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LqYsP9Xlki1Wf8Ec6mCZMIsGPbFjbzYWrLiTO+tzwOs=; b=HorOL3Pn17Pz8EK03YAqptUhGdGZwYtg7XVv5EOWPs4yZ2tD4ScsH4PiT9r6/PixEM Uwn/IF2sxYzG+kLtLhseQKQIBe44QOgZIoHfejKLggFIXCmNsNNQtxRGY3+Liwe4M3UP WLBdJg5etTxXMM2dAV5b6q5g2wDLq9K4HlLvu+kFg+e3BGflQoaypeAG1sgPK0ayWICG 9OhOakzU4f3bdNSIWv6GGXw7f/WpDa5B+aQpKAm43SEiOvta3Q5IPoxecg9MNkk7viEj 7qwJjZ8Qg70qLy58SbYEIxHQ2p1juQ7zj5GsSJS93ogAYQ0I88QouJgnrEFtrtljZQVq ndxg== X-Gm-Message-State: AC+VfDx2pfsO9yz14Z1ujFwBNPRRWhM9NHpj/+k02rmzmocqvQpxzX09 qbNWDQQRA0yydrViUYoHStPMudUHUaiSxAteTXA7rJn6 X-Google-Smtp-Source: ACHHUZ4JjlepvNJtx4OEn9rHPvDY3u4ipD6ths3s73zEtU1NcnKoqyG2AD2IM2Vng1iuHw47kulwKMQ/xPaX2t61Rmo= X-Received: by 2002:a05:6870:e351:b0:188:c684:5ca5 with SMTP id a17-20020a056870e35100b00188c6845ca5mr7762751oae.37.1683755033208; Wed, 10 May 2023 14:43:53 -0700 (PDT) In-Reply-To: <87jzxie9yf.fsf@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:261530 Archived-At: Thank you, JP. On Mon, May 8, 2023 at 5:26=E2=80=AFPM J.P. wrote: > > "J.P." writes: > > > The main focus will be those aspects impacting ERC 5.6 and how they > > integrate with the upstream display-buffer facility provided by > > window.el. In a sense, this is a spiritual successor to > > > > bug#51753: ERC switches to channel buffer on reconnect > > Complaints continue to trickle in regarding the option `erc-join-buffer' > and its new default of `bury'. To recap, bug#51753 led to changes [1] Please add me to the list of people who didn't much care for the new defaul= t. > that altered how buffers are displayed in various contexts, most > commonly: > > 1. (erc-tls :server ...) > 2. M-x erc-tls RET > 3. /JOIN #chan > 4. /RECONNECT > 5. automatically reconnect FWIW, I connect automatically on startup using a desktop shortcut running a command something like: emacs -f my-erc-init.el -eval "(my-connect-fun)" > > Basically, the attempted fix for 5 also affected the others, most of > which are triggered by user interaction and therefore ought to have been > exempt from any such nerfing (arguably). See, back before the change, a > new or reassociated buffer would simply replace the one in the selected > window. Now, in ERC 5.5 (Emacs 29), new buffers aren't displayed by > default, and the only confirmation that anything's happened (after, say, > invoking M-x erc-tls) is typically a blip in the mode-line. This lack of > feedback has confused new users and irritated existing ones. > > Thus, I'm thinking we ought to consider changing the default in Emacs 29 > to `window-noselect'. This is exactly what etc/ERC-NEWS currently > recommends for personal setups anyway [2], and the behavior it triggers w= as > newly redone in 5.5 to make good on its long advertised purpose, which > is to show the new buffer in some other window via the `display-buffer' FWIW, I'd prefer that to the present situation. My sense from chatter on IRC is that this probably matches others expectations also but perhaps someone who prefers the new and now current default setting of bury will weigh in here and dispell my confirmation bias ;) > action > > (nil (inhibit-same-window . t)) > > which, AFAIK, never results in that window being selected. If true, then > I believe `window-noselect' (at least, among the available choices) most > closely approximates what will hopefully become an improved user > experience in ERC 5.6. > > The main impediment I see to making such a change is that it would mean > yet a third default value for this option in as many years (or four, if > you count `bury' being forever baked into ERC 5.5 on ELPA). That's quite > a bit of whiplash, and it speaks to our being overly equivocal (not > untrue) if not wholly unprofessional (hopefully only possibly true). > There's also the lesser matter of the current behavior having been > somewhat suggested by an Emacs maintainer [3], which makes me less > inclined to pursue a fix unless folks upset enough by the issue voice > their concerns here on the tracker. I don't see an issue with multiple changes to a default within a short time, either within an ERC version or in several consecutive ones. Changing it each *Emacs* version seems more problematic, but I think that's not an issue (so far) in this case. So I think now is a very good time to make the change, and I'd like to see it happen. I hope other ERC users who feel strongly about this will weigh in. > > Thanks. > > > [1] commit 132d5cb0a3ec94afbb49772631861e00160ffffb > Author: F. Jason Park > Date: Tue Sep 6 19:09:54 2022 -0700 > > Bury new ERC buffers by default > > * lisp/erc/erc.el (erc-join-buffer): Change default value to `bury'. > [...] > (Bug#51753) > > etc/ERC-NEWS | 14 +++++++-- > lisp/erc/erc.el | 5 +-- > test/lisp/erc/erc-scenarios-base-reconnect.el | 45 ++++++++++++++----= --------- > 3 files changed, 37 insertions(+), 27 deletions(-) > > > [2] ** Changes to display options for new ERC buffers. > > The default value for the option 'erc-join-buffer', which determines > how new buffers are displayed, has been changed to 'bury' for > security reasons. Although the old value of 'buffer' is still > accessible, along with its original behavior, users wanting a safer > alternative can now opt for an improved 'window-noselect' instead. > It still offers the same pronounced visual cue when connecting and > joining but now avoids any hijacking of the active window as well. > > [3] https://lists.gnu.org/archive/html/emacs-erc/2022-09/msg00006.html > Really appreciate your work on this JP