Proposal: Features instead of versions
I believe our current approach to database schema changes is inhibiting the evolution of Notmuch's features and would like to propose what I think is lighter-weight solution. Currently, our database schema is versioned and each database schema change must occur "atomically" in Notmuch's development history: before some commit, Notmuch uses version N, after that commit, it uses version N+1. Hence, each new schema version can introduce only one change, the task of developing a schema change falls on a single person, and it must all happen and be perfect in a single commit series. This makes introducing a new schema version hard. We've seen only two schema changes in the history of Notmuch. I'd like to propose that we switch to a "feature set", recorded in a database field. The recent introduction of boolean folder terms would be a "feature" (and the lack of that feature would imply probabilistic folder terms). Likewise, the file terms added in version 1 would be a "feature". The upgrade process would be structured around the delta between the database's feature set and the desired feature set. For many things, it would be easy to support databases both with and without a feature, which would enable "unstable" features that can be developed and tested over time, and different features could be under development in parallel. We can also mark features as required or optional for opening the database in read mode and replace our current unknown version warning (which the user can't act on in any useful way) with either no warning or a straight failure. I've done some of this for my ghost messages support (restructuring upgrade, unstable features, and supporting both the current schema and the new schema), and it was simple and worked nicely. This is also very similar to how ext4 works [1]. Thoughts? [1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block fields 0x5C through 0x64.
Proposal: Features instead of versions
I believe our current approach to database schema changes is inhibiting the evolution of Notmuch's features and would like to propose what I think is lighter-weight solution. Currently, our database schema is versioned and each database schema change must occur "atomically" in Notmuch's development history: before some commit, Notmuch uses version N, after that commit, it uses version N+1. Hence, each new schema version can introduce only one change, the task of developing a schema change falls on a single person, and it must all happen and be perfect in a single commit series. This makes introducing a new schema version hard. We've seen only two schema changes in the history of Notmuch. I'd like to propose that we switch to a "feature set", recorded in a database field. The recent introduction of boolean folder terms would be a "feature" (and the lack of that feature would imply probabilistic folder terms). Likewise, the file terms added in version 1 would be a "feature". The upgrade process would be structured around the delta between the database's feature set and the desired feature set. For many things, it would be easy to support databases both with and without a feature, which would enable "unstable" features that can be developed and tested over time, and different features could be under development in parallel. We can also mark features as required or optional for opening the database in read mode and replace our current unknown version warning (which the user can't act on in any useful way) with either no warning or a straight failure. I've done some of this for my ghost messages support (restructuring upgrade, unstable features, and supporting both the current schema and the new schema), and it was simple and worked nicely. This is also very similar to how ext4 works [1]. Thoughts? [1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block fields 0x5C through 0x64. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
nevermore
Nevermore is an experimental emacs email interface for Notmuch. It provides: * Interactive search * Snooze * Tag editing with autocompletion * Mail address completion (via company-mode) * Junk mail filtering (via bogofilter) Get it from github: https://github.com/tjim/nevermore I'm not sure where I'm taking nevermore. I was using it as my main mail client but I lost IMAP access to some of my mail, which makes it it less useful for me. But it has some features that I don't see in notmuch.el, so, I'm releasing it in case others find it interesting. -Trevor ? -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140710/3de7cc93/attachment.html>
[DRAFT PATCH] modified notmuch-emacs-mua
Highlights:
* notmuch-emacs-mua without arguments runs (notmuch-hello)
* runs emacs(1) in case emacsclient(1) fails to connect to running emacs
* takes -nw option
* handles mailto:
* --from option when sending non-mailto: way
* -i includes file --body[= ]string inserts string
---
notmuch-emacs-mua | 200 ++
1 file changed, 200 insertions(+)
create mode 100755 notmuch-emacs-mua
diff --git a/notmuch-emacs-mua b/notmuch-emacs-mua
new file mode 100755
index 000..b1696f7
--- /dev/null
+++ b/notmuch-emacs-mua
@@ -0,0 +1,200 @@
+#!/usr/bin/env bash
+# -*- mode: shell-script; sh-basic-offset: 4; tab-width: 8 -*-
+#
+# notmuch-emacs-mua - start composing a mail on the command line
+#
+# Copyright © 2014 Jani Nikula
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/ .
+#
+# Authors: Jani Nikula
+# Tomi Ollila
+#
+
+set -eu
+
+# "expand" '\' to '\\' & '"' to '\"'
+escape_optarg ()
+{
+OPTARG=${OPTARG//\\/}; OPTARG=${OPTARG//\"/\\\"}
+}
+
+# ditto, in case there is '\n' sequence in the source, otherwise
+# "expand" only trailing '\'s to '\\'s
+escape_body_optarg ()
+{
+case ${OPTARG} in
+ *'\"'*) OPTARG=${OPTARG//\\/} ;;
+ *'\') OPTARG=$( printf %s "${OPTARG}" | sed 's/\(\\*\)$/\1\1/' )
+esac
+OPTARG=${OPTARG//\"/\\\"}
+}
+
+unset ALTERNATE_EDITOR
+exec_mua ()
+{
+if "${EMACSCLIENT:=emacsclient}" --eval t >/dev/null 2>&1
+then
+ emacs=$EMACSCLIENT
+ # close stdout in case no -nw (and no --print)
+ test -n "$W$X" || exec >/dev/null
+else
+ emacs=${EMACS:-emacs}
+fi
+${X:-exec} "$emacs" $W --eval "$*"
+exit
+${X:-exec "$emacs" $W --eval} "$*"
+}
+
+X=
+W=
+
+SUBJECT= TO= CC= BCC= BODY= FROM= IB=
+
+while
+# first, handle "long" options which cannot be handled by getopts
+case ${1-} in
+ -nw)
+ W=-nw
+ shift
+ continue
+ ;;
+ mailto:*)
+ oIFS=$IFS; IFS=; OPTARG="$*" IFS=$oIFS
+ escape_optarg
+ exec_mua "(progn (require 'notmuch) (browse-url-mail \"$OPTARG\"))"
+ exit
+esac
+
+getopts :s:c:b:i:h opt
+do
+# Handle errors and long options.
+case ${opt} in
+ :)
+ echo "$0: short option '-${OPTARG}' requires an argument." >&2
+ exit 1
+ ;;
+ \?)
+ opt=$1
+ if [[ ${OPTARG} != '-' ]]; then
+ echo "$0: unknown short option '-${OPTARG}'." >&2
+ exit 1
+ fi
+
+ case ${opt} in
+ # Long options with arguments.
+ --subject=*|--to=*|--cc=*|--bcc=*|--body=*|--from=*)
+ OPTARG=${opt#--*=}
+ opt=${opt%%=*}
+ ;;
+ # Long options with argument in next arg.
+ --subject |--to |--cc |--bcc |--body |--from )
+ if [[ $# < 2 ]]; then
+ echo "$0: option '${opt}' requires an argument." >&2
+ exit 1
+ fi
+ OPTARG=$2
+ OPTIND=$((OPTIND + 1))
+ ;;
+ # Long options without arguments.
+ --help|--nw|--print)
+ ;;
+ *)
+ echo "$0: unknown long option '${opt}', or argument
mismatch." >&2
+ exit 1
+ ;;
+ esac
+ # getopts does not do this for what it considers errors.
+ OPTIND=$((OPTIND + 1))
+ ;;
+esac
+
+case ${opt} in
+ --help|h)
+ exec man notmuch-emacs-mua
+ ;;
+ --from)
+ escape_optarg
+ FROM=${OPTARG}
+ ;;
+ --subject|s)
+ escape_optarg
+ SUBJECT=${SUBJECT:+$SUBJECT }${OPTARG}
+ ;;
+ --to)
+ escape_optarg
+ TO=${TO:+$TO, }${OPTARG}
+ ;;
+ --cc|c)
+ escape_optarg
+ CC=${CC:+$CC, }${OPTARG}
+ ;;
+ --bcc|b)
+ escape_optarg
+ BCC=${BCC:+$BCC, }${OPTARG}
+ ;;
+ i)
+ escape_optarg
+ if [[ ! -f ${OPTARG} ]]; then
+ echo "$0: '${OPTARG}': no such file" >&2
+ exit 1
+ fi
+ IB=${IB}$'\n'" (insert-file \"${OPTARG}\
[PATCH 04/11] emacs: Track full message and part descriptor in w3m CID store
Austin Clements writes: > This will simplify later changes. I'd have preferred the whitespace changes as a seperate patch, but OK. d
[PATCH 03/11] emacs: Fix coding system in `notmuch-show-view-raw-message'
Austin Clements writes: > This fixes the known-broken test of viewing 8bit messages added by the > previous commit. this looks OK, but waits on a new version of the test in question? d
[PATCH 01/11] emacs: Remove redundant NTH argument from `notmuch-get-bodypart-content'.
Austin Clements writes: > This can be derived from the PART argument (which is arguably > canonical), so there's no sense in giving the caller an extra foot > gun. This patch seem ready to go, independant of the rest of the series. d
Re: [PATCH 04/11] emacs: Track full message and part descriptor in w3m CID store
Austin Clements writes: > This will simplify later changes. I'd have preferred the whitespace changes as a seperate patch, but OK. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 03/11] emacs: Fix coding system in `notmuch-show-view-raw-message'
Austin Clements writes: > This fixes the known-broken test of viewing 8bit messages added by the > previous commit. this looks OK, but waits on a new version of the test in question? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 01/11] emacs: Remove redundant NTH argument from `notmuch-get-bodypart-content'.
Austin Clements writes: > This can be derived from the PART argument (which is arguably > canonical), so there's no sense in giving the caller an extra foot > gun. This patch seem ready to go, independant of the rest of the series. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
