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: Mon, 5 Apr 2010 00:01:54 -0700 Message-ID: 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><4173056BC32F4835955C1B5A781D37EE@us.oracle.com> <87wrwmvjfe.fsf@mail.jurta.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 1270452832 23349 80.91.229.12 (5 Apr 2010 07:33:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 5 Apr 2010 07:33:52 +0000 (UTC) Cc: 5809@debbugs.gnu.org To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 05 09:33:48 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 1Nygod-0006Z5-9l for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Apr 2010 09:33:48 +0200 Original-Received: from localhost ([127.0.0.1]:57336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nygob-0003WU-LL for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Apr 2010 03:33:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NyghA-0001cE-C0 for bug-gnu-emacs@gnu.org; Mon, 05 Apr 2010 03:26:05 -0400 Original-Received: from [140.186.70.92] (port=42173 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nygh5-0001b1-OG for bug-gnu-emacs@gnu.org; Mon, 05 Apr 2010 03:26:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nygh4-0000si-6c for bug-gnu-emacs@gnu.org; Mon, 05 Apr 2010 03:25:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34094) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nygh4-0000sP-2g for bug-gnu-emacs@gnu.org; Mon, 05 Apr 2010 03:25:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NygLq-0005S5-2T; Mon, 05 Apr 2010 03:04: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: Mon, 05 Apr 2010 07:04: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.127045102520951 (code B ref 5809); Mon, 05 Apr 2010 07:04:02 +0000 Original-Received: (at 5809) by debbugs.gnu.org; 5 Apr 2010 07:03:45 +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 1NygLZ-0005Rs-95 for submit@debbugs.gnu.org; Mon, 05 Apr 2010 03:03:45 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NygLW-0005Rm-Ro for 5809@debbugs.gnu.org; Mon, 05 Apr 2010 03:03:43 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3573b1c031877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Apr 2010 07:03:39 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 o3549tjX018118; Mon, 5 Apr 2010 07:03:37 GMT Original-Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 136566841270450920; Mon, 05 Apr 2010 00:02:00 -0700 Original-Received: from dradamslap1 (/141.144.72.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 00:01:59 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87wrwmvjfe.fsf@mail.jurta.org> Thread-Index: AcrUViQEGJyoKYMISfOZg3oDGYfLKAALbHiA 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.0A090205.4BB98B49.00AC:SCFMA4539814,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 05 Apr 2010 03:04: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:35943 Archived-At: > > 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.