groff
[Top][All Lists]
Advanced

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

Re: [htmlxref.cnf] Please update link to the Groff manual


From: Ingo Schwarze
Subject: Re: [htmlxref.cnf] Please update link to the Groff manual
Date: Sat, 30 Sep 2023 22:07:44 +0200

Hi,

Gavin Smith wrote on Sat, Sep 30, 2023 at 08:10:01PM +0100:
> On Sat, Sep 30, 2023 at 01:15:09PM -0500, G. Branden Robinson wrote:

>> 4.  "They might have changed this by mistake."
>> 
>>     Sort of.  I find the "html_node" name uglier, but if there's popular
>>     demand to switch it (back), I can see doing that for groff 1.24.

> We'll change htmlxref.cnf to whichever URLs you decide to use going forward.
> 
> If there are no links to the groff Texinfo HTML manuals anywhere on the
> web, it doesn't matter, but it is likely there are at least some somewhere.

Now that i see this bumpy ride explained at length, i realize the
link on this overview page of mine is currently broken, too:

  https://mandoc.bsd.lv/links.html

First paragraph, first line, second link ("manual").
Rather prominently featured because, well, groff is important.

Here are a few more links to the established URI, in alphabetical order:

  https://forums.freebsd.org/threads/converting-a-man-page-with-pandoc.36706/
  https://git.pwmt.org/pwmt/zathura/-/issues/258
  https://github.com/asciidoctor/asciidoctor/issues/3992
  https://github.com/jgm/pandoc/issues/5019
  https://lists.defectivebydesign.org/archive/html/groff/2020-10/msg00066.html
  https://lwn.net/Articles/912260/
  https://news.ycombinator.com/item?id=36066812
  https://perldoc.perl.org/Pod::Perldoc::ToMan.txt
  https://unix.stackexchange.com/questions/623970/writing-vietnamese-in-groff
  https://uu.diva-portal.org/smash/get/diva2:1189607/FULLTEXT01.pdf
  https://www.illumos.org/issues/9367
  https://www.reddit.com/r/groff/comments/gbfsx4/page_number_position/
  ...

In general, i think keeping URIs stable makes sense unless there
are *very* strong reasons for changing them - for example, forceful
loss of control over the domain name. or finding out that the old name
violated a relevant standard.  Isn't making a resource available in
the long term at least half the purpose of a URI in the first place,
if not more than half?

Besides, i don't see how a directory name on a public webserver
could possibly be related to internal file naming conventions
in autotools makefiles.

Argumably,

  https://www.gnu.org/software/groff/manual/html_node/

is even better than

  https://www.gnu.org/software/groff/manual/groff.html.node/

because it's more concise (a virtue in URIs) and less
redundant (a vice in URIs) without lacking any information.
The part of the path "groff/manual/groff" doen't really make much sense.

Arguably, even /software/groff/manual/html_node/ is excessively
wordy, but making it more concise and easier to remember is not
a sufficient reason for changing it and breaking links.

Probably it's best to go back to the link that has been in use for
at least a decade - and for extra safety, maybe leave the longer
path in place as an alias for a number of years before checking that
no links to it remain on the web, then deleting the longer alias.

Yours,
  Ingo



reply via email to

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