[OS X TeX]

Jérôme Laurens jerome.laurens at u-bourgogne.fr
Tue Sep 14 03:24:50 EDT 2004

Le 13 sept. 04, à 22:40, Joachim Kock a écrit :

> Hello,
> I am working my way through a backlog of messages on this interesting
> subject of magic-lines and tex bundles.
> Let me briefly express my opinion:
> 1) I agree that using %& for other things than formats is a bad idea.
> (But let me add my compliments to the TeXShhop developers for making 
> the
> experiment and for taking the encoding issue seriously.)
> 2) TeX bundles is an interesting idea, and it might lead to a smoother 
> and
> more Mac-like user experience.  But on the other hand this will 
> inevitably
> lead to bad experiences in terms of portability: the TeX reality will 
> be
> hidden from the users and make them ill-prepared to meet the real world
> (cf. common experiences with Textures users who don't know what a DVI 
> file
> is, and such).  (I am not against the idea, but at least the design 
> should
> be worked out in collaboration with the TeX community at large, and its
> possible drawbacks should be analyzed.)

Being myself an ex-TeXtures user and loking at some of my cooleagues 
still using TeXTures,
I share your opinion.

But the situation is really different here:
1- we can see from the Finder what is inside a bundle
2- the bundle can be turned into a normal directory

Newbies will use TeX bundles as is, then with more experience, they 
will take a look at the insides,
and for advanced use they will let down the bundle.
Moreover, the frontend can be smart enough to let the user easily 
switch between folder and bundle
some checkbox "TeX wrapper is a Mac OS X bundle" versus "TeX wrapper is 
a normal directory"

> 3) I like the idea very much that every file should start with a short
> header describing what the file is and how it should be read.  This is 
> just
> common sense, and probably you all write a few comments for yourself, 
> and
> ps files, mail files, and xml files do this.  Clearly it should be 
> possible
> to agree on a good format suitable for both human readers and TeX
> frontends.  If emacs writes such metadata at the *end* of the file it 
> is
> probably an indication that this is meant only for machine readers (and
> probably only for emacs).  A human reader will not find any 
> convenience in
> reading at the end of the file, it should be at the start.  I don't 
> like
> the idea of having this data in a separate file --- you should be able 
> to
> open any file and immediately see what it is about; this would not be
> possible if the meta-data is stored away in a separate file.  Hence I 
> will
> defend that the correct place for these small bits of metadata 
> (encoding,
> docroot, etc) is in the text file itself, and at the top.

emacs is using TeX comments at the top of any text file to define the 
encoding but a limited set of such encodings are used.
AUCTeX is using TeX comments at the end of the TeX file for the master 
document and is using an external directory named in general auto/ 
where it stores private data.
TeXniCenter also uses an external file to store meta data, I don't know 
if TXC is encoding aware...

IMO, the only thing that really needs to live in the file itself is the 
If the master document info is pertinent, it means that you have at 
least 2 documents gathered in one folder because... then there is no 
problem in having one more external location where you store data.
I explained in one of my previous mails how the master document 
information can be in only one location, but not in any input file.

Moreover, the input files are not only text documents and may not be 

Suppose you are working on a TeX document including PDF images, you can 
open one of the pdf images using your integrate frontend.
The frontend will be smart enough to guess that this image is in fact 
part of a more general project and if you finally decide to edit your 
project everything will already be available in the frontend. How the 
frontend will be able to guess that this image file belongs to a 
project? Nothing will be available from the pdf contents, in fact the 
frontend will be able to find an external file where meta information 
is stored.

IMO, the encoding information is the only one that should be available 
from the TeX file itself.
It seems that this information is available as a universal standard 
only for UTF16 text files.
Wait for final TeXShop to have the exact syntax to declare the 
encoding, something like

%!TeX encoding = blah

except that the whole syntax must be carefully described.
This is the only thing that might eventually survive the TeX project 
design because it is not too much intrusive
and will not pollute the source more than necessary, whatever editor 
you are using (alpha, bbedit, vi, emacs...).
Moreover, there is an implementation trick for smart editors that hides 
this information from the user.

I understand the meta data problem as: Will I have to drag two files 
instead of on?
The answer could be: no longer drag individual files, just drag single 
The problem is now that most xfer tools only accept flat files and do 
not like directories at all.
I have not yet the answer to that, only some ideas like a contextual 
menu item in the finder that lets you "flaten" a TeX wrapper directory.

--------------------- 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