Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

truncate default args in help menu #202

Closed
VVX7 opened this issue Jan 16, 2022 · 5 comments
Closed

truncate default args in help menu #202

VVX7 opened this issue Jan 16, 2022 · 5 comments

Comments

@VVX7
Copy link

VVX7 commented Jan 16, 2022

Is there an option to truncate default args? I have a tool with long default args (URLs) that break the help menu formatting. I looked through the config and docs but I didn't see such an option.

@c-blake
Copy link
Owner

c-blake commented Jan 16, 2022

This comes up a lot. I should probably put it in the README.md or start an FAQ/frequently encountered problems on the Wiki.

What I generally recommend is that you default to a special value, such as empty string "" or "default" and then test against that special value inside your wrapped proc as in:

  let uri = if uri.len == 0: longDefault else: uri

And (maybe) document the long default in the per-parameter help string, possibly with a user-friendly conceptual abbreviation like "uri of first google result for xyz".

About the only thing better than this would be obviously type-specific word-wrap (e.g., in TeX you can put in a soft-hyphen to guide word breaking, or sometimes with set[SomeEnum] the set already has a lot of natural word breaks.

I don't mean to distract, though. The problem is actually less the wrapping for which there are always at least heuristic "any punctuation" breaks. It is more the logical/coding complexity of formatting "multiple horizontal cells in the table wrapped to multiple rows". If you wanted to take a crack at making cligen/textUt.alignTable smarter in this regard then we could work on the rest together.

At a minimum it seems one needs multiple passes to even figure out how tall each row is and how wide with the wrapping. But if the multiple columns are wrapped you probably need another pass on top of that. It's all kind of a mess. Once you have multiple columns wrapped, you also need a better "language" to express allocation of widths to columns (like fractions of the terminal width, say). Anyway, there may be some simple "overall metric" with some dynamic programming algorithm. But this is all so complex compared to defaulting to empty string that I never sat down to really try to do it.

It is also possible to make the default value the final column in the help table by re-ordering the columns of the help table the way test/HelpTabCols.nim does. This gives you more, but still very finite "width real estate".

@c-blake c-blake closed this as completed Jan 16, 2022
@c-blake
Copy link
Owner

c-blake commented Jan 16, 2022

Oh, and of course, you can also kill the entire default value column if you want in a way just like re-arranging their order as in test/helpTabCols.nim.

Most CLI engines don't tell you the type at all - just leaving it as "understood". So, if killing that happened to give you enough room then you wouldn't have to break things like auto-complete based on emitted help in Bash/Zsh/etc.

@VVX7
Copy link
Author

VVX7 commented Jan 16, 2022

Thank you! Appreciate the detailed response. The ternary in the wrapped proc makes sense.

@c-blake
Copy link
Owner

c-blake commented Jan 16, 2022

You're welcome. Detailed responses are my style. I know URIs can be just huge. You can get a little extra room per line if you flip the clause order and also chain together multiple strings like:

if uri.len > 0: uri
else: "1" &
  "2" &
  "3"

@c-blake
Copy link
Owner

c-blake commented Jan 16, 2022

At least one recent issue with the same question - just for reference of issue searchers: #190 and a somewhat related pre-formatting "trick/heuristic": #109

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants