On Sat, 10 Mar 2012 05:24:49 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
Changes in v2:
* rebase on master
pushed.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Before the change, messages generated by generate_message() used "Test
message #N" for default subject where N is the generated messages
counter. Since message subject is commonly present in expected
results, there is a chance of breaking other tests when a new
generate_message() cal
Hi Dmitry, I tagged this notmuch::stale as it no longer cleanly applies
to master.
BR,
Jani.
On Tue, 31 Jan 2012 02:06:35 +0400, Dmitry Kurochkin wrote:
> Before the change, messages generated by generate_message() used "Test
> message #N" for default subject where N is the ge
Hi Dmitry, I tagged this notmuch::stale as it no longer cleanly applies
to master.
BR,
Jani.
On Tue, 31 Jan 2012 02:06:35 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
Before the change, messages generated by generate_message() used Test
message #N for default subject where N
Changes in v2:
* rebase on master
Regards,
Dmitry
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Before the change, messages generated by generate_message() used Test
message #N for default subject where N is the generated messages
counter. Since message subject is commonly present in expected
results, there is a chance of breaking other tests when a new
generate_message() call is added
Probably both of these patches could use some polishing; Austin asked
for a test to help debug the crash I found today.
Probably both of these patches could use some polishing; Austin asked
for a test to help debug the crash I found today.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
I would like to thread some mails by subject, can I do this: get to the data
and forge threads between messages that don't otherwise have any References or
In-Reply-To:s?
Basically I want to make mails with "Subject: XYZZY Re: foobar" replies to
those without "Re:".
s(+), 15 deletions(-)
Jameson and Antoine have asked for this patch to be reverted. As far as
I understand it the printing code actually crashes on blank subjects if
this patch is removed, so it seems to me that that (slightly) outweighs
the annoyance caused by printing [No Subject]. I don't
I would like to thread some mails by subject, can I do this: get to the data
and forge threads between messages that don't otherwise have any References or
In-Reply-To:s?
Basically I want to make mails with Subject: XYZZY Re: foobar replies to
those without Re
deletions(-)
Jameson and Antoine have asked for this patch to be reverted. As far as
I understand it the printing code actually crashes on blank subjects if
this patch is removed, so it seems to me that that (slightly) outweighs
the annoyance caused by printing [No Subject]. I don't find the
argument
- Rebased to current master (be851ad3).
- Addressed Dmitry's comments re test for `notmuch-search-operate-all'
(which is now `notmuch-search-tag-all') [1,2,3].
- Dropped patches 5 and 6 [5,6]. Might be dealt with later.
Peace
[1] id:"87y5spober.fsf at gmail.com"
[2] id:"87hazamywi.fsf at
- Rebased to current master (be851ad3).
- Addressed Dmitry's comments re test for `notmuch-search-operate-all'
(which is now `notmuch-search-tag-all') [1,2,3].
- Dropped patches 5 and 6 [5,6]. Might be dealt with later.
Peace
[1] id:87y5spober@gmail.com
[2] id:87hazamywi@gmail.com
On Mon, 06 Feb 2012 11:19:46 -0800, Jameson Graef Rollins wrote:
> On Mon, 06 Feb 2012 08:56:34 +, David Edmondson wrote:
> > With blank subjects the printing code generated an error (because
> > `rename-buffer' doesn't like an empty string as the first argument), so
> > _some_ change is
On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins wrote:
> Sorry to be so late on this, but I'm not a big fan of this new feature.
> I would prefer to always see the subject (or any other field for that
> matter) as is.
I agree. as a native french speaker, for example, it's
On Mon, 06 Feb 2012 08:56:34 +, David Edmondson wrote:
> With blank subjects the printing code generated an error (because
> `rename-buffer' doesn't like an empty string as the first argument), so
> _some_ change is required.
This sounds like something that could easily be fixed in the
fan of this new feature.
> > > I would prefer to always see the subject (or any other field for that
> > > matter) as is.
> >
> > The Emacs UI always replaced blank subjects with '[No Subject]' in
> > buffer names. The printing code also needed something other tha
On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins wrote:
> Sorry to be so late on this, but I'm not a big fan of this new feature.
> I would prefer to always see the subject (or any other field for that
> matter) as is.
The Emacs UI always replaced blank subjects with '[N
On Mon, 06 Feb 2012 07:47:38 +, David Edmondson wrote:
> On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins finestructure.net> wrote:
> > Sorry to be so late on this, but I'm not a big fan of this new feature.
> > I would prefer to always see the subject (
On Mon, 06 Feb 2012 07:47:38 +, David Edmondson d...@dme.org wrote:
On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Sorry to be so late on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other
on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other field for that
matter) as is.
The Emacs UI always replaced blank subjects with '[No Subject]' in
buffer names. The printing code also needed something other than a blank
subject for buffer
On Mon, 06 Feb 2012 08:56:34 +, David Edmondson d...@dme.org wrote:
With blank subjects the printing code generated an error (because
`rename-buffer' doesn't like an empty string as the first argument), so
_some_ change is required.
This sounds like something that could easily be fixed in
On Mon, 06 Feb 2012 11:19:46 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Mon, 06 Feb 2012 08:56:34 +, David Edmondson d...@dme.org wrote:
With blank subjects the printing code generated an error (because
`rename-buffer' doesn't like an empty string as the first
On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Sorry to be so late on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other field for that
matter) as is.
I agree. as a native french speaker
Sorry to be so late on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other field for that
matter) as is.
As a principle I would prefer there not be text replacements unless it's
very clear that text has been replaced. Buttons work because it's
Sorry to be so late on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other field for that
matter) as is.
As a principle I would prefer there not be text replacements unless it's
very clear that text has been replaced. Buttons work because it's
On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Sorry to be so late on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other field for that
matter) as is.
The Emacs UI always replaced blank subjects
0 +
> +++ emacs.24.output 2012-02-02 03:55:14.0 +
> @@ -1,8 +1,4 @@
>From: Notmuch Test Suite
> -To: user at example.com
> -Subject: Re: Testing message sent via SMTP
> -In-Reply-To:
> -Fcc: /home/br
:14.0 +
@@ -1,8 +1,4 @@
From: Notmuch Test Suite
-To: user at example.com
-Subject: Re: Testing message sent via SMTP
-In-Reply-To:
-Fcc: /home/bremner/software/upstream/notmuch/test/tmp.emacs/mail/sent
+To:
+Subject
:14.0 +
@@ -1,8 +1,4 @@
From: Notmuch Test Suite test_su...@notmuchmail.org
-To: u...@example.com
-Subject: Re: Testing message sent via SMTP
-In-Reply-To: XXX
-Fcc: /home/bremner/software/upstream/notmuch/test/tmp.emacs/mail/sent
Before the change, messages generated by generate_message() used "Test
message #N" for default subject where N is the generated messages
counter. Since message subject is commonly present in expected
results, there is a chance of breaking other tests when a new
generate_message() cal
On Tue, 24 Jan 2012 16:06:15 -0800, Jameson Graef Rollins wrote:
> Final v3 rework of this patch series:
>
pushed.
d
(interactive)
>(kill-buffer (current-buffer)))
>
> +(defun notmuch-prettify-subject (subject)
> + ;; This function is used by `notmuch-search-process-filter' which
> + ;; requires that we not disrupt its' matching state.
> + (save-match-data
> +(if (and subject
> + (st
..d315f76 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -133,6 +133,15 @@ the user hasn't set this variable with the old or new
value."
(interactive)
(kill-buffer (current-buffer)))
+(defun notmuch-prettify-subject (subject)
+ ;; This function is used by `notmuch-s
Before the change, messages generated by generate_message() used Test
message #N for default subject where N is the generated messages
counter. Since message subject is commonly present in expected
results, there is a chance of breaking other tests when a new
generate_message() call is added
ariable with the old or new
> value."
>(interactive)
>(kill-buffer (current-buffer)))
>
> +(defun notmuch-prettify-subject (subject)
> + (if (and subject
> + (string-match "^[ \t]*$" subject))
> + (setq subject "[No Subject]"
On Fri, 27 Jan 2012 13:31:27 +, Mark Walters
wrote:
> Oh one other question: I think a search result line in the emacs
> interface just has a blank if a thread has no subject. Would it be
> appropriate to change that to [No Subject] too? (I have no preference)
Yes, makes sense. In
Oh one other question: I think a search result line in the emacs
interface just has a blank if a thread has no subject. Would it be
appropriate to change that to [No Subject] too? (I have no preference)
Best wishes
Mark
On Fri, 27 Jan 2012 10:28:56 +, David Edmondson wrote:
> On Fri,
I am very much not a lisp expert but for what it's worth I read/reviewed
the patches and like them with a couple of minor queries that I am happy
to be overruled on
The patch 1/3 seems to set the show buffer line to *[No Subject]* where
it used to be just [No Subject]. (I have no preference: I
On Fri, 27 Jan 2012 10:23:07 +, Mark Walters
wrote:
> I am very much not a lisp expert
Me neither, so please do continue to review stuff.
> The patch 1/3 seems to set the show buffer line to *[No Subject]* where
> it used to be just [No Subject]. (I have no preference: I just wasn
On Fri, 27 Jan 2012 10:23:07 +, Mark Walters m.walt...@qmul.ac.uk wrote:
I am very much not a lisp expert
Me neither, so please do continue to review stuff.
The patch 1/3 seems to set the show buffer line to *[No Subject]* where
it used to be just [No Subject]. (I have no preference: I
I am very much not a lisp expert but for what it's worth I read/reviewed
the patches and like them with a couple of minor queries that I am happy
to be overruled on
The patch 1/3 seems to set the show buffer line to *[No Subject]* where
it used to be just [No Subject]. (I have no preference: I
Oh one other question: I think a search result line in the emacs
interface just has a blank if a thread has no subject. Would it be
appropriate to change that to [No Subject] too? (I have no preference)
Best wishes
Mark
On Fri, 27 Jan 2012 10:28:56 +, David Edmondson d...@dme.org wrote
.
(interactive)
(kill-buffer (current-buffer)))
+(defun notmuch-prettify-subject (subject)
+ (if (and subject
+(string-match ^[ \t]*$ subject))
+ (setq subject [No Subject]))
+ subject)
+
;;
(defun notmuch-common-do-stash (text)
diff --git a/emacs/notmuch-print.el b/emacs
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -130,6 +130,12 @@ the user hasn't set this variable with the old or new
value."
(interactive)
(kill-buffer (current-buffer)))
+(defun notmuch-prettify-subject (subject)
+ (if (and subject
+ (string-match "^[ \t]*
On Wed, 25 Jan 2012 13:08:33 +, David Edmondson wrote:
> ---
> emacs/notmuch-lib.el |5 +
> emacs/notmuch-print.el |8 ++--
> emacs/notmuch-show.el |5 -
> emacs/notmuch.el |5 +
> 4 files changed, 16 insertions(+), 7 deletions(-)
Don't apply this
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -130,6 +130,11 @@ the user hasn't set this variable with the old or new
value."
(interactive)
(kill-buffer (current-buffer)))
+(defun notmuch-prettify-subject (subject)
+ (if (string-match "^[ \t]*$" subject)
+
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -130,6 +130,12 @@ the user hasn't set this variable with the old or new
value.
(interactive)
(kill-buffer (current-buffer)))
+(defun notmuch-prettify-subject (subject)
+ (if (and subject
+ (string-match ^[ \t]*$ subject
Final v3 rework of this patch series:
* reworked pop-at-end patch to be much simpler (which also happens to
get around other issues with this patch that dme had)
* added pop-at-end function to both show-next-...message functions
* fixed call to search-next-thread in show-next-thread function
*
Final v3 rework of this patch series:
* reworked pop-at-end patch to be much simpler (which also happens to
get around other issues with this patch that dme had)
* added pop-at-end function to both show-next-...message functions
* fixed call to search-next-thread in show-next-thread function
*
After a little fine-tuning, and some consensus about brace style on
the list, I think this is getting pretty useful. I attach a demo
uncrustification, where IMHO the output is mostly good. Note that it
catches some style mistakes in quite recent changes.
One thing I wondered about where to put
After a little fine-tuning, and some consensus about brace style on
the list, I think this is getting pretty useful. I attach a demo
uncrustification, where IMHO the output is mostly good. Note that it
catches some style mistakes in quite recent changes.
One thing I wondered about where to put
On Tue, 27 Dec 2011 18:04:37 +0200, Jani Nikula wrote:
> Hi all, v3 with the following changes:
>
> * new patch 1/3 to add fake parts through a special handler to make them stand
> out from real MIME parts
>
Pushed.
d
On Tue, 27 Dec 2011 18:04:37 +0200, Jani Nikula j...@nikula.org wrote:
Hi all, v3 with the following changes:
* new patch 1/3 to add fake parts through a special handler to make them stand
out from real MIME parts
Pushed.
d
___
notmuch mailing
Signed-off-by: Jani Nikula
---
test/emacs-subject-to-filename | 138
test/notmuch-test |1 +
2 files changed, 139 insertions(+), 0 deletions(-)
create mode 100755 test/emacs-subject-to-filename
diff --git a/test/emacs-subject
Use the mail subject line for creating a descriptive filename for the wash
generated inline patch fake parts. The names are similar to the ones
created by 'git format-patch'.
If the user has notmuch-wash-convert-inline-patch-to-part hook enabled in
notmuch-show-insert-text/plain-hook
Hi all, v3 with the following changes:
* new patch 1/3 to add fake parts through a special handler to make them stand
out from real MIME parts
* make notmuch-wash-subject-to-patch-filename more lispy as suggested by David
in id:"cun62h3tu51.fsf at hotblack-desiato.hh.sledj.net"
Hi all, v3 with the following changes:
* new patch 1/3 to add fake parts through a special handler to make them stand
out from real MIME parts
* make notmuch-wash-subject-to-patch-filename more lispy as suggested by David
in id:cun62h3tu51@hotblack-desiato.hh.sledj.net
BR,
Jani.
Jani
Signed-off-by: Jani Nikula j...@nikula.org
---
test/emacs-subject-to-filename | 138
test/notmuch-test |1 +
2 files changed, 139 insertions(+), 0 deletions(-)
create mode 100755 test/emacs-subject-to-filename
diff --git a/test/emacs
Use the mail subject line for creating a descriptive filename for the wash
generated inline patch fake parts. The names are similar to the ones
created by 'git format-patch'.
If the user has notmuch-wash-convert-inline-patch-to-part hook enabled in
notmuch-show-insert-text/plain-hook
e patch (as text/x-diff) ]
BR,
Jani.
>From b1847714f7368247fbc5c93767f59d8269eadc1c Mon Sep 17 00:00:00 2001
From: Jani Nikula <j...@nikula.org>
Date: Mon, 26 Dec 2011 23:31:41 +0200
Subject: [PATCH] emacs: add inline patch fake parts through a special handler
Add wash generated inline pa
On Mon, 26 Dec 2011 23:52:23 +0200, Jani Nikula wrote:
> Below is an idea I came up with, utilizing the content-type
> vs. declared-type distinction. I think it's really simple and neat,
> but I hope not too magical.
>
> Picking up an example mail from the list, inline patches would show up
>
On Mon, 26 Dec 2011 12:06:02 +, David Edmondson wrote:
> On Mon, 26 Dec 2011 00:00:05 +0200, Jani Nikula wrote:
> > +(defun notmuch-wash-subject-to-patch-filename (subject)
> > + "Convert a patch mail SUBJECT into a filename.
> > +
> > +The resulting
On Mon, 26 Dec 2011 00:00:05 +0200, Jani Nikula wrote:
> +(defun notmuch-wash-subject-to-patch-filename (subject)
> + "Convert a patch mail SUBJECT into a filename.
> +
> +The resulting filename is similar to the names generated by \"git
> +format-patch\". I
Signed-off-by: Jani Nikula
---
test/emacs-subject-to-filename | 138
test/notmuch-test |1 +
2 files changed, 139 insertions(+), 0 deletions(-)
create mode 100755 test/emacs-subject-to-filename
diff --git a/test/emacs-subject
Use the mail subject line for creating a descriptive filename for the wash
generated inline patch fake parts. The names are similar to the ones
created by 'git format-patch'.
If the user has notmuch-wash-convert-inline-patch-to-part hook enabled in
notmuch-show-insert-text/plain-hook
: create patch filename from subject for inline patch fake parts
test: emacs: test notmuch-wash-subject-to-* functions
emacs/notmuch-wash.el | 43 -
test/emacs-subject-to-filename | 138
test/notmuch-test |1 +
3 files
On Mon, 26 Dec 2011 14:24:42 +0200, Jani Nikula j...@nikula.org wrote:
Clicking on the button for the part saves the wrong thing, though,
because it's not a real MIME part. That looks a bit awkward to fix, so
perhaps you could still prefix the name with inline: to indicate that
it's odd?
Dec 2011 23:31:41 +0200
Subject: [PATCH] emacs: add inline patch fake parts through a special handler
Add wash generated inline patch fake parts through a special
inline-patch-fake-part handler to distinguish them from real MIME
parts. The fake parts are described as inline patch (as text/x-diff
On Mon, 26 Dec 2011 23:52:23 +0200, Jani Nikula j...@nikula.org wrote:
Below is an idea I came up with, utilizing the content-type
vs. declared-type distinction. I think it's really simple and neat,
but I hope not too magical.
Picking up an example mail from the list, inline patches would
: create patch filename from subject for inline patch fake parts
test: emacs: test notmuch-wash-subject-to-* functions
emacs/notmuch-wash.el | 43 -
test/emacs-subject-to-filename | 138
test/notmuch-test |1 +
3 files
Use the mail subject line for creating a descriptive filename for the wash
generated inline patch fake parts. The names are similar to the ones
created by 'git format-patch'.
If the user has notmuch-wash-convert-inline-patch-to-part hook enabled in
notmuch-show-insert-text/plain-hook
Signed-off-by: Jani Nikula j...@nikula.org
---
test/emacs-subject-to-filename | 138
test/notmuch-test |1 +
2 files changed, 139 insertions(+), 0 deletions(-)
create mode 100755 test/emacs-subject-to-filename
diff --git a/test/emacs
the middle of the replace process.)
>
> This is splitting hairs, but in my original suggestion, I was thinking
> something like
>
> (let* ((s subject)
> (s (replace-regexp-in-string "^ *\\(\\[[^]]*\\]\\)? *" "" s))
> (s (replace-regexp-in-stri
gestion, I was thinking
something like
(let* ((s subject)
(s (replace-regexp-in-string "^ *\\(\\[[^]]*\\]\\)? *" "" s))
(s (replace-regexp-in-string "[. ]*$" "" s))
(s (replace-regexp-in-string "[^A-Za-z0-9._-]+" "-"
On Tue, 20 Dec 2011 16:52:52 -0500, Austin Clements wrote:
> Seems like a definite improvement, but perhaps a let* instead of all
> of the setq's?
What would be a lispy approach? I tried:
(defun notmuch-subject-to-patch-filename (subject)
"Convert a typical patch mail s
Hi Jani.
On Tue, 20 Dec 2011 22:05:31 +0200, Jani Nikula wrote:
>
> Shameless promotion of own patches... I suppose not many use the
> notmuch-wash-convert-inline-patch-to-part option, but with this patch
> I've actually started to like it better. An actual patch name from
>
On Tue, 20 Dec 2011 16:52:52 -0500, Austin Clements amdra...@mit.edu wrote:
Seems like a definite improvement, but perhaps a let* instead of all
of the setq's?
What would be a lispy approach? I tried:
(defun notmuch-subject-to-patch-filename (subject)
Convert a typical patch mail subject
was thinking
something like
(let* ((s subject)
(s (replace-regexp-in-string ^ *\\(\\[[^]]*\\]\\)? * s))
(s (replace-regexp-in-string [. ]*$ s))
(s (replace-regexp-in-string [^A-Za-z0-9._-]+ - s))
(s (replace-regexp-in-string \\.+ . s))
(s (substring s 0 (min
of the replace process.)
This is splitting hairs, but in my original suggestion, I was thinking
something like
(let* ((s subject)
(s (replace-regexp-in-string ^ *\\(\\[[^]]*\\]\\)? * s))
(s (replace-regexp-in-string [. ]*$ s))
(s (replace-regexp-in-string [^A-Za-z0-9
Shameless promotion of own patches... I suppose not many use the
notmuch-wash-convert-inline-patch-to-part option, but with this patch
I've actually started to like it better. An actual patch name from
subject instead of "inline patch".
As I said, the lisp is less than pe
ally started to like it better. An actual patch name from
> subject instead of "inline patch".
>
> As I said, the lisp is less than perfect here, but this is still better
> than what's existing.
>
> Any comments?
>
>
> BR,
> Jani.
>
>
> On Sat, 19
Shameless promotion of own patches... I suppose not many use the
notmuch-wash-convert-inline-patch-to-part option, but with this patch
I've actually started to like it better. An actual patch name from
subject instead of inline patch.
As I said, the lisp is less than perfect here
Hi Jani.
On Tue, 20 Dec 2011 22:05:31 +0200, Jani Nikula j...@nikula.org wrote:
Shameless promotion of own patches... I suppose not many use the
notmuch-wash-convert-inline-patch-to-part option, but with this patch
I've actually started to like it better. An actual patch name from
subject
it better. An actual patch name from
subject instead of inline patch.
As I said, the lisp is less than perfect here, but this is still better
than what's existing.
Any comments?
BR,
Jani.
On Sat, 19 Nov 2011 01:02:48 +0200, Jani Nikula j...@nikula.org wrote:
Use the mail subject
Fixed whitespace error reported by Jameson.
Fixed whitespace error reported by Jameson.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
So it turns out the completely untested NOTMUCH_OPT_STRING code was
(surpise!) buggy. I also fixed a few remaining formatting issues, added
a unit test, and some documentation (in command-line-arguements.h).
I also reordered option description struct so that the two mandatory
(in the sense of
So it turns out the completely untested NOTMUCH_OPT_STRING code was
(surpise!) buggy. I also fixed a few remaining formatting issues, added
a unit test, and some documentation (in command-line-arguements.h).
I also reordered option description struct so that the two mandatory
(in the sense of
I decided to start a new thread since the other one
id:"1322808114-11854-1-git-send-email-david at tethera.net" was getting
pretty long, and there was no actual relevant discussion there.
I think these patches are getting close to ready.
One thing to discuss is the inclusion of single element
I decided to start a new thread since the other one
id:1322808114-11854-1-git-send-email-da...@tethera.net was getting
pretty long, and there was no actual relevant discussion there.
I think these patches are getting close to ready.
One thing to discuss is the inclusion of single element
Use the mail subject line for creating a descriptive filename for the wash
generated inline patch fake parts. The names are similar to the ones
created by 'git format-patch', just without the leading numbers.
Signed-off-by: Jani Nikula
---
I know notmuch-subject-to-patch-filename is totally un
Use the mail subject line for creating a descriptive filename for the wash
generated inline patch fake parts. The names are similar to the ones
created by 'git format-patch', just without the leading numbers.
Signed-off-by: Jani Nikula j...@nikula.org
---
I know notmuch-subject-to-patch
---
NEWS | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index 71c7c9a..88f7b20 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,21 @@ Add search terms to "notmuch dump"
search/show/tag. The output file argument of dump is deprecated in
favour
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements wrote:
> This is a rebase and cleanup of Istvan Marko's patch from
> id:m3pqnj2j7a.fsf at zsu.kismala.com
>
Pushed. Would you mind making a NEWS patch?
d
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements amdra...@mit.edu wrote:
This is a rebase and cleanup of Istvan Marko's patch from
id:m3pqnj2j7a@zsu.kismala.com
Pushed. Would you mind making a NEWS patch?
d
___
notmuch mailing list
---
NEWS | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index 71c7c9a..88f7b20 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,21 @@ Add search terms to notmuch dump
search/show/tag. The output file argument of dump is deprecated in
favour of
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements wrote:
> This is a rebase and cleanup of Istvan Marko's patch from
> id:m3pqnj2j7a.fsf at zsu.kismala.com
>
> Search retrieves these headers for every message in the search
> results. Previously, this required opening and parsing every message
I really hate the default behavior of the space bar in notmuch-show; I
don't want it to pop out of the thread that i'm currently view, and I
especially don't want it to archive threads. The space bar should
just be for viewing, not altering.
The following patch breaks out the food functionality
201 - 300 of 449 matches
Mail list logo
