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: Tue, 25 May 2021 18:28:48 +0200 Message-ID: References: <87h7j0wwkf.fsf@gmail.com> <87cztg41zy.fsf@host.localdomain> <878s434ls1.fsf@host.localdomain> <877djn3r3i.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="21681"; 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 Tue May 25 18:55:33 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 1llaL6-0005UR-1j for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 May 2021 18:55:32 +0200 Original-Received: from localhost ([::1]:52830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llaL5-0001Zt-2A for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 May 2021 12:55:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llZwT-0001ON-12 for bug-gnu-emacs@gnu.org; Tue, 25 May 2021 12:30:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35077) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llZwQ-00036G-TA for bug-gnu-emacs@gnu.org; Tue, 25 May 2021 12:30:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1llZwQ-0003FM-Ja for bug-gnu-emacs@gnu.org; Tue, 25 May 2021 12:30: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: Tue, 25 May 2021 16:30: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.162196014312381 (code B ref 48493); Tue, 25 May 2021 16:30:02 +0000 Original-Received: (at 48493) by debbugs.gnu.org; 25 May 2021 16:29:03 +0000 Original-Received: from localhost ([127.0.0.1]:46623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llZvT-0003Dd-3n for submit@debbugs.gnu.org; Tue, 25 May 2021 12:29:03 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:48005) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llZvQ-0003D6-SL for 48493@debbugs.gnu.org; Tue, 25 May 2021 12:29:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1621960130; bh=+sXrPRRBBexsC0DGkVCuuJbregypxPx43skTCA2jZQI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=GAimk2wJTROz6nu97pzp0g4eY7dCyCYjRJj06RqCdCxdTYncXB+KF2RGXw0Gles+d Fy14bYXqex2u96iY9TbB2q0hTiPIapPJcItwPRzKkQW8JtEHiAr/DEcX8IZkSi08gL QovoUmlNGpvn2ngqucKfPA/KHE2ylAuk04btG9C4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([213.142.96.199]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MaJ81-1lxRt11Vrh-00WDXP; Tue, 25 May 2021 18:28:50 +0200 In-Reply-To: <877djn3r3i.fsf@host.localdomain> Content-Language: en-US X-Provags-ID: V03:K1:0iRnRAJU+1OgdCSXz4tzmFa0t4wIT0pe6a/ugxtctEhy+XZC7al tCZ/wjh+QLTizv0OfJig/c0TGVOHsSyW++69IDjUJr+Z3h4N4Arngd9yQd2JId8z7q9K/Yq EpKk4T3ltYv2CDzmDBIF2eoAdY+wkodKa8ZquRZaxX5fLm/zML5kSEjcEJWjXRE5HSkz+8k DDB1hef2aXFG5oF3TFqlQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:arBuzWwi3W0=:mTmhy+B05cIx7LViwOJI4c o3ezK/55tjTlS7DG/2s06FFa4Xing9eVq7tL9NudlPn1kWENbIJdUujoBvtO1rOk7euj+AYbS tL0miPwBaYFS4klGeo0oQBZnKuqpzeAW2Ij321deYWyI+msKo9SkaFZTL2czy8ppov2BipC3v 6L2nWaF0/dMRRMPFeXGetnp4GyVviAF/a5BBufa/YLWnD67QE78wPP+VhwvvsynhEc2N5+s+G oi1Q7PMpRF1JszWnOJpDF1eKLm46dzs6AHQmMU8ZkN7D/hdy7ArzBMPU3byvjaLT78TcOYfhd gRqpPuA5ImQKE8awgt2lRKTDA+46zoP3hxqc9f9eKzLziBXtEQv4OQ1wKy4pt2z70sEgFxbsm z7uKEtSF7C0HmLWww2QdUsZumQJG/UgfOzy3V92VjyNoZtonZCc1ICeWdVtGzkfBv1lD3/fWD 3gvxzNoIjuSpxLW8UD4YoTCZRUJNRpiKUIVq1UCtDmhailfAcppZiLKxBM7a/6RZG2NKloq+/ t24GUJ2GOn9NTErKTLwOeKXB1MhWZesHG171wgY1g+Lgm90SuawyyaCv3BJGbdr9F5Hw+4I9P S1MavSECT78zn5dTrg6BApbmoEiomRBS4ieSbNFN8IFFp4tzxYrp/E7TSgISZwVo0+sy1v0lz GcgbozgtkSS9/rchXWasjhV4YtYFeqkoTky0fwox32kMJnTbxZuVP+tFhppJNjhDrnDligfLo JnyAycao9ZGFHGmIgg1d8uKr6oCactLs9SkDESLh/X/IU53APVHjqHucUrxdqsK8onpatw85 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:207223 Archived-At: > Which is what I think you are asking and IMHO ask to deal with the > dedicated window state to not cripple side-windows. You're right, I forgot that side windows are by default dedicated to their buffers. The dedicated flag in a side window serves to prevent "normal" buffer display to "avoid" that window. A side window may be reused for showing another buffer only by `display-buffer-in-side-window'. This sense of dedication is somewhat different from the normal sense where killing the buffer always attempts to delete its dedicated windows (and maybe their frames too) first. Hence it is perfectly valid to switch to the previous buffer here - any such buffer was meant to be displayed in that side window. It would be, however, invalid to switch to some buffer that was never shown in that window here. Note in this context that we can always delete a side window, a side window can never be alone on its frame. > Thanks for the snippet, I think I am confused by this window dedication, > please help me to clarify my mind before I try to implement a solution > with or without the dedicated window state. So maybe something like this might cut it: (if (and prev-buffer (memq (window-dedicated-p window) '(nil side))) ;; If a previous buffer exists, try to switch to it. If that ;; fails for whatever reason, try to delete the window. (unless (switch-to-prev-buffer window bury-or-kill) (window--delete window nil (eq bury-or-kill 'kill))) ;; If no previous buffer exists, try to delete the window. If ;; that fails for whatever reason, try to switch to some other ;; buffer. (unless (window--delete window nil (eq bury-or-kill 'kill)) (switch-to-prev-buffer window bury-or-kill))) Tell me whether this works with DOOM's `kill-buffer-hook'. If you feel that it's more natural to delete the window in the case at hand, we can consider that too. But suppose someone uses such a side window for something more permanent like a compile or shell buffer and the backtrace buffer kicked in only accidentally, then deleting the side window when killing the backtrace buffer might not be a good idea. martin