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: Thu, 01 Nov 2018 10:03:21 +0100 Message-ID: <5BDAC159.1060008@gmx.at> References: <87efdnsp2k.fsf@mail.linkov.net> <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> <5BD81D97.2000000@gmx.at> <87bm7bru1c.fsf@mail.linkov.net> <5BD963C8.9090905@gmx.at> <87h8h195ki.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 1541062994 29195 195.159.176.226 (1 Nov 2018 09:03:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2018 09:03:14 +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 Thu Nov 01 10:03:09 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 1gI8sa-0007Oc-S1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Nov 2018 10:03:05 +0100 Original-Received: from localhost ([::1]:40108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gI8uh-0008RE-2M for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Nov 2018 05:05:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gI8te-0007XC-Dv for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 05:04:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gI8tY-0004Pk-BU for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 05:04:10 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53470) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gI8tW-0004OL-Ub for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 05:04:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gI8tW-0003Gc-HI for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 05:04: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: Thu, 01 Nov 2018 09:04:02 +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.154106302112506 (code B ref 32790); Thu, 01 Nov 2018 09:04:02 +0000 Original-Received: (at 32790) by debbugs.gnu.org; 1 Nov 2018 09:03:41 +0000 Original-Received: from localhost ([127.0.0.1]:57725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gI8tB-0003Fe-EQ for submit@debbugs.gnu.org; Thu, 01 Nov 2018 05:03:41 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:36007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gI8t9-0003FS-TW for 32790@debbugs.gnu.org; Thu, 01 Nov 2018 05:03:40 -0400 Original-Received: from [192.168.1.101] ([46.125.250.45]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M6SE3-1fKIAr0q4J-00yUDy; Thu, 01 Nov 2018 10:03:30 +0100 Original-Received: from [192.168.1.101] ([46.125.250.45]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M6SE3-1fKIAr0q4J-00yUDy; Thu, 01 Nov 2018 10:03:30 +0100 In-Reply-To: <87h8h195ki.fsf@mail.linkov.net> X-Provags-ID: V03:K1:5eo6X/BSOKxKv+fkaB9M8td1VDO/h7sF06gSkB+KZpiRhUNFriP R4wsQn4stlw2yDcumI+aSty1W1v4tiVNyU5nQgrQmaaMuKR7UOlmQhfRS9I1Fh4CTcedrFy UKSBMF3ocQNtw7fnN4+icZgPcKeeCLuCJ4TjPC1gi3buMQVqMshDN1S/gaYaKyGIto6Sw/J 9GufysEnqgkuqDSBPNlWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:gZltGUJN6Xw=:mBYNdEkP+ZbQV5ycJw+0Ju Bp0HpMnBaE7iNr39c8/JCUIvR+Mcl4iyq1k1GXAR4ikWJ0tMO5zqm/3+SGYRwHSMLPmBNglIg csEc0pjhBbOk3PbQTpNnIOGwoKDZ6WMP5pLwYsDfj3FXeYOOm1dLbdxgxpoGy/nq6r08u+/Eh wUx5Zqt3ywn/GtR5kFVLFMr1a/13Jqfk3eIwXqsbkUAjnpXqDe7QjqGeHE2P28M+qOoZAKvnK zig7MZOZLB5fkom3/35VphwjStIRi9bcYDY6dmDudvA0DKmbx0H1swdVImvMu0NV+nHiUrJdI J8fiORtM7Xt4vyvyAGPdF0mCvYcdE638A201pVtr9yicL0cBYwiL4TFlfJK13uicoT8j6R9cO dat8Ym4BBlxHB19XEE2ICCAWhgFfPp77Fz+5II3Kv14/ZqzM88hC0GdIr4K8FMtN14L82PkQ5 GfgK7zKolp5oI2VV2jhbrohL8LRFZVUFKTAcYBYKs55n7YWOe9/iptp6nOq0RWDxGtdGA8evP JAOkKpkWklFMnObl/3IvdEGGmHeI+/xv5CyMW6H3dbTxXJEM1dfIQjH8DVCnedcRZd3JTaN85 7pvO/VO+uaqNOHvoYYprwEZ5EKzixoXymQJnWftXDdY4I5Y2+Nnx9boOUYVDIv65o67ip21Z3 VKaQVQwRfnXUnMjHtb2pQNGDb0J7rkuonjQWJ1CoNksfPV/gFhYZqpkSmyjRmACqllpmqYH25 FBnrZwrjSJdbXKDmWRXlF4R5iSnw3J8ZKDFK+p8aC/XpJf1TXjsQCBg3CdTHO8gYfeHlVzOt 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:151888 Archived-At: >> I forgot (or never learned) how to use it. Can you please include an >> example so people can try it. > > An example is this: [...] Yes. But when I now try your earlier example S-M-up M-x ffap RET RET with emacs -Q, after the S-M-up the *scratch* window is just split. What am I missing? > When display-buffer-directionally is called, it adds the hook > to post-command-hook, and when display-buffer-directionally finishes, > post-command-hook is called, and immediately removes itself from > post-command-hook. This condition ensures that the hook is removed > only when post-command-hook is called after a next command finishes > (while the minibuffer is inactive). Can you give an example of a sequence of events how this should work in practice and which scenario it is supposed to avoid? The term "next command" is not clear to me here. And wouldn't it be more intuitive to check the minibuffer depth instead? That is, let the lambda succeed to do its job iff the current value of 'minibuffer-depth' equals the value of 'minibuffer-depth' at the time 'display-buffer-overriding-action' was set to the lambda. >>> (window--display-buffer buffer ,win 'reuse alist))))))) >> >> 'reuse' holds only for the ?0 case. When we split, the third argument >> should be 'window'. > > I noticed that when replaced with > > (window--display-buffer buffer ,win ',(if (eq dir ?0) 'reuse 'window) alist) > > then 'window means that killing the buffer will delete its window. What's bad about that? What else do you want the window to show? If the window got reused, it's natural to show the buffer it showed previously. If the window was created anew, it's the most natural thing to delete it when its buffer gets killed. If we want to change that, we can add an option. But the way you do it, you completely mess up the semantics of the 'quit-restore' mechanism by faking its history. > Another observation is that switch-to-buffer is unaffected by this command. As long as it does not end up calling 'display-buffer', yes. martin