[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wishlist: implicit anchor for @deffn etc
From: |
Gavin Smith |
Subject: |
Re: wishlist: implicit anchor for @deffn etc |
Date: |
Thu, 2 Nov 2017 18:14:33 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Tue, Oct 31, 2017 at 01:42:37PM -0700, Per Bothner wrote:
> >As you point out there is already an HTML anchor generated for index
> >entries. Would one possibility be to change whatever this anchor is so
> >that the URL is not so ugly? This would be a change for HTML only,
> >leaving other output formats unchanged.
>
> A clarification: I didn't realize that the html backend already does generate
> somewhat stable and semi-readable links. (I missed that because I normally
> first convert to DocBook.)
>
> So the functionality in terms of generated links is already there.
> However, I suggest (for HTML output) changing the encoding to use the
> standard percent-encoding
> as in the encodeURIComponent encoding:
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent
>
> Browsers and other tools already understand percent encoding.
I don't think that links to index entries have to be stable, unlike
links to nodes or anchors. As you mention, there is no Texinfo support
for a link to an index entry (or definition). So it is probably okay to
change the HTML anchor ID if there is a benefit to doing so.
Are you thinking of linking to a definition from within the same manual
or from another HTML file? If it's the former and there is Texinfo-level
support for it, then what the link is doesn't matter that much as the
correct link will be generated by texi2any. If it's the latter, I would
also think it doesn't matter that much either, as whoever was writing
the file would have to look up the exact anchor they are linking to.
However, if we want stable links to definitions from external HTML
files, then this would be more disruptive. When each node is output in
its own HTML file ("split" output), the link is to that file. If
definitions are moved between files, the link will break, so there would
have to be a lot of redirection pages. Because we don't know which
definitions would be linked to, there would have to be redirection pages
for them all.