From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50256: thing-at-mouse Date: Sat, 04 Sep 2021 11:02:20 +0300 Message-ID: <83sfykwyyb.fsf@gnu.org> References: <87sfys6ubm.fsf@mail.linkov.net> <871r6a8ooe.fsf@gnus.org> <87y28i85xi.fsf@mail.linkov.net> <87k0k1o5ks.fsf@mail.linkov.net> <87ilzk6bsr.fsf@mail.linkov.net> <6dcf3191-dbb3-0c6c-2483-0fc05e9ff6e5@gmx.at> <83lf4gqyn9.fsf@gnu.org> <1a65f234-c1ee-ae95-aa05-2e3d9d1e1002@gmx.at> <8335qoqobm.fsf@gnu.org> <7c9cb0a1-b222-cb06-7e7c-7f17231faca3@gmx.at> <83pmtsp4g1.fsf@gnu.org> <831r67ph8d.fsf@gnu.org> <87tuj3bffb.fsf@gnus.org> <83y28fo1xf.fsf@gnu.org> <191e9cc6-7370-5b7d-7777-716b61e0155d@gmx.at> <83pmtrnydh.fsf@gnu.org> <158a8854-f56a-9aaa-3a14-d108e086a24c@gmx.at> <83k0jznms2.fsf@gnu.org> <87v93j9dfz.fsf@mail.linkov.net> <87y28e4ysv.fsf@mail.linkov.net> <83czpqzupp.fsf@gnu.org> <83v93hyl3l.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28761"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50256@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 04 10:03:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mMQdq-0007K3-NC for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Sep 2021 10:03:10 +0200 Original-Received: from localhost ([::1]:57828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMQdp-0004Ni-Cp for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Sep 2021 04:03:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMQdi-0004NZ-Mt for bug-gnu-emacs@gnu.org; Sat, 04 Sep 2021 04:03:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34990) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mMQdi-00083D-FL for bug-gnu-emacs@gnu.org; Sat, 04 Sep 2021 04:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mMQdi-0001pt-50 for bug-gnu-emacs@gnu.org; Sat, 04 Sep 2021 04:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Sep 2021 08:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50256 X-GNU-PR-Package: emacs Original-Received: via spool by 50256-submit@debbugs.gnu.org id=B50256.16307425526487 (code B ref 50256); Sat, 04 Sep 2021 08:03:02 +0000 Original-Received: (at 50256) by debbugs.gnu.org; 4 Sep 2021 08:02:32 +0000 Original-Received: from localhost ([127.0.0.1]:46536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mMQdD-0001g7-EV for submit@debbugs.gnu.org; Sat, 04 Sep 2021 04:02:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mMQdB-0001Zf-BE for 50256@debbugs.gnu.org; Sat, 04 Sep 2021 04:02:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53978) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMQd4-0007WG-LV; Sat, 04 Sep 2021 04:02:22 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1911 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMQd4-0005Bn-7L; Sat, 04 Sep 2021 04:02:22 -0400 In-Reply-To: (message from martin rudalics on Sat, 4 Sep 2021 09:34:17 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:213399 Archived-At: > Cc: juri@linkov.net, 50256@debbugs.gnu.org, larsi@gnus.org > From: martin rudalics > 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?)