Add longoptions support for gmtconvert

[rbdavis]

Description of proposed changes
Add longoptions support for gmtconvert

Python differences:

No python module found.

Julia differences:

Changed range (-Z) to transpose.
The gmtconvert manual page -Z documentation says
nothing about range.

Fixes #7952

Reminders

• Make sure that your code follows our style. Use the other functions/files as a basis.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Describe changes to function behavior and arguments in a comment below the function declaration.
• If adding new functionality, add a detailed description to the documentation and/or an example.

[joa-quim]

Thanks for the -Z catch. A mistake for sure. As I said in another PR range is for those -T's

[PaulWessel]

What to do about -T[d][h][selection]? We have two directives that both could be set, e.g. -Tdh, Dont think we can say --suppress=headers,data, or perhaps we can? If not, we could do a backwards compatible syntax change and turn one or both directives into modifiers +d and +h? Also, selection might be better as columns? Comments, @GenericMappingTools/long-options-review ?

BTW, I merged in 21 commits from master.

[joa-quim]

--suppress=headers,duplicates looks fine to me.

[PaulWessel]

--suppress=headers,duplicates looks fine to me.

Done.

[PaulWessel]

@rbdavis please check that I did the short and long directives for -T correctly.

[remkos]

I would suggest to have --select_number as an alias for --select_num.
Same for --select_header as an alias for --select_hdr

[PaulWessel]

I would suggest to have --select_number as an alias for --select_num. Same for --select_header as an alias for --select_hdr

Agreed and done.

[joa-quim]

In that sense, I would even drop the --select_num (I'll change it GMT.jl too). Regarding --select_hdr this one I think is fine to keep alongside --select_header. Using hdr to mean header is a very common practice in coding.

[PaulWessel]

OK, so just --select_number then?

[PaulWessel]

and the two aliases for headers

[joa-quim]

For me, yes

[PaulWessel]

Wait a minute. Reading -Q and it takes about a series or range of segments that should be written. I think --segments is much more to the point. select_num|select_number is not clear that these are segment numbers. So --segments=1,2,11 is much clearer, no?

[joa-quim]

Yes, clearer.

[rbdavis]

Dont think we can say --suppress=headers,data, or perhaps we can?

We most definitely can NOT do this with the current parsing code. (I just tested to confirm.)

I have encountered a substantial number of options in various modules with similar structure, i.e., there are attribute-ish flags (i.e., NOT +x modifier flags) where immediately following the short-option the user may specify more than one such attribute flag in any order such as gmtselect's -I[cflrsz] option, e.g.,

% gmtselect -Ircz

So, I can certainly see how it would be a nice feature to be able to longoptify such choose-any-or-all-type attributes. However, enhancing the longoption translation code is always an adventure in discovering which of the zillion variations in existing GMT option syntax will be broken by doing so. In this case, anything that currently uses a comma character would be at risk, and in fact the comma already has particular importance for longoption translation as a special separator character between option groups in certain cases.

Paul's suggestion to change such option flag sets to a collection of modifiers, e.g.,

% gmtselect -I+r+c+x

which could then be longoptified as

% gmtselect --invert+rectangle+circle+zrange

would certainly work, although presumably you would want to both preserve the existing syntax, e.g., -I[cflrsz] , as well as add the new modifiers.

[PaulWessel]

Ok will give this one more thought

[PaulWessel]

This needs the new multi-directive scheme I think?

[rbdavis]

Yes. I will be re-examining all longoptified modules completed so far for possible application of this new translation feature. Probably amount to maybe one out of every six to ten? Workplan for this week, probably starting Wednesday (after all outstanding longoption string group review PRs are closed): (1) Modify translation tests to accommodate group review of the last batch of PRs. (2) Submit one PR for new bitmask field update of all *_inc.h files for your review only (no string changes). LMK if you would like me to break this up into multiple PRs due to the number of *_inc.h files, but preferably no more than 3 or so? (3) Revisit already-longoptified modules for multi-directive stuff, with PRs for group review (new strings). (4) Resume per-module longoptification as before with group reviews. Roger

…

This needs the new multi-directive scheme I think? -- Reply to this email directly or view it on GitHub: #7953 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>