bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6316: 24.0.50; unexpected region highlighting


From: Stefan Kangas
Subject: bug#6316: 24.0.50; unexpected region highlighting
Date: Thu, 26 Sep 2019 12:17:48 +0200

Stephen Berman <stephen.berman@gmx.net> writes:

> On Tue, 01 Jul 2014 14:14:52 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> However, with your new patch, temporarily enabling transient-mark-mode,
>>> when it is disabled, seems to break transient-mark-mode; here's a recipe:
>>
>> Yes, the buffer "remembers" that it was nil.
>> I installed an additional patch which tries to avoid this problem,
>
> I confirm that it fixes that problem.  In addition, it fixes (presumably
> in combination with your previous patch) another case of unexpected
> region highlighting that differs somewhat from the recipe of my OP:
>
> 0. emacs -Q
> 1. M-x transient-mark-mode (disabling it).
> 2. C-SPC to set the mark in *scratch*, then move point, creating a
>    nonempty region, which, as expected, is not highlighted.
> 3. Open another buffer, e.g. with `C-h v transient-mark-mode RET' and
>    select and highlight a region in it, e.g. with `C-SPC C-SPC M-f'.
> 4. Switch back to *scratch*.
> => The region in *scratch* is now highlighted.
[...]
>> tho it probably comes with other undesirable cases.
>
> I haven't found any new ones yet, and given the above problem, I would
> be in favor of backporting your last two patches to emacs-24 (sorry I
> didn't notice the above problem earlier).

Good.  That confirms that the original issue has been solved.

> There is another apparently longer-standing behavior (at least it
> happens with -Q in 24.3, as well as emacs-24 and trunk), which I noticed
> while testing you latest patch: if you mark and highlight a region in a
> buffer and then call e.g. `C-h f' or `C-h v', when the *Help* buffer
> opens this unhighlights the region in the other buffer, although the
> latter remains the current buffer.  Is this supposed to happen, and if
> so, why?  (If it's not supposed to happen, I'll open a new bug.)

I can't reproduce this on current master.  I'm going to assume that it's
been fixed some time in the last five years.

It therefore looks like everything is done here, and I'm closing this
bug.  If that's incorrect, please reopen the bug.

Best regards,
Stefan Kangas

reply via email to

[Prev in Thread] Current Thread [Next in Thread]