[PATCH 3/4] test/emacs-tree: add known broken test for subject with CR/NL

-tree.sh +++ b/test/T460-emacs-tree.sh @@ -222,6 +222,15 @@ test_emacs '(let ((notmuch-tree-outline-enabled t)) # folding all messages by height or depth should look the same test_expect_equal_file $EXPECTED/notmuch-tree-tag-inbox OUTPUT +test_begin_subtest "notmuch-tree for message with su

Re: Carriage returns in subject line cause problems in unthreaded and tree mode

On Thu, May 16 2024, Richard Stanton wrote: > Today I received an email with (raw) subject line > > Subject: =?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your > =?UTF-8?Q?workout=0D=0A?= > > When displayed in Emacs in either unthreaded or tree mode, “^M” appears after &

Carriage returns in subject line cause problems in unthreaded and tree mode

Today I received an email with (raw) subject line Subject: =?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your =?UTF-8?Q?workout=0D=0A?= When displayed in Emacs in either unthreaded or tree mode, “^M” appears after the word “workout”, and the displayed line is split into two, like this: Today 07

[PATCH 6/6] WIP/tests: (count ...) tests for subject

less than 4 times" output=$(notmuch count --output=messages --query=sexp '(tag (count * 3))') test_expect_equal "${output}" "0" +test_begin_subtest "subjects with unique words" +notmuch search --query=sexp '(and (from gusarov) (subject (count 1)))' | notmuch

Re: [PATCH] test: add regression test for Subject with newline.

David Bremner writes: > David Bremner writes: > >> This tests the issue reported by Thibault in id:87wn9w4xus@thb.lt >> --- >> >> I could not duplicate the problem here. Maybe it depends on the version of >> gmime? >> I have 3.2.9 here. > > Now that I have gmime 3.2.13 I can confirm your

Re: [Bug] Notmuch Emacs Message Subject Can Be Truncated

Bogdan Ruslanovich Drozd writes: > In `notmuch-message-mode' subject can be truncated. > > How to reproduce: > > 1. Send an email message to yourself with the subject “test abcdf fdcba >12345 54321 qwerty ytrewq 09876 67890 =- -= zxcv vcxz m,./ /.,m asdf >f

[Bug] Notmuch Emacs Message Subject Can Be Truncated

In `notmuch-message-mode' subject can be truncated. How to reproduce: 1. Send an email message to yourself with the subject “test abcdf fdcba 12345 54321 qwerty ytrewq 09876 67890 =- -= zxcv vcxz m,./ /.,m asdf fdsa ';lk kl;' qaz zaq ]'/ /'] йцукен некуцй ъхзщш шщзхъ” via Emacs notmuch

Re: bug: subject line with several chunks of base64

Emmanuel Beffara writes: > Hello, > > I am stumbling upon what looks to be a bug. > > Sometimes I receive messages where a header entry consists of several chunks > of base64-encoded quoted utf-8 text. For instance: > >

bug: subject line with several chunks of base64

Hello, I am stumbling upon what looks to be a bug. Sometimes I receive messages where a header entry consists of several chunks of base64-encoded quoted utf-8 text. For instance: Subject: =?UTF-8?B?dGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUgZm9yIGRlbW9uc3RyYXRpb24gcHVycA==?= =?UTF-8?B?b3Nlcw

Re: Possible bug: incorrect processing of multipart, base64-encoded subject lines.

* Thibault Polge , 2022-09-21 16:15: Subject: =?UTF-8?B?TGl2cmFpc29uIHByw6l2dWUgcG91ciBhdWpvdXJk4oCZaHU=?= =?UTF-8?B?aTogUkVTVFJBUCBTYWRkbGUgQmFnIFNhY2NvY2hlLi4u?= Notmuch displays the subject as only the decoded contents of the first fragment I believe this is now fixed in GMime upstream

Re: [PATCH] test: add regression test for Subject with newline.

me.init() msg = b'''\ Subject: =?UTF-8?B?SGVsbG8=?= =?UTF-8?B?IHdvcmxk?= . ''' with tempfile.NamedTemporaryFile() as tmpfile: tmpfile.write(msg) tmpfile.flush() fp = GMime.StreamFile.open(tmpfile.name, 'r') parser = GMime.Parser.new_with_stream(fp) msg = parser.construct_mes

[PATCH] test: add regression test for Subject with newline.

This tests the issue reported by Thibault in id:87wn9w4xus@thb.lt --- I could not duplicate the problem here. Maybe it depends on the version of gmime? I have 3.2.9 here. test/T050-new.sh | 4 test/corpora/indexing/subject-newline:2, | 10 ++ 2 files

Re: [PATCH] nmweb: escape subject in search view

David Bremner writes: > Fix a bug reported by Jakub Wilk [1]. > > [1]: id:20220822064717.qftn4tr7cs4r2...@jwilk.net applied to master d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org

Possible bug: incorrect processing of multipart, base64-encoded subject lines.

Hi all, Notmuch doesn't parse correctly some Subject lines consisting of multiple base64-encoded snippets. As an example, this is the raw subject line of an e-mail from Amazon: Subject: =?UTF-8?B?TGl2cmFpc29uIHByw6l2dWUgcG91ciBhdWpvdXJk4oCZaHU=?= =?UTF-8?B

Re: [PATCH] nmweb: escape subject in search view

uch-web/nmweb.py > index 928e4863..7b555c62 100755 > --- a/devel/notmuch-web/nmweb.py > +++ b/devel/notmuch-web/nmweb.py > @@ -131,7 +131,7 @@ env.globals['mailto_addrs'] = mailto_addrs > def link_msg(msg): >lnk = quote_plus(msg.messageid.encode('utf8')) >try: > -subj =

[PATCH] nmweb: escape subject in search view

-web/nmweb.py +++ b/devel/notmuch-web/nmweb.py @@ -131,7 +131,7 @@ env.globals['mailto_addrs'] = mailto_addrs def link_msg(msg): lnk = quote_plus(msg.messageid.encode('utf8')) try: -subj = msg.header('Subject') +subj = html.escape(msg.header('Subject')) except LookupError: subj

[no subject]

This series is against branch "next", which is currently ahead of master by the following 7 commits 9c1ed5ab CLI: document handling of --config for external commands 0d33392f CLI: pass --config to external commands via NOTMUCH_CONFIG. 163dae81 test: initial tests for external commands a5a3ed90

Re: [PATCH 1/2] test: known broken tests for bracketed terms in subject

Hello, On Sat 19 Mar 2022 at 07:38am -03, David Bremner wrote: > David Bremner writes: > >> The heuristics in the field processor currently incorrectly trigger >> phrase parsing. > > I have applied this series to master Nice, thanks! -- Sean Whitton

Re: [PATCH 1/2] test: known broken tests for bracketed terms in subject

David Bremner writes: > The heuristics in the field processor currently incorrectly trigger > phrase parsing. I have applied this series to master d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to

[PATCH 1/2] test: known broken tests for bracketed terms in subject

-query.sh +++ b/test/T650-regexp-query.sh @@ -65,6 +65,24 @@ thread:XXX 2001-01-05 [1/1] Notmuch Test Suite; - (inbox unread) EOF test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest "bracketed subject search (with dquotes)" +test_subtest_known_broken +notmuch search subje

[no subject]

Floris wrote: > FWIW having spaces between the function name and parentheses is rather >uncommon for python style. Though of course complaining about style >without using an auto-formatter is pretty meh these days :) > Yeah fair enough, it's the default in the C code, but we pretty clearly have

Re: Variable used to detect reply prefixes in Subject

Jonas Bernoulli writes: > Hello, > > Please tell me what variable I have to customize to recognize additional > unusual prefixes that some people add to the subject when they send a > reply. > > I searched using some strings I would expect to appear in the value of > that

Re: Variable used to detect reply prefixes in Subject

* 2022-01-23 15:13:18+0100, Jonas Bernoulli wrote: > Please tell me what variable I have to customize to recognize > additional unusual prefixes that some people add to the subject when > they send a reply. There is message-subject-re-regexp. > Ps: Since (I assume) many notmuc

Variable used to detect reply prefixes in Subject

Hello, Please tell me what variable I have to customize to recognize additional unusual prefixes that some people add to the subject when they send a reply. I searched using some strings I would expect to appear in the value of that variable but either got no results or way too many

Re: Provide an option to make thread summaries keep initial subject

Thomas Schwinge writes: > Hi! > > Regarding the following ideas -- from almost a decade ago ;-) -- is > anyone aware of any work in that area? [snip] > Austin wrote: >> I think this would be fantastic. I've proposed unconditionally >> showing the earliest

Re: Provide an option to make thread summaries keep initial subject

Hi! Regarding the following ideas -- from almost a decade ago ;-) -- is anyone aware of any work in that area? On 2012-09-25T15:31:37-0400, Austin Clements wrote: > Quoth Olivier Berger on Sep 25 at 6:03 pm: >> Whenever a participant changes the subject in the middle of

[no subject]

I was curious if anybody had any ideas of how to add unread messages along with total messages to the hello view for each saved search? I am aware of the count-query parameter to the notmuch-saved-searches call that shows a count based on a search term. However when all messages are read the

[PATCH 11/36] lib/parse-sexp: support subject field

called *prefixes* in notmuch documentation) +correspond to attributes of mail messages. Some are inherent (and +immutable) like ``subject``, while others ``tag`` and ``property`` are +settable by the user. Each concrete field in +:any:`the table below ` +is discussed further under "Search pre

[PATCH 10/31] lib/parse-sexp: support subject field

called *prefixes* in notmuch documentation) +correspond to attributes of mail messages. Some are inherent (and +immutable) like ``subject``, while others ``tag`` and ``property`` are +settable by the user. Each concrete field in +:any:`the table below ` +is discussed further under "Search pre

[PATCH 10/27] lib/parse-sexp: support subject field

* in notmuch documentation) +correspond to attributes of mail messages. Some are inherent (and +immutable) like ``subject``, while others ``tag`` and ``property`` are +settable by the user. Each concrete field in +:any:`the table below ` +is discussed further under "Search prefixes" in +:an

[PATCH 07/25] lib/parse-sexp: parse 'subject'

_sexp_field_t fields[] = +{ +{ "subject",Xapian::Query::OP_PHRASE }, +{ } +}; + static notmuch_status_t _sexp_to_xapian_query (notmuch_database_t *notmuch, const sexp_t *sx, Xapian::Query ); @@ -6

[PATCH 06/11] lib/parse-sexp: parse 'subject'

_sexp_field_t fields[] = +{ +{ "subject",Xapian::Query::OP_PHRASE }, +{ } +}; + static Xapian::Query _sexp_to_xapian_query (sexp_t *sx); static Xapian::Query @@ -46,6 +57,26 @@ _notmuch_sexp_string_to_xapian_query (notmuch_database_t *notmuch, const char *q

[PATCH 5/8] test: add regression tests for n_t_get_{authors, subject}

+authors = notmuch_thread_get_authors (thread); +printf("%d\n%s\n", thread != NULL, authors); +} +EOF +cat < EXPECTED +== stdout == +1 +Lars Kellogg-Stedman, Mikhail Gusarov, Keith Packard, Carl Worth +== stderr == +EOF +test_expect_equal_file EXPECTED OUTPUT + +test_be

[no subject]

Here's a not too ambitious attempt to clean up the error handling on zlib output. It's bit gross to treat any error reported by zlib as fatal, but it's a step up from ignoring them, and it's in the client code, not in the library. The first patch splits out the first fix of

Re: [PATCH 1/3] test: add known broken tests for from: and subject:

:b@c >> OUTPUT > +notmuch count $1:a@b $1:b@c >> OUTPUT > +cat < EXPECTED > +1 > +1 > +2 > +0 > +EOF the above could be done printf %s\\n 1 1 2 0 > EXPECTED (whichever way is "clearer" -- using '%s\n' or even "%

[PATCH 1/3] test: add known broken tests for from: and subject:

nt $1:a@b > OUTPUT +notmuch count $1:a $1:b >> OUTPUT +notmuch count $1:a@b OR $1:b@c >> OUTPUT +notmuch count $1:a@b $1:b@c >> OUTPUT +cat < EXPECTED +1 +1 +2 +0 +EOF +test_expect_equal_file EXPECTED OUTPUT +} + +test_AND from test_subtest_known_broken +test

[PATCH v4 10/17] indexing: record protected subject when indexing cleartext

When indexing the cleartext of an encrypted message, record any protected subject in the database, which should make it findable and visible in search. Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 42 ++ lib/message.cc

Re: [PATCH v3 10/17] indexing: record protected subject when indexing cleartext

On Mon 2019-05-27 17:17:20 -0400, Daniel Kahn Gillmor wrote: > When indexing the cleartext of an encrypted message, record any > protected subject in the database, which should make it findable and > visible in search. ugh, please ignore v3 of this patch (10/17) as well. v4 should

_notmuch_database_log vs _notmuch_database_log_append [was: Re: [PATCH v2 10/17] indexing: record protected subject when indexing cleartext]

On Mon 2019-05-27 07:24:41 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> +status = _notmuch_message_crypto_potential_payload (msg_crypto, clear, >> GMIME_OBJECT (encrypted_data), GMIME_MULTIPART_ENCRYPTED_CONTENT); >> +_index_mime_part (message, indexopts, clear,

[PATCH v3 10/17] indexing: record protected subject when indexing cleartext

When indexing the cleartext of an encrypted message, record any protected subject in the database, which should make it findable and visible in search. Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 46 +++--- lib/message.cc

Re: [PATCH v2 10/17] indexing: record protected subject when indexing cleartext

Daniel Kahn Gillmor writes: > +status = _notmuch_message_crypto_potential_payload (msg_crypto, clear, > GMIME_OBJECT (encrypted_data), GMIME_MULTIPART_ENCRYPTED_CONTENT); > +_index_mime_part (message, indexopts, clear, msg_crypto); > g_object_unref (clear); If you're going to

[PATCH v2 17/17] cli/reply: pull proposed subject line from the message, not the index

Protected subject lines were being emitted in reply when the cleartext of documents was indexed. create_reply_message() was pulling the subject line from the index, rather than pulling it from the GMimeMessage object that it already has on hand. This one-line fix to notmuch-reply.c solves

[PATCH v2 07/17] test: add test for missing external subject

Adding another test to ensure that we handle protected headers gracefully when no external subject is present. Signed-off-by: Daniel Kahn Gillmor --- test/T356-protected-headers.sh| 6 .../subjectless-protected-header.eml | 29 +++ 2 files changed

[PATCH v2 10/17] indexing: record protected subject when indexing cleartext

When indexing the cleartext of an encrypted message, record any protected subject in the database, which should make it findable and visible in search. Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 42 ++ lib/message.cc

[PATCH v2 05/17] cli/show: emit payload subject instead of outside subject

Correctly fix the two outstanding tests so that the protected (hidden) subject is properly reported. Signed-off-by: Daniel Kahn Gillmor --- notmuch-client.h | 2 +- notmuch-reply.c| 4 +++- notmuch-show.c | 14 +- test/T356-protected

Re: [PATCH 11/20] cli/show: emit payload subject instead of outside subject

On Thu 2018-06-28 21:40:04 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> >> sp->map_key (sp, "Subject"); >> -sp->string (sp, g_mime_message_get_subject (message)); >> +if (msg_crypto && msg_crypto-

[no subject]

Thanks to Gregor for the test data. I can now duplicate the problem with a regression test using (small) synthetic data. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 17/20] cli/reply: add --protected-subject boolean flag

Daniel Kahn Gillmor writes: > This flag indicates the intent of the client to protect the subject > line, which allows "notmuch reply" to safely emit the earlier > message's encrypted subject without risking leaking it in the clear in > the reply. > > Obvio

Re: [PATCH 11/20] cli/show: emit payload subject instead of outside subject

Daniel Kahn Gillmor writes: > > sp->map_key (sp, "Subject"); > -sp->string (sp, g_mime_message_get_subject (message)); > +if (msg_crypto && msg_crypto->payload_subject) { > + sp->string (sp, msg_crypto->payloa

Re: [PATCH 18/20] indexing: record protected subject when indexing cleartext

On Fri, May 11 2018, Daniel Kahn Gillmor wrote: > When indexing the cleartext of an encrypted message, record any > protected subject in the database, which should make it findable and > visible in search. > --- > lib/index.cc | 42 ++

[PATCH 15/20] cli/reply: ensure encrypted Subject: line does not leak in the clear

Now that we can decrypt headers, we want to make sure that clients using "notmuch reply" to prepare a reply don't leak cleartext in their subject lines. In particular, the ["reply-headers"]["Subject"] should by default show the external Subject. --- test/T356-prote

[PATCH 17/20] cli/reply: add --protected-subject boolean flag

This flag indicates the intent of the client to protect the subject line, which allows "notmuch reply" to safely emit the earlier message's encrypted subject without risking leaking it in the clear in the reply. Obviously, it should only be used by a client that *will* protect the su

[PATCH 18/20] indexing: record protected subject when indexing cleartext

When indexing the cleartext of an encrypted message, record any protected subject in the database, which should make it findable and visible in search. --- lib/index.cc | 42 ++ lib/message.cc | 8 +++ lib/notmuch-private.h

[PATCH 13/20] test: add test for missing external subject

Adding another test to ensure that we handle it gracefully when no external subject is present. --- test/T356-protected-headers.sh| 6 .../subjectless-protected-header.eml | 29 +++ 2 files changed, 35 insertions(+) create mode 100644 test/corpora

[PATCH 11/20] cli/show: emit payload subject instead of outside subject

Correctly fix the two outstanding tests so that the protected (hidden) subject is properly reported. --- notmuch-client.h | 2 +- notmuch-reply.c| 4 +++- notmuch-show.c | 11 +++ test/T356-protected-headers.sh | 3 --- 4 files changed, 11

Re: [PATCH] test: add known broken test for regexp search of second subject

David Bremner <da...@tethera.net> writes: > We expect this to give the same answer as the non-regexp subject > search. It does not because the regexp search relies on the value > slot, which currently contains only one subject. Pushed to master. I still need to revi

wish: notmuch-emacs: wash From: / To: and Subject: in notmuch search / show

Dear notmuch-emacs developers, it would be nice if there was a facility to wash (= shorten) the displayed To:, From: and Subject headers at least for the display of notmuch search results. >From the users perspective this could be done via a list of regular expressions with corresponding sh

[no subject]

From: Matthew Lear <m...@bubblegen.co.uk> To: notmuch@notmuchmail.org Cc: Matthew Lear <m...@bubblegen.co.uk> Subject: [PATCH] Update date search syntax. Date: Thu, 1 Feb 2018 20:52:18 + Message-Id: <20180201205218.4368-1-m...@bubblegen.co.uk> X-Mailer: git-send-email 2.

[PATCH] test: add known broken test for regexp search of second subject

We expect this to give the same answer as the non-regexp subject search. It does not because the regexp search relies on the value slot, which currently contains only one subject. --- test/T670-duplicate-mid.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/test/T670-duplicate

Re: [PATCH 0/6] Sort by from and subject

is this something we want to have? Is this generally useful? >> >> Sorting by from and subject are in most mail clients (mutt, gnus, outlook...) > > Which of those display results as threads, and of those that do, how do > they sort the threads? In the notmuch case, the

Re: [PATCH 0/6] Sort by from and subject

On Sat, 30 Sep 2017, William Casarin <j...@jb55.com> wrote: > Jani Nikula <j...@nikula.org> writes: > >> I think there are two considerations here: >> >> First, is this something we want to have? Is this generally useful? > > Sorting by from and su

Re: [PATCH 0/6] Sort by from and subject

Hey Jani, Jani Nikula <j...@nikula.org> writes: > I think there are two considerations here: > > First, is this something we want to have? Is this generally useful? Sorting by from and subject are in most mail clients (mutt, gnus, outlook...) > There's still the issue of

Re: [PATCH 0/6] Sort by from and subject

binding. I think there are two considerations here: First, is this something we want to have? Is this generally useful? There's still the issue of From: and Subject: needing more heuristic for useful sorting that I mentioned in id:87efrm70ai@nikula.org. Second, if we decide we want this, IMHO the inte

Re: emacs: reply subject sanitization

Jani Nikula writes: > v2 of id:20170915155716.19597-1-j...@nikula.org, now with test. > > BR, > Jani. pushed. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: emacs: reply subject sanitization

On Tuesday, 2017-09-26 at 21:26:06 +0300, Jani Nikula wrote: > v2 of id:20170915155716.19597-1-j...@nikula.org, now with test. Looks good. dme. -- I can't explain, you would not understand. This is not how I am. ___ notmuch mailing list

[PATCH 2/2] emacs: sanitize subject in replies

8,7 +218,7 @@ mutiple parts get a header." else collect pair))) (notmuch-mua-mail (plist-get reply-headers :To) - (plist-get reply-headers :Subject) + (notmuch-sanitize (plist-get reply-he

emacs: reply subject sanitization

v2 of id:20170915155716.19597-1-j...@nikula.org, now with test. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 0/6] Sort by from and subject

This patch series replaces my original set[1]. I've been using this extensivly for about 3 weeks now and I'm pretty happy with it. I've added the ability to change sort-order on the fly with the O key binding. Main use cases -- * subject sorting: github subscriptions Sorting through

[PATCH 1/6] sorting: add the ability to sort by from and subject

* add {from,subject}-{ascending,descending} sort options --- lib/notmuch.h| 16 lib/query.cc | 12 notmuch-search.c | 4 3 files changed, 32 insertions(+) diff --git a/lib/notmuch.h b/lib/notmuch.h index f26565f3..071bfe4d 100644 --- a/lib/notmuch.h

[PATCH 2/6] sorting: update ruby bindings for from and subject

OTMUCH_SORT_FROM_ASC)); +/* + * Document-const: Notmuch::SORT_FROM_DESC + * + * Sort query results by from in descending order + */ +rb_define_const (mod, "SORT_FROM_DESC", INT2FIX (NOTMUCH_SORT_FROM_DESC)); +/* + * Document-const: Notmuch::SORT_SUBJECT_ASC + * + *

[PATCH] emacs: sanitize subject in replies

t a header." else collect pair))) (notmuch-mua-mail (plist-get reply-headers :To) - (plist-get reply-headers :Subject) + (notmuch-sanitize (plist-get reply-headers :Subject))

Re: [PATCH 1/3] sorting: add the ability to sort by from and subject

David Bremner writes: > It seems worth mentioning that it's possible to preprocess values into > keys (see Xapian::Enquire::set_sort_by_key). So things like Re: > etc... could be stripped. Hmm looks like I need to create a KeyMaker class which appears to be a glorified

Re: [PATCH 1/3] sorting: add the ability to sort by from and subject

sent to my inbox, I wanted to be able to group >> similar feeds (mainly by from, sometimes subject). Alternatively if >> there was a way to group by tags I could do it that way, but I don't tag >> all of my individual feeds. >> >> If this is too obscure of a use case

Re: [PATCH 1/3] sorting: add the ability to sort by from and subject

William Casarin <j...@jb55.com> writes: > Jani Nikula <j...@nikula.org> writes: > >> The implementation seems simple enough, but what's the use case, really? > > I get all of my rss feeds sent to my inbox, I wanted to be able to group > similar feeds (

Re: [PATCH 1/3] sorting: add the ability to sort by from and subject

On Mon, 04 Sep 2017, William Casarin <j...@jb55.com> wrote: > * add {from,subject}-{ascending,descending} sort options The implementation seems simple enough, but what's the use case, really? When thinking about the usefulness of the feature, you have to think about what gets indexed

[PATCH 2/3] sorting: update ruby bindings for from and subject

OTMUCH_SORT_FROM_ASC)); +/* + * Document-const: Notmuch::SORT_FROM_DESC + * + * Sort query results by from in descending order + */ +rb_define_const (mod, "SORT_FROM_DESC", INT2FIX (NOTMUCH_SORT_FROM_DESC)); +/* + * Document-const: Notmuch::SORT_SUBJECT_ASC + * + *

[PATCH 1/3] sorting: add the ability to sort by from and subject

* add {from,subject}-{ascending,descending} sort options --- I'm not sure if we want to eventually refactor ascending and descending into a separate option, but I decided to keep it this way for now. lib/notmuch.h| 16 lib/query.cc | 12 notmuch-search.c

Re: notmuch-search: sort by subject or author?

David Bremner <da...@tethera.net> writes: > I think it's not really possible at the moment. If you want this to work > with large searches then it probably needs to be done at the CLI level > (see [1] for work in progress adding sorting by file size). > > Luckily 'From' and

Re: notmuch-search: sort by subject or author?

William Casarin <j...@jb55.com> writes: > Hey there, > > Is there a way to sort by subject or author in emacs/notmuch-search? I > find myself wanting to do this a lot. My particular use case is rss > feeds, where I have many different feeds in my rss tag that I would lik

notmuch-search: sort by subject or author?

Hey there, Is there a way to sort by subject or author in emacs/notmuch-search? I find myself wanting to do this a lot. My particular use case is rss feeds, where I have many different feeds in my rss tag that I would like to group together. If not, I am interested in adding this feature

[PATCH 3/5] test: known broken test for subject after reindexing

/test/T670-duplicate-mid.sh @@ -40,6 +40,14 @@ notmuch reindex '*' notmuch search --output=files "sekrit" | notmuch_dir_sanitize > OUTPUT test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest 'reindex choses subject from first filename' +test_subtest_known_broken +cat < EXPE

[PATCH 5/5] test/duplicate-mid: check for subject with notmuch-show

ile EXPECTED OUTPUT +test_begin_subtest 'First subject preserved in notmuch-show (json)' +test_subtest_known_broken +output=$(notmuch show --body=false --format=json id:duplicate | notmuch_json_show_sanitize) +expected='[[[{ +"id": "X", +"match": true, +

[PATCH] test: check for subject consistency between search and show

> OUTPUT test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest 'First subject preserved in notmuch-show (json)' +output=$(notmuch show --body=false --format=json id:duplicate | notmuch_json_show_sanitize) +expected='[[[{ +"id": "X", +"match&qu

[no subject]

This is the first allegedly complete version of support for gmime 3 It obsoletes several partial series [1][2] - id:20170602022232.17264-1-da...@tethera.net - patches 9-11, starting at id:20170527165121.9654-10-da...@tethera.net There still remains the question of whether we should

[no subject]

for future reference if need for atexit functionality arises. From Tomi Ollila <tomi.oll...@iki.fi> # This line is ignored. From: Tomi Ollila <tomi.oll...@iki.fi> Subject: stop gpg-agent (among other) processes at test module exit In-Reply-To: ___

Re: [PATCH 3/4] test: add known broken tests wildcard search in from and subject

David Bremner writes: > This was broken by the addition of regexp searching. The detection of > wildcards is not currently done in the recursive call to parse_query, > because of quoting issues. Patches 3 and 4 pushed to release and master. d

[PATCH 1/2] test: add known broken test for null from: and subject: query

--- a/test/T650-regexp-query.sh +++ b/test/T650-regexp-query.sh @@ -11,6 +11,26 @@ fi notmuch search --output=messages from:cworth > cworth.msg-ids +# these headers will generate no document terms +add_message '[from]="-" [subject]="empty from"' +add_message '[subject]=&qu

[PATCH 1/4] test: add known broken test for empty from: and subject: query

UT +test_expect_equal_file cworth.msg-ids OUTPUT + +test_begin_subtest "empty subject: search" +test_subtest_known_broken +notmuch search --output=messages 'subject:""' and from:cworth > OUTPUT +test_expect_equal_file cworth.msg-ids OUTPUT test_begin_subtest "regexp

[PATCH 3/4] test: add known broken tests wildcard search in from and subject

/T650-regexp-query.sh index 049477b4..ba4a64e0 100755 --- a/test/T650-regexp-query.sh +++ b/test/T650-regexp-query.sh @@ -18,6 +18,16 @@ test_expect_equal_file cworth.msg-ids OUTPUT test_begin_subtest "empty subject: search" notmuch search --output=messages 'subject:""' and

[PATCH] fixup! lib: regexp matching in 'subject' and 'from'

--- lib/regexp-fields.cc | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/regexp-fields.cc b/lib/regexp-fields.cc index b2b39504..65108e38 100644 --- a/lib/regexp-fields.cc +++ b/lib/regexp-fields.cc @@ -62,6 +62,11 @@ RegexpPostingSource::init (const Xapian::Database ) it_ =

[PATCH 2/4] lib: regexp matching in 'subject' and 'from'

the idea is that you can run % notmuch search subject:// % notmuch search from:// or % notmuch search subject:"your usual phrase search" % notmuch search from:"usual phrase search" This feature is only available with recent Xapian, specifically support for field

Re: [patch v5 4/6] lib: regexp matching in 'subject' and 'from'

On Thu, 16 Feb 2017, David Bremner <da...@tethera.net> wrote: > the idea is that you can run > > % notmuch search subject:// > % notmuch search from:// > > or > > % notmuch search subject:"your usual phrase search" > % notmuch search from:"usual p

[patch v5 4/6] lib: regexp matching in 'subject' and 'from'

the idea is that you can run % notmuch search subject:// % notmuch search from:// or % notmuch search subject:"your usual phrase search" % notmuch search from:"usual phrase search" This feature is only available with recent Xapian, specifically support for field

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

Mark Walters <markwalters1...@gmail.com> writes: > > Hi > > Broadly I like the backslash escaping option. Two thoughts: can any > fields (from/subject/message-id) start with a "\" anyway? I think not > but thought it worth checking. From and subject are probabli

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

done, > although I'm a bit uneasy about how this makes the syntax for id: > different, so id:/foo would be legit, but from:/foo would be an error. > Maybe the dwim-factor is worth it. Hi Broadly I like the backslash escaping option. Two thoughts: can any fields (from/subject/message-id) sta

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

On Thu, Feb 09 2017, David Bremner wrote: > Jani Nikula writes: > >> >> Theoretically "/" is an acceptable character in message-ids [1]. Rare, >> unlikely, but acceptable. Searching for message-id's beginning with "/" >> would have to use regexps, which would

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

Jani Nikula writes: > > Theoretically "/" is an acceptable character in message-ids [1]. Rare, > unlikely, but acceptable. Searching for message-id's beginning with "/" > would have to use regexps, which would break in all sorts of ways > throughout the stack. I don't think

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

; users get used to it, and try to tighten the rules if we realize we'd >> need that for some reason. > > I agree -- should we allow trailing slash ('/') without first char also > being '/' (e.g. subject:blah/) > I'd say that should also be an error. it doesn't add anything useful to

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

required for this feature -- and emphasize it a bit better in >>> manual page ? >>> >>> Probably '//' is used to escape '/' -- should such a character ever needed >>> in regex search. >>> >> >> Currently no escaping is needed because it only

Re: [Patch v4] lib: regexp matching in 'subject' and 'from'

t; in regex search. >> > > Currently no escaping is needed because it only looks at the first and > last characters of the string (the usual xapian/shell rules mean that "" might > be needed). > > The following seem to work as hoped > > # match a / with a spa

  1   2   3   4   5   >