mactextoolbox-talk — Discussion for Macintosh developers for TeX Tools

Re: [toolbox] LaTeXiT 1.2 beta

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

On 3 Jul 2005, at 14:24, Pierre Chatelier wrote:

[massive snip]

> Ok, that makes sense. What about $ for inline mode ? Is there  
> another, better shortcut ? By the way, during the latexisation, I  
> do not even use \[ but $\displaystyle. Is it a potential problem ?

inline maths with single $'s is supported in LaTeX.

Maarten

Re: [toolbox] LaTeXiT 1.2 beta

[Pierre C. <pie...@cl...>]

>>> - Since we're talking LaTeX, it would be better to write
>>>    Display (\[...\])
>>>   because $$...$$ is, to be strict, incorrect.
>>>
>> I guess this is a debatable problem. I did never use \[...\]  
>> myself, since I find $$ more handy. But I am certainly not a LaTeX  
>> expert. What does the majority of people expect here (this is a  
>> question for the mailing list) ?
>>
>
> To quote Lamport on this (L. Lamport, "LaTeX, a document  
> preparation system (LaTeX2e edition), page 233): "Plain TeX's $$  
> does not work properly; it has been replaced by the LaTeX commands \ 
> [ and \]."
>
> In short, $$ should not be used with LaTeX.
Ok, that makes sense. What about $ for inline mode ? Is there  
another, better shortcut ? By the way, during the latexisation, I do  
not even use \[ but $\displaystyle. Is it a potential problem ?

>>>   But I think users tend to know enough of what's going on to be  
>>> able to write   | Display | Inline | Text | in those buttons and  
>>> put \[...\] , etc., in a tooltip.
>> Here I disagree a little. For people not familiar with LaTeX's  
>> vocabulary, the use of the button becomes obvious. Here again,  
>> what do people think about that ?
> People not familiar with LaTeX's vocabulary will have some trouble  
> using LaTeXiT anyway. I think the descriptive names (which can be  
> localized) on the buttons are better, with the command displayed in  
> the tooltip as a backup.
Finally, it's fair to say that it would be, visually, less heavy.

Regards,

Pierre

Re: [toolbox] LaTeXiT 1.2 beta

[Herbert S. <he...@wi...>]

On Jul 3, 2005, at 5:00 AM, Pierre Chatelier wrote:

>
>>  - The cropping seems slightly over-enthusiastic. But not as bad  
>> as TeX itself! For example:
>> \documentclass{article}
>> \begin{document}
>> \parindent=0pt
>> \voffset=-1in
>> \hoffset=-1in
>> \setbox0=\hbox{$1=3$}
>> \dimen0=\ht0
>> \advance\dimen0\dp0
>> \pdfpageheight=\dimen0
>> \pdfpagewidth=\wd0
>> \shipout\box0
>> \end{document}
>> % (Stolen ages ago from Maarten, perhaps)
> You are cheating, using Maarten's pathological latex source ( ;-)  
> no offense!)
> I have an immediate solution, that concerns Herbert's remark too :  
> I could add a control to add some margin to the default bounding  
> box. If you need great precision, it would be a textfield. On the  
> contrary, it would be a slider. But it would need a re-latexisation  
> (nice word). Any thoughts ?
>
>>

Howdy,

A slider would be fine but there might be a display/entry box for the  
``extra boundary space'' in pt too so one could be more precise.

OT: have other folks on this list who use Tigerrrr had files that  
were left in /tmp/UID/ (actually /private/tmp/UID/) moved to UID's  
Trash on boot? This seemed to start happening on my system recently  
under 10.4.1. I use Macaroni so it may have something to do with how  
Macaroni is handling the daily cleanup.

Good Luck,

Herb Schulz
(he...@wi...)

Re: [toolbox] LaTeXiT 1.2 beta

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

On 3 Jul 2005, at 12:00, Pierre Chatelier wrote:

>> - Since we're talking LaTeX, it would be better to write
>>    Display (\[...\])
>>   because $$...$$ is, to be strict, incorrect.
> I guess this is a debatable problem. I did never use \[...\]  
> myself, since I find $$ more handy. But I am certainly not a LaTeX  
> expert. What does the majority of people expect here (this is a  
> question for the mailing list) ?

To quote Lamport on this (L. Lamport, "LaTeX, a document preparation  
system (LaTeX2e edition), page 233): "Plain TeX's $$ does not work  
properly; it has been replaced by the LaTeX commands \[ and \]."

In short, $$ should not be used with LaTeX.

>>   But I think users tend to know enough of what's going on to be  
>> able to write   | Display | Inline | Text | in those buttons and  
>> put \[...\] , etc., in a tooltip.
> Here I disagree a little. For people not familiar with LaTeX's  
> vocabulary, the use of the button becomes obvious. Here again, what  
> do people think about that ?

People not familiar with LaTeX's vocabulary will have some trouble  
using LaTeXiT anyway. I think the descriptive names (which can be  
localized) on the buttons are better, with the command displayed in  
the tooltip as a backup.

Maarten

Re: [toolbox] LaTeXiT 1.2 beta

[Pierre C. <pie...@cl...>]

Hello,

Woh, much feedback there ! I really enjoy getting your opinion.

> [in the error manager] so if it could be reliably determine what  
> the offending token is it would be nice to see that as well.
For now, I would prefer not to. I prefer to be less precise, but  
ensure that the error-line is ok, rather than trying to deduce the  
faulty token, with the risk of getting wrong and give a bad  
indication. However, since LaTeXiT is open source and will be a  
toolbox project, if anybody has the knowledge to improve that, this  
will be no problem I think. Do you agree with this opinion ?

>  - I think I like the use of those things that look like tabs but  
> are actually buttons. The old school way would be to use radio  
> buttons, but I'm undecided if these things are actually better than  
> radio buttons.
This thing is called a "segmented control"; it was already available  
with Panther, but with Tiger, it is directly usable from  
InterfaceBuilder. At the very beginning of LaTeXiT, I was using radio  
buttons, because I did not know the existence of segmented controls.  
A friend of mine told me about that, I and find that in this context,  
it is much more beautiful.

> - Since we're talking LaTeX, it would be better to write
>    Display (\[...\])
>   because $$...$$ is, to be strict, incorrect.
I guess this is a debatable problem. I did never use \[...\] myself,  
since I find $$ more handy. But I am certainly not a LaTeX expert.  
What does the majority of people expect here (this is a question for  
the mailing list) ?

>   But I think users tend to know enough of what's going on to be  
> able to write   | Display | Inline | Text |
>   in those buttons and put \[...\] , etc., in a tooltip.
Here I disagree a little. For people not familiar with LaTeX's  
vocabulary, the use of the button becomes obvious. Here again, what  
do people think about that ?

> - For a future version, it'd be good to add a toolbar for the LaTexise
A toolbar ? For what purpose ?

> (don't suppose we've got enough of an anti-American majority to get  
> rid of the "z"? Can this be localised?)
Oh, do you mean that the "z" is a mistake (regardless of the fact  
that the word does no exist) ? English is not my mother language, so  
I did not pay great attention to this. It really does not distrub me  
to put an "s" instead.

> button as well as a button for the drawer, etc.
Do you mean, to open/close the drawers ? Oh, I understand, now :  
putting this buttons in the toolbar. Mmmh, it seems to me that my  
toolbar would be very "poor" (only two button), so it would not be  
very nice.

>  - I'm not sure if it's necessary to use \usepackage[applemac] 
> {inputenc}. For a start, I think [utf8] would be better for  
> forwards compatibility, and second -- since this thing will  
> *mostly* be used for maths, I think if people *do* want accented  
> characters then they can add this line to the preamble themselves.
Haha, you are forgetting french people like me; I do use accentuated  
characters, even in an equation label ! And [utf8] does not work,  
since the encoding of the input in the textfield is MacOS Roman.

>  - European decimal mark :) Can this be localised?
This should be... I will have a look.

>  - The cropping seems slightly over-enthusiastic. But not as bad as  
> TeX itself! For example:
> \documentclass{article}
> \begin{document}
> \parindent=0pt
> \voffset=-1in
> \hoffset=-1in
> \setbox0=\hbox{$1=3$}
> \dimen0=\ht0
> \advance\dimen0\dp0
> \pdfpageheight=\dimen0
> \pdfpagewidth=\wd0
> \shipout\box0
> \end{document}
> % (Stolen ages ago from Maarten, perhaps)
You are cheating, using Maarten's pathological latex source ( ;-) no  
offense!)
I have an immediate solution, that concerns Herbert's remark too : I  
could add a control to add some margin to the default bounding box.  
If you need great precision, it would be a textfield. On the  
contrary, it would be a slider. But it would need a re-latexisation  
(nice word). Any thoughts ?

> The preview package seems to give the same results as LaTeXiT:
>
> \documentclass{article}
> \usepackage[active,pdftex,textmath,tightpage]{preview}
> \begin{document}
> $1=3$
> \end{document}
> Is this actually what is used to generate the output? I couldn't  
> work it out from looking at the log file.
I do not use the preview package. If you want to get the generated  
files, you can look into /private/tmp/folders.[your uid]/Temporary Items
(this is under Tiger the result of NSTemporaryDirectory(). The files  
are put there.

> Great work!
Thanks, and especially to take time writing feedback


Regards

Pierre

Re: [toolbox] LaTeXiT 1.2 beta

[Herbert S. <he...@wi...>]

On Jul 2, 2005, at 6:57 PM, Pierre Chatelier wrote:

> Hello,
>
> The download URL is still : http://ktd.club.fr/programmation/ 
> fichiers/LaTeXiT-beta.dmg
> I have updated the program thanks to your proposals :
>
> Aaron : when dragging from the library, the equation label can be  
> dropped in text-only areas (without \ref{...} though}
> Herbert : preferences are updated, Command-T does work, and a zoom  
> has been added for the preview pane
>
> Feel free to add remarks, criticize the interface, and so on.
>
> Regards,
>
> Pierre
>

Howdy,

Thank you very much. This is lovely! Very usable.

The only thing left might be to add the ability to change the size of  
the Bounding Box boundary as a preference. That should take care of  
Will Robertson's concern too. Of course that change would hve to be  
reflected in the base line specs passed to a program so in-line  
equations have the correct baseline.

Is there anyone working on passing the proper baseline, via LinkBack,  
for word processor use?

Good Luck,

Herb Schulz
(he...@wi...)

Re: [toolbox] LaTeXiT 1.2 beta

[Will R. <wi...@gu...>]

On 3 Jul 2005, at 9:27 AM, Pierre Chatelier wrote:

> Aaron : when dragging from the library, the equation label can be  
> dropped in text-only areas (without \ref{...} though}
> Herbert : preferences are updated, Command-T does work, and a zoom  
> has been added for the preview pane
>
> Feel free to add remarks, criticize the interface, and so on.

This looks very promising!
First thoughts:

  - I LOVE the hidden-by-dragbar preamble. I'd like to see something  
like this in my actual LaTeX editor.

  - I also like to window re-use and ESPECIALLY the log file parsing  
that occurs when you make an error, although I suspect a little more  
information should be provided. For example, if I try and typeset "1  
\nq 2", it says "Undefined control sequence". The actual log file says

    ! Undefined control sequence.
    l.4 1 \nq
              2

so if it could be reliably determine what the offending token is it  
would be nice to see that as well. You could even go the easy way out  
and do the equivalent of (warning: pseudocode and shell script ahead!)

   if $error = "Undefined control sequence." then
     echo \\`echo "l.4 1 \nq" | sed s/.*\\\\\\\\//`
   fi

to find the offending command. (BTW, anyone know any easier way to  
isolate string elements on a line than my crappy sed technique?)

  - I think I like the use of those things that look like tabs but  
are actually buttons. The old school way would be to use radio  
buttons, but I'm undecided if these things are actually better than  
radio buttons.

- Since we're talking LaTeX, it would be better to write
    Display (\[...\])
   because $$...$$ is, to be strict, incorrect.
   But I think users tend to know enough of what's going on to be  
able to write
    | Display | Inline | Text |
   in those buttons and put \[...\] , etc., in a tooltip.

- For a future version, it'd be good to add a toolbar for the  
LaTeXise (don't suppose we've got enough of an anti-American majority  
to get rid of the "z"? Can this be localised?) button as well as a  
button for the drawer, etc.

  - I'm not sure if it's necessary to use \usepackage[applemac] 
{inputenc}. For a start, I think [utf8] would be better for forwards  
compatibility, and second -- since this thing will *mostly* be used  
for maths, I think if people *do* want accented characters then they  
can add this line to the preamble themselves.


Now a couple of small problems:

  - European decimal mark :) Can this be localised?

  - The cropping seems slightly over-enthusiastic. But not as bad as  
TeX itself! For example:

\documentclass{article}
\begin{document}
\parindent=0pt
\voffset=-1in
\hoffset=-1in
\setbox0=\hbox{$1=3$}
\dimen0=\ht0
\advance\dimen0\dp0
\pdfpageheight=\dimen0
\pdfpagewidth=\wd0
\shipout\box0
\end{document}
% (Stolen ages ago from Maarten, perhaps)

Cuts off heaps of the top of the numbers because their bounding boxes  
aren't equal to their vertical extremes. LaTeXiT produces similarly  
cropped results, and 5 minutes of tinkering didn't give me anything  
satisfactory.

The preview package seems to give the same results as LaTeXiT:

\documentclass{article}
\usepackage[active,pdftex,textmath,tightpage]{preview}
\begin{document}
$1=3$
\end{document}

Is this actually what is used to generate the output? I couldn't work  
it out from looking at the log file.

  - Probably some small adjustments could be made to the layout of  
some things (the zoom control, especially, seems too close to the  
border of the window), but I'll leave that for another time...

Great work!

Will

Re: [toolbox] Extended Attributes

[Will R. <wi...@gu...>]

On 3 Jul 2005, at 7:15 AM, Maarten Sneep wrote:
> And for metadata:
>
> % \iffalse
> %<*metadata>
> %! pragma mark My marker.
> %</metadata>
> % \fi
>
> Is this a workable suggestion? Since dtx files are processed at  
> different levels, I think you get more room to play with and add  
> your own stuff. On the other hand, Most dtx files are also pure  
> ASCII, so the encoding is less important, and sectioning is already  
> rather clearly indicated (making markers less of an issue).

Well, personally I think that
    %! pragma mark
is very ugly, but as a technique to mark dtx files I think you're  
right that it works well. (Note also that fontspec.dtx is a unicode  
document for example.)

A mark that might be useful for editing DTX files might be
    %! TODO:
I don't think there's any point in surrounding the metadata with
   %<*metadata>
tags unless that information needs to be extracted from the dtx at  
some stage. And I can't really see why that would be...

(On a previous note:)

I honestly have no problem, for now, with implementing metadata in  
the same way as emacs: in a big comment block at the very end of the  
document. It would be easy to hide from the user, and is very portable.

On the other hand, if there are other standards that spring up for  
storing the encoding of the file in an extended attribute -- well, we  
may as well use that as well! (too many `well's)

I am more interested with the possibilities raised from a rich  
document interface, and I think WHERE the metadata is stored is less  
of an issue -- it can always be changed if a new method turns out to  
be better.

Re: [toolbox] LaTeXiT 1.2 beta

[Pierre C. <pie...@cl...>]

Hello,

The download URL is still : http://ktd.club.fr/programmation/fichiers/ 
LaTeXiT-beta.dmg
I have updated the program thanks to your proposals :

Aaron : when dragging from the library, the equation label can be  
dropped in text-only areas (without \ref{...} though}
Herbert : preferences are updated, Command-T does work, and a zoom  
has been added for the preview pane

Feel free to add remarks, criticize the interface, and so on.

Regards,

Pierre

Re: [toolbox] Extended Attributes

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

Sorry to jump back so far, but I had another look at the dtx files, =20
and it seems rather easy. To remind you what I'm responding to:

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

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

Yes, I think it is in a slightly different shape. dtx files can =20
contain code for may different output files. Here's something I =20
prepared earlier. It sets up the dtx for printing (in the driver =20
section), and adds the version to the output style-file (in the =20
package section). Note that this is all kept out of the printed file =20
with the \iffalse ... \fi grouping. A section metadata could be added =20=

without harm, either printed or hidden.

First the example:

% \iffalse
%
%<*driver>
\ProvidesFile{xmpincl.dtx}
%</driver>
%<package>\NeedsTeXFormat{LaTeX2e}[1999/12/01]
%<package>\ProvidesPackage{xmpincl}
%<*package>
     [2005/02/15 v2.1 Include XMP data in pdflatex]
%</package>
%
%<*driver>
\documentclass{ltxdoc}
\usepackage{hyperref}
\usepackage{url}
\usepackage{xmpincl}
\hypersetup{colorlinks=3Dtrue, pdftitle=3D{Including XMP in pdflatex},
    pdfauthor=3D{Maarten Sneep <sn...@na...>},
    pdfsubject=3D{pdflatex and XMP inclusions.}, pdfkeywords=3D{XMP, =20
Creative Commons},
    pdfview=3D{FitH}, pdfstartview=3D{FitH}, pdfstartpage=3D{1}, =20
plainpages=3Dfalse}
\includexmp{license}
\DisableCrossrefs
%\CodelineIndex
%\RecordChanges
%\OnlyDescription
\begin{document}
   \DocInput{xmpincl.dtx}
\end{document}
%</driver>
% \fi

And for metadata:

% \iffalse
%<*metadata>
%! pragma mark My marker.
%</metadata>
% \fi

Is this a workable suggestion? Since dtx files are processed at =20
different levels, I think you get more room to play with and add your =20=

own stuff. On the other hand, Most dtx files are also pure ASCII, so =20
the encoding is less important, and sectioning is already rather =20
clearly indicated (making markers less of an issue).

Maarten

Re: [toolbox] Extended Attributes

[Jon G. <jg...@hi...>]

On Jul 2, 2005, at 1:26 PM, Maarten Sneep wrote:

> I had to read this twice: at first I thought you said that BBEdit 
> stored all files in its preferences, which would be silly :p

Actually, I think that's what I said... which *is* silly. Yes, I meant 
I think they store the file *state* someplace in prefs or app support.

Re: [toolbox] LaTeXiT 1.2 beta

[Pierre C. <pie...@cl...>]

>> Yes, good point, I will correct that.
>> Do you also want to be able to chose the default color and the  
>> latex mode (display, inline, text) ?
> That would be quite nice; especially since I usually use in-line  
> formats in the figures. Hope this isn't asking too much.
No, it's rather easy. The preferences will change a little. In the  
"general" pane, you will have the possibility to chose teh defaults  
color, font size, and mode, and in the "service" pane, the check box  
"use this color/font if not possible" will disappear, replaced by a  
label "otherwise, use default color/font"

> I noticed that when playing with it in Create! I thought it was  
> pretty neat but I see that there can be problems. Maybe the  
> transfer can take place if you close the window or do a Save  
> although I'd guess your suggestion would work a bit more  
> automatically.
Nice. So I will make refresh occur only on "latexize" event. I don't  
think it is agood idea to make it if the user close the window, since  
he was perhaps trying to get rid of the linkback link !

> Here is another pie-in-the-sky wish... Set a separate magnification  
> for the ``Preview'' pane. That way the equation can be the correct  
> smaller size I need for my figures but I can get a quick magnified  
> view of the results in that Preview pane to check it.
Mmm.... more difficult. I will investigate it.

> How about Cmd-T forcing a ``LaTeXize'' too? I guess I use that more  
> that Shft-Cmd-L in TeXShop because I use the engines quite a bit.  
> Well, I guess I could do that in the 10.4 System Preferences!
Why not ? Ok.


> I just noticed many lines that look like
>
> Jul  2 14:53:39 HSPBG4 /Applications/TeX/LaTeXiT/LaTeXiT.app/ 
> Contents/MacOS/LaTeXiT: WARNING: Type1 font data returned by  
> OFAStreamPSDownload isn't in the correct format required by the  
> Adobe Type 1 Font Format specification.
yes, I also noticed that. It occurs at every latexization, when I am  
creating a Cocoa PDFDocument with the pdf file generated by pdfLatex.  
I noticed that I can get rid of this warning if i first convert the  
pdf file to another pdf file using ghostscript. But I think it is not  
necessary (it would just waste time), since this warning seems not to  
generate any problem. But I should have documented that in "Know issues"

Pierre

Re: [toolbox] LaTeXiT 1.2 beta

[Herbert S. <he...@wi...>]

On Jul 2, 2005, at 2:27 PM, Pierre Chatelier wrote:

>> I see that there is an option in Preferences->Service to set a  
>> default font size (if you can't match the surrounding text size  
>> automatically) for the Service items. Could there also be  
>> (Preferences->General might be a good place for that) for a  
>> default font size besides 36.00pt when using LaTeXiT stand alone?
>>
> Yes, good point, I will correct that.
> Do you also want to be able to chose the default color and the  
> latex mode (display, inline, text) ?
>

Howdy,

That would be quite nice; especially since I usually use in-line  
formats in the figures. Hope this isn't asking too much.

>
>> Using the LinkBack is very nice!
>>
> Since you are using linkback, can you give me your opinion about  
> that :
> In the LaTeXiT beta that you are using, if you edit back an  
> equation through Linkback, the equation dropped in the other app  
> will be live-refreshed. It will be refreshed as soon as the image  
> in LaTeXiT changes. That means, it will change even if you simply  
> select an history item. But in fact, this is a problem, since if  
> you just click by error on the history, you lose the current  
> equation state, without possibilities to undo that. So, would you  
> mind, if the live refresh would be triggered only if the user  
> clicks the "latexize" buton ?
>

I noticed that when playing with it in Create! I thought it was  
pretty neat but I see that there can be problems. Maybe the transfer  
can take place if you close the window or do a Save although I'd  
guess your suggestion would work a bit more automatically.

> Regards,
>
> Pierre Chatelier
>

Here is another pie-in-the-sky wish... Set a separate magnification  
for the ``Preview'' pane. That way the equation can be the correct  
smaller size I need for my figures but I can get a quick magnified  
view of the results in that Preview pane to check it.

How about Cmd-T forcing a ``LaTeXize'' too? I guess I use that more  
that Shft-Cmd-L in TeXShop because I use the engines quite a bit.  
Well, I guess I could do that in the 10.4 System Preferences!

Good Luck,

Herb Schulz
(he...@wi...)

Re: [toolbox] LaTeXiT 1.2 beta

[Pierre C. <pie...@cl...>]

> I see that there is an option in Preferences->Service to set a  
> default font size (if you can't match the surrounding text size  
> automatically) for the Service items. Could there also be  
> (Preferences->General might be a good place for that) for a default  
> font size besides 36.00pt when using LaTeXiT stand alone?
Yes, good point, I will correct that.
Do you also want to be able to chose the default color and the latex  
mode (display, inline, text) ?

> Using the LinkBack is very nice!
Since you are using linkback, can you give me your opinion about that :
In the LaTeXiT beta that you are using, if you edit back an equation  
through Linkback, the equation dropped in the other app will be live- 
refreshed. It will be refreshed as soon as the image in LaTeXiT  
changes. That means, it will change even if you simply select an  
history item. But in fact, this is a problem, since if you just click  
by error on the history, you lose the current equation state, without  
possibilities to undo that. So, would you mind, if the live refresh  
would be triggered only if the user clicks the "latexize" buton ?

Regards,

Pierre Chatelier

Re: [toolbox] LaTeXiT 1.2 beta

[Herbert S. <he...@wi...>]

On Jul 2, 2005, at 11:56 AM, Pierre Chatelier wrote:

>
> I also wait some time to increase the chances to find and squash  
> bugs. If you feel like to help, you can download the beta to test  
> it and report bugs; such help is greatly appreciated !
> The download URL is : http://ktd.club.fr/programmation/fichiers/ 
> LaTeXiT-beta.dmg
>

Howdy,

Looking very nice so far.

I see that there is an option in Preferences->Service to set a  
default font size (if you can't match the surrounding text size  
automatically) for the Service items. Could there also be  
(Preferences->General might be a good place for that) for a default  
font size besides 36.00pt when using LaTeXiT stand alone?

I'll be using LaTeXiT with Create for figure text and I usually do  
that in 9pt when using 10pt running text. It would be convenient to  
be able to just have the point size default to that when I open LaTeXiT.

Using the LinkBack is very nice!

Good Luck,

Herb Schulz
(he...@wi...)

Re: [toolbox] Extended Attributes

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

On 2 Jul 2005, at 19:26, Maarten Sneep wrote:

> On 2 Jul 2005, at 19:03, Jon Guyer wrote:
>
>> On Jul 2, 2005, at 4:36 AM, J=E9r=F4me Laurens wrote:
>>
>>> I am very surprised! How can BBEdit track changes in file names =20
>>> while not being open.
>>> Did they patch the system? I would not be surprised if they use =20
>>> in fact resource forks...
>>
>> They almost certainly use aliases. Aliases are such a vastly =20
>> superior technology to unix symbolic links that  it's not even funny.
>
> I'll try to find the note in the release notes. I'll also try to =20
> find the external storage location. Be patient, I'll get back to =20
> you. IIRC, they use a property list representing a dictionary, with =20=

> aliases as the key. I might be mistaken though, please hold.

They changed the system in BBEdit 8.0: http://www.barebones.com/=20
support/bbedit/arch_bbedit80.shtml

To quote the relevant bits:

BBEdit no longer saves document state in the resource fork of the =20
document's file. This has a number of advantages, including (but not =20
necessarily limited to): no longer creating resource forks to save =20
document state, better compatibility with source-control systems, and =20=

easier personalization (your changes don't affect other users of =20
shared files).

Saved document states are forgotten 14 days after the last access, so =20=

the saved-state storage won't grow unbounded.

Note that no distinction is made between saved-state formats; the old =20=

"MPW" and "BBEdit" state settings are gone. You can control whether =20
BBEdit saves document states by means of the "Save Document State" =20
switch in the Text Files: Saving preferences.

The "State" preferences have been consigned to the dustbin of =20
history. Settings which control how (or if) BBEdit honors saved state =20=

are now in the "Text Files: Opening" preferences.

(end quote)

For some setting you *do* want others to be affected: text encoding =20
comes to mind (although I can't recall if that was ever stored in the =20=

document state).

The information is stored in "~/Library/Preferences/=20
com.barebones.bbedit.PreferenceData/Document State.plist" (and a =20
similar location for TextWrangler). =46rom a cursory view of the =20
property list, it seems there are no aliases in this file. I can tell =20=

it is robust, but I can't tell how they did this.

Maarten=

Re: [toolbox] Extended Attributes

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

On 2 Jul 2005, at 19:03, Jon Guyer wrote:

>
> On Jul 2, 2005, at 4:36 AM, J=E9r=F4me Laurens wrote:
>
>
>> I am very surprised! How can BBEdit track changes in file names =20
>> while not being open.
>> Did they patch the system? I would not be surprised if they use in =20=

>> fact resource forks...
>
> They almost certainly use aliases. Aliases are such a vastly =20
> superior technology to unix symbolic links that  it's not even funny.

I'll try to find the note in the release notes. I'll also try to find =20=

the external storage location. Be patient, I'll get back to you. =20
IIRC, they use a property list representing a dictionary, with =20
aliases as the key. I might be mistaken though, please hold.

>> 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 =20
>> really elegant.
>
> I think BBEdit stores the files in its preferences, so it doesn't =20
> move around. Of course, that means it doesn't go with the file if =20
> you send it to somebody or move it to a different computer.

I had to read this twice: at first I thought you said that BBEdit =20
stored all files in its preferences, which would be silly :p -- they =20
store the file state in a separate file somewhere in the preferences =20
system or in application support.

Maarten

Re: [toolbox] Extended Attributes

[Jon G. <jg...@hi...>]

On Jul 2, 2005, at 4:36 AM, J=E9r=F4me Laurens wrote:

> 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=20
> fact resource forks...

They almost certainly use aliases. Aliases are such a vastly superior=20
technology to unix symbolic links that  it's not even funny.

> 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=20
> really elegant.

I think BBEdit stores the files in its preferences, so it doesn't move=20=

around. Of course, that means it doesn't go with the file if you send=20
it to somebody or move it to a different computer.

[toolbox] LaTeXiT 1.2 beta

[Pierre C. <pie...@cl...>]

Hello,

I am about to release a new version of LaTeXiT; I am waiting for =20
MacOS 10.4.2, that will fix a bug of 10.4.1 that I handle with a =20
dirty workaround. That's why in the documentation it is written that =20
LaTeXiT 1.2 will be compatible only with 10.4.2 at least. That is =20
untrue for this beta, but it will be in the future. This beta only =20
requires 10.4

I also wait some time to increase the chances to find and squash =20
bugs. If you feel like to help, you can download the beta to test it =20
and report bugs; such help is greatly appreciated !
The download URL is : http://ktd.club.fr/programmation/fichiers/=20
LaTeXiT-beta.dmg

LaTeXiT is a tool similar to LaTeX Equation Editor, in the sense that =20=

it allows to quickly typeset a latex equation and drag'n drop it in =20
another application.
Its main feature that make it useful are:
-a smart error manager
-automatic history
-a library to store the equation you use very often
-LaTeXiT can be called as an application service to transform text =20
into an image of the equation
-LinkBack support (an equation dropped from LaTeXiT in an application =20=

supporting LinkBack can be reopen and modified; see the readme for =20
more info)
-now open source software (source code will be available with the =20
final 1.2 version)

For those who have already used LaTeXiT, here are the "what's new"
v 1.2
- the software is now Tiger only (at least MacOS 10.4.2) ;
- ready for Mac-Intel (compiled using UniversalBinary) ; but even if =20
the Intel version should not contain specific bugs, it could not be =20
tested anyway. So it is considered "experimental", and bug reports =20
(for those who own a Mac-Intel) are welcome ;
- the software is now under the CeCILL license (open source, GPL =20
compatible) ;
- improved speed ;
- better LinkBack support (you can now "refresh" an equation dropped =20
into another application) ;
- you can now repoen with LaTeXiT a PDF file created by it ;
- you can now drop on the Finder items from the history or from the =20
library ;
- the export format, by drag'n drop or through the service, is now =20
customizable ;
- better application service configurability ;
- the LaTeXiT service now tries to align the equation with the =20
surrounding text ;
- the LaTeXiT service can now use the same color as the source text ;
- you can now update a library item without deleting/recreating it ;
- japanese users can now use the " =C2=A5 " (yen) symbol instead of " \ =20=

" (backslash) ;
- updated palettes ;
- corrected tooltips in the palette ;
- the latexization can now be triggered with =E2=8C=98L or =E2=87=A7=E2=8C=
=98L (to =20
please TeXShop users) ;
- some minor bugs fixed.

Thanks in advance

Pierre Chatelier

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.

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=

Re: [toolbox] Fwd: (Case 43877) Open request: extended attributes for file encoding

[Jon G. <jg...@hi...>]

On Jul 1, 2005, at 11:18 AM, Maarten Sneep wrote:

> A while ago I asked BareBones about support for storing the file 
> encoding in an extended attribute. I think the answer is box-standard, 
> but they are investigating this - which in itself is good news. 
> Perhaps a pre-emptive strike on our behalf?

We'll look into supporting this in Alpha.  The more information what 
*what* should be supported, the better.

[toolbox] Fwd: (Case 43877) Open request: extended attributes for file encoding

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

Hi listers,

A while ago I asked BareBones about support for storing the file  
encoding in an extended attribute. I think the answer is box- 
standard, but they are investigating this - which in itself is good  
news. Perhaps a pre-emptive strike on our behalf?

Regards,

Maarten

Begin forwarded message:

> From: "Bare Bones Software Technical Support"
> Date: 13 May 2005 22:42:53 GMT+02:00
> To: Maarten Sneep
> Subject: Re: (Case 43877) Open request: extended attributes for  
> file encoding
>
> Maarten Sneep wrote:
>
>> Hi,
>>
>> With Tiger, files can have extended attributes. These can hold a
>> variety of data (all of which could be interesting for various
>> applications). I'm interested in storing the text encoding in an
>> xattr node. Are you aware of any proposed standard for the name of
>> such an xattr in this respect, or are you planning to force something
>> down all our throats ;-).
>>
>> Joking aside: I think it would be a good idea to remove heuristic
>> interpretation whenever possible, and BareBones may just have the
>> influence in the Mac text editor community to set a standard.
>>
>> Kind regards,
>>
>> Maarten Sneep
>>
>
> Thanks for writing in, we appreciate your feedback.
>
> The product engineering team is investigating possible support in  
> some future version, but per our standard policy, I regret that I  
> cannot speculate on when or if this will be added.
>
> Please don't hesitate to write if you have any more questions or  
> problems.
>
> -- John

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

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=