On Sun, Apr 12, 2020 at 8:38 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > On Sat, Apr 11, 2020 at 6:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Is that going to be a problem for the docs toolchain? If > >> the anchors are attached to individual function names rather than > >> sections or paragraphs, do they actually work well as link references? > >> (I'm particularly wondering how an <xref> would render.) > > > So I can't speak to any scalability issues for adding a bunch of refs, > but > > I did try this out for justify_days() (diff attached) and here's what I > > found: > > * <link linkend="function-justify-days">justify_days</link> > > This made a link, in the same font as any other link ref. > > * <xref linkend="function-justify-days"/> > > This made a link that looks exactly like the previous one, with the > text > > "justify_days", so if we're fine with the font change, we could use that > > * <link > > linkend="function-justify-days"><function>justify_days</function></link> > > This made the link we want in the function font. > > Hm. Attaching the link ID to an <indexterm> is an interesting hack. >
it worked for glossterms, I figured an indexterm is just another 'term. > My inclination is to standardize on using <xref> for references and > just accept the lack of a special font. It's not worth the notational > pain to use both <link> and <function>, especially not in HTML output > where links will probably get rendered specially anyway. We > previously made the same tradeoff with respect to GUC variables, > and I've not seen many complaints. (I experimented with putting > <function> into the indexterm text, but that did not help.) > > I'd be a bit inclined to shorten the ID prefix to "func-", just > in the interests of carpal tunnel avoidance. > xref it is. I'll take a shot and scripting the necessary changes.
