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: Thu, 28 Jan 2021 02:23:46 +0300 Message-ID: <87ft2mhsl9.fsf@gkayaalp.com> References: 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="18533"; 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 Thu Jan 28 00:28:46 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 1l4uEv-0004it-Ls for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Jan 2021 00:28:45 +0100 Original-Received: from localhost ([::1]:36664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l4uEu-0007gE-Li for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Jan 2021 18:28:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l4uAE-0003kh-Vd for emacs-devel@gnu.org; Wed, 27 Jan 2021 18:23:54 -0500 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:54533) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l4uAC-0006Nv-SM; Wed, 27 Jan 2021 18:23:54 -0500 X-Originating-IP: 46.2.235.191 Original-Received: from localhost (unknown [46.2.235.191]) (Authenticated sender: self@gkayaalp.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id BFF75C0002; Wed, 27 Jan 2021 23:23:47 +0000 (UTC) In-Reply-To: (message from martin rudalics on Wed, 20 Jan 2021 17:51:22 +0100) Received-SPF: none client-ip=217.70.183.198; envelope-from=self@gkayaalp.com; helo=relay6-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_H2=-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:263522 Archived-At: On 2021-01-20 17:51 +01, martin rudalics wrote: > So I suggest you put a 'display-buffer-reuse-window' at the beginning of > 'gk-display-buffer-for-rmail' and test how it behaves then. Thanks for the suggestion. I tried to add it to the logic using an if-let*, and I made sure the function returned a window, but I could not improve the situation. I then tried to just skip dealing with the situation where there=E2=80=99s only a single window: (setq display-buffer-alist '(((lambda (b _) (and (not (one-window-p)) ;; also: ;; (memq (with-current-buffer b major-mode) ;; '(rmail-mode rmail-summary-mode))) (eq (with-current-buffer b major-mode) 'rmail-mode))) . ((lambda (buffer _) (split-window-vertically (/ (window-height) 4)) ;; Select the buffer. (switch-to-buffer buffer) ;; Return the current window. (selected-window)))))) but still got the same behaviour. I think this has something to do with the following lines in rmailsum.el, in the definition of =E2=80=98rmail-new-summary=E2=80=99: ;; If pop-to-buffer did not use that window, delete that ;; window. (This can happen if it uses another frame.) (if (not (eq sumbuf (window-buffer (frame-first-window)))) (delete-other-windows))) Here the condition is for some reason true somewhere in the call chain, and I don=E2=80=99t really understand. I think I=E2=80=99ll give up on this as what Rmail does with buffers in intermediary steps of a command is fairly complex, and Rmail has many assumptions about what=E2=80=99s where when. Maybe later I=E2=80=99ll try = make Rmail call pop-to-buffer no more than strictly necessary. Till then I=E2=80=99ll= give it it=E2=80=99s own frame and call it a day :) Again, thanks for bearing with me! Best, -gk.