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: Sat, 13 May 2023 07:03:46 -0700 Message-ID: <87sfc08h19.fsf__6629.10610424063$1683986660$gmane$org@neverwas.me> References: <87leiuy3cv.fsf@neverwas.me> <87jzxie9yf.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17942"; 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: Corwin Brust Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 13 16:04:12 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 1pxpr1-0004S3-U7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 May 2023 16:04:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pxpqt-00009e-Sc; Sat, 13 May 2023 10:04:03 -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 1pxpqs-00009G-Hd for bug-gnu-emacs@gnu.org; Sat, 13 May 2023 10:04:02 -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 1pxpqs-0006eC-9P for bug-gnu-emacs@gnu.org; Sat, 13 May 2023 10:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pxpqs-0005WF-4N for bug-gnu-emacs@gnu.org; Sat, 13 May 2023 10:04: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: Sat, 13 May 2023 14:04: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.168398663921205 (code B ref 62833); Sat, 13 May 2023 14:04:02 +0000 Original-Received: (at 62833) by debbugs.gnu.org; 13 May 2023 14:03:59 +0000 Original-Received: from localhost ([127.0.0.1]:39203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxpqo-0005Vx-FK for submit@debbugs.gnu.org; Sat, 13 May 2023 10:03:58 -0400 Original-Received: from mail-108-mta49.mxroute.com ([136.175.108.49]:33607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxpqm-0005Ve-87 for 62833@debbugs.gnu.org; Sat, 13 May 2023 10:03:56 -0400 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta49.mxroute.com (ZoneMTA) with ESMTPSA id 188156cc44e000e27e.002 for <62833@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sat, 13 May 2023 14:03:49 +0000 X-Zone-Loop: d00f8e8f354248dd5cc976f46154cd569ccf141d3ec0 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=9Nko5YaDNxFK0EChDoLEqpRoQl18SKG0uOyHW+9DCUA=; b=mHcQY01ZE5pdTDUMhV/+UCNdyP dQfQaBdpxYEH9ZhlesVMe8v0zDssvzz+Cl9CThaPJPvH4f2HO8RpLPlmqvgkgmyTKALLAYG/iozlO ZW+1aPMRonF4mNm3pFTxBnXdN5NkTzwV/dNj067wza1eMxxJ9iMbneoQuc76RooRXkZ3uqc1bL3Zv NXtVow5A5ecs6YpeEOg6zB1ZdKDfkItyMcnh0THZG3RJ7hDzV7wXNei7sDEMYMQyCa/WDGzsymfuS dRroAZGwk18U3Y5DW3KHLaS6uEiDomBUoJE2u81BvhLZo3IVplkpQ9lPrEhkH9ZfABw5PeI7Bxi8l Isq35eGA==; In-Reply-To: (Corwin Brust's message of "Wed, 10 May 2023 16:43:42 -0500") 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:261684 Archived-At: Corwin Brust writes: >> 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)" I guess I could have tried grouping these into user-initiated and non-, but it seems to me the first item, `erc-tls', can go either way. While your example, which presumably calls `erc-tls' at some point, clearly falls into the user-initiated camp, the same might not be said, for example, of running `erc-tls' whenever Emacs receives a specific message over DBus. So because detecting a user's intent isn't foolproof (not only with 1, but in general), we may want to extend the existing display options by offering some sort of universal escape hatch that affords more granular control. However, doing this alone won't cover the problem of communicating to each user-implemented instance of such an escape hatch the necessary specifics about the context in which Emacs' display machinery is being summoned. And I don't think switching away from the one-to-many arrangement we have now to a single option per context is doable because of the first problem of accurately detecting intent. So, as a compromise, I'm thinking we could extend all existing options to accommodate arbitrary "action" forms, which we'd then pass along to a new `display-buffer' call (in `erc-setup-buffer') before trusting and selecting whatever window it spits out. The point would be to supplement user-supplied "action alists" with extra contextual data to indicate things like the last slash command invoked. (Alternatively, we could relay the same info via global erc-* variables; doesn't matter to me.) However, even this wouldn't be a panacea. A user would still need to apply some extra elbow grease for things like your `my-connect-fun' or my DBus example, possibly by doing something like (let ((erc-join-buffer '(my-use-dedicated-frame (inhibit-same-window . t)))) (erc-tls :server ...)) which doesn't seem all that painful. Although, at that point, why not just do (display-buffer (let ((erc-join-buffer 'bury)) (erc-tls :server ...)) '(my-use-dedicated-frame (inhibit-same-window . t))) which has always been possible and is no more complicated? >> 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 was >> 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 ;) That's my sense as well. >> 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. Just to recap, here are the default values of `erc-join-buffer' (now also aliased to `erc-buffer-display' on HEAD): 5.4 - buffer 5.5 - bury 5.5.1.29.1 - window-noselect (proposed) 5.6 - bury (repurposed as a catch-all) In the last one, "catch-all" not only means it's overridden by other options, which has always been the case, but that contexts formerly within its domain, like M-x erc and "/JOIN", are now determined elsewhere, such as by `erc-interactive-display' (currently `window'). (BTW, "/RECONNECT" currently isn't covered by the latter, but that could change if folks want.) > 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. I suppose it couldn't hurt to get a patch going for "5.5.1.29.1", just to have something on standby. > Really appreciate your work on this JP Very kind, thanks.