From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: breadcrumbs for Info . . . . . . Date: Sat, 14 Jun 2008 10:24:52 -0700 Message-ID: <00c501c8ce43$8e81c8a0$0200a8c0@us.oracle.com> 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><004a01c8cd67$b2f7a9c0$0200a8c0@us.oracle.com><00b101c8cda2$63175a50$0200a8c0@us.oracle.com><00b601c8ce03$6c7db2e0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1213464431 19756 80.91.229.12 (14 Jun 2008 17:27:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2008 17:27:11 +0000 (UTC) Cc: 'Juri Linkov' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 14 19:27:45 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 1K7ZXU-0003CW-33 for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 19:27:44 +0200 Original-Received: from localhost ([127.0.0.1]:49571 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7ZWf-0008Jv-Vw for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 13:26:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7ZWa-0008Jb-LR for emacs-devel@gnu.org; Sat, 14 Jun 2008 13:26:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7ZWY-0008J9-Ko for emacs-devel@gnu.org; Sat, 14 Jun 2008 13:26:47 -0400 Original-Received: from [199.232.76.173] (port=54136 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7ZWY-0008J6-EN for emacs-devel@gnu.org; Sat, 14 Jun 2008 13:26:46 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:63161) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7ZWX-0007G8-UW for emacs-devel@gnu.org; Sat, 14 Jun 2008 13:26:46 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m5EHQhEr003317; Sat, 14 Jun 2008 11:26:43 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m5EGuOO8018494; Sat, 14 Jun 2008 11:26:43 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3694285301213464286; Sat, 14 Jun 2008 10:24:46 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jun 2008 10:24:46 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjOOgLFetJoVJaXR4eT9QhGTYUGJwABHofA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:99192 Archived-At: > > Wrong type argument: stringp, toc > > Indeed, thanks. It broke info-apropos as well. Should both be > fixed now. > > BTW, I agree with you that the `toc' should be a virtual node rather > than a virtual manual. And the info-apropos should construct a node > "(apropos)" rather than "(apropos)Top". I don't recall saying that, but I agree. ;-) I think I wrote something related a while back about users creating virtual books that way. And I mentioned caching the node list rather than the TOC text. Other than that, I don't recall saying anything related. But it is a good idea. > > But I also think the breadcrumbs, when used at all, should be > > complete - never elided. They should also be filled, so > > that (like the Info body text) they stay within 72 chars without > > wrapping. > > I understand. The current default is a tradeoff: it provides all the > info that was there before and it fits within 80 columns in my tests > (i.e. it doesn't use up more screen real-estate than before). Info text is, AFAICT, generally filled to 72 columns, not 80. The same should hold for all header-area lines (including breadcrumbs). Node names can, as you said, be long sometimes. Long enough to call for filling breadcrumbs. Eliding does not help users. If you insist, keep eliding as an option, but please always show the complete breadcrumbs path, by default. 99% of the time, no filling or eliding will be necessary. For the remaining 1%, filling is better than eliding. When someone hits that 1%, s?he shouldn't be surprised with elision. Most users will not think to look into the doc to see if there is a way to show what's elided. Users who are surprised by a filled path and also bothered by it are more likely to look for a way to turn it off. More importantly, in the one case there is loss of information and functionality, in the other case there is only a minor loss of screen space. Better to show the information, wrapping it as needed - least surprise. (What the `...'? Where did the rest of it go?) > > I'd suggest therefore getting rid of the depth user option > > altogether. If you feel you must keep it, then please make its > > default value 5, which includes everything (the 4 possible > > section levels plus the top level). By default, at > > least, no breadcrumb nodes should be elided. > > Not eliding breadcrumbs means that we would occasionally use up more > screen real-estate than before. Some users may like it, others won't. > The current choice seems safer. Very occasionally. And some users might not like some of the other changes that we've made here. And users can choose not to use breadcrumbs. Eliding means that occasionally we would not show the intermediate nodes. Some users might not like that... It will not be obvious to them where they are or how to get to those nodes - there are no commands to do so. If we fill instead of elide, it might not be obvious to users how to get rid of the extra breadcrumbs lines, but at least no one loses any information or navigation actions that way. > > The question is what should be dropped when using ellipsis. The > > current and top nodes are the least important parts to keep in the > > breadcrumbs, for the reasons I gave. _If_ you drop anything, they > > should be dropped. > > Maybe to you they are the least important pieces of info, but they're > the only piece of info that was there before, this seems to indicate > that there's a good chance they are *more* important. You are misrepresenting what I said. It is less important to duplicate them in breadcrumbs, because they are visible elsewhere and because we have commands (u and t) to go to them directly. I am not saying that up and top are less useful. > I've never removed the Info-fontify-maximum-menu-size > binding, I've just moved it elsewhere. Ah, yes, I missed that.