Hello Nicholas,
On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote:
> Would it be better to ship README.org and file a bug against the
> package myself?
Yes. Why not ship README.org in the interim?
> I still don't have a plan for Policy 12.4, and am currently wondering
> if further conversion of README.html to README using html2txt (if
> pandoc cannot do this) would be best, because the expectation is that
> the upstream README found in /usr/share/doc is a plain text file.
I don't think Policy 12.4 really applies to READMEs. It says "extensive
documentation", and a README is not extensive documentation.
Policy 12.4 is basically saying "ship HTML instead of PDF".
> So this?:
>
> - Copyright: 2014, 2015 Free Software Foundation, Inc.
> - 2014-2016 Artur Malabarba <emacs@endlessparentheses.com>
>
> +Copyright: 2014-2016 Free Software Foundation, Inc.
> + <this line actually gets deleted>
Yes.
> > - your rationale for uploading to experimental applies to
> > smart-mode-line, but why not upload rich-minority to unstable? Is
> > it similarly untested? Maybe we should just wait a few weeks.
>
> If you'd prefer I'd be happy to wait a few weeks. In terms of
> worst-case scenario planning: If for some reason smart-mode-line
> upstream didn't add emacs26 compatibility in time for Buster's freeze,
> and I (or someone from pkg-emacsen) didn't have time to add it, then
> should rich-minority still be part of Buster?
It would depend on whether a user of buster gets emacs25 or emacs26 if
they type "apt-get install emacs".
> How many lines can I dedicate to this? By my count I need to
> summarise the following in five lines, and the most salient additions
> are the mention of diminish.el, plus compare/contrast by adding what I
> suspect are the two most salient points.
> * "/missing/...quick and simple replacement functionality"
> * the addition of "It accepts *regexps* instead of [individual specifications]".
Where are you getting this line limit from?
> These two points seem contradictory to me. Do you know how
> diminish.el is more quick and simple? Also, can I use your answer for
> a patch against the upstream description, because I might not be the
> only one who's not confused about this. Failing that, I can open an
> upstream issue/request for clarified description.
diminish.el works like this:
(diminish 'auto-fill-function)
That's it. Clearly simpler.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature