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, 15 Nov 2018 10:13:10 +0100 Message-ID: <5BED38A6.6020206@gmx.at> References: <87efdnsp2k.fsf@mail.linkov.net> <87bm7bru1c.fsf@mail.linkov.net> <5BD963C8.9090905@gmx.at> <87h8h195ki.fsf@mail.linkov.net> <5BDAC159.1060008@gmx.at> <87muqsh11q.fsf@mail.linkov.net> <5BDC0E81.1050806@gmx.at> <87tvkwh4bp.fsf@mail.linkov.net> <5BE00F12.5000703@gmx.at> <87d0rjuq8c.fsf@mail.linkov.net> <5BE15552.4040507@gmx.at> <87y3a5rgm2.fsf@mail.linkov.net> <5BE2AF28.2020505@gmx.at> <87bm6zme24.fsf@mail.linkov.net> <5BE54FA1.2030004@gmx.at> <87k1lkllud.fsf@mail.linkov.net> <5BE7EDAD.9040808@gmx.at> <87tvklx4je.fsf@mail.linkov.net> <5BEA94A7.20809@gmx.at> <87r2foa8gq.fsf@mail.linkov.net> <5BEBDDCB.6090608@gmx.at> <87va4zfapq.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: quoted-printable X-Trace: blaine.gmane.org 1542273141 830 195.159.176.226 (15 Nov 2018 09:12:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 09:12:21 +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 15 10:12:16 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 1gNDhA-0008WH-M1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Nov 2018 10:12:16 +0100 Original-Received: from localhost ([::1]:37577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNDjG-00011u-KF for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Nov 2018 04:14:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNDj4-00011C-9s for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNDit-00051U-1V for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48733) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gNDis-000518-Ga for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gNDis-0007wp-7R for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Nov 2018 09:14: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.154227320730500 (code B ref 32790); Thu, 15 Nov 2018 09:14:02 +0000 Original-Received: (at 32790) by debbugs.gnu.org; 15 Nov 2018 09:13:27 +0000 Original-Received: from localhost ([127.0.0.1]:52991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNDiJ-0007vs-B7 for submit@debbugs.gnu.org; Thu, 15 Nov 2018 04:13:27 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:51145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNDiI-0007vf-0S for 32790@debbugs.gnu.org; Thu, 15 Nov 2018 04:13:26 -0500 Original-Received: from [192.168.1.101] ([212.95.5.247]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LqALY-1fsXfC0hvM-00dp2W; Thu, 15 Nov 2018 10:13:18 +0100 In-Reply-To: <87va4zfapq.fsf@mail.linkov.net> X-Provags-ID: V03:K1:iGV5yfX1FO6HuYuiPNXNaDK0/dQPpwcSOc9X37EpPqXup+fxT9m 5t90VZHxsQJfqagjaN78AXR310NMLDDhU8m3XwHu8whkY3jv27ycwv7pCazyAF9nTlchfIg SRDqUFC8UdDNwv65q4Z94nleNInBu41HX4j5h/7JkZrI4Lmfg3LGsmkQLNjLY1EhPeEnz4w oKm/eLQy1kjqxe6a4s7Gw== X-UI-Out-Filterresults: notjunk:1;V01:K0:0Fb/wTLw1SU=:ArmR4yZ3lownfOZc9LA/XI yDEjndiOTqYJTc2C8gzsW74359iNjpCqruC/YK7uTfrep6sTJSWlNFz58FIegMDxXhplHlA7p 088NwGmSMgAmMl1sZxLB2NXiSgW7vXXlt5VJ+Q+wLR0QDy+dwZPVKEY3UJjPKRIa4nGI93NDg HY7H8SGEuHTd2mHr/57mRLSIFEgkVI6E8nirJYxuEGgp5doyTblBeHWowuVcSEU+/Jf6kmT7M OzCONM0rQTa8lDTQB9Ekb8sTqGaEfCYOYKhvhbFLk+lhEWDvXhOFBA1vrb76lYrCq6woyaZTv L6HUVV6HBg0Sx90NPDovornLmbkslb01bBgh4yAuwbAyTgqrnPw1ifnsG1VgFZl/Ey1KSGHTs KbsLtWrA4qbFIZuzPI+cGdDD9xtjeEAaCsGq4DJOye0sfZLsKrciVsuqz7oPF2pXnM2ynPxyH m77UKzcDWpgPSErkD8pTXJyA6zW9b/Y8zG9i2zwPs2Icvtm80mBXp2JPA6/YnFP2lIf0e1rc1 bPLjju5yak4QQiTfwFzGKyhbgOvmfeRjud2kRXv8WC6Z7IBfjUykcEwAr3U92xCh16v1Ult8Q RLXsxy+RWsQwV+30f8qFXkXa/TIN38LwMs2odyHeIv2RtVXFOzrUDwGhOl8lpzVrHhLvnLQFT ZCKXkB0H5rHiUx6kEnOOHeIeAxnV5Xyd2Mk/6O2/v0ZEo3JZ+UDLco+9dm59CqhJdaUDFn90U KP9hzjA6o9jFN+r40RZn2LcRGUrapZY8zttVn2pHyvYYV88ufxddO6XbHWUVRkTUhZdUIFvw 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:152407 Archived-At: >>>> I'd invert these: The "-display-" infix implies that the buffer is >>>> displayed and not popped to. >>> >>> Then easier just to rename it to windmove-pop-in-direction >>> because most commands use pop-to-buffer, so this should be >>> the default. >> >> That would be much better. > > The name 'windmove-display-in-direction' is more intuitive and still > correct because it displays. Select/no-select is a minor detail > that depends on the prefix arg and a variable that I propose to name > windmove-display-select. OK. We can easily add the "other" one later if there's a need. >>> But currently I'm more concerned about inability to use switch-to-bu= ffer, >>> i.e. trying to display a buffer in another window with =E2=80=98S-M-= down C-x b RET=E2=80=99 >>> doesn't work. >> >> You mean wherever we can't use 'pop-to-buffer-same-window' instead? > > Yes, and 'switch-to-buffer' should not use 'pop-to-buffer-same-window'= =2E You mean uses of 'switch-to-buffer' in code that we cannot (or are too lazy to) replace with 'pop-to-buffer-same-window'. Right? Because ideally code should not use 'switch-to-buffer' - we had quite a number of reports that the point restoring mechanism conflicted with the purpose to show a preselected buffer position in the selected window. > I tried to set switch-to-buffer-in-dedicated-window to t instead of 'p= op'. I miss you here: Above you say that you want to display the buffer in another window. But setting 'switch-to-buffer-in-dedicated-window' to t is useful only when you insisit on using the selected window. > But I see now it's not worth the trouble to handle dedicatedness in > 'windmove-display-in-direction' because it's not a general solution. Windows have been often made dedicated so they get auto-deleted as soon as their buffer gets buried or killed. This use-case should now be handled by the 'quit-restore' parameter. I have no idea whether windows are made dedicated for any other reason. Do you? In either case we can easily add an action alist entry telling 'display-buffer' whether to reuse an arbitrary dedicated window. > Maybe simpler to rebind 'C-x b' from 'switch-to-buffer' to the command= > 'pop-to-buffer'? Is 'pop-to-buffer' equivalent to 'switch-to-buffer' > as a command with only difference in select/no-select behavior? 'pop-to-buffer' does not try to restore the previous position of point in the chosen window. martin