Subject: bug#21732: 25.0.50; intermittent failure using windmove when in doc-view buffer

From: Eli Zaretskii <[email-masked]>
Date: Sat, 07 Nov 2015 14:30:45 +0200

> From: Daniel McClanahan <[email-masked]>
> Date: Sat, 7 Nov 2015 03:51:15 -0600
> Cc: Tassilo Horn <[email-masked]>, [email-masked], Eli Zaretskii <[email-masked]>
> 
> Sorry for the late response, I've been working with other things and
> haven't had time to analyze it when this was reproduced. Managed to
> reproduce it today and had time to attach gdb. Before you check out
> the stack trace, note the following paragraph first.
> 
> Eli, thanks for the suggestion to attempt to manually trigger the
> error. After viewing the "*Backtrace*" buffer, I manually tried to
> enter a huge value for `posn-at-point' (I tried the exact value
> 681965) on a doc-view buffer, and received the wholenump error
> reliably, but ONLY in the buffer which displays the error I described
> in the original post. In other buffers (I tried C, org-mode, and other
> doc-view buffers), (posn-at-point 681965 (selected-window)) just
> returns nil instead of erroring out. It's interesting to note that
> currently the doc-view buffer which I was able to reproduce the error
> on is no longer displaying the error when I use `windmove-up', but is
> still erroring out when I run (posn-at-point 681965
> (selected-window)).
> 
> In short:
> - (posn-at-point 681965 (selected-window)) returns nil on most
> buffers. (Replace 681965 with some point outside the buffer range.)
> - On doc-view buffers which have already gone into the failure state
> (through black magic we don't know yet), it throws the wholenump
> error.
> - This appears to be a buffer thing, not a window thing, since closing
> and reopening the window displaying the failing buffer and running
> (posn-at-point 681965 (selected-window)) causes the wholenump error.

Thanks for looking into this.  I cannot run doc-view here,
unfortunately.  Can I ask you to step inside pos_visible_p, which is
called by Fpos_visible_in_window_p, and see where this negative Y
coordinate is produced?  I think this somehow happens because doc-view
in effect lets Emacs show a large image, but I couldn't reproduce the
problem by visiting an image file, so there's probably something I'm
missing.