Re: [toolbox] Extended Attributes

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

(Use the archives to read the parts snipped from this message, a.k.a. =20=

massive snipping ahead)

On 1 Jul 2005, at 16:48, J=E9r=F4me Laurens wrote:

> Le 28 juin 05, =E0 22:14, Maarten Sneep a =E9crit :
>
>> Text encoding is a mess, that is true. The correct encoding is =20
>> placed in the master file (\usepackage[latin1]{inputenc} is pretty =20=

>> clear). Since this indicator has to appear before the use of =20
>> special characters, you can parse the file up to that point as if =20
>> it is just 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.

Yes, context requires its own indicator, and plain should have gotten =20=

its indicator once 8-bit was added. The fact that emacs uses its own =20
markers is something that could be used to our advantage, or just =20
ignored. I think that the fact that a human readable indicator of the =20=

encoding is present is good - it is robust, and independent of the =20
platform used to create the file.

>> 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 =20
> the master(s) from the slave

I think it is possible to detect that a file is not a master. One =20
could assume that the master then lives either in the same directory, =20=

or at most one or two levels up from there. Search those locations =20
for all TeX files - filter to select the same engine (plain, latex, =20
context) - and find the file that includes the present file. I didn't =20=

say it would be easy or fast.

>> I'm not sure about that - and most of those items are stored in =20
>> the application preferences (window positions, see the way BBEdit =20
>> does this).
>
> I doubt they do it in a robust/frendly way.

To be honest, I hardly noticed that they changed their ways - except =20
that the document state was preserved after a CVS update.

> What about files being moved in your local HD.
     seems to work correctly.
> What about files being moved from Office to Work?
     Mostly OK (but I used cvs, which may be considered cheating)
> What about this prefs being corrupted and trashed?
     BareBones uses a separate file to store this information. By the =20=

way, I asked BareBones about using extended attributes to store the =20
input encoding. For reference I've forwarded the reply to this list.

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

But for robustness reasons, neither may the resource fork proove to =20
be. Perfect solutions do not exsits, and our best bet may be a =20
combination of storage locations.

>> I can see your point, but if a file with externally managed =20
>> markers is altered with a different application, you loose track =20
>> of the markers. I think this is more annoying than having meta-=20
>> comments, especially the unobtrusive ones like =91%:=92 for marker =20=

>> (like TeXShop). Now, the idea of this list is to coordinate such =20
>> developments, but there will always be editors that don't play by =20
>> these rules (vi, emacs, BBEdit come to mind, and others may take a =20=

>> while, like Alpha, or even editors on other platforms). %: as a =20
>> marker is easily implemented in other editors like BBEdit, =20
>> 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:

(I think it was a "pragmatic solution" to a problem the standards =20
committee couldn't quite resolve.)

> %! pragma ...
>
> for any "texnical" inline comment
>
> something like
>
> %! pragma mark My Mark Comment Here

A bit verbose maybe, but otherwise OK. I think the =91%!=92 implies =20
=91pragma=92 so =91%! keyword=92 would be sufficient.

> But is it strong enough for dtx files?

dtx files are specific to LaTeX, so part of the information could be =20
extracted from the file itself, especially since the format of the =20
source is even more tightly defined than of regular latex sources. =20
That said, the comment could be hidden with an
\iffalse
%! pragma mark My Mark Comment Here
\fi
construct (with appropriate %-marks thrown in).

> 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

I don't think that this is a particularly good example of information =20=

to store in the source. I mean, marks are local to the text, text =20
encoding is local to the file, but collapsing sections really belong =20
at the project level, I think they are too dynamic to be stored =20
within the text. Unless you'd like to hide the pragmas completely, =20
but that is a step I'm not willing to take lightly.

Maarten=