Re: [toolbox] Extended Attributes

[Maarten S. <maa...@xs...>]

Hi J=E9r=F4me,

I've snipped some text to limit the length of this message.

On 28 Jun 2005, at 8:56, J=E9r=F4me Laurens wrote:

> Le 27 juin 05, =E0 22:06, Maarten Sneep a =E9crit :
>
>> On 27 Jun 2005, at 16:21, J=E9r=F4me Laurens wrote:
>>
>>> 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, =20
>> when not available they must be reconstructed somehow.
>
> They can be trusted as long as the end user keeps the control in =20
> its hands.
> The most critical part concerns the text encoding because it can =20
> definitely break the source.

Text encoding is a mess, that is true. The correct encoding is placed =20=

in the master file (\usepackage[latin1]{inputenc} is pretty clear). =20
Since this indicator has to appear before the use of special =20
characters, you can parse the file up to that point as if it is just =20
ASCII, and switch once found.

The problem really starts for included files.

>>> Also, for extended file attributes, the best way seems to =20
>>> consider at the same time xattrs, resource fork and external =20
>>> location when 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 =20
>> this article should address the context in which wrappers will be =20
>> used (in your vision)).
>
> Give me one more hour a day and I can do it...

Sorry, no spares here...

>>> That way, we hardly break the whole metadata design when moving =20
>>> files around, and can retrieve at least partly the metadata.
>>
>> I'm going to make a bold statement here: all the metadata is =20
>> already in the TeX sources, and can be reconstructed from there. =20
>> (why are we 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;-)

I'm not sure about that - and most of those items are stored in the =20
application preferences (window positions, see the way BBEdit does =20
this).

>> OK, doing away with metadata is not a good idea, but not all is =20
>> lost if they become separated. At the moment I'm still in favour =20
>> of using comments to indicate some key elements (character =20
>> encoding, an indication of the master file, the core engine, and =20
>> then some) or a property-list file to hold that info (the latter =20
>> may become out of sync, so that is an issue). For things like =20
>> navigation markers, I strongly prefer the in-source option, =20
>> because it allows me to put a marker in very quickly.
>
> I am strongly against using TeX comments for that purpose, despite =20
> I did it myself for iTM.
> Except if they conform to an official, clear, publicly available =20
> specification, and eventually become part of the language.

I can see your point, but if a file with externally managed markers =20
is altered with a different application, you loose track of the =20
markers. I think this is more annoying than having meta-comments, =20
especially the unobtrusive ones like =91%:=92 for marker (like TeXShop). =
=20
Now, the idea of this list is to coordinate such developments, but =20
there will always be editors that don't play by these rules (vi, =20
emacs, BBEdit come to mind, and others may take a while, like Alpha, =20
or even editors on other platforms). %: as a marker is easily =20
implemented in other editors like BBEdit, external markers are a =20
nightmare in this respect.

Other meta-information is probably easier to handle with an external =20
file, because the info changes less frequently, or is easier to =20
derive from the source (file-inclusion is an example).

> Before implementing the inline navigation markers in iTM, I asked =20
> the Mac OS X TeX list about the syntax, in order not to be =20
> preemptive. The only answer I got came from Gerben, who preferred =20
> to use identifiers dedicated to applications. So I implemented =20
> something clearly targeted to iTM. If you add scientific words, =20
> emacs, auctex, TeXShop and others, your source will contain a lot =20
> of useless things...
> Moreover, TeX is already complicated, such that adding new rules =20
> should require great care.

Yes, and the %& issue is a clear indicator of the care needed.

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

No, I'm not (or at least I'd like to think so): I like to add =20
robustness against external modification. My next article will =20
probably be written on a combination of computers running Linux =20
(Kile) and Mac OS X. Appropos Kile: its interface contains some very =20
good ideas.

> 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 =20
> window. Do you really need to see the mark name exactly where it =20
> stands? No, you only need to see it in the mark menu. So the user =20
> interface does not really have to expose the mark name, something =20
> like a tooltip is sufficient.

Putting the marker in the text doesn't exclude this either (think =20
folding text to collapse sections).

> Finally, if you use inline comments for that purpose, adding or =20
> removing a mark takes place in the text undo stack. Some people =20
> might feel uncomfortable with that.

That is true, and there is no easy solution.

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

I assume the first one was MTT? I'll put it between the articles later.

Maarten=