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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 33301 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33301: 27.0.50; broken elisp indentation for non-definition
 symbols starting with "def.."
Date: Sun, 23 Aug 2020 14:39:50 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> João Távora <joaotavora <at> 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.

Previous Next

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