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: Sat, 28 Jan 2023 17:30:47 +0000	[thread overview]
Message-ID: <CO6PR10MB5473B1EE256000B74DFAC323F3CD9@CO6PR10MB5473.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83cz6zaxjt.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]

> > I think it's _good_ to have a separate face
> > for this.
> 
> I disagree that another face is a Good Thing.
> We have too many of them already.

I respectfully disagree.  I'll give my reasons
here, then call it quits.

Nothing prevents the new face from, by default,
inheriting its appearance from the other one.
(Though I'd much prefer that it not do that by
default.)

And nothing prevents its doc from pointing out
that that's the case.  So customizing the Info
link face gives the new Info *Help* link face
the same appearance (but not vice versa).

By inheriting, there is, in effect, a general
category: link in Info, and you can either have
all links in Info look the same or have the
two kinds look different.

> > That gives users the choice:
> >
> > * Have the same appearance for both kinds of link.
> > * Have the two kinds of link (Info, *Help*) look
> >   different.
> >
> > When you provide two faces, users can always customize
> > them to look the same, if they like.  Otherwise, they
> > don't have that possibility.
> 
> The downside of having a separate face is the need 
> to know about it and customize it separately.

"_Need_ to know about it"?  Why/when does anyone
need to know about it, any more than they need
to know about the Info link face?

Users can check which face is used somewhere,
and show both kinds of links with either
`list-faces-display' or `M-x customize-face'.

(BTW, shouldn't the Info faces for links be
included in group `info-xref-group'?  You
should be able to do `M-x customize-group
info-xref-group' and see `info-xref',
`info-xref-visited' and `info-header-xref'.)

> we should introduce new faces only if they
> really are for a different purpose.  This one
> isn't.

I think it is.  It's not for Info navigating.
It's not for following Info cross-references.
Its purpose is something different.

More importantly than what I think perhaps, is
that if you give users the choice, so they can
see a difference, and if some make the choice
to see it, they will have demonstrated that -
for them - the two do have different purposes.

This isn't really different from the choice we
made to have _three_ faces for following Info
xrefs: `info-xref', `info-xref-visited', and
`info-header-xref'.  Someone chose to have 3,
not 1, face for this.

I don't expect to convince you, and you've
maybe already decided about it.  But I'd like
to state my position and reasons about this.

The question about "too many faces" comes up
periodically.  Just as in taxonomy discussions,
there are those who are more "clumpers" and
those who are more "splitters".  When it comes
to faces, I tend to be more of a splitter.
(When it comes to letting users customize their
editor, Emacs itself is very much a splitter!)
___

Finally, here's an example of another Info
link face, which I added in my code.  It links
glossary words to their definitions in the
Glossary.  Unlike the new *Help* links, this
one is, like the *xref* faces, for navigating
in Info.

And like the new *Help* links, users are able
to hide/show its links on the fly.  Equally
important, only the _first_ occurrence in a
node of a given word is linked.  That too
would be useful for the new *Help* links, as
opposed to linking every occurrence of the
same symbol name (too noisy).

More generally, users can choose how and when
to show glossary links.

In addition to linking them, glossary words
in the text can show their definitions on
mouseover.

(Going to the Glossary lets you follow links
within the Glossary.  But there aren't many
of those, and a user might prefer to just
see definitions on mouseover.)

Choices (option `Info-link-glossary-words'):

1. Never (off).  Not even an invisible link.
2. Only until a link for that word has been
   visited.  But show a tooltip with the
   word's definition on mouseover.
3. Only until visited (no mouseover tooltip).
4. Always.  And show mouseover tooltip.
5. Always.  No mouseover tooltip.
6. Never - an invisible link, but show
   mouseover tooltip.
7. Never - invisible link, and no mouseover
   tooltip.

The default is #2.  Attached are screenshots
showing #2/#3, #5, and #6.

A toggle command toggles the option between
#1 (a nil value) and the last used of the
others (non-nil values).  A cycle command
cycles the option among the possible values.

[-- Attachment #2: throw-emacs-info-gloss-links-face+def.png --]
[-- Type: image/png, Size: 77997 bytes --]

[-- Attachment #3: throw-emacs-info-gloss-face-until+NO-def.png --]
[-- Type: image/png, Size: 66006 bytes --]

[-- Attachment #4: throw-emacs-info-gloss-links-NOface+def.png --]
[-- Type: image/png, Size: 73413 bytes --]

  reply	other threads:[~2023-01-28 17:30 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
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 [this message]
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=CO6PR10MB5473B1EE256000B74DFAC323F3CD9@CO6PR10MB5473.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).