audit of commands

older
Re: [dev-context] audit of commands

Idris Samawi Hamid ادريس سماوي ح امد

6 May 2010 6 May '10

9:50 a.m.

Dear gangsters, I'm interested in an audit of all current mid-to-high-level mkiv commands, including experimental or undocumented ones. I'm trying to come up with, as much as possible, a set of context commands which is mutually exclusive jointly exhaustive. By 'mutually exlcusive' in this context I mean that I want to identify, for redundant commands, the deprecated commands and use only the current. No point teaching old methods. By 'jointly exhaustive' I mean that i don't want to leave anything out, at least not yet. Some of, eg, the bidi and otf control is undocumented, and I can dig those up. OTOH there are lots of other areas where there may be some commands of interest that only get brought up on the list occasionally... by mid-level I mean commands like \define or other user-friendly non-plain commands that may be used to create mkiv macros etc. Aside from core developers Hans and Taco: Luigi, Wolfgang and Mojca seem to have extensive knowledge of the internals... any ideas how we can do this in an efficient manner? My idea is to organize this list in interesting ways for pedagogical purposes, for the current book project. Again, ONLY MKIV is under consideration; as far as this book project is concerned, only mkiv exists ;-) Any help is greatly appreciated! Peace Idris -- Professor Idris Samawi Hamid, Editor-in-Chief International Journal of Shi`i Studies Department of Philosophy Colorado State University Fort Collins, CO 80523

Show replies by date

luigi scarso

7 May 7 May

1:41 a.m.

2010/5/6 Idris Samawi Hamid ادريس سماوي حامد :

...

Dear gangsters,

I'm interested in an audit of all current mid-to-high-level mkiv commands, including experimental or undocumented ones. I'm trying to come up with, as much as possible, a set of context commands which is

mutually exclusive

jointly exhaustive.

By 'mutually exlcusive' in this context I mean that I want to identify, for redundant commands, the deprecated commands and use only the current. No point teaching old methods.

By 'jointly exhaustive' I mean that i don't want to leave anything out, at least not yet. Some of, eg, the bidi and otf control is undocumented, and I can dig those up. OTOH there are lots of other areas where there may be some commands of interest that only get brought up on the list occasionally...

by mid-level I mean commands like

\define

or other user-friendly non-plain commands that may be used to create mkiv macros etc.

Aside from core developers Hans and Taco: Luigi, Wolfgang and Mojca seem to have extensive knowledge of the internals... any ideas how we can do this in an efficient manner?

My idea is to organize this list in interesting ways for pedagogical purposes, for the current book project.

Again, ONLY MKIV is under consideration; as far as this book project is concerned, only mkiv exists ;-)

Any help is greatly appreciated!

I remember a "tally" variable in pdftex that governs the lenght of line used in trace commands Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe. -- luigi

Hans Hagen

1:56 a.m.

On 7-5-2010 9:41, luigi scarso wrote:

...

Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe.

already there for a while: context --dumphash yourfile context --dumpdelta yourfile of course undocumented apart from context --help --expert Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

luigi scarso

2:07 a.m.

2010/5/7 Hans Hagen :

...

On 7-5-2010 9:41, luigi scarso wrote:

...
Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe.

already there for a while:

context --dumphash yourfile context --dumpdelta yourfile

of course undocumented apart from context --help --expert yes, but what I meant was something like \tracingall \starttext

\stoptext and then parsing the log extracting macro & their meaning Not for this trivial example, but for context.tex -- luigi

Hans Hagen

2:24 a.m.

On 7-5-2010 10:07, luigi scarso wrote:

...

2010/5/7 Hans Hagen:

...
On 7-5-2010 9:41, luigi scarso wrote:

...
Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe.

already there for a while:

context --dumphash yourfile context --dumpdelta yourfile

of course undocumented apart from context --help --expert yes, but what I meant was something like \tracingall \starttext

\stoptext and then parsing the log extracting macro& their meaning

even their meaning? that would be huge (with --dumphash you get the macros + some statistics) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Taco Hoekwater

2:45 a.m.

Hans Hagen wrote:

...

On 7-5-2010 10:07, luigi scarso wrote:

...
2010/5/7 Hans Hagen:

...
On 7-5-2010 9:41, luigi scarso wrote:

...
Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe.

already there for a while:

context --dumphash yourfile context --dumpdelta yourfile

of course undocumented apart from context --help --expert yes, but what I meant was something like \tracingall \starttext

\stoptext and then parsing the log extracting macro& their meaning

even their meaning? that would be huge

You could use the --dumphash output to get a list of meanings (with a bit of lua processing to run \meaning\<csname>), but in general the meanings are not always that useful, because a lot of macros expand into \dosingleempty c.s. Best wishes, Taco

Idris Samawi Hamid ادريس سماوي حامد

7:50 a.m.

Hi Luigi, On Fri, 07 May 2010 01:41:09 -0600, luigi scarso wrote:

...

...
Again, ONLY MKIV is under consideration; as far as this book project is concerned, only mkiv exists ;-)

Any help is greatly appreciated! I remember a "tally" variable in pdftex that governs the lenght of line used in trace commands Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe.

I don't pretend to 100% understand you ;-) but I greatly appreciate this. I guess is should also be simple enough to ignore the dedicated mkii files where there are two versions of the macros. How and when can I see that list? Or maybe better: post the list on yours or the main wiki page and then we can all contribute/discuss to make sure it's complete, identify and tag the deprecated/obsolete/redundant commands, etc... Peace Idris -- Professor Idris Samawi Hamid, Editor-in-Chief International Journal of Shi`i Studies Department of Philosophy Colorado State University Fort Collins, CO 80523

Marius

8:05 a.m.

Idris, maybe this is what you are looking for: http://www.pragma-ade.com/general/qrcs/setup-en.pdf And at the same time I have a question. Does this list of commands is the most recent? Is it generated automaticaly? 2010/5/7 Idris Samawi Hamid ادريس سماوي حامد :

...

Hi Luigi,

On Fri, 07 May 2010 01:41:09 -0600, luigi scarso wrote:

...
...
Again, ONLY MKIV is under consideration; as far as this book project is concerned, only mkiv exists ;-)

Any help is greatly appreciated!

I remember a "tally" variable in pdftex that governs the lenght of line used in trace commands Starting from it, and modifying the pdftew.web, I've produced the lists of all macros and their meaning simple put something like \tracingmacros3 etc at the beginning of context.tex and then rebuild the format. I can revisit it now for luatex: this should still work for TeX macros but not for Lua functions, I believe.

I don't pretend to 100% understand you ;-) but I greatly appreciate this. I guess is should also be simple enough to ignore the dedicated mkii files where there are two versions of the macros. How and when can I see that list?

Or maybe better: post the list on yours or the main wiki page and then we can all contribute/discuss to make sure it's complete, identify and tag the deprecated/obsolete/redundant commands, etc...

Peace Idris

-- Professor Idris Samawi Hamid, Editor-in-Chief International Journal of Shi`i Studies Department of Philosophy Colorado State University Fort Collins, CO 80523

_______________________________________________ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context

luigi scarso

8:12 a.m.

On Fri, May 7, 2010 at 4:05 PM, Marius wrote:

...

Idris, maybe this is what you are looking for: http://www.pragma-ade.com/general/qrcs/setup-en.pdf

And at the same time I have a question. Does this list of commands is the most recent? Is it generated automaticaly? If I remember well the sources are here minimals/tex/texmf-context/tex/context/interface

-- luigi

Hans Hagen

9:04 a.m.

On 7-5-2010 4:05, Marius wrote:

...

the most recent? Is it generated automaticaly?

Peter Münster

8 May 8 May

2:43 p.m.

On Thu, May 06 2010, Idris Samawi Hamid ادريس سماوي حامد wrote:

...

I'm interested in an audit of all current mid-to-high-level mkiv commands, including experimental or undocumented ones. I'm trying to come up with, as much as possible, a set of context commands which is

mutually exclusive

jointly exhaustive.

Hello, I would like to contribute to a very similar project: a new version of setup-en.pdf, more verbose (detailed description of all options), complete (even for low-level commands, but like you no obsolete commands), and with some additional features (categories, index, cross-references). There is also the new command reference on the wiki, but it's not enough tagged. Here my questions: - How could all these efforts be shared in the most efficient way? - Are others already working for the above project? - Is the structure of cont-en.xml already the good choice and it only needs some extensions for additional features, or would it be as good to use lua-tables (one lua-file per command for example)? I imagine the following steps: 1. decision how to structure the commands (lua or xml or ...) 2. script for producing setup-en.pdf (perhaps Hans can provide his current converter?) 3. implementation of \showsetup (currently broken anyway) 4. filling in the structure with all available information at the moment (last cont-en.xml, wiki) 5. putting nightly built setup-en.pdf on-line 6. filling the structure with all command descriptions Then continuously: 7. updating command descriptions at each update on the wiki 8. updating command descriptions at each new context release 9. updating command descriptions whenever something seems not clear enough (questions on mailing list) Please send me your comments! Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

Hans Hagen

4:08 p.m.

On 8-5-2010 10:43, Peter Münster wrote:

...

Here my questions:

- How could all these efforts be shared in the most efficient way?

- Are others already working for the above project?

- Is the structure of cont-en.xml already the good choice and it only needs some extensions for additional features, or would it be as good to use lua-tables (one lua-file per command for example)?

I think that it does not make much sense to extend cont-en.xml as extending it will make it way too big to be convenient. Also, I use that file for generating the current setup-* files as part of generating a beta an di'd like to keep that test. Of course adding more complete definitions (or fixing them) in cont-en.xml is welcome. I can add an index or whatever needed based on cont-en.xml as long sas it does not get bloated. So, how about more extensive info. As each command has a unique reference, the best approach is to have a separate file for each such entry. I suppose that this can be generated from the wiki. From that it's possible to generate something big (although big pdf's are not that much fun) or generate command specific files that are crosslinked to the main setup file.

...

I imagine the following steps: 1. decision how to structure the commands (lua or xml or ...)

the xml is handy for manipulations but documentation about tex can best be done in tex (verbatim can get quite messy in xml)

...

2. script for producing setup-en.pdf (perhaps Hans can provide his current converter?)

it's all in the distribution (x-set-*)

...

3. implementation of \showsetup (currently broken anyway)

hm, in what sense broken?

...

4. filling in the structure with all available information at the moment (last cont-en.xml, wiki) 5. putting nightly built setup-en.pdf on-line 6. filling the structure with all command descriptions

Then continuously: 7. updating command descriptions at each update on the wiki 8. updating command descriptions at each new context release 9. updating command descriptions whenever something seems not clear enough (questions on mailing list)

ambituous -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Peter Münster

10 May 10 May

3:23 a.m.

On Sun, May 09 2010, Hans Hagen wrote:

...

So, how about more extensive info. As each command has a unique reference, the best approach is to have a separate file for each such entry. I suppose that this can be generated from the wiki.

Hello Hans, Yes, I also like one file per command, it's easier to manage.

...

From that it's possible to generate something big (although big pdf's are not that much fun) or generate command specific files that are crosslinked to the main setup file.

For looking up something, I often open big pdf-files (> 1000 pages), and the size doesn't matter. But for printing it, I agree. If someone really wants to print it on A4, the font size must be small and it must be 2-column layout.

...

...
I imagine the following steps: 1. decision how to structure the commands (lua or xml or ...)

the xml is handy for manipulations but documentation about tex can best be done in tex (verbatim can get quite messy in xml)

Thanks for the advice. This is good, because I don't have any experience with xml.

...

...
3. implementation of \showsetup (currently broken anyway)

hm, in what sense broken?

No output: \usemodule[set-11] \loadsetups % from contextref-env.tex (context-manual) \starttext \showsetup{startproject} % from co-documents.tex (context-manual) \stoptext

...

ambituous -)

Yes, it'll take a long time (I can spend only 2-3 hours per week...). So what about: - a new directory "http://foundry.supelec.fr/svn/contextman/context-commands" - one tex-file per command ? If you agree, I just start. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

Hans Hagen

4:49 a.m.

On 10-5-2010 11:23, Peter Münster wrote:

...

On Sun, May 09 2010, Hans Hagen wrote:

...
So, how about more extensive info. As each command has a unique reference, the best approach is to have a separate file for each such entry. I suppose that this can be generated from the wiki.

Hello Hans,

Yes, I also like one file per command, it's easier to manage.

...
From that it's possible to generate something big (although big pdf's are not that much fun) or generate command specific files that are crosslinked to the main setup file.

For looking up something, I often open big pdf-files (> 1000 pages), and the size doesn't matter. But for printing it, I agree. If someone really wants to print it on A4, the font size must be small and it must be 2-column layout.

printing, distribution and generation also, i expect it to be more that 1000 pages at some point

...

...
...
I imagine the following steps: 1. decision how to structure the commands (lua or xml or ...)

the xml is handy for manipulations but documentation about tex can best be done in tex (verbatim can get quite messy in xml)

Thanks for the advice. This is good, because I don't have any experience with xml.

...
...
3. implementation of \showsetup (currently broken anyway)

hm, in what sense broken?

No output:

\usemodule[set-11] \loadsetups % from contextref-env.tex (context-manual) \starttext \showsetup{startproject} % from co-documents.tex (context-manual) \stoptext

\usemodule[set-11] \loadsetups \starttext \showsetup{framed} \stoptext works -)

...

So what about: - a new directory "http://foundry.supelec.fr/svn/contextman/context-commands" - one tex-file per command

If you agree, I just start.

let me think about it for a while (naming and such) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

luigi scarso

4:55 a.m.

...

\usemodule[set-11]

\loadsetups

\starttext \showsetup{framed} \stoptext

works -) here too with last current -- luigi

Taco Hoekwater

5:13 a.m.

Hans Hagen wrote:

...

...
So what about: - a new directory "http://foundry.supelec.fr/svn/contextman/context-commands" - one tex-file per command

If you agree, I just start.

let me think about it for a while (naming and such)

I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo. Best wishes, Taco

Peter Münster

5:51 a.m.

On Mon, May 10 2010, Taco Hoekwater wrote:

...

I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo.

Hello Taco, There is not enough structure on the wiki. I imagine a script that exports parts of the wiki to tex, but additional information has to be entered in the tex-files (are arguments optional or not, etc.). BTW, how can I get automatic emails for every change in http://wiki.contextgarden.net/Reference/en/ ? Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

Hans Hagen

5:56 a.m.

On 10-5-2010 1:51, Peter Münster wrote:

...

On Mon, May 10 2010, Taco Hoekwater wrote:

...
I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo.

Hello Taco,

There is not enough structure on the wiki. I imagine a script that exports parts of the wiki to tex, but additional information has to be entered in the tex-files (are arguments optional or not, etc.).

that kind of info is already available in cont-en.xml Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Taco Hoekwater

5:59 a.m.

Hans Hagen wrote:

...

On 10-5-2010 1:51, Peter Münster wrote:

...
On Mon, May 10 2010, Taco Hoekwater wrote:

...
I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo.

Hello Taco,

There is not enough structure on the wiki. I imagine a script that exports parts of the wiki to tex, but additional information has to be entered in the tex-files (are arguments optional or not, etc.).

that kind of info is already available in cont-en.xml

as well as in the wiki (red syntax text indicates optional arguments) Taco

Taco Hoekwater

6:02 a.m.

Peter Münster wrote:

...

BTW, how can I get automatic emails for every change in http://wiki.contextgarden.net/Reference/en/ ?

You can only get emails for pages on your watchlist. To do that, log on to the wiki and go to 'my preferences', there is a heading with 'Email' settings on that page. Best wishes, Taco

Aditya Mahajan

1:50 p.m.

On Mon, 10 May 2010, Peter Münster wrote:

...

On Mon, May 10 2010, Taco Hoekwater wrote:

...
I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo.

Hello Taco,

There is not enough structure on the wiki. I imagine a script that exports parts of the wiki to tex, but additional information has to be entered in the tex-files (are arguments optional or not, etc.).

Maybe, we can have an infobox for the wiki pages, so we can say something like {{ Infobox command | name = setupframed | ... }} That way, it will be easier to export to TeX (no need to parse raw HTML). Aditya

Khaled Hosny

1:55 p.m.

On Mon, May 10, 2010 at 03:50:40PM -0400, Aditya Mahajan wrote:

...

On Mon, 10 May 2010, Peter Münster wrote:

...
On Mon, May 10 2010, Taco Hoekwater wrote:

...
I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo.

Hello Taco,

There is not enough structure on the wiki. I imagine a script that exports parts of the wiki to tex, but additional information has to be entered in the tex-files (are arguments optional or not, etc.).

Maybe, we can have an infobox for the wiki pages, so we can say something like

{{ Infobox command | name = setupframed | ... }}

It also makes editing the wiki much easier (using also wiki tables instead of HTML tables etc.) -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer

Taco Hoekwater

11 May 11 May

1:30 a.m.

Khaled Hosny wrote:

...

...
Maybe, we can have an infobox for the wiki pages, so we can say something like

{{ Infobox command | name = setupframed | ... }}

It also makes editing the wiki much easier (using also wiki tables instead of HTML tables etc.)

This is definitely true, but for the export there is a simple solution: export as xml, feed the output through Tidy, then process with mkiv's native xml support. Best wishes, Taco

Peter Münster

2:07 p.m.

On Tue, May 11 2010, Taco Hoekwater wrote:

...

...
It also makes editing the wiki much easier (using also wiki tables instead of HTML tables etc.)

This is definitely true, but for the export there is a simple solution: export as xml, feed the output through Tidy, then process with mkiv's native xml support.

Hello, It's not so funny to deal with the actual structure and make conversion tools like this: color=red -> optional parameter, <strong>...</strong> -> default value Also, the editing performance is much higher when using a good editor instead of html-wiki-forms. In order to be motivated to spend time on this project, I - don't want to get blocked by limits (e.g. wiki-limitations), that I cannot control - want to have a well designed structure: ergonomic for editing and beautiful (as Hans said: TeX seems to be a good choice) - want to use my favorite editor for writing the command descriptions At the moment, I don't really understand how to carry that out using the wiki... :( Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

Hans Hagen

10 May 10 May

5:54 a.m.

On 10-5-2010 1:13, Taco Hoekwater wrote:

...

Hans Hagen wrote:

...
...
So what about: - a new directory "http://foundry.supelec.fr/svn/contextman/context-commands" - one tex-file per command

If you agree, I just start.

let me think about it for a while (naming and such)

I would much prefer working on the wiki, then export to .tex with a script. Having two sources for what is essentially the same information is asking for trouble, imo.

sure. it's more an export question indeed (and what to export to) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

5190

Age (days ago)

5195

Last active (days ago)

List overview

Download

24 comments

9 participants

participants (9)

Aditya Mahajan
Hans Hagen
Idris Samawi Hamid ادريس سماوي ح امد
Idris Samawi Hamid ادريس سماوي حامد
Khaled Hosny
luigi scarso
Marius
Peter Münster
Taco Hoekwater