This series obsoletes the series at
id:20240828160710.866567-1-da...@tethera.net
As far as the points there,
0, 1 still hold.
3) There is now URL handling, in an upwardly compatible way from felipe's
script and (I think) neomutt.
4) The error handling has improved, although arguably stil
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 CLI
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
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 folde
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
id:20200410173039.yextm
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
From: Matthew Lear
To: notmuch@notmuchmail.org
Cc: Matthew Lear
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.14.1
If searching using the date prefix and timestamps, each times
> OK, I see with counsel-imenu the current indexing by header lines is
> reasonable. It might be improvable by adding the subject, but I'm
> not sure about line lengths.
> - maybe the docstrings should recomment counsel-imenu?
I'm not sure as the function
`notmuch-show-imenu-extract-index-name-fu
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 include
This implementation adds add_exit_function (and rm_exit_function)
which can also be used for other things in the future.
Now that I did this simpler way would be to just check for
existence of $GNUPGHOME for indication to exit gpg processes.
If that path is taken this series can be used for futur
This supercedes
id:1476207707-21827-1-git-send-email-marmstr...@google.com with
changes steming from Mark's helpful feedback.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
From: Matthew Lear
To: notmuch@notmuchmail.org
Cc: Matthew Lear
Subject: [PATCH] Fix reply to encrypted mail when discouraging plain text.
Date: Tue, 11 Oct 2016 22:24:18 +0100
Message-Id: <1476221058-10431-1-git-send-email-m...@bubblegen.co.uk>
X-Mailer: git-send-email 2.4.10
If an encrypted mu
I added a new test to to be "fixed" by Mark's patch. I wasn't 100%
sure about whether to add the test to the emacs set or the crypto set,
but this way doesn't introduce new dependencies to the test set (T350
is already using emacs). If people feel strongly we could move the
test to T310; this will
This obsoletes
id:1449842087-10972-1-git-send-email-da...@tethera.net
I reworked the tests to use gpgsm to generate the certificate. This
leaves less room for me to screw things up. Since this requires gpgsm
2.1, I'm including the certs in the patches, rather then having the
test suite gene
It turns out S/MIME encryption requires non-trivial additional code in
libgmime. There is no reason to wait for that to support signtures (via
emacs+openssl|epg), and verification (via notmuch-cli).
Here we also test encryption, relying on emacs message-mode facilities.
(At least) two things co
David Bremner writes:
> This has Jani's suggestions fixed, along with a couple of other trivial
> patches.
>
> I'll mark them ready at this point.
I pushed these, with Trevor's suggested changes.
d
This has Jani's suggestions fixed, along with a couple of other trivial patches.
I'll mark them ready at this point.
This has Jani's suggestions fixed, along with a couple of other trivial patches.
I'll mark them ready at this point.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Sat, 04 Oct 2014, David Bremner wrote:
> This is in some sense a successor to
>
> id:cover.1411914914.git.jani at nikula.org
>
> It includes the first two patches of that series verbatim, and adds
> some tests.
I like it, very nice. Start pushing and add the post-insert hook patch
from m
David Bremner writes:
> This is in some sense a successor to
>
> id:cover.1411914914.git.jani at nikula.org
>
> It includes the first two patches of that series verbatim, and adds
> some tests.
I should have said _almost_ verbatim; it marks some tests non-broken.
This is in some sense a successor to
id:cover.1411914914.git.jani at nikula.org
It includes the first two patches of that series verbatim, and adds
some tests.
This is in some sense a successor to
id:cover.1411914914.git.j...@nikula.org
It includes the first two patches of that series verbatim, and adds
some tests.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listin
Here's one approach to keeping config information at the library
level. IMHO, a key philosophical point is that this metadata is
associated with a database, not with the library.
Having every key map to a distinct file is arguably not as nice for
humans to edit, but it avoids certain concurrency
Here's one approach to keeping config information at the library
level. IMHO, a key philosophical point is that this metadata is
associated with a database, not with the library.
Having every key map to a distinct file is arguably not as nice for
humans to edit, but it avoids certain concurrency
- revise version hackery per Tomi's suggestion
- add hack to clean up doxygen's terrible nroff.
Obviously the latter is somewhat fragile, but it should fail gently,
i.e. do nothing, if the doxygen output is fixed upstream.
- revise version hackery per Tomi's suggestion
- add hack to clean up doxygen's terrible nroff.
Obviously the latter is somewhat fragile, but it should fail gently,
i.e. do nothing, if the doxygen output is fixed upstream.
___
notmuch mailing list
notmu
The first of these fixes a build failure on Debian Linux/armhf (and
OS/X). If the patch seems ok, I'd like to roll it into a bug fix
release. The second is more of a suggestion to make that atomicity
test easier to debug, since it seems to find the dark corners of gdb.
On Tue, May 06 2014, David Bremner wrote:
> The first of these fixes a build failure on Debian Linux/armhf (and
> OS/X). If the patch seems ok, I'd like to roll it into a bug fix
> release. The second is more of a suggestion to make that atomicity
> test easier to debug, since it seems to find t
On Tue, May 06 2014, David Bremner wrote:
> The first of these fixes a build failure on Debian Linux/armhf (and
> OS/X). If the patch seems ok, I'd like to roll it into a bug fix
> release. The second is more of a suggestion to make that atomicity
> test easier to debug, since it seems to find th
The first of these fixes a build failure on Debian Linux/armhf (and
OS/X). If the patch seems ok, I'd like to roll it into a bug fix
release. The second is more of a suggestion to make that atomicity
test easier to debug, since it seems to find the dark corners of gdb.
___
The first patch has been revised according to comments from Jani and
Tomi on IRC. The next two are completely new. They pass the existing
tests, but they should probably get a skeptical eye, particularly the
implementation of gzreadline, since it's hard to know how well
existing tests exercise th
The first patch has been revised according to comments from Jani and
Tomi on IRC. The next two are completely new. They pass the existing
tests, but they should probably get a skeptical eye, particularly the
implementation of gzreadline, since it's hard to know how well
existing tests exercise th
David Bremner writes:
> Several people observed a problem with the test T010-help not finding
> the man pages anymore. To fix that, I had change the previous fix:
> instead of flattening the rst2man output into one directory, I had to
> move the sphinx output into a hierarchy.
>
> Patches 1 and 3
On Thu, Mar 13 2014, David Bremner wrote:
> Several people observed a problem with the test T010-help not finding
> the man pages anymore. To fix that, I had change the previous fix:
> instead of flattening the rst2man output into one directory, I had to
> move the sphinx output into a hierarchy.
Several people observed a problem with the test T010-help not finding
the man pages anymore. To fix that, I had change the previous fix:
instead of flattening the rst2man output into one directory, I had to
move the sphinx output into a hierarchy.
Patches 1 and 3 should be the same as
id
Several people observed a problem with the test T010-help not finding
the man pages anymore. To fix that, I had change the previous fix:
instead of flattening the rst2man output into one directory, I had to
move the sphinx output into a hierarchy.
Patches 1 and 3 should be the same as
id
Hi
I have been playing with this. One thing that is worrying me a little at
the moment is that the man page looks different from before (imo less
nice). More importantly, I can't tweak the rst to get the generated
pages to look like the current ones (this could just be my lack of skill
with rst)
Mark Walters writes:
>
> The particular thing is the indentation for options (eg options in the
> notmuch.1 page) In the original pages it looks like
>
> OPTIONS
>Supported global options for notmuch include
>
>--help
>
>Print a synopsis of available commands
Here's a second try.
- less build system cruft
- integrate into notmuch's build system
- optionally build the man pages (but not info) using just
python-docutils.
No doubt this could use polishing; I'm still looking for feedback on
the general approach.
Here's a second try.
- less build system cruft
- integrate into notmuch's build system
- optionally build the man pages (but not info) using just
python-docutils.
No doubt this could use polishing; I'm still looking for feedback on
the general approach.
Changes since last round:
- rebased to current master
- one more converted man page
- a bit more actual manual text
- fix for Tomi's comment about return valules in pipeline.
- commit message of 2/3 no longer lies about the conversion process.
Changes since last round:
- rebased to current master
- one more converted man page
- a bit more actual manual text
- fix for Tomi's comment about return valules in pipeline.
- commit message of 2/3 no longer lies about the conversion process.
From: Ben Gamari
Subject: [PATCH] notmuch compact support (v3)
In-Reply-To:
Here is the latest (and hopefully last) iteration of my patchset introducing a
compact command. The set has been rebased on top of master, a manpage has been
added, and error handling has been greatly improved.
Cheers,
From: Ben Gamari
Subject: [PATCH] notmuch compact support (v3)
In-Reply-To:
Here is the latest (and hopefully last) iteration of my patchset introducing a
compact command. The set has been rebased on top of master, a manpage has been
added, and error handling has been greatly improved.
Cheers,
Martin Owens writes:
> Looking at trunk it looks like this code was rewritten completely.
> Should the packages be ignored and should trunk be used instead?
Hi Martin;
Probably somebody needs to poke the folks at Ubuntu to sync from Debian
experimental again; the packages in experimental are ve
Dear NotMuch,
I'm getting an error from the packages in Ubuntu 13.04 (beta) version
14.1 of python-notmuch:
File "/usr/lib/python2.7/dist-packages/notmuch/database.py", line 156,
in __init__
self.create(path)
File "/usr/lib/python2.7/dist-packages/notmuch/database.py", line 191,
in create
Dear NotMuch,
I'm getting an error from the packages in Ubuntu 13.04 (beta) version
14.1 of python-notmuch:
File "/usr/lib/python2.7/dist-packages/notmuch/database.py", line 156,
in __init__
self.create(path)
File "/usr/lib/python2.7/dist-packages/notmuch/database.py", line 191,
in create
david at tethera.net writes:
> Hi Gang;
>
> Here are some proposed changes to the debian packaging for 0.15.
>
> Most will probably be boring to people not familiar with debian
> packaging, with the excepotion of 4/5, which has a shell pipeline with
> two xargs in it, and almost can certainly be i
Hi Gang;
Here are some proposed changes to the debian packaging for 0.15.
Most will probably be boring to people not familiar with debian
packaging, with the excepotion of 4/5, which has a shell pipeline with
two xargs in it, and almost can certainly be improved by several
readers of this list.
Hi Gang;
Here are some proposed changes to the debian packaging for 0.15.
Most will probably be boring to people not familiar with debian
packaging, with the excepotion of 4/5, which has a shell pipeline with
two xargs in it, and almost can certainly be improved by several
readers of this list.
Hi
This is looking good: I have two comments the second of which is significant.
The first is do you want to sort (alphabetically) the headerline tags?
As it stands they are in the order they appear in the thread which is
probably not what is wanted.
The second is that there is a notmuch-show-t
From: Damien Cassou
Subject: [PATCH v4] emacs: display tags in notmuch-show with links
In-Reply-To:
This patch obsoletes:
id:1355149964-27905-1-git-send-email-damien.cassou at gmail.com
[PATCH 1/4] emacs: Add a thread's tags to notmuch-show header-line
[PATCH 2/4] emacs: Make tags in notmuch-sh
From: Damien Cassou
Subject: [PATCH v4] emacs: display tags in notmuch-show with links
In-Reply-To:
This patch obsoletes:
id:1355149964-27905-1-git-send-email-damien.cas...@gmail.com
[PATCH 1/4] emacs: Add a thread's tags to notmuch-show header-line
[PATCH 2/4] emacs: Make tags in notmuch-show
On Sun, Apr 15 2012, Jameson Graef Rollins
wrote:
> A previous patch [0] replaced blank subject lines with '[No Subject]'
> in search and show mode. Apparently this was needed to circumvent
> some bug in the printing code, but there was no need for it search or
> show, an
On Sun, Apr 15 2012, Jameson Graef Rollins wrote:
> A previous patch [0] replaced blank subject lines with '[No Subject]'
> in search and show mode. Apparently this was needed to circumvent
> some bug in the printing code, but there was no need for it search or
> show, an
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
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
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
- 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 gmai
- 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 requ
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 annoying havin
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 annoying havi
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 req
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 printi
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 printi
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 some
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 &#x
is 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 th
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 renaming.
I don't much care what the buffer name is. That seems to be
ny 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 renaming.
I don't much care what the buffer name
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 &#x
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 c
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 c
On Thu, 2 Feb 2012 00:01:31 -0400, David Bremner wrote:
> I rebased these against branch release (and copied a comment from
> aaron's email), but the test fails there, as does the reply within emacs test.
>
Same issue here.
That mark was introduced in commit 03146f20, so isn't available in th
I rebased these against branch release (and copied a comment from
aaron's email), but the test fails there, as does the reply within emacs test.
FAIL Reply within emacs
--- emacs.24.expected 2012-02-02 03:55:14.0 +
+++ emacs.24.output 2012-02-02 03:55:14.000
I rebased these against branch release (and copied a comment from
aaron's email), but the test fails there, as does the reply within emacs test.
FAIL Reply within emacs
--- emacs.24.expected 2012-02-02 03:55:14.0 +
+++ emacs.24.output 2012-02-02 03:55:14.000
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
>
;(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
>
uch-search-process-filter' which
+ ;; requires that we not disrupt its' matching state.
+ (save-match-data
+(if (and subject
+(string-match "^[ \t]*$" subject))
+ "[No Subject]"
+ subject)))
+
;;
(defun notmuch-common-do-stash (text)
dif
uch-search-process-filter' which
+ ;; requires that we not disrupt its' matching state.
+ (save-match-data
+(if (and subject
+(string-match "^[ \t]*$" subject))
+ "[No Subject]"
+ subject)))
+
;;
(defun notmuch-common-do-stash (text)
dif
his variable 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]&q
his variable 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]&q
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 preferen
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 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 preferen
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
\t]*$" subject))
+ (setq subject "[No Subject]"))
+ subject)
+
;;
(defun notmuch-common-do-stash (text)
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
index 83eb525..51bb740 100644
--- a/emacs/notmuch-print.el
+++ b/emacs/notmuch-print.el
@@ -19,6 +19,8 @@
;
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 one
ilable key bindings:
"Display the currently selected thread."
(interactive "P")
(let ((thread-id (notmuch-search-find-thread-id))
- (subject (notmuch-search-find-subject)))
-
-(if (string-match "^[ \t]*$" subject)
- (setq subject "[No Subj
\t]*$" subject))
+ (setq subject "[No Subject]"))
+ subject)
+
;;
(defun notmuch-common-do-stash (text)
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
index 83eb525..51bb740 100644
--- a/emacs/notmuch-print.el
+++ b/emacs/notmuch-print.el
@@ -19,6 +19,8 @@
;
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 one
urrently available key bindings:
"Display the currently selected thread."
(interactive "P")
(let ((thread-id (notmuch-search-find-thread-id))
- (subject (notmuch-search-find-subject)))
-
-(if (string-match "^[ \t]*$" subject)
- (setq
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
* a
1 - 100 of 148 matches
Mail list logo
