PDF movement controls inoperative after windmove-swap-states-*

[Cerebus]

Describe the bug
Using windmove to swap a PDFView buffer into a different window in the frame causes

Steps to Reproduce the behaviour
Steps to reproduce the behaviour:

1. Split the frame vertically.
2. Open a PDF in the left buffer.
3. windmove-swap-states-right
4. Page forward and back
5. windmove-swap-states-left
6. Page forward and back.

What is the expected behaviour?
The buffer should behave normally after any windmove-swap.

Desktop
Please complete the following information:

• OS: macOS Tahoe
• Emacs Version: 30.2 (d12frosted)
• Poppler Version: 26.0.2

Your pdf-tools install
Please complete the following information:

• pdf-tools Version:

     Status: Installed in ‘pdf-tools-20260102.1101/’ (unsigned). Delete
    Version: 20260102.1101
     Commit: e4b7f1f37cf59ddf025d609ffcdabe732a6e99ba
    Summary: Support library for PDF documents.
   Requires: emacs-26.3, tablist-1.0, let-alist-1.0.4
    Website: https://github.com/vedang/pdf-tools/
   Keywords: files multimedia 
     Author: Andreas Politz <mail@andreas-politz.de>
Other versions: 20260102.1101 (melpa), 1.3.0 (nongnu).

• pdf-tools customization / configuration that you use

(use-package pdf-tools
  :ensure t
  :defer t
  :init
  (add-to-list 'auto-mode-alist '("\\.[Pp][Dd][Ff]\\'" . pdf-view-mode))
  :config
  (pdf-loader-install))

Additional context

• Sometimes movement still works after a single swap operation, but not after a second.
• Moving a PDFView buffer back to a window where movement previously worked will "fix" the problem, so this is possibly something about window parameters.

[aikrahguzar]

Does this still happen if you comment out everything from your init.el except for the pdf-tools configuration you posted?

[Cerebus]

Yes. emacs -Q and evaluate:

(add-to-list 'load-path "~/.emacs.d/elpa/pdf-tools-20260102.1101")
(require 'pdf-tools)
(add-to-list 'auto-mode-alist '("\\.[Pd][Dd][Ff]\\'" . pdf-view-mode))
(require 'windmove)

Then load a PDF and swap windows around.

[aikrahguzar]

Does this diff fix the issue:

diff --git a/lisp/pdf-view.el b/lisp/pdf-view.el
index b40f16f..7248a58 100644
--- a/lisp/pdf-view.el
+++ b/lisp/pdf-view.el
@@ -1339,12 +1339,12 @@ If WINDOW is t, redisplay pages in all windows."
       (setq ol (make-overlay (point-min) (point-max) nil t))
       (overlay-put ol 'pdf-view t))
     (overlay-put ol 'window (car winprops))
-    (unless (windowp (car winprops))
+    (if (windowp (car winprops))
+        (image-mode-window-put 'overlay ol winprops)
       ;; It's a pseudo entry.  Let's make sure it's not displayed (the
       ;; `window' property is only effective if its value is a window).
       (cl-assert (eq t (car winprops)))
       (delete-overlay ol))
-    (image-mode-window-put 'overlay ol winprops)
     ;; Clean up some overlays.
     (dolist (ov (overlays-in (point-min) (point-max)))
       (when (and (windowp (overlay-get ov 'window))

[Cerebus]

Does not appear to, no.

[aikrahguzar]

I don't still understand how it happens but the problem is that pdf-view-new-window-function gets called multiple times and each time a new overlay is created. So, now it up to Emacs to pick an overlay to get a display property and sometimes it doesn't pick the one in which we are displaying the page.

I am fairly confident that this diff will fix the problem:

diff --git a/lisp/pdf-view.el b/lisp/pdf-view.el
index b40f16f..0f8cf50 100644
--- a/lisp/pdf-view.el
+++ b/lisp/pdf-view.el
@@ -1332,19 +1332,17 @@ If WINDOW is t, redisplay pages in all windows."
                  (eq (window-buffer (car winprops)) (current-buffer))))
   (let ((ol (image-mode-window-get 'overlay winprops)))
     (if ol
-        (progn
-          (setq ol (copy-overlay ol))
-          ;; `ol' might actually be dead.
-          (move-overlay ol (point-min) (point-max)))
+        ;; `ol' might actually be dead.
+        (move-overlay ol (point-min) (point-max))
       (setq ol (make-overlay (point-min) (point-max) nil t))
       (overlay-put ol 'pdf-view t))
     (overlay-put ol 'window (car winprops))
-    (unless (windowp (car winprops))
+    (if (windowp (car winprops))
+        (image-mode-window-put 'overlay ol winprops)
       ;; It's a pseudo entry.  Let's make sure it's not displayed (the
       ;; `window' property is only effective if its value is a window).
       (cl-assert (eq t (car winprops)))
       (delete-overlay ol))
-    (image-mode-window-put 'overlay ol winprops)
     ;; Clean up some overlays.
     (dolist (ov (overlays-in (point-min) (point-max)))
       (when (and (windowp (overlay-get ov 'window))

In my cursory testing it didn't create a problem but I am not at all confident that this is going to hold: I have no idea why that copy-overlay that I have removed was needed.

[aikrahguzar]

@Cerebus did you try the second fix?