Re: [AUCTeX] TEXINPUTS as local variable

[David Kastrup]

Akim Demaille <address@hidden> writes:

>>>> "David" == David Kastrup <address@hidden> writes:
>
>  >> 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.
>
> Well, sure, that's another valid answer.  I might have overlooked
> it, but it seemed harder to me, unless there are strict conditions
> over the Makefiles.

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

>  >> AUCTeX plays the role of an IDE here.
>
>  > Not really.
>
> Well, as a compile center, able to compile the master file instead of
> the current buffer, it offers features that are closer to an IDE than
> plain M-x compile.
>
>
>  > 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.

>  > 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.  As project
leader, I am thinking about a lot of things that actually should
really get done at some point of time.  The TODO file is quite long,
and stuff gets added faster into it than worked off.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum