bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual

bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual

[Bruno Félix Rezende Ribeiro]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Hello Emacs developers,

The inlined patch implements the (already expected) generation of
multi-file package long description from a potential README file
residing inside the package’s content directory.  Currently Emacs only
implements the long description generation from commentary sections and
for single-file packages.

This behavior is documented in ‘(elisp) Multi-file Packages’ and the
function ‘package-upload-buffer-internal’ from ‘package-x.el’ had a
‘FIXME: Get it from the README file.’ right on the spot of this
implementation.


Let me know if any change is necessary.  Thanks!



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: package-x-multi-file-README-long-description.patch --]
[-- Type: text/x-diff, Size: 748 bytes --]

diff --git a/lisp/emacs-lisp/package-x.el b/lisp/emacs-lisp/package-x.el
index 2815be3..d929cf5 100644
--- a/lisp/emacs-lisp/package-x.el
+++ b/lisp/emacs-lisp/package-x.el
@@ -205,7 +205,10 @@ if it exists."
 	       (commentary
                 (pcase file-type
                   ('single (lm-commentary))
-                  ('tar nil))) ;; FIXME: Get it from the README file.
+                  ('tar (when (file-exists-p "README")
+                          (with-temp-buffer
+                            (insert-file-contents "README")
+                            (buffer-string))))))
                (extras (package-desc-extras pkg-desc))
 	       (pkg-version (package-version-join split-version))
 	       (pkg-buffer (current-buffer)))

[-- Attachment #3: Type: text/plain, Size: 259 bytes --]



-- 
 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     xmpp://oitofelix@riseup.net

bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual

[Stefan Kangas]

Bruno Félix Rezende Ribeiro <oitofelix@gnu.org> writes:

> The inlined patch implements the (already expected) generation of
> multi-file package long description from a potential README file
> residing inside the package’s content directory.  Currently Emacs only
> implements the long description generation from commentary sections and
> for single-file packages.
>
> This behavior is documented in ‘(elisp) Multi-file Packages’ and the
> function ‘package-upload-buffer-internal’ from ‘package-x.el’ had a
> ‘FIXME: Get it from the README file.’ right on the spot of this

Did you see the function package--get-description?  In there, we also
consider other names for the README file.  Could we perhaps base
ourselves on that code somehow?

Best regards,
Stefan Kangas

bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual

[Bruno Félix Rezende Ribeiro]

Hello Stefan,

> Did you see the function package--get-description?

I hadn’t seen that.  It seems that is not available in 26.3, but in master.
Thanks for pointing it out!


> In there, we also consider other names for the README file.  Could we
> perhaps base ourselves on that code somehow?

I think it’s a good idea to try to read all those READMEs in turn until
the first one succeeds, like it’s done there.  Are you proposing
something deeper?


-- 
 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     xmpp://oitofelix@riseup.net

bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual

[Stefan Kangas]

Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>:

> > In there, we also consider other names for the README file.  Could we
> > perhaps base ourselves on that code somehow?
>
> I think it’s a good idea to try to read all those READMEs in turn until
> the first one succeeds, like it’s done there.  Are you proposing
> something deeper?

No, that sounds good to me.  I'm mostly thinking about how to avoid
(even more) code duplication.  This is probably at least somewhat
related to my comments on your patch in Bug#37548.

Best regards,
Stefan Kangas

bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual

[Stefan Kangas]

Hi Bruno,

Bruno Félix Rezende Ribeiro <oitofelix@gnu.org> writes:

>> In there, we also consider other names for the README file.  Could we
>> perhaps base ourselves on that code somehow?
>
> I think it’s a good idea to try to read all those READMEs in turn until
> the first one succeeds, like it’s done there.  Are you proposing
> something deeper?

Did you get any further with this?

Best regards,
Stefan Kangas