Re: [toolbox] Extended Attributes

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

Le 1 juil. 05, =E0 22:48, Maarten Sneep a =E9crit :

> (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 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.
>
> 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 the=20=

>> 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 for=20=

> 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 the=20=

>>> application preferences (window positions, see the way BBEdit does=20=

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

I am very surprised! How can BBEdit track changes in file names while=20
not being open.
Did they patch the system? I would not be surprised if they use in fact=20=

resource forks...

If they use an ex(ternal file of their own, you have to move this=20
separate file with your own one when moving things around... Not really=20=

elegant.
Can we make some basic reverse engineering on that file?

I heard that theGimp also used an external file to store the=20
information..

>
>> 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 don't really understand.
The question is that some meta information must be stick to a standard=20=

file, and the link should not be broken while moving things around.
The link is some information that must be stored somewhere in the file=20=

system, and should be managed by the file system.
If we are talking about information that we don't want to appear in the=20=

file itself,
The resource fork is the best solution for meta information that cannot


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

This was my first opinion, but the verbose version seems more=20
understandable for people who are not aware of this convention.
Moreover, google like search will be successful if there is a full=20
word, not if there is only non letter character controls.


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

???
You are really confusing me.
What is the difference between the bounds of collapsing regions and the=20=

location of the marks?
If one must be  local, so the other one.

> I think they are too dynamic to be stored within the text. Unless=20
> you'd like to hide the pragmas completely, but that is a step I'm not=20=

> willing to take lightly.

The same confusing between the data model and its user interface.
You are not only talking about marks, but you are talking also about=20
how you are using marks.
You put some %: somewhere and don't change it, so you are not using=20
these marks dynamically.
This is simply because the user interface for such marks is a big=20
machinery that discourage an intense use.
See the mark implementation in textedit for a dynamic use.
But in fact, the mark location changes dynamically as soon as you=20
modify the text before...

For collapsing regions, you are also talking about their use.

So you are comparing the data models based on your experience of=20
corresponding user interfaces.
For marks, you chose a heavy and inefficient user interface whereas for=20=

collapsing regions you chose a light efficient one.
It is not really fair...
Textures user interface for marks is a lightweight example.