11:46 a.m.
Hello,
as you probably have noticed, AUC TeX's maintainer has changed and
the development site has moved to
<URL:http://savannah.nongnu.org/projects/auctex>;. The currently
released stable version is 11.13, the current beta version is 11.14
(which contains another important fix for multi-directory projects).
In the archives for this list, I have dug up a reference to an
interaction problem of preview-latex with other XEmacs packages such
as Gnus. This bug has been fixed starting with preview-latex 0.7.5.
The current release of preview-latex is 0.7.7.
It is a shame that XEmacs still ships with the appallingly outdated
AUC TeX 10.0g: a lot of TeX packages have gained support in the mean
time, and a lot of bugs have been fixed.
We get frequent complaints from AUC TeX users both on the auc-tex and
the preview-latex related discussion lists.
Additionally, it would be nice if preview-latex was also offered as
part of the normal package repositories. It is already organized as an
XEmacs package except for additional TeX styles. Those could
probably be put into their own subdirectory, and that could be added
with
(setenv "TEXINPUTS" (concat "~/package-directory/preview-tex-files:"
(getenv "TEXINPUTS)))
into TeX's usual search path in case the user does not want to add
those files generally into his local TeX styles.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
7:11 p.m.
On Tue, 2002-12-17 at 13:46, David Kastrup wrote:
as you probably have noticed, AUC TeX's maintainer has changed
[...]
It is a shame that XEmacs still ships with the appallingly outdated
AUC TeX 10.0g: a lot of TeX packages have gained support in the mean
time, and a lot of bugs have been fixed.
You're right, the latest real update to the auctex XEmacs package
happened in 04/2001, when it was upgraded to 10.0g.
Additionally, it would be nice if preview-latex was also offered as
part of the normal package repositories.
Would you be interested in maintaining these packages for us? That
would be great; the obsoleteness of the auctex package is mostly due to
missing XEmacs maintainer for it. I'm sure that wouldn't happen if the
upstream maintainers/authors (== you in this case) would take care of
them in XEmacs packages CVS as well... what do you say?
Another question, do preview-latex and the new auctex work with XEmacs
21.1[.14]? They should; unless something devastating happens, we'll
support running and building packages on 21.1 until about June'ish 2003.
It is already organized as an
XEmacs package except for additional TeX styles. Those could
probably be put into their own subdirectory, and that could be added
with
(setenv "TEXINPUTS" (concat "~/package-directory/preview-tex-files:"
(getenv "TEXINPUTS)))
into TeX's usual search path in case the user does not want to add
those files generally into his local TeX styles.
Assuming the styles would be installed as DATA_FILES in the XEmacs
package, I think (locate-data-directory "preview-latex") would do what
you want; return something like
"/path/to/your/packages/dir/xemacs-packages/etc/preview-latex/".
Cheers,
--
\/ille Skyttä
scop at xemacs.org
11:14 p.m.
Ville Skyttä <scop(a)xemacs.org> writes:
On Tue, 2002-12-17 at 13:46, David Kastrup wrote:
> as you probably have noticed, AUC TeX's maintainer has changed
> [...]
> It is a shame that XEmacs still ships with the appallingly
> outdated AUC TeX 10.0g: a lot of TeX packages have gained support
> in the mean time, and a lot of bugs have been fixed.
You're right, the latest real update to the auctex XEmacs package
happened in 04/2001, when it was upgraded to 10.0g.
> Additionally, it would be nice if preview-latex was also offered
> as part of the normal package repositories.
Would you be interested in maintaining these packages for us?
No. I don't use XEmacs. I am an Emacs user myself. It is certainly
more than enough trouble for me trying to try to keep the stuff I
maintain basically running with XEmacs. I certainly won't volunteer
for more. As it is, XEmacs is already causing me more work than I'd
care for.
I'd so this, if at all, on a strictly tit for tat basis: somebody
implement a well-working package system for both Emacs and XEmacs,
and packages will appear.
Another question, do preview-latex and the new auctex work with
XEmacs 21.1[.14]? They should; unless something devastating
happens, we'll support running and building packages on 21.1 until
about June'ish 2003.
AUCTeX yes, but IIRC both the display engine of 21.1.14 as well as
the process system were pretty much broken. 21.4.9 (21.4.8 on
Windows) is the first XEmacs known to display reasonably for
preview-latex. We don't use any undefined commands in 21.1.14: it is
just that what is there sucks.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
9:49 a.m.
>>>> "David" == David Kastrup
<David.Kastrup(a)t-online.de> writes:
David> It is certainly more than enough trouble for me trying to
David> try to keep the stuff I maintain basically running with
David> XEmacs. I certainly won't volunteer for more. As it is,
David> XEmacs is already causing me more work than I'd care for.
It's possible it would be _less_ work than dealing with (for example)
regular bug reports from people using old versions of AUC-TeX on
XEmacs, and people trying to set up preview-latex on XEmacs without a
package. (Eg, I've had _no_ set up questions about latin-unity that
weren't due to real bugs. The user had the set up right, it just
didn't work.) Set up costs of an XEmacs package for the maintainer
are non-negligible, but not that high. We'd help substantially with
that. Maintenance cost of the package infrastructure is mostly borne
by XEmacs people.
I can't promise the results I've seen (latin-unity is a unusually
setup-free package), but AUC-TeX is typical of the status of large 3rd
party packages that are maintained by the XEmacs Dev Team. Packages
maintained by their owners or by someone close to the package core are
usually more up-to-date. This will make your users happier, for sure.
Or maybe you can find someone who keeps up-to-date with AUC-TeX or
preview-latex who would be willing to keep the XEmacs repository
up-to-date.
David> I'd so this, if at all, on a strictly tit for tat basis:
David> somebody implement a well-working package system for both
David> Emacs and XEmacs, and packages will appear.
Implementation is done, and you know that, David. Getting the UI and
maintenance infrastructure into GNU Emacs is not under our control.
RMS flat-out refused to consider it on at least two occasions, and a
few months ago an effort to do something cooperative, initiated IIRC
by Mike Sperber and which eventually included serious discussion about
the package system, petered out once again, I'm not sure why.
--
Institute of Policy and Planning Sciences 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.
10:18 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
<David.Kastrup(a)t-online.de> writes:
David> It is certainly more than enough trouble for me trying to
David> try to keep the stuff I maintain basically running with
David> XEmacs. I certainly won't volunteer for more. As it is,
David> XEmacs is already causing me more work than I'd care for.
It's possible it would be _less_ work than dealing with (for example)
regular bug reports from people using old versions of AUC-TeX on
XEmacs, and people trying to set up preview-latex on XEmacs without a
package.
The package system is not powerful enough to deal with all settings
those packages work under. You might have wildly different TeX
distributions with their own directory components, you have different
GhostScript executable names, you have different ways of adding local
TeX styles and so forth and so on. preview-latex's installation is
./configure; make; make install
on all systems (where you need a few more options when you are not
kpathsea based). Of course, this has the disadvantage of requiring a
toolset being able to run autoconf.
There is no package system for GNU Emacs, and I am not abandoning GNU
Emacs support. Having to cater for a package based install thus is
more work. Either somebody else does it or it does not get done,
period.
David> I'd so this, if at all, on a strictly tit for tat
basis:
David> somebody implement a well-working package system for both
David> Emacs and XEmacs, and packages will appear.
Implementation is done, and you know that, David. Getting the UI
and maintenance infrastructure into GNU Emacs is not under our
control.
From what I have heard, the author of the XEmacs package system is
working on replacing it by yet something different which would then
again make the version taken into GNU Emacs obsolete.
Also, if there is going to be any sense in the operation, it would
need to be done in a way to make packages possible that work with both
Emacs and XEmacs. I don't see that. The venture only makes sense to
me if it means I can create packages that will work on both systems.
This means, of course, that byte compilation should happen at
installation time, as well as weeding out unneeded package parts for
the particular Emacs. It would be a boon to be able to keep files
that are not Emacs-version-specific in common subdirectories. In this
case, you would need to update packages in sync, which might not be
feasible at all times. So this should be optional, and probably is
not really that much of importance.
In short: a port that will make Emacs have something similar but
incompatible to XEmacs does not help people in the long run.
The idea is to make less work, not more.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
5:55 p.m.
On Wed, 2002-12-18 at 12:18, David Kastrup wrote:
The package system is not powerful enough to deal with all settings
those packages work under. You might have wildly different TeX
distributions with their own directory components, you have different
GhostScript executable names, you have different ways of adding local
TeX styles and so forth and so on.
How do you suggest that it would be rolled into a XEmacs package then?
There is no package system for GNU Emacs, and I am not abandoning
GNU
Emacs support. Having to cater for a package based install thus is
more work. Either somebody else does it or it does not get done,
period.
Given that you said the package organization is already almost done,
that wouldn't be a big job, I guess. Unfortunately, without a
designated maintainer in XEmacs, the same as has already happened to
auctex may happen to preview-latex. The XEmacs preview-latex (and
auctex) maintainer doesn't have to be you, but we do need someone to
look after them. I have plenty on my plate already. Hands up,
volunteers.
>From what I have heard, the author of the XEmacs package system
is
working on replacing it by yet something different which would then
again make the version taken into GNU Emacs obsolete.
Could you provide more specific pointers, who is working on exactly
what? I'd be really interested to hear more about this.
--
\/ille Skyttä
scop at xemacs.org
3:12 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
> From what I have heard, the author of the XEmacs package
> system is working on replacing it by yet something different
> which would then again make the version taken into GNU Emacs
> obsolete.
Ville> Could you provide more specific pointers, who is working on
Ville> exactly what? I'd be really interested to hear more about
Ville> this.
David is talking hearsay of rumor of whispers.
Here's what I know. Steve Youngs is probably authoritative; I can't
imagine anything would have happened up to about 6 months ago without
consulting him.
The package system is split into three fairly independent parts, with
three different authors. The run-time pathfinding support is by Mike
Sperber. The envisioned changes there AFAIK amount to inverting the
type and the package in the packages hierarchy (ie, {etc,lisp}/auctex
-> auctex/{etc,lisp}). This will allow "opaque" packages that want to
completely manage their internals, with only auto-autoloads and
custom-load having fixed locations. (Obviously this isn't suitable
for support libraries.) It also will satisfy the current "wanna run
packages in-place" RFE.
The second part is the build and install mechanism, most importantly,
XEmacs.rules. Primary author is Steve Baur, who is not doing any
XEmacs development whatsoever at the moment. Secondary, but major,
contributions from Jan Vroonhof, Mike Sperber (or was that just
tripling the number of DATADIR defines to accomodate JDEzilla?), Steve
Youngs, and maybe some others. None of them have any plans for this
AFAIK. Adapting this to a new package hierarchy layout would be
trivial, because (at least for "opaque apps") you'd just tar up the
source tree and slap it down in place. The main changes planned in
build'n'install are REQUIRES stuff, which is Jerry James, you, and
Rendhalver, so you tell me. ;-)
The third part is the package-ui stuff, which has a bunch of authors
including Darryl Okahata (package-ui), Pete Ware, Jan V, and Greg
Klanderman (package-get). There are lots of proposals for working on
these (Steve Y, me, Rendhalver has shown some interest), but nothing
concrete. (At least, not since I seem to have lost my "three-layer"
transport for packages code. :-( )
--
Institute of Policy and Planning Sciences 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.
4:24 p.m.
David.Kastrup(a)t-online.de (David Kastrup) writes:
The package system is not powerful enough to deal with all settings
those packages work under. You might have wildly different TeX
distributions with their own directory components, you have different
GhostScript executable names, you have different ways of adding local
TeX styles and so forth and so on. preview-latex's installation is
./configure; make; make install
on all systems (where you need a few more options when you are not
kpathsea based). Of course, this has the disadvantage of requiring a
toolset being able to run autoconf.
I've said before that IMHO, work on an Emacs package system should
start with support for Autoconf. Ie, it should be easy to use
Autoconf to make Emacs packages so that they can be installed with
"./configure; make; make install".
David has done all the work manually, I guess. (I haven't looked at
the code.)
But it seems that both the XEmacs and the Emacs folk think that
code outside of *.el files can be ignored, more or less.
But from time to time, it turns out that this is just not enough.
What about gnuserv? How is gnuserv handled in XEmacs? Maybe this
mechanism could be used for Preview-LaTeX, as well.
What about Remembrance Agent?
What about starttls?
ebrowse?
Hexl-mode?
Movemail?
A lot of questions, I'm sure somebody has answers.
--
Ambibibentists unite!
5:35 p.m.
>>>> "Kai" == Kai Großjohann
<kai.grossjohann(a)uni-duisburg.de> writes:
Kai> I've said before that IMHO, work on an Emacs package system
Kai> should start with support for Autoconf.
*chortle* First, get XEmacs to work with Autoconf 2.5x. But autoconf
is such an ugly hack to start with. Yes, it's necessary to handle the
brain-damage in system libraries and so on, and it's hard to imagine
how it could be made "pretty". But searching $PATH and similar
command UI-level operations can just as easily be done in Lisp as in
m4/autoconf.
Kai> What about gnuserv? How is gnuserv handled in XEmacs?
Built in core.
Kai> Maybe this mechanism could be used for Preview-LaTeX, as
Kai> well.
Nope. David won't even maintain an XEmacs package, he surely would be
unwilling to suffer the restrictions that putting preview-latex in
core would entail. Not to mention that it would surely be vetoed.
Kai> Hexl-mode?
Kai> Movemail?
Movemail, certainly, and hexl, AFAIK, are built in core. They share
configure with XEmacs. I don't know about the others you mention.
But they have nothing to do with David's use of autoconf, if his
comment accurately describes the total use of autoconf. According to
David's description, preview-latex uses autoconf for quite trivial
PATH-chasing and checking for whether options are present that could
just as easily be done in Lisp.
--
Institute of Policy and Planning Sciences 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:17 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
But they have nothing to do with David's use of autoconf, if his
comment accurately describes the total use of autoconf. According to
David's description, preview-latex uses autoconf for quite trivial
PATH-chasing and checking for whether options are present that could
just as easily be done in Lisp.
I've now scanned aclocal.m4, and that's indeed what he appears to be
doing. However, the file is 10k, so there is some amount of work to
be done in porting it all to Lisp. (Even though parts of it are
already in Lisp.)
--
Ambibibentists unite!
1:42 p.m.
>>>> "Kai" == Kai Großjohann
<kai.grossjohann(a)uni-duisburg.de> writes:
Kai> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> According to David's description, preview-latex uses
autoconf
> for quite trivial PATH-chasing and checking for whether options
> are present that could just as easily be done in Lisp.
Kai> I've now scanned aclocal.m4, and that's indeed what he
Kai> appears to be doing. However, the file is 10k, so there is
Kai> some amount of work to be done in porting it all to Lisp.
Kai> (Even though parts of it are already in Lisp.)
Oh, I don't deny that it would be "some work" to port.
But _we're_ not likely to do it, because then we'd have another pile
of rapidly bitrotting code on our hands, whose author is decidedly
biased against cooperation with XEmacs. Better to spend the effort
updating AUC-TeX, IMO.
--
Institute of Policy and Planning Sciences 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.
7996
days inactive
8011
days old
10 comments
4 participants
participants (4)
-
David Kastrup -
Kai Großjohann -
Stephen J. Turnbull -
Ville Skyttä