reb-prev-match behavior

[Juanma Barranquero]

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  => cursor is on "n" from "ong"
C-c C-s  => cursor is on "n" from "ung"
C-c C-r  => cursor is on "n" from "ong"
C-c C-r  => cursor is on "n" from "ing"

Now, if we searched for "str[iou]?": Cursor is on "n" from "ing"
C-c C-s => cursor is on "n" from "ong"
C-c C-s => cursor is on "n" from "ung"
C-c C-r  => cursor is on "u"
C-c C-r  => cursor is on "n" from "ong"
C-c C-r  => cursor is on "o"
C-c C-r  => cursor is on "n" from "ing"
C-c C-r  => 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?

-- 
                    /L/e/k/t/u