Here's an update on the other issue I mentioned, possibly (but probably)
related to the first. This is the issue where windmove-left/right was not able
to find a window to the left or right when there should be a window to the left
or right:

> Ok, I see.  When it happens again, please also report the value of
> (image-mode-winprops).

With a window displaying this error, (image-mode-winprops) displays:

(#<window 8 on project_guidelines.pdf> (image image :type imagemagick :file
"/tmp/docview1000/project_guidelines.pdf-6b74fe3de14062aa62bfca2d5caff0ef/page-1.png"
:pointer arrow :width 850) (info . #("Page 1 of 5.  " 0 12 (face bold))) (page
. 1) (overlay . #<overlay from 1 to 84522 in project_guidelines.pdf>))

To reproduce:
1. Start emacs from master with -Q.
2. (require 'windmove) and set `windmove-wrap-around' to t.
3. Split the window horizontally, then vertically.
4. Display a pdf with doc-view in the buffer at the bottom right.
4. Use `windmove-left' or `windmove-right' into the frame border.

See the attached image to get an idea of what step #2 means (in this case, I'm
running `windmove-right', which only produces an error after I follow the above
steps; normally, it works just fine). I'm running graphical emacs on arch linux
in X. The error only occurs for the affected doc-view buffer; it does not affect
other doc-view buffers.

> Alternatively, you could try to add the function ‘window-in-direction’ (in
> window.el) temporarily to your .emacs.

Added the revised version to .emacs and evaluated. The `when' clause was always
nil because `my-value' was always a positive number (this is on the window
erroring out when running windmove-left/right), but here's the value
`my-variable` it would have been set to if the `when' clause was true:

("window: #<window 4 on *Minibuf-1*> direction : above sign: nil wrap: nil mini:
nil posn-cons: (234 . 0)" "window: #<window 8 on project_guidelines.pdf>
direction : right sign: nil wrap: t mini: t posn-cons: (965 . 1011)")

Once the failing behavior is induced with the reproduction steps above, when the
window is resized, the failing behavior seems to stop. This issue is probably
just an issue with `window-in-direction' somewhere. Should I open up a separate
bug for it?