unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "dieter@duenenhof-wilhelm.de" <dieter@duenenhof-wilhelm.de>,
	"60587@debbugs.gnu.org" <60587@debbugs.gnu.org>,
	"monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>
Subject: bug#60587: Patch for adding links to symbols' help documentation
Date: Mon, 23 Jan 2023 16:16:18 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488DA9C9D033CDBF72C0936F3C89@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <835ycxjvmc.fsf@gnu.org>

> I don't think "button" is problematic.
> 
> > Drew thinks we should use the same standard term we
> > use everywhere - including in Info: for users it's a
> > link, not a button.
> 
> We use "buttons" as well as "hyperlinks".  See, e.g., the node "Mouse
> References" in the user manual, which basically describes the facility
> Dieter intends to use.

You're right - that node speaks of `"buttons", or
"hyperlinks"'.  And node `Scroll Bars' speaks of
"the scroll bar's up and down buttons".

I think such terminology is old - early/mid 90s.
"Hyperlinks" is OK, but in general they're just
referred to as "links" now, I think.  That is, since
the Internet and web took hold in a general way.

The UI things that actually look like buttons, can
reasonably be called "buttons", especially things
that perform some _action_ other than moving to a
different text location.  I think this applies to
icons in the tool bar and fields in the mode-line
and header line, and it applies to some of the spots
in Customize.  I don't think it's the best term to
use for text links.

That there are some remaining places where Emacs or
Elisp still refers to links as "buttons" isn't a
reason to continue using "button" for links, in new
doc or when updating existing doc (IMO).  My advice
is to progressively move away from such a use of
"button" when doing that.

But if you prefer to continue with "button", so be it.

> > > If the user types "M-x describe-text-properties RET",
> > > will he/she see that there's a button at point?
> I meant the hyperlinks in the *Help* buffer.

I see, thanks.  Yes, I see that - e.g.:

There are text properties here:
  button               (t)
  category             help-symbol-button
  help-args            (symbol-nearest-point)

However, again, this kind of help (showing text
properties) essentially exposes _implementation_
names, so that's no surprise.  Yes, Elisp has
things called "buttons".

Nothing wrong with help doing this, of course.
But that's not a reason why the user doc (e.g.
Emacs manual) should call links there "buttons".

The current change is for Info.  What terminology
does the Info manual use?  Searching for "button"
shows that the only occurrences are for mouse
buttons (physical buttons).  And there are lots
of occurrences of "link".  _All_ mention of what
we're talking about uses "link", never "button".
That's how Info talks about itself and its parts.

Here's a typical use of both terms from the Info
manual.  "Link" is the thing you see and click
(or hit `RET' on).  "Button" is a physical mouse
part that you click.

 >> Now type 'n', or click the middle mouse button
    on the 'Next' link, to visit the next node.

But if you prefer "buttons", "buttons" it is.
Users will understand, either way.





  reply	other threads:[~2023-01-23 16:16 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 23:47 bug#60587: 30.0.50; Info pages are lacking links from symbol names to the symbol's help documentation H. Dieter Wilhelm
2023-01-06 19:03 ` bug#60587: Patch for adding links to symbols' " H. Dieter Wilhelm
2023-01-07  7:38   ` Eli Zaretskii
2023-01-08 20:06     ` H. Dieter Wilhelm
2023-01-09 12:46       ` Eli Zaretskii
2023-01-09 14:25         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-09 20:01         ` H. Dieter Wilhelm
2023-01-13 23:33     ` H. Dieter Wilhelm
2023-01-14  7:12       ` Eli Zaretskii
2023-01-15 12:48         ` H. Dieter Wilhelm
2023-01-17 21:53     ` H. Dieter Wilhelm
2023-01-18 13:20       ` Eli Zaretskii
2023-01-20 21:09         ` H. Dieter Wilhelm
2023-01-20 21:59           ` Drew Adams
2023-01-20 23:32           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-22 13:00             ` H. Dieter Wilhelm
2023-01-21  8:21           ` Eli Zaretskii
2023-01-21 20:27             ` H. Dieter Wilhelm
2023-01-22  6:00               ` Eli Zaretskii
2023-01-22 22:09                 ` Drew Adams
2023-01-23 12:14                   ` Eli Zaretskii
2023-01-23 16:16                     ` Drew Adams [this message]
2023-01-25 21:29             ` H. Dieter Wilhelm
2023-01-25 22:24               ` Drew Adams
2023-01-26 10:29                 ` Ihor Radchenko
2023-01-26 15:06                   ` Drew Adams
2023-01-26 15:12                     ` Ihor Radchenko
2023-01-26 15:23                       ` Drew Adams
2023-01-27 21:35                 ` H. Dieter Wilhelm
2023-01-27 22:12                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-27 23:09                     ` Drew Adams
2023-01-27 23:13                   ` Drew Adams
2023-01-28  8:11                     ` Eli Zaretskii
2023-01-28 17:30                       ` Drew Adams
2023-02-01 22:09                     ` H. Dieter Wilhelm
2023-02-02  2:30                       ` Drew Adams
2023-02-05  0:48                     ` H. Dieter Wilhelm
2023-02-05  3:54                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-05 13:54                         ` H. Dieter Wilhelm
2023-02-06 21:04                           ` H. Dieter Wilhelm
2023-02-12 11:04                         ` H. Dieter Wilhelm
2023-02-14 20:56                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 22:18                             ` H. Dieter Wilhelm
2023-02-16  3:08                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-20 23:53                                 ` H. Dieter Wilhelm
2023-02-21  2:12                                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-01 21:45                                     ` H. Dieter Wilhelm
2023-03-11  8:32                                       ` Eli Zaretskii
2023-03-11  9:16                                         ` H. Dieter Wilhelm
2023-02-15  5:17                           ` Richard Stallman
2023-02-15  9:53                             ` Gregory Heytings
2023-02-15 13:42                               ` Gregory Heytings
2023-01-26 10:37               ` Eli Zaretskii
2023-01-27  7:45                 ` Juri Linkov
2023-01-27  8:11                   ` Eli Zaretskii
2023-01-27 22:21                 ` H. Dieter Wilhelm
2023-01-28  7:51                   ` Eli Zaretskii
2023-02-01 21:26                 ` H. Dieter Wilhelm

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=SJ0PR10MB5488DA9C9D033CDBF72C0936F3C89@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=60587@debbugs.gnu.org \
    --cc=dieter@duenenhof-wilhelm.de \
    --cc=eliz@gnu.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 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).