[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX] TEXINPUTS as local variable

From: David Kastrup
Subject: Re: [AUCTeX] TEXINPUTS as local variable
Date: Thu, 19 May 2005 16:30:40 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Akim Demaille <address@hidden> writes:

>>>> "David" == David Kastrup <address@hidden> writes:
>  > AUCTeX is not better than anything else.  Your complaint is that
>  > AUCTeX does not provide a different environment for each project
>  > all in one Emacs session.
> Well, it turns out that AUC-TeX is different that what happens from
> most other situations: they use a Makefile in which these facts are
> encoded, while AUC-TeX bypasses the point of having a Makefile.

Well, then the right solution would seem to make AUCTeX better
interface with Makefiles, not add a complete new layer that you can
get to do all the stuff that _is_ already working.

> AUCTeX plays the role of an IDE here.

Not really.

> And IDE do cope with these package-layout issues.
>  > But no other tool or shell that I know of provides that.  So I
>  > don't see how you are worse off with AUCTeX than with anything
>  > else.
> I'm certainly not saying AUCTeX is making things worse :) I was
> pointing out that in its tradition of making things easier, I felt a
> possible path for improving some situations.
> Up to now I ran M-x compile instead of latex-command.  But it is a
> pale replacement for AUCTeX, and for instance does not scale to the
> compilation of partial inputs.

Well, then we need a better interface into make.  Something like doing
make -n test.dvi
and then parsing the output and massaging it for working with a region

>  >> - In fact this problem is acknowledged by TeXperts themselves,
>  >> see the introduction of path mechanisms in Graphics: too bad
>  >> there is no equivalent for .sty etc.
>  > I don't see it as a shortcoming as AUCTeX not to provide
>  > something which is not generally available.  You try picturing
>  > this as a shortcoming of AUCTeX, and I don't follow that.
> I'm sorry if I gave the impression it's a shortcoming of AUCTeX:
> it's a shortcoming of TeX, and AUCTeX, in general, is trying to
> address them.  For instance TeX has an incredible stupid
> incomprehensible (for humans) way to report errors, and AUCTeX does
> improve the situation...

Not much, though.

>  > Basically you are asking for a feature that will make your
>  > project depend on AUCTeX in order to work at all.  I don't see
>  > that this is a good idea.
> That's where you are wrong: the packages I use distchecks without
> any problem, thanks.

Then we should find a way of making AUCTeX work with that, instead of
inventing a way for reinventing the wheel.

>  > I can't see that this is _the_ way to go, and it certainly does
>  > not make for portable projects since the environment variables
>  > don't magically transfer to everybody else that uses the files.
> I'm sorry, but there is some misunderstanding running here, because
> precisely I provide a means to have this "magically transfer to
> everybody else that uses the files", while the current status
> _doesn't_!

I don't see how AUCTeX environment variables would transfer to
non-AUCTeX users.

> Here is the situation I'm picturing.
> Some people work on a free TeX/LaTeX/Texinfo document, free in the
> sense that it is a source package.  There are chapters, or different
> lectures, grouped in separate directories.  (That's just like a
> regular source package.)
> Because these directories share files (.bib, .bst, .sty etc.), just
> like a usual include/ directory for C projects, there is an include/
> (or style/ etc.) directory in there.  The Makefile takes care of all
> the -I details.
> But *because AUCTeX "bypasses the Makefile"* (which of course is
> definitely a good thing),

I am not convinced of that.

> the parallel with M-x compile stops.  And then start the problems:
> one has to find a means to teach the *-commands how to enrich the
> environment so that \usepackage etc. work properly.  Or they resort
> to using M-x compile, losing a significant part of the usefulness of

Then it would seem to be necessary to stop AUCTeX from losing
usefulness in connection with Makefiles.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]