bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50256: thing-at-mouse


From: martin rudalics
Subject: 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]