Cysharp
Long help text descriptions do not wrap with correct indentation.
Not sure if this varies across shells, but if I have a large amount of text in the <summary> tag (not even accounting for raw XML stuff like #231), then the description wraps around to the next line, but the indentation does not actually bring it into alignment with whichever column the description started being rendered at. So, you get something like this:
Options:
-m, --message Displays a message. The messages may vary depending on the
scope of the message text.
--twice Displays the message two times.
Instead, I would've expected something like this:
Options:
-m, --message Displays a message. The messages may vary depending on the
scope of the message text.
--twice Displays the message two times.
I was using pwsh.
Controlling it to that extent is outside the scope of a CUI execution framework, I think, since it doesn't govern the rendering. What do you think?
I mean, the fact that it word-wraps automatically is already evidence that it participates in contributing to rendering. In order for me to make it render in the way one would generally expect it to, I have to add in an extra 8 spaces in my XML comment manually to "hack" it into performing the expected behavior.
I think you would be correct if I were just providing my own raw string literal and could choose between multi-line strings with triple quotes vs. other string literal techniques so I have full control and the framework just passes it through. But because you derive the rendering behavior from analyzed XML comments, I don't have rendering control and am forced to delegate it through whatever thin pipeline the CUI execution framework offers. As a result, it feels like it's seizing the scope of work from my purview, if that makes sense.
@willnationsdev If you want to display the lines correctly in on your PC, you indeed need to hack it. Where the lines wrap depend on the buffer width of the current terminal session, if you resize the terminal or use a different screen it will wrap in different places or not wrap at all if there is enough buffer width.
As the output is a simple string it is unaware of the actual buffer width thus it can't control if and where the text wraps.
Oh, I see. Yeah, that makes things a lot more complicated, and not really something this framework could "solve" in a reliable way then.
I suppose most programs then either explicitly avoid going over 80 characters as a convention or insert their own newlines, not relying on word wrap at all, in order to achieve the look they want?
@willnationsdev 80 characters used to be an unofficial "max-length" for code lines, my previous workplace even forced it in code as well as even emails.
With that said, today people use CLIs in split-windows, which makes the bufferwidth very small, and may even use ultra wide monitors which makes it very big.
I think trying to acheive a look is pointless, as the better it looks on one case, the worse it look on the other. Personally I think you better just try to make the descriptions as concise as possible and leave it at that.