[Top][All Lists]

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

Search text matches empty string: bug (?)

From: Bernard Leak
Subject: Search text matches empty string: bug (?)
Date: Mon, 5 May 2003 18:17:04 +0100
User-agent: KMail/1.4.3

Stefan Monnier didn't like a previous message of mine, and

>So, Bernard, could you shows us succinct (but precise) bugs ?
>And please separate unrelated ones into separate messages.

Well, thanks for not *quite* throwing the message away!
Here it is, with less circumstance - and some companion
messages.  Emacs LISP syntax has been used for regexps.

This is seen in GNU Emacs 21.3.1 - I haven't checked
whether it is new with that version.  I don't like the
(apparently undocumented) behaviour when an
empty match is found for a search string in
(query-replace)  - where the search string itself must
be empty - and (query-replace-regexp) .

Either function usually seems to move point forward after
an empty string has been matched - i.e., point ends
up one character after the string matched (or its
replacement, if replaced).  At end-of-buffer, however,
no match at all will be found.

This is quite different from the case in which a non-empty
string is matched: here nothing need follow the match, and
point remains immediately after the match (or its replacement).

Yet a third class of behaviour belongs to regexps which
force matching at a particular point, like "\\`" and "\\=" and
These don't "move on" after matching, and apparently
only ever match once, but they also insist on having
*some* character after point.

I can see the point in avoiding runaway replacements,
but this way of dealing with the problem seems random.
Refusing to match an empty string even once at end-of-
buffer seems especially counter-intuitive to me.  I
haven't found a reference to this in the documentation
(perhaps I wasn't looking hard enough).

Bernard Leak.

reply via email to

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