Hi,
> if (STREQ_LEN (option_text, "--help", 6) > || STREQ_LEN (option_text, "--version", 9)) That wouldn't recognize unique abbreviations as accepted by getopt, e.g. "--hel". Better handle it in the actual handler of that option. > Anyways, one more thing I'm curious about. Should HELP_NO_SGR be named > to something a bit more friendly? I did not know what SGR meant until I > looked it up. I assume it might have been influenced by groff's GROFF_NO_SGR, but I agree that it's way too technical and not that user friendly. It's also not only SGR. SGR (Select Graphic Rendition) is the family of escape sequences that modify per-cell rendering properties, such as colors, bold, italic, underlined etc. OSC (Operating System Command) is another family, controlling OS-related stuff such as the window title, or the concept of the working directory in order to open a new terminal in the same dir. Hyperlinks is a bit weird hybrid. It's the first OSC controlling a per-cell property and not a global one. SGR could have perhaps been a better choice in the sense that it's per-cell, although hyperlinks are not about graphical rendition but an OS-related functionality. So there's pros and cons for either choice. OSC was chosen purely for syntax reasons: SGR's syntax doesn't allow URLs to be included (or it would be extremely cumbersome, like encoding each byte in decimal). GROFF_NO_SGR has a reason to defend the use of the word "SGR" where in fact it stands for both SGR and OSC 8: This env var has existed many-many years before OSC 8 support was added, or even OSC 8 itself was invented. For a new utility where it turns off both SGR (bold typeface) and OSC (hyperlinking functionality), I think coming up with a brand new, user-friendly name would be a better choice than following groff's example. e.
