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: Sun, 11 Nov 2018 09:51:57 +0100 Message-ID: <5BE7EDAD.9040808@gmx.at> References: <87efdnsp2k.fsf@mail.linkov.net> <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> <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> 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 1541926271 21348 195.159.176.226 (11 Nov 2018 08:51:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2018 08:51:11 +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 Sun Nov 11 09:51:06 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 1gLlSU-0005SX-6K for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Nov 2018 09:51:06 +0100 Original-Received: from localhost ([::1]:41393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLlUa-0002EZ-Na for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Nov 2018 03:53:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLlUP-00024x-Qt for bug-gnu-emacs@gnu.org; Sun, 11 Nov 2018 03:53:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLlUM-0003bE-Hp for bug-gnu-emacs@gnu.org; Sun, 11 Nov 2018 03:53:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41018) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLlUM-0003ac-E6 for bug-gnu-emacs@gnu.org; Sun, 11 Nov 2018 03:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gLlUM-0005jg-8X for bug-gnu-emacs@gnu.org; Sun, 11 Nov 2018 03:53: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: Sun, 11 Nov 2018 08:53: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.154192633221977 (code B ref 32790); Sun, 11 Nov 2018 08:53:02 +0000 Original-Received: (at 32790) by debbugs.gnu.org; 11 Nov 2018 08:52:12 +0000 Original-Received: from localhost ([127.0.0.1]:45273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gLlTY-0005iO-Ix for submit@debbugs.gnu.org; Sun, 11 Nov 2018 03:52:12 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:50625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gLlTW-0005iA-Ae for 32790@debbugs.gnu.org; Sun, 11 Nov 2018 03:52:10 -0500 Original-Received: from [192.168.1.101] ([212.95.5.227]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzYY2-1fPnSE3tD8-014htA; Sun, 11 Nov 2018 09:52:01 +0100 In-Reply-To: <87k1lkllud.fsf@mail.linkov.net> X-Provags-ID: V03:K1:OD5ggDZBt1bv9fxoP924QQDvp8RxYdxae7ERJJESJYHMQYT2M+1 TMZZj0yvyMIwem64QsB+Bw2GcBnaxD0tHU4nodWYuW07yzblpBZNuiyergeLF26BsQA4nW3 DhEyzzC/NKmQ6ifds0JIijRgWvN+gHeYdomqZszy8bi/eiD+2WeYd2xp1PxKfhgd5o8CO2L Ne6nyLMsgBA5RIQozzWCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:JjLE7u+lbZU=:Nc7QIs5SVTmtr7zsxFmRAb lluPnseB45B2UT50u8sGuBm8PUqcupWXzxFPdjiRZu94NbY8hYfATicIddbdDItaQlS0HHmk5 t2ESAeAEzY7O6Ktr8P802BcOLcgjnOl/Ye5xQFzlMFOJrMIooKpR2NioaP9bKMjLkUNaopKUB fpMgHdI9buumkPYXC0atTpB4uRI74oszf4Nl0NMCWnSD5CiCQN2Pur1bu/0y0ObbGS/MGPHXL KQWMRxJ8WmKv+NUoHrw8Bz0sa0Uy+6vJOWScItEDkL0Gka4mfXc/2Ulml6ETIvHqvl69AEuqK 5oRe+ER5elErW+oZ4M6EmatPuRME8jRYN2Z7/j6fK2L9JmvMyi5BwDnIFEQIgCT54KKEAHNtg q/OrE/kCqbogf8UndRV80BWFG8TQRfn+FcakDDEmHbhL7W2XWnneExS4ExM6pPTwcYE0LquNI c0LPAGRzdfkBXM76Afm6dZb4aM8j0SuCctbAyz9Y949frKMiPXMYdiHyOk32KHJ8vHHRApP0E e6lSAEq4F/Gp8rcsnb4asgScK19DRu3q5HaQKLU6JuWkhJ/dmUyGGSLgpCVRpOPkxnY9gA1zi PW18oikApn+FV89Tt5ZsjGnqE2B5gly0kB82zhLGICW4Gm5/mx8Ry2eO6CuyWWd/MC8k++k+H VW04JjEO6J4QfI2CpJXOuzLpmwjlN9M2RwIsviIjODjYgfAyDtq68zkyup0sE39BNeW5CS17Y TaG1ugSqjcpE5wNpRVmbxW2SEjgfJuwhjtVA3AvE6jOX5VdnDx8Jce3zObIUtCLihTWUjZYw 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:152287 Archived-At: >> Shouldn't (selected-window) be actually (minibuffer-selected-window) >> in these cases anyway? Otherwise, we probably should invent two >> scenarios where either of the above would be preferable so we can mak= e >> a decision. > > Probably you meant (or (minibuffer-selected-window) (selected-window))= Something like that, yes. > This summarizes the prefix keys where 'default' is the default > window selection behavior, and 'window-noselect' restores a previously= > selected window: > > default window-noselect > relative to the position of point no prefix M-0 > relative to the first edge M-1 C-u > relative to the last edge M-- 1 M-- I would drop that edge thingy, interactively. I'm quite convinced that nobody would ever use it. IMHO this "relative" code is there for historical reasons - the author wrote the simpler edges versions first, wrote the point version later and didn't want to drop the edges versions then (maybe also because he wasn't sure whether the point version would always work). What I doubt is that a user would ever make the relativity choice interactively. Rather people would be used to one or the other. > But maybe also another choice 'window-select' should be added to > force window selection? I mean that some commands don't select > the displayed window by default, e.g. help commands like > 'C-h e', 'C-h f', 'C-h v', 'C-h k' after their invocation > don't select the window with the *Help* buffer. With 'help-window-select' non-nil they should always select the help window. > Or maybe a prefix key should invert the default behavior, > e.g. 'S-M-right C-x v =3D' by default selects the displayed window, > so =E2=80=98C-u S-M-right C-x v =3D=E2=80=99 will not select the windo= w. > 'S-M-right C-h e' by default doesn't select the window, > so =E2=80=98C-u S-M-right C-h e=E2=80=99 will select the window. That would confuse the hell out of me. I'm not sure how you or others feel, but personally I would prefer a fixed two layer choice like: (1) The select/no-select choice always bound to one and the same prefix key _regardless_ of the default behavior of the function (for the buffer at hand), and (2) in addition to a window relative to the selected window (above, on the right, ... a new one always made by splitting the selected window) optionally allow a window relative to the selected frame (on the top full-width, on the right full-height, ... a new one always made by splitting the frame's root window) bound to another prefix key. Then (2) could be generalized via a global option to use/make a new (child) frame in the indicated direction or whatever people want. martin