> - When you use the regexp [0-9]+ in &xequal, it doesn't work at all.
> - When you use [0-9]*, it works like [0-9]+, not matching the empty string but matching a string of digits.
> - When you use these in query-replace-string, they work "correctly," i.e., '+' matches one or more of a char, '*' matches empty strings and any number of a char.
This is a user error. As with most systems there are 2 types of 'regex', the
complex gnu regex used by search and replace which is what you think &xseq is,
and the file-system regex where '*' is any number of any character (i.e. ".*"
in gnu regex) and '?' is any char. Which is why [0-9]* appears to work and
Having said that, when I implemented the &xse regexcmp function I did not have
access to a simple interface to a gnu-regex style engine. I now do, so I'm
tempted to move everything over to gnu-regex. This means that variables like
$spell-word, $buffer-names, $command-names etc will be gnu-regex compliant.
Can anyone see any reason why I shouldn't?
> p.s. While we're discussing regexps, why are the \h, \l etc. functions not
> supported? These would be useful. My (admittedly limited) Unix in a Nutshell
> book documents these as being part of GNU regexp (they make letters/words
I'm afraid they are not gnu Emacs regex compliant, only \b (word boundary) and
\w (word char) are strictly gnu, there are also "\s " and \s- for a white
space and \sw for a word char. I also added the posix style character classes,
i.e. [[:upper:]] or [^[:upper:][:lower:]] (horrible I know but they are the
We could add the \h & \l (what others are missing??), after all, this is not
gnu Emacs. But I am concerned that they will conflict with existing \?
characters, such as \n or \t etc. So which ones are missing? And does anyone
object to adding them?