From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Thu, 13 May 2021 11:54:37 +0000 Message-ID: References: <83fsyu57oj.fsf@gnu.org> <838s4l5uld.fsf@gnu.org> <83zgx14cal.fsf@gnu.org> <83cztx3v04.fsf@gnu.org> <37291ae0-11cb-c817-cf26-b90ad50bfaaa@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29974"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alex.bennee@linaro.org, 48337@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 13 13:55:16 2021 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 1lh9vv-0007ec-Je for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 May 2021 13:55:15 +0200 Original-Received: from localhost ([::1]:44592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lh9vu-0001KT-L0 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 May 2021 07:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lh9vi-0001Gl-Hh for bug-gnu-emacs@gnu.org; Thu, 13 May 2021 07:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lh9vi-0003Pe-AY for bug-gnu-emacs@gnu.org; Thu, 13 May 2021 07:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lh9vi-0002LT-9w for bug-gnu-emacs@gnu.org; Thu, 13 May 2021 07:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 May 2021 11:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48337 X-GNU-PR-Package: emacs Original-Received: via spool by 48337-submit@debbugs.gnu.org id=B48337.16209068878985 (code B ref 48337); Thu, 13 May 2021 11:55:02 +0000 Original-Received: (at 48337) by debbugs.gnu.org; 13 May 2021 11:54:47 +0000 Original-Received: from localhost ([127.0.0.1]:41536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lh9vT-0002Kr-F1 for submit@debbugs.gnu.org; Thu, 13 May 2021 07:54:47 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:56888 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lh9vQ-0002KC-66 for 48337@debbugs.gnu.org; Thu, 13 May 2021 07:54:44 -0400 Original-Received: (qmail 87426 invoked by uid 3782); 13 May 2021 11:54:38 -0000 Original-Received: from acm.muc.de (p4fe15ecf.dip0.t-ipconnect.de [79.225.94.207]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 13 May 2021 13:54:37 +0200 Original-Received: (qmail 10455 invoked by uid 1000); 13 May 2021 11:54:37 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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" Xref: news.gmane.io gmane.emacs.bugs:206430 Archived-At: Hello again, Martin. On Thu, May 13, 2021 at 09:52:19 +0000, Alan Mackenzie wrote: > On Thu, May 13, 2021 at 09:54:52 +0200, martin rudalics wrote: > > > The deeper cause of the bug is that calling buffer-list-update-hook > > > simply doesn't belong in record-window-buffer. That hook should be > > > called when the buffer list changes, not when a window's current buffer > > > gets "recorded". > > > So, as the main fix, I propose moving the call of buffer-list-update-hook > > > to (some of) the places where record-window-buffer gets called, those > > > places where the buffer list changes. There are exactly two such places, > > > both in window.c. This will prevent the chain of events in read_minibuf > > > outlined above. > > Alan, please take one step back and reconsider. IIUC you added the > > `record-window-buffer' call to read_minibuf, added the DO-MINIBUF > > argument to `record-window-buffer' and now decide that > > `buffer-list-update-hook' doesn't belong into `record-window-buffer'. > > Aren't you putting the cart before the horse? That decision might be > > correct but still constitutes a change that affects all applications > > running `buffer-list-update-hook'. > Maybe you're right. I've never really liked those changes to > record-window-buffer, they're a bit scruffy. The requirement is simply > to push a minibuffer onto w->prev_buffers, where w is the mini-window of > a frame. > Maybe I should instead undo those changes to r-w-b, and write a separate > function for pushing the minibuffer onto w->prev_buffers. This would > surely be cleaner. Whether that function should be in C or in Lisp > (like record-window-buffer) would need to be decided. Maybe r-w-b could > use that new function to avoid duplicating code. How about the following functions, in which minibuf.c now bypasses record-window-buffer, instead calling push-window-buffer-onto-prev direct? I'm still not convinced that the call to buffer-list-update-hooks belongs in record-window-buffer, but that doesn't seem too important any more. On preliminary testing, these appear to work: (defun push-window-buffer-onto-prev (&optional window) "Push entry for WINDOW's buffer onto WINDOW's prev-buffers list. WINDOW must be a live window and defaults to the selected one. Any duplicate entries for the buffer in the list are removed." (let* ((window (window-normalize-window window t)) (buffer (window-buffer window)) (w-list (window-prev-buffers window)) (entry (assq buffer w-list))) (when entry (setq w-list (assq-delete-all buffer w-list))) (let ((start (window-start window)) (point (window-point window))) (setq entry (cons buffer (if entry ;; We have an entry, update marker position. (list (set-marker (nth 1 entry) start) (set-marker (nth 2 entry) point)) (list (copy-marker start) (copy-marker ;; Preserve window-point-insertion-type ;; (Bug#12855) point (with-current-buffer buffer window-point-insertion-type)))))) (set-window-prev-buffers window (cons entry w-list))))) (defun record-window-buffer (&optional window) "Record WINDOW's buffer. WINDOW must be a live window and defaults to the selected one. If WINDOW is a minibuffer, it will only be recorded if DO-MINIBUF is non-nil." (let* ((window (window-normalize-window window t)) (buffer (window-buffer window))) ;; Reset WINDOW's next buffers. If needed, they are resurrected by ;; `switch-to-prev-buffer' and `switch-to-next-buffer'. (set-window-next-buffers window nil) ;; Don't record insignificant buffers. (when (not (eq (aref (buffer-name buffer) 0) ?\s)) (push-window-buffer-onto-prev window) (run-hooks 'buffer-list-update-hook)))) > > martin -- Alan Mackenzie (Nuremberg, Germany).