Also bump the python bindings version, the NEWS version and the Debian
version.
Since the changelog is (slightly dubiously) metadata, we have to
change it to upload a release candidate.
Wildcard matching was a feature of the probabilistic prefix, and we no
longer have it for the boolean prefix. Also note that top-level folder
can now be searched.
The changes landed with c200167 (nmbug: Add 'clone' and replace
FETCH_HEAD with @{upstream}, 2014-03-09).
The preferred markup language for NEWS seems to be Markdown, which is
parsed by devel/news2wiki.pl into Markdown chunks for rendering by
ikiwiki [1].
[1]: http://notmuchmail.org/news/
If the user has unsorted or alphabetically sorted saved-searches these
should continue to work. If they have some custom lisp sort function
then it will need updating to work with the new saved-sort
format. Document this, and how the updating should be done.
Also roll in fixes for the markdown in the first part of the NEWS
suggested by Tomi: change `just work' to *just work* and removed
periods from the end of subtitle lines.
The important point is that the changed search variable is not forward
compatible (it *is* backwards compatible): that is previous version
of notmuch-emacs will be unusable with a new style
notmuch-saved-search variable.
Roll (one last?) release candidate because of Austin's
LIBNOTMUCH_VERSION changes.
Atomically bump the manually (NEWS, debian/changelog) and
automatically (everywhere else) updated places version is mentioned.
News for
commit 5c19eb46a9
Author: Jani Nikula <jani@nikula.org>
Date: Sun Sep 1 20:59:53 2013 +0300
emacs: insert quotable parts in reply as they are displayed in show view
The 0.16 NEWS grew chronologically during development, and as a result
wound up in a particularly odd order. This rearranges it to put the
most user-visible news first. Roughly: new features, modified
behavior, bug fixes, then deprecation, with related items grouped.
This does not modify the text of any of the news.
While looked good on paper, its attempted use caused confusion, complexity,
and potential for information leak when passed through wrapper scripts.
For slimmer code and to lessen demand for maintenance/support the set of
commits which added top level --stderr= option is now reverted.
As discussed in id:871udhcmks.fsf@zancas.localnet, notmuch-vim doesn't
really meet the standards of the CLI, emacs interface, or python
bindings in terms of being well maintained.
The commands are long deprecated, so removal is probably overdue. The
real motivation is to simplify argument handling for notmuch so that
we can migrate to the common argument parsing framework.
Date range search may be implemented as a library change, but it's an
important user-facing change that affects all notmuch usage. Tag name
restrictions aren't as important, but they affect both the CLI
interface and the Emacs interface.
Added the following Emacs Interface NEWS entries:
Catch errors bodypart insertions may throw,
Improved text/calendar content handling and
Disabled coding conversions when reading in
`with-current-notmuch-show-message`.
Thanks to Austin and David for content improvements.
notmuch show --format json now includes Bcc and Reply-To headers of
the message. Mention that in NEWS.
(Heavily modified version of text originally from Michal Nazarewicz.)
0.13.2: `contrib/notmuch-deliver` is in backticks elsewhere in
NEWS file. Commands are generally written in backticks in latest
NEWS entries.
0.13.1: Dropped period at the end of Title
'Fix compilation of ruby bindings',
as all other titles do not end with a period.
The recent change to use json for notmuch-search.el introduced a bug
in the code for keeping position on refresh. The problem is a
comparison between (plist-get result :thread) and a thread-id returned
by notmuch-search-find-thread-id: the latter is prefixed with
"thread:"
We fix this by adding an option to notmuch-search-find-thread-id to
return the bare thread-id. It appears that notmuch-search-refresh-view
is the only caller of notmuch-search that supplies a thread-id so this
change should be safe (but could theoretically break users .emacs
functions).
