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

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

bug#25992: perform-replace leaves mark-active when not transient-mark-mo


From: Keith David Bershatsky
Subject: bug#25992: perform-replace leaves mark-active when not transient-mark-mode
Date: Mon, 06 Mar 2017 09:06:56 -0800

Thank you for taking a look at issue #25992.

In a custom test to determine whether the region is active, I had been testing 
mark-active prior to using (region-beginning) and/or (region-end) to avoid 
trowing an error "The mark is not set now, so there is no region".  When the 
following is true `(and mark-active (= (region-beginning) (region-end)))`, my 
custom function should return nil.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  Mon, 06 Mar 2017 18:26:53 +0200
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
>  transient-mark-mode
> 
> > Date: Sun, 05 Mar 2017 18:02:23 -0800
> > From: Keith David Bershatsky <esq@lawlist.com>
> > 
> > When transient-mark-mode is turned off, perform-replace leaves mark-active 
> > set to `t`.
> > 
> > Step 1:  Launch emacs -q
> > 
> > Step 2:  Turn off transient-mark-mode.  (transient-mark-mode -1)
> > 
> > Step 3:  Evaluate mark-active and verify it is `nil`.
> > 
> > Step 4:  Run a simple perform-replace such as:  (replace-regexp ";" "@" nil 
> > 1 2)
> > 
> > Step 5:  Evaluate mark-active and see that it is now set `t`.
> > 
> > The desired behavior is to leave `mark-active` set to `nil` if it was 
> > previously set to `nil`.
> 
> I'm not sure why you worry about mark-active when transient-mark-mode
> is off: AFAIK that flag is only meaningful when transient-mark-mode is
> on.  Can you describe your use case?
> 
> Anyway, the reason for activating the mark is that replace-regexp
> calls push-mark, which always activates the mark when
> transient-mark-mode is turned off.  Not sure why we do that, but the
> code which does that has been doing it for the last 24 years, so I
> don't think we should change that now, unless we have a _very_ good
> reason.
> 
> Thanks.





reply via email to

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