RE: breadcrumbs for Info . . . . . .

[Drew Adams]

> >> There is also another visual problem: when 
> >> Info-hide-note-references is nil, the displayed breadcrumbs
> >> line is not nice looking:
> >> *Note Top:: > *Note Files::  > *Note Saving::  > *Note Backup::
> 
> > That's a bug.
> 
> I'm not so sure.  The same reasons that might push someone to want to
> see "*Note <FOO>::" in the main text might push someone to want to see
> them in the breadcrumbs.  The reasons are typically the someone
> unclea(r|n) behavior of invisible text when you move cursor around or
> when you copy&paste it.

I don't see that (as a) problem, I guess. Could you elaborate? Are you talking
about someone copying and pasting the breadcrumbs links (why)?

> So if you want to trat it as a bug, a better fix would be to really
> refrain from inserting "* Note <FOO>::" in the first place.  I.e. use
> a different buffer-text representation for your breadcrumbs.  This may
> not be very easy to do either because you then have to change all the
> link-following code to deal with the new hyperlink format used in
> the breadcrumbs.

I don't even follow what you have in mind as the alternative fix. If you want to
do that, feel free.

> I think it's a good feature, so I suggest you go back to the previous
> version which didn't mess around with Info-hide-note-references, 

The previous version also messed around with `Info-hide-note-references'.
Otherwise, you would have seen "See Top > See Foo > See Bar" instead of just
"Top > Foo > Bar".

The previous version just didn't handle all of the places where
`Info-hide-note-references' is tested. Hopefully, they are handled now.

The code just ignores `Info-hide-note-references' (values other than those that
hide), for the first 4 lines of each node. It fakes the treatment of *Notes in
that zone, to never adorn them with any text (e.g. "See" or "*Note") beyond the
link text itself. This is different from a specialized link treatment such as
that used for Prev, Next, etc., but the appearance is (should be, IMO) similar
to those. 

You can think of the breadcrumbs line as part of an extended header area. (And
you might even want to remove the Up link from the header now, since it is no
longer needed - the breadcrumbs subsume Up.)

It might be cleaner to create and use a new link type that is never displayed as
"See" or "*Note", but always just as the link text. Perhaps that's what you
meant, above. That might be better than simply adopting a rule that *Note within
the header area is never displayed with text other than the link text. And there
might be additional uses for such a link type, other than breadcrumbs - I don't
know. But it would be more work, and I'm not sure it would be worth it.

In any case, I won't be working on that. If you want to install the current
version now (after people test it), and then later try to do what you want,
that's OK by me.

> then rework the code to stay with the 80-columns limit, 

I did not widen the code. In fact, I made it narrower, in passing, by splitting
a very long string (via \ at line end). The code I added was shorter than the
existing lines. Nevertheless, I've shortened all of the lines to 80 max, as you
asked - see attachment. 

Personally, I think that's quite silly and makes the code less readable. And it
is far, far, far, f a r from being a convention that is followed in the Emacs
sources. (And I don't see you insisting on it whenever changes are made.) Many
files are ridiculously wide. Have fun condensing them all to illegibleness. 

Better to concentrate on factoring code and creating helper functions, to
shorten some of the tome-length monster functions. That would have the side
effect of shortening line lengths AND produce readable code. IMO, that is a
better cleanup goal than simply shortening lines.

> and then someone can maybe install it.

I think it would be useful. It can always be improved upon later (e.g. changes
to links or reimplement based on a cached node graph, etc.). If it would help,
we could add an option now to let you choose not to produce breadcrumbs. 

> I do worry about the (string= "Top" up) test: what
> happens if your info file is slightly messed up and you never hit
> a reference to "Top"?

Agreed. Patches welcome.

info-patched-2008-06-12b.el
Description: Binary data