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

[Jérôme Laurens]

Le 10 sept. 04, à 15:07, Maarten Sneep a écrit :

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

I was convinced that parsing a file from its beginning was much faster 
than parsing from the end...
I might be wrong.

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

No, you are making a choice by saying that this info needs to be in 
every file.
 From the programmer POV, leaving this info in the source is more 
comfortable.
 From the user POV, hiding all ancillary info is much more comfortable.
A good front end will implement both.

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

I agree that emacs solution exists and should be supported, but users 
should not be asked to adopt this "ugly" syntax if this can be avoided. 
Moreover, as emacs syntax is actually not sufficient, and not safely 
expandable, a new solution might be interesting. As external files 
might be used, why not putting this info in external files too.

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

Except if you accept some rules:
- the master information is in the project
- the project knows what files it manages
- the project is always stored above its files in the file system 
hierarchy

Given a file, you just look for the projects just above and keep those 
which know the file, that's all.

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

Except that applications will have to parse 3rd party stuff.
But, this is not a big problem regarding confidentiality.
The big problem is that different applications must be able to 
edit/view this file at the same time (editor, viewer, spell 
checker...).
So they must be aware of "external editing" and implement this feature.
Moreover, this allows corruption and does not separate data.

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

Very simple description
A TeX wrapper is just a folder containing everything for the document, 
except standard macros maybe.
Name it foo.texd for example (texd for tex directory).
The contents must agree to only two rule:
1- *.texp names are reserved for the project names.
2- *.texp files can be removed without breaking the document.

So each time you gather all your files in one folder, this is a basic 
TeX wrapper
I bet you already use such design.

Then, the meta data is stored in some *.texp folder (texp for tex 
project)
Inside this folder, you find a main property list containing the 
encoding and master info, along with other folders or files containing 
frontend private data. The project must be more general than a simple 
.texshop file or property list.

In fact the wrapper is not the central point, the project design is as 
you pointed out above.

What problem will it solve? all the above mentioned.

Will it make life easier? for some of us definitely yes.
Does it break the current TeX environment, whatever OS is running?
Certainly not. The only disagreement are the added *.texp folders.

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

Just because choices are made in a direction that closes further 
enhancements, and then backwards compatibility becomes a real problem.

>
>> 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 missed something, the TeX applescript suite syntax IS the user 
interface to the TeX applescript suite, may be you are thinking of the 
GUI?
The "at least largely" is the problem. We should not have different 
scripts for different apps.

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

Waiting for your ideas.

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