Re: 2a73673 Change how thread-first/thread-last indent the first argument

[Adam Porter]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That's true of any indentation change, but we do make those, anyway.  In
> Emacs 28 we changed how
>
> '( foo
>    bar)
>
> is indented

I would argue that that's introducing a new feature rather than changing
how an existing form is indented, because such a form with a space
before the first element didn't indent differently than one without a
space, so there was no reason to write a form that way before this
change.

> and in Emacs 29 we've changed how cl-flet is indented.

> (The first change probably didn't entail any churn because nobody wrote
> something like that before, but the cl-flet one does introduce churn.)

Yes, but that's fixing a longstanding bug, a clear incompatibility with
CL, and the unfixed cl-flet indentation is purely a drawback (causing
too-long lines where they'd otherwise be within fill-column).

> So the question is whether the old indentation was a bug or not, and it
> looks like a bug to me.  That is, the only documentation of the form we
> have indents the way it does now (after the change).  On the other hand,
> the documentation could be incorrect.

Looking at vc-region-history for thread-last, it's only been touched 3
times: most recently in this indentation change, then in 2014 when Paul
Eggert fixed a typo in the docstring, and firstly in the same year when
Fabián Ezequiel Gallina introduced the macro.  I would argue that Fabián
wrote "(declare (indent 1))" intentionally, and the fact that the "5" in
the docstring example was not indented by two more spaces was an
oversight, probably explained by having manually indented the code in
the docstring.

So I would argue that the bug was in the example in the docstring, not
in the code.  And given that offsetting the first form is more useful,
and that it's in line with other macros whose first form is special
(e.g. `prog1'), the indentation for `thread-first' and `thread-last'
should not be changed to match the erroneous docstring.  It would be
preferable to just fix the docstring.