From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#48493: 28.0.50; quit-window doesn't work Date: Thu, 27 May 2021 09:47:20 +0200 Message-ID: References: <87h7j0wwkf.fsf@gmail.com> <87cztg41zy.fsf@host.localdomain> <878s434ls1.fsf@host.localdomain> <877djn3r3i.fsf@host.localdomain> <8735u94gt4.fsf@host.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3257"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Sujith Manoharan , 48493@debbugs.gnu.org To: pillule Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 27 09:48:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmAkY-0000bV-Gy for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 May 2021 09:48:14 +0200 Original-Received: from localhost ([::1]:41448 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmAkX-0003Dj-9L for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 May 2021 03:48:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53804) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmAkN-0003DZ-1Z for bug-gnu-emacs@gnu.org; Thu, 27 May 2021 03:48:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39011) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmAkM-0006nX-Q3 for bug-gnu-emacs@gnu.org; Thu, 27 May 2021 03:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lmAkM-0005KA-He for bug-gnu-emacs@gnu.org; Thu, 27 May 2021 03:48: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, 27 May 2021 07:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48493 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 48493-submit@debbugs.gnu.org id=B48493.162210165320424 (code B ref 48493); Thu, 27 May 2021 07:48:02 +0000 Original-Received: (at 48493) by debbugs.gnu.org; 27 May 2021 07:47:33 +0000 Original-Received: from localhost ([127.0.0.1]:50557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmAjs-0005JM-No for submit@debbugs.gnu.org; Thu, 27 May 2021 03:47:33 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:53749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmAjr-0005J9-Mk for 48493@debbugs.gnu.org; Thu, 27 May 2021 03:47:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622101642; bh=CN1kx9Ctp+k5ox/P1RKXRy7dCeB69/Ex0G59bJZqDHc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fc/2vfpOUMDnHjn+TsXmxI12Fp/MB4H1Q8yB8LWaGclfGk77kKWCRniv1oHCgCazF ZvL9OJMOls8arbjEj2LUJOQeDAAMo6Q4OFN/3YtZuFOBiZ2vsAV/hdqmvpjOxxiEFQ N4iHapGdgecQTNn66/ZccV4t6F/cV4T/MY9ndyZs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.167]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MbivG-1l9FLg27lW-00dDaz; Thu, 27 May 2021 09:47:22 +0200 In-Reply-To: <8735u94gt4.fsf@host.localdomain> Content-Language: en-US X-Provags-ID: V03:K1:4+N0nOz2K/5w9Kun0eEqlUNBMJIC9E3HRXQBOh70hhpmWkq514V AdUuaj3vAvyRLAGGhCacupJ4Rm9yCO5NMFpSr292RYCnHzTcVRjXLfSzmKqt+v6x2Wg4Flk Xmhgzd30NivqXTLbarm7GmFvzu9WUxpo8n7cTgBZrONYxI/q56fxMtxcCd+DbBz3npQGfw7 nhI+WVDQy6GMKpiKGAOqQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:FZvvdreTdIg=:6OIHxspVjuW++mrJZFZM9V 8R7veGVlyJwJFbK7RGz6bIklyrnOX/D5Fcg7YAD1K470AOXkIoNS1N6tXvYi6Pt9rv5AL4/0d NnZsEUEgnbD0anot9uWHB5M41HFqGhfsnZprurcOhN7wanaz9XEMnOvSplabQp+S6x0bUJXjB u9SDCiqdeq1jok2RjkSi2FDJGK5w5jPrsqCBj6u62b9ie4dT5a6nMl5qL2jS9BSwKXBwjb2hC lEMTYyN7RfSyd2vCbIMLBY4ZgFXYGE/5MzmMMRCbQYzIl5CxLR3ck8xahIcBHLOUBKx0TjOKZ n8/3mm6pZt00wdOJnZ9PTZuxwZp3vR2AiMykCv9qUKtddFTbmgFrth1u90m/ChGOVM1/4g5Kh nTnr9E0aZ3rH4F7v00Lm2ngrYw7dDZs/VzJjKPTPj1SkpVJcicw726YPq5XewMkWl3FGvVZ7x xuu4mviLB8XuxbdWqtipBsmKNvhg29MnXF/NvvP9mznuixTLan9vIjXLSluowNsI16RQv/jko qORMVydBik3RR0J8CKTfETtVq72XtYu6GMDINSXKWkbw68w7zmrzwlkGW0br+SDzWDjdWbHpe 2qIC8WYN9ZGUAPGRHpO18RKHpyJtKzB6VB3dPjJFV0uoHJN3RMmOqi/TldziLXWznp8wqvmVr hKKrwJIT/eRDpTSK0nUSoU4vNSZghnPdluhyVbUS8Y24/N+b+33JRzt6p3sjMTnLoWBtHsBNs L9sIVjNNpqwX9te4gRW09MLoxFw2acEh4MSiLA35oIBN6roAxPFrnNpfdQVW0ST5Fqn/59HB X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:207360 Archived-At: > I can test the changes against a version of DOOM, yes. For the draft below > it seems to be ok, but keep in mind that their library bypass these parts > window.el You already told me so. >> If you feel that it's more natural to delete the window in the case at >> hand, we can consider that too. > > Not at all. For me it is ok with switch-to-prev-buffer, if users want to delete > the window and/or buffer explicitly, they have commands for that. In the case of > DOOM it is implemented as a workaround against some bugs, it is > explicated in : > > (+popup/quit-window) > Documentation > The regular quit-window sometimes kills the popup buffer and switches to a > buffer that shouldn't be in a popup. We prevent that by remapping quit-window > to this commmand. Maybe this is precisely the behavior you're trying to fix and their fix won't then be needed any more. > So here is the *draft* that pass the previous cases of this thread. > `replace-buffer-in-windows' take care of killing buffers. > I restore the dedication of side-window because : > 1. it seems to me it is the right think to do, and it prevents 2. This is quite a weakness of the present mechanism and I think you got it right. To summarize your approach: - When we have to replace a buffer in a side window, that window's dedicated status is 'side', and some other buffer is found that was shown there before (it's on the list of that window's _previous_ buffers) we show that other buffer in the window and make sure to restore the window's dedicated status to 'side'. - Otherwise delete the window. Deleting the window is always possible and we have to make sure one thing - never show in a side window a buffer that has not been shown before in that window. This rule should take care of the DOOM workaround. And users who override the behavior sketched here by setting the side window's dedicated status to t should have the window deleted (since that is always possible). Have I got it right? > 2. I lost the trace when we kill a buffer and no previous-buffer is found > but still an undesirable buffer replace the current, > is it in the C part ? I can't inspect C... IIUC you mean the one in `kill-buffer' in buffer.c. `kill-buffer' first calls replace_buffer_in_windows (buffer); which simply calls the Lisp function `replace-buffer-in-windows' for buffer (the buffer to kill) and later on does replace_buffer_in_windows_safely (buffer); That last call will show another buffer in a window if and only if `replace-buffer-in-windows' failed to do its work which is an unusual case - one that should _not_ have happened. But we must, in C, simply make sure that such a failure gets caught since showing a dead buffer in a live window can crash Emacs. So if replace_buffer_in_windows_safely shows another buffer, then something in `replace-buffer-in-windows' was already broken before and we need not bother to clean up things. > I will pass the rest of they day to look at ERT to see if I can learn > how to write reusable tests and see if this discussion needs to be reflected > in the documentation. We have to document it in the Elisp manual. martin