GNU bug report logs -
#19714
reftex under Xemacs 21.5.33 Mule
Previous Next
Reported by: Uwe Brauer <oub <at> mat.ucm.es>
Date: Wed, 28 Jan 2015 16:58:01 UTC
Severity: normal
Merged with 19715
Done: Tassilo Horn <tsdh <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19714 in the body.
You can then email your comments to 19714 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Wed, 28 Jan 2015 16:58:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Uwe Brauer <oub <at> mat.ucm.es>:
New bug report received and forwarded. Copy sent to
bug-auctex <at> gnu.org.
(Wed, 28 Jan 2015 16:58:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi
I just downloaded the latest reftex version from the GNU Emacs textmode
directory and compiled it with a list of compiler warnings.
Then I enabled it and opened a Latex file, reftex mode was on, however
when I try to run reftex-toc
I obtain an error (debug-on-error t) which I attach. I understand that
Xemacs compatibility is not guaranteed, since for quite a while reftex
is part of GNU Emacs.
However I would like to know whether it could be made compatible with
Xemacs,
I CC xemacs-beta
Emacs : XEmacs 21.5 (beta33) "horseradish" [Lucid] (i686-pc-linux, Mule) of Fri Oct 17 2014 on Burrurr
Package: 21.5 (beta33) "horseradish" XEmacs Lucid
current state:
==============
(setq
window-system 'x
reftex-plug-into-AUCTeX t
)
[reftex-GNU-bug.txt (text/plain, attachment)]
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 07:26:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 19714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Uwe Brauer <oub <at> mat.ucm.es> writes:
Hi Uwe,
> I just downloaded the latest reftex version from the GNU Emacs textmode
> directory and compiled it with a list of compiler warnings.
>
> Then I enabled it and opened a Latex file, reftex mode was on, however
> when I try to run reftex-toc
>
> I obtain an error (debug-on-error t) which I attach. I understand that
> Xemacs compatibility is not guaranteed, since for quite a while reftex
> is part of GNU Emacs.
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.
Bye,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 12:23:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 19714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Uwe Brauer <oub <at> 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
[reftex-gnu-bug-ref.txt (text/plain, attachment)]
[reftex-gnu-bug.txt (text/plain, attachment)]
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 12:50:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 19714 <at> debbugs.gnu.org (full text, mbox):
Uwe Brauer <oub <at> 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
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 13:24:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 19714 <at> debbugs.gnu.org (full text, mbox):
David Kastrup <dak <at> 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
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 14:09:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 19714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> David Kastrup <dak <at> gnu.org> writes:
> 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.
Thanks David, for the fast response!
> 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)
Ok, I will see whether somebody on xemacs-beta picks it up.
> 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.)
Do you mean a split in code here?
wrapped around a
(when (featurep 'xemacs)
Simplified version
)
something like this?
I will try this, but not right now unfortunately.
Just in case, I would like to know:
Suppose I come up with a solution the way you suggest it. Would you then
include the corresponding patch to reftex? It should not do any harm to
GNU emacs. Because otherwise I would have to replace the regexp every
time you release a new version....
Uwe
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 14:11:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 19714 <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
> David Kastrup <dak <at> 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.
The first non-nil matching group?
--
David Kastrup
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 14:43:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 19714 <at> debbugs.gnu.org (full text, mbox):
David Kastrup <dak <at> gnu.org> writes:
>> 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?
Well, reftex also relies on group 3 being the section, group 7 being a
file being input or included, group 9 being the appendix, etc. So when
the label becomes the first non-nil group, the section becomes the third
non-nil group after the first non-nil group...
Oh, and of course you may have a document without a \label. Then the
first non-nil group is the section rather than the label.
Bye,
Tassilo
Reply sent
to
Tassilo Horn <tsdh <at> gnu.org>:
You have taken responsibility.
(Thu, 29 Jan 2015 14:55:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Uwe Brauer <oub <at> mat.ucm.es>:
bug acknowledged by developer.
(Thu, 29 Jan 2015 14:55:03 GMT)
Full text and
rfc822 format available.
Message #31 received at 19714-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Uwe Brauer <oub <at> mat.ucm.es> writes:
> > 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.)
>
> Do you mean a split in code here?
>
> wrapped around a
>
> (when (featurep 'xemacs)
> Simplified version
> )
>
> something like this?
What I mean is exactly this:
--8<---------------cut here---------------start------------->8---
(if (featurep 'xemacs)
(defconst reftex-label-regexps '("\\\\label{\\([^}]*\\)}"))
(defcustom reftex-label-regexps
'(;; Normal \\label{foo} labels
"\\\\label{\\(?1:[^}]*\\)}"
;; keyvals [..., label = {foo}, ...] forms used by ctable,
;; listings, minted, ...
"\\[[^]]*\\<label[[:space:]]*=[[:space:]]*{?\\(?1:[^],}]+\\)}?")
"List of regexps matching \\label definitions.
The default value matches usual \\label{...} definitions and
keyval style [..., label = {...}, ...] label definitions. It is
assumed that the regexp group 1 matches the label text, so you
have to define it using \\(?1:...\\) when adding new regexps.
When changed from Lisp, make sure to call
`reftex-compile-variables' afterwards to make the change
effective."
:version "24.4"
:set (lambda (symbol value)
(set symbol value)
(when (fboundp 'reftex-compile-variables)
(reftex-compile-variables)))
:group 'reftex-defining-label-environments
:type '(repeat (regexp :tag "Regular Expression"))))
--8<---------------cut here---------------end--------------->8---
> Suppose I come up with a solution the way you suggest it. Would you
> then include the corresponding patch to reftex?
I've already committed the above to the emacs-24 branch which is synced
also to master regularly.
I'm closing this bug.
Bye,
Tassilo
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 15:18:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 19714 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 15:21:03 GMT)
Full text and
rfc822 format available.
Message #37 received at 19714-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Uwe Brauer <oub <at> mat.ucm.es> writes:
> What I mean is exactly this:
> (if (featurep 'xemacs)
> (defconst reftex-label-regexps '("\\\\label{\\([^}]*\\)}"))
> (defcustom reftex-label-regexps
> '(;; Normal \\label{foo} labels
> "\\\\label{\\(?1:[^}]*\\)}"
> ;; keyvals [..., label = {foo}, ...] forms used by ctable,
> ;; listings, minted, ...
> "\\[[^]]*\\<label[[:space:]]*=[[:space:]]*{?\\(?1:[^],}]+\\)}?")
> "List of regexps matching \\label definitions.
> The default value matches usual \\label{...} definitions and
> keyval style [..., label = {...}, ...] label definitions. It is
> assumed that the regexp group 1 matches the label text, so you
> have to define it using \\(?1:...\\) when adding new regexps.
> When changed from Lisp, make sure to call
> `reftex-compile-variables' afterwards to make the change
> effective."
> :version "24.4"
> :set (lambda (symbol value)
> (set symbol value)
> (when (fboundp 'reftex-compile-variables)
> (reftex-compile-variables)))
> :group 'reftex-defining-label-environments
> :type '(repeat (regexp :tag "Regular Expression"))))
> I've already committed the above to the emacs-24 branch which is synced
> also to master regularly.
Ok, I will try this as soon as I can, this weekend then.
> I'm closing this bug.
> Bye,
> Tassilo
thanks
Uwe
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org:
bug#19714; Package
auctex.
(Thu, 29 Jan 2015 15:23:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 19714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[smime.p7s (application/pkcs7-signature, attachment)]
Merged 19714 19715.
Request was from
mose <at> gnu.org (Mosè Giordano)
to
control <at> debbugs.gnu.org.
(Thu, 26 Feb 2015 22:03:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 27 Mar 2015 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 149 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.