| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
To help people pester me in the case of uploading a new upstream
release without a corresponding Debian package.
|
|
The libnotmuch.so library already does, so we don't need to do
it again. (Thanks to a Debian debhelper warning for pointing this
out.)
|
|
This avoids a lintian complaint about several packages with identical
package descriptions.
|
|
With man pages we have to be careful or commands may not function
after copy-and-paste.
|
|
No changes needed.
|
|
The library goes into libnotmuch1 and the headers into libnotmuch-dev.
|
|
We're doing debian packaging in the primary repository now.
|
|
It just doesn't work.
|
|
This broke when we changed from a single notmuch.el file
to multiple notmuch-foo.el files.
|
|
Now that we have multiple emacs-lisp source files, it's just more
polite this way.
|
|
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).
|
|
To make a Debian package for the recent 0.1 release of notmuch.
|
|
These include:
--infodir=DIR
--localstatedir=DIR
--libexecdir=DIR
--disable-maintainer-mode
--disable-dependency-tracking
|
|
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.
|
|
Again, nothing tricky here.
|
|
Very similar to the existing --libdir option.
|
|
Since we're emitting the user's input back, let's leave it pristine
and not confuse the issue by adding a final period.
|
|
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 9f99a301b158dc1ed1c8c6754db1d57e3b0becf4
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).
|
|
For much better modularity.
|
|
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).
|
|
The "make release" target creates this directory, but it's nothing
I'll ever want to add to the git repository.
|
|
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.
|
|
At the end of "make release" or at any point later with
"make release-message".
|
|
Otherwise I'm sure I'll always forget to push it.
|
|
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)
|
|
And hopefully it actually works.
|
|
So far just doing checks that the version is sane and that no release
of the same version already exists.
|
|
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.
|
|
These steps might be changing a bit as we work on making the initial
0.1 release.
|
|
After publishing the first notmuch release (0.1) to
http://notmuchmail.org/releases .
|
|
To create a versioned tar file for release.
|
|
Just to avoid any clash with files of the same names.
|
|
Initially this file provides one main function
notmuch-query-get-threads, which takes a set of search terms, and
returns a parsed set of matching threads as a lisp data structure.
A set of notmuch-query-map-* functions are provided to help map
functions over the data structure.
The function notmuch-query-get-message-ids uses this machinery to get
the set of message-ids matching a query.
Edited-by: Carl Worth <cworth@cworth.org>: Change comment syntax,
(";;" rather than ";" to make emacs-lisp mode happy), and eliminate
some excess whitespace, as suggested by David Edmonson.
|
|
Text parts returned by `g_mime_stream_mem_get_byte_array()' are not
NULL terminated strings - add `json_quote_chararray()' to handle them
correctly.
|
|
|
|
To ease the transition to a JSON based implementation of
`notmuch-show', move the current implementation into a separate file.
Create `notmuch-lib.el' to hold common variables.
|
|
|
|
Both of these ideas were recently discussed on the mailing list.
|
|
Emacs really wants us to defvar each variable before assigning to it,
(which gives us a place to document the variable as well).
|
|
Assume that tags never include an opening bracket, and hence improve
the regular expression used to highlight them. This avoids false
matches where the 'from' address of a thread participant includes an
opening bracket.
|
|
We add a magic line to the beginning of each Makefile.local file to
help the editor know that it should use makefile mode for editing the
file, (even though the filename isn't exactly "Makefile").
Edited-by: Carl Worth <cworth@cworth.org>: Expand treatment from
emacs/Makefile.local to each instance of Makefile.local.
|
