Re: bug#19714: reftex under Xemacs 21.5.33 Mule
10 years, 2 months
Uwe Brauer
Uwe Brauer
> David Kastrup <dak(a)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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
Re: bug#19714: reftex under Xemacs 21.5.33 Mule
10 years, 2 months
David Kastrup
David Kastrup
Tassilo Horn <tsdh(a)gnu.org> writes:
> 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.
The first non-nil matching group?
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
Re: bug#19714: reftex under Xemacs 21.5.33 Mule
10 years, 2 months
Uwe Brauer
Uwe Brauer
> 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
- 4 participants
- 4 comments
reftex under Xemacs 21.5.33 Mule
10 years, 2 months
Uwe Brauer
Uwe Brauer
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
)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 2 comments
reftex pkg, maintainer, upgrade
10 years, 2 months
Uwe Brauer
Uwe Brauer
Hi
The xemacs pkg of Reftex is version 4.21.
There is at least version 4.34 available as a stand alone package. More recent
versions are part of GNU emacs and may or may not run under Xemacs.
However I recommend to upgrade at least to 4.34.
I am not sure who is the actual maintainer. The Changelog suggests that
it is basically orphaned. I would volunteer, but would need write access
to that part of bitbucket.
regards
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: Cygwin Subprocesses on XEmacs
10 years, 2 months
Vin Shelton
Vin Shelton
Hi, Corinna et al,
On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
> On Jan 27 23:05, Vin Shelton wrote:
>> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
>> Here's what I found out.
>>
>> In the child after fork() but before exec(), the setsid() call in
>> disconnect_controlling_terminal() is causing the subprocess not to
>> function after it gets spawned.
>
> Can you define "not function" a bit more detailed? Does no process work
> at all, or do only processes requiring a tty not work? For instance,
> does something like an "echo foo > bar" still work?
M-x shell is specifically designed to spawn an interactive process
like a shell. The bash subprocess starts, but it accepts no input.
Here is the output of ps for that process:
S 1740 252 1740 268 pty1 1003 08:10:54 /usr/bin/bash
I think it's only commands requiring a tty, but that's the whole point
of M-x shell mode. There is a separate command - M-x shell-command -
which is designed to run and capture the output of individual commands
like "ls" or "echo". That works fine.
BTW, if I try to spawn gdb as a shell, the behavior is similar, but
this time the process looks like this:
3328 3248 3328 3408 pty2 1003 08:15:18
/usr/bin/gdb <defunct>
HTH.
>>
>> Thanks for any insight you can offer.
>
> Hmm, not off the top of my head. Is there a chance that you could
> provide a simple, self contained testcase to reproduce the setsid
> behaviour? I think I have to debug that.
You mean a simpler test case than XEmacs? That seems like a low bar. :-)
I'll try. Meanwhile, I've been looking at the emacs code (which in
this case is simpler) to see if I can figure out how it is that M-x
shell works there.
Thank you!
- Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Cygwin Subprocesses on XEmacs
10 years, 2 months
Vin Shelton
Vin Shelton
I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
Here's what I found out.
In the child after fork() but before exec(), the setsid() call in
disconnect_controlling_terminal() is causing the subprocess not to
function after it gets spawned.
Here is a patch which works around the problem, enabling M-x shell to
work for bash and zsh (at least):
diff -r 00f2705e2cb3 src/sysdep.c
--- a/src/sysdep.c Mon Jan 26 08:53:07 2015 -0500
+++ b/src/sysdep.c Tue Jan 27 22:15:16 2015 -0500
＠＠ -1319,7 +1319,7 ＠＠
void
disconnect_controlling_terminal (void)
{
-# ifdef HAVE_SETSID
+# if defined(HAVE_SETSID) && !defined(CYGWIN)
/* Controlling terminals are attached to a session.
Create a new session for us; it will have no controlling
terminal. This also, of course, puts us in our own
HOWEVER - I don't understand why this should be necessary.
I here reproduce all of disconnect_controlling_terminal() for your
reading pleasure.
void
disconnect_controlling_terminal (void)
{
# if defined(HAVE_SETSID) && !defined(CYGWIN)
/* Controlling terminals are attached to a session.
Create a new session for us; it will have no controlling
terminal. This also, of course, puts us in our own
process group. */
setsid ();
# else
/* Put us in our own process group. */
EMACS_SEPARATE_PROCESS_GROUP ();
# if defined (TIOCNOTTY)
/* This is the older way of disconnecting the controlling
terminal, on 4.3 BSD. We must open /dev/tty; using
filedesc 0 is not sufficient because it could be
something else (e.g. our stdin was redirected to
another terminal).
*/
{
int j = open ("/dev/tty", O_RDWR, 0);
ioctl (j, TIOCNOTTY, 0);
close (j);
}
# endif /* TIOCNOTTY */
/*
On systems without TIOCNOTTY and without
setsid(), we don't need to do anything more to
disconnect our controlling terminal. Here is
what the man page for termio(7) from a SYSV 3.2
system says:
"The first terminal file opened by the process group leader
of a terminal file not already associated with a process
group becomes the control terminal for that process group.
The control terminal plays a special role in handling quit
and interrupt signals, as discussed below. The control
terminal is inherited by a child process during a fork(2).
A process can break this association by changing its process
group using setpgrp(2)."
*/
# endif /* not HAVE_SETSID */
}
Since Cygwin doesn't seem to have TIOCNOTTY, commenting out the
setsid() call reduces disconnect_controlling_terminal to:
void
disconnect_controlling_terminal (void)
{
# 1330 "sysdep.c"
setpgid (0, 0);
# 1362 "sysdep.c"
}
Incidentally, that setpgid() call causes bash to complain at startup:
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
Thanks for any insight you can offer.
- Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
Summary of XEmacs Issue Tracking System Issues
10 years, 2 months
XEmacs Issue Tracking System
XEmacs Issue Tracking System
ACTIVITY SUMMARY (2015-01-20 - 2015-01-27)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
563 open ( +0) / 317 closed ( +0) / 880 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1986 days.
Median duration of open issues: 2152 days.
Open Issues Breakdown
new 255 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: Issue with package Tramp
10 years, 2 months
Marcus Harnisch
Marcus Harnisch
Michael Albinus <michael.albinus(a)gmx.de> writes:
> Well, we have `tramp-compat-temporary-file-directory'. I gave it the
> autoload cookie, and used it here. Patch committed to the hg repository.
I was wondering about that and suspected that you might have been
trying to avoid some sort of circular dependency issue.
> Marcus, could you please check whether it works for you?
It doesn't unfortunately.
Symbol's function definition is void: tramp-compat-funcall
Thanks
Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 2 comments
Gnus packaging notes
10 years, 2 months
Mike Kupfer
Mike Kupfer
I've finally gotten around to writing up some packaging notes for Gnus
(attached). I also included some general notes for working with
Mercurial.
I plan to push this to Bitbucket next Thursday; feedback is welcome.
mike
-*- outline -*-
* Introduction
This file contains notes on packaging new versions of Gnus, as well as
some general information for package maintainers.
* Supplement to DevGuide Section 4.3
The XEmacs Developers Guide is included in the "general-docs" package.
Section 4.3 of the Developers Guide contains useful information for
package maintainers, but it has some gaps, and its discussion of
source code management tools is obsolete.
** General Information
*** Mercurial, not CVS
The Developers Guide assumes CVS. XEmacs now uses Mercurial for
source code control, so skip the parts of Section 4.3.2 that discuss
CVS. Instead, see http://www.xemacs.org/Develop/hgaccess.html for
information on using Mercurial for XEmacs development.
*** metadata
The package Makefile contains a few variables that you need to manage.
AUTHOR_VERSION This should reflect the upstream version that you are
packaging.
MAINTAINER This should contain your name and email address.
REQUIRES See "package dependencies", below.
You should never change VERSION, as that variable is owned by the
package buildmeister.
The "provides" clause in package-info.in lists the libraries that your
package provides.
**** package dependencies
The XEmacs package framework provides structure for declaring
inter-package dependencies. The REQUIRES list in the package Makefile
lists the other packages that your package depends on at compile time.
In addition, PUI, the package user interface, uses the REQUIRES list
to determine dependencies for downloads, but that is not the primary
purpose of the REQUIRES list.
*** ChangeLog files
Many upstream packages provide their own ChangeLog files. You may
wish to rename those to ChangeLog.upstream (or some variation), so
that they are separate from the XEmacs ChangeLog files. You can refer
to the upstream ChangeLog file in the ChangeLog entry that you create
when updating to a new upstream release. For example:
YYYY-MM-DD J. Random Hacker <jrh(a)xemacs.org>
* Sync with foobar 2.7.
Please see the ChangeLog.upstream files for details.
** Source Tree Organization
*** top-level and subrepos
The packages tree is stored on bitbucket.org as a top-level repository
with subrepositories (subrepos). This simplifies access control, as
each package maintainer can be easily given write access to just her
own package(s).
There are a few gotchas that package maintainers should be aware of.
- Not all Mercurial commands automatically recurse into subrepos.
See the section "Mercurial recipes" below for recommended
commands.
- The repository organization on Bitbucket is set up such that you
can clone and build the entire package tree, but you cannot easily
clone your clone. This is primarily because the subrepo
configuration assumes that the parent has a flat layout, whereas
your clone will have the individual package repositories
underneath the top-level repository. (In addition, a couple of
the subrepo names get tweaked during the cloning process.)
This is not a problem if you are working with a single package
repository. Nor is it a problem if you don't want to clone your
clone. But if, for example, you want to keep a pristine master
repository and a working repository, you will need to massage the
master repo before cloning it to create your working repo. A Unix
shell script is provided below to do this massaging for you.
- If you do "hg stat -S" in the top-level repo, you may see changes
listed that you have committed in the subrepo. Mercurial will
stop listing them when the top-level repo is committed with the
subrepo changes. Normally only the Packages buildmeister will
commit changes in the top-level repo, so to avoid confusion, you
may want to avoid running "hg stat -S" in the top-level
repository.
Most of the time, you will only need to make changes in the subrepo
for your package. But if you change the source organization of your
tree (e.g., to simplify merging with upstream), you will need to
update package-directory-map in package-compile.el, which is in the
top-level repository. Ask on xemacs-beta(a)xemacs.org how to proceed.
Additional information about subrepos is available at
http://mercurial.selenic.com/wiki/Subrepository
*** variances between upstream and the XEmacs package
**** source variances
The source organization of the upstream package may not match the
organization used in the XEmacs package tree. In fact, for large,
complicated packages (e.g., Gnus), it's possible that the upstream
package contains files that are not in the XEmacs package and vice
versa. In these cases, it can be a challenge to update an XEmacs
package to a new upstream version. Nonetheless, the update algorithm
described below under "Mercurial recipes" should be adequate.
**** content variances
You can make XEmacs-specific changes easier to find by tagging them
with this comment:
;; XEmacs change
Of course, the more variances there are between the upstream code and
the XEmacs package, the harder it will be to update to new upstream
versions. So the general recommendation is to work with the upstream
developers to get any such changes incorporated into the upstream code
base.
** Mercurial recipes
This section has sample commands for a simple package workflow. It
assumes that you have already reviewed
http://www.xemacs.org/Develop/hgaccess.html.
*** initial clone
The first thing you need to do is create a local clone of the repo on
Bitbucket.
**** single package
If you are just cloning the "gnus" package, you can use
$ hg clone ssh://hg＠bitbucket.org/xemacs/gnus
We use an ssh URL here under the assumption that you will eventually
want to push changes back to Bitbucket.
**** the entire package tree
If you are cloning the entire package tree and don't plan to create
any additional clones from it, you can just do
$ hg clone https://bitbucket.org/xemacs/xemacs-packages mypackages
On the other hand, if you do plan to clone from your local copy, you
should create one more directory layer, e.g.,
$ mkdir mypackages
$ cd mypackages
$ hg clone https://bitbucket.org/xemacs/xemacs-packages
and then run the following script. In the example above, you would
run it from the mypackages/xemacs-packages directory.
--8<---------------cut here---------------start------------->8---
#! /bin/sh
top=$(basename $(pwd))
for d in mule-packages xemacs-packages; do
for f in $d/*; do
[ -d $f ] && ln -s $top/$f ..
done
done
mv ../Sun ../sun
mv ../hm--html-menus ../hm-html-menus
--8<---------------cut here---------------end--------------->8---
Independent of which method you just used, for the packages that you
want write access to, change the "default" line in the subrepo's
.hg/hgrc from the https URL to an ssh URL, e.g.,
default=ssh://hg＠bitbucket.org/xemacs/gnus
*** updating and merging your clone
As a general recommendation, you should commit your local changes
before pulling from the parent repository. If there are new changes
in the parent repo, having your changes committed means they will not
be lost in case something goes awry during the merge process.
If you need to run "hg merge", you should do an "hg commit" after you
have finished merging the changes. This will make it easier to
distinguish additional work from changes that resulted from the
merge.
**** single package
If you have a single package repository, you can use "hg pull" and
"hg merge" as described in
http://mercurial.selenic.com/wiki/Tutorial.
**** the entire package tree
If you have the entire package tree, the most reliable way to get an
update is to do "hg pull -u" in the top-level repository. The -u (or
a separate "hg update") is necessary to pull the subrepo updates from
the parent repository.
If a merge is needed in your package subrepo, it will be indicated
during the update step with the string "+1 heads". You can then use
the normal "hg merge" and "hg commit" commands within the subrepo.
*** committing and pushing changes
Normally you will just push changes from your package (sub)repo, not
the top-level packages repo. You can use "hg stat" to check for
uncommitted changes. After your final commit, you can use "hg
outgoing" to list the changeset(s) that you will be pushing.
If your push fails with an error message about creating multiple
heads, that usually means that changes have been made in the parent
repo since the last time you pulled from it. It's usually best to
pull down those changes and (re)run "hg merge". Retest as needed,
review your changes, commit, and try again to push.
*** updating to a new upstream version
Probably the most straightforward way to handle updates is to keep a
pristine copy of the most recent upstream version (i.e., the version
that the XEmacs package is based on).
Diff the new upstream version against the previous upstream version to
generate a patch file.
If necessary, massage the patch file to reflect the XEmacs file
layout, or to remove diffs for files that are not in the XEmacs
package.
Make sure that your repository has the latest changesets from
Bitbucket.
Apply the patch and resolve any conflicts by hand.
Manually register any new files with Mercurial ("hg add") and remove
any files that have been deleted ("hg rm --after").
Build your package (and optionally build the entire package tree).
Test as seems appropriate.
When you are ready (e.g., after testing), commit and push the new
version as described in the previous section. Monitor the package
smoketest in case your changes break the build of other packages.
** changes to other packages or the top-level repo
Sometimes your changes may require changes to code that you don't own.
For example, API changes in a new release of your package may break
other packages. Also, the top-level repo has some package-specific
data, like whether the sources are in the package's top-level
directory or in a "lisp" subdirectory. So it's possible you will need
to make changes in the top-level repo as well.
If you need to make changes in code that you don't own, send mail to
xemacs-beta to ask for assistance. Describe the changes that you want
to make (and why) and ask for instructions on how to proceed.
* Gnus-Specific Information
** What to Merge
XEmacs distributes the "stable" release of Gnus. For a long time
this was the 5.10 branch. Currently there are at least 3 contenders
for the "stable" release, and no direction has been forthcoming from
the Gnus developers. The 3 contenders are
- the latest release in the 5.10 branch
- the last release in the previous development branch (e.g., if "Ma"
Gnus is the current development branch, then use the last release
from the "No" Gnus branch)
- the version of Gnus that was included in the most recent release
of GNU Emacs.
In any event, tarballs are no longer being posted on gnus.org.
Instead, you must download a snapshot from an upstream repo, either
the Git repository on gnus.org or the Git repository for Emacs.
** How to Merge
*** Files to (Not) Include
Upstream Gnus releases contain many files that are not included in the
XEmacs Gnus package. The following files from the "lisp" directory
should _NOT_ be included in the XEmacs Gnus package, as they are
delivered in other XEmacs packages:
dig.el
dns.el
hex-util.el
netrc.el
pgg-def.el
pgg-gpg.el
pgg-parse.el
pgg-pgp.el
pgg-pgp5.el
pgg.el
pop3.el
rfc2104.el
sha1.el
sieve-manage.el
sieve-mode.el
sieve.el
starttls.el
tls.el
Corresponding files from the texi directory should also be omitted.
We have not been delivering the current smiley.el, either, because an
earlier maintainer preferred an old version over the one that is
currently included in Gnus releases.
The XEmacs Gnus package does include the following files from the
"contrib" directory:
gpg-ring.el
gpg.el
hashcash.el
nnir.el
vcard.el
It would make more sense for vcard.el to be included in the mail-lib
package, so that it can be more easily used by other MUAs, notably VM.
Getting that fixed will require negotiation with the maintainers for
mail-lib and VM.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 4 comments