Added the ability to use \n and/or \r in HelpText

[ericnewton76]

Issue by rupe120
Monday Jun 22, 2015 at 19:41 GMT
Originally opened as gsscoder/commandline#169

---

It would be helpful to be able to create more than one paragraph in the HelpText, for the instances where there is supplemental / conditional information to add.

I have a scenario where depending on the list of options supplied, a given option may have slightly different behavior and/or be required or not.

It tends to be helpful if the user can see clear separation between the default functionality of an option, and additional scenarios.

---

rupe120 included the following code: https://github.com/gsscoder/commandline/pull/169/commits

[ericnewton76]

Comment by gsscoder
Tuesday Jun 23, 2015 at 04:12 GMT

---

I've added comments to the PR #168 that you closed... This is the new version of the PR?
If yes, can I ask you to add a test relative to changes?

[ericnewton76]

Comment by rupe120
Tuesday Jun 23, 2015 at 12:22 GMT

---

Yes this is a new version, I apologize for the confusion and I will add a test

[ericnewton76]

Comment by gsscoder
Tuesday Jun 23, 2015 at 13:16 GMT

---

@rupe120, no problem... 👍 If you need to ask something, don't hesitate.

[ericnewton76]

Comment by rupe120
Tuesday Jun 23, 2015 at 17:08 GMT

---

Thanks! Will do

On Tue, Jun 23, 2015 at 9:16 AM, Giacomo Stelluti Scala <
notifications@github.com> wrote:

@rupe120 https://github.com/rupe120, no problem... [image: 👍] If you
need to ask something, don't hesitate.

—
Reply to this email directly or view it on GitHub
gsscoder/commandline#169 (comment).

[ericnewton76]

Comment by gsscoder
Tuesday Jun 23, 2015 at 18:15 GMT

---

So it's OK, I wait you test addition and if possible (and you've a time) a sample (side by side) of current help output and what you want to get.

Have a nice day!

[ericnewton76]

Comment by rupe120
Tuesday Jun 23, 2015 at 18:26 GMT

---

Np, the sample should be fairly easy

On Tue, Jun 23, 2015 at 2:15 PM, Giacomo Stelluti Scala <
notifications@github.com> wrote:

So it's OK, I wait you test addition and if possible (and you've a time) a
sample (side by side) of current help output and what you want to get.

Have a nice day!

—
Reply to this email directly or view it on GitHub
gsscoder/commandline#169 (comment).

[ericnewton76]

Comment by rupe120
Tuesday Jun 23, 2015 at 19:17 GMT

---

Hey guys, heads up on xunit. They've changed their runner and switched from an extension to a NuGet package http://xunit.github.io/docs/running-tests-in-vs.html

[ericnewton76]

Comment by rupe120
Tuesday Jun 23, 2015 at 19:29 GMT

---

The before and after

[ericnewton76]

Comment by rupe120
Tuesday Jun 23, 2015 at 19:31 GMT

---

btw, I actually removed \r from the processing because I thought it would be confusing to see \r\n and actually receive 2 lines. While I did want \n\n to give you 2 lines, the distinction would be more logic then I felt necessary. So I just eliminated the \r

[ericnewton76]

Comment by indigotock
Tuesday Jun 23, 2015 at 23:49 GMT

---

Would using Environment.NewLine not be better?

[ericnewton76]

Comment by gsscoder
Wednesday Jun 24, 2015 at 03:51 GMT

---

@indigotock, yes, is also consistent with the rest of HelpText class. @rupe120, can you do this last change to your PR, please?

(If you've done in it, please forgive me, have you verified if after the change all tests are green?)

Ping me when you're done, I'll fetch the PR locally to proceed.

[ericnewton76]

Comment by rupe120
Wednesday Jun 24, 2015 at 12:31 GMT

---

Ok so, I agree that we need to keep everything consistent. On the other hand, I'm seeing this context as being different from the other places where Environment.NewLine is used. For all other places in the code the Environment.NewLine reference is used in the background to create the string that will be fed to the console. In this instance our interface is between the developer in what they have typed for help text and the help text processing, instead of the help text processing and the console.

If I use the Environment.NewLine instead of a raw \n then the users will need to use Environment.NewLine in their help text strings as well. It seems to me that using \n will be an easier interface for the developer to use.

Thoughts?

[ericnewton76]

Comment by rupe120
Wednesday Jun 24, 2015 at 12:38 GMT

---

With that said, I agree that there should be a comment next to the .split() call that uses \n explaining why the break in pattern because anyone else looking at the code will have the same question.

[ericnewton76]

Comment by indigotock
Wednesday Jun 24, 2015 at 12:38 GMT

---

I think that users implementing new lines "incorrectly" is something which shouldn't be counted on by the library? Quite interested to hear other peoples' opinions on this. Perhaps there could be an enum flag which allows the author to specify the new line sequence? Something like

enum NewLineStyle{
    LineFeed,
    CarriageReturnLineFeed,
    EnvironmentNewLine,
    Any
}

Although this feel a little bit over-engineered

[ericnewton76]

Comment by rupe120
Wednesday Jun 24, 2015 at 12:42 GMT

---

Though to do this "correctly" would make for more awkward HelpText creation, either using String.Format() or concatenation