Hi Sean,
On Tue, Jun 13, 2017 at 06:42:28PM +0100, Sean Whitton wrote:
> 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".
Ok, I'll default to shipping *.orgs for now as I learn more about
pandoc and how it should be used. This won't be necessary for
rich-minority, because I discovered pandoc supports plaintext output
(see commit f0e90360 of rich-minority).
I think for phase two I should probably add pandoc to overrides in
d/rules for my other packages, paying attention to where fixups are
required (eg: those sed rules in rich-minority, which are needed for
pandoc-1.12.4.2~dfsg-1+b14). Before doing this I ought to upgrade to
Stretch, because otherwise all this might be "make-work-project" that
potentially only reveals the shortcomings of
pandoc-1.12.4.2~dfsg-1+b14.
Phase three seems like it should be contacting the Debian pandoc
maintainers with an inquiry to whether pandoc could detect and
work-around these issues on its own. This will eliminate the sed
fixups.
Phase four: Do you think that it would be useful to have
d/package.convert-to-info, d/package.convert-to-text, etc? This would
allow a plain d/rules.
Alternatively, it might be a better use of time to just write a
Makefile to generate the docs for each package, and then submit those
to upstreams. What do you think? If ELPA/MELPA are already taking
care of this without Makefiles I'm not sure how useful this would be
for the overall emacs-elpa ecosystem... If we go the Makefile route
then we should put the Makefile example/template somewhere that is
accessible the the pkg-emacsen team.
What do you think? Does this sound like a good proposal? When should
I email pkg-emacsen? After Stretch is released?
> > > - 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".
Hmm, so the question comes down to how committed and able I am to get
rich-minority (and smart-mode-line for that matter) to work with a
potential default of emacs26 for Buster? Worst case scenario, if I'm
not able to get it to work, would probably be that the package gets
dropped during the freeze, and then having to use buster-backports
with a new upstream release. Is this worst-case scenario preferable
to keeping a package in experimental where users have to explicitly
opt-in? Of course, I'm going to do whatever I can to make it work,
despite my limited abilities...
> > 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?
Most packages have a fairly short "long description" so I've been
operating under the assumption that it is supposed to be less than 25
lines long, with 24 lines preferred. I've also assumed that if the
description grows longer than this then it needs to be more
aggressively ellipsed and summarised--possibly with references to
other documentation such as the README, man, and info pages.
> > 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.
Does this hide "Fill" from the modeline? Does a subsequent
(diminish 'flyspell-mode)
concatenate Fly|Flyspell to the list of minor modes that will be
hidden? I've sent a pull request to Artur (upstream contact) to add
examples to the documentation of rich-minority. eg:
;; Blacklist minor modes that match these regexp
(setq rm-blacklist
(format "^ \\(%s\\)$"
(mapconcat #'identity
'("Fly.*"
"Projectile.*"
"my-keys-mode"
"PgLn"
"company"
"Undo-Tree")
"\\|")))
;; Blacklist all minor modes (there's probably a better way to do this)
(setq rm-blacklist
(format "^ \\(%s\\)$"
(mapconcat #'identity
'(".*")
"\\|")))
For now, do you think I should create a README.Debian with these
examples or wait for upstream to merge them?
Cheers,
Nicholas
Attachment:
signature.asc
Description: Digital signature