Re: [toolbox] completion format

[Adam R. M. <ama...@ma...>]

On Apr 25, 2006, at 18:57, Will Robertson wrote:

> 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 =20
> my quickly hacked together solution. I was just following from what =20=

> TeXShop already provided for.

Wouldn't this be front-end specific?  I don't see anything wrong with =20=

having <#...#>, even, since it's strictly a placeholder.  Xcode uses =20
ctrl-/ to select placeholders as well, so that's a nice familiar =20
shortcut for some of us.

>>
>>  > 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 =20
>> should 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!!
> No, this is a core concept to making LaTeX easier to use. It =20
> shouldn't be up to the user to add every single macro defined to =20
> their completions file, nor for a studious individual to hand craft =20=

> an all-encompassing list.

This sounds like a good job for a grad student who can't concentrate =20
on research :).  However it's implemented, it would be very handy.
>
>
[...]

>>  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 =20
> gains you here, but why not. In a good implementation, the =20
> metamarkers would never appear in the TeX source.

XML is probably a good choice; it's machine readable and checkable, =20
although (IMHO) it sucks to read/write by hand.  I curious as to why =20
the meta markers should be a part of any standard, though; why would =20
they be present in the XML file?

[...]
>
>
>>  Remark:
>>  Some extensions of this macros/completion design.
>>  Suppose you have a macro whose parameters only take a finite =20
>> number of
>>  values, the user interface should only present these =20
>> possibilities. If
>>  you have a more complex macro, the user interface might need a =20
>> 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.

If anyone's interested in a popup window implementation for =20
autocomplete, we rewrote Apple's NSTextView autocompletion mechanism =20
for BibDesk.  I wonder how difficult it would be to add that style =20
(popup child window) of autocomplete for LaTeX?  It could be =20
triggered by something like "\usepackage geom"<hit esc>, search list =20
of commands and packages with "geom" in them, and then replacing " =20
geom" with the selected choice.

Adam=