bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I think both types of navigation links (breadcrumbs and up/next/prev)
> should be treated equally.  If we'll implement clicking with the keyboard
> and copy&paste in Emacs-24, it would be natural to apply this to the
> up/next/prev links as well and change their visual appearance.

The up/prev/next links are different because we don't want them to
scroll with the text.  I.e. we're willing to give up on keyboard-clicking
and copy&pasting to be able to use the header-line.

Maybe we'd want to put the breadcrumbs in the header-line as well, but
that would require 2 lines of header-line and I'm not sure I'd be in
favor of such a change (especially as computer displays tend to get
less and less tall nowadays, for reasons that escape me).

> In any case, it's important that the visual appearance should match the
> user's expectation.  When the visual appearance of breadcrumbs is
> the same as for the rest text of the Info buffer, users will be tempted
> to use the keyboard on breadcrumbs.

I think it's OK: it is a misfeature, so it's normal for people to
complain about them.  Let's not pretend it's a feature when it's not.
Or to reverse your argument: if it looks like a header-line, people will
report bugs about the fact that it doesn't stay at the top of the
display ;-)
I.e. in any case it won't match all the user's expectations and I don't
think this argument will give us a good basis on which to make a decision.

> The overlay doesn't correctly interact with the `invisible'
> text property.

Interesting.  That deserves a comment.

> However, we can put 'invisible on the overlay instead of the text property:
>     (let ((ov (make-overlay (point-min) (1+ header-end))))
>       (overlay-put ov 'invisible t)
>       (overlay-put ov 'after-string (Info-breadcrumbs))
>       (overlay-put ov 'evaporate t))

Yes, that's better, thank you.


        Stefan