[bug #63768] want configurable URL format for man page hyperlinks

[G. Branden Robinson]

Follow-up Comment #15, bug #63768 (project groff):

[comment #14 comment #14:]
> [comment #13 comment #13:]
> > I wouldn't say "adamant"...but pretty resolved on letting groff 
> > 1.23.0 gather some feedback on the feature.
> 
> Do you mean feedback on the 'an*MR-URL-format' register? What if you end up
having to ditch it? It strikes me as poor form to introduce a feature in a
major release (1.23.0), only to axe it in (1.23.1). (Of course, I'm probably
reading too far into this…)

I think you are, as I'm trying to _avoid_ etching this register's name, or
even its existence, in stone.

> > A. Can you clarify that both Terminal.app and iTerm support the second
one?
> 
> You recently gained SSH access to a macOS machine, yes? If so, you should be
able to test this yourself:
> 
> 
> $ open x-man-page://3/printf
> $ screencapture -mxT3 ~/Desktop/screengrab.png
> 

It's _just_ SSH access, to a machine in a build farm somewhere in Europe; I
did not imagine that remote terminal connections fired up in a desktop
environment in a virtual framebuffer.  I can try this but I have no reason to
expect it to work...

> On Darwin, the open(1) command is the moral equivalent of xdg-open(1), and
treats URIs with semantics similar to `xdg-mime query x-scheme-handler/…` (I
think; I don't have a Linux machine handy to double-check this myself).

This sounds much like see(1) in the Debian "mailcap" package.
 
> 
> $ uri="mailto:bug-groff@gnu.org&subject=Let%27s+go+Branden!";

Bernie Sanders was robbed!

> $ open     "$uri" # macOS
> $ xdg-open "$uri" # Actual POSIX systems
> 
> 
> Your confusion with the "x-man-page" scheme likely stems from the fact that
macOS's default handler for that protocol is Terminal.app (which opens
man(1)'s output in a new window, irrespective of whether the Terminal.app's
running or not). Hence, iTerm2 will open those links in Terminal.app by
default (changing that is an exercise for the macOS user, and irrelevant to
this discussion).

I remain confused even after that explanation.  I haven't used Mac OS X since
it was called that, nearly 20 years ago, and never seriously--never for
development, for example.  At one time I was a NeXTSTEP user, though--on a
real NeXT cube, even!  ;-)
 
> > B. That last one--in email you documented it as "x-man-doc://1/groff(1)"
(ManOpen), complete with the redundant parenthesized suffix.  Which is
correct?
> 
> That was a typo. The "x-man-doc" scheme was used by antique versions of
ManOpen before Apple introduced the "x-man-page" scheme in 2005. Afterward,
ManOpen supported both schemes, with the older one kept for compatibility and
flexibility.

Okay.  I will resequence the formats and scotch the redundant "(1)" in
x-man-doc.
 
> Not so much "necessary" as it is plain old defensive programming: if a macro
unsets that register—deliberately or otherwise—it shouldn't cause man(7)
to generate mangled and/or useless hyperlinks.

Okay, yes, a perverse user's man.local, or a document, could indeed set it to
a bogus value or remove it entirely.  (No macro is necessary to achieve this,
just the `nr` or `rr` requests, respectively.)
 
> > It seems useful to let a value of 0 mean "I don't know what the F you're
talking about", which will be true of other implementations, particularly
since the zero-interpolation-for-undefined-registers language rule suggests
it.
> 
> Erh, won't other implementations have a `an-url` string (or whatever)
defined as well?

As far as I know, Plan 9 from User Space troff is the only other
implementation, and I don't expect any others to arise, except _maybe_ in
mandoc(1), if Ingo can steel himself to do it (he thinks it's a bad idea).
 
> There's probably a way to add support for it from C++/Objective-C, but that
would require knowledge and access to Xcode, Apple's SDKs, and access to a
proper workstation. I have all but the knowledge (I haven't touched Xcode in
12 years), and I'm not sure RMS would be pleased with a FSF project housing
code that requires a heavily, *heavily* commercial IDE to build…

I don't think the last point is relevant unless you tried to undertake this
development on an FSF-owned (or -leased, whatever) host.

If support for "man:page(section)" URLs were added to Apple's apps, that would
mean we could _remove_ explicit mentions of proprietary macOS stuff from
groff.  I think RMS would approve of their embrace of a de facto standard
pioneered by Free Software desktop environments (GNOME, KDE).


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63768>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/