Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13887.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13887.

[Stefan Monnier]

> === modified file 'lisp/doc-view.el'
> --- a/lisp/doc-view.el	2013-03-14 15:24:04 +0000
> +++ b/lisp/doc-view.el	2013-03-14 21:33:07 +0000
> @@ -324,7 +324,26 @@
>        ;; `window' property is only effective if its value is a window).
>        (cl-assert (eq t (car winprops)))
>        (delete-overlay ol))
> -    (image-mode-window-put 'overlay ol winprops)))
> +    (image-mode-window-put 'overlay ol winprops)
> +    (when (windowp (car winprops))
> +      (if (stringp (get-char-property (point-min) 'display))

This get-char-property looks fishy, since we may have several overlays,
each with its `display' property and we don't know which one we'll get.
It might be the case that `stringp' will return the same value
regardless, so maybe it's OK, but if so it deserves a comment explaining
why it's OK.

> +    	  ;; 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.

> +    	;; We've split the window showing the document.  All we need
> +    	;; to do is selecting the new window to make the image appear
> +    	;; there, too.
> +    	(run-with-timer nil nil
> +    			(lambda ()
> +    			  (save-window-excursion
> +    			    (select-window (car winprops)))))))))

save-window-excursion won't undo the effects of select-window on the
buffer-list.  So you might like to use the `norecord' argument, or
(better) to use with-selected-window.

Also will this work just by virtue of causing a redisplay (in which case
the comment should say so), or will it work by triggering
window-configuration-change-hook (in which case, maybe this is
a workaround for a bug elsewhere)?


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13887.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> === modified file 'lisp/doc-view.el'
>> --- a/lisp/doc-view.el	2013-03-14 15:24:04 +0000
>> +++ b/lisp/doc-view.el	2013-03-14 21:33:07 +0000
>> @@ -324,7 +324,26 @@
>>        ;; `window' property is only effective if its value is a window).
>>        (cl-assert (eq t (car winprops)))
>>        (delete-overlay ol))
>> -    (image-mode-window-put 'overlay ol winprops)))
>> +    (image-mode-window-put 'overlay ol winprops)
>> +    (when (windowp (car winprops))
>> +      (if (stringp (get-char-property (point-min) 'display))
>
> This get-char-property looks fishy, since we may have several
> overlays, each with its `display' property and we don't know which one
> we'll get.  It might be the case that `stringp' will return the same
> value regardless, so maybe it's OK, but if so it deserves a comment
> explaining why it's OK.

I think in this case it's ok, because this case happens only once when
opening a new document, so there's only one overlay.  But anyway, I've
changed it to use check the 'display property of `ol', now.

I also changed the single remaining `get-char-property' call in
`doc-view-document->bitmap' to check the current doc-view overlay's
'display property.

>> +    	  ;; 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.  My
change to `doc-view-insert-image' prevents insertion of image data if
the window isn't shown, and here the `doc-view-goto-page' call will do
just that.

>> +    	;; We've split the window showing the document.  All we need
>> +    	;; to do is selecting the new window to make the image appear
>> +    	;; there, too.
>> +    	(run-with-timer nil nil
>> +    			(lambda ()
>> +    			  (save-window-excursion
>> +    			    (select-window (car winprops)))))))))
>
> save-window-excursion won't undo the effects of select-window on the
> buffer-list.  So you might like to use the `norecord' argument, or
> (better) to use with-selected-window.

I'm doing the latter now.

> Also will this work just by virtue of causing a redisplay (in which
> case the comment should say so), or will it work by triggering
> window-configuration-change-hook (in which case, maybe this is a
> workaround for a bug elsewhere)?

By virtue of causing a redisplay.  (At least I've removed
`image-mode-reapply-winprops' from the local value of
`window-configuration-change-hook' for testing, and that made no
difference with respect to showing the image).

I've adjusted the comment accordingly.

Bye,
Tassilo

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13887.

[Stefan Monnier]

>>> +    	  ;; 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.

> 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"?

> 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.

> I've adjusted the comment accordingly.

Thanks,


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112045: * doc-view.el Fix bug#13887.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> 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