bug#50256: thing-at-mouse

[martin rudalics <rudalics@gmx.at>]

 > I think we need to special-case the case of the current buffer.  But
 > I'd still like to talk about the semantics of calling
 > pos-visible-in-window-p when WINDOWS is the selected window, but the
 > WINDOW's buffer is not the current one.  Who "wins" in that case, for
 > the purpose of the default value of position: the window or the
 > buffer?

If in the manual we say "The argument POSITION defaults to the current
position of point in WINDOW", this means that the window should win.
Whether that's reasonable is another question.  Note that a similar
disputable case already happens when we do

(pos-visible-in-window-p nil (next-window) t)

and the next window does not show the current buffer.  We there silently
override the "nil" with WINDOW's point.  Maybe we should signal an error
in either of these cases when WINDOW's buffer is not the current buffer.

IIUC we use `pos-visible-in-window-p' mainly for three purposes:

(1) Detect whether a buffer position that typically does _not_ equal
     window point is visible in window and, if it isn't, do something
     (scroll, enlarge the window) to make it visible.

(2) Detect whether window point is only partially visible.

(3) Get the coordinates of window point and move the mouse or pop up a
     menu there.

In all these cases, callers simply don't care about which buffer is
current when calling the function - the buffer in question is WINDOW's
buffer.

A different use were to check whether a position of an arbitrary BUFFER
would be visible in a WINDOW if BUFFER were displayed there with the
start of the window set to some valid BUFFER position.  I don't know
whether anyone ever used such a functionality.  To make it work, a
caller would have to set WINDOW's buffer and start position first, call
`pos-visible-in-window-p' and restore the original state afterwards.
Even in this hypothetical case, the caller wouldn't care about which
buffer is current.

martin