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
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 handle
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,
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 orig
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 issu
On Mon, 2016-10-10 at 20:20 +0100, Mark Walters wrote:
> On Mon, 10 Oct 2016, Keith Amidon wrote:
> >
> > I was able to make this work by setting notmuch-fcc-dirs to:
> >
> > "\"[Gmail]/Sent Mail\" +sent -inbox -unread"
>
> That is correc
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,
reviewing patch submissions quickly and not having
gotten any feedback, I'm wondering if something went wrong after all...
--- Keith
On Mon, 2016-10-10 at 21:52 -0700, Keith Amidon wrote:
> This commit expands docstrings for notmuch-fcc-dirs and
> notmuch-maildir-fcc-with-notmuc
On Thu, 2016-10-13 at 22:30 -0300, David Bremner wrote:
> No technical difficulties, we're just not as good as you think we are
> at quick reviews ;). I wanted to hear what Mark felt about exposing
> these internals as docstring. I OK with it, but it does make it
> slightly harder to change things
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 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 is
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:
https:
{-- 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
{-- 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: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
{-- 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 g
{-- 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 to
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 an
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
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 function:
{-- 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. :-)
{-- 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
{-- Fri, 27 Nov 2009 21:06:45 -0800: Carl 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 for a file tha
{-- Fri, 27 Nov 2009 21:15:15 -0800: Carl wrote: --}
Carl> On Fri, 27 Nov 2009 05:30:11 -0800, cama...@picnicpark.org wrote:
>> From: Keith Amidon
>> Sometimes forwarding a message is preferable to replying and
>> modifying the set of recipients. This commit
{-- 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 g
{-- Fri, 27 Nov 2009 21:22:36 -0800: Carl wrote: --}
Carl> On Fri, 27 Nov 2009 05:30:12 -0800, cama...@picnicpark.org wrote:
>> From: Keith Amidon
>>
>> As an alternative to creating a reply from the current thread, this
>> commit provides functions to
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 an
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
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 function:
{-- 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. :-)
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 would
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 would
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 happ
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 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
Does
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 (
This thread inspired me to look a little more deeply into the address
completion issues I've been having since switching to corfu as well. It
was a rather long and twisted journey but I ended up getting completion
using corfu working with the following in my init file:
;; Make corfu-based a
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
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 handle
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,
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 orig
42 matches
Mail list logo
