GNU bug report logs - #5809
23.1.94; cross-reference by anchor yields in accurate position

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 5809 <at> debbugs.gnu.org
Subject: bug#5809: 23.1.94; cross-reference by anchor yields in accurate position
Date: Sun, 4 Apr 2010 15:51:29 -0700

> > Also, *in practice* this is a *rare* problem. You are 
> > making a mountain out of a mole hill.
> 
> Drew, please try being objective.  You were one of the main pushers
> for introducing the breadcrumbs feature, so it's understandable that
> you have bias, but please try to hold it back.

Eli, you please try being objective. That was my precisely my point:
*objectively measure* how much this is a real problem in practice. YOU do the
measurement - don't take my word for it. Judge for yourself, but judge only
after actually trying a sample of links.

No, BTW, I was not in fact a "pusher" of breadcrumbs for Emacs. I created
breadcrumbs for Info in my own library, and I eventually offered the idea (and
implementation) to Emacs. Stefan took it from there. I don't care to push it or
any particular implementation of it for Emacs. Do with it what you will.

Personally, I think breadcrumbs are helpful to users, but I really don't care
whether I convince Emacs developers of that. I still have and use the feature in
my own library, with my original code (somewhat different from the Emacs
implementation).

I have no problem with Emacs not adopting that feature or any of the other Info
enhancements I use - that should be clear by now. (In fact, it's much easier in
terms of maintenance when Emacs does not adopt a feature I have, if it
implements it only partially or differently, for example.)

And even if you don't believe me and you think I have some perverse motivation
for what I'm saying, the *facts* don't lie: There simply are very few
problematic links. Don't believe me; test for yourself - but be honest about
what you find.

My motivation is irrelevant, as is yours. Let us not second-guess motives or
descend to ad hominem argument: Drew's arguments and findings don't count,
because he's the one who came up with the idea for breadcrumbs in the first
place. You can be better than that, Eli.

My point was and still is that BOTH breadcrumbs AND being able to target a
precise mid-node position are helpful aids to users. I've been clear that IF you
can do them both cleanly and simply then please do so.

FWIW, until I actually tried sampling links today, you had me convinced, with
your single link-behaving-badly and your exaggerated language, that this was in
fact a real, practical problem.

I was surprised when I discovered that existing links do not bear out your
characterization of the situation. (I wondered about that, since I use this
feature all the time.)

After that discovery I thought it might help to put this in perspective -
objectively - hence my mail today. Ignore reality if you like - your choice.

> > In truth, Eli's dramatic characterization of this problem 
> > as "a PITA" and
> > 
> >   you are placed in the middle of a sentence that,
> >   more often than not, has nothing to do with the
> >   subject you are after.
> > 
> > is quite overblown and inaccurate. It is simply not the 
> > case, except in rare cases.
> 
> Well, perhaps I happen to hit only those ``rare cases'', because it
> happens all the time to me.

Yes, perhaps. Can you characterize that use?

I characterized the behavior of both (a) links in general and (b) index links,
which are an exception to the rule.

And my characterization was not only theoretical (logical), explaining *why* in
general there would be no real problem. It was also practical: I followed lots
(hundreds) of links in both manuals. How about you?

Use your own link traversal/sampling. Describe it to us, so we can understand
your use case where "it happens all the time". Is that just hyperbole? Does it
really happen to you for each link?

You truly must be doing something I haven't thought of. I have difficulty
finding links that don't work well. One of us is either exaggerating or doing
something very exceptional.

Pick links at random. Or start at the beginning of the manual and try each link
in order. Or start at the end. Or start with the index, which is where the
problem is most likely to arise. Even for index links, I think you'll find that
you've exaggerated the claim greatly.

For those willing to test this objectively, I propose two quick tests, to give
you a good idea: (a) links in the text (anywhere) and (b) links in an index.
Take just 2 minutes right now to click, click, click, seeing whether you end up
in the wrong place.

I am convinced that you will find the same thing I reported: there are *very*
few bad-behaving links. This is not a PITA.

> The amount of offset depends on how many other nodes you visited in
> the same sub-file, so it's somewhat unpredictable.

I'm aware of that. That's why I wrote

  So being off by the length of one or more breadcrumbs
                                    ^^^^^^^
  still takes you to the right description.

TRY it. Visit as many nodes and links as you like - the more the better.
Describe to us what you *actually* see: what percentage of the links do not take
you directly to the appropriate passage?  10%?  1%?  0.1%?

I gave you my guesstimate: 0.1% - a bad-link case such as you reported
represents maybe one in a thousand links. You give us your estimate. But please
do try actually following a fair number of links before estimating. Objective -
yes, please.

Don't just make the claim that it happens "all the time" to you, without letting
us know what links lead you to say that.

> Anyway, Juri is actively working on a solution for this bug, and
> almost has it done, so this argument is pointless and unnecessary.

I repeat:

  If you can find a clean, simple way to make
                    ^^^^^^^^^^^^^
  *everything* work well, so much the better, obviously.
  ^^^^^^^^^^^^

What I've heard so far about the solution in progress doesn't seem to fit that
description; it doesn't inspire confidence. The last I heard, there was even
talk about having to rebind keys (or else sacrifice keyboard link following).
"If you *really really really* want to make it work", as Stefan put it. Each
time some part of a solution was proposed there seemed to be drawbacks. Fixing
the fixes...

At some point the question becomes whether the cure might be worse than the
illness. The point of my message today was to take a second, objective look at
the illness. Is it "really really really" worth the complicated cure?

So I agree that not just this discussion but the whole enterprise - this bug fix
- has been rather pointless and unnecessary. There are far more important
problems to fix (a long list of them, including UI bugs).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.