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: Wed, 24 Oct 2018 11:45:49 +0200 Message-ID: <5BD03F4D.1000900@gmx.at> References: <87efdnsp2k.fsf@mail.linkov.net> <87zhw8nd8g.fsf@mail.linkov.net> <5BA8A143.9040604@gmx.at> <87sh1ybyo6.fsf@mail.linkov.net> <5BA9E390.8030506@gmx.at> <87pnx1h1op.fsf@mail.linkov.net> <5BAB489E.5090002@gmx.at> <87h8ibvrs2.fsf@mail.linkov.net> <5BAD2507.6040605@gmx.at> <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> 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 1540374486 32746 195.159.176.226 (24 Oct 2018 09:48:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2018 09:48:06 +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 Wed Oct 24 11:48:01 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 1gFFle-0008IN-SY for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Oct 2018 11:47:59 +0200 Original-Received: from localhost ([::1]:47126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFFnl-0003FJ-DG for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Oct 2018 05:50:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFFkn-0000c4-Ur for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2018 05:47:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFFkk-0008Oy-Mz for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2018 05:47:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34817) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gFFkk-0008Os-Im for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2018 05:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gFFkj-00023F-TE for bug-gnu-emacs@gnu.org; Wed, 24 Oct 2018 05:47: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: Wed, 24 Oct 2018 09:47: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.15403743667823 (code B ref 32790); Wed, 24 Oct 2018 09:47:01 +0000 Original-Received: (at 32790) by debbugs.gnu.org; 24 Oct 2018 09:46:06 +0000 Original-Received: from localhost ([127.0.0.1]:39075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFFjq-000226-Ee for submit@debbugs.gnu.org; Wed, 24 Oct 2018 05:46:06 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:48109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFFjo-00021E-Le for 32790@debbugs.gnu.org; Wed, 24 Oct 2018 05:46:05 -0400 Original-Received: from [192.168.1.101] ([212.95.5.202]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LbA4j-1frQJp17dZ-00ki7E; Wed, 24 Oct 2018 11:45:56 +0200 Original-Received: from [192.168.1.101] ([212.95.5.202]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LbA4j-1frQJp17dZ-00ki7E; Wed, 24 Oct 2018 11:45:56 +0200 In-Reply-To: <878t2owo8i.fsf@mail.linkov.net> X-Provags-ID: V03:K1:5v6LWBVrJMOshkelKoWvVVtpUOPVyg89bdcmvb8DKuMRV2w7UwQ 1Fg8neSJ896DPRKw/B1frIVEWbUykq2Aycbq8WAmOx1xPaDW7KbbkSC3iaaWSL4lcb72kmE GBB2S8mpDtSYKg3BRFT2zZjF4JZI0SHUpoparxEp4N7/cGN6eAtYLN8nONMrgP2T7zHKiOS JikbUjoJfrSh2EE5E/HZg== X-UI-Out-Filterresults: notjunk:1;V01:K0:hPz5Cp/aQO4=:Xiyah9/kjgbOkdoG4/72T0 vhDAJLDABAPBjfbvqam8cKXRYrn7kfoPVI5+ijYOppzyLH5KrBQXpoqnv7xj8WXd85suIkovX JajjgUgt3rRZGeUbIYGTtxvpNui8XcU4u4342Ao9eEjCAS1z9aLNNbx5jN6xZmI6DYasProIU G0UuxaeQ3ypJ9p9A9GAm1NOwQQX/309k9jZ5CFaibusugBhTPE39YeU5doUh5hbqLk9bIBAb6 u/neVyznqcV/6ICdh7r0CPHcdbDGYpXKp3gmwCOfdP07JCiiPruWYAuAlIWigipr4gbOMsp09 OzJNK4oYvXhvqtNZsxHFiwcPHLY6nzv4EmJ1qQwfJZC9xqHPzP0Ew0lHMlxC2CEdclVDy3r2y rCaJGDJ8FlV+0QRpX+/mbyD+qxZjct8kz8Ki0lauWVbRy9PrkOEd6CCSmPvsn5OjAqC0X1krU rwXSPdh92xeou3VTrN6lAc8/1RgKmF/yVWERRzHtG3TQ792oDnrATvGQxR7ZijkibeJjeoI8P z4HRmm3apACNkZQAha1lZDw9KiEWdl8vunmU/0Rv4yBaXvRPnb9lnpkobqn84H7Ek9f5gLqWZ elifUaG3CRPb53Kg9ofrQ8SWdRzQ4h1lzWW/rEllb42ZoV6ADDFpe8W7AOvxOljCw27knsbS9 L6JKn8yb5BwAHJN0L5KBCCyQFpiQjTIcYuIsAbP3sKPT8BiysJZbLeq7+9dR67JWypOB+ajBu ALGA1hl6UMjQSxqw5jqQp1OVNmyr2AkqpzFrZ/yZFtgR3vjW0vNSwdPO1pTZl/yXqbe/+wUU 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:151542 Archived-At: >> It would indeed be nice to fix that there in some way. > > There are not too many options that can be supported to make > Emacs window management more manageable. I see at least these: > > 1. If the user knows beforehand in which window to display some > particular buffer, then it's possible to customize display-buffer-alist. > For example, instead of displaying *Backtrace* in a random window > to make its placement more predictable: > > (custom-set-variables > '(display-buffer-alist > '(("\\`\\*Backtrace.*" display-buffer-below-selected)))) That's the status quo, I suppose. > 2. based on display-buffer-alist, implement some more declarative > definitions of window layouts, i.e. allow the user to describe > the used windows in which buffers should be displayed in them. I'd need to see a proposal how that can be done. In a way it's orthogonal to how 'window-state-put' tries to reconstruct a window configuration and it's no entirely trivial to do that. > 3. in some cases there is an one-off need to point out explicitly > where to display the result of the next display-buffer command. > If this will require only short code addition then better to have > this feature in window.el. I think that 'display-buffer-directionally' is supposed do that. But this should rather go to windmove.el because directional key bindings are already in use there. >> Good idea. But IIUC we can't use 'hyper' in Emacs because it is not >> supposed to be generally present and must be bound to a key first. So >> we'd need some other mechanism. > > This is the same mechanism as already used by windmove-default-keybindings. 'windmove-default-keybindings' binds only the 'shift' modifier which is "standard" so to say. Binding the 'hyper' modifier is not standard to my knowledge. We could bind any combination of 'shift', 'control' and 'meta' though. But I think that putting a function on 'window-configuration-change-hook' can be dangerous when a window showing the buffer in question already exists and gets reused. In such case 'window-configuration-change-hook' is not run and the changed value of 'display-buffer-overriding-action' will persist. So we probably need a 'display-buffer-functions' hook to remove it reliably. Basically, however, I think that using an overriding action is justified here. martin