Re: Customizing HTML output of indexes

[Gavin Smith]

On Sun, Sep 22, 2024 at 11:05:04AM -0400, Benjamin Kalish wrote:
> And now I can't reproduce the problem with the sidebar even when I try!
> 
> To get the expected behavior with the index the following seems to be
> working for me. In the function cache_index_links (info.js line 147)
> replace:
> 
> if ((link = link.nextSibling)
>               && link.classList.contains("printindex-index-section")
>               && (link = link.firstChild))
>             {
>               dict[text] = href_hash (link_href (link));
>             }
> 
> with
> 
> if (link.classList.contains("printindex-index-entry")
>             && (link = link.firstChild)
>             && (link.nodeName == 'A')
>           ) {
>             dict[text] = href_hash (link_href (link));
>           }

I found this change didn't update the sidebar correctly although the
correct location in the page was selected.

I have started adding tracing statements to info.js to try to understand
the execution better.  (You can view this in the Chromium developer
tools console with Ctrl-Shift-I after changing DEBUG to 1 in config at
start of file.)

When you select an index entry by pressing Return in the "index"
text box, the code in the "keydown" event listener calls "set_current_url"
on the saved value for the index entry.

With your change above, this "link id" contains the anchor name
for the index entry along with the node name.  For example, in
the "info-stnd" manual, for the "last-node" entry in the "More Node Commands",
this linkid is "More-Node-Commands.index-last_002dnode".

The sidebar is then updated in "on_message" that is nested inside
"init_sidebar" inside info.js.  The "More-Node-Commands" part is
extracted in the following line:

        /* Remove the hash part for the main page.  */
        var pageid = linkid_split (data.selected).pageid;

However, it wasn't being used due to the following lines:

        var selected = (pageid === config.INDEX_ID) ? pageid : data.selected; 

        /* Highlight the current LINKID in the table of content.  */
        var elem = scan_toc (toc_div, selected, data.section_hash);
        if (elem)
          elem.scrollIntoView (true); 

I haven't understood what the purpose of the "pageid == config.INDEX_ID"
test was (it is not recent, it was present in the code as far back as 2017).

Disabling it, the sidebar is updated correctly.  Here's the full change,
including your change, that appears to produce the correct behaviour:

diff --git a/js/info.js b/js/info.js
index f08ecf4eba..f604a9b79e 100644
--- a/js/info.js
+++ b/js/info.js
@@ -170,10 +170,10 @@ var actions = {
             text0 = text;
           }
 
-        if ((link = link.nextSibling)
-            && link.classList.contains("printindex-index-section")
-            && (link = link.firstChild))
-          {
+        if (link.classList.contains("printindex-index-entry")
+            && (link = link.firstChild)
+            && (link.nodeName == 'A')
+          ) {
             dict[text] = href_hash (link_href (link));
           }
       }
@@ -1457,7 +1457,8 @@ init_sidebar ()
 
         /* Remove the hash part for the main page.  */
         var pageid = linkid_split (data.selected).pageid;
-        var selected = (pageid === config.INDEX_ID) ? pageid : data.selected;
+        //var selected = (pageid === config.INDEX_ID) ? pageid : data.selected;
+        var selected = pageid;
         debug ("sidebar - " + selected);
 
         /* Highlight the current LINKID in the table of content.  */

I'll probably commit this in a day or two to give a chance for more
investigation and testing.

Trace output:
current-url
info.js:2171 :linkid: More-Node-Commands.index-last_002dnode
info.js:2171 sidebar - index
info.js:2171 sidebar - More-Node-Commands


> 
> I should note that I made this change directly in the info.js found in the
> html directory after building a project with texi2any.

Yes, that's a fine way to debug the problem.


> 
> I wish I had a better understanding of what was going on with the sidebar.
> My guess is that the problem, when it happens, has something to do with the
> way the application tracks and updates its state. If the problem reemerges
> I would look for the problem there, rather than change the cached index
> links.

The point is that the "cached index links" have to have the information
of where the index entries are pointing.  As it is they only go to the
node, not the specific location in the page, as you found.