[OS X TeX] TeXShop's %& ugly bug

[Maarten Sneep]

Hi,

I've been away for a meeting, so this one contains a lot of replies all 
at once.

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
>
> %-*-coding=blah-*-

 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 
auctex's variables.

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

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

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 
widespread useage.

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

Maarten

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