GNU bug report logs - #37548
Implement sanitation of single-file package long description

Previous Next

Full log

Message #8 received at 37548 <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: 37548 <at> debbugs.gnu.org
Subject: Re: bug#37548: Implement sanitation of single-file package long
 description
Date: Mon, 30 Sep 2019 19:27:14 +0200

Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org> writes:

> Hello Emacs developers,

Hi Bruno,

And thanks for your patch.

> The inlined patch implements sanitation of single-file package’s long
> description which is derived from the package’s commentary header
> section.  It removes the commentary header, the double semicolon prefix
> of each line, trailing new-lines and trailing white-space.  I think this
> is the usual practice for packages in GNU ELPA and MELPA repositories.
> Furthermore it’s aligned with the intended behavior for multi-file
> packages which is to read the long description from a README file[1] ---
> which presumably does not have commentary sections nor double semicolon
> prefixes.

I agree with the change.  However, there seems to be code duplication
here, since the same is done in package.el:

          ;; For built-in packages, get the description from the
          ;; Commentary header.
          (let ((fn (locate-file (format "%s.el" name) load-path
                                 load-file-rep-suffixes))
                (opoint (point)))
            (insert (or (lm-commentary fn) ""))
            (save-excursion
              (goto-char opoint)
              (when (re-search-forward "^;;; Commentary:\n" nil t)
                (replace-match ""))
              (while (re-search-forward "^\\(;+ ?\\)" nil t)
                (replace-match ""))))

Maybe it would make more sense to create a new function in package.el
that takes care of this?  That way we don't have the same
functionality in two places.

FWIW, I would probably prefer to base it on the code already in
package.el, since I find it a bit easier to read when the regular
expressions are split up.

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.