GNU bug report logs - #58175
29.0.50; M-x window-swap-states during an active mark leaves behind a region overlay

Previous Next

Full log

Message #41 received at 58175 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 58175 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, miha <at> kamnitnik.top
Subject: Re: bug#58175: 29.0.50; M-x window-swap-states during an active mark
 leaves behind a region overlay
Date: Wed, 05 Oct 2022 11:28:30 +0300

> Date: Wed, 5 Oct 2022 09:36:40 +0200
> Cc: miha <at> kamnitnik.top, 58175 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> From: martin rudalics <rudalics <at> gmx.at>
> 
> Now keeping the mark active when restoring a window configuration is
> problematic in the first place since it restores the mark from the saved
> state while taking point from the current state possibly ending up in
> some arbitrarily specified region.  OTOH deactivating the mark in such
> case is hardly feasible because restoring a window configurations should
> be barely perceptible for the user.

In the scenario described in this bug report, point is copied to the
new window, so the result is as expected.  Deactivating the mark also
does the expected job.  So it looks like adding
internal-region-overlay to the persistent window parameters is a good
solution in this case.  I suggest that you try that, maybe you will
see some problems that I missed.

>  > If the former, I guess the above should be done
>  > globally when Emacs is dumped?
> 
> I would try to get rid of the window parameter used here.  Active region
> highlighting is an activity that affects the selected window only and
> not any window.  The 'window' property of any overlay used for it must
> always refer to the selected window and not any other window.  So I see
> no use for window parameters here which are mainly useful for overriding
> a global variable or the local value of the buffer shown in a window.

So you are saying we should redesign how region overlay is implemented
and managed?  I'd prefer not to go there.

> I'd rather use one global overlay and move it (by setting its 'window'
> property) whenever 'window-selection-change-functions' tell me that the
> selected window has changed.  But maybe I'm missing something here.

highlight-nonselected-windows, I guess?  How can we have a single
global overlay and still support that option?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.