From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: breadcrumbs for Info . . . . . . Date: Fri, 13 Jun 2008 09:58:38 -0400 Message-ID: References: <009d01c8cb55$13d53e20$0200a8c0@us.oracle.com> <87fxrkltma.fsf@jurta.org> <00ae01c8cb71$c26aeef0$0200a8c0@us.oracle.com> <873ankqou6.fsf@jurta.org> <00d901c8cbc9$7df36fb0$0200a8c0@us.oracle.com> <87tzfzk331.fsf@jurta.org> <00a501c8ccdd$93328720$c2b22382@us.oracle.com> <002401c8cd1f$98631650$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1213365662 27718 80.91.229.12 (13 Jun 2008 14:01:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Jun 2008 14:01:02 +0000 (UTC) Cc: 'Juri Linkov' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 13 16:01:36 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K79pW-0003qG-Hc for ged-emacs-devel@m.gmane.org; Fri, 13 Jun 2008 16:00:39 +0200 Original-Received: from localhost ([127.0.0.1]:45842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K79oi-0007vw-Iw for ged-emacs-devel@m.gmane.org; Fri, 13 Jun 2008 09:59:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K79od-0007sK-6o for emacs-devel@gnu.org; Fri, 13 Jun 2008 09:59:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K79ob-0007pc-Ka for emacs-devel@gnu.org; Fri, 13 Jun 2008 09:59:42 -0400 Original-Received: from [199.232.76.173] (port=35469 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K79ob-0007pK-GZ for emacs-devel@gnu.org; Fri, 13 Jun 2008 09:59:41 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46778) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K79ob-0004Pj-Ot for emacs-devel@gnu.org; Fri, 13 Jun 2008 09:59:41 -0400 Original-Received: from ceviche.home (vpn-132-204-232-131.acd.umontreal.ca [132.204.232.131]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m5DDxdlp019355 for ; Fri, 13 Jun 2008 09:59:39 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 945CCB4087; Fri, 13 Jun 2008 09:58:38 -0400 (EDT) In-Reply-To: <002401c8cd1f$98631650$0200a8c0@us.oracle.com> (Drew Adams's message of "Thu, 12 Jun 2008 23:34:55 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered HAS_X_HELO=0, RV3037=0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:99096 Archived-At: >> I'm not so sure. The same reasons that might push someone to want to >> see "*Note ::" in the main text might push someone to want to see >> them in the breadcrumbs. The reasons are typically the someone >> unclea(r|n) behavior of invisible text when you move cursor around or >> when you copy&paste it. > I don't see that (as a) problem, I guess. Could you elaborate? Are you > talking about someone copying and pasting the breadcrumbs links Yes, for example. > (why)? Because some people work differently than you do. Why do you think we have the Info-hide-note-references variable in the first place? >> I think it's a good feature, so I suggest you go back to the previous >> version which didn't mess around with Info-hide-note-references, > The previous version also messed around with `Info-hide-note-references'. > Otherwise, you would have seen "See Top > See Foo > See Bar" instead of just > "Top > Foo > Bar". Yes, I overlooked that. I think this part was OK. It only changes the way Info-hide-note-references works, but not whether Info-hide-note-references is obeyed or not. > The code just ignores `Info-hide-note-references' (values other than > those that hide), for the first 4 lines of each node. Yes, and that is the part I don't like. > You can think of the breadcrumbs line as part of an extended header > area. (And you might even want to remove the Up link from the header > now, since it is no longer needed - the breadcrumbs subsume Up.) It would be nice to merge the two lines; but Info node titles tend to be longish, so I don't think there's enough room for that. As for removing "up", it might be a good idea. In any case we'll want to add a Info-insert-breadcrumbs config var for people like Thien-Thi. > It might be cleaner to create and use a new link type that is never > displayed as "See" or "*Note", but always just as the link > text. Perhaps that's what you meant, above. Yes, that's what I meant. Maybe it could even be just an `insert-text-button'. > That might be better than simply adopting a rule that *Note within the > header area is never displayed with text other than the link text. Yes. > And there might be additional uses for such a link type, other than > breadcrumbs - I don't know. Indeed: there's no reason why the header line links should use a different mechanism than the breadcrumbs links. > But it would be more work, and I'm not sure it would be worth it. I think it would improve the result noticeably. > In any case, I won't be working on that. If you want to install the current > version now (after people test it), and then later try to do what you want, > that's OK by me. As I said, the current way it works is acceptable to me, so we can indeed improve it later on. >> then rework the code to stay with the 80-columns limit, > I did not widen the code. In fact, I made it narrower, in passing, by > splitting a very long string (via \ at line end). Yes, I saw that. I know the info.el code is pretty bad w.r.t line length. But that's no excuse for using more than 80 columns in new code ;-) > The code I added was > shorter than the existing lines. Nevertheless, I've shortened all of > the lines to 80 max, as you asked - see attachment. Thank you. Could you provide it as a patch? > Personally, I think that's quite silly and makes the code less > readable. And it is far, far, far, f a r from being a convention that > is followed in the Emacs sources. (And I don't see you insisting on it > whenever changes are made.) Many files are ridiculously wide. Have fun > condensing them all to illegibleness. I often make changes like that to a file to bring it back within 80 columns. BTW, w.r.t readability, a better way to make it fit in 80 columns is to move your breadcrumbs code into its own function (that will give you an extra 8 columns). Actually, it'd be a good change (the Info-fontify-node function needs a lot of such splitting) which would obviate the need for the "Add breadcrumbs" comment. > Better to concentrate on factoring code and creating helper functions, to > shorten some of the tome-length monster functions. That would have the side > effect of shortening line lengths AND produce readable code. IMO, that is a > better cleanup goal than simply shortening lines. Of course: long lines are generally a symptom. I'm glad we agree. Stefan