bug#33301: 27.0.50; broken elisp indentation for non-definition symbols starting with "def.."

[João Távora]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> I wouldn't count 34 as "oodles" and don't think a new line for each
>> occurrence of what is essentially a breach of convention is a high
>> price to pay. Even converting some of those to macros or "make-foo"
>> could be worth it if it would enable non-surprising indentation.
>
> Changing functions to macros, or renaming functions from def* to make*,
> just because we have a slightly odd heuristic in Emacs Lisp mode doesn't
> sound quite right to me.

This wouldn't be the only reason to do that.  As I explained
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33301#51 this convention
is good in itself.

>> As for the problem of needing to load macros before indenting forms
>> where they appears, that's already very much a thing. We wouldn't be
>> creating new problems there, it's just the way it is.
>
> That's true, but it would exacerbate the problem.

Really doubt that. I think regular use of macros (like, say with-foo) is
prevalent enough that people already know not to mass-reindent existing
code anyway.

> But the main problem is that it would indent the code differently than
> it does now, and that leads to whitespace churn in the vc, which we
> should avoid unless we have a very, very good reason not to.

What exactly do you mean "whitespace churn"?  Can you illustrate this
hypothetical scenario?  I don't expect whitespace/indentation beyond
fixing the akward cases, at least that's the entire point of this
report.

> good enough reason...

It is a somewhat infrequent but annoying bug when one decides to use a
variable name that happens to start with "def".  I use "default" and
"deferred" a lot, for instance.  In Common Lisp mode, I don't have this
problem.

>> As for out-of-tree definitions, we could be lenient and have this
>> saner indentation be controlled by a variable which we would default
>> to 'insane, but to 'sane inside Emacs's source, via directory local
>> variables.
>
> I'd be against that -- again, because it leads to whitespace VC churn.

Again, I'm missing something: this option wouldn't lead to that, I think

João

PS: another entirely different approach would just limit the current
hacky heuristic to calls/expansions that happen at top-level, i.e. at
"column 0".  I believe this to be the vast majority (though not the
entirety) of cases.