GNU bug report logs - #24801
25.1; Reverse regexp search highlighting

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Wed, 26 Oct 2016 16:25:02 UTC

Severity: minor

Tags: notabug

Merged with 9681, 11025

Found in versions 23.1, 25.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24801 in the body.
You can then email your comments to 24801 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#24801; Package emacs. (Wed, 26 Oct 2016 16:25:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 26 Oct 2016 16:25:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Reverse regexp search highlighting
Date: Wed, 26 Oct 2016 09:24:02 -0700 (PDT)
[Message part 1 (text/plain, inline)]
emacs -Q

Visit the attached file in text mode.

`C-M-s aa.*' and repeat.  highlighting seems fine, and search moves
forward with one search hit per line, with that search hit including all
of the consecutive a's in the line.

`C-M-r' and repeat (same search pattern).  Search hits are just _pairs_
of consecutive a's (so more than one hit per line), and lines that have
an odd number of consecutive a's do not include the first a in a search
hit.

This seems wrong.  Am I missing something, or is this a bug?

I see this behavior in Emacs 23 and later, but not in Emacs 22 and
before, so I'm guessing this change is maybe intentional.  But it's not
clear to me why it would be.


In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'
[throw-C-M-r--aa-dot-star.txt (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24801; Package emacs. (Wed, 26 Oct 2016 22:42:02 GMT) Full text and rfc822 format available.

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

From: npostavs <at> users.sourceforge.net
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24801 <at> debbugs.gnu.org
Subject: Re: bug#24801: 25.1; Reverse regexp search highlighting
Date: Wed, 26 Oct 2016 18:42:20 -0400
Drew Adams <drew.adams <at> oracle.com> writes:

> emacs -Q
>
> Visit the attached file in text mode.
>
> `C-M-s aa.*' and repeat.  highlighting seems fine, and search moves
> forward with one search hit per line, with that search hit including all
> of the consecutive a's in the line.
>
> `C-M-r' and repeat (same search pattern).  Search hits are just _pairs_
> of consecutive a's (so more than one hit per line), and lines that have
> an odd number of consecutive a's do not include the first a in a search
> hit.
>
> This seems wrong.  Am I missing something, or is this a bug?
>
> I see this behavior in Emacs 23 and later, but not in Emacs 22 and
> before, so I'm guessing this change is maybe intentional.  But it's not
> clear to me why it would be.

`(elisp) Regexp Search', under `re-search-backward' says:

     This function is analogous to `re-search-forward', but they are not
     simple mirror images.  `re-search-forward' finds the match whose
     beginning is as close as possible to the starting point.  If
     `re-search-backward' were a perfect mirror image, it would find the
     match whose end is as close as possible.  However, in fact it
     finds the match whose beginning is as close as possible (and yet
     ends before the starting point).  The reason for this is that
     matching a regular expression at a given spot always works from
     beginning to end, and starts at a specified beginning position.

     A true mirror-image of `re-search-forward' would require a special
     feature for matching regular expressions from end to beginning.
     It's not worth the trouble of implementing that.

And the texi source says the same at tag emacs-22.1; I've only built
Emacs back to 23.4 though, so I can't test it.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24801; Package emacs. (Wed, 26 Oct 2016 23:24:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: npostavs <at> users.sourceforge.net
Cc: 24801 <at> debbugs.gnu.org
Subject: RE: bug#24801: 25.1; Reverse regexp search highlighting
Date: Wed, 26 Oct 2016 16:23:26 -0700 (PDT)
> `(elisp) Regexp Search', under `re-search-backward' says:...

That has always been the case.  The same node from Emacs 20.7 says
the same thing:

 - Command: re-search-backward REGEXP &optional LIMIT NOERROR REPEAT
     This function searches backward in the current buffer for a string
     of text that is matched by the regular expression REGEXP, leaving
     point at the beginning of the first text found.

     This function is analogous to `re-search-forward', but they are not
     simple mirror images.  `re-search-forward' finds the match whose
     beginning is as close as possible to the starting point.  If
     `re-search-backward' were a perfect mirror image, it would find the
     match whose end is as close as possible.  However, in fact it
     finds the match whose beginning is as close as possible.  The
     reason is that matching a regular expression at a given spot
     always works from beginning to end, and starts at a specified
     beginning position.

     A true mirror-image of `re-search-forward' would require a special
     feature for matching regular expressions from end to beginning.
     It's not worth the trouble of implementing that.

I don't think that description is germain to this bug report, except
insofar as what it describes is _not_ the behavior reported.

This really looks like a bug to me.  But regexp search is so basic
to Emacs, and this has been like this since Emacs 23, so I can only
guess that the change in behavior must have been intentional.  But
if so, why?  What's the advantage/point of such behavior?

In Emacs 23.4, `C-h n', then `C-s search', shows that there were a
zillion changes in Isearch behavior.  But this one is not mentioned
at all.

I have to guess (so far) that this is a bug that was introduced when
implementing one or more of those zillion documented changes.  But
if so, why has no one reported it before?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24801; Package emacs. (Wed, 26 Oct 2016 23:36:02 GMT) Full text and rfc822 format available.

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

From: npostavs <at> users.sourceforge.net
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24801 <at> debbugs.gnu.org
Subject: Re: bug#24801: 25.1; Reverse regexp search highlighting
Date: Wed, 26 Oct 2016 19:36:10 -0400
Drew Adams <drew.adams <at> oracle.com> writes:

>> `(elisp) Regexp Search', under `re-search-backward' says:...
>
[...]
>      If
>      `re-search-backward' were a perfect mirror image, it would find the
>      match whose end is as close as possible.  However, in fact it
>      finds the match whose beginning is as close as possible.
[...]
>
> I don't think that description is germain to this bug report, except
> insofar as what it describes is _not_ the behavior reported.
>

Isn't it?  The match of aa.* "whose beginning is as close as possible"
when point is at the of a line of a's, is "aa".  So it seems expected
that searching backwards would match pairs of a's.

> This really looks like a bug to me.  But regexp search is so basic
> to Emacs, and this has been like this since Emacs 23, so I can only
> guess that the change in behavior must have been intentional.  But
> if so, why?  What's the advantage/point of such behavior?

Can you describe exactly how the behaviour is different in Emacs 22?

>
> In Emacs 23.4, `C-h n', then `C-s search', shows that there were a
> zillion changes in Isearch behavior.  But this one is not mentioned
> at all.
>
> I have to guess (so far) that this is a bug that was introduced when
> implementing one or more of those zillion documented changes.  But
> if so, why has no one reported it before?

Actually, this report looks similar to 9681, although I see no claims
there that it worked in version 22.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24801; Package emacs. (Thu, 27 Oct 2016 01:53:01 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: npostavs <at> users.sourceforge.net
Cc: 24801 <at> debbugs.gnu.org
Subject: RE: bug#24801: 25.1; Reverse regexp search highlighting
Date: Wed, 26 Oct 2016 18:51:53 -0700 (PDT)
> Isn't it?  The match of aa.* "whose beginning is as close as
> possible" when point is at the of a line of a's, is "aa".  So it seems
> expected that searching backwards would match pairs of a's.

You are right.

> Can you describe exactly how the behaviour is different in Emacs 22?

I was mistaken.  The same search hits are found in 22 (and before)
as now.  Somehow I thought I was seeing something different when
I tried 22 and 20 earlier today.

> Actually, this report looks similar to 9681, although I see no
> claims there that it worked in version 22.

Yes, this is the same.  I will close this bug.

Funny that I never noticed this before.  I guess that in practice
it doesn't bite that often.  It is multiple matches in the same
line that makes this really stand out as weird behavior.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24801; Package emacs. (Thu, 27 Oct 2016 02:35:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 24801 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24801: 25.1; Reverse regexp search highlighting
Date: Thu, 27 Oct 2016 05:33:52 +0300
> From: npostavs <at> users.sourceforge.net
> Date: Wed, 26 Oct 2016 18:42:20 -0400
> Cc: 24801 <at> debbugs.gnu.org
> 
> > I see this behavior in Emacs 23 and later, but not in Emacs 22 and
> > before, so I'm guessing this change is maybe intentional.  But it's not
> > clear to me why it would be.
> 
> `(elisp) Regexp Search', under `re-search-backward' says:
> 
>      This function is analogous to `re-search-forward', but they are not
>      simple mirror images.  `re-search-forward' finds the match whose
>      beginning is as close as possible to the starting point.  If
>      `re-search-backward' were a perfect mirror image, it would find the
>      match whose end is as close as possible.  However, in fact it
>      finds the match whose beginning is as close as possible (and yet
>      ends before the starting point).  The reason for this is that
>      matching a regular expression at a given spot always works from
>      beginning to end, and starts at a specified beginning position.
> 
>      A true mirror-image of `re-search-forward' would require a special
>      feature for matching regular expressions from end to beginning.
>      It's not worth the trouble of implementing that.
> 
> And the texi source says the same at tag emacs-22.1; I've only built
> Emacs back to 23.4 though, so I can't test it.

I see the same behavior in all versions, including 22.x and 21.4.




Added tag(s) notabug. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Sat, 29 Oct 2016 01:19:01 GMT) Full text and rfc822 format available.

Forcibly Merged 9681 11025 24801. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Sat, 29 Oct 2016 01:19:01 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 24801 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Sat, 29 Oct 2016 01:19:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 26 Nov 2016 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 207 days ago.

Previous Next


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