Re: [toolbox] completion format

[Will R. <ws...@gm...>]

Hi Jerome,

Not sure how productive this thread is, but it's good to hash out  
some consensus.

>>>  > 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 macros
>>>  > can be added to the current pool of "known" commands that the  
>>> editor
>>>  > can prompt for. Ideally, every single user command in LaTeX  
>>> should be
>>>  > completely documented in this way, which would then allow true  
>>> 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  
> rest of the paragraph...
> The problem with latex and other programming languages is "what  
> command is legal -now-?"

Sorry, I thought your "this is a detail" applied to the whole  
paragraph. I don't see too much difference between "what command is  
legal -now-" and spelling checking LaTeX code, anyway. I think we're  
agreed here that the functionality would be nice.

>> I disagree with each of these statements.
>> 1 - There has never been good coordination between macro writers  
>> and frontends.
>
> Because macro and frontends are already 2 difficult things when  
> managed independently.
> People are reluctant to add the complexity of managing both at the  
> same time...

Perhaps I didn't explain myself properly. I mean that frontends  
haven't tended to take advantage of the structured way LaTeX  
programmers write their macros. For example, it's easy to parse  
a .sty file for \DeclareOption and prompt for package options  
interactively (I wrote an Applescript once).

So maybe it's time for the macro writers to take the initiative and  
provide more hooks for the frontend authors.

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

This is only for packages who don't want to do this themselves. In an  
ideal world. this wouldn't be necessary. I know, we don't live in an  
ideal world.

>>>  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 the package, and provides that the author of the package  
>> specifies how it works.
>
> Version checking

More complexity.

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

Ah, here's the rub.
Obviously, it's too late for LaTeX2e.
But if the functionality is written into LaTeX3, I predict the  
advantages would be apparent and the scheme would be followed.

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

Easier I think to find an enthusiastic volunteer who's willing to  
trawl through the LaTeX sources and packages adding everything in  
sight. The problem as always is (wo)manpower.

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

I agree it's a long shot that this sort of thing will work in the  
capacity that I imagine.
It's clear to me now that something has to be written at the macro  
level in docstrip to prove the technique before talk of what can be  
done by the frontend is discussed. Provided the macro solution is  
sufficiently general, the results can be transformed easily enough to  
suit whatever purpose.

Perhaps I'll bring it up with the LaTeX3 people and see if anyone  
there has thought about similar things.

Will