* bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual
@ 2019-09-29 3:52 Bruno Félix Rezende Ribeiro
2019-09-30 17:35 ` Stefan Kangas
0 siblings, 1 reply; 5+ messages in thread
From: Bruno Félix Rezende Ribeiro @ 2019-09-29 3:52 UTC (permalink / raw)
To: 37546
[-- 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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual
2019-09-29 3:52 bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual Bruno Félix Rezende Ribeiro
@ 2019-09-30 17:35 ` Stefan Kangas
2019-10-02 1:56 ` Bruno Félix Rezende Ribeiro
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Kangas @ 2019-09-30 17:35 UTC (permalink / raw)
To: Bruno Félix Rezende Ribeiro; +Cc: 37546
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual
2019-09-30 17:35 ` Stefan Kangas
@ 2019-10-02 1:56 ` Bruno Félix Rezende Ribeiro
2019-10-02 9:31 ` Stefan Kangas
2020-01-23 22:21 ` Stefan Kangas
0 siblings, 2 replies; 5+ messages in thread
From: Bruno Félix Rezende Ribeiro @ 2019-10-02 1:56 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Bruno Félix Rezende Ribeiro, 37546
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual
2019-10-02 1:56 ` Bruno Félix Rezende Ribeiro
@ 2019-10-02 9:31 ` Stefan Kangas
2020-01-23 22:21 ` Stefan Kangas
1 sibling, 0 replies; 5+ messages in thread
From: Stefan Kangas @ 2019-10-02 9:31 UTC (permalink / raw)
To: Bruno Félix Rezende Ribeiro; +Cc: 37546
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual
2019-10-02 1:56 ` Bruno Félix Rezende Ribeiro
2019-10-02 9:31 ` Stefan Kangas
@ 2020-01-23 22:21 ` Stefan Kangas
1 sibling, 0 replies; 5+ messages in thread
From: Stefan Kangas @ 2020-01-23 22:21 UTC (permalink / raw)
To: Bruno Félix Rezende Ribeiro; +Cc: 37546
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-01-23 22:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-29 3:52 bug#37546: 26.3; Implement multi-file package README long description generation as described by elisp manual Bruno Félix Rezende Ribeiro
2019-09-30 17:35 ` Stefan Kangas
2019-10-02 1:56 ` Bruno Félix Rezende Ribeiro
2019-10-02 9:31 ` Stefan Kangas
2020-01-23 22:21 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).