Arbitrary font faces can be specified for given thread tags. By
default, no coloring is applied. To specify coloring, place something
like this in your .emacs:
(setq notmuch-search-line-faces '(("delete" . '(:foreground "red"))
("unread" . '(:foreground "green"))))
Order matters: line faces listed first will take precedence (in the
example above, a thread tagged both "delete" and "unread" will be
colored red, since the "delete" face is listed before the "unread").
notmuch.el | 33 ++++++++++++++++++++++++++++++++-
1 files changed, 32 insertions(+), 1 deletions(-)
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll through
numerous open buffers.
Note that this patch adds an optional `buffer-name' argument to notmuch
show.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
The date was unfairly left out of getting pretty colors in the
notmuch-show header display. This fixes that grave injustice.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
And just make the Debian packaging request site-lisp/notmuch like it
wants. Otherwise, the installed files won't appear on the load-path
so won't be found by emacs.
When replying to a message notmuch tries to pick the correct From
address by looking which one of a user's configured email addresses
were included in To or Cc headers of the email that is being replied to.
If none of the users email addresses are in the To or Cc headers we now
try to guess from the first (chronologically, last) Received header
which domain this email was received in and therefore which of the
email addresses to use in a reply
If that fails we still use the primary email as From email
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
fix notmuch_message_file_get_header to always return the first instance
of the header you are looking for
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
These are the changes made between the notmuch 0.1 release and the
release of Debian version 0.1-1. It's mostly changes to the debian
directory, of course, but does also include some generally useful
Makefile improvements.
We currently don't distribute anything that's not already in git, so
there's no difference between these two targets, (but debhelper wants
to be able to call distclean).
Which means that the bash completion script will now install
to ${prefix}/etc by default (unless configured with --syconfdir=/etc)
which is probably the right thing to do.
I'm not sure that this option would actually be useful for anything,
but debhelper at least expects our configure script to support it. So
we'll accept it and ignore it.
Most anyone familiar with debian should know to look for the top-level
debian directory, but since we do have a "packaging" directory, I
thought it should at least mention the debian stuff rather than just
containing the fedora spec file.
Conflicts:
Makefile.local: The Makefiles were all recently re-written on
master, but I did ensure that the changes from the
debian branch were all implemented here, (in
particular, installing the emacs files from "make
install").
configure: I've reverted one change as part of this merge:
commit 9f99a301b1
Remove ./configure failure for unrecognized options
I'd much rather find what options the Debian scripts pass
and either implement them or at least make the explicitly
do nothing. One of the things that often annoyed me about
gnu autoconf-generated configure scripts was the silent
ignoring of unknown options, (which was very unhelpful in
the case of mistyped options on the command line).
It makes sense to me to have the little tests for functionality right
next to the comptability implementations of that same functionality.
But also, this means I can now tab-complete ./configure from the three
initial characters (rather than the seven required previously).
The original "contrib" name is lousy. Everything in notmuch has been
contributed, and we are integrating as much of it as possible, (rather
than making users grub through contrib looking for useful pieces to
install).
Meanwhile, the only things we have in contrib are command-line
completion scripts, so "completion" makes more sense as a name, (and
helps make "./configure" slightly less ambiguous).
Again, simplifying the interface to the Makefile. Installing these
files doesn't require bash nor zsh to actually be installed, so there's
little harm in just installing them unconditionally.
Instead, simply byte-compile the emacs source files as part of "make"
and install them as part of "make install". The byte compilation is
made conditional on the configure script finding the emacs binary.
That way, "make; make install" will still work for someone that doesn't
have emacs installed, (which was the only reason we had made a separate
"make install-emacs" target in the first place).
With the original quiet function, there's an actual purpose (hiding
excessively long compiler command lines so that warnings and errors
from the compiler can be seen).
But with things like quiet_symlink there's nothing quieter. In fact
"SYMLINK" is longer than "ln -sf". So all this is doing is hiding the
actual command from the user for no real benefit.
The only actual reason we implemented the quiet_* functions was to be
able to neatly right-align the command name and left-align the arguments.
Let's give up on that, and just left-align everything, simplifying the
Makefiles considerably. Now, the only instances of a captialized command
name in the output is if there's some actually shortening of the command
itself.
For other projects I release, there's a bunch of manual effort in
cosntructing the final release-announcement email. That's silly.
So automate this by extracting the appropirate text from NEWS and
by including a canned piece of the content from README.
This is a merge of the few changes I made to release 0.1
retroactively, (after having incremented the version to 0.1.1).
Conflicts:
Makefile.local (renamed NOTMUCH_VERSION to VERSION)
Generally, the NEWS items will describe changes since the previous
release. But there's not much we can do for that since we've never had
a release before.
