Emacs Lisp code formatting

Emacs Lisp code formatting

[Lars Ingebrigtsen]

I've always assumed that Emacs has a function for pretty-printing Emacs
Lisp -- and it's just that I haven't found it.

`pp' indents sexps nicely, but it doesn't format code in any way a human
would.

Doesn't Emacs have a pretty-printer for code?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Campbell Barton]

On 11/3/21 02:27, Lars Ingebrigtsen wrote:
> I've always assumed that Emacs has a function for pretty-printing Emacs
> Lisp -- and it's just that I haven't found it.
> 
> `pp' indents sexps nicely, but it doesn't format code in any way a human
> would.
> 
> Doesn't Emacs have a pretty-printer for code?

As far as I know, Emacs doesn't include this built-in.

There are a handful of 3rd party lisp formatting tools [0], though, YMMV.

[0]: https://emacs.stackexchange.com/a/55759/2418

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Campbell Barton <ideasman42@gmail.com> writes:

> There are a handful of 3rd party lisp formatting tools [0], though, YMMV.
>
> [0]: https://emacs.stackexchange.com/a/55759/2418

Thanks.  I had a look at them, but they seem to have the problem of
being 1) too dependent on the rest of a larger package or 2) having
special code for known constructs (meaning that there'd be a maintenance
burden over the years).

I wonder how far one can get by using the symbol properties (i.e.,
edebug-form-spec/lisp-indent-function/doc-string-elt).  Has anybody
looked into that?  If not, I think I'll take a whack at implementing
something simple based on that -- it seems like it should be possible to
make something general based on that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Campbell Barton]

On 11/4/21 10:59, Lars Ingebrigtsen wrote:
> Campbell Barton <ideasman42@gmail.com> writes:
> 
>> There are a handful of 3rd party lisp formatting tools [0], though, YMMV.
>>
>> [0]: https://emacs.stackexchange.com/a/55759/2418
> 
> Thanks.  I had a look at them, but they seem to have the problem of
> being 1) too dependent on the rest of a larger package or 2) having
> special code for known constructs (meaning that there'd be a maintenance
> burden over the years).
> 
> I wonder how far one can get by using the symbol properties (i.e.,
> edebug-form-spec/lisp-indent-function/doc-string-elt).  Has anybody
> looked into that?  If not, I think I'll take a whack at implementing
> something simple based on that -- it seems like it should be possible to
> make something general based on that.

You could get quite far, an issue I ran into is function introspection 
such as `func-arity' depend on the code being loaded into emacs.

You could scan external `require' calls, but this means parsing many 
files to extract the information you need.
If you're OK with loading the code for the purpose of introspection - 
you could spawn an emacs instance for that purpose.
If speed is important (such as running this whenever saving a file) the 
information could be cached (with a file list to detect when the cache 
needs to be regenerated).

This is the main sticking point for me, something that would need to be 
resolved before auto-formatting could be recommended for general use.

Note that I use auto-format on save for all my packages (full 
auto-formatting, not just auto-indent), and personally find it great, 
but as far as I know I'm the only person doing this.

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Campbell Barton <ideasman42@gmail.com> writes:

> You could scan external `require' calls, but this means parsing many
> files to extract the information you need.

Like with indentation, I think we can assume that the source has been
loaded.

> Note that I use auto-format on save for all my packages (full
> auto-formatting, not just auto-indent), and personally find it great,
> but as far as I know I'm the only person doing this.

I think auto-formatting would be a more complicated thing than a pp for
code -- it would need to preserve comments, for instance.  A pp for code
doesn't have to worry about things like that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Campbell Barton]

On 11/4/21 16:47, Lars Ingebrigtsen wrote:
> Campbell Barton <ideasman42@gmail.com> writes:
> 
>> You could scan external `require' calls, but this means parsing many
>> files to extract the information you need.
> 
> Like with indentation, I think we can assume that the source has been
> loaded.

Not sure what you mean exactly, while developing packages 
functions/macros may change, so I don't think it's reasonable to assume 
the evaluated state in emacs has loaded into memory is up to date.
In general it may be useful to auto-format code that hasn't been 
evaluated too.

>> Note that I use auto-format on save for all my packages (full
>> auto-formatting, not just auto-indent), and personally find it great,
>> but as far as I know I'm the only person doing this.
> 
> I think auto-formatting would be a more complicated thing than a pp for
> code -- it would need to preserve comments, for instance.  A pp for code
> doesn't have to worry about things like that.

For sure, even so, I think getting an initial auto-formatter working is 
a weekend project, getting all the details figured out is a bigger task 
though.

I get the impression most elisp developers prefer to manually format 
their code and use auto-indentation.

Auto formatters are becoming more popular in other languages though, 
clang-format (C/C++), black (for Python)... once you're used to running 
them automatically on save, it feels like a step backwards not to have 
this feature available.

Re: Emacs Lisp code formatting

[Helmut Eller]

On Thu, Nov 04 2021, Campbell Barton wrote:

> I get the impression most elisp developers prefer to manually format
> their code and use auto-indentation.

If there isn't a decent tool to do it automatically, that would be no
surprise.

Maybe C-M-q (indent-pp-sexp) should do bit more than just indent every
line.  I certainly would like it to break long lines automatically.

Or maybe code formatting could be integrated in elint.

The other obvious candidate is the byte-compiler.  But the compiler seems
to be so complicated already, that nobody wants to touch it.

> Auto formatters are becoming more popular in other languages though,
> clang-format (C/C++), black (for Python)... once you're used to
> running them automatically on save, it feels like a step backwards not
> to have this feature available.

On that topic: I find it rather unsatisfactory that GNU indent doesn't
seem to be used much.  Not even by the Emacs developers.

Helmut

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Campbell Barton <ideasman42@gmail.com> writes:

> Not sure what you mean exactly, while developing packages
> functions/macros may change, so I don't think it's reasonable to
> assume the evaluated state in emacs has loaded into memory is up to
> date.

That is the assumption.  If you're writing code that uses (say)
`thread-first', it will be indented wrong until you load its definition.

> Auto formatters are becoming more popular in other languages though,
> clang-format (C/C++), black (for Python)... once you're used to
> running them automatically on save, it feels like a step backwards not
> to have this feature available.

Yes, auto-formatting is cool, but outside the scope of a "better pp".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Doesn't Emacs have a pretty-printer for code?

Emacs does now.  So instead of the `pp' output of

(lambda nil
  (interactive)
  (let
      ((beg nil))
    (setq beg
	  (point))
    (while
	(and
	 (looking-at "[	\n ]")
	 (not
	  (eobp)))
      (forward-char))
    (delete-region beg
		   (point))))

you can have

(lambda ()
  (interactive)
  (let ((beg nil))
    (setq beg (point))
    (while (and (looking-at "[	\n ]") (not (eobp)))
      (forward-char))
    (delete-region beg (point))))

with `pp-emacs-lisp-code'.  And I'm sure there's a ton of stuff that can
be tweaked -- this is the sort of stuff that'd open ended, because
there's always something that can look just a bit prettier.

Have at it if you want to, but remember to add test cases.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Juri Linkov]

>> Doesn't Emacs have a pretty-printer for code?
>
> Emacs does now.  So instead of the `pp' output of
> ...
> you can have
>
> (lambda ()
>   (interactive)
>   (let ((beg nil))
>     (setq beg (point))
>     (while (and (looking-at "[	\n ]") (not (eobp)))
>       (forward-char))
>     (delete-region beg (point))))
>
> with `pp-emacs-lisp-code'.  And I'm sure there's a ton of stuff that can
> be tweaked -- this is the sort of stuff that'd open ended, because
> there's always something that can look just a bit prettier.

This is a nice feature, but I wonder why it's not used
by ‘C-u C-M-q’ (‘indent-pp-sexp’ with a prefix arg) in Lisp mode?

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This is a nice feature, but I wonder why it's not used
> by ‘C-u C-M-q’ (‘indent-pp-sexp’ with a prefix arg) in Lisp mode?

It takes a sexp and formats it -- it doesn't support interactive code
formatting, so no comments, and it'll turn ?\s into 32, etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> with `pp-emacs-lisp-code'.

Cool - thanks for that.

May I ask why something like (pp-emacs-lisp-code '(when t 1)) fails -
can you have a look please?  Seems there is a minor problem with edebug
spec inspection.

  (wrong-type-argument listp t)
  car(t)
  (consp (car edebug))
  (and (consp (car edebug)) (eq (car (car edebug)) '&rest))
  (if (and (consp (car edebug)) (eq (car (car edebug)) '&rest)) (pp--insert-binding (car-safe (prog1 sexp (setq sexp (cdr sexp))))) (if (null (car sexp)) (insert "()") (pp--insert-lisp (car sexp))) (car-safe (prog1 sexp (setq sexp (cdr sexp)))))
  (while (and (cl-plusp indent) sexp) (insert " ") (if (and (consp (car edebug)) (eq (car (car edebug)) '&rest)) (pp--insert-binding (car-safe (prog1 sexp (setq sexp (cdr sexp))))) (if (null (car sexp)) (insert "()") (pp--insert-lisp (car sexp))) (car-safe (prog1 sexp (setq sexp (cdr sexp))))) (car-safe (prog1 edebug (setq edebug (cdr edebug)))) (setq indent (1- indent)))
  pp--format-definition((t 1) 1 t)
  (if indent (pp--format-definition sexp indent edebug) (let ((prev 0)) (while sexp (let ((start (point))) (pp--insert (if (> prev 1) "\n" " ") (car-safe (prog1 sexp (setq sexp ...)))) (setq prev (count-lines start (point)))))))
  (let* ((sym (car sexp)) (edebug (get sym 'edebug-form-spec)) (indent (get sym 'lisp-indent-function)) (doc (get sym 'doc-string-elt))) (if (eq indent 'defun) (progn (setq indent 2))) (if doc (progn (setq indent (1- doc)))) (if (and (not indent) (eq sym 'closure)) (progn (setq indent 0))) (pp--insert "(" sym) (car-safe (prog1 sexp (setq sexp (cdr sexp)))) (if indent (pp--format-definition sexp indent edebug) (let ((prev 0)) (while sexp (let ((start (point))) (pp--insert (if (> prev 1) "\n" " ") (car-safe (prog1 sexp ...))) (setq prev (count-lines start (point))))))) (insert ")"))
  pp--format-function((when t 1))
  [...]

Thanks,

Michael.

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> May I ask why something like (pp-emacs-lisp-code '(when t 1)) fails -
> can you have a look please?  Seems there is a minor problem with edebug
> spec inspection.

Yup.  Should now work less bad.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yup.  Should now work less bad.

Thanks.

In some situations I see some other quirks like multiple consecutive
newlines added, but we do not need to discuss this here, and there is no
hurry.

Regards,

Michael.

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> In some situations I see some other quirks like multiple consecutive
> newlines added, but we do not need to discuss this here, and there is no
> hurry.

I'm not surprised.  😇  Feel free to rewrite and tweak as you wish.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Juri Linkov]

>> This is a nice feature, but I wonder why it's not used
>> by ‘C-u C-M-q’ (‘indent-pp-sexp’ with a prefix arg) in Lisp mode?
>
> It takes a sexp and formats it -- it doesn't support interactive code
> formatting, so no comments, and it'll turn ?\s into 32, etc.

Oh, I thought it works like 'pp-buffer' - just by adding/removing newlines
(because everything else is handled by 'indent-sexp').

Would it be possible to do such a thing and keep it uncomplicated?
For example, to ensure there is no newline after if/when/unless, but insert
a newline after its condition, unless it's short enough to fit on one line,
etc.

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Oh, I thought it works like 'pp-buffer' - just by adding/removing newlines
> (because everything else is handled by 'indent-sexp').

Since we're being passed a sexp, I thought it would be easier to just
work on the sexp instead of inserting it into the buffer and then
partially re-parse it to get at the symbol properties.  pp-buffer
doesn't have that problem, since it basically doesn't care about any of
that.

> Would it be possible to do such a thing and keep it uncomplicated?
> For example, to ensure there is no newline after if/when/unless, but insert
> a newline after its condition, unless it's short enough to fit on one line,
> etc.

Sure, doing it that way around would produce results that could be used
when editing code, too (which was not part of what I was trying to do
here), but my guess is that it'd be more complicated.  But I haven't
tried -- if you want to rewrite the code to do it that way around,
please do so.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Lisp code formatting

[Juri Linkov]

>> Oh, I thought it works like 'pp-buffer' - just by adding/removing newlines
>> (because everything else is handled by 'indent-sexp').
>
> Since we're being passed a sexp, I thought it would be easier to just
> work on the sexp instead of inserting it into the buffer and then
> partially re-parse it to get at the symbol properties.  pp-buffer
> doesn't have that problem, since it basically doesn't care about any of
> that.

BTW, it seems the new pp-emacs-lisp-code is not yet used to pp
the variable values by 'C-h v'?  Especially, hook's lambdas/closures
could benefit from prettier printing.

Re: Emacs Lisp code formatting

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> BTW, it seems the new pp-emacs-lisp-code is not yet used to pp
> the variable values by 'C-h v'?  Especially, hook's lambdas/closures
> could benefit from prettier printing.

Yup.  It would have to determine first whether the value is a Lisp data
structure or ... a list of functions etc, but I guess the defcustom type
could be used for that?  Or just inspect the data and see what it looks
like.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no