| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Convert the part headers into buttons that save the part when
activated.
|
|
|
|
|
|
| |
Use the `notmuch part' command to access body parts not currently
included in the JSON output and display those body parts
appropriately.
|
|
|
|
|
|
|
|
|
|
| |
Use the mailcap functionality to guess a MIME type for attachments of
type application/octet-stream and, presuming successful, feed the
attachment back into the display code with the determine type.
This is mostly useless at the moment, as the JSON output from notmuch
does not include the content of application/octet-stream parts, so
they cannot be displayed even if the guess is a good one.
|
|
|
|
|
|
| |
For parts that the mm-decode/mm-view functions can inline and we have
the content, use `mm-display-part' to insert the part in the
buffer.
|
|
|
|
|
|
|
|
| |
If a text/plain part is not the first part in a message, add a label
in order that a user can see that multiple parts are present.
If a part has a 'filename' attribute, include it in any label
describing the part.
|
|
|
|
|
|
| |
Move the citation and signature markup for text/plain parts to a new
file (notmuch-wash.el) and call it using a hook mechanism rather than
directly.
|
|
|
|
|
| |
This is more consistent with the related names (toggle-message,
:message-visible, etc.)
|
|
|
|
|
|
|
|
|
|
|
| |
In the recent switch to a JSON-based emacs interface, RET now toggles
message visibility anywhere in the message, (rather than only on the
summary line). So we no longer need this separate "b" binding for this.
Additionally, the body toggle was implemented independently from RET,
so after hiding a message with "b" one could not make it visible with
RET. This confusing state is now no longer possible, (since the
:body-visible property is removed entirely).
|
|
|
|
|
|
| |
Re-implement notmuch-show.el using the JSON output format of the
notmuch command. Most functionality is retained - HTML display is
noticeably missing.
|
|
|
|
|
|
|
|
|
|
|
| |
The special case for len==0 was wrong---the normal code path is to
talloc to get a newly allocated, editable string, that might be
talloc_free'd later. It makes more sense just to let the len==0
behaviour fall through into the normal case code.
Reviewed-by: Carl Worth <cworth@cworth.org>
This results in the same value being returned, but with the proper
memory handling.
|
|
|
|
|
| |
MIME parts may have no filename, which previously resulted in calling
strlen(NULL).
|
| |
|
|
|
|
|
| |
If the text being stashed included %, `message' was unhappy and
complained.
|
|
|
|
|
| |
The "make release" target doesn't cause these to be left around, but
manually doing something like ./debian/rules/build can.
|
|
|
|
| |
Finally, a single button to push to do all the uploading.
|
|
|
|
| |
Only minor features added this time--nothing that merits a 1.0.
|
|
|
|
|
|
|
| |
Eventually I'd like to automate this so that one or the other of these
files is canonical and the other is generated from it. Until then, add
this check to the release process to avoid a skewed release being
shipped.
|
|
|
|
| |
This cleans up a few spurious warnings from the build.
|
|
|
|
|
|
|
|
|
| |
On Linux, a C program that depends on a C library which in turn
depends on a C++ can be linked with the C compiler, (avoiding a direct
link from the program to the C++ runtime libraries).
Other platforms with less fancy linkers need to use the C++ compiler
for this linking.
|
|
|
|
|
| |
We're switching to a native package, where we build the upstream and
debian releases simultaneously, so there's no need for a watch file.
|
|
|
|
| |
To keep lintian happy.
|
|
|
|
|
| |
Otherwise, building from a tar-file snapshot or release caused a bunch
of error messages from unnecessary git invocations.
|
|
|
|
|
|
| |
Useful for verifying that our tar-file creation works. The tar-file
name can't easily be used as a target directly since it depends on the
current git revision.
|
|
|
|
|
|
| |
Theese were previously pointing to "make VERSION=X.Y release", but
we've recently changed to an alternate scheme involving the updated
version in a file named "version".
|
|
|
|
|
|
| |
It is annoying to have an extra step here, but it does at least mean
that we are back to just "make release" rather than "make VERSION=X.Y
release".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do this so that "git archive" produces a usable tar file without us
having to post-modify it, (since tools like git-buildpackage might not
give us an easy way to hook into the tar-file-creation step).
To support this we also have to change our preference to prefer the
git-described-based version (if available) and only if not available
do we fallback to using what's in the "version" file. Finally, we also
ovverride this preference when releasing, (where what's in the
"version" file wins).
Note that using our Makefile's rule to create a tar file still will
insert the git-based version into the tar file. This is useful for
creating snapshots which will correctly report the git version from
which they were created.
|
|
|
|
| |
A (very slightly filtered) version of what already appears in NEWS.
|
|
|
|
|
| |
I'd like to have this be fully automated in the future, but for now,
it's an extra step.
|
|
|
|
|
|
|
| |
David Bremner informs me that shoving everything from the notmuch "git
log" into the debian/changelog is a bit excessive. Instead, we'll
start manually updating this file, (which feels a bit redundant with
NEWS, but perhaps makes us a better Debian-comunity member).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Bdale Garbee's recommendation I'm switching from gitpkg, (which
constructed a source tree but still required me to go run debuild), to
git-buildpackage. I hadn't originally used git-buildpackage because it
didn't seem to work without a configuration file, (where gitpkg was
fine).
Bdale was kind enough to point me to his fw/altos source at
git.gag.com where I found an example gpb.conf file as well as a target
in debian/rules to automatically update debian/changelog with the new
version number.
|
|
|
|
|
| |
It's just too long for copy/paste, so just let the user know the name
of the file containing the message instead.
|
|
|
|
| |
This was accidentally hard-coded to always print the 0.1 NEWS blurb.
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit fbec989fe3272d6eff038369587be076347b96f0.
I only pushed this accidentally. See message
id:871ver6u9r.fsf@yoom.home.cworth.org for the various reasons I
didn't like this patch, (mostly I think the association of 'F' is
wrong).
|
|
|
|
|
|
|
|
| |
We previously output "notmuch version 0.1" as response to notmuch --version.
Shorten this to "notmuch 0.1" as we know that we will receive a version
number when we explicitely ask for it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the recent addition of "*" being a special case for a search
matching all messages, we have to take care when doing a filter
operation. In this case it's not legal to simply append and get:
* and <some-new-search-terms>
Instead we carefully construct a new search string of only:
<some-new-search-terms>
This could all be avoided if we had a parser that could understand
"*" with the meaning we want.
|
|
|
|
|
|
|
| |
It was noted today in IRC that libnotmuch is not yet careful about
wrapping all Xapian calls with try/catch blocks to print nicer error
messages. It seems it would be natural to audit that at the same time
as doing the symbol-hiding work.
|
|
|
|
|
|
|
| |
We actually want this version to be incremented by the commits that
extend the interface. So the release process really is not to just
verify two things (NEWS and libnotmuch version), then run "make
VERSION=x.y release", and send the mail. Quite nice.
|
|
|
|
|
| |
Where by clean, we check that no files are known to git to be
modified.
|
|
|
|
|
|
|
|
|
|
|
| |
The entire "make sure the code you want is in place" thing is part of
a larger release process that we don't document here at all. Instead,
we just focus here on the mechanics of pushing things out once the
larger process has determined the code is ready.
And the fewer steps there are, the better, (for making the
release-process as painless as possible and for avoiding any
mistakes).
|
|
|
|
|
|
| |
Before and after the assignment operator, no spaces are allowed.
I don't know if there are any /bin/sh which allow spaces, but at least
in bash, csh and zsh, the former code was no valid assigment.
|
| |
|
|
|
|
|
| |
I'm unlikely to always remember to pass VERSION=X.Y so it's nice for
make release to remind me.
|
|
|
|
|
|
|
|
|
|
|
| |
We put verify-version as a dependency, not a recursive action to keep
its output clean, (I know that I will always type "make release"
instead of "make VERSION=X.Y release" so I want a nice, neat
reminder).
Also, put the various ssh-based commands together, and after the
build, (so that it doesn't ask for a password/passphrase both before
and after building).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had a separate release-upload target that a user might
mistake as something useful to call directly, (which would have the
undesired effect or uploading a new package, but without first making
all the checks that we want).
So we eliminate that target, (folding its actions into "make
release"), and we also rename the several release-verify-foo targets
to simply verify-foo. This leaves as the only targets with "release"
in the name as "release" and "release-message". Both of these are
intended for the user to call directly.
|
|
|
|
| |
Just an extra word that clearly didn't belong.
|
|
|
|
|
|
|
| |
We've now changed to using "git describe" to automatically report a
version number that changes with every git commit. So we no longer
need to manually update anything in the Makefile during the release
process.
|
|
|
|
|
| |
This drops one manual step from our release process, (helping
to ensure we don't forget anything during the release).
|
|
|
|
|
|
|
|
| |
Hurrah---no more manual verification of that PASS column.
This means that "make test" can actually be a useful part of the
release process now, (since it will exit with non-zero status if there
are any failures).
|
|
|
|
|
|
|
|
|
|
|
| |
Previously some tests (dump/restore) were doing ad-hoc verification of
values and their own printing of PASS/FAIL, etc. This made it
impossible to count test pass/fail rates in a single place.
The only reason these tests were written that way was because the old
execute_expecting function only worked if one could directly test the
stdout output of a notmuch command. The recent switch to pass_if_equal
means that all tests can use it.
|