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 13:39:00 -0700 Message-ID: <83C1972058E043DB8B80FEFB5A317A98@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> 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 1270414570 6352 80.91.229.12 (4 Apr 2010 20:56:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 4 Apr 2010 20:56:10 +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 Sun Apr 04 22:56:06 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 1NyWrV-0007Gb-86 for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Apr 2010 22:56:05 +0200 Original-Received: from localhost ([127.0.0.1]:47981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NyWrU-0005Uy-Qz for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Apr 2010 16:56:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NyWrP-0005Uf-Po for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 16:55:59 -0400 Original-Received: from [140.186.70.92] (port=56444 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NyWrO-0005U3-Aj for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 16:55:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NyWrN-0001cH-0U for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 16:55:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57293) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyWrM-0001cC-QA for bug-gnu-emacs@gnu.org; Sun, 04 Apr 2010 16:55:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NyWbz-0001nm-0N; Sun, 04 Apr 2010 16:40:03 -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 20:40: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.12704135696916 (code B ref 5809); Sun, 04 Apr 2010 20:40:02 +0000 Original-Received: (at 5809) by debbugs.gnu.org; 4 Apr 2010 20:39:29 +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 1NyWbR-0001nV-Dj for submit@debbugs.gnu.org; Sun, 04 Apr 2010 16:39:29 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyWbP-0001nQ-F6 for 5809@debbugs.gnu.org; Sun, 04 Apr 2010 16:39:28 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o34KdLqa017927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Apr 2010 20:39:22 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o34K4p0C002005; Sun, 4 Apr 2010 20:39:20 GMT Original-Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 136066591270413545; Sun, 04 Apr 2010 13:39:05 -0700 Original-Received: from dradamslap1 (/141.144.72.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Apr 2010 13:39:05 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcrSckk4cP4m8N7RQrO81mQ6hoTxJwABdmZgAG0H6KA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BB8F8F8.0101: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 16:40:03 -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:35929 Archived-At: > > > Keep in mind too that in some documentation systems, which > > > don't even have the fine-grained "node" size of Info (on > > > average), cross references generally do not > > > take you to an exact destination position. They just get > > > you to the appropriate section. > > > > That Info does support this feature is one of its advantages, and we > > should not lose it, IMO. Without it, reading a large manual as a > > reference is a PITA. > > > > Besides, it simply feels as a bug (and actually is): you > > are placed in the middle of a sentence that, more often > > than not, has nothing to do with the subject you are after. > > I think everyone agrees that it is a desirable feature. If we > can have both exact cursor destination and breadcrumbs, that > will be ideal. Both are useful features. > > It is somewhat disorienting to not have point land only > nearby and not at exactly the right spot. And it is > disorienting to not immediately see where you > are in the document hierarchy (beyond just immediate up, > next, and prev nodes). > > We should aim to get both working properly together. Also, *in practice* this is a *rare* problem. You are making a mountain out of a mole hill. I wonder if people discussing this have actually tried following many links in the manuals. Most of the discussion has been about how to implement a solution and not about the problem. Think about the user and actual use, not just about implementation. Follow the actual cross references in the Emacs and Elisp manuals, and you will see that there are only a very *small* number of them that do not simply point to the beginning of a node. And only those small number are the potential candidates for target imprecision. And even in a reference manual such as Elisp, where you might expect many cross references to specific function and variable descriptions that occur in the middle of a node, there are relatively few such mid-node cross references. The one exception: index links to specific keys, functions, variables, and keys. They do target precise mid-node positions. But in fact only a small minority of even those exceptional cases do not act as well as one might hope. Following the link places you quite near the precise location and generally at a location that can still be considered the intended target (e.g. within the correct, targeted 1-3 line description or paragraph). Why would that be? Because (a) most breadcrumbs are short and (b) most function, variable, and key descriptions are more than one line long. So being off by the length of one or more breadcrumbs still takes you to the right description. Again, try it and see for yourself. Follow a representative sample of links of your choice, and see what proportion are in fact problematic. I'm sure you'll find that it is *very* small. So in practice this is not a real problem. There are many more important UI difficulties and annoyances that could be addressed before trying to achieve perfection here. Again, if you can find a clean, simple way to make *everything* work well, so much the better, obviously. But we should not make the perfect into the enemy of the good - do not throw out the baby with the bathwater. Don't let your enthusiasm for trying some new UI technique (`after-string', `cursor' properties, multi-line headers etc.) carry you away - creating a sledgehammer to kill a fly. Think about where you're going with the implementation vs what you're really trying accomplish. What's the problem and how bad is it in practice? 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. More often than not - in fact in the overwhelming majority of cases - you are NOT placed in the middle of a sentence that has nothing to do with the subject you are after. That's a fact, AFAICT. Try it, instead of just treating this academically. Follow real links and you will soon see what I mean. You are taken directly to the precise info you need in 99.9% of the cases (no, I didn't count - but try it and make your own estimate).