[notmuch] JSON based emacs UI

[Michal Sojka]

On Sun, 28 Mar 2010, Sebastian Spaeth wrote:
> On Mon, 22 Mar 2010 14:47:39 +0000, David Edmondson <dme at dme.org> wrote:
> > I'm pushed the first stage of a JSON based emacs UI to the repository at
> > http://github.com/dme/notmuch (it's in the "master" branch).
> 
> Despite the switch to daylight savings time stealing me an hour of this
> night, I managed to test your new notmuch.el.
> 
> It works really nice and I get the (unmeasured) feeling that it is
> faster too (but then it might just be the lack of my additional patches
> which slow things down :-)).
> 
> I have one question (which is more build related): now, I have to pull
> your branch and an make install-emacs will also always compile and
> install the notmuch binary from your branch, but I might want to keep my
> own notmuch binary. Is it possible to just use the notmuch frontend from
> your branch, but not having to install the binary? Is there such a make
> target, or any other way? Should we create a repo that just contains the
> frontend and not notmuch itself, so people can mix and match more
> easily? (not sure what the right answer is here).

Hi Sebastian,

I don't think this can be solved only in Makefile. From my look at dme's
repo, he adds a new subcomand 'part', which is used by the UI. So if you
want to use the new UI and your other features, you need to merge the
things together.

To build my version of notmuch, I use an ugly script
(http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage)
which first does a big octopus merge to combine several features to one
branch and then I build notmuch from there. The current state of my
integration can be seen at
http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features.

This approach has a disadvantage that integration/features branch is
often rewritten (whenever I add, remove or change a patch) so that
others cannot track the branch. On the other side, the advantage is that
others can easily see which patches I have applied on top of master. If
Carl updates master, I just rerun the script and the updated integration
branch is ready (unless there is a merge conflict).

Cheers,
Michal