On 8/15/21 12:27 PM, David Bremner wrote:
I should repeat my advertising for the (in-progress) s-expression query
parser [1], which would allow defining macros to group various user
defined headers. So assuming headers XSpam and XSpamResult are defined,
$ notmuch config set squery.Spam '(macro
On 8/5/21 3:44 AM, David Bremner wrote
I started thinking about how I would add this feature and was thinking
it might be better to support in the configuration by using semi-colon
separated values like some of the other config options. For example:
[index]
header.Spam=X-Spam;X-Spam-Result
I've been a very happy user of notmuch for a very long time. Thank you
for such a great tool!
Recently I've been working on implementing a new workflow for handling
email which uses automated tagging much more heavily. In doing so, I
want to use some custom header indexes to construct some of
On 10/18/18 1:37 AM, Jeff Templon wrote:
I guess the point for me is that I frequently search for messages (and
not threads), and when I do so, it's easy for me to forget that actions
taken on the results buffer not only apply to those messages, they can
apply to all messages in threads that
On Mon, 2016-11-21 at 13:44 +0200, Jani Nikula wrote:
> I wonder if there's a way to define different Execs for clicking on
> the icon and handling mailto.
The desktop file format specification implies you can just add an extra
context entry. For reference, the full specification is here:
On Sat, 2016-10-22 at 12:55 +0300, Jani Nikula wrote:
> Any ideas how to get a list of mime types in shell, so I could do the
> same in bash completion without hard-coding some limited list?
Not sure if this is really what you're looking for, but on my archlinux
system, the file /etc/mime.types
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
---
emacs/notmuch-maildir-fcc.el | 13 ++---
1 file changed,
Tnis version implements Mark's second, simpler, suggestion. Since
the reference to split-string-and-unquote remains, someone with
sufficiently esoteric requirements will know where to look to
determine exactly what is possible.
___
notmuch mailing list
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
---
emacs/notmuch-maildir-fcc.el | 13 ++---
1 file changed,
On Mon, 2016-10-10 at 20:20 +0100, Mark Walters wrote:
> On Mon, 10 Oct 2016, Keith Amidon <cama...@picnicpark.org> wrote:
> >
> > I was able to make this work by setting notmuch-fcc-dirs to:
> >
> > "\"[Gmail]/Sent Mail\" +sent -inbox -unrea
I just upgraded to 0.23 and tried out the Fcc handling using notmuch-
insert. I think this is a significant improvement and I'm excited to
use it. I have it working successfully for my use case now, but it
did require one workaround that I didn't expect and that seems somewhat
fragile.
The
On Mon, 2014-09-22 at 15:06 +, Austin Clements wrote:
> I assume you're doing this from the command line? Does the following
> work?
>
> notmuch search --output=files 'path:"dir/INBOX/INBOX/Sent Items/**"'
>
> Shell quoting and Xapian quoting interact in often confusing ways. In
> your
On Mon, 2014-09-22 at 11:20 +0200, David Bremner wrote:
> Keith Amidon writes:
> >
> > notmuch search --output=files path:'dir/INBOX/INBOX/Sent Items'
> >
> > I don't get any results, but it seems like the two results above should
> > be shown, right?
I'm trying to update an archiving tool that used the old folder: search
terms to use the newer folder: or path: terms. From playing around with
it, I think that the path: term is what I want to use. However, I am
getting some behavior I don't understand unless path: searches don't
properly
On Mon, 2014-09-22 at 15:06 +, Austin Clements wrote:
I assume you're doing this from the command line? Does the following
work?
notmuch search --output=files 'path:dir/INBOX/INBOX/Sent Items/**'
Shell quoting and Xapian quoting interact in often confusing ways. In
your original
I'm trying to update an archiving tool that used the old folder: search
terms to use the newer folder: or path: terms. From playing around with
it, I think that the path: term is what I want to use. However, I am
getting some behavior I don't understand unless path: searches don't
properly
On Tue, 2014-09-02 at 14:26 +0200, David Belohrad wrote:
> could that scenario be somehow fitted automatically, so when I overwrite
> the default 'From:' address (by hand. is it possible to do some
> automatic cycling?) to work address, so that message sender in emacs
> would automatically use
On Tue, 2014-09-02 at 14:26 +0200, David Belohrad wrote:
could that scenario be somehow fitted automatically, so when I overwrite
the default 'From:' address (by hand. is it possible to do some
automatic cycling?) to work address, so that message sender in emacs
would automatically use work
Resending to the list as well as just Carl...
{-- Tue, 23 Feb 2010 11:12:36 -0800: Carl wrote: --}
Carl> I apologize for the extraordinarly-late review, but here it
Carl> is...
No problem at all. You're updates on status have been sufficient to
convince me you were making progress and
Resending to the list as well as just Carl...
{-- Tue, 23 Feb 2010 11:12:36 -0800: Carl cwo...@cworth.org wrote: --}
Carl I apologize for the extraordinarly-late review, but here it
Carl is...
No problem at all. You're updates on status have been sufficient to
convince me you were making
{-- Thu, 10 Dec 2009 16:57:01 -0800: Carl wrote: --}
Carl> First, I'm not sure whether we need two different variations of
Carl> what's effectively the same operation here ("save all
Carl> attachments").
Yes, I agree it is an ugly solution. Thanks for not letting me get away
with it.
{-- Thu, 10 Dec 2009 16:57:01 -0800: Carl cwo...@cworth.org wrote: --}
Carl First, I'm not sure whether we need two different variations of
Carl what's effectively the same operation here (save all
Carl attachments).
Yes, I agree it is an ugly solution. Thanks for not letting me get away
Prompt for a directory and write all attachments of the current
message to that directory, prompting for a filename for each with a
default value of the filename specified in the attachment.
The behavior of this function differs in two ways from the existing
notmuch-show-save-attachments
Prompt for a directory and write all attachments of the current
message to that directory, prompting for a filename for each with a
default value of the filename specified in the attachment.
The behavior of this function differs in two ways from the existing
notmuch-show-save-attachments
Previously only mime parts that indicated specified a "disposition" of
"attachment" were saved. However there are time when it is important
to be able to save inline content as well. After this commit any mime
part that specifies a filename will be considered when saving
attachments.
---
I found there were some attachments I couldn't save using the existing
functionality. Since I was already touching the code I implemented a
rough cut at the "save all attachments" function Carl requested as
well.
I don't think this is the best code in the world but it gets the job
done for now
{-- Fri, 27 Nov 2009 21:22:36 -0800: Carl wrote: --}
Carl> On Fri, 27 Nov 2009 05:30:12 -0800, camalot at picnicpark.org wrote:
>> From: Keith Amidon
>>
>> As an alternative to creating a reply from the current thread, this
>> commit provides functions
{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl wrote: --}
Carl> So when there are quick and easy things, (like calling an
Carl> existing function on an 'f' binding like above), that totally
Carl> makes sense to do. We can look at things like that as interim
Carl> solutions until the C program
{-- Fri, 27 Nov 2009 21:15:15 -0800: Carl wrote: --}
Carl> On Fri, 27 Nov 2009 05:30:11 -0800, camalot at picnicpark.org wrote:
>> From: Keith Amidon
>> Sometimes forwarding a message is preferable to replying and
>> modifying the set of recipients. This commit
{-- Fri, 27 Nov 2009 21:06:45 -0800: Carl wrote: --}
Carl> On Fri, 27 Nov 2009 05:30:08 -0800, camalot at picnicpark.org wrote:
Carl> I had a patch (on a side branch that I must have never merged)
Carl> that just removed these autoload comments. Do these even do
Carl> anything for a file
{-- Fri, 27 Nov 2009 21:06:45 -0800: Carl cwo...@cworth.org wrote: --}
Carl On Fri, 27 Nov 2009 05:30:08 -0800, cama...@picnicpark.org wrote:
Carl I had a patch (on a side branch that I must have never merged)
Carl that just removed these autoload comments. Do these even do
Carl anything
{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl cwo...@cworth.org wrote: --}
Carl So when there are quick and easy things, (like calling an
Carl existing function on an 'f' binding like above), that totally
Carl makes sense to do. We can look at things like that as interim
Carl solutions until
{-- Fri, 27 Nov 2009 20:48:46 +0530: Aneesh wrote: --}
Aneesh> Hi, Really good set of patches. I am right now testing with
Aneesh> the set of changes and found that
Thanks!
Aneesh> a) notmuch-show-reply-current and other helpers doesn't put
Aneesh> the mail content i am replying in the
33 matches
Mail list logo
