[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AUCTeX-devel] Anybody out there?
[AUCTeX-devel] Anybody out there?
Tue, 03 May 2005 10:43:28 +0200
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
this is my last day at Bachotek, and I am leaving at 14:45. I am now
quitting this session to start on my traditional run around the lake
(which will take hours given my current fitness level).
This means that I won't be having net access for the next week while I
am in Berlin and Greifswald. There is a slight chance that in Berlin
I may be able to do some intermittent net access by visiting Sven, a
hard-core vim proponent. The amount of things I am willing to do for
Anyway, I pretty much have my claws of the current source code. Here
is a list of things that need to get finished for the release:
a) RPM specs need to be created. The current RPM is Emacs-only and
includes everything and the kitchen sink. The README and INSTALL
files from preview-latex and AUCTeX conflict: somebody needs to take a
look at what %doc actually does and fix that. I am still ambiguous
about package distribution, but I think I prefer the
--without-texmf-dir setting. This means duplication of the LaTeX
stuff. I can't think of a sane scheme to avoid that except have
separate auctex-emacs-no-styles, auctex-xemacs-no-styles and
preview-styles packages as an alternative to auctex-emacs and
auctex-xemacs, with the obvious necessary conflicts and dependencies.
Then you can choose to install the styles in your distribution's
standard place (and make them generally available) or skip this and
use the integrated styles. If your distribution comes with its own
preview files in the texmf tree, you would likely be forced to use the
auctex-emacs and auctex-xemacs packages unless we make preview-styles
install into the site-local tree. Since installing preview-styles is
a fine-grained installation decision, this might actually be less
terrible than it sounds at first: a site administrator choosing to
install his own site-wide styles can "just" remove preview-styles
In a similar vein, the auctex-xemacs and auctex-xemacs-no-styles
packages would probably need to go into the site-packages tree in
order to shadow the sumo tarball. We have that already, I think.
Better names and schemes welcome. Who implements this gets to choose.
b) the installation procedures should be checked for sanity. I added
quite a few Makefile targets in the top directory, and similar things
should probably be done in the preview layer.
c) the tarball creation procedure should use a tagged cvs export into
a clean tree and run autogen.sh there. We should not remove
README.CVS and configure.ac and so: they don't take up much stuff and
are properly a part of the source.
d) the versioning of the preview package/subpackage should be done. I
think that we should probably use the AUCTeX release version number in
the bundled package, and a separate preview numbering scheme (but
probably by stealing the AUCTeX detection scheme from aclocal.m4, no
longer relying on CVS tags). I don't have a good idea what version
numbers we should actually put into preview.dtx: after all, those get
released separately, and we'd want a consistent scheme. So perhaps we
should always have a separate internal preview numbering scheme,
though probably not extending it to preview-latex when it is used as
embedded component of AUCTeX.
As part of that, we need to come up with a sane release tagging scheme
for the combined stuff.
e) we need a TeX-set-mode-hook that latex-toolbar can use for changing
its icons when modes get toggled.
f) documentation proofreading. I am certain to have introduced
nonsense, and certainly stuff must be missing.
g) thinking about XEmacs packages. There is still stuff like
TeX-kpathsea-path-delimiter that is not installation-independent, and
probably not even documented, and TeX-style-global and stuff.
I really can't manage all that on my own. I know people are reluctant
to jump in when I am breaking their work all over the place and
introducing new stuff all over in whirlwind manner, but I found that
we really needed to get those changes in for the long-term goal of
getting AUCTeX installed and used everywhere with preview-latex
integrated. So please make yourself acquainted, at least to the level
of proofreading, with what I threw in there. I am quite open to
changes, as long as the basic goals are kept in sight.
Have to run...
David Kastrup, Kriemhildstr. 15, 44793 Bochum
- [AUCTeX-devel] Anybody out there?,
David Kastrup <=