bug#36767: [External] : bug#36767: 26.1; request: add more quick keys to the *Help* buffer

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

> >     Eli> And that need to go to *Help* is, for me, the single significant
> >     Eli> annoyance with Help commands.  For example, I frequently want to
> look
> >     Eli> at the source of a function whose doc string I just requested, and
> its
> >     Eli> a nuisance to have to click on the button there or go to the
> *Help*
> >     Eli> buffer, find the button, and press RET.
> >
> > I guess you donʼt like (setq help-window-select t)
> 
> The nuisance is to have to switch to the Help window.  That variable
> saves the command to switch to it, but it doesn't change the fact that
> you are no longer in your original window/buffer.  Viewing help
> shouldn't interfere with the window/buffer where you do your main
> work, IMO.

I think the two are separate/separable.  Your point
about not necessarily always wanting to switch to
the Help window is valid.  But it's also useful to
switch to the Help window automatically.  Whether
that window should be switched to automatically is
governed by a user preference, as it should be.

There are lots of reasons one might want to be in
the Help window.  Whether some actions there might
merit also being available on keys from other
buffers is a different question (and yes, it's the
question of this thread).
___

It might also be possible for help commands to have
a particular prefix argument effect the opposite
behavior from `help-window-select'.  E.g., with
that prefix arg, the Help window would be selected
only if `help-window-select' is nil.