Re: [toolbox] Extended Attributes

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

Le 28 juin 05, =E0 22:14, Maarten Sneep a =E9crit :

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

Except that this is limited to LaTeX.
ConTeXt has its own.
emacs uses another inline hint of its own too.
Plain has nothing.

> The problem really starts for included files.
>
Yes, this assumes you already know the master file, so you must=20
indicate the master file in each input slave files...
Or at least there must be some kind of hinting to easily retrive the=20
master(s) from the slave


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

I doubt they do it in a robust/frendly way.
What about files being moved in your local HD.
What about files being moved from Office to Work?
What about this prefs being corrupted and trashed?

The user defaults database coming from OS X does not replace the=20
resource fork.

>
>>> 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.
>
> I can see your point, but if a file with externally managed markers is=20=

> altered with a different application, you loose track of the markers.=20=

> I think this is more annoying than having meta-comments, especially=20
> the unobtrusive ones like =91%:=92 for marker (like TeXShop). Now, the=20=

> idea of this list is to coordinate such developments, but there will=20=

> always be editors that don't play by these rules (vi, emacs, BBEdit=20
> come to mind, and others may take a while, like Alpha, or even editors=20=

> on other platforms). %: as a marker is easily implemented in other=20
> editors like BBEdit, external markers are a nightmare in this respect.

in C there is an official "#pragma mark" for that purpose.

I don't get the meaning of "pragma" but let me suggest something like:

%! pragma ...

for any "texnical" inline comment

something like

%! pragma mark My Mark Comment Here

But is it strong enough for dtx files?

Other inline comments could be used to collapse/expand sections or=20
parts of the source. In that case things are perverse...

%! pragma begin collapse

%! pragma end collapse

>
> Other meta-information is probably easier to handle with an external=20=

> file, because the info changes less frequently, or is easier to derive=20=

> from the source (file-inclusion is an example).
>