-
Notifications
You must be signed in to change notification settings - Fork 482
Open
Labels
Description
The command line wiki shows what help texts look like:
yourapp 2.0.201-alpha
[...]
--filename Input filename.
--help Display this help screen.
--version Display version information.
Each argument entry is followed by a double end of line. I wondered if there is a simple way to get a formatting with single eol, like this grep
example:
Usage: grep [OPTION]... PATTERN [FILE]...
[...]
-E, --extended-regexp PATTERN is an extended regular expression (ERE)
-F, --fixed-strings PATTERN is a set of newline-separated strings
-G, --basic-regexp PATTERN is a basic regular expression (BRE)
If I undestand correctly, I'll have to implement my own help screen and use HelpText.RenderUsageText
or HelpText.RenderUsageTextAsLines
?
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
moh-hassan commentedon Oct 20, 2019
You need not to use Rendering methods, only configure HelpText and set:
Wiki is updated to include new page: HelpText Configuration for generating custom help with examples that you can run online.
Custom helpExample: Try it online
downwater commentedon Oct 20, 2019
Thank you very much.
leoformaggi commentedon Dec 13, 2019
Is there a way to cut the empty lines from Default parser? Using the HelpText it works, but there's a different behavior. I am using a method for parsing subverbs, which works fine. If I use a single --help with Default parser, it shows the available verbs. But if I use HelpText.AutoBuild() setting AdditionalNewLineAfterOption = false, the single --help command won't show the available verbs.
downwater commentedon Dec 17, 2019
@moh-hassan, I confirm this works (tested with VB.NET).
moh-hassan commentedon Dec 17, 2019
@downwater
Thanks for feedback
moh-hassan commentedon Dec 17, 2019
@leoformaggi
Can you post sample code to repro the issue.
downwater commentedon Dec 17, 2019
@moh-hassan, I just realized I'm experiencing the same issue as @leoformaggi , but I didn't yet dig into it. I started from your sample to write the one below to show up the case:
Calling the program with
--help
will ouput this:moh-hassan commentedon Dec 22, 2019
@downwater, @leoformaggi
Custom Help for Verbs need accessing internal members.
I investigate the possibility of modifying these members to be public.
downwater commentedon Dec 22, 2019
@moh-hassan, thank you for this first feedback.
moh-hassan commentedon Jan 1, 2020
@downwater, @leoformaggi
Custom help for verb is fixed in v2.7.0-preview1 by adding a new overload method to AutoBuild and DisplayHelp is simplified
Try it online
Click to expand source code!
Click to expand Help Screen!
downwater commentedon Jan 1, 2020
@moh-hassan
Thank you for the information. We'll be waiting for the stable release.
downwater commentedon Jan 7, 2020
@moh-hassan, using the current release (2.7.82) and following the new code sample, it works.
A last detail though. If the description of a parameter is longer than the console width, it returns to the line of course, but after two line feeds:
moh-hassan commentedon Jan 7, 2020
@downwater
Thanks for feedback,
The new overload method has a third parameter maxDisplayWidth which is 80 by default.
Try to expand it to fit your width
downwater commentedon Jan 7, 2020
@moh-hassan
Thank you for your answer.
I don't really understand (sorry), I was talking about word wrap. The HelpText object succeeds to perform word wrap with a correct left indentation, but adds an extra newline.
Increasing
maxDisplayWidth
formats the output as below:leoformaggi commentedon Jan 9, 2020
@moh-hassan I tested release 2.7.82 and it solved my problem like a charm. Thank you for the update.
moh-hassan commentedon Jan 9, 2020
@leoformaggi
Thanks for feedback and I appreciate your effort in testing v2.7.82.
moh-hassan commentedon Jan 9, 2020
@downwater,
I checked the help in this demo with addin a newline \n in middle of string and using large and small size and it's working fine.
If there is an issue with double new lines, you can provide a test case with xunit that repro the issue, and what is the device you are using and its width, Full framework/netcore and OS: windows/linux/..
downwater commentedon Jan 14, 2020
@moh-hassan,
After several tries, the first issue seems to reproduce if the following conditions are fulfilled:
sbw
and a verb help textstr
,maxDisplayWidth = sbw
str.charAt(maxDisplayWidth + 1)
is a blank" "
character.To reproduce:
Define a verb with the given help text (with the very string value):
Define a HelpText as below:
Run with
--help
in a command prompt window, with width sized to 80; you can run it with Visual Studio and adding a break point right before the Console.WriteLine() call to set the buffer width on the fly.Tested with Visual Studio 2010 on Windows Server 2008 Entreprise SP2 and Command Line Parser 2.7.82.
moh-hassan commentedon Mar 18, 2020
@downwater
It seems that the boundary of 80 column cause this issue
Try to resize the console to column width: 81 by the command
I couldn't catch this issue in xunit test.
@NeilMacMullen
Kindly, can you help in fixing this issue.
NeilMacMullen commentedon Mar 18, 2020
@moh-hassan I believe the issue occurs because TextWrapper.WrapAndIndextText treats the supplied number of columns as the number available for non-whitespace but then appends a newline when converting back to a single string so in the case that we've wrapped to N columns and the line is exactly N characters long, the additional newline will push it to N+1 and the console behaviour is to wrap the line at the Nth character and "display" the newline on the following line. There are are a few alternate fixes:
change the columnWidth calculation in TextWrapper.WordWrap to allow an extra character for the newline....
columnWidth = Math.Max(1, columnWidth-1); //subtract 1 to allow for newlines that will be added when converting back to a block of text
Unfortunately this changes the documented (in the comments) semantics of the call and some of the unit tests which assume that the number of columns being passed in are for non-whitespace so if you go this route you'll need to fix up a few things.
change the call sites for TextWrapper.WordWrap to subtract 1 from the available column-width (both calls are in HelpText.cs) This is also likely to break a few unit tests which make the wrong assumption about MaximumDisplayWidth being the number of characters available for non-whitespace.
Modify the setter/use of MaximumDisplayWidth to make it clear it is is the number of columns that can be used for text rather than the screen width.
Unfortunately I'm too busy to fix this myself but my suggested fix would be option 1 which is a trivial code fix that just requires some tedious test changes. Note though that TextWrapper is not the only thing that formats text and it's possible things like the copyright display also suffer from this problem.
moh-hassan commentedon Mar 18, 2020
Thanks @NeilMacMullen for reply and suggestions.
I appreciate your time and I will investigate your suggestions including the other possible things that may be the cause and feedback the result.