Re: [AUCTeX] TEXINPUTS as local variable

[Akim Demaille]

>>> "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.

AUCTeX plays the role of an IDE here.  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.


 >> - 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...

 > 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.  But when I used AUCTeX as an IDE, there are some
inadequacies.  The same problem, of course, happens with Texinfo
documents with different source directories: make does a perfect job
thanks to the various -I, but because AUCTeX is an non-make-based IDE,
it is harder to exploit to its full power.


 >> - What exactly do you mean on the additional shell invocation?

 > Separate project, separate environment variables.  Separate
 > environment variables require a separate shell.  Whether you are using
 > make, Emacs or bash.

I was referring to execve: I fail to see how the suggestion of having
a TeX-local-TEXINPUTS or whatever, requires one additional shell.
When I run

     CC=gcc ./configure

there is no additional shell as compared to

      ./configure


 >> The workaround you propose, I guess, does require this.  But if it
 >> becomes a feature from AUC-TeX, no such shell is required, only
 >> the env is changed.

 > The current project management of AUCTeX (like integrating make and
 > similar)

I'm not asking for make support.  I fail to see what good there would
be in there.

 > is not such that I want to start integrating pseudofeatures like
 > local floating environments.

Just stop calling this floating environment :)

 > 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_!



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), 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 AUCTeX.

They should certainly not have to tweak their envvars, this breaks the
localness of the process.  So one would like to be able to teach
AUCTeX of these *local* extensions.

If only one could embed this into the TeX file itself, there would be
no such need.  But that's not the case, unfortunately.


It seems to me that it is inconsistent from AUCTeX to support
something like TeX-style-local, that means that AUCTeX supports the
idea of a local extension of the mode, but not the dual: a local TeX
extension path.


Am I making more sense?