12:21 p.m.
Uwe Brauer <oub(a)mat.ucm.es> writes:
Hi Uwe,
Could you please try reproducing the error without having the reftex
files byte-compiled? Finding an error in an unknown compiled function
From reftex-toc.elc is a bit hard to do.
Ok, I did this. There are two types of error, I can detect so far:
- when running reftex-toc, there is an error which has to do with
the defcustom setting, GNU emacs allows 3, Xemacs only two
arguments. This is easy to repair, I attach the bug trace, but
don't start fixing it, because the second error looks much more serious:
- when running reftex-label or reftex-ref, there is an error
concerning regexp, this looks harder to fix.
Both bug traces are attached.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:49 p.m.
New subject: bug#19714: reftex under Xemacs 21.5.33 Mule
Uwe Brauer <oub(a)mat.ucm.es> 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.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:23 p.m.
New subject: bug#19714: reftex under Xemacs 21.5.33 Mule
David Kastrup <dak(a)gnu.org> 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. So basically you have two
options:
1. implement explicitly numbered groups in XEmacs (they are really
useful in many cases)
2. remove `reftex-label-regexps' and stick to matching only
\label{...} labels without being able to match other things that
also produce labels
(or even simpler: remove the "?1" from the first regexp in
`reftex-label-regexps' and delete the second regexp. Also make it
to a `defconst' to indicate that nobody should touch it.)
Bye,
Tassilo
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:17 p.m.
New subject: bug#19714: reftex under Xemacs 21.5.33 Mule
Uwe Brauer 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's the "\\(?1:" construct, which I have no idea what it is.
Debugger entered--Lisp error: (wrong-number-of-arguments
define-obsolete-variable-alias 3)
define-obsolete-variable-alias(reftex-toc-map reftex-toc-mode-map "24.1")
*sigh* Gotta love the way the GNUbies whose whole point is software
freedom assume there's only one implementation of any given language.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:22 p.m.
New subject: bug#19714: reftex under Xemacs 21.5.33 Mule
Uwe Brauer writes:
It's the "\\(?1:" construct, which I have no idea what
it is.
It seems that Tassilo just committed a patch with a (featurep 'xemacs
*sigh* Gotta love the way the GNUbies whose whole point is software
freedom assume there's only one implementation of any given language.
Fortunately this is relatively easy to «fix.»
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3374
days inactive
3374
days old
4 comments
4 participants
participants (4)
-
David Kastrup -
Stephen J. Turnbull -
Tassilo Horn -
Uwe Brauer