Re: ~Make emacs friendlier: package documentation [POC CODE INCLUDED]

[Eli Zaretskii]

> Date: Thu, 15 Oct 2020 15:41:32 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: emacs-devel@gnu.org
> 
> I just now double-checked, and my "C-h P" binds to a function
> `describe-package'. Is that what you mean? That function produces very
> different content in a very different format. What I submitted is
> proof-of-concept code, which *could* be integrated into
> `describe-package'; I'm not picky. Here are some of the differences:
> 
> 
> + describe-package doesn't operate on all emacs-lisp files
>   + try performing it on `dired' or dired.el
> 
> + describe-package does in fact extract the *first* section of header
>   documentation commentary.
>   + What it omits, that is in the proposal is all the rest of the header
>     documentation, which in many cases includes information on
>     installation, configuration, usage, examples, known bugs, etc.
> 
> + describe package provides information on package 'status' (eg.
>   built-in, external) which isn't in my POC.
> 
> + My POC function additionally formats and presents *all* the
>   documentation for all the package's symbols.
>   + and it's done in an org-mode hierarchy for your navigating pleasure.

Thanks.  To me this sounds like your code could be used to extend "C-h P"
in useful ways.  Perhaps the result of "C-h P" should include a button
"More information" or something that could produce an Org buffer with
the additional stuff.  WDYT?

The main point, I think, is not to create another command whose
functionality overlaps with an existing one, but instead extend the
existing command to do more when requested.