all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stephen Leake <stephen_leake@stephe-leake.org>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: installed packages long description.
Date: Tue, 11 Dec 2018 17:46:59 -0800	[thread overview]
Message-ID: <86r2enecto.fsf@stephe-leake.org> (raw)
In-Reply-To: <jwvmupbalp9.fsf-monnier+gmane.emacs.devel@gnu.org> (Stefan Monnier's message of "Tue, 11 Dec 2018 15:01:04 -0500")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> And it does not describe "the <pkg>-readme.txt served via HTTP"
>>
>> So we need to add that at least. We could also document the other uses
>> of 'package--with-response-buffer':
>>
>> package--check-signature
>> package--download-one-archive
>> package-install-from-archive
>>
>> Then package.el can reference the elisp manual.
>
> Sounds good.  Can you take care of it?

Yes. 

>>>> from elpa/admin/archive-contents.el, that appears to be:
>>>>
>>>> (archive--get-section
>>>>   "Commentary"
>>>>   '("README" "README.rst" "README.org")
>>>>   srcdir mainsrcfile)
>>>>
>>>> That code could be moved to package.el
>>>
>>> Sounds good.
>
> Can you take care of this as well?

Yes. I won't change the elpa code.

I'll submit a patch for review before committing anything.

>>> As for saying the README and/or Commentary: from now on is assumed to
>>> use Markdown, that will result in ugly text with current/previous
>>> packages which are not written under this assumption.
>> Right, I would say no markup in Commentary: or README, and rely on the
>> file extension for a README*.* .
>
> We could support a new section name ("Description:" or
> "Commentary.org:" or ...) for the "Commentary: with markup".
>
> This said, there's also the possibility to just use Commentary: along
> with a heuristic which would give "mostly correct" results on
> existing Commentaries.
>
> Bonus points if we can change elisp-mode's font-lock so the markup is
> correctly prettified.

I'll leave this for later. Simple package authors can switch to a
multi-file package with a README.* file if they want markup.

>>> Also, there's the old discussion of which markup to use (mostly Org or
>>> markdown).
>> Easiest to allow any that Emacs can display.
>
> I think currently Org is the only markup format that vanilla Emacs can
> render (tho arguably Texinfo is there as well, via makeinfo.el).
>
> Allowing more formats requires more code to handle the various formats,
> so I think we'd be better off only supporting one format.

We have markdown-mode in ELPA, which does a reasonable job. There's also
markdown-preview-eww - I didn't try it.

That's what I meant by "any that Emacs can display"; if there is a mode
(built-in or in ELPA) for the format, that does a reasonable job of
display, then the package author can decide to use that format.

Hmm. It also has to work well on the ELPA web page; that's a
complication.

We might have to use multi-major-mode in the display buffer, for the
headers provided by 'describe-package'.

If the mode is in ELPA and not installed, there needs to be some header
text saying "please install foo-mode to display this better". Or
something. That would be a reason to use only modes bundled with the
standard distribution.

Or the author could provide a plain text README as a fall-back. I
suspect most markdown formatters have an option to output plain text, so
that could be automated.

I don't see an "rst-mode", but I guess that format is meant to be
readable as plain text.

This is less important than getting the correct long description for
installed packages.

-- 
-- Stephe



  reply	other threads:[~2018-12-12  1:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05  1:39 installed packages long description Stephen Leake
2018-12-09 16:38 ` Stefan Monnier
2018-12-09 18:46   ` Stephen Leake
2018-12-10  2:40     ` Stefan Monnier
2018-12-10 19:27       ` Stephen Leake
2018-12-11 20:01         ` Stefan Monnier
2018-12-12  1:46           ` Stephen Leake [this message]
2018-12-12  2:02             ` Stefan Monnier
2018-12-13 14:49               ` Stephen Leake
2018-12-13 15:24                 ` Stefan Monnier
2018-12-13 22:47                   ` Stephen Leake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86r2enecto.fsf@stephe-leake.org \
    --to=stephen_leake@stephe-leake.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.