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 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
Does
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 happ
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:
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
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
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
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
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 wrote:
> >
> > I was able to make this work by setting notmuch-fcc-dirs to:
> >
> > "\"[Gmail]/Sent Mail\" +sent -inbox -unread"
>
> That is correc
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, 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
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
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 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,
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
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 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
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 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
{-- 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 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. :-)
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:
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
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
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:
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
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
{-- 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
{-- 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
{-- 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
{-- 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: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
{-- 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, 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: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 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 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
42 matches
Mail list logo
