[Top][All Lists]

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

Re: [AUCTeX] TEXINPUTS as local variable

From: Akim Demaille
Subject: Re: [AUCTeX] TEXINPUTS as local variable
Date: Thu, 19 May 2005 17:45:45 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

>>> "David" == David Kastrup <address@hidden> writes:

 > I don't think that just using "make something.dvi" requires overly
 > strict conditions.  We already use texexec with ConTeXt.

You speak Chinese to me, but OK :)

 >> > 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.
 >> Seems tough to me :)

 > Probably too insane.  Instead one should probably have the Makefile
 > provide some special rules for regions.  Nobody but AUCTeX users would
 > probably need them.

I'm not sure how you are now simplifying the problem.  In addition it
means that now, even if the dvi file is up to date, but not the bbl
file, then you'd have to run make dvi anyway just to learn the
additional paths.  And you rely on how the path are specified (will
you decode calls to texi2dvi?).

 >> > Then it would seem to be necessary to stop AUCTeX from losing
 >> > usefulness in connection with Makefiles.
 >> The more I think about this, the more I find you're quite brave!

 > It is not brave to think about how something should be done properly.
 > Actually doing the stuff would be a different matter. 


 > I just want to avoid having too many hotpatches installed (and
 > consequently have people rely on them) that don't really solve the
 > underlying problem, but just a minor aspect of it.  Such
 > half-solutions can then get in the way of doing a _real_ solution once
 > somebody actually attempts doing that.

Honestly, your proposal would certainly solve my problem, but I'm not
convinced it is a better solution.  For instance, people using other
tools than texi2dvi, or other means to extend their TeX paths, are out
of the game.  Making this explicit as an Emacs local variable is
indeed more work for the user, but it pays off, as you already know
for things such as TeX-master (and at that point you probably didn't
stress that this feature was not available to non AUCTeX users).

I still think my proposal was simpler, and more robust.

But we certainly agree that in a better TeX-world, such a thing would
be coded into a single universal file describing the file and its
dependencies.  Then every higher-level tool could just read that file.

reply via email to

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