Sometimes a notmuch query matches only a subset of messages in a thread.
When this happens only that subset of messages will be "open". Many
notmuch commands operate on the "open" messages only. For example: SPC,
'n', 'p'.
Often this is what I want. It works well when I'm looking for a
specific
A feature I miss from Gnus is being able to reply to multiple emails at
once. Has anyone else found to be a missing feature? I wonder if it
would be easy to add to notmuch's Emacs MUA.
Background: In Gnus' equivalent to notmuch.el's tree mode it is possible
to "mark" multiple messages at once in
Jonathan Wilner writes:
> I love this feature! I hope it could get mainstreamed. :-)
Yes, seems like a nice idea to me.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Matt Armstrong writes:
> See Emacs bug#58479. An upcoming change in Emacs will make these
> dangling overlays visible to the user.
It seems that the ellipsis overlays were shown due to a bug in Emacs,
but this patch is still a reasonable idea. Otherwise, every time a
notmuch search buf
notmuch-search-insert-authors now sets the evaporate property on the
ellipsis overlays. Emacs will delete them when the buffer contents
are zeroed out, which happens with `notmuch-refresh-buffer`. This
prevents them from being collapsed to zero-width overlays in position
1. See Emacs bug#58479.
BSD xargs does not have the -d option. Here we use tr to convert
newlines to NUL characters, then pass -0 to xargs (which BSD does
support).
I looked at passing -z to 'git ls-files', but I did not find a BSD
grep option to turn on NUL deliminted line processing.
---
devel/author-scan.sh | 2 +-
1
David Bremner writes:
[...]
> +case NOTMUCH_CONFIG_BACKUP_DIR:
> + return "database.backup_dir";
[...]
David, your recent changes that allow configurable separation of the
mail store and .notmuch files look like good ideas to me.
Separately, I've recently set up backups of my system a
Mark Gardner writes:
> I am so close to getting my ideal email setup working...
>
> Instead of offlineimap or mbsync, I use gmailieer to pull down emails. It
> is quite fast and works with notmuch to map Gmail labels to notmuch tags.
> Much cleaner than the awkward way of accessing Gmail through
David Bremner writes:
> Matt Armstrong writes:
>
>> Carl Worth writes:
>>
>>> Hi Gregor,
>>>
>>> The trick here is that when notmuch is indexing body text it feeds it
>>> into a Xapian function that parses the text by finding "terms&q
Sheng Yang writes:
> For the second case, I mean the call of notmuch-help fails with the
> following error:
>
> notmuch-documentation-first-line: Symbol’s function definition is void:
> aya-persist-snippet
>
> Sorry for the confusion. Other void functions include the following for me
>
> spacema
David, interesting idea. I'm not very familiar with this code or its
conventions so my feedback should be taken with that in mind. More
below.
David Bremner writes:
> diff --git a/lib/database.cc b/lib/database.cc
> index 9cf8062c..27c2d042 100644
> --- a/lib/database.cc
> +++ b/lib/database.
I miss some of the Gnus "wash" functions available for message display.
There was one that either reformatted the Date: header into my time
zone, or displayed the Date in terms of elapsed time from now (e.g. 1
hour ago, 1 day ago, etc.). I don't remember which, but I'd be happy
with either.
Has a
David Bremner writes:
> Jan Malakhovski writes:
>
>>
>> The test suite has such a message already. "signature verification
>> (notmuch CLI)" test fails with a SIGSEGV when built with gmime-2.6.23.
>>
>> T355-smime: Testing S/MIME signature verification and decryption
>> gpgsm: keybox
>> '/tmp/n
David Bremner writes:
> Matt Armstrong writes:
>
>> David Bremner writes:
>
>> This is happening to me on a fairly regular basis too. Is there
>> something I can bind C-x C-s to in notmuch-show that doesn't create a
>> new draft?
>>
>>
David Bremner writes:
> Matt Armstrong writes:
>
>> David Bremner writes:
>>
>>> Matt Armstrong writes:
>>>
>>>> I've been able to diagnose a SIGSEGV, and I have a workaround that
>>>> satisfies me. I'm unsure
David Bremner writes:
> Sanjoy Mahajan writes:
>
>> I save an outgoing email as I write it and often (as if it were a
>> regular document) by using the usual Emacs key sequence C-x C-s. With
>> notmuch v0.24, notmuch saves a proper draft each time I use C-x C-s.
>> The result is a million draft
David Bremner writes:
> Matt Armstrong writes:
>
>> I've been able to diagnose a SIGSEGV, and I have a workaround that
>> satisfies me. I'm unsure how to fix it, so I'll describe the problem
>> and leave it at that.
>>
>> Repro:
>>
>
I've been able to diagnose a SIGSEGV, and I have a workaround that
satisfies me. I'm unsure how to fix it, so I'll describe the problem
and leave it at that.
Repro:
% notmuch --version
notmuch 0.25+22~g0967e46 (a recent git @HEAD)
% notmuch show --format=sexp --decrypt thread:0002ad2c
->
Daniel Kahn Gillmor writes:
> Hey all--
>
> I really appreciate the thought and experimentation and research that's
> gone into this thread!
>
> On Thu 2017-06-22 17:00:58 -0700, Matt Armstrong wrote:
>> # All threads in which I participate get tag:participated
>
David Bremner writes:
> Daniel Kahn Gillmor writes:
>
>>
>> For example, would it make sense to have "notmuch new" (and "notmuch
>> insert") do "thread-based propagation" of specific tags? for example,
>> consider the following (i've just made up the config options):
>>
>> notmuch config se
Gaute Hope writes:
> Gaute Hope writes on juni 22, 2017 8:08:
>> Daniel Kahn Gillmor writes on juni 21, 2017 23:30:
>>> On Wed 2017-06-21 13:04:53 -0700, Matt Armstrong wrote:
>>>> For what it is worth, I've found this idea from Daniel intriguing
Daniel Kahn Gillmor writes:
> On Wed 2017-06-21 13:04:53 -0700, Matt Armstrong wrote:
>> For what it is worth, I've found this idea from Daniel intriguing and
>> pretty useful in practice:
>>
>> "show me threads in which i've participated, where
Gaute Hope writes:
> David Bremner writes on juni 15, 2017 22:20:
>> Daniel Kahn Gillmor writes:
>>>
>>> One of my long-standing wishes is to be able to say "show me mails in my
>>> inbox from people who have replied to messages i've sent them".
>>>
>>> This could be re-framed as "show me thread
David Bremner writes:
> Daniel Kahn Gillmor writes:
>
>>
>> One of my long-standing wishes is to be able to say "show me mails in my
>> inbox from people who have replied to messages i've sent them".
>>
>> This could be re-framed as "show me threads in which i've participated,
>> where there are
Mark Walters writes:
> +Fix notmuch-interesting-buffer and notmuch-cycle-notmuch-buffers.
> +
> + The functions `notmuch-interesting-buffer` which detects notmuch
> + buffers, and `notmuch-cycle-notmuch-buffers` which cycles between
> + notmuch buffers, now additionally detect notmuch-tree-mod
Jani Nikula writes:
> On Tue, Nov 8, 2016 at 1:16 AM, Matt Armstrong wrote:
>> I'm not experienced with managing patches via email on this list,
>> especially when it comes to applying patches sent out for review and
>> testing. Is there a documented best practic
I'm not experienced with managing patches via email on this list,
especially when it comes to applying patches sent out for review and
testing. Is there a documented best practice?
Ideally, I'd like a "dwim" command that does something reasonable, such
as take messages from the current thread and
Hey Mark,
For consistency with Emacs' own elisp, perhaps rename
notmuch-mua-pre-send-check-hooks to
notmuch-mua-pre-send-check-functions?
This patch reminded me of a recent discussion on emacs-devel about the
definition of "hook" in Emacs code and documentation. There is the
broad meaning of "ar
I noticed that https://notmuchmail.org/emacstips/#index21h2 is stale
(the patch it mentions is now part of notmuch). Is there a git
repository for the website that I can suggest patches against?
___
notmuch mailing list
notmuch@notmuchmail.org
https://no
Mark Walters writes:
[...]
> Version 1 of this patch (with some discussion) is at
> id:1477191835-17828-1-git-send-email-markwalters1009 at gmail.com
>
> The general consensus is that we should not define functions outside
> our namespace, even when they are just backports of functions from
> la
The notmuch-tag-flagged, notmuch-search-flagged-face and
notmuch-crypto-part-header faces defaulted to "blue", which is nearly
unreadable when a dark background is in use. This is addressed by using
"LightBlue1" for dark backgrounds.
As a side effect, these faces are now no-op definitions for gra
This is a followup to
id:1476987754-13672-1-git-send-email-marmstr...@google.com with:
- Addition of ((class color) (background light)) tests for the light
faces, as requested by Mark. This is consistent with how many
other light/dark faces are already defined in notmuch.
- Switch to a
Matthew Lear writes:
> Hi,
> I switched to trying emacs 25 (25.1) with notmuch the other day.
I'm on 25.1 as well, but haven't experienced the symptoms you describe.
>> !!! Bodypart handler `notmuch-show-insert-part-text/html' threw an error:
>> !!! Window is dedicated to ‘*unsent mail to u...@
Neat. Basics of it look correct to me. Personally, I'd abandon most of
these environment variables and edit the script directly, but that goes
against your stated goal.
Other comments below.
Tomi Ollila writes:
> Hi
>
> j4ni on irc expressed interest of having an installation option for
> no
David Bremner writes:
> Mark Walters writes:
>
>> This is a good point. I think I don't mind too much if they do -- they
>> should see it is provided by notmuch-lib if they do describe-function
>> etc. But maybe bremner would like to comment?
>>
>> However, maybe other packages are doing the sam
Mark Walters writes:
> +;; Compatability functions for emacs 23.
> +
> +(unless (fboundp 'setq-local)
> + (defmacro setq-local (var val)
> +`(set (make-local-variable ',var) ,val)))
A concern I have with this approach is that it modifies symbols outside
the notmuch namespace. Could people
Mark Walters writes:
> Broadly this looks good to me -- though I think blue is OK on some dark
> backgrounds so it would be good to have confirmation from some people
> who do use a dark background normally as to whether they had to
> customise these faces.
I'm happy to wait for further feedback
The notmuch-tag-flagged, notmuch-search-flagged-face and
notmuch-crypto-part-header faces defaulted to "blue", which is nearly
unreadable when a dark background is in use. This is addressed by using
"gold" for dark backgrounds.
---
emacs/notmuch-crypto.el | 5 -
emacs/notmuch-tag.el| 5 ++
I found a multipart/signed message and verified that indeed the "blue"
button created by way of notmuch-crypto-part-header is unreadable on
dark backgrounds.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuc
Mark Walters writes:
> In commit 2a7b11b064233afc4feead876fa396e3c18a6b91 the default value
> for notmuch-search-line-faces was changed so that it didn't match the
> specification in the corresponding defcustom. This meant that it was
> difficult for the user to customize this variable as they go
The notmuch-tag-flagged and notmucy-search-flagged-face faces defaulted
to "blue", which is nearly unreadable when a dark background is in use.
This is addressed by using "gold" for dark backgrounds.
There is one remaining unconditional use of "blue" at
notmuch-crypto-part-header, but I don't have
notmuch-show--build-buffer now queries a list of queries built by the
former. This simplifies the logic. It also provides an easy place to
experiment with alternate sets of queries for given notmuch-show-*
variables (e.g. users can use advice-add to do so in a surgical way).
---
emacs/notmuch-sh
Mark Walters writes:
>> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
[...]
>> +(defun notmuch-show--build-queries ()
[...]
> We may want to call this from tree-mode later, so I wonder whether
> passing it notmuch-show-thread-id and notmuch-show-query-context as
> arguments would
Mark Walters writes:
> On Mon, 17 Oct 2016, Matt Armstrong wrote:
>> David Bremner writes:
>>
>>> I (very) recently started using longer key sequences with Mark's
>>> tag-jump feature. One thing I miss from a similar feature in org-mode
>>> (e.
David Bremner writes:
> I (very) recently started using longer key sequences with Mark's
> tag-jump feature. One thing I miss from a similar feature in org-mode
> (e.g. exporting) is some visual feedback on what I have typed so far,
> and thus what my next key is likely to do.
Tangentially, has
Matt Armstrong writes:
> This supercedes
> id:1476207707-21827-1-git-send-email-marmstr...@google.com with
> changes steming from Mark's helpful feedback.
Apologies for the lack of a subject here. I'm still learning the ins
and outs of 'git send-email'. I can
notmuch-show--build-buffer now queries a list of queries built by the
former. This simplifies the logic. It also provides an easy place to
experiment with alternate sets of queries for given notmuch-show-*
variables (e.g. users can use advice-add to do so in a surgical way).
---
emacs/notmuch-sh
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
y one way to do this.
Mark Walters writes:
> On Tue, 11 Oct 2016, Matt Armstrong wrote:
>> notmuch-show--build-buffer now queries a list of queries built by the
>> former. This simplifies the logic. It also provides an easy place to
>> experiment with alternate sets of q
notmuch-show--build-buffer now queries a list of queries built by the
former. This simplifies the logic. It also provides an easy place to
experiment with alternate sets of queries for given notmuch-show-*
variables (e.g. users can use advice-add to do so in a surgical way).
---
emacs/notmuch-sh
This supercedes
id:1474003701-19831-1-git-send-email-marmstr...@google.com with a much
simpler patch. My goal here is to make it easier to tweak
notmuch-show behavior without hacking on notmuch-show--build-buffer
itself, since it is responsible for a host of other tasks.
I'm still working (slowly
David Bremner writes:
> Mark Walters writes:
>
> If we think about the operation as reverse rather than undo
I'd be happy without undo/reverse in the first version of this feature.
I have a few key bindings I've set up and I have not bothered to set up
"reverse/undo" for them.
_
Tomi Ollila writes:
> I don't (yet) know how complete this is (Someone's "workflow" it may break)
> but tests pass...
[...]
> -(defun notmuch-query-get-threads (search-terms)
> +(defun notmuch-query-get-threads (cli-args search-terms)
I'm new here and still have a low reputation :-) but fwiw,
(notmuch-apply-face tag
(if (display-supports-face-attributes-p'(:strike-through "red"))
'(:strike-through "red")
'(:inverse-video t)))
Mark Walters writes:
> Commit d25d33ff cleaned up some of the tag face code. However, for the
> face notmuch-tag-deleted it
Mark Walters writes:
> Hi
>
> On Fri, 16 Sep 2016, Matt Armstrong wrote:
>> Tomi, thanks for your reply asking for some motivation behind this
>> patch. I can't reply directly to your message because, for some reason,
>> it doesn't appear in my mailbox (I
Mark Walters writes:
> Hi
>
> On Fri, 16 Sep 2016, Matt Armstrong wrote:
>> Expand unread messages by default in show mode.
>>
>> Show mode now expands messages matching tags designated by
>> notmuch-show-unread-tags (in addition to those matching the search
>
Jani Nikula writes:
> On Thu, 04 Aug 2016, Carl Worth wrote:
>>> i) notmuch could have an "also expand tags" feature, where thread based
>>> results would auto expand matching tags. I would set this to
>>> "unread".
>>
>> This approach makes a lot of sense to me based on how notmuch.el
he quoting is unnecessary on both accounts.
Matt Armstrong writes:
> Remove shell quoting from notmuch-show--build-buffer. The args list
> is ultimately passed to call-process, which passes them verbatim to
> the subprocess (typically, notmuch). The quoting, intended for a
>
Expand unread messages by default in show mode.
Show mode now expands messages matching tags designated by
notmuch-show-unread-tags (in addition to those matching the search
query). By default, this list is `("unread"). This way, one can still
tag and search for messages however one likes, but i
Sorry, ignore this one.
id:1473834053-17591-1-git-send-email-marmstr...@google.com has some
typo fixes to the commit message.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Remove shell quoting from notmuch-show--build-buffer. The args list
is ultimately passed to call-process, which passes them verbatim to
the subprocess (typically, notmuch). The quoting, intended for a
shell, is unnecessary and confusing.
This code originally appeared in
9193455fa1476ea3957475e77
Remove shell quoting from notmuch-show--build-buffer. The args list
is ultimately passed to call-process, which passes them verbatim to
the subprocess (typically, notmuch). The quoting, intended for a
shell, are unnecessary and confusing.
This code originally appeared in
9193455fa1476ea3957475e7
I believe this moves all "anonymous" face specifications in notmuch
code into a configurable defface.
---
NEWS | 8
emacs/notmuch-tag.el | 45 ++---
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/NEWS b/NEWS
index
While passing a lambda to mapc is idiomatic elisp, dolist is easier
to understand, and there are a few other calls to it in this file.
---
emacs/notmuch.el | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 43d56f7..6307b37 1
Ken Stevens writes:
> I am new to notmuch. I am using the emacs interface for notmuch. I would
> like to be able to use bbdb to manage my contacts. Is their a simple way
> to integrate bbdb and notmuch so I cann add addresses, etc.
https://notmuchmail.org/emacstips/ has some coverage for bbdb in
My mail yesterday about muting
(id:qf5vazjjciq@marmstrong-linux.kir.corp.google.com) was in part
motivated by this question:
Has anybody implemented something like "snooze" in notmuch?
I think of a "snooze" as a temporary mute.
The intent would be to hide messages from the inbox until some f
Yuri D'Elia writes:
> For example, for a query like "tag:unread AND date:24h..now", I'm shown
> all threads containing unread messages within the last day, which is
> perfect. But when I select a thread (with RET), I'm shown the thread
> from the start.
Yuri, I see you're running into issues sim
Jani Nikula writes:
> On Thu, 04 Aug 2016, Matt Armstrong wrote:
>> This question pertains to notmuch built from recent git HEAD, using
>> notmuch.el in show mode (i.e. not tree mode).
>>
>> I sometimes read a thread with a bunch of messages and notmuch.el
>> c
This question pertains to notmuch built from recent git HEAD, using
notmuch.el in show mode (i.e. not tree mode).
I sometimes read a thread with a bunch of messages and notmuch.el
collapses a bunch of them (even if unread and the search matches tags in
every message). I can't figure out the heuri
I've got a privately built xapian 4.0 in my $HOME/opt/xapian-core-1.4.0
dir, and its bin dir in my path.
xapian-config is working like this:
% xapian-config --libs
-L/usr/local/google/home/marmstrong/opt/xapian-core-1.4.0/lib -lxapian
Then "./configure; make" doesn't produce a functioning build
David Bremner writes:
> Matt Armstrong writes:
>
>> Is anyone else interested in Gmail-like "mute" support in notmuch.el?
>> If so, I can think about polishing the below off and adding it to
>> notmuch.
>>
>> I've managed to implement Gmail
David Bremner writes:
> Matt Armstrong writes:
>
>
>> To address both, has something like this ever been considered:
>>
>> notmuch --lock_timeout COMMAND ARG...
>>
>> Then frontends like Emacs could lean on retry logic written in C. If
>> t
Nicolas Petton writes:
> [ Unknown signature status ]
> Matt Armstrong writes:
>
>>> The AUTHORS file is not unmaintained, why are you saying that?
>>
>> I was going by David's related comment where he said the file had not
>> changed in seven years:
Is anyone else interested in Gmail-like "mute" support in notmuch.el?
If so, I can think about polishing the below off and adding it to
notmuch.
I've managed to implement Gmail's "mute" in notmuch as follows in my
notmuch-post-new:
-
Simple notmuch commands like "notmuch tag" can fail to grab the Xapian
lock. When this occurs they bail with:
A Xapian exception occurred opening database: Unable to get write lock on
/example/.notmuch/xapian: already locked
I've noticed a few issues with this:
1) The notmuch command line does
Nicolas Petton writes:
> [ Unknown signature status ]
> Matt Armstrong writes:
>
>> Looking into this further, if AUTHORS file is essentially unmaintained,
>> I need not touch it.
>
> The AUTHORS file is not unmaintained, why are you saying that?
I was going by David
David Bremner writes:
> Never argue with a happy lawyer, that's motto :). It sounds like we're
> good to go; I merged patch 2/2 after moving the NEWS. Then I wanted to
> shorten the summary line of the commit, which got a bit more intrusive
> than I wanted, hopefully it conveys the intent of the
David Bremner writes:
> Matt Armstrong writes:
>
>> By virtue of being a Google employee I'm required to contribute
>> software in the name of Google and not myself.
[...]
> I've no objection to this in principle, but
>
> 1) if we start updating AUTHORS
This makes it easier to find the relevant face by customizing
notmuch-faces. I plan to do the same to the other alists of faces
found elsewhere.
---
NEWS | 7 +++
emacs/notmuch.el | 39 ---
2 files changed, 39 insertions(+), 7 deletions(-)
dif
. (by way of Matt Armstrong )
--
2.8.0.rc3.226.g39d4020
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
clear that Google is the legal entity that owns whatever rights (and
liabilities!) exists for the work I do. So, I use
marmstr...@google.com and not my personal mail, and the contributor
line should say Google and not "Matt Armstrong". Of course, given
this is a GPL project, those rights
81 matches
Mail list logo