bug-auctex
[Top][All Lists]
Advanced

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

Re: [Bug-AUCTeX] Re: texi2dvi: AUC-TeX and depots


From: Ralf Angeli
Subject: Re: [Bug-AUCTeX] Re: texi2dvi: AUC-TeX and depots
Date: Wed, 21 Sep 2005 15:31:23 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

* Reiner Steib (2005-09-21) writes:

> On Tue, Sep 20 2005, Akim Demaille wrote:
>
>> So I guess some more people are likely to make the move if it proves
>> useful.  And indeed texi2dvi does provide some services that AUC-TeX
>> does not support.  I made this NEWS addition precisely to prompt
>> AUC-TeX users.
>>
>> I agree pdftexi2dvi is bad, but that's really how AUC-TeX works --
>> currently.  

I don't think that a deficiency of AUCTeX should lead to Texinfo tools
being changed.  Rather AUCTeX should be fixed (that's probably why
Reiner CC'ed bug-auctex).

And I don't think that the code for adding prefixes to processors
(like latex --> pdflatex) or viewers (like xdvi --> oxdvi) will stay
in the long-term.

If somebody is interested I could post a very very _very_ rough patch
to tex.el which shows some ideas for a scheme for viewer selection and
the creation of the respective command lines.  Maybe this could be
extended to a scheme for any type of tool in a tool chain from source
file to final output.

The idea is basically that for every tool you define what type it is
(processor, converter, viewer, etc.), what the command name is, and
what command line options there are for different purposes.  Then you
would be able to plug them together in order to create a toolchain.
With several toolchains defined for different purposes you would not
switch on and off separate modes (like PDF mode or Omega mode now) but
rather switch between toolchains.  Of course there would have to be
the possibility to deviate from the default "path" of a toolchain at
every step.  For example if you have the chain `LaTeX source
--latex--> DVI file --dvips--> PostScript file --ps2pdf--> PDF file'
you should be able to create a PDF file from the DVI file right away
e.g. with dvipdfm.  Such a possibility would be especially important
in case of Texinfo for producing and viewing the different output
formats.

Okay, that would be the radical way.  For now I could just look if we
can support stuff like `texi2dvi --pdf' with our current scheme of
placeholders and expanders in command line creation.

-- 
Ralf




reply via email to

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