emacs-devel
[Top][All Lists]
Advanced

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

Re: Removing no-back-reference restriction from syntax-propertize-rules


From: Stefan Monnier
Subject: Re: Removing no-back-reference restriction from syntax-propertize-rules
Date: Mon, 18 May 2020 15:30:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> I think it's OK, but I think the risk of false positives for `\N` is
>> sufficiently high (compared to that for `\(?N:`)
>
> Can you give an example regexp where \N preceeded by a non-\ is no
> back-reference (and still valid)?

Of course: "bar\\(foo\\)[\\1-9]".

> BTW, do I read the docs right in that there are at most nine
> back-references, i.e., \10 cannot exist?  In that case, we'd have the
> restriction that at most 9 back-references may appear in all syntax
> rules.

Apparently, yes:

    (string-match "\\(?5:[ab]\\)-\\5" "a-a")
    0 (#o0, #x0, ?\C-@)
    ELISP> (string-match "\\(?15:[ab]\\)-\\15" "a-a")
    nil

[ I guess that's another reason to stay away from backreferences.  ]

> I guess in that case we should signal an error, no?

Indeed.

>       (when (save-match-data
>               ;; With \N, the \ must be in a subregexp context and the
>               ;; N must not be in a subregexp context.
>               (and (subregexp-context-p new-re (match-beginning 0))
>                    (not (subregexp-context-p new-re (match-beginning 1)))))

You don't need/want to test (subregexp-context-p new-re (match-beginning 1)).

> That doesn't shift/renumber things like [\N] or fo\{\N\} but are those
> valid regexps anyway?

[\N] is, \{\N\} isn't.


        Stefan




reply via email to

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