Re: Indent lisp files on save -- How?

[Matt Armstrong]

"T.V Raman" <raman@google.com> writes:

> I'm somewhat surprized I've never setup the above for emacs-lisp or
> Common-Lisp in all these years.

For Emacs Lisp, I don't think there is a good "format on save"
implementation.


> But having gotten used to having format on save for Go, Rust and
> Python among others I want the same for all lisp dialects -- how do I
> achieve this? It's unclear which of the options available is designed
> for placing on before-save-hook.

I like this kind of thing too, but in the cases of Go, Rust, Python,
Ruby, Javascript, etc. there are existing external tools, and projects
often enforce strict formatting rules.  For these languages Emacs is
just one more editor running the tool.

Emacs has something subtly different for Emacs Lisp.

One issue for an "auto-indenter" for Emacs Lisp is that indentation
behavior is dependent on what is currently loaded.  In particular,
indentation of macros is often wrong until the macro is loaded, since
the indenter doesn't know it is a macro with a custom indentation
declaration.  This is an issue because one can't simply load an .el
file, make an edit, and expect the indenter to do the right thing.  One
must at least make sure to eval whatever that file requires.  I don't
know how to solve this problem in the general case.  Perhaps an Emacs
Lisp auto-indenter should run as a subprocess, much like emacs-lisp.el
tells flymake to use an emacs subprocess to byte compile the current .el
file to surface bytecomp errors.

Another problem is that the programming culture for Emacs Lisp doesn't
seem to be about a strict adherence to any one indentation tool or
algorithm, and the Emacs indenter isn't always perfect.  Load up any
random .el file shipped with Emacs, then M-x mark-whole-buffer, then M-x
indent-region, and you will usually get diffs.  Sometimes the diffs
should be applied (when the code has misleading or obviously wrong
indentation).  Sometimes the diffs are the programmer's choice and
should not (necessarily) be undone.

Then there is the question: does the whole file get indented, or is the
indentation limited to just the portions of the buffer that have been
edited?  In the latter case, what decides when enough of the surrounding
sexp has been reindented?  These are surprisingly subtle questions,
often requiring non-trivial heuristics.

I use the clang-format+ package to format C and C++ code on save.  It
has logic to run the formatter only on portions of the buffer I have
edited (it uses lists of ranges and text properties to track the "dirty"
areas of the buffer).  It might be useful to extract this machinery out
into a package that provides a way to track this for formatting
purposes, and then experiment with using that in an
emacs-lisp-indent-on-save package.