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

Previous Next

To reply to this bug, email your comments to 37546 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: oitofelix <at> gnu.org (Bruno Félix Rezende Ribeiro)
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3;
 Implement multi-file package README long description generation as
 described by elisp manual
Date: Sun, 29 Sep 2019 00:52:04 -0300

[Message part 1 (text/plain, inline)]

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!

[package-x-multi-file-README-long-description.patch (text/x-diff, inline)]

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)))

[Message part 3 (text/plain, inline)]

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

Message #8 received at 37546 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
Cc: 37546 <at> debbugs.gnu.org
Subject: Re: bug#37546: 26.3; Implement multi-file package README long
 description generation as described by elisp manual
Date: Mon, 30 Sep 2019 19:35:06 +0200

Bruno Félix Rezende Ribeiro <oitofelix <at> 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

Message #11 received at 37546 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>,
 37546 <at> debbugs.gnu.org
Subject: Re: bug#37546: 26.3;
 Implement multi-file package README long description generation as
 described by elisp manual
Date: Tue, 01 Oct 2019 22:56:11 -0300

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 <at> gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     xmpp://oitofelix <at> riseup.net

Message #14 received at 37546 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
Cc: 37546 <at> debbugs.gnu.org
Subject: Re: bug#37546: 26.3; Implement multi-file package README long
 description generation as described by elisp manual
Date: Wed, 2 Oct 2019 11:31:55 +0200

Bruno Félix Rezende Ribeiro <oitofelix <at> 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

Message #17 received at 37546 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
Cc: 37546 <at> debbugs.gnu.org
Subject: Re: bug#37546: 26.3; Implement multi-file package README long
 description generation as described by elisp manual
Date: Thu, 23 Jan 2020 23:21:56 +0100

Hi Bruno,

Bruno Félix Rezende Ribeiro <oitofelix <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.