pdf-view-roll-minor-mode corrupts overlays (including highlight overlays)

[haji-ali]

Describe the bug
One of the many issues that are seemingly fixed on @aikrahguzar fork, but not here, is that the overlays at position with window property get clobbered by pdf-roll.

Steps to Reproduce the behaviour
Tested on emacs 31.0.50

1. Open a pdf
2. Enable pdf-view-roll-minor-mode
3. Select any text and scroll window with mouse scroll.
4. Navigate to another buffer in the same window
5. Select any text and see that the pdf image now appears in this unrelated buffer.

Additional context
The issue is that pdf-roll-display-image sets the display property of all overlays in position to the pdf image. What this means is that the highlight overlay at position (which happens to have the window property) also has its display property set to the pdf image. This overlay is window specific (being set in redisplay--update-region-highlight) and navigating to another buffer displays the same overlay with the pdf image.

I can see that the code is changed in the child-frame-preview fork to also condition on a cateogry being pdf-roll or similar (this is standard practice to avoid modifying unintended overlays).
Until this fix is merged, the pdf-roll remains unusable and very distruptive.

[aikrahguzar]

This was a bug that I fixed sometime ago. The problem was that pdf-roll used to find the first overlay with the window property eq to the window we were interested in. Sometimes this overlay would end up being the one used by the region highlighting machinery.

[aikrahguzar]

The commit that fixed this is: 9152f1c

[haji-ali]

Hopefully the bug fixes will be merged soon.

I also noticed another issue that I am still debugging. After using pdf-view-roll-minor-mode, sometimes redisplaying during input is disabled in my emacs (in the sense that when I keep pressing a key in a buffer like A, nothing is displayed until I release the key and only then the text AAAAAAA is inserted and displayed in the buffer).

I am still trying to reproduce/debug this issue, but I wanted to check if this is a known bug that was fixed.

[aikrahguzar]

Hopefully the bug fixes will be merged soon.

I also noticed another issue that I am still debugging. After using pdf-view-roll-minor-mode, sometimes redisplaying during input is disabled in my emacs (in the sense that when I keep pressing a key in a buffer like A, nothing is displayed until I release the key and only then the text AAAAAAA is inserted and displayed in the buffer).

I am still trying to reproduce/debug this issue, but I wanted to check if this is a known bug that was fixed.

I have not noticed this and this issue hasn't been reported before. I am not even sure how can we even cause this. The only place inhibit-redisplay is used in the whole of pdf-tools is in pdf-outline-display-link (I am not sure why that is needed).

Does this happen when a pdf buffer is displayed in another window? We do add a function to pre-redisplay-functions buffer locally. It should only be called when a buffer is being displayed and does very little work unless something in the pdf buffer or window has changed. So if the input is being buffered somehow due to slow redisplay the problem should be most severe when the pdf is being scrolled.

[HiTuX]

I noticed that something may be related to this report when hl-line-mode is enabled.

To reproduce:

1. Open a PDF and enable pdf-view-roll-minor-mode.
2. Enable hl-line-mode if it is not enabled globally.
3. Scroll with the mouse.

Disabling hl-line-mode fixes the display. However, if I select text in the PDF and then scroll with the mouse, the display becomes corrupted again, even after hl-line-mode is disabled.

[aikrahguzar]

@HiTuX, I think this is another manifestation of the same bug and should be fixed in #338. If you can please try it and report back.