GNU bug report logs - #50256
thing-at-mouse

Previous Next

Full log

Message #119 received at 50256 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 50256 <at> debbugs.gnu.org
Subject: Re: bug#50256: thing-at-mouse
Date: Thu, 02 Sep 2021 21:41:06 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 02 Sep 2021 21:28:32 +0300
> Cc: 50256 <at> debbugs.gnu.org, larsi <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.