Re: [PATCH] diff: "lisp" userdiff_driver
- From
Scott L. Burson <scott@sympoiesis.com>
- Date
- Nov 15, 2025, 23:32 UTC
- Message-ID
- <CAF5LJ4D4q2S2VFhvEgVOe1Ar0e6cu=H3e_o_98VwHN7wYHh+DQ@mail.gmail.com>
- In-Reply-To
- <773d3233-c890-4df9-8f7e-32ff8a48651e@kdbg.org>
On Sat, Nov 15, 2025 at 9:06 AM Johannes Sixt <j6t@kdbg.org> wrote:
Show 9 quoted lines
> > [Cc the author of the Scheme driver] > > Am 15.11.25 um 11:17 schrieb Scott L. Burson via GitGitGadget: > > From: "Scott L. Burson" <Scott@sympoiesis.com> > > Please > add a lot more details why the Scheme driver is unsuitable for Lisp and > why a new driver is needed.
Here is text I propose for the commit message:
---- Common Lisp has top-level forms 'defun' and 'deftype' that are not matched by the current Scheme pattern. Also, it is more common when defining user macros intended as top-level forms to prefix their names with "def" instead of "define"; such forms are also not matched. And some such forms don't even begin with "def".
On the other hand, it is an established formatting convention in the Lisp community that only top-level forms start at the left margin. So matching any unindented line starting with an open parenthesis is an acceptable heuristic; false positives will be rare.
However, there are also cases where notionally top-level forms are grouped together within some containing form. At least in the Common Lisp community, it is conventional to indent these by two spaces, or sometimes one. But matching just an open parenthesis indented by two spaces would be too broad; so the pattern added by this commit requires an indented form to start with "(def". It is believed that this strikes a good balance between potential false positives and false negatives. ----
I discussed the pattern with some other experienced Common Lisp developers on a mailing list, and this is what I settled on after incorporating their feedback.
> It is customary to mark changes to the drivers in the subject line with > "userdiff:". Have a look at `git log userdiff.c`. It would be > appreciated to stay away from nerdy tokens like "userdiff_driver" when > the change can be summarized in plain English language.
Will do.
Show 34 quoted lines
> >
> > Signed-off-by: Scott L. Burson <Scott@sympoiesis.com>
> > ---
> > diff: "lisp" userdiff_driver
> >
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2000%2Fslburson%2Flisp-userdiff_driver-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2000/slburson/lisp-userdiff_driver-v1
> > Pull-Request: https://github.com/gitgitgadget/git/pull/2000
> >
> > userdiff.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/userdiff.c b/userdiff.c
> > index fe710a68bf..e127b4a1f1 100644
> > --- a/userdiff.c
> > +++ b/userdiff.c
> > @@ -249,6 +249,14 @@ PATTERNS("kotlin",
> > "|[.][0-9][0-9_]*([Ee][-+]?[0-9]+)?[fFlLuU]?"
> > /* unary and binary operators */
> > "|[-+*/<>%&^|=!]==?|--|\\+\\+|<<=|>>=|&&|\\|\\||->|\\.\\*|!!|[?:.][.:]"),
> > +PATTERNS("lisp",
> > + /* Either an unindented left paren, or a slightly indented line
> > + * starting with "(def" */
> > + "^((\\(|:space:{1,2}\\(def).*)$",
>
> Compared to the Scheme driver, this regular expression is
>
> - more restrictive because it does not permit arbitrary indentation;
>
> - less restrictive because it permits everything that begins with "(def".
>
> What would happen if this regular expression were added to the Scheme
> driver? Would it pick up additional and unwanted hunk headers is typical
> Scheme code?That is a good question. I don't think so, but I don't work in Scheme. I see that you have CC'ed Atharva Raykar; let's see whether he would have any objection.
I would point out that Scheme is a dialect of Lisp, not the other way around. (Lisp is unusual in being a family of languages, rather than a single language.) And having a separate "lisp" driver might aid discoverability.
But I understand: Scheme got their driver in first, and you have to fight against the tendency of the driver list to grow unboundedly.
Ooh, that reminds me: if we do decide to add a "lisp" driver, I'll also need to add it to 'Documentation/gitattributes.adoc'.
> The string literal for hunk headers can contain "\n"
Noted.
Show 7 quoted lines
> > + /* Common Lisp symbol syntax allows arbitrary strings between vertical bars */ > > + "\\|([^\\\\]|\\\\\\\\|\\\\\\|)*\\|" > > The Scheme driver has an similar description of this word token, but it > has only half as many backslashes. Is the difference necessary? Isn't > actually one or the other incorrect? (I did not try to understand what > this version here does.)
It's not important, but technically, Common Lisp allows an escaped backslash between vertical bars, but the R7RS formal grammar does not. However, I just tried Chicken Scheme, which claims to be at least partially R7RS compliant, and it does accept the escaped backslash. I am left to conclude that Scheme implementors think that the omission of the escaped backslash from the R7RS formal grammar is an oversight (I think so too).
Of course, no one would actually write a symbol name with an escaped backslash in it unless they were submitting to an obfuscated Lisp contest. So we are really being pedantic here. Still, may as well allow it.
Atharva, any comments?
-- Scott