Re: [toolbox] Extended Attributes

[<jer...@u-...>]

Le 27 juin 05, =E0 22:06, Maarten Sneep a =E9crit :

> On 27 Jun 2005, at 16:21, J=E9r=F4me Laurens wrote:
>
>> Le 24 juin 05, =E0 22:56, Maxwell, Adam R a =E9crit :
>>
>>> I've tried setting xattrs and moving a text file onto an NFS volume;=20=

>>> the attributes were preserved when moving them back and forth, which=20=

>>> is good.  However, opening and saving the file in TextEdit lost the=20=

>>> attributes, which is unfortunate.
>>>
>>
>> Indeed.
>>
>> I guess mail will not send this xattrs too...
>
> or an ftp transfer, or http for that matter. I'm not sure about=20
> sftp/scp though, they might support xattrs. But I guess there are a=20
> thousand ways to loose your metadata (cue music here).
>
>> I think the best policy is to never rely on such attributes.
>
> I wouldn't put it that way: when present, they can be trusted, when=20
> not available they must be reconstructed somehow.

They can be trusted as long as the end user keeps the control in its=20
hands.
The most critical part concerns the text encoding because it can=20
definitely break the source.

>
>> Also, for extended file attributes, the best way seems to consider at=20=

>> the same time xattrs, resource fork and external location when=20
>> possible.
>
> I assume with external location you means something like a project=20
> file or a wrapper. Warning: attempt to get you to write an article=20
> ahead: Could you create some overview of what your idea of a TeX=20
> wrapper is (and maybe more importantly: what it isn't. I think this=20
> article should address the context in which wrappers will be used (in=20=

> your vision)).

Give me one more hour a day and I can do it...

>
>> That way, we hardly break the whole metadata design when moving files=20=

>> around, and can retrieve at least partly the metadata.
>
> I'm going to make a bold statement here: all the metadata is already=20=

> in the TeX sources, and can be reconstructed from there. (why are we=20=

> getting so excited about it then ;)
>

Except the language used and list of known words, window size and=20
position, selected text ranges, magnification, page displayed, page=20
diplay mode and so on.
In short, everything that makes the difference between a tool and a=20
good tool;-)

> - The encoding is indicated in the master file=20
> \usepackage[latin1]{inputenc} is fairly unambiguous, and Context has=20=

> similar statements.
> - The master file can be found by searching through a directory tree=20=

> (including looking 'up' the tree), again this works for both LaTeX,=20
> TeX and Context. It may be relatively slow, and I know of cases where=20=

> it fails (where a file could be processed stand-alone, or included, or=20=

> documents that can be included in more than a single master. The=20
> current metadata approaches will not handle those cases either).
> - One can try to determine the engine by looking at the command=20
> sequences: \begin{figure} is indicative of LaTeX, \startfigure hints=20=

> at context (though its multiple input language support makes things a=20=

> bit harder).
>
> OK, doing away with metadata is not a good idea, but not all is lost=20=

> if they become separated. At the moment I'm still in favour of using=20=

> comments to indicate some key elements (character encoding, an=20
> indication of the master file, the core engine, and then some) or a=20
> property-list file to hold that info (the latter may become out of=20
> sync, so that is an issue). For things like navigation markers, I=20
> strongly prefer the in-source option, because it allows me to put a=20
> marker in very quickly.

I am strongly against using TeX comments for that purpose, despite I=20
did it myself for iTM.
Except if they conform to an official, clear, publicly available=20
specification, and eventually become part of the language.
Before implementing the inline navigation markers in iTM, I asked the=20
Mac OS X TeX list about the syntax, in order not to be preemptive. The=20=

only answer I got came from Gerben, who preferred to use identifiers=20
dedicated to applications. So I implemented something clearly targeted=20=

to iTM. If you add scientific words, emacs, auctex, TeXShop and others,=20=

your source will contain a lot of useless things...
Moreover, TeX is already complicated, such that adding new rules should=20=

require great care.

What you prefer is to put a marker in very quickly (so do I) but this=20
has nothing to do with inline commenting or not. This has to do with=20
the user interface provided by your text editor. You are confusing the=20=

user interface and the underlying data model.
It is very easy to write down a text editor that makes you believe that=20=

marks are just inline comments, whereas they are in fact stored outside=20=

the text stream. On the other hand, it is also very easy to write a=20
text editor that hides those inline comments in the displayed text=20
stream an replace them by a small icon in the left margin (like xcode=20
stop markers). These are just hints to let you imagine how can be an=20
efficient user interface.
What you need is typing the mark name, add one or two keystrokes as=20
shortcut, then clearly identify the position of the mark in the window.=20=

Do you really need to see the mark name exactly where it stands? No,=20
you only need to see it in the mark menu. So the user interface does=20
not really have to expose the mark name, something like a tooltip is=20
sufficient.
Finally, if you use inline comments for that purpose, adding or=20
removing a mark takes place in the text undo stack. Some people might=20
feel uncomfortable with that.

So, here might be the subject of the second mac tex toolbox texnical=20
note: official inline comments.