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

["João Távora" <joaotavora@gmail.com>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> This may explain the string-match hack in the first place. I don't know
>> the exact motivation of the hack, but it's been there since the initial
>> 2001 revision of the file.  Possibly before declare/indent existed?
>
> But wait, this is in lisp-mode.el which I remember is used not only for
> Elisp but also for other Lisps, right?

Well it's lisp/emacs-lisp/... ;-)

> So your patch could make things worse for editing Common Lisp, for
> example.

OK, just add (derived-mode-p 'emacs-lisp-mode), as is done elsewhere in
that file.

Or I would suggest (setq-local lisp-indent-function
'common-lisp-indent-function) in you hypothetical fancy-lisp-mode hook
and has much better heuristics that don't cause the bug I've described.

(But, as someone who writes CL for a living, if you're indenting CL with
these heuristics, you've already lost.  You should use SLY/SLIME which
looks at the macroexpansion to understand what you're trying to indent.)

> For Elisp the heuristic doesn't make much sense, though, if the edited
> file is not loaded, it also prevents false negatives for macro uses of
> macros defined in that file.

I don't fully understand the "it also" part, but here's my take on this:
If you're not loading the code, all things being equal, it's better to
incorrectly re-indent existing "def"-macros (not defmacro) than to
incorrectly indent new arbitrary "def"-forms anywhere in the AST.
That's because it's a bad idea to re-indent code anyway, but indent new
code happens all the time.

Also, it's not a very good idea to indent without some form of
evaluation anyway.  Because of the indentation declaration, that ship
has sailed long ago (and bon voyage).

João