From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>,
Stefan Monnier <monnier@iro.umontreal.ca>
Cc: bug#36478 <36478@debbugs.gnu.org>
Subject: bug#36478: Perhaps rearrange *Help* buffer a bit?
Date: Mon, 8 Jul 2019 16:21:52 -0700 (PDT) [thread overview]
Message-ID: <3c3e15e3-ab92-430a-ba21-adb6224cbb55@default> (raw)
In-Reply-To: <m3bly4yxgq.fsf@gnus.org>
> > Here's my favorite color:
> > - don't move it to the end, because it's much too far.
> > - hide it by default, with some obvious-enough button-like thingy to
> > expand it on demand.
> > - maybe the first line could also be moved into this "metadata" block.
>
> A button that says "Technical details..." or something? Or... a
> text-less button would perhaps be better.
FWIW, I think I disagree with handling all such
"metadata" equally, e.g. hiding it all by default.
To me, it makes sense to show, without fishing, that
a function is autoloaded (e.g. not yet loaded),
compiled, etc.; and to show its definition location,
with a link to it; and to show a link to its advice
- especially if the advice changes the doc (which is
what the help is mainly for); and to show a variable's
value.
Such things are helpful for most users, I think, and
they're not in the way. Such things are not so
concerned with "our" implementation details as they
are with the definition - what the thing is/does.
This is a bit like using `C-u C-x ='. Both kinds
of help can and do show lots of information. And
it's not good to overwhelm users at the outset with
too much info, especially in a not-very-organized
way.
But I think that for `*Help*' the info we've long
shown is pretty much user-oriented. It's more a
question of organization. I objected, in bug
#36478, to sticking the following kind of info
near the top, before even the first line of the
doc string:
This function has a compiler macro 'zerop--anon-cmacro'.
Dunno how useful that info is, but a priori that's
not the place to stick it, IMO.
Many users (I'm one) have no clue what a "compiler
macro" is or why they should care. (And it's not
explained in the manual, which is a big part of
what bug bu#36478g is about.)
But if that info is actually useful for users (I'm
ignorant, so can't judge that) and if it were put
at or near the end of `*Help*' (and if "compiler
macro" got documented, and especially if those
words linked to the place in the manual where that's
documented), then I'd have no problem with it.
next prev parent reply other threads:[~2019-07-08 23:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 20:18 Perhaps rearrange *Help* buffer a bit? Lars Ingebrigtsen
2019-07-08 20:29 ` Drew Adams
2019-07-08 20:31 ` Drew Adams
2019-07-08 21:14 ` bug#36478: " Stefan Monnier
2019-07-08 21:14 ` Stefan Monnier
2019-07-08 22:26 ` bug#36478: " Lars Ingebrigtsen
2019-07-08 23:21 ` Drew Adams [this message]
2019-07-08 23:30 ` Stefan Monnier
2019-07-09 13:58 ` Lars Ingebrigtsen
2019-07-09 14:18 ` Stefan Monnier
2019-07-10 3:58 ` Howard Melman
2019-07-10 11:27 ` Lars Ingebrigtsen
2019-07-10 12:59 ` Howard Melman
2019-07-10 14:06 ` Drew Adams
2019-07-08 21:24 ` Basil L. Contovounesios
2019-07-08 22:38 ` Lars Ingebrigtsen
2019-07-09 0:02 ` Eric Abrahamsen
2019-07-09 0:59 ` Basil L. Contovounesios
2019-07-09 3:26 ` Eric Abrahamsen
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=3c3e15e3-ab92-430a-ba21-adb6224cbb55@default \
--to=drew.adams@oracle.com \
--cc=36478@debbugs.gnu.org \
--cc=larsi@gnus.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.