Predicting / computing node links
Denis 'GNUtoo' Carikli <[email protected]>
| Newsgroups | gmane.comp.tex.texinfo.general |
|---|---|
| Message-ID | <[email protected]> |
Hi, I'm using texinfo like that: $ makeinfo --html --no-split gnuboot.texi -o gnuboot.html And I'm also integrating the resulting HTML file into a website (the GNU Boot website). We're migrating that website to Haunt, a static website generator written in GNU Guile, and some pages will be made in Guile too (thanks to SXML). So I'm trying to write a Guile function that can refer to a manual node to keep the maintenance costs low (I don't want to have to check all the links manually each time I rebuild the website). It looks like that: > (gnuboot-manual-url "ThinkMods expresscard to NVMe adapter") And it should give: > "gnuboot.html#ThinkMods-expresscard-to-NVMe-adapter" And I've code that verifies that the manual nodes names don't have any forbidden characters (like Periods, Commas, etc, and their UTF-8 version as well, as described in the texinfo info manual). But then I have strange things. This texinfo in our manual: > @node Non-standard GNU/Linux configurations > @subsubsection Non-standard GNU/Linux configurations Gives me that in the HTML output file: > gnuboot.html#Non_002dstandard-GNU_002fLinux-configurations And This: > @node Load Operating System (can be fully encrypted) > @subsubsection Load Operating System (can be fully encrypted) Gives me this in the HTML output file: > gnuboot.html#Load-Operating-System-_0028can-be-fully-encrypted_0029 So my question is if there is some (informal?) specification for how the node links are generated, or if I can make them predictable somehow, to be able to make sure to point to a manual node. And if possible the question also applies across a wide range of texinfo versions (to not have to use a very specific texinfo version through Guix, and enable anyone to also build our website without Guix, on the distribution of their choice). Denis.
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmp3tbAACgkQX138wUF3 4mNyrQ//axqPsyoRrVKQmraJSc4BbPTL5BYTDL/V4Iux6JZ3i1AWZdej6coMwUT5 amLeVGkC9RqM6zH+1+iXZ4/TSBcVmDx42OKHNYkRquXpkROk0r80zV27zd8M+oVk Cw2Crig0JS24L3r7MSs1SJbRFeBi0OboBu6vNcbdxejv4ITceUGtrzcwoS8MIt4f LVNZ59jt6H5U0JZ3+w/OJngoMvHzOVIij3SOfr46Dllk+8MSBqa4nOkoNSpDiziJ tUzzmkLfOc9ZnJdSTr30+JqfCPdXKksMSJ5Dy507pDAYXwbbkDMCIp3EhFU1ETv8 0/9WtFb8GyFkaBDzxmL/hVT8XluavJRndEIjxFAvQZ8l6dj6Uo4JShwV9NcZGDNg bs7LekMdNgkQpM5Zk4E7e0vloHbQsu0S5FrBlxeu+aXIdTBUwxv3kvHX20ntmAyk NxBiTGqbPMUPj46K+0afmf8OdJCGO7S27HXjTGmQEWP9IfG/Tls9dj/8OrTxc9o4 8GauH3kD/TiAdPmGSdYsFOn997vES9ieVU90AxhzG2p+t3dAg3rZEZVpfx5Jtn9J BVuIwXvCcIIJ5zafrcw/+b1IpI+GXLtxqCnXoE02bkEjq/+PQaaCXHsELZTwR1tn q0sHGMP+ZdQhQL8Rf/HRH90BuN0J57FnOFC2CHunMj+mJBSmjGk= =4Xt5 -----END PGP SIGNATURE-----