bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tassilo Horn
Subject: bug#13887: 24.3; doc-view will render blurry images when image-magick is available
Date: Mon, 11 Mar 2013 21:27:16 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Tassilo Horn <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Mon, 11 Mar 2013 19:20:47 +0100
>> 
>> > doc-view-new-window-function seems to be run from a
>> > window-configuration-change-hook, right?
>> 
>> No, from `image-mode-new-window-functions'.  The functions in there
>> are run by `image-mode-winprops' if (and only if) there are no
>> winprops set for the image and the current window.
>
> Maybe I'm missing something, but in image-mode.el:
>
>   . image-mode-winprops is called by image-mode-reapply-winprops
>
>   . image-mode-reapply-winprops is added by image-mode-setup-winprops
>     to window-configuration-change-hook
>
> Doesn't that mean what I said?

Nearly, except that `image-mode-new-window-functions' are only run when
they don't have an entry in `image-mode-winprops-alist'.

>> Basically, this should only ever happen when there's a new window
>> showing the buffer with the image.
>
> How's that ensured?  Can you walk us through the relevant code?

That's line 72 in image-mode.el:

  (let ((winprops (assq window image-mode-winprops-alist)))
    ;; For new windows, set defaults from the latest.
    (unless winprops
      (setq winprops (cons window
                           (copy-alist (cdar image-mode-winprops-alist))))
      (run-hook-with-args 'image-mode-new-window-functions winprops))

However, whenever the doc-view window is split (e.g., when a completion
buffer pops up), the doc-view buffer is indeed shown in a new window.
That's why `doc-view-new-window-function' is run more often than I
expected originally.

That also explains why there are often multiple overlays in the doc-view
buffer.  There's one overlay per window that has shown the buffer at
least once.  This allows that you can have 2 windows displaying the same
doc-view buffer: one showing page X, and in the other you can switch to
other pages without changing the other window.

So the multiple overlays thingy is actually intended.  But somewhere the
logic goes wonky and we're acting on the wrong overlay.

Bye,
Tassilo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]