bug-texinfo
[Top][All Lists]
Advanced

[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.



reply via email to

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