[OS X TeX] TeXShop's %& ugly bug
maarten.sneep at xs4all.nl
Fri Sep 10 09:07:49 EDT 2004
I've been away for a meeting, so this one contains a lot of replies all
On 10 sep 2004, at 13:08, Jérôme Laurens wrote:
> Le 10 sept. 04, à 12:43, Will Robertson a écrit :
>> From the AUCTeX documentation (v11.50, which I haven't even worked
>> out how to install yet), it looks something like this at the end of a
>> file: (couldn't find an example for the character encoding)
> The character encoding is given in the first line of the file and does
> not seem related to AUCTeX
From Patrick Gundlach's message, I think this is a different set of
emacs variables. I think this is a more generic mechanism than just
> It is a list of semicolon separated instructions.
>> %%% Local Variables:
>> %%% TeX-master: "master"
>> %%% TeX-command-default: "SliTeX"
>> %%% End:
>> It's ugly enough that I'd be happy just re-implementing the %&
>> functionality to use a different prefix. I find the whole issue
>> fairly trivial, though.
> Hummmm, not that trivial I'm afraid...
"Key: value", I've seen less trivial designs.
> Moreover, very inefficient if you have to parse the whole file just to
> know the master one, or the command to perform.
Start parsing from the back: the specs say that it should be in the
last 3000 characters.
> This is not a good design if you want to separate the editor and the
> TeX frontend.
Setting some information (like the character encoding) in the file
itself, in a way that important frontends know about (*cough* emacs
*cough*), eases portability (of the tex sources) a great deal. There
are some commands that need to be in every tex file: the path to the
master file and the character encoding. The methods used by emacs for
this information can be implemented by other editors, at least that is
what I would prefer. And yes, cleaner solutions are possible: we're not
going to get emacs in another direction just like that.
> An external file would be significantly better. Why not defining
> something more general?
For other information, a property list would be better. This property
list still must be found relative to the open file, so either a pointer
(like an emacs variable, /me ducks), or the same base-name as the
master file, with a separate extension (.project or similar). Still for
any daughter files of the master, a link to the master must be made (I
suppose you wouldn't propose to create a configuration file for each
daughter file ;)
Notice that I don't speak of wrappers. This is intentional: tex is too
flexible to handle everythin inside a wrapper. Example: how would you
handle files under a versioning system (subversion, perforce, cvs), my
figures are in metapost, and require a hierarchy to work properly.
As to your later reply:
> IMHO, this is not a good idea because you are just making the first
> step towards reproducing the %& bug.
> All these Local Variables do have a meaning in emacs and auctex and
> you are suggesting to interfere with something private changing their
OK, good point. Let me rephrase: only use the variables that emacs
already defines, that is provide a way to identify a master file, and
to identify the source encoding (although the latter could be derived
from an \inputencoding statement in the master file). From the master
file a second configuration file can be found (through the same
base-name as the master file) which can contain whatever you want.
Different applications could use the same file: just add a dictionary
under the key edu.uoregon.math.koch.TeXShop or comp.text.tex.iTeXMac
with whatever keys in it: no more clashes there.
> You will have to be sure that emacs will not be affected by the new
> comments and ensure forward compatibility.
> A TeX wrapper would be a much much better alternative.
Can you define what you mean with a wrapper? maybe the problem is just
that I cannot visualise how it would work. A property list that defines
commands and such: OK, sort of a project file. If you manage to get a
next generation tex to put output files in a specific directory (and
look for those files there as well, without breaking standard latex
(i.e. be cross platform again): it might work. Putting the sources in
there: no thanks. Can you send me (off list) a sample or a mock-up of
what you have in mind, and a description of the problems it would
And now for your second mail:
> Just forget the tone, the contents remain.
Agreed, but you also have to get people to listen to what you say...
> The fact is that we once had a chance to make a very neat and
> efficient TeX environment on Mac Os X with
> - unique applescript syntax
> - unique TeX applescript suite
> - unique macros format storage
> - unique templates policy
> - unique TeX source meta data design
> - unique tex wrapper design
All but the last items would be very welcome. I have some grave
concerns about the wrapper, and I think it would cause a great number
of problems because tex is used in so many variants. It would also
happer document exchange is some way. Unless of course you would
propose to have a wrapper in which the files are represented by
symbolic links and everything is compiled there (to keep the mess in
one location). That might work, but a thorough cleaning script is
easier to maintain, and can be made cross platform: write it in perl or
python. This has two advantages: more developers and and more
> This seems more and more difficult as new TeXShop versions come out.
Not sure about that: at one point the TeXShop development process will
grind to a halt, as fixing one thing starts to break other things
quickly. That seems to be only a matter of time. Besides: if your/the
other design really is better, it should come out on top.
> Notice that all the previous things, but the applescript syntax, only
> deal with the data model such that the user interface is not concerned
> as is.
Properly designed, the TeX applescript suite syntax is interface
independent, and the applescript code can be independent as well, at
least largely: the viewer can conform to a set of standards, and thus
behave the same whether in one application or another.
> I do agree that many users won't have time to discuss about such
> things, but I was thinking that developers would feel naturally
I'd love to help, and maybe in the next few months I might actually be
able to do so. But discussion is certainly possible. BTW: I'm still
thinking about you next-gen tex question.
--------------------- 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