Hacker News new | ask | show | jobs
by jvillasante 68 days ago
I think the website is weird to navigate. "Next" links go to top-level headers instead of the "logical" next. For example, if I'm on "1.1 Fset Tutorial" clicking "Next" takes me to "1.2 Using Fset" instead of "1.1.1 The Major FSet Types".

At a conceptual level, do these data-structures store what in other languages would be pointers and so every access would mean paying for the pointer indirection or do they store objects themselves and they are cache friendly data-structures?

3 comments

This is how Texinfo (which this uses) works. It's the same if you navigate it with an Info reader: "n" goes to the "next" node, which behaves as you point out.

When I'm reading in an Info reader (almost always in GNU Emacs) I always hit the spacebar when reading. This scrolls down a page and, if it's at the end of a page and, if at the bottom, goes to the next subnode - in other words, what "makes sense." (Actually the binding for this is "Info-scroll-up".)

That doesn't help when you're on a website, but for me Texinfo websites have a distinctive look and when I see them, I immediately know what clicking "Next" will do, and I know to instead go to the bottom of the page and go to the subnodes if that's what I want, which it typically is.

I agree that it's weird...but maybe understanding the overall weirdness of Texinfo helps it all make sense?? A more coherent weirdness?

I guess this might just be emacs Info-mode bias on my part (and the bias of someone who generally lives inside old documentation like this instead whatever the newfangled stuff is like I guess), but this behavior is precisely what I expect. For "next" to either mean jumping to the next in a sequence or jumping down a hierarchical level, depending on context, seems like "bad design" to me, or at the very least, trying to push the book metaphor to a fault.

The relation of 1.1.1 to 1.1 is about drilling down into detail if you want that, where you can still peruse through at the given upper level.

Picking another random other manual, it is the same: https://www.gnu.org/software/guile/manual/html_node/index.ht...

I did think about cache-friendliness and made them as much so as I reasonably could, mostly by trying to minimize levels of indirection; but pointers are inescapably involved, and there are limits to how cache-friendly such data structures can be.

For instance, each CHAMP node is a single CL vector; the header occupies the first few slots rather than being a separate allocated ooject.