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/