From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#50256: thing-at-mouse Date: Fri, 3 Sep 2021 09:40:36 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15218"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50256@debbugs.gnu.org, larsi@gnus.org To: Eli Zaretskii , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 03 09:41: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 1mM3p0-0003mX-Ji for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Sep 2021 09:41:10 +0200 Original-Received: from localhost ([::1]:47108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mM3oy-0003gG-Jj for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Sep 2021 03:41:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM3ot-0003g1-J0 for bug-gnu-emacs@gnu.org; Fri, 03 Sep 2021 03:41:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59419) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mM3ot-0002P5-BG for bug-gnu-emacs@gnu.org; Fri, 03 Sep 2021 03:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mM3or-0002ee-Of for bug-gnu-emacs@gnu.org; Fri, 03 Sep 2021 03:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Sep 2021 07:41:01 +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.163065484810163 (code B ref 50256); Fri, 03 Sep 2021 07:41:01 +0000 Original-Received: (at 50256) by debbugs.gnu.org; 3 Sep 2021 07:40:48 +0000 Original-Received: from localhost ([127.0.0.1]:42729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mM3od-0002dm-LH for submit@debbugs.gnu.org; Fri, 03 Sep 2021 03:40:47 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:47313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mM3oa-0002dG-CB for 50256@debbugs.gnu.org; Fri, 03 Sep 2021 03:40:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1630654838; bh=BQjFqnpMf5OJNNW8fQw5cjSrobt9jT5eOR/pN9Sj1f8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bt6XZ48Oebqe7tdr94tSxMVdrNk7xBTv2F6fLzfCaze29k1EJeur83BqaoxoR4AZX DB2RwQGewu+2IS7hu995Pt5ZwtZsA+31Lz/UhTuy++h/KWtJ8TbPgKzmrsPfGBX1yk MTGiQ/yy2O8e1i4aYVqC0VVOqcmw+LYfgW8DtFnA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.4]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MeCtj-1mwV9t0127-00bKhM; Fri, 03 Sep 2021 09:40:38 +0200 In-Reply-To: <83czpqzupp.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:0PnVrtbAZXTUDbiaYbqFBc09pPWol3+2kuHR2a7xOsXi6OdmoLF G8uED1RvkZ8XyLxfJEpPcg0PUlP4U/rxbQqqHDty1dpReNDwLM2efOqql66lHRYLk0FiiSZ F9XydNHjp5+rMmy53Nn7/vfSeZRVZwVmugLp1I7AfrV9UkB8QFoA6qnlDyYOdIB/9vY/o7x A/hnUJap1xEy/NX4jmMvQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:i48nien1S0E=:c/bMjVZT5L9822E3HMF5pL 3OgcDPVvqytlrogH4CYDiSj5wuWKNMNFvcRocLosqMNBNPeQm3aqDW/nfRtYmPF4fcWrL0jlQ Znh/lBZ2u/YlXtyhLbi8Xn0THPrt6Tj7kCw/P8pYGJIn8w9k8puCXppkKvvxfIGg0S8gVVjgd K4lQffl7SYePswI62mWJtNFF4a5Ji7DdELw5HzH3HfEaxZFfhVgF9NmIvKhI74nOmf4zQs7I7 32PJHUz5giUp5exvD+CrTv7h3heDU/gcjSK3xNI3Eegb/vL2/pqDI1aTspr8YhPfN2VUllPK9 NpQN7IfkzBeM/1EWfuVEiCANeysWPyBu6OMVcCOhcNgjKDJailpmL7ZDtej0Xtk2GKclCtolo ebX0Cs3CFzEwijlWWhnc/U/PzGWLwq8qwhPa7hdnE29+uctTJnIs5d0el/4FSCno0/FYvSoR9 0WG4MBMA0vo1T6XkiNU7BALmM9Q/ZMFqotO5zIXZjjbG61/tjaDql4Hwa/93oIQ+Z/9VCsTm/ V83bKwZHVpviuZ0ZSBA7xOtH5/fOVOy/5xFNKp2vGj3BboissZbd5eXGG4gphZ5OZ111Nvmdn k1yxb960mKgns07cE9p+s3rYKiUjoYZEbM5PT1ppyEGNGK9stBm5c/2rb3j6KILsCOBkStVS3 oJmAOm833xdMZc39LDF0fPoQYirx1md9WMEksaCnJ6tAmodanNgkl0QIVv/+HJrtlj+J+1fiK zRmDKsQtwIo1noqqxoNqWkjsnCze3tn6Sgzs/HF1rKL+YZ5Bsd3OK5Al7J6+ExBYDQo770Tg 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:213326 Archived-At: > I think we need to special-case the case of the current buffer. But > I'd still like to talk about the semantics of calling > pos-visible-in-window-p when WINDOWS is the selected window, but the > WINDOW's buffer is not the current one. Who "wins" in that case, for > the purpose of the default value of position: the window or the > buffer? If in the manual we say "The argument POSITION defaults to the current position of point in WINDOW", this means that the window should win. Whether that's reasonable is another question. Note that a similar disputable case already happens when we do (pos-visible-in-window-p nil (next-window) t) and the next window does not show the current buffer. We there silently override the "nil" with WINDOW's point. Maybe we should signal an error in either of these cases when WINDOW's buffer is not the current buffer. IIUC we use `pos-visible-in-window-p' mainly for three purposes: (1) Detect whether a buffer position that typically does _not_ equal window point is visible in window and, if it isn't, do something (scroll, enlarge the window) to make it visible. (2) Detect whether window point is only partially visible. (3) Get the coordinates of window point and move the mouse or pop up a menu there. In all these cases, callers simply don't care about which buffer is current when calling the function - the buffer in question is WINDOW's buffer. A different use were to check whether a position of an arbitrary BUFFER would be visible in a WINDOW if BUFFER were displayed there with the start of the window set to some valid BUFFER position. I don't know whether anyone ever used such a functionality. To make it work, a caller would have to set WINDOW's buffer and start position first, call `pos-visible-in-window-p' and restore the original state afterwards. Even in this hypothetical case, the caller wouldn't care about which buffer is current. martin