unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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).