From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#24801: 25.1; Reverse regexp search highlighting Date: Wed, 26 Oct 2016 16:23:26 -0700 (PDT) Message-ID: <5537d36d-a365-4a3f-97a3-78c32e86e7ea@default> References: <4efa49bf-c223-4148-a291-12a722db033c@default> <8737jispf7.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1477524260 5457 195.159.176.226 (26 Oct 2016 23:24:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 23:24:20 +0000 (UTC) Cc: 24801@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 27 01:24:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzXYH-00009X-BK for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Oct 2016 01:24:09 +0200 Original-Received: from localhost ([::1]:38043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzXYJ-0001BU-Qg for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Oct 2016 19:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzXYD-0001BL-MF for bug-gnu-emacs@gnu.org; Wed, 26 Oct 2016 19:24:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzXYA-00009k-Hu for bug-gnu-emacs@gnu.org; Wed, 26 Oct 2016 19:24:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42633) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzXYA-00009e-EL for bug-gnu-emacs@gnu.org; Wed, 26 Oct 2016 19:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bzXYA-0004qm-8T for bug-gnu-emacs@gnu.org; Wed, 26 Oct 2016 19:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Oct 2016 23:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24801 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24801-submit@debbugs.gnu.org id=B24801.147752421718610 (code B ref 24801); Wed, 26 Oct 2016 23:24:02 +0000 Original-Received: (at 24801) by debbugs.gnu.org; 26 Oct 2016 23:23:37 +0000 Original-Received: from localhost ([127.0.0.1]:58031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzXXl-0004q6-6f for submit@debbugs.gnu.org; Wed, 26 Oct 2016 19:23:37 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:20647) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzXXj-0004pu-GW for 24801@debbugs.gnu.org; Wed, 26 Oct 2016 19:23:35 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9QNNS0J014566 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Oct 2016 23:23:29 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u9QNNRAC026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Oct 2016 23:23:28 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9QNNR6b016528; Wed, 26 Oct 2016 23:23:27 GMT In-Reply-To: <8737jispf7.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125055 Archived-At: > `(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?