Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id F0FFA4196F3 for ; Sat, 27 Mar 2010 22:46:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KujrbMhCDqcH for ; Sat, 27 Mar 2010 22:46:43 -0700 (PDT) Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36]) by olra.theworths.org (Postfix) with ESMTP id 9829F4196F2 for ; Sat, 27 Mar 2010 22:46:43 -0700 (PDT) Received: from localhost (unknown [192.168.200.4]) by max.feld.cvut.cz (Postfix) with ESMTP id F168419F3409; Sun, 28 Mar 2010 07:46:42 +0200 (CEST) X-Virus-Scanned: IMAP AMAVIS Received: from max.feld.cvut.cz ([192.168.200.1]) by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new, port 10044) with ESMTP id GHMZHJvCJyBP; Sun, 28 Mar 2010 07:46:41 +0200 (CEST) Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34]) by max.feld.cvut.cz (Postfix) with ESMTP id A775419F33CD; Sun, 28 Mar 2010 07:46:41 +0200 (CEST) Received: from steelpick.2x.cz (r5da224.net.upc.cz [86.49.116.224]) (Authenticated sender: sojkam1) by imap.feld.cvut.cz (Postfix) with ESMTPSA id 360EAFA003; Sun, 28 Mar 2010 07:46:41 +0200 (CEST) Received: from wsh by steelpick.2x.cz with local (Exim 4.71) (envelope-from ) id 1NvlKa-0007tT-Qn; Sun, 28 Mar 2010 07:46:40 +0200 From: Michal Sojka To: Sebastian Spaeth , David Edmondson , notmuch@notmuchmail.org In-Reply-To: <87aatt2pf7.fsf@SSpaeth.de> References: <87iq8o76r8.fsf@uf.hh.sledj.net> <87aatt2pf7.fsf@SSpaeth.de> Date: Sun, 28 Mar 2010 07:46:40 +0200 Message-ID: <87y6hdgfr3.fsf@steelpick.2x.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [notmuch] JSON based emacs UI X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 05:46:45 -0000 On Sun, 28 Mar 2010, Sebastian Spaeth wrote: > On Mon, 22 Mar 2010 14:47:39 +0000, David Edmondson 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