RE: breadcrumbs for Info . . . . . .

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

> > Bias note: personally, i dislike features that use screen space.
> > If there is another line taken for breadcrumbs, i will find a way
> > to remove it.
> 
> Of course, that's always a problem.  Emacs being what it is, we'll of
> course make it an option.  This said, I think it'd be 
> worthwhile to try and make it all fit onto the existing header-line.

I don't think so, except perhaps when it would still keep the header-line less
than 70 chars. Info files generally are formatted to be at most 70 (or perhaps
72, it seems) chars wide - and that's a good thing.

The combination of (a) header line, (b) the next line (what's it called?) with
File and Node, and (c) breadcrumbs could perhaps be optimized _sometimes_ to
take up only two lines. 

However, we wouldn't gain much doing that, and users would lose some
predictability wrt where things are located. It's important that the same thing
(e.g. File) always be in essentially the same location.

In no case should any of these three lines be wider than the 70//72 chars that
are used for the buffer text itself. That already occurs for a few nodes now, I
believe, which is too bad. Before the existence of a standalone header line,
that happened quite often - the header line brought sanity to the header area.
It is much better, IMO, to sacrifice another line, when things don't all fit on
the same line within 70 columns, than it is to have a superwide line. 

> One way to make it might be to abbreviate node names.  But 
> I'm not sure how best to do that.  Maybe we should try to elide/abbreviate
> a (sequence of) word from a node name when that (sequence of) word
> already appears in the node's parent.

The node name, which appears in the mode line and the Node field, is already
abbreviated wrt the node (section) title. That's sufficient, and most of the
node names are quite short. There should be a single, canonical node name, used
everywhere. Abbreviating node names more than that, especially automatically, is
a bad idea.

If some node names are currently too long, then they should be shortened, on a
case-by-case basis, taking into account the context. Sometimes node names that
are too long reflect insufficient document structure, which can be relieved by
restructuring. 

More commonly, names are too long out of laziness. It takes thought to find
appropriate shorter names - an automatic abbreviation mechanism will not cut the
mustard.

Occasionally the fault is (presumably) politics: "GNU Free Documentation
License" instead of just "GNU License", "GFDL", or "License".