[OS X TeX] Flashmode for Emacs : Whizzytex + Enrico Franconi's Carbon Enhanced Emacs + TeXniscope
Philipp Mathey
pmathey at uwo.ca
Sat Apr 9 20:25:12 EDT 2005
Hello-
thanks for the comments. Just to clarify some points :
> This is strange. The terminal is known for having slow graphics, so
> that
> one bottle-neck is actually writing the tex messages on the screen!
> This is particularly articulate on computers without Quartz Extreme.
> On this iBook 500 MHz, running tex from within Alpha is 10-20 percent
> faster than running in the terminal. There have been several
> testimonies of this sort on this list and on the AlphaTcl-users list.
>
To compile, one may
(1) working within emacs ( Carbon Enhanced Emacs), one may issue the
command "compile this document" via some short-cut or the emacs menu,
(2) Open a Terminal ( Terminal.app) and enter "pdflatex document.tex".
(3) Open X11. This will open an 'xterm'. Enter "pdflatex
document.tex".
My experience is that (3) is faster than (1).
I don't know about (2) - I don't use Terminal.app.
> (Two empty lines? Usually tex needs only one empty line to delimit a
> paragraph.)
You misunderstand. The word "paragraph" here has a special meaning : it
does not refer to the layout of the compiled document, but instead it
refers to a 'slicing mode' - one of several ways in which whizzytex
'slices' the source tex-file . At every given moment, only the
so-called 'slice' is recompiled. The slice is a user-definable region
of the tex-file. It can be the current ( i.e. where the cursor in the
emacs buffer is located at the moment) chapter, section, subsection,
paragraph ... ( there are more, I forgot) . It may also be set to be
the whole document.
For example, when set to 'section', only the current section is
compiled. One other option is 'paragraph' : one 'paragraph' ( in the
emacs buffer) ends and a new 'paragraph' begins where there are two
empty lines in the emacs buffer. I changed the default of 2 empty lines
to 4 empty lines ( see instructions). This makes it easier to separate
'paragraphs'.
So, for example, if the slicing mode is set to 'paragraph' and if this
is your emacs buffer containing the tex source file :
bla bla bla
bla bla bla 1
bla bla bla
bla bla bla 2
bla bla bla
bla bla bla 3
bla bla bla
and the cursor is in either 1 or 2, then the slice contains 1 and 2,
but not 3. Moving the cursor down to 3, makes 3 the new current slice.
Then only 3 is compiled. If you wish 1, 2, and 3 to be in the same
slice , just remove one or to lines :
bla bla bla
bla bla bla 1
bla bla bla
bla bla bla 2
bla bla bla
bla bla bla 3
bla bla bla
Now 1, 2, and 3 are in the same slice.
So, while in 'paragraph mode' , by just adding or removing an empty
line or two to your emacs buffer, you determine how whizzytex slices
the document. But perhaps you prefer a more rigid slicing mode such as
'section'.
> An important principle of the flash script in Alpha is that no
> alterations
> are required in the tex documents, and that the script never writes to
> your
> tex document or saves it for you or anything. In this way the document
> remains *yours* and you have complete control over it.
Well, you only have to add one line at the beginning - not a big deal,
is it ? You can add it to your template.
And, of course, you still have "control" over your tex-file !
> This looks like a strange shortcoming. Does it mean that if you
> suddenly
> decide to use flash for some minutes you have to restart emacs from the
> xterm?! I
No.
When using whizzytex with TeXniscope, of course you don't need X11( for
what ?!)
But if you wish to use advi, xdvi, gv or xpdf as previewer, then you
need X11. In that (latter) case, you need to open emacs from an xterm
. Of course , if linux was the operating system, everything would be
based on the X -windows system, but since MacOsX has its own window
manager , quartz, frequently, when running applications that require
X11, special care has to be taken. For example, an obvious problem
might be that the DISPLAY variable is not set correctly. Normally
Carbon Enhanced Emacs does not need X11 but in this case it does.
Starting emacs from an xterm has the effect that emacs becomes a child
process of the xterm . Then whizzytex works.
But even with previewers requiring X11 you only have to open emacs
once, at the beginning of your emacs session. Then you may activate,
stop and reactivate whizzytex as many times as you want. You don't have
to "restart emacs" each time.
----------------------
Regarding the issue of speed :
I am currently using whizzytex together with pdflatex and TeXniscope. I
am using the 'microtype' package, among others. With xdvi output, there
are fewer packages/fonts to be used, perhaps this might explain why
advi feels a little faster than xpdf or TeXniscope. But, as I mentioned
in y post, in my opinion, pdftex produces better-looking documents.
I haven't really tried to measure exactly the time delay for changes to
the emacs buffer to become visible in TeXniscope . It's about 3-4
seconds. With advi, it's a little shorter, maybe.
My main motivation for using whizzytex is speed. I feel the 3 seconds
delay is acceptable - it's certainly better than the 15 seconds before
(for that large document I mentioned) .
[ as a side remark (perhaps some people are wondering about that) : the
reason for the 15 seconds was mainly the slowness of xypic : loading
(even when precompiled) xypic-matrices is what slows TeX down and
accounted for a large chunk of those 15 seconds; there were over 90
commutative diagrams in the document; so if you want to compare compile
times, you need to compile latex documents with a similar number of
xypic-matrices]
Still, if you could make your flashmode work together with Enrico
Francon's Carbon Enhanced Emacs , that would be fantastic. I am not
quite sure, though - does it work with pdftex ?
Anyway, I would definitely give it a try. I looked again at your
announcement from January 9 and from today, and I must say it sounds
impressive in terms of speed. If your flashmode could be made to work
with Enrico Franconi's Carbon Enhanced Emacs, and if it supported
pdftex, and if it was faster than whizzytex, I would be using it
instead of whizzytex.
Thanks,
Philipp Mathey
On 9-Apr-05, at 5:19 AM, Joachim Kock wrote:
> And here are some comments on the whizzytex instructions, with some
> technical comparison to the Alpha script.
>
>
>> Whizzytex opens up a previewer and compiles a certain region of your
>> document, the so-called "slice" on-the-fly. In other words, every word
>> or symbol that you enter into your emacs buffer appears in the
>> previewer - almost instantaneously. On my outdated 800 Mhz i-book the
>> delay is about 3-4 seconds ( when using TeXnscope; with advi, it's a
>> little faster)
>
> For the flashmode plugin for Alpha, the delay is about 1 second for
> TeXniscope, and around 0.7 seconds for xdvi. This is measured on an
> iBook 500MHz G3.
>
>
>> a compilation of a large document of about 70 pages with lots of
>> commutative diagrams (xypic) took at least 15 seconds (when
>> issuing the command to compile from an xterm; from within emacs,
>> it took even longer ( why ?)).
>
> This is strange. The terminal is known for having slow graphics, so
> that
> one bottle-neck is actually writing the tex messages on the screen!
> This is particularly articulate on computers without Quartz Extreme.
> On this iBook 500 MHz, running tex from within Alpha is 10-20 percent
> faster than running in the terminal. There have been several
> testimonies of this sort on this list and on the AlphaTcl-users list.
>
>> (1) usually tetex has to load all the packages etc specified in the
>> preamble each time you compile the document; whizyytex has to
>> read/load
>> the preamble at the beginning of the whizzytex-run only once;
>
> The Alpha flash script too uses initex to precompiles the preamble.
> While
> this is not important for long documents, it's an important time saver
> for
> short documents or fragments of documents.
>
>> (2) whizzytex compiles only the current "slice" of the document; the
>> slice can be the whole document, the chapter, section, subsection,
>> paragraph ... I am using the paragraph mode : one paragraph ends and a
>> new one begins where there are two empty lines in the emacs buffer.
>
> (Two empty lines? Usually tex needs only one empty line to delimit a
> paragraph.) The Alpha script uses paragraphs as slices when the
> partial-flash flag is set. There is currently no support for other
> slice sizes, but that's just because the script was proposed as a
> proof of
> concept. It would be easy to implement support for other slice sizes.
>
>
>> What kind of previewers are available ?
>> advi , xdvi, gv, xpdf and TeXniscope.
>
> The Alpha script works with xdvi or with TeXniscope. It's a slightly
> different script for TeXniscope:
> http://mat.uab.es/~kock/alpha-tcl/flashTeXniscope.tcl.gz
>
>
>> Next, you need to install whizzytex.
>
> ... followed by descriptions of setting compile parameters and doing
> 'make' and 'make install'. And instructions for handling PATH, and
> execute permissions and so on. About one page of instructions...
>
> All this is unnecessary with the Alpha script which is interpreted, not
> compiled. And it is run by Alpha's embedded Tcl interpreter, where it
> has
> access to all sorts of internal variables and can react directly on
> internal events, e.g. a character typed in the tex source window.
>
> The fact that it is interpreted and not compiled doesn't seem to make
> a difference in speed -- in fact it seems to be faster. The main speed
> gain comes from relying on notification instead of polling. (For more
> technical details, see the comments in the script itself.)
>
>
>> Now add the following to your default preamble :
>> The first lines should be ( each should be on one line) :
>>
>> %%; whizzy paragraph -pdf "xpdf -bg black -fg blue -g 1025x900 -z 170
>> -remote $$" -initex "pdflatex -ini" -latex pdflatex
>> %; whizzy paragraph -advi advi -A -html Start-Document -(perhaps you
>> like -rv) -geometry 1025x900 -initex "pdflatex -ini" ( or just "latex
>> -ini") -latex pdflatex (or just latex)
>> %%; whizzy paragraph -dvi xdvi -expert -rv -s 5 -fullscreen -offsets 0
>> %%; whizzy paragraph -ps "gv ..."
>
> An important principle of the flash script in Alpha is that no
> alterations
> are required in the tex documents, and that the script never writes to
> your
> tex document or saves it for you or anything. In this way the document
> remains *yours* and you have complete control over it.
>
>
>> Since all of the previewers (advi,xdvi,gv,xpdf) use X11, and since
>> somehow whizzytex requires communication between X11 and emacs back
>> and
>> forth, it seems that the only way for whizzytex to work is by doing
>> the
>> following :
>>
>> -open an xterm.
>> -type "/Applications/Emacs.app/Contents/Resources/sitelisp/emacs"
>>
>> This will open up Enrico Franconi's Carbon Enhanced Emacs but - this
>> is
>> crucial- this emacs process will be a "child process" of the xterm
>> shell.
>
> This looks like a strange shortcoming. Does it mean that if you
> suddenly
> decide to use flash for some minutes you have to restart emacs from the
> xterm?! In Alpha, the viewer is the child process, but this does not
> mean
> that you cannot have xdvi open in advance, because as explained the new
> view job is completely independent of what else you might be doing with
> your tex and dvi files.
>
>
>> If you want, you can change the AutoRefresh Interval of TeXniscope to
>> 1.0 seconds by opening a Terminal and typing
>>
>> defaults write TeXniscope AutoRefreshInterval 1.0
>
> An important speed feature of the Alpha script is that it does not
> work by
> polling but by notification. This means that the various involved
> components do not have to ask each other at intervals if it is their
> turn
> to do their job. These waiting times quickly add up. Instead each
> component notifies the relevant next component, so that there is never
> any
> unnecessary waiting time. So for example, instead of having TeXniscope
> autorefresh at every 0.6 second (this means an average waste of time
> of 0.3
> seconds for every flash cycle!), send it an explicit 'refresh' Apple
> Event
> when the pdf file is ready. And instead of checking at intervals if
> the
> buffer has been modified (or running a new tex run blindly on a file
> that
> has not been modified) set up a hook that detects buffer modification,
> and
> activate the next flash cycle precisely when needed.
>
>
> Cheers,
> Joachim.
>
>
> --------------------- Info ---------------------
> Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
> & FAQ: http://latex.yauh.de/faq/
> TeX FAQ: http://www.tex.ac.uk/faq
> List Post: <mailto:MacOSX-TeX at email.esm.psu.edu>
>
>
--------------------- Info ---------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
& FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Post: <mailto:MacOSX-TeX at email.esm.psu.edu>
More information about the MacOSX-TeX
mailing list