Re: [toolbox] completion format

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

Le 26 avr. 06, =E0 03:57, Will Robertson a =E9crit :

> Sorry, Mail.app just nuked half of my [toolbox] messages during a=20
> crash. Damn this app.
>
>>  For iTeXMac2, I changed the bullet character to __(ANYTHING)__
>>  I adapted the xcode behaviour concerning placeholders.
>>  Xcode uses something like
>>
>>  [myTextView setSelectedRange:<#NSRange aRange#>];
>>
>>  The problem with this syntax is that < and > are not allowed in xml
>>  files...
>>  This is why I replaced them with __()__
>
> XML, meh. Anyway, my characters weren't <>, they were =8B=9B, single=20=

> guillemets. An opening/closing syntax is a marked improvement over my=20=

> quickly hacked together solution. I was just following from what=20
> TeXShop already provided for.
>
>>  BTW, the actions to select the next and pervious placeholders should=20=

>> be
>>  part of the editor, not an applescript add on.
>
> Again, whatever. Applescript add-ons provide a good way to "suggest"=20=

> new features. It works and has worked well enough for now, but I agree=20=

> it would be better to integrate it into the app.

There are other good (better) ways to extend an app: plug-ins, perl=20
script, ...

>
>>  If you have some time, see how iTM2 deals with macros at
>>  http://itexmac.sourceforge.net/wiki/index.php/Macros.
>
> I'll be investigating iTM2 thoroughly when the final version is=20
> released. I don't have time, I'm sorry to say, to help out with bug=20
> testing.
>
>>  > New LaTeX packages should be able to write their own command
>>  > description file (via the dtx mechanism) which would be preparsed
>>  > somewhere such that when a \usepackage is recognised, the extra=20
>> macros
>>  > can be added to the current pool of "known" commands that the=20
>> editor
>>  > can prompt for. Ideally, every single user command in LaTeX should=20=

>> be
>>  > completely documented in this way, which would then allow true=20
>> syntax
>>  > spell checking of LaTeX code.
>>
>>  This is a detail.
>
> And what a detail!!
Sorry Will, for me spell checking was just a detail compared to the=20
rest of the paragraph...
The problem with latex and other programming languages is "what command=20=

is legal -now-?"
> No, this is a core concept to making LaTeX easier to use. It shouldn't=20=

> be up to the user to add every single macro defined to their=20
> completions file, nor for a studious individual to hand craft an=20
> all-encompassing list.
>
>>  > I imagine an extension to \newcommand (or the LaTeX3 equivalent,=20=

>> more
>>  > likely) that takes such syntax information for purely metadata
>>  > reasons. E.g.,
>>  >   \newcommand\mycommand[2]{#1: #2}
>>  >   \describemacro\mycommand[1=3Dfirst arg, 2=3Dsecond arg]{This is =
a=20
>> macro
>>  > for not doing much.}

I forgot: this is very similar to the management of macros designed for=20=

ConTeXt

>>
>>  Here is my pov.
>>
>>  You should not rely on metadata in the dtx:
>>  1 - if it were easy people would have implemented/used it for a long
>>  time.
>>  2 - There are some people in the world that would like to see this
>>  information in their native languages
>>  3 - once the documentation is put in the dtx, you cannot improve it
>>  until the next release...
>
> I disagree with each of these statements.
> 1 - There has never been good coordination between macro writers and=20=

> frontends.

Because macro and frontends are already 2 difficult things when managed=20=

independently.
People are reluctant to add the complexity of managing both at the same=20=

time...


> 2 - \describemacro\mycommand[english][1=3Dfirst, 2=3Dsecond]{...}
>     \describemacro\mycommand[french][1=3Dune, 2=3Ddeu]{...}

see below

> 3 - Supplementary files containing \describemacro can be created.

And the documentation is no longer in the dtx...
and different localizations can live in different files...

>
>>  4 - it takes time to parse the dtx for just one part of information
>
> Yes, I envision a caching system when the .dtx file is installed.
>
>>  5 - Caching the result of the parsing is quite like not using the =
dtx
>>  at all.
>
> NO!
> Using the dtx ensures that the completion file remains up-to-date with=20=

> the package, and provides that the author of the package specifies how=20=

> it works.

Version checking

>
>>  Instead, here is my proposal:
>>
>>  1 agree on meta markers , I vote for __(*)__ instead of *. The
>>  former is not mac centric, is xml compliant and of course is a TeX
>>  error.
>>  2 agree on a xml format
>>  3 agree on a categorization (to uniquely identify the macro...)
>>  4 agree on a context dependency (to ensure that \put is used in=20
>> picture
>>  environments only...)
>
> Sure, all these are insignificant details. I don't see what XML gains=20=

> you here, but why not.

the xml grammar is better than tex's
the parser already exists

If you define a new dtx scheme, you'll have to write an appropriate=20
parser too.
Moreover, how will you convince macros developpers to support the new=20
dtx scheme?

> In a good implementation, the metamarkers would never appear in the=20
> TeX source.
>
>>  5 create a web form where anyone can contribute. when posting, this
>>  form will just create an xml file containing the appropriate
>>  information, including language, format, and so on. Some kind of =
wiki
>>  or spip would help. No need to be a programmer to write doc.
>
> Too hard. Let the package writers deal with it. Docs should only have=20=

> to be written once and then everyone can benefit, and the syntax=20
> shouldn't be tricky. You want to waste time with a web form?!?

If the docs should only have to be written once, then there is no=20
problem of synchronization with the package.
How many macros in how many packages?

If there is only one form for each macro of each package, I don't call=20=

this a waste of time.

>
>>  6 Any frontend will just do whatever they want with this material=20
>> (it's
>>  easy with a bit of perl and xslt.).
>
> Yes. An agnostic approach is highly desirable.
>
>>  That way, many people can contribute, and we just have to designate
>>  some moderators to accept contributions, modifications...
>
> Are you volunteering to moderate? This is impractical.

Not if there are moderator-s-

>
>>  Remark:
>>  Some extensions of this macros/completion design.
>>  Suppose you have a macro whose parameters only take a finite number=20=

>> of
>>  values, the user interface should only present these possibilities.=20=

>> If
>>  you have a more complex macro, the user interface might need a =
better
>>  approach.
>>  For example,
>>
>>  \usepackage[__(choose:paper size, a4paper,a5paper,a6paper,letter,
>>  legal)__]{geometry}
>>
>>  would show a small window with a popup to let the user choose the
>>  proper paper size.
>
> This is a good idea, and fits in better with extracting this data from=20=

> the .dtx file. Take a look at xkeyval -- it has a structured approach=20=

> for defining keyval lists, from which data such as the above can be=20
> extracted.
>
> A dtx file is supposed to be a self-contained implementation and=20
> documentation of a package. Moving the macro syntax out of here is=20
> madness.

Yes, it is certainly a nonsense to move anything out of the dtx archive.
But we are talking about adding something new, aren't we?

BTW, what if a package maintainer does not want to adhere to your new=20
dtx scheme?
What if a package maintainer does not want to manage different=20
localizations?

I am afraid your solution is not efficient in practice because it=20
relies on a supplemental work assigned to an already designated person.
When someone chose to maintain some package, the localization was not=20
in the contract... It is not fair to add something behind hisback.
If you design a new approach and say : okay any one can contribute,=20
then you will have some success.
See how things work for cocoa: localization has a minimal binding=20
inside the code such that you can localize the application without=20
knowing any programming language.

>
> Will
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,=20
> security?
> Get stuff done quickly with pre-integrated technology to make your job=20=

> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache=20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd--Mactextoolbox-talk mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/mactextoolbox-talk
>