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

[Daniel McClanahan]

> *y = it2.current_y + it2.max_ascent - it2.ascent;

I don't know what max_ascent or ascent's values were supposed to be,
but I recall current_y was negative. Sorry I don't have more info; as
mentioned below, I lost my backtrace when my computer turned off.

> First, I believe the function that was signaling an error is
> posn-at-x-y, which is called internally by posn-at-point; the latter
> AFAICS doesn't make any checks that could cause such an error to be
> signaled.  Is that correct?

Correct. I was referring to the sequence of calls in Fposn_at_point
which calls Fpos_visible_in_window_p (which calls pos_visible_p,
setting x and y), and then calls Fposn_at_x_y which checks for
negativity and throws an error (it's just the negative y in this
case). So the function that throws the error is separate from the one
that sets those x and y values, and Fpos_visible_in_window_p is not
visible in the stack trace.

> So to get the investigation of this bug forward, could you post here
> the C-level backtrace you get in GDB when this error is signaled?
> Please accompany it with the output of the "xbacktrace" GDB command,
> which should show the corresponding Lisp backtrace.  (This command
> is defined in the file src/.gdbinit in the Emacs source tree, so you
> will have to source that file before issuing the command.)

I don't have the *Backtrace* buffer or gdb backtrace, I didn't think
to do so earlier and my machine turned off in between then so I have
been trying hard to get it to a failure state again. I will update
this thread with those and the info from report-emacs-bug when I can
do so.

> It might help to find out with which arguments was posn-at-point (or
> was it posn-at-x-y?) called, and then try reproducing the problem by
> manually calling that function with the same arguments in the same
> buffer.  If that works, you will have a reproducible recipe.

I'll see if I can try to trigger pos-visible-in-window-p and examine
the window's "cursor" value afterwards, once I can get it back to the
failure state.

As an aside, I've also found that when a doc-view-mode buffer is
adjacent to a frame border, using windmove directed at that border (so
using windmove-right when the window is on the right side of the
frame) occasionally fails with "No window right from selected window"
(or whatever the direction is). This + the current bug leads me to
believe doc-view.el is doing some weird stuff with window
management. I tried to take a look at what it might be, but couldn't
figure out anything quickly enough.