bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> For example, ‘C-h f’ (describe-function) first calls a back-end function
>> that collects all information about a function and returns it in a such form:
>>
>>    ((type . function)
>>     (name . "car")
>>     (source-file . "src/data.c")
>>     (Info-node . "(elisp) List Elements")
>>     (docstring . ...)
>>     ...)
>>
>> Then it gives this data to a front-end function that will render it
>> as buttonized text in the Help buffer, or as html in a eww buffer,
>> or as Info markup in an Info buffer, etc.
>
> And ‘describe-function-help-front-end’ would peruse that information.

‘describe-function’ is already a front-end function for the help buffers.
But the problem is that it currently also amalgamates back-end code to it.

> And 'describe-key-help-front-end' would use a 'key' entry.
> But what would you pass to 'view-lossage-help-front-end'?

'view-lossage' is already a very simple function, no need
to add a back-end for it.

> Anyway I seem to see what you have in mind: Each front end would have
> its own rules for how to render the cdr of 'type' or 'name' entries.
> And the back end would not be concerned with rendering.

Exactly.

>>>> Indeed, now there are such modifiers: ‘C-x 4 0’ and ‘C-x 4 4’.
>>>
>>> I meant modifiers for mouse-1 clicks on the menu entry.
>>
>> But ‘C-x 4 0’ and ‘C-x 4 4’ already do what is needed,
>> and indeed I tested these work fine: ‘C-x 4 0 down-mouse-3’.
>
> That's not for people who start to explore Emacs via the context menus.
> Since you are currently writing them from scratch, they should provide a
> simpler interface IMHO.  I'd say C-<mouse-1> should pop up the desired
> information in another window, M-<mouse-1> in another frame, ...

But C-<mouse-1> and M-<mouse-1> are already bound.