8:06 p.m.
Please keep the discussion on the list.
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
> Are you sure you have the shell.el as of 2006-06-01?
It was an error in change merge. Because of continuous committing
buggy versions in upstream, had to maintain a distinct local one.
With `shell.el' as of 2006-06-01 fully duplicated, finding no more
bugs. As for being able to run `comint', `shell', considering it
closed.
I am happy to have had your help in identifying bugs in the sync, but I
don't understand why you think you have to maintain a distinct local
copy. Can't you just stick with the officially released packages? If
you are installing test packages, then you've agreed to be a tester.
And you've been a good one, so I hope you continue, but you shouldn't
feel like you are required to be a tester.
One reason to still maintain another `shell.el' version is that
is
still has a maintainability bug. It does not `(require 'font-lock)'
in run time, but does so in `eval-when-compile'. Already wrote that
`font-lock' has a (IMO, mis-) feature of enabling itself on mere load,
so there may be strong reasons not to load it. That perhaps makes no
difference when compiling `shell.el' in batch mode, but user may need
his own version of the file, and compile it by executing
`byte-compile-file' interactively. In this case the undesired changes
in his environment will occur.
What is the purpose of such a `require' in `eval-when-compile'? If it
is only to shut warnings about use of `font-lock-mode-hook', this
variable is autoloaded, but in `auto-autoloads.el'. In this case
should `(require 'lisp-autoloads)'.
Changing `font-lock' not to enable itself on load (in all xemacs
branches) perhaps would be even better.
Are you worried about this?
------------------------------------------------------------------------
;; Install ourselves:
(add-hook 'find-file-hooks 'font-lock-set-defaults t)
------------------------------------------------------------------------
I don't see anything else in font-lock.el that makes an obtrusive change
to the user's environment.
As for the byte compiling issue, (require 'auto-autoloads) is not the
right thing to do, because there are lots of auto-autoloads.el files,
one per package in fact. It is true that this is just to quiet a byte
compiler warning. That may be considered a small thing by some, but I
try to get rid of such warnings whenever I touch a package. I have this
dream that, eons from now, some XEmacs developer may be able to notice
that there were 2 warnings when compiling the packages and go fix the
problem. Right now, we get so many warnings that they are nearly
worthless.
We could drop the require of font-lock and get the warning back. I'm
not terribly concerned about this, though, because (1) we distribute the
packages in precompiled form, which is good enough for the vast majority
of users; and (2) anybody who needs to compile their own due to
maintaining local variations should be sophisticated enough to deal with
a change in find-file-hooks.
--
Jerry James, Assistant Professor Jerry.James(a)usu.edu
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
6:48 p.m.
New subject: branching in packages?
In xemacs core beta and stable versions are marked fairly clearly,
that is, kept in separate cvs branches. There are obvious and well-
known cvs commands to obtain both beta and stable snapshot and do
whatever merging or other operations on them one pleases to. In
particular, keeping local version control branches that parallel beta
and stable versions is trivial.
With packages there also appear to be test and stable versions, but
procedures to retrieve the current test or current stable sources are
not as obvious. On Fri, 23 Jun 2006 13:06:35 -0600 Jerry James wrote:
Can't you just stick with the officially released packages?
This is one of reasons to answer "no".
Keeping parallel local branches for test and stable versions is also
non- trivial.
Please put in your `TODO' a task to create such a procedures for
packages (and maintain appropriate labels in cvs).
5:56 a.m.
New subject: branching in packages?
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> With packages there also appear to be test and stable
Ilya> versions,
If you're referring to the Pre-Release packages, those are *versions*,
not *branches*. Those are beta tests for new package releases in the
stable line. They're mostly intended to deal with packaging bugs, and
also to detect show-stoppers. They do not represent a separate branch.
In the case of comint, field, and gdb libraries, there have been a
number of show-stoppers recently. To be honest, they're more unstable
than stable -- but there's still only one branch.
cvs status -v on any package of interest should show this quite clearly.
If you would like to maintain separate branches of packages of special
interest to you in our CVS, that can probably be arranged (Norbert,
what say you?), but since ISTR you have code that can't be released to
the public, that's probably more trouble than it's worth. :-(
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:20 a.m.
New subject: branching in packages?
* "Stephen J. Turnbull" <stephen(a)xemacs.org>:
Hi!
If you would like to maintain separate branches of packages of
special
interest to you in our CVS, that can probably be arranged (Norbert,
what say you?), but since ISTR you have code that can't be released to
the public, that's probably more trouble than it's worth. :-(
Sure, I don't have any objections against a branch maintainer (or even
package maintainer :-)), but I second your doubts about effort and
result.
norbert.
3:23 p.m.
New subject: branching in packages?
Never insisted on creating separate branches for pre- release and
stable packages in package cvs. All that asked was *procedures* to
obtain / retrieve latest stable or latest pre- release package working
directory from cvs. And markup in cvs for use in such procedures -
whatever you choose.
Currently cvs certainly contains package version tags. But these tags
do not specify whether the version is stable, and thus useless for the
task described above.
If you would like to maintain separate branches of packages of
special
interest to you in our CVS, that can probably be arranged (Norbert,
what say you?), but since ISTR you have code that can't be released to
the public, that's probably more trouble than it's worth. :-(
Wherever these branches are kept, one still has to sync / merge them
with upstream sources, and, for some branches, take stable upstream
versions for the sync. Which means the task above.
As for keeping my branches in your CVS - thanks for invitation; all my
code certainly can be released to the public. OTOH, can have my own
CVS, and certainly there is no reason to bother you or other CVS
maintainers with requests to keep my branches. This is why never
asked for that.
4:50 a.m.
New subject: branching in packages?
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> Currently cvs certainly contains package version tags. But
Ilya> these tags do not specify whether the version is stable, and
Ilya> thus useless for the task described above.
If there's a version tag, it's stable as far as we know. If the
package maintainer believes there's an issue, they tell Norbert, who
holds back on any release until it's resolved. Some package
maintainers keep exceptionally unstable packages in the unsupported
tree (eg, Ville Skyttä's vc sync). The prerelease cycle is mostly
intended to catch packaging bugs, not Lisp code bugs.
If you want to avoid the pre-releases, then M-x list-packages will tell
you current recommended version as long as you have no pre-release
archives in the list of download hosts.
Ilya> As for keeping my branches in your CVS - thanks for
Ilya> invitation; all my code certainly can be released to the
Ilya> public.
If you want us to take *any* precautions to not break your code,
publication of your code is absolutely necessary.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:31 p.m.
New subject: branching in packages?
If you want to avoid the pre-releases, then M-x list-packages will
tell
you current recommended version as long as you have no pre-release
archives in the list of download hosts.
This is the trouble: requesting additional information that is not
only ill- defined for automatic processing, but not stored in cvs at
all. Unlike xemacs core, where all that one needs to obtain current
versions is cvs repository - perhaps even its local copy, in which
case no network transfers are done at all - except automatic
background synchronization of the copy.
Even if have saved, along with xemacs cvs repository copy, (current)
listing of master package download directory, - there is no well-
defined procedure to match its items against tags in cvs. At least
not one that is obviously automated. For each package one has to do
the following.
. Determine latest package file name from listing.
. Take package name and version from it.
. Convert it to version tag that *should* be in cvs. Perhaps it done
the same way for all packages, perhaps not. If the tag is there, all
right. What if it is not?
. `cvs update' the package with that tag.
Hope that this is enough to show that obtaining current stable
package sources snapshot is non- trivial. Having tag like
'current_stable_packages' or some other well- defined markup in cvs
itself would make things much simpler.
The prerelease cycle is mostly
intended to catch packaging bugs, not Lisp code bugs.
But used for <Lisp code bugs> way too often. See package change logs
for statistics. This is why posted initial message on this subject in
the first place. Followed up discussion of Lisp code bugs in one
prerelease package: `comint' + `shell' in `xemacs-base'.
Besides, see no clear distinction between <packaging> and <Lisp code>
bugs. If there are some local Lisp code changes in xemacs package
cvs, and new author / upstream package version is merged, is this
<packaging> operation? Whatever it is, merging can easily generate
definite <Lisp code> bugs.
Some package maintainers keep exceptionally unstable packages in the
unsupported tree
Would be happy to see this practice commonplace. But currently it is
as described above.
6 p.m.
New subject: branching in packages?
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> Having tag like 'current_stable_packages' or some other
Ilya> well- defined markup in cvs itself would make things much
Ilya> simpler.
I see no reason why it would. Under current policy, the right way for
Norbert to implement it is the way I implement it in 21.5: an
automatic "cvs -f tag -r this_release current_stable" when the tarball
is rolled out, ie, at pre-release. But CVS HEAD == most recent
release most of the time.
If Norbert wants to, I don't think anybody would object to a policy
change where he simply adds a current_stable tag at the time he moves
a package from pre-release to the main archive. Ie, implicitly a
short unofficial beta test period. But I would be opposed to turning
that into some kind of official beta test period, or having the
promotion to stable be delayed by depending on anything but Norbert's
judgment and convenience as it does now.
> The prerelease cycle is mostly intended to catch packaging
> bugs, not Lisp code bugs.
Ilya> But used for <Lisp code bugs> way too often. See package
Ilya> change logs for statistics.
If you think the package change logs have anything to say about this
issue, I have to wonder what logs you're looking at. I see no way to
determine from most change logs whether a bug was caught in the
prerelease stage, or after public release. Nor is there usually a way
to tell whether the bug was introduced in the changes leading up to
the current release, or whether it was present previously.
Now, if you track Norbert's announcements to see which ones put a new
version of a package into pre-release where the previous one was
already in pre-release, you'd have some data---but still not enough to
distinguish at which stage the bugs were injected.
Ilya> Besides, see no clear distinction between <packaging> and
Ilya> <Lisp code> bugs.
It's a packaging bug if the code does not install or load correctly.
If an error occurs after loading, it's a bug in Lisp code.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:31 p.m.
New subject: branching in packages?
But CVS HEAD == most recent
release most of the time.
For `xemacs-packages/xemacs-base/comint.el' is was not so since
2006/05/25 02:49:47 -0 (revision 1.14). So packages may stay in this
state fairly long, and figuring last stable source fast is very
helpful.
I see no way to
determine from most change logs whether a bug was caught in the
prerelease stage, or after public release.
Agree that need also numbers of stable package versions - from master
package download site, or from announce archive. That list of
versions that were released as stable is not kept otherwise, that is,
in cvs itself, is also at least inconvenient.
Nor is there usually a way
to tell whether the bug was introduced in the changes leading up to
the current release, or whether it was present previously.
Agree that this is rarely put in package change logs. Most likely
have to be familiar with bug reports in mailing lists - or have one's
own package use experience, as in my case. :-/
It's a packaging bug if the code does not install or load
correctly.
If an error occurs after loading, it's a bug in Lisp code.
This definition is at least easily written - however, depending on
particular user environment, the same bug may manifest either only
after loading or when loading. To consider `comint.el', most of bugs
fixed after revision 1.14 were <Lisp code> ones. Still there are some
reasons not to release it as stable yet. At least some of these bugs
were introduced by that revision.
`find-func' revision 1.10 fix was also for <Lisp code> bug, and
introduced after last stable release.
It appears that packages with last version different from current
stable one, and largely due to <Lisp code> bugs, are quite common.
This is why need a standard, easily automated way to obtain / keep
last stable sources.
8:05 p.m.
New subject: branching in packages?
"Ilya N. Golubev" <gin(a)mo.msk.ru>
For `xemacs-packages/xemacs-base/comint.el' is was not so since
2006/05/25 02:49:47 -0 (revision 1.14). So packages may stay in this
state fairly long, and figuring last stable source fast is very
helpful.
That is why, for that particular package, the related traffic on
xemacs-patches included the announcement that these tags would be
available to help anyone needing the last version before the sync:
pre-JJ-comint-sync
post-JJ-comint-sync
I agree that this is not a good general mechanism. However, it is also
true that my sync of comint and shell with Emacs is not representative
of package updates in general, so the related instabilities do not make
a good general argument about the way in which the package tree is
managed.
If the new comint is causing you more grief than you are willing to put
with, then please revert to the versions of comint and shell tagged
pre-JJ-comint-sync. On the other hand, I want to repeat that your
testing and bug reports have been very valuable, and I hope you will
continue helping me iron out the remaining comint and shell bugs.
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
6:38 p.m.
New subject: branching in packages?
the related traffic on
xemacs-patches
I agree that this is not a good general mechanism.
Often the only thing read after upstream cvs update is new change log
text. Better put this notice in change log.
However, it is also
true that my sync of comint and shell with Emacs is not representative
of package updates in general
Change logs not of `xemacs-base' only, but of `xemacs-devel',
`mail-lib' are filled with <sync with GNU Emacs> entries. And even
more syncs is needeed, for `gud.el' in particular. Code in xemacs and
emacs became quite different, so introducing by these syncs / merges
all sorts of errors, including ones manifesting after loading new
code, is highly likely. So disagree.
so the related instabilities do not make
a good general argument about the way in which the package tree is
managed.
On the contrary, it appears a quite general scenario.
9 p.m.
New subject: branching in packages?
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> Often the only thing read after upstream cvs update is new
Ilya> change log text. Better put this notice in change log.
Semantic content: "I don't feel like reading the patch discussion, so
put information that belongs with the patch discussion in text that I
do read." Deserves no response.
And elsewhere:
Ilya> My experience is that I will just end up with the same
Ilya> broken version promoted to stable and causing the same
Ilya> grief.
That's always a risk. There's nothing (that involves reasonable
levels of effort) we can do about that risk and still put new code
into circulation. You can't have both new code and stability---and
that's your choice to make. XEmacs does not force you to upgrade
packages.
I think it's time to stop running in circles. Let's end this thread
here.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
9:48 p.m.
New subject: branching in packages?
Semantic content: "I don't feel like reading the patch
discussion, so
put information that belongs with the patch discussion in text that I
do read."
Unfortunately, the <m3u07pftkj.fsf(a)jerrypc.cs.usu.edu> message pointed
by cvs log message of `comint.el' sync does not mention cvs tags at
all, neither it contains
pre-JJ-comint-sync
post-JJ-comint-sync
And if their names were there, do they <belong> *only* there? New cvs
tags are change in cvs itself, and done for purposes of some big
change in the same cvs. So why pointers to them do not <belong> in
description of that change put in cvs, why *must* refer to mailing
list message? The latter may be unaccessible for some time, because
all one has is local copy of cvs repository, and no network access at
all. <The big ben-mule-21-5 check-in!> of 2002/03/13 08:52:41 shows
example of less error prone practice: stating cvs tags - not in change
log entry, but in cvs commit message.
After all, these pointers are certainly far smaller than detailed
description of code changes being committed - which are universally
considered belonging in cvs.
As for looking for these tags in other messages (except
<m3bqrovyq4.fsf(a)jerrypc.cs.usu.edu>) - it basically amounts to vgrep
in mailing list archives, and just impossible. <xemacs-patches>, in
particular, contains information about all, even proposed, patches,
not only about ones already committed.
7:46 p.m.
New subject: branching in packages?
If the new comint is causing you more grief than you are willing to
put
with, then please revert to the versions of comint and shell tagged
pre-JJ-comint-sync.
My experience is that I will just end up with the same broken version
promoted to stable and causing the same grief.
5:08 a.m.
New subject: branching in packages?
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> Agree that need also numbers of stable package versions -
Ilya> from master package download site,
That is precisely what you get with
ftp://ftp.xemacs.org/pub/xemacs/packages/package-index.LATEST.gpg,
which is the database used by list-packages. By its nature, this file
does *not* include packages in pre-release state, only the latest
public release. That is the closest approximation we can reasonably
offer to a list of stable versions. We could slightly improve on this
by matching a CVS tag to it, but is there really that big a difference
between a CVS tag and an authoritive list from the download site?
There are also dated indexes, eg, package-index.LATEST.gpg is symlink
to package-index.2006-05-08.gpg. (Currently only LATEST is available;
you'd have to ask Norbert what his policy is on cleaning out the older
ones and whether they're archived somewhere.)
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:18 a.m.
New subject: branching in packages?
* "Stephen J. Turnbull" <stephen(a)xemacs.org>:
Hi!
There are also dated indexes, eg, package-index.LATEST.gpg is
symlink
to package-index.2006-05-08.gpg. (Currently only LATEST is available;
you'd have to ask Norbert what his policy is on cleaning out the older
ones and whether they're archived somewhere.)
Old things are kept in the attic as in real life.
ftp://ftp.xemacs.org/pub/xemacs/Attic/packages/
has two sub directories oldpkg and oldsumo which in term contain tons of
stuff (and dust and bugs :-))
HTH, HAND,
norbert.
4:45 p.m.
New subject: vc-hooks hosed, requires everything [Re: Pushing new vc towards regular packages tree]
it is expected that there are some rough
edges here and there.
One is that `vc-hooks' elisp library runs amok and requires each and
every vc backend, at least in some cases.
The whole point of `vc-hooks' always was to contain some minimum code
needed to recognize what other vc backends are needed, if any, and
thus to prevent requiring elisp libraries of all of these backends in
a lump. It fails to serve this main purpose as follows.
Keep the following in `site-load-packages' (list) value in
`site-packages' in top xemacs build directory.
"../xemacs-packages/lisp/vc/vc-xemacs.elc"
"../xemacs-packages/lisp/vc/vc-hooks.elc"
(Having to load `vc-xemacs' is easily accountable for and not a
trouble in itself.)
Try to build xemacs. It completes dumping normally, but `xemacs'
dumped this way is unusable, at least in the following invocation done
in course of normal build after dumping.
./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f batch-update-elc-2
${LISP}
(Using `${LISP}'. Actually it is absolute name of `lisp' subdirectory
of top xemacs source directory.)
It exits with error, reporting the following lisp backtrace.
signal(file-error ("Cannot open load file" "vc-rcs"))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("${LISP}/custom-load.el" nil nil)
# (unwind-protect ...)
# bind (outbuf trim-name autoloads-done print-length print-readably float-output-format
visited suppress-form output-end)
byte-code()
# (catch --cl-block-generate-autoload-type-section-- ...)
# bind (fun-to-call literal load-name file)
generate-autoload-type-section("${LISP}/custom-load.el"
"custom-load" nil generate-lisp-file-autoloads-1)
# bind (file)
generate-file-autoloads("${LISP}/custom-load.el")
This way the build is broken.
In debugger could obtain richer backtrace.
signal(file-error ("Cannot open load file" "vc-rcs"))
# bind (path handler filename nosuffix nomessage noerror file)
load("vc-rcs" nil require nil)
# (unwind-protect ...)
require(vc-rcs)
# bind (f fun backend)
vc-find-backend-function(RCS registered-lite)
# bind (f args function-name backend)
vc-call-backend(RCS registered-lite "${LISP}/custom-load.el")
# bind (b)
#<compiled-function (b) "...(34)" [file b fboundp vc-make-backend-sym
registered vc-call-backend registered-lite vc-file-setprop vc-backend throw found t]
4>(RCS)
mapcar(#<compiled-function (b) "...(34)" [file b fboundp
vc-make-backend-sym registered vc-call-backend registered-lite vc-file-setprop vc-backend
throw found t] 4> (RCS CVS SVN SCCS Arch MCVS GIT))
# bind (backend)
byte-code()
# (catch found ...)
# bind (handler file)
vc-registered("${LISP}/custom-load.el")
# bind (property file)
vc-backend("${LISP}/custom-load.el")
vc-find-file-hook()
run-hooks(vc-find-file-hook)
# bind (nomodes after-find-file-from-revert-buffer noauto warn error)
after-find-file(nil t)
# (unwind-protect ...)
# bind (inhibit-read-only error number truename rawfile nowarn filename buf)
find-file-noselect-1(#<buffer "custom-load.el">
"${LISP}/custom-load.el" nil nil "${LISP}/custom-load.el" (1825176
773))
byte-code()
# (condition-case ... . ((t (byte-code ))))
# bind (number truename buf wildcards rawfile nowarn filename)
find-file-noselect("${LISP}/custom-load.el" nil nil)
That is, `vc' sets xemacs up so that during the mere visiting of
arbitrary file that is possibly not under any version control at all
it requires this way not only `vc-rcs', but all other elisp libraries
for list in `vc-handled-backends'. Did try to have this batch xemacs
load `vc-rcs', and confirming that this is not enough, it keeps
requiring more vc backend libraries exactly as they are listed in
`vc-handled-backends', until all of them are loaded.
Did observe that xemacs with the new vc loaded does not always behave
this way. If dumped in xemacs (21.4 or 21.5) none of `vc' libraries,
and ran it interactively, it loaded only some reasonable fraction of
these libraries as files are visited.
Never tried to figure the exact conditions on which vc runs amok and
requires every backend library. In particular, have no idea whether
xemacs has to be invoked in batch mode, or interactive uses are also
affected.
In any case, such a bulk loading of elisp libraries is intolerable
whenever happens. So please put this bug in list of ones to be fixed
before what you committed on 2007/08/23 21:27:53 +0 leaves
<experimental area>.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:06 p.m.
New subject: avoiding / forcing experimental packages [Re: Pushing new vc towards regular packages tree]
Push the new package to the experimental area
I would still rather figure which packages are in this area (and which
are, on the contrary, deemed stable) from the contents of cvs itself
in some uniform, well- defined way, without ad- hoc means such as
chasing pointers to mailing list archive items containing information
for humans only. That is, to have clear conventions and procedure,
how, at my option, retrieve from cvs and stick to current
experimental, or current stable version of given package. An old
issue, already raised at least on Fri, 07 Jul 2006 21:48:00 +0400
(<09lkr5mhm7.fsf(a)mo.msk.ru>, <branching in packages?>).
Please consider developing and using such a conventions - on both vc
and other packages.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:44 p.m.
New subject: vc-hooks hosed, requires everything [Re: Pushing new vc towards regular packages tree]
On Monday 27 August 2007, Ilya N. Golubev wrote:
> it is expected that there are some rough
> edges here and there.
One is that `vc-hooks' elisp library runs amok and requires each and
every vc backend, at least in some cases.
The whole point of `vc-hooks' always was to contain some minimum code
needed to recognize what other vc backends are needed, if any, and
thus to prevent requiring elisp libraries of all of these backends in
a lump. It fails to serve this main purpose as follows.
Keep the following in `site-load-packages' (list) value in
`site-packages' in top xemacs build directory.
"../xemacs-packages/lisp/vc/vc-xemacs.elc"
"../xemacs-packages/lisp/vc/vc-hooks.elc"
auto-autoloads.el(c) of the new vc must be up to date and available for things
to work as intended. I have no other suggestions offhand.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6280
days inactive
6710
days old
18 comments
6 participants
participants (6)
-
Ilya N. Golubev -
Jerry James -
Jerry James -
Norbert Koch -
Stephen J. Turnbull -
Ville Skyttä