From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58175: 29.0.50; M-x window-swap-states during an active mark leaves behind a region overlay Date: Thu, 06 Oct 2022 08:25:19 -0400 Message-ID: References: <86sfkaay2d.fsf@miha-pc> <83a66if2r0.fsf@gnu.org> <8735cauh0b.fsf@miha-pc> <837d1mf0op.fsf@gnu.org> <83fsg6186y.fsf@gnu.org> <83bkqrv8af.fsf@gnu.org> <83wn9eu8qu.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13341"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: rudalics@gmx.at, 58175@debbugs.gnu.org, miha@kamnitnik.top To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 06 15:07:05 2022 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 1ogQae-00038X-JG for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Oct 2022 15:07:04 +0200 Original-Received: from localhost ([::1]:43354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogQad-0006DG-KR for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Oct 2022 09:07:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogPx0-0001vt-Sq for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 08:26:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60204) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ogPww-0000aB-Dm for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 08:26:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ogPww-0007Df-6P for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 08:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Oct 2022 12:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58175 X-GNU-PR-Package: emacs Original-Received: via spool by 58175-submit@debbugs.gnu.org id=B58175.166505913127705 (code B ref 58175); Thu, 06 Oct 2022 12:26:02 +0000 Original-Received: (at 58175) by debbugs.gnu.org; 6 Oct 2022 12:25:31 +0000 Original-Received: from localhost ([127.0.0.1]:59282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogPwQ-0007Cn-EI for submit@debbugs.gnu.org; Thu, 06 Oct 2022 08:25:31 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogPwN-0007CY-I5 for 58175@debbugs.gnu.org; Thu, 06 Oct 2022 08:25:28 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 24F6A443491; Thu, 6 Oct 2022 08:25:22 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6718744347A; Thu, 6 Oct 2022 08:25:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665059120; bh=fac3WJpHcRT7qCEVWiavlagUDAdBwG8LWYJt7WT2GjI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=M8uBcY0uUb9XhRZzuF+zHELfgBpQEIUx5DDiOgK3KjdYmzHmDsjo7Lupr0QN2nonN s3ImRkP+SWNE1lQwXG3E15KXvUBodSLG7wMc71zvmkoDAmlEc4A+2DEck3DyPbY+6q N1GZuiDbdEX+d/PJKX4G48wDnoM51SioCrJf7kAnV+6/D2+mvgaWD//rMKI4uNg24C W5YZUDNbclBWW/qP7HY47/kdTiC8hytSMPqxB0tqk1Mk5/8nLjbf59okO7mKk0akYW pJ69xN0vOAeLX8LNhhp5A9pUfS6qrlyceir90MOrYL7kAMVPqY4UBPmTvk135w0cnr 8P02R6jsQAgYw== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3073F120744; Thu, 6 Oct 2022 08:25:20 -0400 (EDT) In-Reply-To: <83wn9eu8qu.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 08:42:17 +0300") 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:244659 Archived-At: >> We could change the above code so it only sets to nil those >> parameters that are listed in `window-persistent-parameters`, but I'm >> not sure if that's the right choice. It might be, tho: it seems odd to >> just zap properties owned by arbitrary packages without giving them >> a chance to "say goodbye". > > Martin will tell, but I'm pretty sure this wasn't born out of thin > air. Could be, but the behavior is not documented, AFAICT: the doc seems to suggest that `window-state-put` doesn't touch the parameters that are not mentioned in `window-persistent-parameters` (whereas it actually throws them out unconditionally). > I'm sure there are window parameters that will do harm if > copied. I'm not talking about copying. I'm talking about leaving them where they are. >> Or we could add some kind of hook (similar to a `change-major-mode-hook` >> but for window state changes rather than major mode changes) so code >> like the region-highlight code can register itself there to throw away >> its overlays before a new window-state is installed. > Why is this cleaner than maintaining a list of "persistent" > parameters? Notice there are two notions of "persistent" here. Let's say we use `window-stat-save` in window A and then `window-state-put` in window B: - `window-persistent-parameters` lets you control which parameters of window A are "persisted/copied" to B. `internal-region-overlay` doesn't want to be among those copied parameters. - I'm suggesting we add some way to control what happens to parameters that were in window B. Clearly, for those parameters in `window-persistent-parameters` they'll have to be overwritten. But currently they are all wiped out unconditionally just before putting the new state, which is a problem in the case of `internal-region-overlay` where we don't necessarily need to preserve its value (tho that would work as well), but we'd need to remove it a bit more carefully at least. I see `window-state-put` as something similar to calling a major-mode: it starts by "killing all local variables" (i.e. removing all window parameters) and then sets up its own state. I see 3 options: - Change `window-state-put` so it doesn't touch those parameters not mentioned in `window-persistent-parameters`. This is arguably the simplest change and IMO it would make it behave closer to what its doc suggests. - Add a `before-clearing-window-parameters-hook`, just like `kill-all-local-variables` runs the `change-major-mode-hook` (tho, if so, we should design it such that it's a bit easier for that hook to make some parameters survive unscathed). - Add a new variable (or some new special value for `window-persistent-parameters`) listing those window parameters that should not be touched by `window-state-put` (i.e. the equivalent of "persistent variables"). Stefan