bug#50256: thing-at-mouse

[martin rudalics <rudalics@gmx.at>]

 > The actual issue is that pos-visible-in-window-p and posn-at-point
 > produced unexpected results when the buffer shown in the selected
 > window was momentarily changed by with-current-buffer.

Whatever `with-current-buffer' does, it does not "momentarily change the
buffer shown in the selected window".  I've re-read this thread and now
think too that we should not change the code of neither `posn-at-point'
nor `pos-visible-in-window-p'.  Given that a function that calls any of
these can have used `with-current-buffer', `set-window-point' and
`goto-char', it's easy to see that when passing nil as POS argument DTRT
never works out.

Suppose I have two windows, the selected one showing *scratch*, the
other one showing *Messages*, and I managed to make position 0 in the
*Messages* window vertically scrolled out of view.  If I now do

(let ((window (next-window)))
   (set-window-point window 0)
   (pos-visible-in-window-p nil window))

I get nil as response although in the resulting configuration position 0
is clearly visible.  If OTOH I do

(with-current-buffer (window-buffer (next-window))
   (goto-char 0)
   (pos-visible-in-window-p nil (next-window)))

I get t although in the resulting configuration position 0 is clearly
out of view.  We may call both pilot errors but I see no evidence that
the coder did anything wrong wrt our docs of `pos-visible-in-window-p'.

If I do instead

(let ((window (next-window)))
   (set-window-point window 0)
   (pos-visible-in-window-p (window-point) window))

and

(with-current-buffer (window-buffer (next-window))
   (goto-char 0)
   (pos-visible-in-window-p (point) (next-window)))

I get the results I would have expected.

So I would, in general, recommend against using nil as POS argument for
`pos-visible-in-window-p'.  Given how fairly rare in our code base the
use of nil is, such recommendation seems feasible to me.  For Emacs 29
it should be then even possible to warn whenever it's used.

martin