GNU bug report logs - #32790
27.0.50; point jumps unexpectedly after delete-window

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Thu, 20 Sep 2018 23:57:01 UTC

Severity: minor

Found in version 27.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


Message #356 received at 32790 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 32790 <at> debbugs.gnu.org
Subject: Re: bug#32790: 27.0.50; point jumps unexpectedly after delete-window
Date: Sun, 02 Dec 2018 00:43:01 +0200
>>      ((window-minibuffer-p)
>>       (if force-same-window
>>           (user-error "Cannot switch buffers in minibuffer window")
>>         (pop-to-buffer buffer norecord)))
>>      ((eq (window-dedicated-p) t)
>>       (if force-same-window
>>           (user-error "Cannot switch buffers in a dedicated window")
>>         (pop-to-buffer buffer norecord)))
>
> These ones stupefied me when I tried to study your patch yesterday.
> When 'switch-to-buffer-obey-display-actions' is non-nil you do not
> reset 'force-same-window' so you can get an error when this is t and
> you're either in the minibuffer or the window is strongly dedicated.
> Right?

I don't understand how 'force-same-window' can be non-nil if there is
a condition "unless switch-to-buffer-obey-display-actions" in the
interactive spec.  But if some code calls 'switch-to-buffer'
non-interactively with non-nil 'force-same-window', should it
signal an error when 'pop-to-buffer-same-window' displays the buffer
in another window?




This bug report was last modified 5 years and 235 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.