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: Stephen Berman
Subject: bug#6316: 24.0.50; unexpected region highlighting
Date: Wed, 02 Jul 2014 11:27:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (gnu/linux)

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.

I observe this in emacs-24, which contains your fix for my OP, but not
in trunk, which also contains your last two patches for this bug report.

> 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).

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.)

Steve Berman





reply via email to

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