Akim Demaille <[EMAIL PROTECTED]> writes: >>>> "David" == David Kastrup <[EMAIL PROTECTED]> 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 _______________________________________________ auctex mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex
