bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> To support a text property or overlay by display-buffer would be nice.
>
> If called `display-buffer', that property's value would appear like a
> `display-buffer-alist' entry - a <PROPERTY, ACTION> pair that would be
> run by `display-buffer' like an overriding action.
>
> Users could inhibit that by adding to their `display-buffer-alist' a
> <PROPERTY, USER-ACTION> entry where USER-ACTION nil would mean to not
> run ACTION and USER-ACTION some other action would mean to run that
> other action instead of ACTION.

Looks like a good plan.

>> But a new user option is still needed for help-mode, so it could
>> put the right value on text properties in the Help buffer.
>
> Lars would like to rewrite help mode from scratch anyway, so I think
> that would be a good occasion to do that.  In either case we should be
> able to handle mouse clicks, keyboard input like "s" and "i", context
> menus and external handling of *Help* navigation from another buffer in
> a uniform way.

We desperately need to separate the help back-end from its presentation layer.
The back-end should collect information and return it as alists. And
the front-end should display it in the *Help* buffer.

> BTW: IMHO right clicking on a Lisp Object in Elisp mode with
> `context-menu-mode' enabled should list
>
> (1) Help for this object
>
> (2) Manual entry of this object

Good idea.  This should be added to emacs-lisp-mode.

> _first_.  And Find Definition should allow to choose whether to do that
> in another window/frame in the Context Menu.

Wouldn't then the context menu grow too long?  Instead of current 3 items:

  "Find Definition"
  "Find References"
  "Back Definition"

it will show 3x3 items:

  "Find Definition"
  "Find References"
  "Back Definition"
  "Find Definition in another window"
  "Find References in another window"
  "Back Definition in another window"
  "Find Definition in another frame"
  "Find References in another frame"
  "Back Definition in another frame"