bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#46364: regression in lm-commentary


From: Matt Armstrong
Subject: bug#46364: regression in lm-commentary
Date: Mon, 08 Feb 2021 16:11:47 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)

"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 via email to

[Prev in Thread] Current Thread [Next in Thread]