From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 'Juri Linkov' <juri@jurta.org>, emacs-devel@gnu.org
Subject: RE: breadcrumbs for Info . . . . . .
Date: Sat, 14 Jun 2008 02:45:47 -0700 [thread overview]
Message-ID: <00b601c8ce03$6c7db2e0$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <jwvwskt7ygs.fsf-monnier+emacs@gnu.org>
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
> > It is the breadcrumbs line where
> > space is critical; it is likely to be longer than the
> > header-line.
>
> In my tests (and with my setup), the header-line already tends to
> overflow more than the breadcrumbs
I said header-line, but I meant the second line (what is it called?). Are you
perhaps using a nil value for `Info-use-header-line'? The default value is t (at
least on Windows). In the default case, it is the breadcrumbs line that is
likely to be longest.
Personally, as I said, I _like_ the addition of the top and current nodes to the
breadcrumbs, and their removal from the second line (or the first line, if
`Info-use-header-line' is nil). (I didn't do that myself because I figured there
would be too much resistance to a change that removes them from their
traditional spot.)
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'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.
> I introduced the depth first and foremost to ensure termination.
I saw that, and that in itself is fine. I'm talking about the option. You can
still use depth (5) in the code to ensure termination, without having a depth
user option. Your code just uses the option to initialize the internal depth
counter.
> > . 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.
However, I really think nothing should ever be dropped (elided) from the
breadcrumbs. Instead, they should just be filled at 72 chars (splitting at `>').
> > . You might want to bind `Info-fontify-maximum-menu-size' to
> > nil, as I did, for the calls to `Info-goto-node'. That will
> > save useless extra fontification.
>
> You misread the code.
It's possible. But FWIW I followed it (my version, which stopped only at Top,
not via depth) in the debugger, and that binding did save unnecessary work. But
that was only manifested in certain nodes (Multiple Displays, IIRC).
BTW, I wonder if there isn't a bug in the text of node Multiple Displays.
Looking at its raw text, it seems different from its siblings: no explicit Up,
Prev, or Next; no underline of the node title. Perhaps this difference is what
caused the extra fontification attempts that I saw (related to the fragility of
the Top test)?
next prev parent reply other threads:[~2008-06-14 9:45 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 [this message]
2008-06-14 16:16 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00b601c8ce03$6c7db2e0$0200a8c0@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=juri@jurta.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.