[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46364: regression in lm-commentary
From: |
Lars Ingebrigtsen |
Subject: |
bug#46364: regression in lm-commentary |
Date: |
Mon, 08 Feb 2021 07:39:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Matt Armstrong <matt@rfc20.org> writes:
> The issue is a behavior change in `lm-commentary' that probably deserves
> some consideration, because it seems suboptimal in this example. The
> behavior change is most likely caused by commit
> 963a9ffd66cb29f0370e9a4b854dddda242c54a6.
Right. The rationale was:
> I decided to tackle the problem’s root. After figuring out that every
> function depending on ‘lm-commentary’ implemented their own ad-hoc
> sanitation for the same effect, I changed ‘lm-commentary’ to return a
> sanitized string and removed the code/functionality duplication from all
> callers.
(I've added Bruno to the CCs.)
> Prior to that commit, and in Emacs 27.1, the function returns the file's
> commentary as an verbatim substring of the elisp source, including the
> elisp comment characters, commentary headline, etc. E.g. a string like
> this (I'll quote the string for email sanity):
[...]
> 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?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no