Re: [toolbox] Extended Attributes

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

On 6 Jul 2005, at 8:38, J=E9r=F4me Laurens wrote:

> Le 5 juil. 05, =E0 22:39, Maarten Sneep a =E9crit :
>
>> Why would you want to change the name of the master file? I don't =20
>> get the example you give here - since the slave-files are stored =20
>> in the master file, and their relative location is fixed through =20
>> the \input statement (or format specific alternatives). So =20
>> _moving_ the master is not an option, and renaming (IMHO) is a =20
>> relatively rare action. Inefficiency is unimportant for such cases.
>>
>
> Gerben just gave me an example where he splitted a big book in =20
> several chapters, each one could be typeset separately.
> Changing the master name allows this. If each chapter consists of =20
> one file, you just change the master file name in the header, but =20
> if it consists of many different files, then this is not practical.

Call me thick-headed, but I don't see how this works. Care to share a =20=

minimal example?

> Assuming that master files are property identified (with the name, =20
> \documentclass, inline comment), slave files are the ones below.

I can understand the master -> slave direction, after all TeX needs =20
that information to typeset the file. However, if I open a random =20
slave file, how is a front-end going to find the master? Or am I =20
misreading this statement, and do you mean that the slave-file should =20=

contain some information on its master (the documentclass, the master =20=

file, ...).

> In the TeX Wrapper Structure I presented in EuroTeX 2005, there are =20=

> dedicated room for frontend specific and user specific metadata.
> For frontend specific metadata, it's just a naming convention to =20
> avoid collisions, such that quite nothing needs to be changed for =20
> actual editors.

OK, that would work, although you might need a machine or screen-size =20=

dependent category to prevent the window-size clashes I mentioned.

>> With the marks I agree, with the collapsing region bounds, I'm not =20=

>> too sure: they may be a personal preference, not shared between =20
>> collaborators. This information can be stored outside the source =20
>> file (in some project file, which can contain the lot in a TeX =20
>> wrapper - however they may look*).
>
> marks are also personnal, they can just be used as stickies.

But the marks can also serve as pointers to co-editors, to point them =20=

to changes you've made, or important remaining issues. I think most =20
users who share their file will want the markers to be shared (I know =20=

I do). However, with collapsing sections, I'm not so sure.

>> The description of where the different points are inserted - if =20
>> _all_ metadata is expelled from the source files to some external =20
>> storage - may very well need to change, from a line-count to a =20
>> node count.
>>
>
> Exactly, different locations for the metadata serve different =20
> purposes and we definitely need both.

And sometimes as a back-up of the other, possibly less robust =20
location. I still need to do some testing on CVS maintained files as =20
a target for aliases, extended attributes on files, and some more =20
robustness checks.

>> loc   description
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 1,2   text encoding   (extended attribute, in-file, project file)
>> 1     markers         (in file - easiest, most robust)
>> 3     window location (private use only)
>> 1,2   master file     (extended attribute, in-file, project file)
>> . . .
>>
>
> Agreed except for 3.

but still preferred in a location that is not shared between users or =20=

even machines: the 12", 30" mismatch was mentioned before.

> All these are recommandations, and the frontends will do what they =20
> prefer.
> But my opinion is the following:
> If a frontend wants to implement something, he can do whatever he =20
> wants, but there might be dedicated locations for that.
> Every metadata can be stored in either 1, 2 and 3.
>
> For the window location, we can state that:
> if the front end wants to store it in its private domain, he can do =20=

> whatever he wants.
> If the front end wants to store it near the file it refers to, then =20=

> there is some place already reserved for this, and it should use it.
> The frontend is not encouradge to embed this kind of information in =20=

> the file.

That is for sure, in my opinion, there are only a few items critical =20
enough to warrant storage inside the file as an emergency backup: the =20=

character encoding and the master file. I think that the markers =20
belong inside the file - it feels very natural to me - and they can =20
then be used easily with other editors that support regular =20
expressions for markers (BBEdit, perhaps others).

Is anyone prepared to create a summary of this thread to later =20
reference?

Maarten=