unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Juri Linkov' <juri@jurta.org>, emacs-devel@gnu.org
Subject: Re: breadcrumbs for Info . . . . . .
Date: Sat, 14 Jun 2008 12:16:18 -0400	[thread overview]
Message-ID: <jwvy758dmyc.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <00b601c8ce03$6c7db2e0$0200a8c0@us.oracle.com> (Drew Adams's message of "Sat, 14 Jun 2008 02:45:47 -0700")

> BTW, your changes introduced a bug:
> emacs -Q
> load your info.el (from CVS)
> C-h i
> choose Emacs manual
> T

> 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)<query>" rather than "(apropos)Top".

> 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).

> 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.

>> > . When using ellipsis, I suggest dropping first the current
>> >   node name and the file+top - precisely the parts you keep.
>> 
>> I keep them precisely because they were there before.

>> The number of nodes actually displayed depends on too many 
>> things: to be really precise, the docstring would need to be overly 
>> complex.

> 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 misread the code.
> It's possible.

It's sure.  And you misread my above sentence by "the" I meant "my":
I've never removed the Info-fontify-maximum-menu-size binding, I've just
moved it elsewhere.


        Stefan




  reply	other threads:[~2008-06-14 16:16 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-10 23:52 breadcrumbs for Info . . . . . Drew Adams
2008-06-11  0:04 ` Juri Linkov
2008-06-11  3:18   ` Drew Adams
2008-06-11  9:34     ` Juri Linkov
2008-06-11 13:46       ` Drew Adams
2008-06-11 18:59         ` Eli Zaretskii
2008-06-11 22:40         ` Juri Linkov
2008-06-12  2:01           ` Miles Bader
2008-06-12 22:42           ` Drew Adams
2008-06-13  3:27             ` Stefan Monnier
2008-06-13  6:34               ` Drew Adams
2008-06-13  8:43                 ` Thien-Thi Nguyen
2008-06-13 13:55                   ` Drew Adams
2008-06-13 17:17                     ` Thien-Thi Nguyen
2008-06-13 17:52                       ` Drew Adams
2008-06-13 19:55                         ` Thien-Thi Nguyen
2008-06-13 20:10                           ` Drew Adams
2008-06-15 18:19                           ` Juri Linkov
2008-06-13 14:05                   ` Stefan Monnier
2008-06-13 15:12                     ` Drew Adams
2008-06-13 17:16                       ` Stefan Monnier
2008-06-13 18:32                     ` Thien-Thi Nguyen
2008-06-14  9:47                       ` Eli Zaretskii
2008-06-14 10:01                         ` Thien-Thi Nguyen
2008-06-13 13:58                 ` Stefan Monnier
2008-06-13 15:11                   ` Drew Adams
2008-06-13 20:34                     ` Stefan Monnier
2008-06-13 22:11                       ` Drew Adams
2008-06-13 22:44                         ` Stefan Monnier
2008-06-14  9:45                           ` Drew Adams
2008-06-14 16:16                             ` Stefan Monnier [this message]
2008-06-14 17:24                               ` Drew Adams
2008-06-14 18:04                                 ` Stefan Monnier
2008-06-15  0:27                                 ` Juri Linkov
2008-06-15  7:33                                   ` Drew Adams
2008-06-15 18:23                                     ` Juri Linkov
2008-06-15 19:46                                       ` Drew Adams
2008-06-15  0:28                       ` Juri Linkov
2008-06-15  2:04                         ` Stefan Monnier
2008-06-15 18:18                           ` Juri Linkov
2008-06-15  7:55                         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvy758dmyc.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).