From: Matt Armstrong <matt@rfc20.org>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: 46364@debbugs.gnu.org, "Lars Ingebrigtsen" <larsi@gnus.org>,
"Bruno Félix Rezende Ribeiro" <oitofelix@gnu.org>
Subject: bug#46364: regression in lm-commentary
Date: Mon, 08 Feb 2021 16:11:47 -0800 [thread overview]
Message-ID: <m2zh0eje0s.fsf@matts-mbp-2016.lan> (raw)
In-Reply-To: <87wnviqo5b.fsf@tcd.ie> (Basil L. Contovounesios's message of "Mon, 08 Feb 2021 20:51:12 +0000")
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Matt Armstrong <matt@rfc20.org> writes:
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>> Matt Armstrong <matt@rfc20.org> writes:
>>
>> [...]
>>
>>>> It seems `lm-commentary' now strips all leading whitespace from every
>>>> line, as a "sanitization" step, and this has the unsatisfying side
>>>> effect of ruining any indentation formatting in the original commentary.
>>>
>>> Is the removal of the leading white-space the only problem with the
>>> sanitization? Then perhaps that bit could be tweaked?
>>
>> I noticed that Basil's commit 963a9ffd66cb29f0370e9a4b854dddda242c54a6
> ^^^^^^^
> Bruno's ;)
Yes, thank you. :-)
>> consolidated normalization logic but also changed the regex slightly
>> such that all leading whitespace was erased. I've attached a patch to go
>> back to the old ways. It seems to work.
>
> Given that lm-commentary is used outside of Emacs, I suggest its
> behaviour be reverted to that in Emacs 27, and any sanitisation provided
> as a separate function instead.
I leave the decision to Lars and other Emacs maintainers.
My opinion: while introducing a new function is surely safer, we should
submit the patch I proposed. Why?
I did a web search looking for callers of lm-commentary outside of Emacs
proper. In every case I found code that called lm-commentary and then
tried to do sanitization of the result (by removing the comment leaders
from each line, etc.).
For example, this is what MELPA does. See also :
https://www.emacswiki.org/emacs/finder+.el
It seems like the "sanitize" behavior is what callers want.
next prev parent reply other threads:[~2021-02-09 0:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-07 14:01 bug#46364: regression in lm-commentary Boruch Baum
2021-02-07 18:38 ` Lars Ingebrigtsen
2021-02-07 18:55 ` Boruch Baum
2021-02-07 20:35 ` Basil L. Contovounesios
2021-02-08 0:19 ` Matt Armstrong
2021-02-08 6:39 ` Lars Ingebrigtsen
2021-02-08 18:59 ` Matt Armstrong
2021-02-08 20:51 ` Basil L. Contovounesios
2021-02-09 0:11 ` Matt Armstrong [this message]
2021-02-09 8:11 ` Lars Ingebrigtsen
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=m2zh0eje0s.fsf@matts-mbp-2016.lan \
--to=matt@rfc20.org \
--cc=46364@debbugs.gnu.org \
--cc=contovob@tcd.ie \
--cc=larsi@gnus.org \
--cc=oitofelix@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 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).