bug#19714: reftex under Xemacs 21.5.33 Mule

[David Kastrup]

Tassilo Horn <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>>> Debugger entered--Lisp error: (invalid-regexp "Invalid regular expression")
>>>   
>>> re-search-forward("\\(?:\\\\label{\\(?1:[^}]*\\)}\\|\\[[^]]*\\<label[[:space:]]*=[[:space:]]*{?\\(?1:[^],}]+\\)}?\\)\\|\\(^\\)[
>>>   
>>> ]*\\\\\\(begin{SaveListing}\\|part\\|chapter\\|section\\|subsection\\|subsubsection\\|paragraph\\|subparagraph\\|addchap\\|addsec\\)\\*?\\(\\[[^]]*\\]\\)?[[{
>>>   \n\\]\\|\\(^\\)[  ]*\\\\\\(include\\|input\\|subfile\\)[{
>>>   ]+\\([^}  \n]+\\)\\|\\(^\\)[
>>>   
>>> ]*\\(\\\\appendix\\)\\|\\(\\\\glossary\\|\\\\index\\|\\\\nomenclature\\)[[{]"
>>>   nil t)
>>
>> It would be my guess that
>>
>> ‘\(?NUM: … \)’
>>      is the "explicitly numbered group" construct.  Normal groups get
>>      their number implicitly, based on their position, which can be
>>      inconvenient.  This construct allows you to force a particular
>>      group number.  There is no particular restriction on the numbering,
>>      e.g., you can have several groups with the same number in which
>>      case the last one to match (i.e., the rightmost match) will win.
>>      Implicitly numbered groups always get the smallest integer larger
>>      than the one of any previous group.
>>
>> is the culprit here.  At least in the current XEmacs manual
>> <URL:http://www.xemacs.org/Documentation/21.5/html/lispref_45.html#SEC599>
>> I can find nothing of the sort.
>
> Yes, that's it.  Unfortunately, I use that on purpose in
> `reftex-label-regexps' which is a customizable list of regexps which
> gets `regexp-opt'ed and starts `reftex-everything-regexp'.  By default,
> it has one entry matching \label{...} and one matching keyval
> label={...} arguments.
>
> RefTeX relies on the first group in `reftex-everything-regexp' capturing
> the label name (see reftex-parse.el:242).  Without the explicitly
> numbered groups, the regex for \label{...} would be group 1, but the
> regex for label={...} would already be two.
>
> I don't see an easy fix here on my side.

The first non-nil matching group?

-- 
David Kastrup