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: Thu, 02 Sep 2021 10:21:55 +0300 Message-ID: <834kb3phm4.fsf@gnu.org> References: <87sfys6ubm.fsf@mail.linkov.net> <87eeacdnmg.fsf@gnus.org> <87h7f7z8ui.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> <875yvknpls.fsf@mail.linkov.net> <83k0k0p0am.fsf@gnu.org> <87ilzjijto.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11733"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 50256@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 02 09:27:16 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 1mLh80-0002wp-FK for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 09:27:16 +0200 Original-Received: from localhost ([::1]:42908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLh7z-00088I-BA for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 03:27:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLh3u-0002zc-VD for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 03:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56221) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLh3u-00018R-L5 for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 03:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mLh3u-0005RL-HP for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 03:23: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: Thu, 02 Sep 2021 07:23: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.163056732820817 (code B ref 50256); Thu, 02 Sep 2021 07:23:02 +0000 Original-Received: (at 50256) by debbugs.gnu.org; 2 Sep 2021 07:22:08 +0000 Original-Received: from localhost ([127.0.0.1]:39530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLh31-0005Pg-Qy for submit@debbugs.gnu.org; Thu, 02 Sep 2021 03:22:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLh30-0005PD-OX for 50256@debbugs.gnu.org; Thu, 02 Sep 2021 03:22:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51564) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLh2u-0000IZ-P6; Thu, 02 Sep 2021 03:22:00 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4572 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 1mLh2u-0008FW-CJ; Thu, 02 Sep 2021 03:22:00 -0400 In-Reply-To: <87ilzjijto.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 02 Sep 2021 09:16:03 +0300) 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:213240 Archived-At: > From: Juri Linkov > 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.