From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#46364: regression in lm-commentary Date: Sun, 07 Feb 2021 16:19:14 -0800 Message-ID: References: <20210207140125.6rn7lfg33qnkb222@E15-2016.optimum.net> <87lfbzzpsm.fsf@gnus.org> <878s7z1urq.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25396"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) Cc: 46364@debbugs.gnu.org, Lars Ingebrigtsen To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 08 16:58:57 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l98wD-0006Tw-6f for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Feb 2021 16:58:57 +0100 Original-Received: from localhost ([::1]:58110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l98wC-0004bf-5h for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Feb 2021 10:58:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l92nB-0007nA-4y for bug-gnu-emacs@gnu.org; Mon, 08 Feb 2021 04:25:14 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l92n2-00065t-Bo for bug-gnu-emacs@gnu.org; Mon, 08 Feb 2021 04:25:12 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l92n2-00036b-8n for bug-gnu-emacs@gnu.org; Mon, 08 Feb 2021 04:25:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Feb 2021 09:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46364 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 46364-submit@debbugs.gnu.org id=B46364.161277627511856 (code B ref 46364); Mon, 08 Feb 2021 09:25:04 +0000 Original-Received: (at 46364) by debbugs.gnu.org; 8 Feb 2021 09:24:35 +0000 Original-Received: from localhost ([127.0.0.1]:49807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l92mX-000353-FZ for submit@debbugs.gnu.org; Mon, 08 Feb 2021 04:24:35 -0500 Original-Received: from mail-pf1-f174.google.com ([209.85.210.174]:38410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l8uGv-00042p-Uo for 46364@debbugs.gnu.org; Sun, 07 Feb 2021 19:19:24 -0500 Original-Received: by mail-pf1-f174.google.com with SMTP id d26so7371956pfn.5 for <46364@debbugs.gnu.org>; Sun, 07 Feb 2021 16:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=wjND1+//PlnGGBGhNXo1C0G0asX7goguCR/YmF6khs8=; b=nBQo5TCTFtJUYMXzZK5hrW9TKcogfmA5p0fF+sl5FT5EVZiPu3JsUJDO1AUCocSTY+ QJaqp7VEqr4WDyg8jGtHNrZOUyryuFH3cQvzl62G3JeIrpV0ULUYLoK/CRxAcOYg/HRy VTRA5q3dVaxIqffVg1ET5FN8qO4WsovsYMk5AFM4kGqwIJ0MrhWltD6TykK+gLxgL+IH CxBel5tR9y4rkRGEhDLmpX0PhaCF/qBnfwh9eMAJwB60Bt29rfhw7A3cj5h2W6whmIZ9 eiuM3QZJNeTBswuaV4qjZeuObkmOJdTkHmyKH0W4zEMzodQ+aXywX1wFWpOthbJkOCCA YD8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=wjND1+//PlnGGBGhNXo1C0G0asX7goguCR/YmF6khs8=; b=MgiEXhP5uyFmXcacZ1yh1RYUUz+OCk7XWDOldprBXzrBrTJw3W/gy770eqFqVpCWUA lpUIuYSt4gQhIJo9Jh6QhipGQ91zQCe0Tkursyv4TDiqWt0vtNilTe6ne5XLCLw8wgqe lsf50oByvYLyfXqN1qsX/i76J2/W3+9Prb4oAp9JDYTEOfUtn0C4GtKXKVzzNh4VtkV1 sLs9D8uqkToW1S/2NtYn4uAPoxezM/2ZJ0G5NrRBm0Puu7AJxtzvp6CvvayzG+WVO1AB k6ev0uDVNbhraOUfPiol+7XKzic0E9toJxlNgs/H2NnphjRLzzjqlZ8n96mJZOd9OrYF cjvQ== X-Gm-Message-State: AOAM532RnTVlL03GkVn3hQ5/FD3FU3mBzD3XJiO31BYpD2cy8nRoMOhX HNzTVhkzvfW/4vsb1dzO6AlSm45q/JoH0Q== X-Google-Smtp-Source: ABdhPJzzbi5LTSV1ahA1V/3Ho57nyPN33OrqFEsobANeayEyBFWJ1m2o9yqYnfw4+x7/k6Y82S97mA== X-Received: by 2002:a62:ed01:0:b029:1c8:c6c:16f0 with SMTP id u1-20020a62ed010000b02901c80c6c16f0mr15494958pfh.80.1612743555702; Sun, 07 Feb 2021 16:19:15 -0800 (PST) Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com. [24.113.169.116]) by smtp.gmail.com with ESMTPSA id j65sm16285132pfb.23.2021.02.07.16.19.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Feb 2021 16:19:15 -0800 (PST) In-Reply-To: <878s7z1urq.fsf@tcd.ie> (Basil L. Contovounesios's message of "Sun, 07 Feb 2021 20:35:05 +0000") X-Mailman-Approved-At: Mon, 08 Feb 2021 04:24:31 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:199600 Archived-At: "Basil L. Contovounesios" writes: > I attach the file in question, diredc.el. Here's the recipe: > > 0. emacs -Q > 1. (require 'lisp-mnt) C-j > 2. (lm-commentary "/path/to/diredc.el") C-j > > In Emacs 27, the resulting string includes leading semicolons and > indentation. In Emacs 28, it doesn't. Version info follows my > signature. Thanks Basil. I investigated this too and filed a new bug with the information below (because I don't know debbugs well). My investigation belongs here instead. Lars asked about MELPA. Answer: MELPA is relevant only because in some cases MELPA code calls `lm-commentary' to form user-facing description of a package. 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. 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): > ";;; Commentary: > ;; > ;; This package extends and configures `dired' with features found in > ;; almost all 'file managers', and also some unique features: > ;; > ;; * Resilient dedicated dual-pane frame. > ;; * similar look to 'midnight commander'. > ;; * intelligent recovery of manually altered frame configuration > ;; * exit diredc/dired cleanly and totally [...] After that commit, the function returns a "sanitized" version of the same content, such as: > " > This package extends and configures `dired' with features found in > almost all 'file managers', and also some unique features: > > * Resilient dedicated dual-pane frame. > * similar look to 'midnight commander'. > * intelligent recovery of manually altered frame configuration > * exit diredc/dired cleanly and totally [...] 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. We need not go farther than Emacs' own lisp/align.el to see a similar problem. In Emacs 27, (lm-commentary "align.el") returns: > ";;; Commentary: > > ;; This mode allows you to align regions in a context-sensitive fashion. > ;; The classic use is to align assignments: > ;; > ;; int a = 1; > ;; short foo = 2; > ;; double blah = 4; > ;; > ;; becomes > ;; > ;; int a = 1; > ;; short foo = 2; > ;; double blah = 4; > > " And in Emacs 28 (mainline): > "This mode allows you to align regions in a context-sensitive fashion. > The classic use is to align assignments: > > int a = 1; > short foo = 2; > double blah = 4; > > becomes > > int a = 1; > short foo = 2; > double blah = 4;" Perhaps this should be re-thought?