From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?G=C3=B6ktu=C4=9F_Kayaalp?= Newsgroups: gmane.emacs.devel Subject: Re: Potential bug in the logic of rmail-select-summary Date: Wed, 20 Jan 2021 17:09:44 +0300 Message-ID: <87zh13wvh3.fsf@gkayaalp.com> References: <27bf2070-6c72-afb9-dbc8-c1855470123b@gmx.at> 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="15544"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 20 15:12:47 2021 Return-path: Envelope-to: ged-emacs-devel@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 1l2EE3-0003vu-Gy for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 15:12:47 +0100 Original-Received: from localhost ([::1]:35366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2EE2-0002mu-JJ for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 09:12:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2EBK-0001M8-0h for emacs-devel@gnu.org; Wed, 20 Jan 2021 09:09:58 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:36979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2EBG-0000XK-5o; Wed, 20 Jan 2021 09:09:57 -0500 X-Originating-IP: 46.2.229.137 Original-Received: from localhost (unknown [46.2.229.137]) (Authenticated sender: self@gkayaalp.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 3B4ECFF810; Wed, 20 Jan 2021 14:09:44 +0000 (UTC) In-Reply-To: <27bf2070-6c72-afb9-dbc8-c1855470123b@gmx.at> (message from martin rudalics on Tue, 19 Jan 2021 20:04:33 +0100) Received-SPF: none client-ip=217.70.183.199; envelope-from=self@gkayaalp.com; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263204 Archived-At: On 2021-01-19 20:04 +01, martin rudalics wrote: > >> AFAIU rmail-pop-to-buffer could use some form of display-buffer-* to > >> avoid going through display-buffer-alist. > An overriding action? That's much too severe. > > Yes, but I'm not sure we should prevent users from customizing the > > way Rmail buffers are displayed. > Rmail is free to do what it wants in this regard. But > > (".*" . (display-buffer-same-window)) > > is a much too strong customization IMO. It conflates 'pop-to-buffer' > with its standard "pop to a window other than the selected one even if > the buffer is already displayed in the selected window" behavior with > 'switch-to-buffer'. Don't do that - it may miss too many cases. Martin and Eli, thanks for your help and sorry for this non-issue. I had this problem for more than a couple years now, and I was having some problems with some Magit commands too, should=E2=80=99ve figured it out by = now. But also, it seems to me that how Rmail uses (rmail-)pop-to-buffer is somewhat problematic regardless because Rmail uses it as part of its logic sometimes and apparently that results in multiple calls to that function per command. I tested some configs and appended the results below, tho I=E2=80=99m again not sure if it=E2=80=99s expected behaviour or= some bug. Best, -gk. Appendix: Testing various configs with rmail-summary and display-buffer-ali= st. This config in emacs -Q results in a vertical split, both windows displaying the summary buffer, after hitting =E2=80=98h=E2=80=99 in an Rmai= l buffer: (setq display-buffer-alist '(((lambda (b _) (eq (with-current-buffer b major-mode) 'rmail-summary-mod= e)) . (display-buffer-below-selected)))) When I instead try this one: (setq display-buffer-alist '(((lambda (b _) (eq (with-current-buffer b major-mode) 'rmail-summary-mod= e)) . (display-buffer-at-bottom . ((inhibit-same-window . t)))))) (with or without the alist, summary buffer replaces the Rmail buffer. A more sophisticated config which is what I=E2=80=99d actually like to have behaves a bit more weirdly: (setq display-buffer-alist '(((lambda (b _) (eq (with-current-buffer b major-mode) 'rmail-summary-mod= e)) . (gk-display-buffer-for-rmail)))) (defun gk-display-buffer-for-rmail (buffer _) (if (=3D (length (window-list)) 1) (display-buffer-in-direction buffer '((direction . left))) ;; If there are 1+ windows, use the top quarter of selected ;; window. (split-window-vertically (/ (window-height) 4)) (switch-to-buffer buffer))) if I have a vertical split, this happens: [ some buffer ][ rmail ] -> [ some buffer ][ rmail-summary ] [ rmail-summary ] [ rmail ] instead of expected [ some buffer ][ rmail ] -> [ some buffer ][ rmail-summary ] [ rmail ] and if rmail window was the only window, I get [ rmail-summary ][ rmail-summary ] This is apparently because rmail-summary (and rmail-quit, too) end up calling rmail-pop-to-buffer multiple times, somehow. I verified that with calling toggle-debug-on-entry on the function: with rmail-summary I need to hit =E2=80=98c=E2=80=99 in the debugger 4 times for the command to = complete. I tried the following more elaborate setup: (require 'cl-lib) (setq display-buffer-alist '(((lambda (b _) (eq (with-current-buffer b major-mode) 'rmail-summary-mod= e)) . (gk-display-buffer-for-rmail)))) (defun gk-display-buffer-for-rmail (buffer _) ;; If the summary buffer is displayed, just go to it (if-let* ((sumw (car (cl-remove-if #'null (mapcar (lambda (w) (and (eq 'rmail-summary-mode (buffer-local-value 'major-mode = (window-buffer w))) w)) (window-list)))))) (select-window sumw) ;; Otherwise, if frame has only 1 window... (if (=3D (length (window-list)) 1) ;; (a) ...split it in two, otherwise... (split-window-horizontally (/ (window-width) 2)) ;; (b) ...create a 1/4 split above the selected window, ... (split-window-vertically (/ (window-height) 4))) ;; ...eventually, display =E2=80=98buffer=E2=80=99. (switch-to-buffer buffer))) This helps with the multiple summary windows problem, but while (b) case works as expected, (a) results in a single window displaying the summary buffer, which is weird. I thought what rmail-pop-to-buffer does has some effect here, but the following works fine: (let (split-width-threshold) (split-window-horizontally (/ (window-width) 2)))