RE: breadcrumbs for Info . . . . . .

["Drew Adams" <drew.adams@oracle.com>]

> > Wrong type argument: stringp, toc
> 
> Indeed, thanks.  It broke info-apropos as well.  Should both be
> fixed now.
> 
> BTW, I agree with you that the `toc' should be a virtual node rather
> than a virtual manual.  And the info-apropos should construct a node
> "(apropos)<query>" rather than "(apropos)Top".

I don't recall saying that, but I agree. ;-)

I think I wrote something related a while back about users creating virtual
books that way. And I mentioned caching the node list rather than the TOC text.

Other than that, I don't recall saying anything related. But it is a good idea.

> > 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 understand.  The current default is a tradeoff: it provides all the
> info that was there before and it fits within 80 columns in my tests
> (i.e. it doesn't use up more screen real-estate than before).

Info text is, AFAICT, generally filled to 72 columns, not 80. The same should
hold for all header-area lines (including breadcrumbs).

Node names can, as you said, be long sometimes. Long enough to call for filling
breadcrumbs. Eliding does not help users. If you insist, keep eliding as an
option, but please always show the complete breadcrumbs path, by default. 

99% of the time, no filling or eliding will be necessary. For the remaining 1%,
filling is better than eliding. When someone hits that 1%, s?he shouldn't be
surprised with elision. 

Most users will not think to look into the doc to see if there is a way to show
what's elided. Users who are surprised by a filled path and also bothered by it
are more likely to look for a way to turn it off. More importantly, in the one
case there is loss of information and functionality, in the other case there is
only a minor loss of screen space.

Better to show the information, wrapping it as needed - least surprise. (What
the `...'? Where did the rest of it go?) 

> > 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.
> 
> Not eliding breadcrumbs means that we would occasionally use up more
> screen real-estate than before.  Some users may like it, others won't.
> The current choice seems safer.

Very occasionally. And some users might not like some of the other changes that
we've made here. And users can choose not to use breadcrumbs.

Eliding means that occasionally we would not show the intermediate nodes. Some
users might not like that...  It will not be obvious to them where they are or
how to get to those nodes - there are no commands to do so.

If we fill instead of elide, it might not be obvious to users how to get rid of
the extra breadcrumbs lines, but at least no one loses any information or
navigation actions that way.

> > 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.
> 
> Maybe to you they are the least important pieces of info, but they're
> the only piece of info that was there before, this seems to indicate
> that there's a good chance they are *more* important.

You are misrepresenting what I said. It is less important to duplicate them in
breadcrumbs, because they are visible elsewhere and because we have commands (u
and t) to go to them directly. I am not saying that up and top are less useful.

> I've never removed the Info-fontify-maximum-menu-size 
> binding, I've just moved it elsewhere.

Ah, yes, I missed that.