Clicking on long, wrapped links in mc manuals takes to the wrong place #4963
Description
Is there an existing issue for this?
- I have searched the existing issues
Midnight Commander version and build configuration
4.8.33, gitOperating system
.Is this issue reproducible using the latest version of Midnight Commander?
- I confirm the issue is still reproducible with the latest version of Midnight Commander
How to reproduce
Many terminals automatically detect URLs on their display, and allow a convenient way (often Ctrl+click) to open them.
mc's man pages end with a few long(ish) URLs.
If the terminal isn't wide enough and they get wrapped, trying to open them opens the fragment which happened to be rendered in the first line.
It's also a bit cumbersome to copy-paste such wrapped URLs to the browser.
Luckily, there's an extension to solve this problem. Quite a few terminals support the OSC 8 escape sequence to create web-like hyperlinks in the terminal. This escape sequence is supported by groff 1.23 and less 580 (although not without a bug, see below).
As per the groff announcement, the feature is disabled by default, you need to enable it in /etc/groff/man.local. At least Debian (and thus its derivatives too) patch it to enable by default, which is a pretty large user base. If I manually disable there, the feature still works for me, so there's more to this enabling-disabling story than this, which I haven't investigated.
When using this feature (making the URL text explicitly a hyperlink to the same URL), the first line of a wrapped URL becomes a hyperlink to the page. That is, Ctrl+clicking (or whatever way the terminal offers) on the first line opens the desired page, not a truncated URL.
Unfortunately, due to the interaction between groff (which emits a single run of URL spanning across multiple lines) vs. less (which expects all the SGR and this OSC attributes to start from the default state at the beginning of every line), subsequent lines of the URL can't be clicked. But it's up for them to fix one day, and even despite this bug, having a portion of the URL clickable and taking you to the right place is already a strong improvement.
Technically, just like on web pages, the displayed text could differ from the URL, as seen e.g. in the dig and nsupdate manuals pointing to some RFCs. I do not recommend that here though, because either groff or the user's terminal might be lacking this feature, and in that case we want the URL to be shown.
For the same reason, I don't want to eliminate the space in front of the sentence's full stop. When every component supports this feature, it would be safe to get rid of that. When not, and we revert to the terminal's URL auto-recognition, which isn't smart enough to exclude that in some terminals, it's useful to keep that space there.
What if such a manpage with explicit hyperlinks is viewed within mcview? Short answer: no improvement there, but luckily no regression either.
mcview invokes groff/grotty with the legacy compatibility -c option which emits bold and underlined text using the backspace + overstrike technique, rather than the modern output format using SGR and OSC. That's because mcview is only able to parse that legacy format, not the modern one.
As documented in groff's announcement, in this mode such hyperlinks as meta-info are simply omitted. That is, mcview sees the very same formatted file as prior to this suggested improvement.
If one day we implement SGR support in mcview (which would probably need an underlying screen library that supports direct colors without the need for a pre-set palette, which neither ncurses nor slang do) then we'll surely be able to easily add OSC 8 hyperlink support as well.
Expected behavior
.
Actual behavior
.
Additional context
No response