mirror of https://github.com/djcb/mu.git
173deff6a0
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. |
||
|---|---|---|
| .github | ||
| build-aux | ||
| contrib | ||
| guile | ||
| lib | ||
| m4 | ||
| man | ||
| mu | ||
| mu4e | ||
| toys | ||
| www | ||
| .editorconfig | ||
| .gitignore | ||
| .travis.yml | ||
| AUTHORS | ||
| COPYING | ||
| ChangeLog | ||
| HACKING | ||
| Makefile.am | ||
| NEWS | ||
| NEWS.org | ||
| README | ||
| TODO | ||
| autogen.sh | ||
| c.cfg | ||
| configure.ac | ||
| gtest.mk | ||
README
Welcome to mu & mu4e! Given the enormous amounts of e-mail many people gather and the importance of e-mail message in our work-flows, it's essential to quickly deal with all that mail - in particular, to instantly find that one important e-mail you need right now, and quickly file away message for later use. `mu` is a tool for dealing with e-mail messages stored in the Maildir-format. `mu`'s purpose in life is to help you to quickly find the messages you need; in addition, it allows you to view messages, extract attachments, create new maildirs, and so on. See the [mu cheatsheet] for some examples. =mu= is fully documented. After indexing your messages into a [Xapian](http://www.xapian.org)-database, you can search them using a custom query language. You can use various message fields or words in the body text to find the right messages. Built on top of `mu` are some extensions (included in this package): * mu4e: a full-featured e-mail client that runs inside emacs * mu-guile: bindings for the Guile/Scheme programming language (version 2.2 and later) `mu` is written in C and C++; `mu4e` is written in elisp, and `mu-guile` in a mix of C and Scheme. Note, `mu` is available in Linux distributions (e.g. Debian/Ubuntu and Fedora) under the name `maildir-utils`; apparently because they don't like short names.