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

[Maarten Sneep]

To reduce the length of the mail, I removed some bits.

On 10 sep 2004, at 18:08, Jérôme Laurens wrote:

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

It might be more complicated than forward scanning, but I think it is 
possible. If all else fails: read the last 3000 bytes into memory and 
scan forward from that offset. It should be faster than scanning a 
whole file.

[snip]

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

Ok, that'll do for me. How far up would you go? Limit to four levels, 
or go all the way to the root? (make the last rule: "the project is 
always stored above its files, or at the same level in the file system 
hierarchy")

[snip]

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

If I understand things correctly: a 'wrapper', with one configuration 
file per "role" (editor, viewer, checker, ...) and the others can only 
read, but not write the files of the other roles.

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

Yes, but I can use the finder, of the terminal to manipulate the files 
in this pseudo-wrapper. A true wrapper (in the Cocoa sense) doesn't 
(easily) allow for intervention into the structure. The latter would be 
undesirable.

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

So the wrapper is not for organising the tex sources, but for 
organising the configuration. It would be nice if tex-generated 
temporary files could be redirected into this wrapper - except for the 
occasional .aux corruption after fiddling with babel.

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

I think it is a good idea to differentiate between two levels: a 
wrapper for configuration and things that _can_ be handled by a 
front-end, and a general directory structure. I still have some issues 
with CVS or other version control systems: applications should be 
designed with version control in mind (*ahem* KeyNote *ahem*).

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

Depends on the level: I want to be able to get to my sources: I 
wouldn't call a (normal) directory structure to organise tex sources a 
wrapper. Binding project related information in a central location is 
good, especially if the front-ends can agree on the standard.

And I still think that recording the character encoding in a file is a 
good idea, that way it can never be separated from the contents. And 
emacs seems to have set a precedent there.

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

I see what you mean: there are now two methods of locating a master 
file, adding a third would make things needlessly complicated. At that 
point it is up to the authors of TeXShop to find a way out, I don't 
think it should stop the rest of use from improving the situation. And 
the extra information, like "%SourceDoc ../master.tex" can be "just" 
superfluous, once you stop supporting the method. As for %&: it has to 
go, quickly, as it breaks the core utilities behind any front-end.

And breaking some backwards compatibility might be a good thing: if the 
design is not good (applescripts with #special variable#), it has to go 
at some point.

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

Yes, and no: the core non-gui routines should be standard, the others 
as much as possible.

> The "at least largely" is the problem. We should not have different 
> scripts for different apps.

Not all software will have the same set of features, a core set (like a 
TeX applescript suite) should be supplied, and there might be more (TeX 
viewer, TeX editor, BibTeX editor, ... essentially the roles identified 
above). I'd love to have a selection of tools I can mix & match to my 
liking. I prefer BBEdit for writing, but it doesn't have a viewer: a 
standardised set of applescript commands could resolve part of the 
issue.

Functionality that is found in all applications should have the same 
applescript syntax: a viewer should have methods for asking the current 
page, magnification, location of the page relative to the window, ... 
and methods of advancing a page, going to a specific location, ... This 
can be common for all viewers. But a developer should have some freedom 
as well: what if someone creates a viewer that van display in white on 
black, for vision impaired people. This functionality should be 
accessible from applescript, and any script that uses it is then tied 
to that viewer.

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

Don't forget to breathe in the meantime: I still have to finish my 
summary (of my thesis, the date for the defence has been set...).

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>