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

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

bug#24801: 25.1; Reverse regexp search highlighting


From: Drew Adams
Subject: 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?





reply via email to

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