bug#9054: 24.0.50; show source in other window

[martin rudalics]

> Nice.  It's a bit of a mouthful for users, though.

It's a bit fragile as well.  We have a `display-buffer' help-args text
property at that position so everything seems in place already.  But I
would have to understand `help-function-def--button-function' first ...

>> Did you try Juri's proposal?
>
> I don't think we can expect users to do all that just to change the
> behaviour of these *Help* commands.

Agreed.

> Perhaps if we put the
> `display-buffer-from-help-p' function into Emacs.

I think we should specify something like a _general_ `display-buffer'
text property that would specify the basic (aka historic) action
(`pop-to-buffer' in the case at hand) here.  Then have `display-buffer',
before it does its `display-buffer-assq-regexp' job, look whether there
"is a `display-buffer' text property around where the user just clicked
or where point is" and perform a corresponding action based on whether
`display-buffer-alist' has a "somehow specified" entry (not a regexp and
not a function) for it and do either that or what the `display-buffer'
text-property says.

> `help-window-select' is (if you squint at it) the kinda-sorta user
> option in the opposite direction,

`help-window-select' is for users who want to get rid of the *Help*
window by just typing "q" thus avoiding the "Type \"q\" in help window"
excursion where they have to explicitly select the *Help* window just to
quit it.

> so perhaps the way forward here is to
> just define a new user option, or all a new value (`both'?) that affects
> how windows are selected from the *Help* window.  I guess a new user
> option would be the simplest.

Agreed.  But we should decide whether we only want it for *Help* windows
and what kind of additional semantics we should support, if any.

martin