[notmuch] nested tag trees (was: Mail in git)

Excerpts from martin f krafft's message of Wed Feb 17 22:46:13 -0500 2010: > You ought to have sent to the list, and I want to send mine there > too, so please give permission. > Oops! Sorry about that. Damn you sup. > also sprach Ben Gamari [2010.02.18.1620 +1300]: > > This is a very good

[notmuch] Fwd: Re: nested tag trees (was: Mail in git)

--- Begin forwarded message from martin f krafft --- From: martin f krafft To: Ben Gamari Date: Wed, 17 Feb 2010 22:46:13 -0500 Subject: Re: nested tag trees (was: [notmuch] Mail in git) You ought to have sent to the list, and I want to send mine there too, so please give

[notmuch] Mail in git

Excerpts from martin f krafft's message of Wed Feb 17 20:58:47 -0500 2010: > also sprach Ben Gamari [2010.02.18.1339 +1300]: > > Yes, it would be linear in number of tags. I suppose if messages > > weren't stored in the top-level tree nodes, then it would still be > > linear, although with a

[notmuch] Mail in git

enless.pl: maildir to git using fast-import URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100217/bc1a3f34/attachment.pl> -- next part -- -- Stewart Smith

[notmuch] Mail in git

Excerpts from Stewart Smith's message of Wed Feb 17 18:56:53 -0500 2010: > On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft > wrote: > > What I am wondering is if (explicit) tags couldn't be represented as > > tree-objects with this. > > I think it could get expensive for tags with lots of

[notmuch] Mail in git

Excerpts from martin f krafft's message of Wed Feb 17 18:52:11 -0500 2010: > also sprach Ben Gamari [2010.02.18.0834 +1300]: > > Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 > > 2010: > > > But if we have notmuch as a cache of the tags, then don't we > > > already know the

[notmuch] Mail in git

Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: > But if we have notmuch as a cache of the tags, then don't we already > know the tree objects that need updating? Yes, we would probably need > some consistency checks for when things don't work as planned, but in > the

[notmuch] [PATCH] Simplify "unread" tag handling in emacs UI.

On Tue, 19 Jan 2010 17:54:16 -0500, Jameson Rollins wrote: > This patch is intended to greatly simplify the handling of the > "unread" tag in the emacs UI. This patch adds a new function > 'notmuch-show-mark-read', that removes the "unread" tag in > notmuch-show-mode. This function is then

[notmuch] Mail in git

gital signature (see http://martin-krafft.net/gpg/) URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100217/b6a453a6/attachment.pgp>

[notmuch] [PATCH 2/2] notmuch.el: Replace inline function calls for body cleaning with a hook mechanism.

In-lining every possible body cleaning function is difficult to maintain and doesn't allow users any flexibility. Rather, use a hook mechanism so that users can choose what cleaning takes place. notmuch-washing.el: Sample cleaning functions. --- Makefile.local |6 +++- notmuch-washing.el

[notmuch] [PATCH 1/2] build: Ensure that '.' is in the emacs load-path when compiling files.

--- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 64b9d4a..9fcb2b9 100644 --- a/Makefile +++ b/Makefile @@ -60,7 +60,7 @@ quiet ?= $($1) $(call quiet,CC,$(CFLAGS)) -c $(FINAL_CFLAGS) $< -o $@ %.elc: %.el - $(call

[notmuch] [PATCH] notmuch.el: bind 'd' to new function notmuch-search-delete-thread-or-region

Create a new function notmuch-search-delete-thread-or region which does exactly what its name implies. Hitting 'd' will delete the current thread (or multiple threads if you marked a region). Deleting means adding tag 'delete' and removing tags 'unread' and 'inbox' in this case. This patch

[notmuch] Mail in git

On Wed, 17 Feb 2010 10:03:36 -0500, Ben Gamari wrote: > > notmuch would then only search and provide the hash ID(s); tags > > would be a function of storage. > > > > Is it possible to find out all trees that reference a given object > > with Git in constant or sub-linear time? > > > I don't

[notmuch] Mail in git

On Tue, 16 Feb 2010 14:06:29 -0500, Ben Gamari wrote: > Excerpts from Stewart Smith's message of Sun Feb 14 19:29:14 -0500 2010: > > So... I sketched this out in my head at LCA... and it's taken a bit of > > time to actually properly try it. > > > In case anyone wanted to play around with this,

[notmuch] [PATCH] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

In many conversations the last few lines of a citation are more interesting than the first few lines, hence allow those to be shown if desired. Modify the face used for the citation button to distinguish it from the surrounding citation. --- notmuch.el | 37

[notmuch] Mail in git

Excerpts from martin f krafft's message of Tue Feb 16 20:21:01 -0500 2010: > What I am wondering is if (explicit) tags couldn't be represented as > tree-objects with this. > > evenless-link ? link a message object with a tree object > evenless?unlink ? unlink a message object from tree

[notmuch] [PATCH] Simplify "unread" tag handling in emacs UI.

/notmuchmail.org/pipermail/notmuch/attachments/20100217/0746af09/attachment.pgp>

[notmuch] Using test-lib.sh under GPLv3?

Dnia wtorek 16. lutego 2010 14:06, Michal Sojka napisa?: > On Tue, 16 Feb 2010 02:27:37 -0800 (PST), Jakub Narebski gmail.com> wrote: > > Michal Sojka writes: > > > > > I like the simple and powerful test suite used by Git and I would like > > > to use something like that in Notmuch project

Re: [notmuch] Mail in git

On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith stew...@flamingspork.com wrote: Using fast-import is interesting. Does it update the working tree? The big thing I wanted to avoid was creating a working tree (another million inodes being created is not ever what I need) Also interesting is

[notmuch] [PATCH] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

In many conversations the last few lines of a citation are more interesting than the first few lines, hence allow those to be shown if desired. Modify the face used for the citation button to distinguish it from the surrounding citation. --- notmuch.el | 37

[notmuch] [PATCH] notmuch.el: bind 'd' to new function notmuch-search-delete-thread-or-region

Create a new function notmuch-search-delete-thread-or region which does exactly what its name implies. Hitting 'd' will delete the current thread (or multiple threads if you marked a region). Deleting means adding tag 'delete' and removing tags 'unread' and 'inbox' in this case. This patch

Re: [notmuch] [PATCH] Simplify unread tag handling in emacs UI.

On Tue, 19 Jan 2010 17:54:16 -0500, Jameson Rollins jroll...@finestructure.net wrote: This patch is intended to greatly simplify the handling of the unread tag in the emacs UI. This patch adds a new function 'notmuch-show-mark-read', that removes the unread tag in notmuch-show-mode. This

[notmuch] [PATCH 1/2] build: Ensure that '.' is in the emacs load-path when compiling files.

--- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 64b9d4a..9fcb2b9 100644 --- a/Makefile +++ b/Makefile @@ -60,7 +60,7 @@ quiet ?= $($1) $(call quiet,CC,$(CFLAGS)) -c $(FINAL_CFLAGS) $ -o $@ %.elc: %.el - $(call

[notmuch] [PATCH 2/2] notmuch.el: Replace inline function calls for body cleaning with a hook mechanism.

In-lining every possible body cleaning function is difficult to maintain and doesn't allow users any flexibility. Rather, use a hook mechanism so that users can choose what cleaning takes place. notmuch-washing.el: Sample cleaning functions. --- Makefile.local |6 +++- notmuch-washing.el

Re: [notmuch] [PATCH] Simplify unread tag handling in emacs UI.

On Wed, 17 Feb 2010 14:33:11 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: I've been using this for quite some time now and I am pretty happy with it. However, there is a problem with this approach as this renders the function notmuch-show-next-unread-message useless. This proceeds

Re: [notmuch] Mail in git

On Wed, 17 Feb 2010 10:03:36 -0500, Ben Gamari bgam...@gmail.com wrote: notmuch would then only search and provide the hash ID(s); tags would be a function of storage. Is it possible to find out all trees that reference a given object with Git in constant or sub-linear time? I don't

Re: [notmuch] Mail in git

also sprach Ben Gamari bgam...@gmail.com [2010.02.18.0834 +1300]: Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: But if we have notmuch as a cache of the tags, then don't we already know the tree objects that need updating? Yes, we would probably need some

Re: [notmuch] Mail in git

On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft madd...@madduck.net wrote: What I am wondering is if (explicit) tags couldn't be represented as tree-objects with this. evenless-link — link a message object with a tree object evenless–unlink – unlink a message object from tree

Re: [notmuch] Mail in git

Excerpts from martin f krafft's message of Wed Feb 17 18:52:11 -0500 2010: also sprach Ben Gamari bgam...@gmail.com [2010.02.18.0834 +1300]: Excerpts from Mark Anderson's message of Wed Feb 17 14:23:48 -0500 2010: But if we have notmuch as a cache of the tags, then don't we already know

Re: [notmuch] Mail in git

also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1401 +1300]: If we keep ancestry though, we are reusing existing working code for backup (git-pull :) This is one of the reasons I feel it's important we keep it. And as is stated below, the storage overhead is minimal. Absolutely;

Re: [notmuch] Mail in git

Excerpts from martin f krafft's message of Wed Feb 17 20:58:47 -0500 2010: also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1339 +1300]: Yes, it would be linear in number of tags. I suppose if messages weren't stored in the top-level tree nodes, then it would still be linear, although

Re: [notmuch] nested tag trees (was: Mail in git)

[Taking a private message back to the list with permission] also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1620 +1300]: This is a very good point. From what I've read about the database format, I can't think of any way that reverse dependencies could be easily found, unfortunately. If

[notmuch] Fwd: Re: nested tag trees (was: Mail in git)

--- Begin forwarded message from martin f krafft --- From: martin f krafft madd...@madduck.net To: Ben Gamari bgam...@gmail.com Date: Wed, 17 Feb 2010 22:46:13 -0500 Subject: Re: nested tag trees (was: [notmuch] Mail in git) You ought to have sent to the list, and I want to send mine there too,

Re: [notmuch] Fwd: Re: nested tag trees (was: Mail in git)

Excerpts from Ben Gamari's message of Wed Feb 17 23:38:13 -0500 2010: --- Begin forwarded message from martin f krafft --- From: martin f krafft madd...@madduck.net To: Ben Gamari bgam...@gmail.com Date: Wed, 17 Feb 2010 22:46:13 -0500 Subject: Re: nested tag trees (was: [notmuch] Mail in

Re: [notmuch] nested tag trees (was: Mail in git)

also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1744 +1300]: I believe you would. The problem isn't the messages (well, that's a problem too), it's the fact that the tree (e.g. tab) objects which reference the messages are immutable (I believe). This presents us with the difficult

Re: [notmuch] nested tag trees (was: Mail in git)

Excerpts from martin f krafft's message of Wed Feb 17 23:59:43 -0500 2010: also sprach Ben Gamari bgam...@gmail.com [2010.02.18.1744 +1300]: I believe you would. The problem isn't the messages (well, that's a problem too), it's the fact that the tree (e.g. tab) objects which reference the