Re: [toolbox] completion format
Status: Planning
Brought to you by:
jlaurens
From: <jer...@u-...> - 2006-04-28 22:27:37
|
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 > |