bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Gardner
Subject: [bug #63768] want configurable URL format for man page hyperlinks
Date: Fri, 17 Feb 2023 05:48:51 -0500 (EST)

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

[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…)


> 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


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).


$ uri="mailto:bug-groff@gnu.org&subject=Let%27s+go+Branden!";
$ 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).


> 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.


> The macro package defines it unconditionally anyway, so I don't see why
that's necessary.

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.


> 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?


> I would love for Apple's terminal emulators to support "man:page(section)". 
I would then happily rip this feature out entirely and never miss it.

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…


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]