[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13
From: |
Tassilo Horn |
Subject: |
Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13887. |
Date: |
Mon, 18 Mar 2013 20:50:34 +0100 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>>>> + ;; We're not already displaying an image, so this is the
>>>> + ;; initial window showing the document.
>>>> + (run-with-timer nil nil
>>>> + (lambda ()
>>>> + ;; In case a conversion is running, the
>>>> + ;; refresh will happen as defined by
>>>> + ;; `doc-view-conversion-refresh-interval'.
>>>> + (unless doc-view-current-converter-processes
>>>> + (with-selected-window (car winprops)
>>>> + (doc-view-goto-page 1)))))
>>> I don't understand the scenario in which this doc-view-goto-page would
>>> be needed.
>> This is the case where the document is initially shown in a window.
>
> I must admit I do not know what you mean precisely with the above
> sentence.
I mean, the code above runs only when the doc-view buffer is shown for
the very first time in some window.
>> My change to `doc-view-insert-image' prevents insertion of image data
>> if the window isn't shown,
>
> Do you mean "if the window is not *live*" or "if the *buffer* isn't
> shown"?
If the window associated with the current doc-view overlay isn't live.
See line 1273.
>> and here the `doc-view-goto-page' call will do just that.
>
> But between the moment you checked window-live-p and the moment you run
> the above timer, if the buffer ends up displayed, there must have been
> an operation that ran window-configuration-change-hook.
>
> So IIUC this doc-view-goto-page shouldn't be required because the
> window-configuration-change-hook should have caused an equivalent
> doc-view-goto-page already.
window-configuration-change-hook runs image-mode-reapply-winprops, but
at that point in time, there's no winprops entry for that window.
However, image-mode-reapply-winprops calls image-mode-winprops, and that
runs image-mode-new-window-functions because of the missing winprops
entry, and now we are in the situation I handle with the code in
question.
Bye,
Tassilo