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

[Drew Adams]

> > I am convinced that you will find the same thing I reported:
> > there are *very* few bad-behaving links.

You changed the subject below (different problem), so shall we assume that you
did in fact find the same thing I reported when you clicked on a representative
sample of links?

> Please see bug#4147.  Breadcrumbs break Info search
> and navigation in the history with `l'.

I suppose you mean this:

>> The odd behavior when point moves forward by a few
>> characters is caused by breadcrumbs inserted to the
>> Info buffer (the distance point moves forward is the
>> length of the breadcrumbs string).

That is indeed a very different symptom, even if the cause is the same.

And that symptom is more disorienting, even if being off by a few characters
also is not the end of the world. Users will wonder what's happening, and they
should not need to be puzzled that way.

No one disputes that making breadcrumbs work without causing such difficulties
is desirable. I questioned the other symptom's description as being "a PITA" and
happening "all the time". And I wondered whether the fixes being discussed were
clean and simple enough. (I might add "and general enough", since we seem
sometimes to have moved away from the search for a general solution that handles
also other, non-Info problems.)

I did, BTW, support your point that putting breadcrumbs in the header line has a
"significant advantage for orientation and navigability" (my words).

Looking over this thread, and particularly the thread for #4147, there have been
several different solution approaches proposed (mainly by you). That's good.
Better to think it over well before picking one and implementing it, since each
possible change seems to be fairly far-reaching in terms of
implementation/design, and the behavior consequences for this and other things
in Emacs are different depending on which is chosen. 

You obviously understand the various solutions better than I. Based on my
limited understanding, a multi-line header seems to be the best solution I've
heard so far (and it has other uses elsewhere).

It's too bad that the simple solution of using a newline in the header line
doesn't work without display-engine changes. Has anyone looked into what changes
to the display engine would be needed to fix that?

Don't get me wrong. I'm not at all against trying to find a better, general
header-line (or other general) mechanism to deal with problems such as this. On
the contrary.

But that merits a general design reflection, not just handling as a bug report
for a particular problem. Some such general discussion has already gone on in
these threads. It's good to continue that, but in emacs-devel under an
appropriate general topic, not just in the thread of a bug that deals with only
one or two aspects of the question.

At one time (in the #4147 thread) you said "The goal is to design a new window
infrastructure that supports window groups." Now you seem to be back to a
multi-line header line (via display-engine changes?), which might or might not
mean the same thing. Maybe that's the question: just what is the general design
goal?

As I said in the #4147 thread:

  In that case, I'd suggest that emacs-devel is the right
  place to discuss such redesign. IOW, leave the bug unfixed
  until the requisite design change allows fixing it, and
  discuss the design change in the dev mailing list, not
  just in this bug thread.

Yes, I do not think we should turn off breadcrumbs by default for Emacs 23.2.
The benefit outweighs the inconveniences, IMO - just one opinion. It is in order
to discuss just such trade-offs that I suggested that people actually click Info
links to see if Eli's problem is typical or exceptional. For Emacs 23.2, both
that problem and the search-off-by-a-few-chars problem do not merit turning off
breadcrumbs by default, IMO.

But I also agree that a general redesign of, say, header lines that helps with
the breadcrumbs problems and with other things (e.g. tabs) would be a good goal.
As you put it (in #4147):

  Currently the header line has the limitation in only
  one glyph row. But this is a general problem that should
  be solved one way or the other, so different modes like
  Info, proced, ruler-mode could have their own header window.

Until that general change is made, I say leave breadcrumbs displayed by default.

And I wish that such general changes were discussed in emacs-devel _as general
design changes_, and not just inside specific bug threads here and there. When
discussed in terms of this or that Info symptom the generality is lost, and the
focus oscillates between being narrow (for the particular problem symptom) and
general.