bug#50256: thing-at-mouse

[Eli Zaretskii <eliz@gnu.org>]

> Cc: juri@linkov.net, 50256@debbugs.gnu.org, larsi@gnus.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 4 Sep 2021 09:34:17 +0200
> 
>  > Thanks.  There's one more use case I can think of: when WINDOW is not
>  > a selected one, but its buffer is also displayed in the selected
>  > window, which could mean its point is different from WINDOW's point.
> 
> You mean this would constitute a reasonable and legitimate scenario
> where we should use the current buffer's point via a nil argument as we
> do with the present code.

I don't know what is reasonable in that case, all I know is that there
could be 2 alternatives, each one not necessarily senseless.

>  > Anyway, after thinking for some time about this, I concluded that the
>  > only sane way forward, especially since we are going to cut the
>  > emacs-28 branch soon, is to leave the default behavior of
>  > pos-visible-in-window-p and posn-at-point as it is today, and add one
>  > more optional argument to force the possible alternative behavior(s).
>  > The proposed change to event-start and event-end are new code, so they
>  > should have no trouble passing this new optional argument to
>  > posn-at-point.
> 
> There's no need doing that - these function could just pass an explicit
> POS argument instead of using nil.

They could, but (posn-at-point) is a very frequent usage, and the same
with pos-visible-in-window-p.  I want to avoid the need of auditing
all of those (and there are a lot of them not in Emacs, so we
practically can't) and adjusting them for the different semantics we
want to introduce to handle what mouse-set-point does, or should do,
for context menus.

>  > That means to add an argument to pos-visible-in-window-p that would
>  > cause it to select one of the following 3 alternatives: WINDOW's
>  > point, WINDOW's buffer's point, and (in case WINDOW is the selected
>  > window) the current buffer's point.  The default should stay as it is
>  > today: when WINDOW is the selected window, use the current buffer's
>  > point.
>  >
>  > Anything else IMNSHO risks introducing many bugs into existing
>  > well-tested code that we will never be able to discover and fix in
>  > time for Emacs 28.1 release.
> 
> Agreed.  But the solution you propose appears pure overkill to me.

It could be, but it is safe, and it does the job.  The allegedly
"buggy" code in pos-visible-in-window-p was there since long ago, so
its behavior is now a de-facto standard, even though the doc string
fails to describe the subtlety.  I cannot see any sense in changing
that behavior now, just because some new (and quite tricky) code made
some assumption about that behavior that happens to be false.

> Instead of adding another argument (and trying to explain its meaning)
> we should rather tell that using nil for POS is ambiguous and should be
> avoided because at the time this function is called, the current buffer
> and WINDOW's buffer might not be the same.

"We should rather tell" means documentation changes, right?  That
cannot fix the problems I'm worried about: if we break code out there,
telling we documented that won't get us any points.  We should avoid
breaking the code in the first place.

> Also, your proposed solution will not catch bugs in existing but
> no-so-well-tested code.

That doesn't make the situation worse, does it?  "Don't do harm" is a
great principle in these cases, IME.

> To catch those it might reasonable to do:
> 
> diff --git a/src/window.c b/src/window.c
> index cb8fe5fcdb..18ada851fe 100644
> --- a/src/window.c
> +++ b/src/window.c
> @@ -2199,10 +2199,16 @@ 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);
> +    {
> +      if (XBUFFER (w->contents) != current_buffer)
> +	message ("`pos-visible-in-window' called with POS nil but WINDOW's buffer is not current");
> +
> +      if (w == XWINDOW (selected_window))
> +	posint = PT;
> +      else
> +	posint = marker_position (w->pointm);
> +    }

That's orthogonal.  (And it seems to issue the warning in an unrelated
case, handled by the 'else' clause?)  We should first decide how to
support the context menus with this stuff, and then we can talk how to
find code out there which makes similar assumptions.  (But if there is
such code out there, how was it working till now?)