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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Sun, 29 Aug 2021 17:44:02 UTC

Severity: normal

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50256 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
Subject: Re: bug#50256: thing-at-mouse
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.  It can be easily accommodated via

diff --git a/src/window.c b/src/window.c
index cb8fe5fcdb..9296b12499 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2199,7 +2199,7 @@ 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))
+  else if (XBUFFER (w->contents) == current_buffer)
     posint = PT;
   else
     posint = marker_position (w->pointm);

> 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.

> 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.
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.

Also, your proposed solution will not catch bugs in existing but
no-so-well-tested code.  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);
+    }

   /* If position is above window start or outside buffer boundaries,
      or if window start is out of range, position is not visible.  */

martin




This bug report was last modified 3 years and 315 days ago.

Previous Next


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