Hi Pádraig, others, Thanks for the heads-up, and for this work!
> tl;dr with the attached you can follow links from: src/ls --help I love this feature and would love to see more utilities adopting it (not just within coreutills but much more broadly). Although, as one of the key people in implementing and popularizing the weblink feature of terminals, I am definitely biased :) > Having each --option hyperlinked also gives a visual distinction > between the --option text and description, which makes --help > quite a bit easier to read IMHO. Speaking of visuals, you've also changed the affected text to have bold typeface. I have mixed feelings about it. On one hand, I really like the resulting visual look. On the other hand, it shouldn't be necessary, terminals _should_ somehow denote if the given text is a hyperlink. Which means: I'd love the bold typeface feature if it was independent from the hyperlink, as in: independent decision to wish for that look, not for the sake of emphasizing the hyperlink, and preferably a separate commit. I wouldn't like it that much if its purpose was to emphasize that the given text is clickable, that's the terminal's job to pick a certain look for that. > We only output --option links if stdout is a tty currently, > though it would be nice to support piping to e.g., less -R. > Perhaps keying on stdin would be better then, or maybe support --help[=WHEN], > though options on --help do seem like overkill. I understand your dilemma and it's surely not an easy question. Another possibility is to piggyback on the existing --hyperlink feature. This way existing aliases (e.g. alias ls='ls --hyperlink') would work. But this also takes us to the question of the _default_ value. Currently ls defaults to no hyperlinks when listing regular files, but (with this patch) to do use hyperlinks in --help. Would you prefer to keep it this way? I think if the main operation doesn't use hyperlinks or colors by default (it's left for aliases to enable them) then it's reasonable for --help to follow that, too. Also, using bold typeface isn't subject to --color in --help, that's another inconsistency between --help vs. real operation. It would be preferable to find a solution that scales well to other tools, including non-coreutils ones, e.g. grep with its already existing --color similarly to ls. I don't have a firm opinion what would be a great solution here, but I think reusing --hyperlink (or introducing it to other tools) might be a viable option. But then again, _if_ you choose to go bold too, then would you need two options (--hyperlink=... and --color=...) to turn on/off them both? Doesn't sound that great. Surely a single option controlling them would be better. > This will result in each option being translated separately. > That seems better anyway, and is something we've already been > gradually adjusting to over the last few years. > Many of the existing translations will not need to change. Would it be reasonable to split existing translations in a (semi-)automated way, so that translators don't have to manually do this (and possibly introduce new wording)? > I've not looked into propagating these URLs to man pages. > It would be useful if man pages did support it, but after a very > quick search it seems that they might not, which is fine but a pity. Man pages do support weblinks, see https://lists.gnu.org/archive/html/groff/2021-10/msg00000.html grep for \X'tty in your manuals, e.g. dig(1) / nsupdate(1) have links to RFCs in their SEE ALSO section, just to randomly pick one out of maybe a handful of matching packages on my system. e.
