Provide ability to configure helptext maxWidth columns about argparse HOT 9 CLOSED

80 characters is a default terminal width, it has been standard for headless servers terminals for years and still is used everywhere.

FYI, if you don't use very long path and very long argument names, it will look perfectly fine.

I don't think this should touch existing help message formatting, otherwise it will break compatibility. Better option is to introduce override formatter, so that anyone can just provide their own formatting functionality if they wish so.

PRs are welcome for formatter override.

from argparse.

As far as I know, most help formatters query the terminal (If $ISTTY is true) to find the width, and use that.

from argparse.

@jkugler while that is correct, there are many cases when those fail to detect width correctly, where you will have then lines extending beyond the visible display area. And correct screen width detection is out of scope for this library I think.

I think would be good to have a way to configure help formatting in some flexible way. Current approach is a bit too tightly coupled with internals.

I think good backward compatible solution would be:

• Define interface that describes message formatter functionality (for example receive list of strings and produce a single formatted string)
• Extract current formatting methods into a type like SimpleFormatter that implements this interface
• Define this SimpleFormatter as default (that is -- it will be used unless explicitly overwritten)
• Define method for Parser to overwrite default formatter

from argparse.

I'd add a +1 to @jkugler 's terminal detection. Speaking from firsthand experience, I know how nasty working with the terminal can be, but it seems like both argparse and argparse4j do it so would definitely be very helpful in this Go port! :)

from argparse.

Python's argparse "cheats" as it uses a function from another module, but it does do it: https://github.com/python/cpython/blob/main/Lib/argparse.py#L170

from argparse.

@mieubrisse To clarify. This is not a port of Python's argparse. This library merely inspired by the usability of it.

The goal of this library is to keep it very simple to use, with no external dependencies.

There are many alternative libraries that do a lot more in CLI.

from argparse.

@akamensky I understand it's not a port. I was just pointing out that 1) the Python version does it, and 2) it does, in fact, rely on an external library, but it just so happens that "external library" is in its own stdlib, so it doesn't have to install anything extra.

So, in your case, unless Go's stdlib has something similar, yes, it would introduce an additional dependency.

from argparse.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs. Thank you for your contributions. Feel free to comment or otherwise update to keep it alive.

from argparse.

Closing due to old age. Feel free to re-open or ping maintainers.

from argparse.