From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#5809: 23.1.94; cross-reference by anchor yields in accurate position Date: Sun, 4 Apr 2010 15:51:29 -0700 Message-ID: <4173056BC32F4835955C1B5A781D37EE@us.oracle.com> References: <837hoszubi.fsf@gnu.org> <87hbnwy2un.fsf@mail.jurta.org> <83y6h8xz8a.fsf@gnu.org> <8739zf5bif.fsf@mail.jurta.org> <83y6h7vy6p.fsf@gnu.org> <87y6h7uitd.fsf@mail.jurta.org> <83wrwqx6r2.fsf@gnu.org> <83vdcax5hu.fsf@gnu.org> <83sk7ewcvz.fsf@gnu.org> <422BAD8C75BE4F5BAE608BD47A355EFF@us.oracle.com> <83d3yhx6jr.fsf@gnu.org> <83C1972058E043DB8B80FEFB5A317A98@us.oracle.com> <83eiivymf6.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1270421771 24458 80.91.229.12 (4 Apr 2010 22:56:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 4 Apr 2010 22:56:11 +0000 (UTC) Cc: 5809@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 05 00:56:07 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NyYje-0002zL-Ff for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Apr 2010 00:56:06 +0200 Original-Received: from localhost ([127.0.0.1]:47741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NyYjd-00034g-NY for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Apr 2010 18:56:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NyYjY-00034Y-Ay for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 18:56:00 -0400 Original-Received: from [140.186.70.92] (port=43903 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NyYjW-00033w-JI for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 18:56:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NyYjV-0002Mz-6u for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 18:55:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36507) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyYjV-0002Mu-14 for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 18:55:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NyYhe-0002cZ-HO; Sun, 04 Apr 2010 18:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Apr 2010 22:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5809 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5809-submit@debbugs.gnu.org id=B5809.127042159110064 (code B ref 5809); Sun, 04 Apr 2010 22:54:02 +0000 Original-Received: (at 5809) by debbugs.gnu.org; 4 Apr 2010 22:53:11 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyYgo-0002cH-TU for submit@debbugs.gnu.org; Sun, 04 Apr 2010 18:53:11 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyYgn-0002cC-Am for 5809@debbugs.gnu.org; Sun, 04 Apr 2010 18:53:10 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o34Mr3dF000775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Apr 2010 22:53:04 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o34Mr1j8022838; Sun, 4 Apr 2010 22:53:02 GMT Original-Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 136120531270421494; Sun, 04 Apr 2010 15:51:34 -0700 Original-Received: from dradamslap1 (/141.144.72.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Apr 2010 15:51:34 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83eiivymf6.fsf@gnu.org> Thread-Index: AcrUODB5md7bvB2BRWalfsnNWiweYAAAVP0g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0209.4BB9184E.016C:SCFMA4539814,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 04 Apr 2010 18:54:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:35931 Archived-At: > > 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).