bug#9054: 24.0.50; show source in other window

[martin rudalics]

>>> Yes, it would be nice to allow displaying the source in the same window
>>> as the *Help* buffer was displayed in.  Martin, can this somehow be done
>>> via `display-buffer-alist', or would we have to add a new user option
>>> for `help-mode' for this?
>>
>> See the discussion of Bug#36767.
>
> Do you mean the help-link-follow patch you proposed there?  I don't
> think that's quite what the user wanted here -- we just want to make the
> pop-to-buffer in help-function-def--button-function not pop to another
> window, but just display in the current window.

Both are about displaying the source in the same window.  And since we
cannot use `display-buffer-alist' here (we'd hardly be able to come up
with a suitable regexp for any buffer that is referenced by *Help*) we
do have to provide a suitable function for displaying the source anyway.

But what I'd like to see first are the typical usage patterns (Eli gave
one) that apply here.  [Personally, I'm using a function bound to
M-<return> that tries to go to the source of any symbol or tag around
point and I usually build up an entire chain of such calls to find the
object I am really interested in.  So I never have to follow a link
from *Help* but instead follow the function or variable name cited at
position 1 of the *Help* buffer via M-<return>.]

Are people usually done after they followed the link once or do they dig
further - in that window?  Do they want to return to the *Help* buffer
after they found what they wanted (probably not) and/or do they want to
restore the window configuration that existed before popping up *Help*.
Eli, for example, wants to keep the *Help* window live - for some time
at least, IIRC.

As soon as we've established these patterns, we can provide a solution
that fixes the `pop-to-buffer' in `help-function-def--button-function'
and in a calling convention based on key combinations only.

martin