bug#50256: thing-at-mouse

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  larsi@gnus.org,  50256@debbugs.gnu.org
> Date: Thu, 02 Sep 2021 09:16:03 +0300
> 
> >> In bug#9923 'C-h m' switched to another buffer before calling
> >> mouse-set-point.
> >
> > Then it's a bug in that command, I'd say.  You assume something about
> > last-input and what mouse-set-point and posn-set-point will do when
> > last-input is not a click event.  And that assumption turns out to be
> > false.  So instead of making that assumption, why not give the code a
> > valid event to work with instead?
> 
> Currently event-start and event-end that use mouse-set-point and posn-set-point
> create an invalid event when some code inadvertently switches the buffer.

Yes.  Then either mouse-set-point should be fixed to avoid that when
it runs inside with-current-buffer, or, when the event is not a click
event, we should concoct the data corresponding to event-start/end
differently, in a way that is tolerant to this situation.

And I'm not yet clear what would be the desired result in this case:

> (progn
>    (with-current-buffer "*Messages*"
>      (goto-char (point-min)))
>    (pop-to-buffer "*Messages*")
>    (with-current-buffer "*scratch*"
>      (pos-visible-in-window-p nil nil t)))

What position would you like this to report on?  Would you like it to
report on the value of point in the selected window, or should it
report on the value of point in the current buffer?  Since these two
are different, it is no longer a trivial question to answer.

> > posn-at-point cannot work correctly when current buffer and the
> > selected window's buffer are not the same, because they use display
> > code which is based on that contract.  If you break the contract by
> > the likes of with-current-buffer, you will be lucky not to crash, let
> > alone cause errors.
> 
> So the conclusion is following?  There is a bug in the low-level
> function, but we ask users to be careful and to take precautions
> against stumbling on this bug.  Then the problem is that such warning
> should be documented somewhere.

It's fine with me to document that restriction, yes.