From: Jonas Bernoulli <jonas@bernoul.li>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: 13207@debbugs.gnu.org
Subject: bug#13207: lisp-mnt.el improvements
Date: Mon, 17 Dec 2012 22:58:26 +0100 [thread overview]
Message-ID: <8738z42vel.fsf@bernoul.li> (raw)
In-Reply-To: <jwv62404lcl.fsf-monnier+emacs@gnu.org>
>> 3. lm-header, lm-header-multiline: wrap with save-match-data
>
> This one doesn't sound right. The callers should be fixed instead.
Okay. On second though: it wouldn't be very useful to use the match
data set by these functions. Why not save the match-data here once so
that no caller has to ever worry about it? Is there a general policy
that this kinda thing shouldn't be done?
>> 4. lm-header-multiline: continuation lines now need to be intended more
>> than the first line. E.g:
>> ;; Keyword: value
>> ;; more value
>> This is necessary because some built-in libraries contain things
>> like:
>> ;; Author: Kenichi HANDA <handa@etl.go.jp>
>> ;; (according to ack.texi)
>> And some third-party libraries contain things like:
>> ;; Keywords: key words
>> ;; This file is not part of Emacs
>> Among the 3500 packages mirrored on the Emacsmirror there are only
>> three where this change results in lines intended as continuation
>> lines not to be recognised anymore. At the same time this change
>> fixes ~50 errors.
>
> An important measure is how much breakage/improvement does it introduce
> when applied to files that are expected to do thing right (e.g. files in
> emacs/lisp and in elpa/packages). I'm OK with making lisp-mnt.el more
> forgiving, but it should not come at the cost of those packages that do
> things right.
The 3500 packages from which I extracted metadata include all built-in
and fsf-elpa packages (though I did not process every library, just the
"main library" of each package). The three packages affected in a
negative way didn't do things right, and they aren't fsf packages.
This should be possible
;; Author: Kenichi HANDA <handa@etl.go.jp>
;; (according to ack.texi)
and this can be sacrificed
;; Author: Kenichi HANDA <handa@etl.go.jp>
;; Jonas Bernoulli <jonas@bernoul.li>
-- Jonas
next prev parent reply other threads:[~2012-12-17 21:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-17 16:26 bug#13207: lisp-mnt.el improvements Jonas Bernoulli
2012-12-17 17:58 ` Stefan Monnier
2012-12-17 21:58 ` Jonas Bernoulli [this message]
2012-12-18 1:29 ` Stefan Monnier
2012-12-19 15:38 ` Jonas Bernoulli
2012-12-19 19:52 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738z42vel.fsf@bernoul.li \
--to=jonas@bernoul.li \
--cc=13207@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 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).