January 2015 - XEmacs-Beta - XEmacs Mailing List Archives

Re: bug#19714: reftex under Xemacs 21.5.33 Mule 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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 9 years, 10 months

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 2015