bug#50256: thing-at-mouse

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 02 Sep 2021 21:28:32 +0300
> Cc: 50256@debbugs.gnu.org, larsi@gnus.org
> 
> >> --- a/src/window.c
> >> +++ b/src/window.c
> >> @@ -2199,8 +2199,6 @@ DEFUN ("pos-visible-in-window-p", 
> >> Fpos_visible_in_window_p,
> >>      posint = -1;
> >>    else if (!NILP (pos))
> >>      posint = fix_position (pos);
> >> -  else if (w == XWINDOW (selected_window))
> >> -    posint = PT;
> >>    else
> >>      posint = marker_position (w->pointm);
> >
> > I confirm this fixes the reported issues.
> 
> Actually, whereas it fixes the reported issue,
> it breaks everything else: moving point up and down
> always jumps to the fixed column like goal-column,
> selecting a completion from the Completions buffer
> always says "No completion here", 'C-c C-c' in diff-mode
> jumps to the wrong hunk, etc.

Figures out, because the window's point didn't get updated yet (AFAIR,
it is updated by redisplay), whereas pos-visible-in-window-p is
expected to work before that.

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?