bug#46364: regression in lm-commentary

[Lars Ingebrigtsen <larsi@gnus.org>]

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