From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: reb-prev-match behavior Date: Sun, 24 Jul 2005 05:11:59 +0200 Message-ID: Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1122175772 11749 80.91.229.2 (24 Jul 2005 03:29:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2005 03:29:32 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 24 05:29:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DwXAu-0004AL-L8 for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2005 05:29:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DwXD8-00008E-By for ged-emacs-devel@m.gmane.org; Sat, 23 Jul 2005 23:31:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DwXBD-0008Kr-E7 for emacs-devel@gnu.org; Sat, 23 Jul 2005 23:29:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DwXAs-0008CR-K7 for emacs-devel@gnu.org; Sat, 23 Jul 2005 23:29:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DwXAs-000873-AF for emacs-devel@gnu.org; Sat, 23 Jul 2005 23:29:10 -0400 Original-Received: from [64.233.182.198] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DwX4T-00063S-L2 for emacs-devel@gnu.org; Sat, 23 Jul 2005 23:22:33 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so84439nfe for ; Sat, 23 Jul 2005 20:11:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dEmZfBeowB9zSak8w0ogi8aUazzZ43/bNN7yI8D2u6fwweaBFQbhNYE+Kesr1ZIibdo92oFiHvhIkmDcEbbvXCXDpTUmVYzsE4OpjAN705yrn3duLnAPGuP9uwD/EtWPrpGFbLEBX8woXSPEpGBPxILACpdE2YBVv1h+J/ZPGYs= Original-Received: by 10.48.250.11 with SMTP id x11mr124839nfh; Sat, 23 Jul 2005 20:11:59 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Sat, 23 Jul 2005 20:11:59 -0700 (PDT) Original-To: Emacs Devel Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:41177 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41177 I've just fixed a small bug in `reb-prev-match' (from re-builder.el) where it would move the point one character to the left even when it found no match. However, I'm not very satisfied with `reb-prev-match'. It is working right, but I don't find it very useful. Let's suppose we have a buffer with this content: --- start of buffer -- string strong strung --- end of buffer -- And we search for "str[iou]": Cursor is on "n" from "ing" C-c C-s =3D> cursor is on "n" from "ong" C-c C-s =3D> cursor is on "n" from "ung" C-c C-r =3D> cursor is on "n" from "ong" C-c C-r =3D> cursor is on "n" from "ing" Now, if we searched for "str[iou]?": Cursor is on "n" from "ing" C-c C-s =3D> cursor is on "n" from "ong" C-c C-s =3D> cursor is on "n" from "ung" C-c C-r =3D> cursor is on "u" C-c C-r =3D> cursor is on "n" from "ong" C-c C-r =3D> cursor is on "o" C-c C-r =3D> cursor is on "n" from "ing" C-c C-r =3D> cursor is on "i" Now, I understand this is not a bug. As "str[iou]?" also matches "str", going back one char and retrying the search does find a successful match before the "origin of the search", as `re-search-backward' doc says. However, it is quite weird to have a pair of interactive commands apparently symmetrical (at least, that's what their names suggest), one of which moves from one highlighted match in the buffer to the next, while the other moves backwards *inside* the match and only after that tries to find a previous match in the buffer. In other words, I think that, when invoking `reb-prev-match', if it is over a match, it should move to the point just before the current match and only then try to find a previous match. Does it make sense? --=20 /L/e/k/t/u