From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67993: Selecting buffer automatically Date: Mon, 8 Jan 2024 09:55:58 +0100 Message-ID: <1ea06837-0d7e-46ba-849c-a4bf42929c40@gmx.at> References: <86zfy0g641.fsf@mail.linkov.net> <865y09nmp0.fsf@mail.linkov.net> <4659812e-c023-492a-b810-d9d3cada1ade@gmx.at> <861qauxswd.fsf@mail.linkov.net> <86cyudjdmb.fsf@mail.linkov.net> Reply-To: martin rudalics 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="30931"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 67993@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 08 09:57:16 2024 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 1rMlRb-0007l7-Bm for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jan 2024 09:57:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMlRN-0004Q6-D3; Mon, 08 Jan 2024 03:57:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rMlRI-0004Gw-O5 for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 03:56:56 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rMlRI-00012A-GH for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 03:56:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rMlRO-0000PM-H2 for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 03:57: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: Mon, 08 Jan 2024 08:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 67993-submit@debbugs.gnu.org id=B67993.17047041741505 (code B ref 67993); Mon, 08 Jan 2024 08:57:02 +0000 Original-Received: (at 67993) by debbugs.gnu.org; 8 Jan 2024 08:56:14 +0000 Original-Received: from localhost ([127.0.0.1]:35150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMlQb-0000OD-MB for submit@debbugs.gnu.org; Mon, 08 Jan 2024 03:56:14 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:41433) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMlQZ-0000Nv-CC for 67993@debbugs.gnu.org; Mon, 08 Jan 2024 03:56:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1704704159; x=1705308959; i=rudalics@gmx.at; bh=iaf8M3OzCjl1dR5oLrW2UYMoZ7qQSIWBxTb4zEJ2Sb0=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=fZaa4hL1BrZghQLdcQjJ5zvzucRIVmXop67hTOr8YQ7djSDsVIR34TTj1IUFUJWw jEW94ILkOwnVL0ladbT9QoWgyf02OlJl0oFNUHM3Z+WwlcUqKj+rBRv5icpN/blBS PCffx9MhmhZeY1eAVnv4uiXOnObHCFEym/Hs8ZcvQ25PCNPr8yciA9IckpDPRItaT NQ3mZo1hhLUMM8wLkBYGYuekXnM5KB5WZZQRi4vNDGfjiDN3y1n4HWfOoY5+8XYOC xHN2orP/nsVGV8T8Ee5dinHpqtM2d1ai0vWSCp1OI+qxnYQUChIGlImfavCZ+HcNR lLVwmwLt2gehRRsrJA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.143]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MyKDU-1qzZhK3Fym-00yjVq; Mon, 08 Jan 2024 09:55:58 +0100 Content-Language: en-US In-Reply-To: <86cyudjdmb.fsf@mail.linkov.net> X-Provags-ID: V03:K1:x+Ll+yU2PxhggptqHGcQU0/ozpG5hqKHPHQz6h9HO944A+2KPZv rlYS4vdHL48itiEzqyl6kUZtPadfuYMEyXR4WJV0FdpH2q6LCVoLeArMq6c8QcCBMsq+ySm l6r7/MEvFoh0zvhYopGmLU5eJZceODJs/VUqqEKmhQvJdBVl87qDcMbTWdJi8oML8VNKHS7 kU9VE/rAeh7uszStAB3+w== UI-OutboundReport: notjunk:1;M01:P0:vX8oPBLdtz4=;By1T28YFWeKbnlxFeVhx6jWc6xc oXlFtbt6AoBwr8e++0GX3iciDjW2QnsR+1J9tyzA/8+Cf4PTR/iL5omBgCYAfSko2CkXTXPfr aINSpRWdKyKHMJpUPy6TRlmCid7j6obDKyYF93H2zQt+1pAyeejPLPv2avgnedL/jJaz9hgV4 w7n8Akb1eoPFKK8acW7hSqv8DSr+IaWV087h04cni+ivm3k43ShVoAsrXLlGYXvMWsxqV505r A96mscXz8WCvoBlROhJNf4tKTVydXS8nd494Gp9StHZOcx092EvgnqwmHzfbtC/5DI2dh2yim 2q/T4+R4x/N+JZbiiTxctSuGpG7Zma4HgHSqsV9kgg6+anC0jWf8UEtRgeQjlAU8xIuKx+HPS KvjO3O/x3QixpekmPFpQTbdGI78LtTa3haTA0kKrSc6xUpXTiv2upzU5R1zxkzbHTbsjJKtFC lHoFq6TUm/skM0sXNAdAGJSaaem1B2o/YYOmYMsljnmNDUutD7pH1U8GVU77b6AmDld6KeDGu hbYvGDOKsDOuKqjZWQbNBxvFXALvCX3gPGMcFjRbKOddfqCyJq2AujlvUOxixsCtSHRjj0ceZ RpQBoEjn+8XyhhttDKLbZz0Pps/2UGqUKNbgxtsYDmGzS2gDPhcPsQOmpDvKR/1ybOFSrujGP H4t0Z2/PvZDX3mmF06Gs8pYiQVe6UchgVCXftBt2lXn0bCYAoOHllbZRmHYEHgQkZfh84rhb9 BOneZbO5X/iUJmKsmbwHb1DxNcW6xA76i7RW971dR/nMdRIdUSbMnE0BL1l0Gp5u1dwNrWs6 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277541 Archived-At: >> In 'display-buffer' first save the selected window as >> old-selected-window, display the buffer and in your code select >> old-selected-window instead of (old-selected-window). > > Unfortunately, this is not so easy to do. 'old-selected-window' > should be reinitialized before the next command is executed. Why? As I imagine it, it would be let-bound in 'display-buffer'. > So by definition 'old-selected-window' should contain > the window that was selected before the current command > was executed. I have no idea how to do this without hooks. Hmmm... I have problems to see what the "current command" is. One and the same command may contain multiple invocations of 'display-buffer'. I thought you wanted a 'select-window' entry to be handled separately by each of them. Otherwise, IIUC the entry provided by the last invocation would prevail any entries provided by previous invocations. How would you explain that to a user? If you want 'old-selected-window' to denote "some" state before the "current command", the function 'old-selected-window' might be a better choice than a variable you bind in 'display-buffer' (but note that redisplay may occur in the middle of executing a command). But if you want to interpret "current command" more strictly, you need a separate variable, say 'pre-command-selected-window' that you always set in 'pre-command-hook' and consult (and maybe reset) in 'post-command-hook'. > 'pop-to-buffer' can't be changed because (select-window . t) > should be handled only at the end of the current command. Are your sure that you do not somewhat arbitrarily restrict the scope of this feature? What if (select-window . t) were to be handled in a call from within a timer? Would you ignore it? > So this also need to run 'select-frame' in post-command-hook. 'select-frame-set-input-focus' maybe. Or, what's worse, undo the consequences of a preceding 'select-frame-set-input-focus' call triggered by 'pop-to-buffer'. That's why any such 'select-window' call (or its avoidance) you propose would be better handled within 'display-buffer' and not later in a 'post-command-hook'. martin