headers
Remo | 29 Jul 21:48
Favicon

Improved flexibility of the TeXify, PDFTeXify etc. macros

If have a proposal for a (hopefully) little modification of the way the 
standard TeX macros (TeXify etc.) work.

My use case looks as follows:
With WinEdt 5.5 I edit files that are part of a bigger LaTeX file (only 
the contents without the documentclass and package stuff). Every file 
can be processed separately using a wrapper file that calls the WinEdt 
file with the \input directive. But that means that WinEdt has to be 
able to TeXify a file which is not currently opened but dynamically 
created. In my projects there exists also a main file that (using a 
different wrapper file) can be TeXified.

To write the necessary macros it would be very helpful if there would be 
a way to call the TeXify, PDFTeXify etc. macros with the name of the 
file to be processed as a parameter, for example stored in %$('TeXify-
Parameters-OnTheFly');. If %$('TeXify-Parameters-OnTheFly'); is set and 
not empty, the settings in %$('TeXify-Parameters'); are ignored. I know 
that I can customize the file name in the Execution Modes window or that 
I could simply save and change %$('TeXify-Parameters'); before calling 
TeXify.edt (and restore it afterwards), but the macros still contain 
references to %P/%N, for example when checking whether target files (%P
\%N.dvi, %P\%N.pdf) exist. 

If I change the standard macros myself I will have to do that again with 
every new version. With this change it would be possible to use the 
macros in a modular way within the self-written ones.

Of course I also appreciate ideas of how to do that with the given (and 
- by the way - very flexible and sophisticated) macros.
(Continue reading)

Permalink | Reply |
headers
David Huffer | 30 Jul 16:51

RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

Remo, I'm not all that clear about what you are trying to do so
I've included some questions here...

On Tuesday, July 29, 2008 3:50, Remo  wrote:

 > ...With WinEdt 5.5 I  edit  files  that  are
 > part  of  a  bigger  LaTeX  file  (only  the
 > contents   without   the  documentclass  and
 > package stuff). Every file can be  processed
 > separately  using  a wrapper file that calls
 > the WinEdt file with the \input directive...

That's a little unclear. When you say "...that calls the WinEdt
file..." what exactly do you mean?  Not a TeX file? Or do you
mean "...that calls the TeX file..."?

The use of a main tex file that \includeS or \inputS
"sub-documents" is standard and, in my view, indispensable when
working with large documents. I do this even with small
documents that include tables. But these subdocuments aren't
themselves complete as they dont include a preamble or the
begin/end document commands. They are meant to be part of the
document that \includeS or \inputS them.

Are you saying you want to treat these subdocuments themselves
as complete files and simply pretend they share the preamble of
some other document?

 > ...But that means that WinEdt has to be able
 > to  TeXify  a  file  which  is not currently
(Continue reading)

Permalink | Reply |
headers
Remo | 30 Jul 17:38
Favicon

RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

Hi David,
OK, I try to clarify my situation:
I am teaching physics and write all my course documents in LaTeX. For 
each course I create a WinEdt project containing lecture notes, 
exercises, worksheets, slides etc. Every document has the same 
structure: (remarks on the right side in upper case)
<<
%SOCDI					THIS IS THE HEADER
%Class:course2			CONTAINING INFORMATIONS FOR THE
%Type:slide				WINEDT MACROS
%EOCDI

\cdiStart{slide}			THIS TELLS LATEX THAT THIS IS A SLIDE

\cdiSetTitle{%%%}			TITLE OF THE DOCUMENT

\cdiSetDescription{			DOCUMENT DESCRIPTION
   %%%					USED ONLY WHEN THE WHOLE COURSE IS
   %%%					PROCESSED TO CREATE AN OVERVIEW PAGE
}

\cdiSetContents{			CONTAINS FINALLY
   %%%					THE LATEX CODE
}

\cdiEnd				END OF THE DOCUMENT
>>

I wrote a bunch of LaTeX macros that compile all these parts into a 
course document. The main file of this project contains the necessary
(Continue reading)

Permalink | Reply |
headers
David Huffer | 30 Jul 17:46

RE: RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

Is \includeonly too restrictive? 

--
 David
 
Permalink | Reply |
headers
WinEdt Team | 30 Jul 18:10
Favicon

Re: RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

> Now I would like to TeXify this wrapper file _temp.tex. It
> would be perfect if I could use the texify.edt macro, but that
> is not possible as long as the macro uses the %N\%P registers
> to find out the name of the file to be TeXified (or the name of
> the dvi or pdf output file).
>
> Sorry for this long explanation. I hope to be clearer this
> time.

You should take a look at the Compile Selected.edt macro. This
macro is essentially a "wrapper" for [pdf]texify.edt. Instead
of introducing new variables and making texify macros even more
complicated you should write a new "wrapper" macro that
temporary resets the main file before calling texify.edt and
then restores the original one back. This way texify can use
%N. Compile Selected.edt does exactly that!

You can even make and exit handler to restore the original main
file (in case you cancel the compilation).

Resetting the main file for the time of compilation is a
simpler solution than the one proposed in your original email.

Best regards,

alex
Permalink | Reply |
headers
Remo | 30 Jul 20:05
Favicon

Re: RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

Thanks, Alex. That was exactly what I was looking for.
Remo

> > Now I would like to TeXify this wrapper file _temp.tex. It
> > would be perfect if I could use the texify.edt macro, but that
> > is not possible as long as the macro uses the %N\%P registers
> > to find out the name of the file to be TeXified (or the name of
> > the dvi or pdf output file).
> >
> > Sorry for this long explanation. I hope to be clearer this
> > time.
> 
> You should take a look at the Compile Selected.edt macro. This
> macro is essentially a "wrapper" for [pdf]texify.edt. Instead
> of introducing new variables and making texify macros even more
> complicated you should write a new "wrapper" macro that
> temporary resets the main file before calling texify.edt and
> then restores the original one back. This way texify can use
> %N. Compile Selected.edt does exactly that!
> 
> You can even make and exit handler to restore the original main
> file (in case you cancel the compilation).
> 
> Resetting the main file for the time of compilation is a
> simpler solution than the one proposed in your original email.
> 
> Best regards,
> 
> alex
>
(Continue reading)

Permalink | Reply |
headers
Remo | 30 Jul 20:06
Favicon

RE: RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

Hi David,

> Is \includeonly too restrictive? 

Yes, unfortunately it is.
Remo
Permalink | Reply |
headers
David Huffer | 30 Jul 20:16

RE: RE: RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

It's strange that you would rather interactively select parts of your
document to process rather than programmatically select the parts. What
about \includeonly is too restrictive?  Maybe I'm missing something.  I
use it when I only want, say, certain sections, to appear in a pdf. I
don't think I would have nearly as much flexibility if I were to rely
merely on selecting text...what do you do when including noncontiguous
selections? 

--
 David
Permalink | Reply |
headers
Remo | 31 Jul 08:42
Favicon

RE: RE: RE: Improved flexibility of the TeXify, PDFTeXify etc. macros

I do not select parts of a document. The approach of Alex when 
implementing the "compile selected" functionality is just the same I 
will use for my purpose.

The problem is that my LaTeX macros do much more than simply including 
documents. First they process all course documents (of course using 
\include) and for example read all descriptions of the slides (defined 
by \cdiSetDescription) and (using \immediate\write) generate a LaTeX 
document that displays an enhanced contents index including the 
descriptions of the slides. Or they generate a list of all solutions of 
the exercises, that will be included at the end of every exercise. All 
information about a specific exercise document is included in this 
document, but will be spread and repeated when generating the whole 
course. LaTeX uses the same approach to create an index. In this way I 
can include the same documents in different courses by simply adding the 
file to the WinEdt course project.

If you're interested in the details I can send you an example, but 
perhaps rather through email than this news thread. We are a little bit 
off topic now.

Remo

> It's strange that you would rather interactively select parts of your
> document to process rather than programmatically select the parts. What
> about \includeonly is too restrictive?  Maybe I'm missing something.  I
> use it when I only want, say, certain sections, to appear in a pdf. I
> don't think I would have nearly as much flexibility if I were to rely
> merely on selecting text...what do you do when including noncontiguous
> selections?
(Continue reading)

Permalink | Reply |

Gmane