1) It is fairly safe to assume that almost all edits to Emacs lisp
files will be done using the Emacs editor, so there is no need
to configure this in a way understood by other editors.
2) Trying to configure the intention of lisp code using editorconfig
causes the indention to be wrong. Here "wrong" does not mean, "it
uses tabs when everyone knows that spaces is the true path" (or
vice-versa), but in the sense of "in lisp indentation is subject to
the outer expression, and it has been like that for decades, but we
are just going to ignore that completely and pretend this is
actually python code".
For example, if we insert a new line character between the 1 and 2
in (progn (progn 1 2) then there are only two ways to intend that
correctly.
(We use "." to represent a leading space and "<-->" to represent
leading tabs. "<------>" for a tab when it is shown eight characters
wide or "<>" if only two.)
First correct way:
(setq-local indent-tabs-mode t)
(progn (progn 1
<------>......2))
Second correct way:
(setq-local indent-tabs-mode nil)
(progn (progn 1
..............2))
With the old editorconfig configuration,
[*.el]
indent_style = tab
indent_size = 2
max_line_length = 100
we get:
(progn (progn 1
<><><><>.2))
This is not how `progn' is indented. No special indentation rules are
defined for it so all arguments are supposed to be aligned. For
`prog1' however special indentation are defined and if we replaced the
second `progn' in this example with a `prog1', then this would
actually be correct. This just demonstrate that it is wrong to indent
everything the same for lisp; the reason that `progn' and `prog1' are
indented differently communicates different meanings to the reader.
I had faint hope that without setting `indent_size' things would work
correctly, but no,
[*.el]
indent_style = tab
max_line_length = 100
gives us:
(progn (progn 1
<------>.......2))
That doesn't even make sense if we pretend to be looking at python
code. Turns out that `indent_size' defaults to 2 even for lisp code
as can be demonstrated by additionally doing,
(setq-local tab-width 2)
which gives us:
(progn (progn 1
<>.......2))
which at least makes some sense.
Today when we query a find cmd with the `--threads` option, all the
childs of each thread are sorted according to their leader based on
the sortfield.
This patch change the way of how the childs of a thread are sorted.
The threads are still sorted according to their leader but all the
childs of each thread are now sorted based on the sortfield only.
Here is an example of what happened with the previous sorting:
Example with random kernel thread sorted by date:
[PATCH 0/4] drm/panel: jh057n0090: Add regulators and drop magic value in init
┣━▶[PATCH 1/4] MAINTAINERS: Add Purism mail alias as reviewer for their devkit's panel
┣━▶[PATCH 2/4] drm/panel: jh057n0090: Don't use magic constant
┣━▶[PATCH 3/4] dt-bindings: display/panel: jh057n0090: Document power supply properties
┗━▶[PATCH 4/4] drm/panel: jh057n0090: Add regulator support
If someone reply to one of these emails in the middle, this email
become the leader and the thread is displayed like this:
[PATCH 0/4] drm/panel: jh057n0090: Add regulators and drop magic value in init
┣━▶[PATCH 2/4] drm/panel: jh057n0090: Don't use magic constant
┃ ┗━▶ Re: [PATCH 2/4] drm/panel: jh057n0090: Don't use magic constant
┣━▶[PATCH 1/4] MAINTAINERS: Add Purism mail alias as reviewer for their devkit's panel
┣━▶[PATCH 3/4] dt-bindings: display/panel: jh057n0090: Document power supply properties
┗━▶[PATCH 4/4] drm/panel: jh057n0090: Add regulator support
With this patch, we will have the following output:
[PATCH 0/4] drm/panel: jh057n0090: Add regulators and drop magic value in init
┣━▶[PATCH 1/4] MAINTAINERS: Add Purism mail alias as reviewer for their devkit's panel
┣━▶[PATCH 2/4] drm/panel: jh057n0090: Don't use magic constant
┃ ┗━▶ Re: [PATCH 2/4] drm/panel: jh057n0090: Don't use magic constant
┣━▶[PATCH 3/4] dt-bindings: display/panel: jh057n0090: Document power supply properties
┗━▶[PATCH 4/4] drm/panel: jh057n0090: Add regulator support
The tests cases concerning threads have also been updated.
Signed-off-by: Julien Masson <massonju.eseo@gmail.com>
Jonas Bernoulli
Dirk-Jan C. Binnema
Julien Masson
Christophe Troestler