Hi,
maybe I missread the "manual" but I can't find an easy way to do
something simple in notmuch.el.
Say I have a thread with A-B-C. I visit the thread and read the
whole thread. Let's say after 'notmuch new' a post has entered
the thread: A-B-C-D. Is there an easy way to just have one of
these b
On Tue, 13 Apr 2010 23:19:37 +0100, James Westby
wrote:
> On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote:
> > Hi,
> >
> > maybe I missread the "manual" but I can't find an easy way to do
> > something simple in notmuch.el.
> >
> > Say I have a thread with A-B-C. I visit the thread a
On Tue, 13 Apr 2010 10:44:03 -0700, Carl Worth wrote:
> On Mon, 12 Apr 2010 10:30:54 +0200, "Sebastian Spaeth" SSpaeth.de> wrote:
> >
> > OK, final post from me on this issue.
>
> No, wait! I want more from you. :-)
>
> Would you care to put together a solution that does this from within
> not
previously we were always sorting the returned results by some string value,
but sometimes we might just be interested in the number of results, and don't
need any sorting.
Also add a --sort=unsorted command line option to notmuch search to test this.
A search that matches 1200 messages, returns i
Sebastian Spaeth wrote:
> previously we were always sorting the returned results by some string value,
> but sometimes we might just be interested in the number of results, and don't
> need any sorting.
>
> Also add a --sort=unsorted command line option to notmuch search to test this.
Does this
This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.
Signed-off-by: Sebastian Sp
On 2010-04-13, Carl Worth wrote:
> > OK, final post from me on this issue.
> No, wait! I want more from you. :-)
Sigh, they always want more :-)
> Would you care to put together a solution that does this from within
> notmuch*.el ? I really want things usable by default without people
> having to
On Wed, 14 Apr 2010 09:38:05 +0200, Sebastian Spaeth
wrote:
> This adds a function (and a hook) to have notmuch insert a User-Agent header
> into composed mails (even if invoked from not-notmuch ways, such as with
> ctrl-x m. This is invariably added for now without the possibility to
> turn it o
On 2010-04-14, Jason White wrote:
> > Also add a --sort=unsorted command line option to notmuch search to test
> > this.
>
> Does this provide relevance-ranked search results? I think relevance ranking
> is the Xapian default if a sort order isn't specified.
Yes, by default it is using sort_by_
On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
> The current hardcoded behaviour will not take you to the next unread
> thread when the sort order is set to newer-first from the default of
> older-first.
Is this really what we want? If I sort messages by newest first, it
menas that I want to pr
On Tue, 13 Apr 2010, Carl Worth wrote:
> On Thu, 8 Apr 2010 16:42:43 +0200, Michal Sojka
> wrote:
> > The goal of mailstore abstraction is to allow notmuch to store tags
> > together with email messages. The abstract interface is needed because
> > people want to use different ways of storing th
On Tue, 13 Apr 2010 19:29:29 -0400, Jameson Rollins wrote:
> On Tue, 13 Apr 2010 23:19:37 +0100, James Westby jameswestby.net> wrote:
> > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote:
> > > Say I have a thread with A-B-C. I visit the thread and read the
> > > whole thread. Let's say
On Wed, 14 Apr 2010 00:43:16 +0200, Xavier Maillard wrote:
> Is it done automatically ? Or do I need to do something special
> in order to unset the unread tag ?
>
> I see there is 'a' and 'x' when in notmuch-show but I am not sure
> I have to explicitely press on of these keys.
>
> Currently, w
On 2010-04-14, David Edmondson wrote:
> This really should be done with `define-mail-user-agent' and associated
> paraphernalia.
Which might be correct but beyond what I can provide :).
So, either we take this and get a followup patch, or someone improves
it, or we drop it.
Sebastian
On 2010-04-14, Michal Sojka wrote:
> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
> > The current hardcoded behaviour will not take you to the next unread
> > thread when the sort order is set to newer-first from the default of
> > older-first.
>
> Is this really what we want? If I sort messa
On 14 April 2010 05:53, Sebastian Spaeth wrote:
> On 2010-04-14, Michal Sojka wrote:
>> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
>> > The current hardcoded behaviour will not take you to the next unread
>> > thread when the sort order is set to newer-first from the default of
>> > older-f
This patch was originally sent by Andreas Kl?ckner in:
id:200912141421.52561.lists at informa.tiker.net. It was then
subsequently updated by Michal Sojka in:
id:1264692317-9175-2-git-send-email-sojkam1 at fel.cvut.cz and then
further improved again by Michal Sojka in:
id:1265122868-1213
rl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/93bc32ab/attachment.pgp>
ated header out,
right?
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/6243e524/attachment.pgp>
tachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/9dac5e4d/attachment.pgp>
nt was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/33817edb/attachment-0001.pgp>
in Makefile.config)
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/811366d4/attachment.pgp>
On Wed, 14 Apr 2010 10:14:46 -0700, Carl Worth wrote:
> The only real problem I see with this approach is that it's fragile in
> depending on the buffer having exactly 2 lines of non-thread text at the
> end. I can easily see myself wanting to remove the "End of Search
> Results" line at the end o
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/b0bce721/attachment.pgp>
plication/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/d2cb10f4/attachment.pgp>
, but it would be nice to not have
to do that in the future.
Thanks!
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/4e92d887/attachment.pgp>
eneration), from
Makefile.local up to the top-level Makefile.
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/86b68882/attachment.pgp>
On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth wrote:
> On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel
> wrote:
> > + * WARNING - if the caller is asking for a header that could occur
> > + * multiple times than they MUST first call this function with a
> > + * a value of NULL for header_desi
On Wed, 14 Apr 2010 12:50:50 -0500, Jesse Rosenthal
wrote:
> It occurs to me that the best way to do this would probably be to go to
> point-max, and then (forward-line -1) until we hit a thread-id. That way
> we wouldn't have to work all the way down long search indexes. I'll try
> to code that
27;s still broken. I did do a little testing
and research with the OS X machine I could find here, but I'm no expert,
nor do I have access to many other systems.
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/b61d1a1b/attachment.pgp>
have uncovered another
bug.
-Carl
[*] I say "should" because I don't believe we have any actual
specification of the data coming out of the JSON output yet. One other
thing that seems odd is the name of "date_unix" in the show output and
"timestamp" in the search output for what is effectively the same
field.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/d55ee234/attachment.pgp>
be the fastest thing to do).
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/b51d2e50/attachment.pgp>
ably wouldn't have
to be fast either---they could operate on the results of threads, which
are generally "small". At least, I hope nobody has threads with hundreds
of thousands of messages in them.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100414/f9030af5/attachment.pgp>
This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.
Signed-off-by: Sebastian Sp
On 2010-04-13, Carl Worth wrote:
> > OK, final post from me on this issue.
> No, wait! I want more from you. :-)
Sigh, they always want more :-)
> Would you care to put together a solution that does this from within
> notmuch*.el ? I really want things usable by default without people
> having t
On Wed, 14 Apr 2010 09:38:05 +0200, Sebastian Spaeth
wrote:
> This adds a function (and a hook) to have notmuch insert a User-Agent header
> into composed mails (even if invoked from not-notmuch ways, such as with
> ctrl-x m. This is invariably added for now without the possibility to
> turn it o
On 2010-04-14, Jason White wrote:
> > Also add a --sort=unsorted command line option to notmuch search to test
> > this.
>
> Does this provide relevance-ranked search results? I think relevance ranking
> is the Xapian default if a sort order isn't specified.
Yes, by default it is using sort_by_
On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
> The current hardcoded behaviour will not take you to the next unread
> thread when the sort order is set to newer-first from the default of
> older-first.
Is this really what we want? If I sort messages by newest first, it
menas that I want to pr
On Tue, 13 Apr 2010, Carl Worth wrote:
> On Thu, 8 Apr 2010 16:42:43 +0200, Michal Sojka wrote:
> > The goal of mailstore abstraction is to allow notmuch to store tags
> > together with email messages. The abstract interface is needed because
> > people want to use different ways of storing their
On Tue, 13 Apr 2010 19:29:29 -0400, Jameson Rollins
wrote:
> On Tue, 13 Apr 2010 23:19:37 +0100, James Westby
> wrote:
> > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote:
> > > Say I have a thread with A-B-C. I visit the thread and read the
> > > whole thread. Let's say after 'notmu
On Wed, 14 Apr 2010 00:43:16 +0200, Xavier Maillard wrote:
> Is it done automatically ? Or do I need to do something special
> in order to unset the unread tag ?
>
> I see there is 'a' and 'x' when in notmuch-show but I am not sure
> I have to explicitely press on of these keys.
>
> Currently, w
On 2010-04-14, David Edmondson wrote:
> This really should be done with `define-mail-user-agent' and associated
> paraphernalia.
Which might be correct but beyond what I can provide :).
So, either we take this and get a followup patch, or someone improves
it, or we drop it.
Sebastian
__
On 2010-04-14, Michal Sojka wrote:
> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
> > The current hardcoded behaviour will not take you to the next unread
> > thread when the sort order is set to newer-first from the default of
> > older-first.
>
> Is this really what we want? If I sort messa
On Thu, 8 Apr 2010 16:42:42 +0200, Michal Sojka wrote:
> My biggest question relates to the first patch, which does an
> incompatible change to libnotmuch API. After reading RELEASING file, I
> found that this change is probably not what Carl wants to merge (and I
> understand that) so I'd like t
On 14 April 2010 05:53, Sebastian Spaeth wrote:
> On 2010-04-14, Michal Sojka wrote:
>> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
>> > The current hardcoded behaviour will not take you to the next unread
>> > thread when the sort order is set to newer-first from the default of
>> > older-f
This patch was originally sent by Andreas Klöckner in:
id:200912141421.52561.li...@informa.tiker.net. It was then
subsequently updated by Michal Sojka in:
id:1264692317-9175-2-git-send-email-sojk...@fel.cvut.cz and then
further improved again by Michal Sojka in:
id:1265122868-12133-1-gi
On Tue, 13 Apr 2010 14:47:19 -0400, Jesse Rosenthal wrote:
> There was a bug in notmuch-search-{add,remove}-tag-region, which would
> not behave correctly if the region went beyond the last message. Now,
> instead of simply iterating to the last line of the region, these
> functions will iterate t
On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel wrote:
> + * WARNING - if the caller is asking for a header that could occur
> + * multiple times than they MUST first call this function with a
> + * a value of NULL for header_desired to ensure that all of the
> + * headers are parsed and concate
On Sun, 11 Apr 2010 19:43:27 -0400, Aaron Ecay wrote:
> In the process of updating to the latest sources, I've discovered that notmuch
> no longer builds on OS X.
Hi Aaron,
Thanks so much for following up here. This transition to
building/installing a shared library (and not using libtool) is th
On Sun, 11 Apr 2010 19:44:51 -0400, Aaron Ecay wrote:
> Since the binaries contain C++ code, it is necessary to use the C++
> linker, or errors result on some platforms (OS X).
Thanks. This one is merged and pushed.
-Carl
pgpGM3l7Vdhrk.pgp
Description: PGP signature
___
On Sun, 11 Apr 2010 19:44:52 -0400, Aaron Ecay wrote:
> Must set extra_c(xx)flags before including subdir Makefile.local's,
> so that there is a blank slate that the subdirs can add on to.
That part looks just fine, but it's intermixed with:
> Must include subdir Makefile.local's before global o
On Wed, 14 Apr 2010 10:14:46 -0700, Carl Worth wrote:
> The only real problem I see with this approach is that it's fragile in
> depending on the buffer having exactly 2 lines of non-thread text at the
> end. I can easily see myself wanting to remove the "End of Search
> Results" line at the end o
On Sun, 11 Apr 2010 19:44:53 -0400, Aaron Ecay wrote:
> This patch adds a configure check for OS X (actually Darwin),
> and sets up the Makefiles to build a proper shared library on
> that platform.
...
> -include $(subdirs:%=%/Makefile.local) Makefile.local
> +include Makefile.config $(subdirs:%=
On Sun, 11 Apr 2010 19:44:54 -0400, Aaron Ecay wrote:
> Otherwise, symbol not found errors result on OS X. I am not sure
> this is the correct solution for the problem, but it gets the build
> working.
...
> -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
> +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS)
On Tue, 13 Apr 2010 13:05:08 -0700, Dirk Hohndel wrote:
> On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky wrote:
> > On 4/13/10 6:47 PM, Dirk Hohndel wrote:
> > > v.3 of this patch, now with the changes to makefiles, configure script
> > > compat.h and all new files that I need
> > > Please te
On Wed, 14 Apr 2010 11:01:58 -0700, Carl Worth wrote:
> On Sun, 11 Apr 2010 19:44:53 -0400, Aaron Ecay wrote:
> > -include $(subdirs:%=%/Makefile.local) Makefile.local
> > +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local
>
> This first hunk looks unrelated to what's describe
On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth wrote:
> On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel
> wrote:
> > + * WARNING - if the caller is asking for a header that could occur
> > + * multiple times than they MUST first call this function with a
> > + * a value of NULL for header_desi
On Wed, 14 Apr 2010 12:50:50 -0500, Jesse Rosenthal wrote:
> It occurs to me that the best way to do this would probably be to go to
> point-max, and then (forward-line -1) until we hit a thread-id. That way
> we wouldn't have to work all the way down long search indexes. I'll try
> to code that u
On Wed, 14 Apr 2010 11:01:58 -0700, Carl Worth wrote:
> > +printf "Checking for Mac OS X (for shared library)... "
> > +if [ `uname` = "Darwin" ] ; then
> > +printf "Yes.\n"
> > +mac_os_x=1
> > +else
> > +printf "No.\n"
> > +mac_os_x=0
> > +fi
> > +
>
> Instead of inventing a new
On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit wrote:
> The test suite doesn't yet cover --format=json output nor UTF-8 in
> subject or body.
>
> This patch starts with test cases for 'search --format=json' and
> 'show --format=json'.
Thanks for the tests, Gregor!
I was about to push this,
On Tue, 13 Apr 2010 16:36:30 +0100, James Westby
wrote:
> Your choice. I prefer putting them in the same commit to be more
> self-documenting, and then using the capabilities of my VCS to verify
> the change if i desire.
But that's my point. With it split, I can actually use "git checkout" to
go
On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard wrote:
> On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson
> wrote:
> >
> > I think that '*' is definitely an awesome command, but I wonder if we
> > shouldn't have another command for the notmuch-search buffer which means
> > 'tag all the thre
62 matches
Mail list logo