Re: tell me how to do this (mass tagging of messages)

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

Re: [PATCH 6/8] emacs/desktop: update to use notmuch-emacs-mua and handle mailto

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:

Re: [PATCH] emacs: add mimetype completions to searches

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

[PATCH] Expand docstrings about fcc using notmuch-insert

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,

[PATCH v2] Expand docstrings about fcc using notmuch-insert

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

[PATCH] Expand docstrings about fcc using notmuch-insert

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,

Re: notmuch-insert Fcc handling w/spaces in dir name

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

notmuch-insert Fcc handling w/spaces in dir name

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

Do path: searches handle spaces correctly?

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

Do path: searches handle spaces correctly?

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?

Do path: searches handle spaces correctly?

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

Re: Do path: searches handle spaces correctly?

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

Do path: searches handle spaces correctly?

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

sending email using different server for different 'From:' field

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

Re: sending email using different server for different 'From:' field

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

[notmuch] [PATCH] Rework saving of attachments.

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

Re: [notmuch] [PATCH] Rework saving of attachments.

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

[notmuch] [PATCH 2/2] Save all attachments to a directory

{-- 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.

Re: [notmuch] [PATCH 2/2] Save all attachments to a directory

{-- 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

[notmuch] [PATCH 2/2] Save all attachments to a directory

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

[notmuch] [PATCH 2/2] Save all attachments to a directory

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

[notmuch] [PATCH 1/2] Expand scope of items considered when saving 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. ---

[notmuch] Simple improvements to 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

[notmuch] [PATCH 6/9] Reply to individual messages using message library

{-- 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

[notmuch] [PATCH 5/9] Forward individual messages using message-forward

{-- 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

[notmuch] [PATCH 5/9] Forward individual messages using message-forward

{-- 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

[notmuch] [PATCH 2/9] Adjust autoload comments

{-- 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

Re: [notmuch] [PATCH 2/9] Adjust autoload comments

{-- 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

Re: [notmuch] [PATCH 5/9] Forward individual messages using message-forward

{-- 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

[notmuch] [PATCH 6/9] Reply to individual messages using message library

{-- 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