GNU bug report logs - #72561
31.0.50; Scan error in ert--pp-with-indentation-and-newline

Previous Next

Full log

Message #14 received at 72561 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 72561 <at> debbugs.gnu.org
Subject: Re: bug#72561: 31.0.50; Scan error in
 ert--pp-with-indentation-and-newline
Date: Wed, 21 Aug 2024 17:28:45 -0700

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Your patch makes sense: indeed, looking at the code of `indent-sexp`,
> I see that it uses `lisp-indent*` functions in a way which presumes that
> we're looking at Lisp code and would require a list-mode syntax-table.
> I wonder why this has not bitten us earlier in other circumstances.
>
> But I also wonder why `ert--pp-with-indentation-and-newline` calls
> `indent-sexp`, since `pp` should have done that for us already, so I'd
> be tempted to just remove that call.  Or maybe the purpose is to "shift"
> the text when `begin` is not in column 0?
> If so, maybe `indent-rigidly` is a better way to get the same result?

Right, I don't think `begin' is ever in column 0 (as currently used). So
I guess the intention is indeed to shift all but the first line of the
`pp' result by `current-column', meaning it's probably cleaner (as you
say) to do a dumb, uniform shift.

[0001-Indent-ERT-failure-explanations-rigidly.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.