Re: [AUCTeX] TEXINPUTS as local variable

[David Kastrup]

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

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

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum