Re: [toolbox] TeXShop completions

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

Le 21 avr. 06, =88 10:43, Will Robertson a =8Ecrit :

> Hello everyone,
>
> I've finally gotten around to taking a more decent look at TeXShop's=20=

> completions, courtesy of some old file of Herb Schulz's I have lying=20=

> around. (Are you here, Herb?)
>
> I've been hacking away at it for a little while now when it occurred=20=

> to me that I should check if it's been improved since I got my hands=20=

> on it. (I don't even know if the file's publicly available any more.)
>
> Anyway, I think you'll like what I've been doing. I always forget what=20=

> the more complex optional arguments are supposed to be in things like=20=

> minipages. I've now got completions like the following:
>
> 	\framebox[#INS#=F0=DCwidth=DD][=F0=DCpos: c,l,r,s=DD]{=F0}
> 	\framebox[#INS#]{=F0}
>
> 	\makebox[#INS#=F0=DCwidth=DD][=F0=DCpos: c,l,r,s=DD]{=F0}
> 	\makebox[#INS#]{=F0}
>
> 	\raisebox{#INS#=F0=DCraise=DD}[=F0=DCheight=DD][=F0=DCdepth=DD]{=F0=
}
> 	\raisebox{#INS#=F0=DCraise=DD}[=F0=DCheight=DD]{=F0}
> 	\raisebox{#INS#}{=F0}
>
> And I've modified the bullet searching TeXShop macros to select any=20
> matching =DC...=DD text after a bullet as well (see appended, and feel=20=

> free to distribute -- I copied them from Herb).
>

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=20
files...
This is why I replaced them with __()__

__(INS)__ is an end of the selected range
__(SEL)__ is the selected text...

The above syntax becomes

\raisebox{__(INS)____(raise)____(INS)__}{__(height)__}{__(depth)__}

It is pure ascii and works easily with xml. Moreover, '__(' and ')__'=20
are clearly opening and closing tags.
Both leading to TeX errors such that they will not be used (except by=20
super gurus).

BTW, the actions to select the next and pervious placeholders should be=20=

part of the editor, not an applescript add on.



> I'm keen on the idea of expanding the completion file to include as=20
> much of base LaTeX as possible, following conventions something like=20=

> the above. There's no reason it should be TeXShop specific, either. I=20=

> don't know how much time I have or how long my motivation will last,=20=

> but anyone interested in helping out would be great. I guess this file=20=

> would need to be placed in a svn site somewhere if more than one=20
> person were to work on it.
>
> Hypothetically, I would like this file to evolve beyond TeXShop's=20
> current completion engine into a file that can be used for more=20
> flexible purposes; e.g., code prompting as you type.

and macros!
You are addressing a completely different problem here.
One should make a distinction between the macros and the mean to=20
activate theme.
The completion is just a user interface to activate some macro, just=20
like a menu item.

If you have some time, see how iTM2 deals with macros at=20
http://itexmac.sourceforge.net/wiki/index.php/Macros.

> New LaTeX packages should be able to write their own command=20
> description file (via the dtx mechanism) which would be preparsed=20
> somewhere such that when a \usepackage is recognised, the extra macros=20=

> can be added to the current pool of "known" commands that the editor=20=

> can prompt for. Ideally, every single user command in LaTeX should be=20=

> completely documented in this way, which would then allow true syntax=20=

> spell checking of LaTeX code.

This is a detail.

>
> I imagine an extension to \newcommand (or the LaTeX3 equivalent, more=20=

> likely) that takes such syntax information for purely metadata=20
> reasons. E.g.,
>   \newcommand\mycommand[2]
>     (1: first argument; 2:second argument)
>     {#1: #2}
> (I just made that up on the spot. Perhaps it's not such a good idea.)=20=

> Alternatively,
>   \newcommand\mycommand[2]{#1: #2}
>   \describemacro\mycommand[1=3Dfirst arg, 2=3Dsecond arg]{This is a =
macro=20
> for not doing much.}
>
> I know, I know. It's all easy to say these things, but I'm not the=20
> first to think of them so I believe the idea has merit. (Frank=20
> Mittelbach touches briefly on the subject in the documentation file,=20=

> if I recall correctly, ltxdoc.pdf .)
>
> Just some rambling thoughts for a procrastinating Friday evening. Any=20=

> thoughts?
>
> Will
>
>

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=20
time.
2 - There are some people in the world that would like to see this=20
information in their native languages
3 - once the documentation is put in the dtx, you cannot improve it=20
until the next release...
4 - it takes time to parse the dtx for just one part of information
5 - Caching the result of the parsing is quite like not using the dtx=20
at all.

Instead, here is my proposal:

1 agree on meta markers , I vote for __(*)__ instead of =F0=DC*=DD. The=20=

former is not mac centric, is xml compliant and of course is a TeX=20
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 picture=20=

environments only...)
5 create a web form where anyone can contribute. when posting, this=20
form will just create an xml file containing the appropriate=20
information, including language, format, and so on. Some kind of wiki=20
or spip would help. No need to be a programmer to write doc.
6 Any frontend will just do whatever they want with this material (it's=20=

easy with a bit of perl and xslt.).

That way, many people can contribute, and we just have to designate=20
some moderators to accept contributions, modifications...

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

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

you have a more complex macro, the user interface might need a better=20
approach.
For example,

\usepackage[__(choose:paper size, a4paper,a5paper,a6paper,letter,=20
legal)__]{geometry}

would show a small window with a popup to let the user choose the=20
proper paper size.