On Sat, Jul 17 2010, luigi scarso wrote:

Why don't put them into a table as is in http://www.lua.org/pil/10.1.html For exampl e placefloat.lua should be placefloat ={ props = { [...]

Because I like to avoid redundancy. It's easy to do things like this automatically: local placefloat = {} setfenv(0, placefloat) dofile("placefloat.lua") setfenv(0, _G) print(placefloat.props.fixpart) Or like this: placefloat.lua: entry = { -- or "command" props = ..., args = ..., ... } And then: local commands = {} dofile("placefloat.lua") commands.placefloat = entry (or command) print(placefloat.props.fixpart) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

On Sat, Jul 17, 2010 at 21:32, Peter Münster wrote:

On Sat, Jul 17 2010, luigi scarso wrote:

...

Why don't put them into a table as is in http://www.lua.org/pil/10.1.html

Ok, now one file defines exactly one "command" table.

For my taste this is better as well. A few random comments from externalfigure: - Despite the fact that the command name is known from filename, wouldn't it be nice to have externalfigure string defined somewhere? - It is not really needed, but it helps when cross-referencing: I would nevertheless leave the [1] = {...}, [2] = {...} for arguments - The following: settings = { inherit = "useexternalfigure", -- n = 3 not needed, since one command has only one settings-option }, is a bit weird to me. Why not putting the "inherit" already under arguments above? And yes, you probably do need to tell from which argument of \useexternalfigure you want to inherit the settings. - If all the three arguments are optional, it's a bit difficult to tell what combination of arguments is allowed, so it might make sense to be a bit more verbose in that (to tell somehow that for example only 123 and 23 and 3 is allowed, but not 13 for example), but this is not too important. Mojca

On Sun, Jul 18 2010, Taco Hoekwater wrote:

arguments = { ["label_arg"] = { type = label, }, ["filename_arg"] = { type = file, }, ["settings_arg"] = { type = settings, comment = "short comment for this option", description = "long description for this option", inherit = { "useexternalfigure", 'settings_arg' }

}, ["parent_arg"] = { type = parent, comment = "short comment for this option", description = "long description for this option" }, }, variants = { -- just an example { "filename_arg" }, { "label_arg", "filename_arg" }, { "label_arg", "filename_arg", "settings_arg" }, { "filename_arg", "parent_arg" },

} },

but I am not sure this is really better ?

Seems to be ok for \externalfigure but not for \setupheadertexts... Peter -- Contact information: http://pmrb.free.fr/contact/

On Sat, Jul 17 2010, Mojca Miklavec wrote:

> A few random comments from externalfigure:
> - Despite the fact that the command name is known from filename,
> wouldn't it be nice to have externalfigure string defined somewhere?

Ok, see response to Taco.


> - It is not really needed, but it helps when cross-referencing: I
> would nevertheless leave the [1] = {...}, [2] = {...} for arguments
> - The following:
>     settings = {
>         inherit = "useexternalfigure",
>         -- n = 3 not needed, since one command has only one settings-option
>     },
> is a bit weird to me. Why not putting the "inherit" already under
> arguments above? And yes, you probably do need to tell from which
> argument of \useexternalfigure you want to inherit the settings.

>From my very small ConTeXt experience, I made some assumptions:
- one command has no more than one settings-option (key-val-pairs)
- one command has no more than one keywords-option

If this is true, then there is no problem with cross-referencing.
The n = X would be even difficult, when there a variants: imagine,
\useexternalfigure can have settings at n = 2 or n = 4 and so on.

And I like the separate settings-table, because it can be very big and
would clutter the arguments table.

If my assumptions are wrong, then there will be more problems:
perhaps the settings must go into the arguments table or we need a lot of
numbering (n = X here and there).


> - If all the three arguments are optional, it's a bit difficult to
> tell what combination of arguments is allowed, so it might make sense
> to be a bit more verbose in that (to tell somehow that for example
> only 123 and 23 and 3 is allowed, but not 13 for example), but this is
> not too important.

I think, there has to be some introduction chapter for the user with the
general rules in ConTeXt-commands. I suppose these rules:
- when a command has an optional keyword-option and an optional
  settings-option and you use only one of them, you don't need a
  placeholder (empty bracket pair)
  example: \setupitemize[packed] or \setupitemize[start=5]
  (context is intelligent here)
- context cannot distinguish between label and keyword, so if you want to
  use a label in \placefloat, you must add a placeholder for the keyword

Hans can tell us perhaps more about these rules...

Furthermore, we can add in this introduction some notes about spaces:
- space is allowed between 2 bracket options
- space is allowed after a comma
- space is not allowed before and after the =
- space is gobbled after ] if not all optional arguments are used

Cheers, Peter

-- 
Contact information: http://pmrb.free.fr/contact/

On Sun, Jul 18 2010, Mojca Miklavec wrote:

I didn't understand the last paragraph, but while it's not a problem for a human to determine where to inherit from, it might be a problem for a computer if you want to print the complete command.

There is no problem for a computer, it's just jumping from the settings of \externalfigure to the settings-table of \useexternalfigure. Peter -- Contact information: http://pmrb.free.fr/contact/

On 07/17/2010 09:32 PM, Peter Münster wrote:

On Sat, Jul 17 2010, luigi scarso wrote:

...

Why don't put them into a table as is in http://www.lua.org/pil/10.1.html

Ok, now one file defines exactly one "command" table. I added also other minor enhancements.

If you start your files like this: command = command or {} command['placefloat'] = { comment = "Insert a floating element.", ... } then they could easily all be merged into a single command table during loading or even via 'cat'. Like Mojca says, it is better not to be dependent on the file name, and also it is more efficient to have a single lua file than 500-600 separate ones. There is no need to combine them immediately, but if this goes into the distro at some point then a single large file is definitely better than lots of smaller ones. Best wishes, Taco

On 18-7-2010 8:09, Taco Hoekwater wrote:

On 07/17/2010 09:32 PM, Peter Münster wrote:

...

On Sat, Jul 17 2010, luigi scarso wrote:

...

Why don't put them into a table as is in http://www.lua.org/pil/10.1.html

Ok, now one file defines exactly one "command" table. I added also other minor enhancements.

If you start your files like this:

command = command or {} command['placefloat'] = { comment = "Insert a floating element.", ... }

then they could easily all be merged into a single command table during loading or even via 'cat'.

I'd rather go for this (see lfg file for examples): return { name = "placefloat", version = "1.00", comment = "Insert a floating element.", } and give the files names like placefloat.cid (context interface definition) and then load them using a lua script (this also permits us to load several definitions named placefloat e.g. for comparison of versions). Another aspect is shared definitions. Settings like style and align are often shared so there we need a way to refer to that like align = interfaces.resolve("align"), and so. In a similar way inheritance can be dealt with. I'm not sure what the final purpose of this exercise is (intended usage and so), but if it's to be integrated (or loaded in context) it has to fit in the general way such data is stored. In that case I have to make a loader (in the interfaces namespace), one that probably drops not needed data, and caches relevant info for runtime usage. Also, as I cannot drop the xml counterpart now so I need to be able to generate that file from it as I don't want to keep that (also mkii) downward compatibility aspect (once the lua format is known I can do the reverse as exercise), so we need at least the level of detail from the xml file, including value types and (this cd:number tagging). So, given this thread .. can we summarize the state of a couple of commands? Say: - setupframed (inherited) - framed (inherits, resolving) - setupheadertexts (several arg configurations) - externalfigure (several arg configurations) - itemize (start command) 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 -----------------------------------------------------------------

On Sat, Jul 17 2010, Hans Hagen wrote:

- props -> properties (or whatever, but no shortcuts)

No more needed.

- args -> arguments

Done.

- [=[ looks rather bad but anyhow, examples should probably not be done this way (examples can be go into tex files)

Ok, why not! Peter -- Contact information: http://pmrb.free.fr/contact/