From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#32790: 27.0.50; point jumps unexpectedly after delete-window Date: Tue, 30 Oct 2018 10:00:07 +0100 Message-ID: <5BD81D97.2000000@gmx.at> References: <87efdnsp2k.fsf@mail.linkov.net> <87a7nedidg.fsf@mail.linkov.net> <5BC5A558.9010401@gmx.at> <87zhvd7mg9.fsf@mail.linkov.net> <5BC6E52F.2070209@gmx.at> <87woqgw9a7.fsf@mail.linkov.net> <5BC83EC9.1090808@gmx.at> <877eiena58.fsf@mail.linkov.net> <5BC98A26.1030901@gmx.at> <87woqcnwas.fsf@mail.linkov.net> <5BCC3757.9020204@gmx.at> <87bm7njk2f.fsf@mail.linkov.net> <5BCD934D.4070906@gmx.at> <878t2owo8i.fsf@mail.linkov.net> <5BD03F4D.1000900@gmx.at> <87in1phhx2.fsf@mail.linkov.net> <5BD2C52E.2060607@gmx.at> <87ftwrgwp2.fsf@mail.linkov.net> <5BD57A8D.8080408@gmx.at> <875zxmx95h.fsf@mail.linkov.net> <5BD70F14.8080509@gmx.at> <87lg6g750v.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1540889986 4428 195.159.176.226 (30 Oct 2018 08:59:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 08:59:46 +0000 (UTC) Cc: 32790@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 30 09:59:42 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHPsE-00012k-1J for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Oct 2018 09:59:42 +0100 Original-Received: from localhost ([::1]:51674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHPuK-0001F9-HX for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Oct 2018 05:01:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHPu1-00018q-JD for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:01:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHPtZ-0001LP-2W for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:01:19 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49031) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHPtW-0001HA-Ph for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:01:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gHPtV-0003mD-Hp for bug-gnu-emacs@gnu.org; Tue, 30 Oct 2018 05:01: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: Tue, 30 Oct 2018 09:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32790 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32790-submit@debbugs.gnu.org id=B32790.154089002812668 (code B ref 32790); Tue, 30 Oct 2018 09:01:01 +0000 Original-Received: (at 32790) by debbugs.gnu.org; 30 Oct 2018 09:00:28 +0000 Original-Received: from localhost ([127.0.0.1]:53286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHPsx-0003Hh-8Z for submit@debbugs.gnu.org; Tue, 30 Oct 2018 05:00:27 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:46635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHPsv-0003By-MQ for 32790@debbugs.gnu.org; Tue, 30 Oct 2018 05:00:26 -0400 Original-Received: from [192.168.1.101] ([213.162.73.177]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LkfdE-1fjS2d19E4-00aULA; Tue, 30 Oct 2018 10:00:15 +0100 Original-Received: from [192.168.1.101] ([213.162.73.177]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LkfdE-1fjS2d19E4-00aULA; Tue, 30 Oct 2018 10:00:15 +0100 In-Reply-To: <87lg6g750v.fsf@mail.linkov.net> X-Provags-ID: V03:K1:mEODriaY0I9He7MLh/uxNgeXFOtrJV92HkP88t7r23jQLCI0NwI xnWMIsE6xTkEyQaqVyrHnu4YKzE5+LBupFj12CmfLwsA6AEadMgNqq1KcasUrHphYdQ/tgK puvmVcBm9DwMpZoFYdVRDnuwR0M0x6TdQr/jlHzcAQIA7u90qGWfcooxIrA3G944Kv/9dHC KZOXMK6ZMcvVAHnOM6uXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:kLsFnvfTXWU=:XiKzvA42OIufKrXfdmyeGA PNCkOVRRQHGg7pbWTA+v8GysHrxMnVRQ6UdKDWazHiHgkkL9fpiMooK8Hqx7mwZd/45+YOPwr ljVXJpjh33RsFCprD1pf4uSksZVRWOT/q1Owtxs17XxbmlVDas11IXd5mUr3wkX9oSxTZtKIo 6DsLk6me1+7rao0yiJbh+5lwCY8Sl5eeCdXYXw9G+wjzFa1rH/Jq9QB2JBkZ45RzVkyirhobe 0Hryr9C+aUIHav5gjgNxf902AhUKvDSVrSRhJK+BU3EvmLNIRpSxb5ZemNxlCpwbS/F/O0skE njFhSruCRnNXpU5gLnL21ZlKogOSbYo1xB14i4B38Ze37k5rK5/szNha67PgD9BfIzDnGMd4W xQz7Qd9oDjKN7zqm8HaKnP6KBcv8bDKCcrL3bPSa1aLRPYuoiMxjdtROyI+6fPUZucE3rJaej wGdurTKLmhyAOGMX7PU3M2S1DHfi2ptxTFwuoBIymVfQ31m+o4BOpz88on6xvpbHJrHv9nvmB IiQjb0RIouUQDrjdoisdcNW4cGPsr7dDNJ/Zp0aC1AvSObuJyh9RSE+kg5Do0147rlKsryKx9 U9VRJiuTBmhuFXEkhzVc9Kp5lPleI3HgNd8fOUI6QMLwD5qaeY5HJBKbC/hpP6p7t6wS5iqHW FcxBV9kHKizk693PEVPs2Xu32Ntc228myaLXv6U4P16tc30tOtp1FWGqa5d8tEtmdjpPSJlyn HxtwT1bNHQGdXcgIp3ahAuSXYR+uMc7ywsCEU1WpJudbp8ydahPEniOZtnqB0iitDHGn+W29 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151817 Archived-At: >> Rather, the function on 'post-command-hook' would have to be more >> intelligent - check whether the minibuffer-window is selected and >> leave the overriding action untouched in that case. > > It's possible to implement it with post-command-hook, but the > implementation will be more contorted - note that adding a hook > to post-command-hook by a command will run it immediately > at the end of this command and immediately remove the hook. The mechanism must be safe in the first place and safety means here to remove the mechanism before anything bad happens. > Whereas window-state-change-functions elegantly checks > if the window displays a new buffer. But it fails when a window gets reused. In general, any outcome of 'display-buffer' is possible, even 'allow-no-window'. As soon as 'display-buffer' returns and no change of the window state happened we are lost. >> Moreover, using 'post-command-hook' would automatically fix any >> problems when quitting an S-M-up action. I see no way to catch >> quitting via a state change of windows. > > What do you mean by quitting an S-M-up action? minibuffer-exit? Let's say anything C-g does. I'm not sure whether we can catch that always via 'minibuffer-exit-hook' though. But it should not harm to remove the overriding action in that case as well. >> I forgot to ask: If that ffap pops up completions, they will appear >> above the selected window. Right? > > Right. Since I agree this is not an expected behavior, here is a better > version without this problem. Instead of display-buffer-overriding-action, > it uses display-buffer-alist because only display-buffer-alist > supports a condition necessary to check for an active minibuffer. As a rule, code must never fiddle with 'display-buffer-alist'. If anything gets wrong, the user is left with a broken customization. If 'display-buffer-overriding-action' is not capable of handling this scenario, then it's useless and we have to provide something better anyway. Now 'display-buffer-overriding-action' has the same deficiencies as 'pop-up-frames' and 'pop-up-windows'. If you bind them around a minibuffer interaction needed to find the buffer to display, you affect that minibuffer interaction and any recursive 'display-buffer' call that interaction emits too. So what we need is a mechanism that (1) specifies a display action for a buffer whose identity has not been specified yet at the time 'display-buffer' (or one of its callers) gets called and (2) does not affect any calls of 'display-buffer' needed to get the identity of the buffer needed by (1). I think we agree on that. So we want to delay the effect of 'display-buffer-overriding-action' until it applies to the buffer the user had in mind when activating the key combination. Since we don't know the name of the buffer yet (and in the worst case the name of the buffer the user wants to display in a specific position is that of a buffer needed to find the name), we need some sort of workaround. I'm afraid we have to agree on that as well. I'm not sure whether checking 'minibuffer-depth' within the function put on 'display-buffer-overriding-action' is sufficient. That is, have the overriding action take effect iff the depth is zero. Please check that first (I have no idea why you didn't try that before and went for setting 'display-buffer-alist' instead). If it doesn't help, we could equip 'display-buffer' itself with some sort of recursion depth and allow the S-M- combination to apply only when the level is zero. We'd need some sort of escape to reset that depth when a user aborts the buffer display action. And it obviously would disallow recursive application of the S-M- mechanism (like the 'minibuffer-depth' check approach). So hopefully we find something better. But as soon as we have found a solution, we could provide prefixes to handle all sorts of -same-window/-other-window/-other-frame and the default display in a similar fashion. martin