fix(pdf-roll): don't draw a page on Emacs's region overlay

[alberti42]

Fixes #345.

What happens

Open a PDF with pdf-view-roll-minor-mode, select some text in it, then show another buffer in that same window. From then on, selecting text in that buffer draws the PDF page over the selection.

1. Open a PDF and enable pdf-view-roll-minor-mode.
2. Select text in the PDF with the mouse. (pdf-view-mouse-set-region calls pdf-view--push-mark, so the region really is active in the document.)
3. Show another buffer in that window.
4. Select text there.

Why

pdf-roll finds the overlay that holds a page like this:

(cl-find window (overlays-at pos) :key (lambda (ov) (overlay-get ov 'window)))

Emacs puts that same window property on the overlay it highlights the region with (redisplay--highlight-overlay-function in simple.el). A pdf-roll buffer has four positions per page, so when the region is active in the document that overlay can sit right at a page position. pdf-roll-display-image then draws the page on it.

The overlay sits in the PDF buffer, but the window is what holds on to it: Emacs keeps it in the window parameter internal-region-overlay and reuses the same one for the next region, by then possibly in another buffer. It simply moves the overlay there, page image and all. Deactivating the region does not help, because Emacs only deletes the overlay and later brings it back with move-overlay.

I checked this in a running session. The overlay sitting over my selection in an unrelated buffer was eq to that window's internal-region-overlay. It carried face region and priority (nil . 100) from Emacs, display (a rendered page) and line-prefix from pdf-roll-display-image, and no category.

The fix

Pass the category to the lookup, so only overlays pdf-roll made can match. pdf-roll-new-window-function had the same problem: when a second window opened on the PDF, it copied whatever overlay it found at the page position.

How this relates to #338

@aikrahguzar diagnosed this bug in #345 and wrote the same category fix in 45b9cc0, before I ran into it. That fix is already part of #338, along with the other pdf-roll fixes on that branch.

The difference between the two pull requests is scope. #338 fixes several pdf-roll bugs, but it also adds features — a child frame preview for links, an isearch preview command, bookmark and slicing work — roughly 1300 added lines across 9 files. A branch that size naturally takes longer to review, and it has been open since January. This pull request changes the overlay lookup and nothing else: two functions, plus tests.

It is your call: if reviewing #338 is going to take a while, merging this one first fixes #345 on master in the meantime, and costs #338 very little afterwards. I deliberately followed @aikrahguzar's approach, so the lookup itself should merge cleanly with their branch. The one spot that will conflict is pdf-roll-new-window-function, which 9152f1c rewrites anyway. There their version should simply win.

Tests

Three tests in test/pdf-roll-test.el. Two of them check the lookup against a stand-in for Emacs's region overlay, in both creation orders, since overlays-at does not promise an order. make test passes, and the two lookup tests fail with the old code. No new byte-compile warnings.