Re: Another input method feature needed

[Juri Linkov <juri@jurta.org>]

>>> Let's not let this fall into oblivion the second time.  Any objections
>>> against Juri including the library into Emacs and continuing integrating
>>> it/working on it (or the other way round)?
>
> If it's in a usable state, it can be installed.  If not, then maybe it
> can be split into smaller steps where each step is in a usable state.

Currently the code is too ugly to install.  I'd like to refactor
help functions first.

>> In any case it would be useful to split help functions into two parts:
>
>> 1. data collection that returns data structures with help information;
>> 2. view generation that renders the output according to defined layouts.
>
> Feel free to install refactoring patches that do that.

Refactoring patches are not ready yet.  I'm thinking about
what is the best way of doing that.  Actually for the data part
there is already exists something similar to what we need:
for advised functions `ad-get-advice-info' returns an alist with
information about an advised function:

      ((active . t/nil)
       (before adv1 adv2 ...)
       (around adv1 adv2 ...)
       (after  adv1 adv2 ...)
       (activation  adv1 adv2 ...)
       (deactivation  adv1 adv2 ...)
       (origname . <symbol fbound to origdef>)
       (cache . (<advised-definition> . <id>)))

We could create a new function `describe-function-info' that will return
a similar alist with information about all functions with association keys
like `docstring', `file-name', `keybindings', `arglist', `obsolete', etc.
And similarly for other help functions: `describe-variable-info',
`describe-face-info', ...

For the view part we need a templating library.  I think the most suitable
is skeleton.el.  It is used successfully in autoinsert.el to generate
large complex text blocks.  So we could use skeleton.el and add new
variables `describe-function-skeleton', `describe-variable-skeleton', ...

-- 
Juri Linkov
http://www.jurta.org/emacs/