Using mu4e-index-updated-hook in mu4e~start with a lambda is just like
adding the call to mu4e-info-handler so do it explicitely which is
much cleaner.
* mu4e/mu4e-utils.el (mu4e-info-handler): Always refresh main buffer.
(mu4e~start): Remove insertion of mu4e-index-updated-hook.
* mu4e/mu4e-headers.el (mu4e~headers-quit-buffer): Refresh main buffer
when done.
* mu4e/mu4e-main.el (mu4e-main-mode-map): Don't bind "g" to mu4e, "g"
should be bound to revert-buffer (special-mode).
(mu4e-main-mode): No need to specify map.
(mu4e~main-view-real-1): New.
(mu4e~main-redraw-buffer): New.
(mu4e~main-view-real): Use them.
(mu4e~main-view): Take one more arg REFRESH.
(mu4e~main-toggle-mail-sending-mode): revert-buffer when done.
Use "_" as the title of that section so that it is less distracting
when sections are collapsed to get an overview of the library.
Using a separate section is useful because it reduces the risk of
accidentally into the middle of a library.
Placing two semicolons on an otherwise empty line helps to logically
"connect" the surrounding "paragraphs", which in (only) some cases
makes sense.
Previously the three paragraphs of the permission statement were not
connected to each other like this, which is perfectly fine. However
the preceding "This file is not part of GNU Emacs." line was connected
to the first paragraph, which does not make sense considering that the
latter is not connected two the second paragraph, which it relates to
more.
Once those two semicolons are gone, it also makes sense to remove
those from the second line.
Texinfo is of the opinion that every hyperlink has to be prefixed
by either "see" or "in". If neither of these words appears there,
then it inserts "see" and it cannot be told not to do that.
This turns a correct sentence like:
> Mu4e lets you define custom actions for messages in the <Headers view>.
into:
> Mu4e lets you define custom actions for messages in the see <Headers view>.
The best compromise is
> Mu4e lets you define custom actions for messages in <Headers view>.
which isn't correct but at least less messed up.
Alternatively one could rephrase every sentence that contains a link
to circumvent Texinfo's speech impairment. Or one could replace each
link with a footnote and place the actual link in the footnote.
There already is a ".editorconfig" file for cross-editor
configuration, but most Emacs users don't use that, so this also has
to be configured the traditional Emacs way. (Also I have some doubts
that cross-editor configuration is relevant for Emacs Lisp files.)
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.