Explore adding long-format GMT options#230
Conversation
This branch is work in progress on adding long-format option parsing to GMT. E.g., --region=w/e/s/n instead of -Rw/e/s/n, --registration=pixel instead of -r, and so on. At the moment only the common options and their most basic forms have been implemented, as well as local options for blockmean. I will write more later about how this all works and what is required to be added to each module - blockmean.c static variable local_kw shows how.
|
Sorry, got formatted. The general thing I am parsing is of the form
which will represent the vast number of module options. |
Update long-syntax for -U and -s.
Merge from master missed the new NULL argument..
Needed to split parsing of options that are given as a series of arguments separated by slashes (e.g., xinc/yinc) or commas (e.g., input columns).
The -T and -C are dealing with the same issue: The text bounding box atrributes. I have combined these with -T now being a modifer +t<shape> under -C. Tests pass, documentation has been updated.
No point having this since this is a separate branch for testing anyway.
Added code to handle multi-section arguments such as --increments=30+e/50+n
Improve the documentation of the new gmtinit_kw_replace function that converts long-format GMT options to standard short-format options.
|
I've suffered a lot with this in the Julia wrapper too, and still have issues. Basically, I find the axes and frame definitions confusing and never remember it clearly without revisiting the -B docs. -Bafg is a frame setting (but where afg is generically presented as a axes), but selecting selecting one of them, e.g. -Bx becomes a axis setting. |
|
No, -Bafg is an axes setting, not frame. The two are clearly separated and described in our long -B page. |
|
Right, but look at this. The first option in a frame is called axes
|
|
Right, but that should actually say axis. i.e., either x, y, or z. The --frame option should specify which axes (--frame=west,south) while the --axes option should specify information about specific axes. |
|
Sorry, I am wrong on that. Yes, the frame setting specifies which axes you want, then the axis setting deals with its settings. Perhaps we use --axis=x+ticks=afg or something. |
|
|
|
Yep. Well, I will experiment with something that works for the command line. It does not have to be identical to your solution. Since -B is broken into frame plus one or more axes calls I need to match that with the long-options as well. |
Better docs for code, longer variables, fixing some bugs.
|
It will continue to be challenging to let people place "+x" strings as part of a longer title or string argument, such as the
I think using +p for those strings you do now want parsed as modifiers is the simplest. I have checked and the string inside C will have the + and hence we can simply (and temporarily) replace + with two non-text ascii codes, process things, and then if those two codes are present, adjust the text by removing the first and replacing the second with +. |
|
Improved further. Added the --axes keyword to deal with axes and let --frame just deal with frame settings. ANy label/text that contains +? sequences that should not be seen as modifiers must be escaped with a backslash and the entire string must be quoted. WIth that, these work for me: The --axes=x:agf follows the general longname=[directive[:arg]] general template since there are many GMT module options that requires this scheme, regardless if we decide to do --xaxis instead. |
--frame=axes sets which axes to draw, and --axis specifies the settings of an axis.
seisman
left a comment
There was a problem hiding this comment.
Looks good to me. Add one test before merging?
|
OK, will do that before committing. Wait, this requires a compilation switch so I dont think we easily can unless you want to add to the CI setup for master. Otherwise the long-parsing is deactivated. |
|
Let me know if you can add those statements to the CI cmake config file and then we could add a test or two to the master branch, @seisman. |
|
@PaulWessel Now you can add long-option tests to this branch. |
|
@PaulWessel The long-option test fails due to the timestamp of the -U option. |
|
I guess we cannot really have the time-step in these tests as it changes. I will remove it. |
Includes the packaging dependency and IPython listed as optional. Create the environment and install dependencies in a single command. Set the conda channel preference order before anything else. Include sphinx and docutils as testing dependencies (GenericMappingTools#226).
This branch is work in progress on adding long-format option parsing to GMT. E.g., --region=w/e/s/n instead of -Rw/e/s/n, --registration=pixel instead of -r, and so on. At the moment only the common options and their most basic forms have been implemented, as well as local options for blockmean.
I will write more later about how this all works and what is required to be added to each module - blockmean.c static variable local_kw shows how. Basically, for each short-format option we need to supply the corresponding long-form names. Many GMT options support modifiers of the form +[ which in long form will be +[=]. Finally, many GMT options have a directive character immediately following the option key and these will become [:] in long form. Thus, what is parsed and converted to short-format options are optinos like
--longoption[=[:]][+<mod1[=]][+<mod2[=]]...