RE: breadcrumbs for Info . . . . . .

[Drew Adams]

BTW, your changes introduced a bug:

emacs -Q
load your info.el (from CVS)
C-h i
choose Emacs manual
T

Wrong type argument: stringp, toc


> >     It is the breadcrumbs line where
> >     space is critical; it is likely to be longer than the
> >     header-line.
> 
> In my tests (and with my setup), the header-line already tends to
> overflow more than the breadcrumbs

I said header-line, but I meant the second line (what is it called?). Are you
perhaps using a nil value for `Info-use-header-line'? The default value is t (at
least on Windows). In the default case, it is the breadcrumbs line that is
likely to be longest.

Personally, as I said, I _like_ the addition of the top and current nodes to the
breadcrumbs, and their removal from the second line (or the first line, if
`Info-use-header-line' is nil). (I didn't do that myself because I figured there
would be too much resistance to a change that removes them from their
traditional spot.)

But I also think the breadcrumbs, when used at all, should be complete - never
elided. They should also be filled, so that (like the Info body text) they stay
within 72 chars without wrapping.

I'd suggest therefore getting rid of the depth user option altogether. If you
feel you must keep it, then please make its default value 5, which includes
everything (the 4 possible section levels plus the top level). By default, at
least, no breadcrumb nodes should be elided.

> I introduced the depth first and foremost to ensure termination.

I saw that, and that in itself is fine. I'm talking about the option. You can
still use depth (5) in the code to ensure termination, without having a depth
user option. Your code just uses the option to initialize the internal depth
counter.

> > . When using ellipsis, I suggest dropping first the current
> >   node name and the file+top - precisely the parts you keep.
> 
> I keep them precisely because they were there before.

> The number of nodes actually displayed depends on too many 
> things: to be really precise, the docstring would need to be overly 
> complex.

The question is what should be dropped when using ellipsis. The current and top
nodes are the least important parts to keep in the breadcrumbs, for the reasons
I gave. _If_ you drop anything, they should be dropped.

However, I really think nothing should ever be dropped (elided) from the
breadcrumbs. Instead, they should just be filled at 72 chars (splitting at `>').
 
> > . You might want to bind `Info-fontify-maximum-menu-size' to
> >   nil, as I did, for the calls to `Info-goto-node'. That will
> >   save useless extra fontification.
> 
> You misread the code.

It's possible. But FWIW I followed it (my version, which stopped only at Top,
not via depth) in the debugger, and that binding did save unnecessary work. But
that was only manifested in certain nodes (Multiple Displays, IIRC).

BTW, I wonder if there isn't a bug in the text of node Multiple Displays.
Looking at its raw text, it seems different from its siblings: no explicit Up,
Prev, or Next; no underline of the node title. Perhaps this difference is what
caused the extra fontification attempts that I saw (related to the fragility of
the Top test)?