bug#13887: 24.3; doc-view will render blurry images when image-magick is available

[Tassilo Horn]

Eli Zaretskii writes:

> What is the "right" overlay?

There should be exactly one overlay in the doc-view buffer whose window
property is the currently selected window, and that window has this
overlay accociated in `image-mode-winprops-alist'.

E Sabof <esabof@gmail.com> writes:

> Further evidence suggests that the "t taking precedence" version is
> wrong.  It's more probable the the precedence is determined by the
> order of overlays in some C data-structure.

I think the buffer-local value of `image-mode-winprops-alist' should
always look like:

--8<---------------cut here---------------start------------->8---
((#<window 0x846c030 on IncPat.pdf>
           (overlay . #<overlay from 1 to 756769 in IncPat.pdf>)
           (image image :type imagemagick :file 
"/tmp/docview1000/IncPat.pdf-982c2eddc6c753dafecbffecb17d5993/page-12.png" 
:width 685)
           (info .
                 #("Page 12 of 13.\n" 0 14
                   (face bold)))
           (page . 12)
           (slice))
 (t
  (page . 1)
  (overlay . #<overlay in no buffer>)))
--8<---------------cut here---------------end--------------->8---

That is, there's one entry for any window that shows this doc-view
buffer, plus one t-entry with a deleted overlay.  The order of entries
is by recency of window activations (or creations?), I think.  t is
always the last.

When `doc-view-new-window-function' is called for the very first time
for a new doc-view buffer (i.e., you opened a new document), (car
winprops) is t.  I that case, a new overlay is created, doc-view and
window properties are added (both t), it's associated in winprops (the
t-entry), and then it's deleted so that its not shown (because at this
point in time the image to be shown might not exist).  This entry acts
as default if there are no other entries.

Thereafter, it's immediately called again with a concrete window in (car
winprops).  Don't ask me from where.  I'm edebugging
`doc-view-new-window-function', but this call doesn't drop me in the
edebugger as the previous one did.  I just see the message

  New window #<window 0x7751d70 on foo.pdf> for buf foo.pdf

in the echo area.

With the second and any subsequent call of
`doc-view-new-window-function' for a given doc-view buffer, the overlay
of the top-entry in `image-mode-winprops-alist' is copied.  That way,
the new window shows the same page with the same zoom level/slice as the
most recent other window showing the document.

Yesterday, when things were messed up, I know that
`image-mode-winprops-alist' looked like that:

--8<---------------cut here---------------start------------->8---
((#<window 0x846c030 on IncPat.pdf>
           ...)
 (t
  (page . 1)
  (overlay . #<overlay from 1 to 756769 in IncPat.pdf>)))
--8<---------------cut here---------------end--------------->8---

That is, the t-entry had an overlay that hasn't been deleted.  I don't
know how I could reach that state (I just quickly switched pages,
zoomed, sliced, split window), but that seems wrong and might be the
culprit because some other window in might already use that.

Bye,
Tassilo