From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>,
"'Thien-Thi Nguyen'" <ttn@gnuvola.org>
Cc: emacs-devel@gnu.org
Subject: RE: breadcrumbs for Info . . . . . .
Date: Fri, 13 Jun 2008 08:12:26 -0700 [thread overview]
Message-ID: <004e01c8cd67$e4184320$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <jwvk5gt4esn.fsf-monnier+emacs@gnu.org>
> > Bias note: personally, i dislike features that use screen space.
> > If there is another line taken for breadcrumbs, i will find a way
> > to remove it.
>
> Of course, that's always a problem. Emacs being what it is, we'll of
> course make it an option. This said, I think it'd be
> worthwhile to try and make it all fit onto the existing header-line.
I don't think so, except perhaps when it would still keep the header-line less
than 70 chars. Info files generally are formatted to be at most 70 (or perhaps
72, it seems) chars wide - and that's a good thing.
The combination of (a) header line, (b) the next line (what's it called?) with
File and Node, and (c) breadcrumbs could perhaps be optimized _sometimes_ to
take up only two lines.
However, we wouldn't gain much doing that, and users would lose some
predictability wrt where things are located. It's important that the same thing
(e.g. File) always be in essentially the same location.
In no case should any of these three lines be wider than the 70//72 chars that
are used for the buffer text itself. That already occurs for a few nodes now, I
believe, which is too bad. Before the existence of a standalone header line,
that happened quite often - the header line brought sanity to the header area.
It is much better, IMO, to sacrifice another line, when things don't all fit on
the same line within 70 columns, than it is to have a superwide line.
> One way to make it might be to abbreviate node names. But
> I'm not sure how best to do that. Maybe we should try to elide/abbreviate
> a (sequence of) word from a node name when that (sequence of) word
> already appears in the node's parent.
The node name, which appears in the mode line and the Node field, is already
abbreviated wrt the node (section) title. That's sufficient, and most of the
node names are quite short. There should be a single, canonical node name, used
everywhere. Abbreviating node names more than that, especially automatically, is
a bad idea.
If some node names are currently too long, then they should be shortened, on a
case-by-case basis, taking into account the context. Sometimes node names that
are too long reflect insufficient document structure, which can be relieved by
restructuring.
More commonly, names are too long out of laziness. It takes thought to find
appropriate shorter names - an automatic abbreviation mechanism will not cut the
mustard.
Occasionally the fault is (presumably) politics: "GNU Free Documentation
License" instead of just "GNU License", "GFDL", or "License".
next prev parent reply other threads:[~2008-06-13 15:12 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 [this message]
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
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='004e01c8cd67$e4184320$0200a8c0@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=ttn@gnuvola.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 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.