Jamie Zawinski writes:
So, "#r" can mean "just do backslash hacking",
as now, for
historical compatibility, and the new "#R" can mean "read this in
Perl syntax".
- return Funcall ("perl-regexp-to-emacs-regexp",
regexp_string, regexp_flags);
That function can either mechanically transform the string into an
Emacs-syntax string,
OK. I still don't like the reader macro enough to implement it
myself, though.
I do think we should implement `perl-regexp-to-emacs-regexp'. Even
using my own copious free time.
or it can return a new object of with type-of "perl-regexp"
which
prints itself with #R syntax and which string-match accepts as an
argument. (Maybe perl-regexp objects can also be typep 'string.)
That, I think, is a bad idea. I think that users would likely to be
annoyed whether (concat #R(a)...@ "...") returns an ordinary string that
is interpreted as an Emacs-syntax regexp when handed to a matching
function, or a perl-regexp object, or a "non-regexp-string" object,
depending on which is the user-supplied part.
> And what about #r/foo\bar/unknown -- would that be a syntax
error?
> But then you'd need to embed knowledge of the flag syntax in the lexer.
#'perl-regexp-to-emacs-regexp just signals, resulting in a parse
error.
OK.
Incidentally, #r is inconsistent, as it has no way to read a string
ending in a backslash or a double-quote. That is, the rules for
parsing character N differ from the rules for characters [0-N). A
more consistent grammar would prohibit \" within #r, which is
exactly why sed-syntax regexps allow arbitrary quote-characters
after the "s".
Sure. I've only needed such strings as examples of what not to do,
though, so I don't consider them a big loss.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta