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: Fri, 02 Nov 2018 09:44:49 +0100 Message-ID: <5BDC0E81.1050806@gmx.at> References: <87efdnsp2k.fsf@mail.linkov.net> <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> <5BDAC159.1060008@gmx.at> <87muqsh11q.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 1541148247 10890 195.159.176.226 (2 Nov 2018 08:44:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Nov 2018 08:44:07 +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 Fri Nov 02 09:44:03 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 1gIV3i-0002id-Vn for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Nov 2018 09:44:03 +0100 Original-Received: from localhost ([::1]:50264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIV5p-0003Qz-Ix for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Nov 2018 04:46:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIV5h-0003Qu-9Q for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2018 04:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIV5e-0000PJ-4r for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2018 04:46:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54982) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gIV5d-0000PB-W8 for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2018 04:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gIV5d-0006Rr-S7 for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2018 04:46:01 -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, 02 Nov 2018 08:46: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.154114830924720 (code B ref 32790); Fri, 02 Nov 2018 08:46:01 +0000 Original-Received: (at 32790) by debbugs.gnu.org; 2 Nov 2018 08:45:09 +0000 Original-Received: from localhost ([127.0.0.1]:59240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gIV4m-0006Qe-T7 for submit@debbugs.gnu.org; Fri, 02 Nov 2018 04:45:09 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:55749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gIV4k-0006Pw-Lc for 32790@debbugs.gnu.org; Fri, 02 Nov 2018 04:45:07 -0400 Original-Received: from [192.168.1.101] ([213.162.73.248]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LyEqr-1fVX6F2dl7-015cNd; Fri, 02 Nov 2018 09:44:58 +0100 Original-Received: from [192.168.1.101] ([213.162.73.248]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LyEqr-1fVX6F2dl7-015cNd; Fri, 02 Nov 2018 09:44:58 +0100 In-Reply-To: <87muqsh11q.fsf@mail.linkov.net> X-Provags-ID: V03:K1:yMqvnftGoCx+XIS/BKST3D+apag00R0ni7rfqMsqoh5rjsTzE9O Yf/20VadhJgDsBm5BTOTywgnW79C5JoTHVCa1zl3Lv3j2xkYyIN0gKvxnCy/oBPDQg5J8z6 UYwnxs1tg0nHk4ryXzFLE+DMjd7XDxYKiycHFqQlGe2+D9w37iNjOVSQn9zwBG43phy8XLI XLsIABf4sW4ybTJzuPjtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:pwnaoc9rp6I=:dHfU8/Wr8wuuNpwYAUuPk2 dZatBwf58azxiCCKsmb6wD5b/AFtvM1m8juQ6GtWiXrzNsOu12p2PFj0LSeeW8n0Qk9IQUCKp ELnXd4vpd18RVrFeZUIk/dK0Wdx0i+C1O4RzY21jEyppc1/rbrM0/YIum6QTes/OO/7JoCaud kAlZ/lFwXa4Q5ALvx/hnghgA/k3EnI23wa/s4t5RErunELqZcK57ddHdyWRPcsDcsw/VIpbWi A3S0wl7i0QVEuxx8D9M/V4LTwKeLPEhGDz8E/1XZh46ci1JeVT0+luxKfzQZfB1fOSiZ9BeFJ NdaBkSx0Nz6570kACHXjPRg1QZI+I7uTWfcuW0lWDkGqozsFNaNJ5NVaJ3zqaNc4G1dvT6bTz O2y2dX87K5sZ1xKjQ+VYzkAAZnQhjjyZrogAae4pbvYpSfZn8Gq5nrpUKWMyslbOzS+hYSIGy b8hSpwppW0/agdKaW5WHM7lHmcjIG1nayljhaGpWkqw2N14BHN1Y90xxSz3EN1qRl/Y9gh+E+ xGYwAIw49QWuo5UmtRi72bFKmfej2thpFWx95t9w6e0/Mmi2am18QHpjbND1Ikq5naNEl8Nkg XrNKh8IyEH+eO2twX5DWu2Vk7DUJ93hW3tHDYxN+hfUAVd/CoOSBAYCjJP06hbwoxfC8XRbo5 2uZ1i2eSXKvr5+/Cwh1eJhyrcDOQdCYt/zqwopvuJOawOZkvHPTiwT3xY8Tnj3dEyil3gY/cP qLLdUHcXNZu/5DH53FCoSSTKto/2UKg6L7s67Dg9ms/zo/SIkLPGLkKBJS6hSaPSicgxBO1L 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:151944 Archived-At: >> 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? > > This is intended behavior - the window is split, so you can see the > window where a new buffer will be displayed after you invoke > the next command (e.g. 'ffap'). Looks uncomfortable, unprofessional. Do you think we can ever sell that? >> 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. > > An example of "next command" is 'ffap' in the earlier example. I understand now. >> 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. > > Yes, this will allow using S-M-up from the active minibuffer. I had that in mind as a side-effect. But we should really get rid of this split-first-decide-what-to-put-there-afterwards approach first. > Yes, killing the buffer without deleting its window will display > some random buffer in its place - this is bad. We could display a buffer that was previously shown in that window if there is one. But I think that such a buffer might be there just due to a temporary excursion so I don't think it's a good idea. > I'm not sure if switch-to-buffer should use pop-to-buffer-same-window, > probably not. 'switch-to-buffer' obeys 'switch-to-buffer-preserve-window-point' while 'pop-to-buffer-same-window' doesn't. That's the main reason to keep the present code (and one reason to replace 'switch-to-buffer' with 'pop-to-buffer-same-window' in Lisp code). There is also that special handling of dedicated windows but I doubt it's ever needed in practice. Dedicated windows are Stefan's department and while I had to live with the ugliness of 'display-buffer-mark-dedicated' it also relieved me from caring about specifying dedicatedness in buffer display elsewhere. martin