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.devel Subject: Re: [ELPA] Brief v5.90: neighboring window merge on deletion Date: Tue, 26 Mar 2024 10:57:23 +0100 Message-ID: References: <86il1cvp7o.fsf@mail.linkov.net> 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="40445"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Juri Linkov , Emacs developers To: =?UTF-8?B?6Lev5a6i?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 26 10:58:18 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rp3ZS-000ALl-3v for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Mar 2024 10:58:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rp3Yk-0001lS-Vp; Tue, 26 Mar 2024 05:57:35 -0400 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 1rp3Yh-0001dK-I8 for emacs-devel@gnu.org; Tue, 26 Mar 2024 05:57:31 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rp3Yf-00075g-Pu for emacs-devel@gnu.org; Tue, 26 Mar 2024 05:57:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1711447044; x=1712051844; i=rudalics@gmx.at; bh=4h3wqnrpOK4e+5T8f25nKtu9aotgmJt7uDAkTRIWTMI=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=D1HCDyjbQUs0Wcvgxwran8s5HvnWwaXWCdQ3UaYcO7vBva0aTaUtJGPFgzGQ1kXt 5necE9WZfjQdrm6yBZK+x6q/9VtQq4kKavZJPQMqXUJIquJGqehs8MPz3VBx1gJj/ m+XiQlDQbTS6ldMEaOqKLvDzXXMZTVnwLELajvgUwkodG5tYcfFmZzkusj5Gb4xfW OLYUgBEUqhIQ5Nz5EMk9kWkiC6X52wjkhU6p10+aTWJn2VIsfl8nUinZUOWfCUNov UCPRN0VSuUzVvQ5xGd0iOs7YA4RrBQOodDlC51nVucPqVX2hx36w4b4x2LG4KuAn2 4DI29WJ7VC0zYHIXiA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([213.142.96.219]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0oBx-1slXV32TMT-00wnGX; Tue, 26 Mar 2024 10:57:24 +0100 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:q9tdPz5c7J1E1WIwNl+W576z8OD4bHKXaRJ/gs+Y0Uioh3PGv3B Qsx2TcjGJon8j0BWdk1bKcPFg2NxgLugFetGnEHUxCqePx/7zpBhlZx+WtqlJgLRATDZHlW nIFLu4G7ZKebCylTcdrUSUsQtPVx/njvdHQBl3ndfrRNWGJVA6M3VzgoRWD4vuAtoxI0VZe rPF8D4b47ufhanyzCyw0g== UI-OutboundReport: notjunk:1;M01:P0:5Fn90rCQ6J8=;oDMiEOxcso6odZb+Dcks8qTfAOw ROc74PeNka5UolSctP+zA6Z3dRY4ZJqyU2Enkcb5rFLCUP7l8fUS3o80eZcHjV4Jx7a2Y4X38 yk9rJwvVSJwa/dpimxnNuTwwXZzw2kywv+HPoztHD4+FAniQI7dq6tUszLrvVRIqr59s/ruY7 I3Vov3u97lsdyKrjO6pzfcABG08BFGmyTOZpFhAiclykHUFh2kBhVwovOB+v8hL3Zh/29V6cG y4awXtQoeSsM2VTQNLqg/sNQjOXAID/ywFsTRTkOICg7En86mSiG+waBeXFWbnmYoekN/8DIH ni/iCv/EzaE24Hv14Y133QeX3JhykN22Gj+IURA5vHCO8oyuYLTbFWgKmkoRMjpQUCBJPYAJo j25U2MivnCUFWiSuYJETyAEbMKB2k9rBpdQuDLEvrf8LhNuGKchrTX/BDoqz06uW6Z4S+vCLg puPBUG+kfV+qbIwGFZ+VSiD7vLGYn4HTYkoNDeDkojRokPDgBl/8A2WNeNRgMvJZzZXkgssMv G1HrfS2fGwZhuVNaDvbm8Iwm4+3oRVga9Hu5cYqXSkgTn93v/gMUTl58DER6o/MRLoniyWkL6 /sAxSxk5kgwGrfXDgV100m8nrutn0PIzvbXS6pyqbuMyE2T7kYrUuRpyGsgxJBnoGcjEDCiuH ngiWn12r04KcNP7Phea7x6LIRw/AUij3+APFCUkfMpk0Ea1E6rKJ4WMnr+oCU7FHeMlkO05cm HC1lzme9sucIgF3PVe5jBzADfkWa6jhFTqVCymWKf21RUN0E2SSjhMjPsq+6R0Cpyd6YvTax Received-SPF: pass client-ip=212.227.17.22; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317295 Archived-At: > Is it possible to provide some means so that we can `recycle' or > `reuse' the deleted window ID to prevent this kind of problem? In > `winner-mode' I saw the window ID is restored even after being deleted. > But that seems to be the nice side effect of `set-window-configuration' > which is not available for `window-state-put'. With the latter I can at > best make it a `clone-of' the original deleted window. It would be non-trivial to provide such a mechanism. There are many restrictions that allow 'set-window-configuration' to operate satisfactorily and any new mechanism would have to adopt them somehow. 'undelete-frame', for example, uses 'window-state-put' to restore its frame's windows, probably because its authors wanted to avoid the pitfalls of making 'set-window-configuration' work for dead frames. > However, as an `emulation' mode, we usually can only expect it to be `as > close as possible' to the emulated target application. After added the > `overlay' and full window state save/restoration it's quite close, but > of course it's best if I have a way to do it better -- a way to > `recycle', `reuse' or even `restore' the deleted window ID like > `winner-mode' does. IIUC handling overlays with a 'window' property with current means is much too cumbersome. One would have to investigate all overlays in the window's buffer and duplicate them if they have a 'window' property that references the cloned window. In practice, most overlays don't have such a property. > Actually, even if so, it's still not possible to fully emulate the > `merge upon deletion' behavior while 100% keeping original Emacs > functionality -- the atomic property of two windows will gone if I force > to split them into two different window subtree, which lose the original > intention of atomicity so I might again need to add a customization > option for users who concern more about merging windows than breaking > window atomicity. It's always a trade-off that users need to decide. Atomicity is a property of a parent window. If your operation clones the parent window, it should retain the property regardless of which its new child windows are. martin