RE: [External] : Re: Proposal for an improved `help-for-help'

[Drew Adams <drew.adams@oracle.com>]

> > I've also added links on key descriptions.  I think
> > they help a lot.  I'm not in favor of just coloring
> > keys as you've proposed, as I've said before - it's
> > better to link them to their full help, IMO.
> 
> I have posted a patch to add such links.  Did you not see it?

No, I didn't check your patch.

It's not hard to put links on key descriptions.  I've
been doing that for a long time; I've suggested it for
Emacs more than once; and I pointed you to it recently.
It was a good idea many moon ago, and it still is.

What's unfortunate is to not adopt the appearance of
Emacs links.  You've provided various other appearances
for key-description links so far.  None of them (AFAIK)
are what links look like in Emacs generally (which is
also what links look like by default in most browsers
and so on).  Why is that?  No answer so far, AFAICT.

And if a user wants to change link appearance in
general that's easy to do: just customize face `link'.
Now, I suppose they'll need to customize more than one
face (?).
___

It's also unfortunate, IMO, to not handle sexps in
*Help* the same way we handle them in Lisp comments
and in *Info*: using `...'.

Occam, reuse, principle of least-surprise, etc., all
argue against multiplying appearances like that.  And
in Emacs that also means multiplying behaviors to
learn and keep track of.

When linked, `...' tells you not only that there's
a link, but that the thing quoted is code - a sexp.
When you drop that `...' envelope you stop conveying
that info.  Lossy, not helpful.

All in the name of what?  Supposed "nicer", "cleaner"
appearance, is all we've heard as a reason.

Much technical doc uses a fixed-pitch font for code
and variable-pitch for ordinary text.  Emacs has long
used `...' for code and not had to deal with both
fixed and variable pitch in the same doc/help.

That's not only a fine approach; it's versatile.  It
works with plain-text or fancy.  It's easy to
recognize, font-lock, search, and process by code.

Sometimes what exists already and has long been
practiced is better than what someone dreams up as
an improvement.

A good thing about free software is that anyone can
have new ideas and implement them - things that might
eventually prove, in practice, to be improvements.

What's not so good is when, instead of that happening
in 3rd-party code and being progressively taken up by
users, we get changes to Emacs itself because someone
considers her idea to be a general improvement.

Instead of trial and potential adoption over time, we
get changes in vanilla Emacs behavior or appearance.
That's too bad, IMHO.

At least, please make such changes optional and opt-in.