unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, 58175@debbugs.gnu.org, miha@kamnitnik.top
Subject: bug#58175: 29.0.50; M-x window-swap-states during an active mark leaves behind a region overlay
Date: Sat, 08 Oct 2022 13:24:26 -0400	[thread overview]
Message-ID: <jwvbkqm1cqm.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <125e8395-b083-6825-d6b7-73ec15b433c8@gmx.at> (martin rudalics's message of "Sat, 8 Oct 2022 12:05:25 +0200")

> What we talk about here is this form in 'window--state-put-2':
>
>       (dolist (parameter (window-parameters window))
> 	(set-window-parameter window (car parameter) nil))

Yes.

> which has no equivalent in 'set-window-configuration'.
>
> The distinction is due to the fact that 'set-window-configuration' works
> on already existing (albeit temporarily deleted) windows while
> 'window-state-put' as a rule has to work on pristine windows.

But the above `dolist` does nothing on pristine windows.
So it's been put there explicitly for the case of non-pristine windows.

> Maybe that aspect is biting us here and we should leave pre-existing
> parameters alone as you suggest.

It seems like the simpler option, yes.

> But doesn't the fact that 'set-window-configuration' handles a nil value
> of a parameter distinctly from "no value for that parameter has been
> stored yet" mean that it handles window parameters specially, unlike
> other window components or the way we handle frame parameters?

I don't follow.  AFAIK the special handling of nil there is simply an
optimization to avoid adding useless nil entries in the parameter list.

> And haven't we discussed these issues already here
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10348
>
> and here?
>
> https://lists.gnu.org/archive/html/emacs-diffs/2012-01/msg00140.html

Thanks for these links.

It was very helpful for me to re-read what those past Stefan and Martin
guys had to say.  Tho it seems they didn't talk very much about what
happens to the poor window-parameters of the target windows, they only
talked about the parameters of the source windows and how/if they should
be transferred to a target window (potentially via a file).

The current bug report points out that we should also pay attention to
the parameters of the target window (because we overwrite them or throw
them away).

>> AFAIK the current code works fine with `set-window-configuration`.
>> And indeed `set-window-configuration` behaves the way I suggest
>> `window-state-put` should behave:
>>
>> 	  /* Restore any window parameters that have been saved.
>> 	     Parameters that have not been saved are left alone.  */
>
> But 'set-window-configuration' does not DTRT when the region overlay
> parameter is made persistent.

But that's because that window parameter should *not* be persistent.


        Stefan






  reply	other threads:[~2022-10-08 17:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 17:29 bug#58175: 29.0.50; M-x window-swap-states during an active mark leaves behind a region overlay miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-29 18:34 ` Eli Zaretskii
2022-09-29 19:17   ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-29 19:19     ` Eli Zaretskii
2022-10-02 16:50       ` Eli Zaretskii
2022-10-04  8:23         ` martin rudalics
2022-10-04 16:54           ` Eli Zaretskii
2022-10-04 20:27             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-04 21:03               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-04 21:25                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-05  5:42                   ` Eli Zaretskii
2022-10-06 12:25                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-07  8:17                       ` martin rudalics
2022-10-07 19:28                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-08 10:05                           ` martin rudalics
2022-10-08 17:24                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-10-09 14:05                               ` martin rudalics
2022-10-05  7:36             ` martin rudalics
2022-10-05  8:28               ` Eli Zaretskii
2022-10-06  7:48                 ` martin rudalics
2022-10-06  8:13                   ` Eli Zaretskii
2022-10-07  8:09                     ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvbkqm1cqm.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=58175@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=miha@kamnitnik.top \
    --cc=monnier@iro.umontreal.ca \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).