email to PDF
Hi, Although we're in the 21 century, there are occasions where one has to turn emails into PDF. What's your solution to do so? I found muttprint, but that doesn't print utf-8 emails as they are all base64 encoded and muttprint doesn't decode that before printing. Thanks, Sebastian ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Debugging slow down over time
I can confirm that after calling (garbage-collect) the search is responsive again. Then I remembered that my init.el changes the gc-cons-threshold speed up the launch. Guess that wasn't a good idea. Sebastian Dan Čermák writes: > Hi Sebastian, > > Sebastian Fischmeister writes: > >> Hi, >> >> For some time already I experience a slowdown of the emacs notmuch interface >> over time. After using emacs with notmuch for a day or two, loading the >> inbox tree view (a search on tag:inbox) takes a significant amount of time >> to build the view. When I quite and restart emacs, the view loads instantly >> again. >> >> Do you have any suggestions on how to debug this issue other than >> removing all customizations? > > Unfortunately no, but I have observed this issue as well. What sometimes > appeared to help is to manually trigger a garbage collection. > > I must admit that I have not suffered from this recently though and it > might have disappeared when I added > --8<---cut here---start->8--- > (setq helm-ff-keep-cached-candidates nil) > --8<---cut here---end--->8--- > to my init.el to work around https://issues.guix.gnu.org/43406 > > In case you are using helm, you could give that a try. > > > Cheers, > > Dan ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Debugging slow down over time
Hi, For some time already I experience a slowdown of the emacs notmuch interface over time. After using emacs with notmuch for a day or two, loading the inbox tree view (a search on tag:inbox) takes a significant amount of time to build the view. When I quite and restart emacs, the view loads instantly again. Do you have any suggestions on how to debug this issue other than removing all customizations? Cheers, Sebastian ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Segmentation fault on tagging with latest xapian 1.4.13
Hello,
Notmuch crashes with xapian-core-1:1.4.13. Everything works fine with
xapian-core-1:1.4.12-1
When running the command:
notmuch tag +me -- tag:new and to:sfisc...@uwaterloo.ca
Notmuch crashes with a segmentation fault.
Here is the essence of the core dump and the local variables when running the
git version 7eb9615b30274033cc0c828244569c709906c40b from Sep 15.
$ gdb notmuch
(gdb) run tag +me -- tag:new and to:sfisc...@uwaterloo.ca
(gdb) where
#0 0x7f2a74a73ee4 in () at /usr/lib/libxapian.so.30
#1 0x7f2a74a776fe in () at /usr/lib/libxapian.so.30
#2 0x7f2a74a7e0a2 in () at /usr/lib/libxapian.so.30
#3 0x7f2a7499d1f8 in Xapian::Enquire::Internal::get_mset(unsigned int,
unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*)
const () at /usr/lib/libxapian.so.30
#4 0x7f2a7499d466 in Xapian::Enquire::get_mset(unsigned int, unsigned int,
unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const ()
at /usr/lib/libxapian.so.30
#5 0x559bef805a1f in _notmuch_query_search_documents(notmuch_query_t*,
char const*, notmuch_messages_t**)
(query=0x559bf14e6c60, type=, out=0x7ffe19dcb8b0) at
lib/query.cc:346
#6 0x559bef7f5818 in tag_query
(ctx=ctx@entry=0x559bf14dfb70, notmuch=notmuch@entry=0x559bf14e6e60,
query_string=0x559bf153c170 "( tag:new and to:sfisc...@uwaterloo.ca ) and (not
tag:me)", tag_ops=tag_ops@entry=0x559bf14e2e40, flags=(TAG_FLAG_MAILDIR_SYNC |
TAG_FLAG_PRE_OPTIMIZED), flags@entry=TAG_FLAG_MAILDIR_SYNC) at notmuch-tag.c:124
#7 0x559bef7f5d82 in notmuch_tag_command (config=0x559bf14dfb70,
argc=, argv=0x7ffe19dcbe80) at notmuch-tag.c:279
#8 0x559bef7e6517 in main (argc=7, argv=0x7ffe19dcbe78) at notmuch.c:505
(gdb) up # to the first notmuch level
#5 0x55584a1f in _notmuch_query_search_documents
(query=0x555d4c60, type=, out=0x7fffd9a0) at
lib/query.cc:346
346 mset = enquire.get_mset (0, notmuch->xapian_db->get_doccount
());
(gdb) info locals
enquire = {internal = {px = 0x555b}, static INCLUDE_QUERY_TERMS = 1,
static USE_EXACT_TERMFREQ = 2}
mail_query = {internal = {px = 0x5562a270}, static MatchNothing = {internal
= {px = 0x0},
static MatchNothing = ,
static MatchAll = {internal = {px = 0x555ae4e0},
static MatchNothing = ,
static MatchAll = }},
static MatchAll = }
final_query = {internal = {px = 0x5562a7b0}, static MatchNothing =
{internal = {px = 0x0},
static MatchNothing = ,
static MatchAll = {internal = {px = 0x555ae4e0},
static MatchNothing = ,
static MatchAll = }},
static MatchAll = }
exclude_query = {internal = {px = 0x0}, static MatchNothing = {internal = {px =
0x0}, static MatchNothing = ,
static MatchAll = {internal = {px = 0x555ae4e0}, static MatchNothing =
,
static MatchAll = }},
static MatchAll = }
iterator = {mset = {internal = {px = 0x555acf50}}, off_from_end = 0}
mset = {internal = {px = 0x555ad060}}
notmuch = 0x555d4e60
query_string =
messages = 0x5562a840
status = NOTMUCH_STATUS_SUCCESS
Do you need more information?
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Filtering completions
Hi, Is there a variable defining a regex to filter harvested completions before showing them? My completions include some outdated or invalid email addresses for people and I would like to automatically remove them from the list. I didn't find something for that in notmuch-address.el, and for instance notmuch-address-matching. Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Sync mail deletion with Notmuch + mbsync for gmail
>
> cmd_personal = io.popen('gpg2 -q --for-your-eyes-only --no-tty -d
> ~/docs/enc/cred/aaermo...@gmail.com.gpg', 'r')
> out_personal = cmd_personal:read('*a')
> pass_personal = string.gsub(out_personal, '[\n\r]+', '')
>
> account_personal = IMAP {
> server = 'imap.gmail.com',
> username = 'aaermo...@gmail.com',
> password = pass_personal,
> ssl = 'ssl3'
> }
>
> trash_personal = account_personal['[Gmail]/Trash']:is_undeleted()
> account_personal['[Gmail]/Trash']:delete_messages(trash_personal)
>
> spam_personal = account_personal['[Gmail]/Spam']:is_unanswered()
> account_personal['[Gmail]/Spam']:delete_messages(spam_personal)
> =
>
> Cheers, Alex
>
> PS Sorry for double posting, have forgot all recepients the first time.
>
> Sebastian Fischmeister <sfisc...@uwaterloo.ca> writes:
>
>> Hi,
>>
>> I use mbsync + notmuch to sync my gmail. The problem is that Google's
>> IMAP implementation is non-standard and when I deleted a file locally,
>> mbsync propagates the deletion, but gmail doesn't delete the
>> message.
>>
>> This is part of mbsync:
>>
>> SyncState *
>> Sync All
>> Expunge Both
>> Create Both
>>
>> When I delete a message, the macro passes the tag 'delete'. Before
>> syncing, the script runs:
>>
>> notmuch search --output=files tag:delete | xargs -l rm
>>
>> By playing with the IMAP settings in gmail, I got it so that the mail
>> vanishes from the 'inbox' label, but it's still in 'All Mails'. I also
>> tried moving it to a "[GMail]/Trash" folder locally and syncing that,
>> but it didn't work.
>>
>> Any ideas?
>>
>> Sebastian
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Sync mail deletion with Notmuch + mbsync for gmail
Hi, I use mbsync + notmuch to sync my gmail. The problem is that Google's IMAP implementation is non-standard and when I deleted a file locally, mbsync propagates the deletion, but gmail doesn't delete the message. This is part of mbsync: SyncState * Sync All Expunge Both Create Both When I delete a message, the macro passes the tag 'delete'. Before syncing, the script runs: notmuch search --output=files tag:delete | xargs -l rm By playing with the IMAP settings in gmail, I got it so that the mail vanishes from the 'inbox' label, but it's still in 'All Mails'. I also tried moving it to a "[GMail]/Trash" folder locally and syncing that, but it didn't work. Any ideas? Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: searching: '*analysis' vs 'reanalysis'
>> It is not possible to use wildcards at the beginning of a term. > > after the current explanation to emphasize this limitation (possibly > blaming Xapian to avoid futile requests). > > I think it is something many would expect (and want). The current > description feels more like an example, and it is easy to make the > assumption that it works for prefixing the terms as well - although, > technically, nothing is promised in the original docs. I ran into this problem before as well. Storage is cheap. Notmuch could index all emails with reversed text to get around some of this problem. It doesn't solve the problem of *analysis*, but it's still an improvement. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
notmuch-address-command questions
Hi, I'm trying out the internal expansion for notmuch-address-command. One thing I immediately notice is that it has lag over 250K emails, since it's lookup up addresses each time. Scripts like nottoomuch-addresses have cached results of only all email addresses and have instantaneous response. The second thing is that it seems to list any email it finds. However, I don't care about email addresses found in emails from 10 years ago. I only care about the last two years. Maybe the lag can be addressed by addressing the time horizon for the search: Is it possible to limit the email address search to the last two years? I currently do this in searches by automatically inserting "date:2y..now " in the search field for normal email searches. Thanks. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: message-default-mail-headers not working in notmuch 0.22
I can confirm that this fixes the problem. Thanks for the quick reply! Sebastian David Edmondson <d...@dme.org> writes: > On Fri, Apr 29 2016, Sebastian Fischmeister wrote: >> After upgrading to notmuch 0.22, my emacs config seems broken: >> >> (setq message-default-mail-headers "Reply-to: m...@example.com\nBcc: >> m...@example.com") >> >> When creating a new mail, it has no header other than "To:" and >> "Subject:". >> >> Since I cannot find any item in the NEWS related to this release, is >> this expected behaviour? > > No, it's not intended. Please try this patch: > > diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el > index 0445975..399e138 100644 > --- a/emacs/notmuch-mua.el > +++ b/emacs/notmuch-mua.el > @@ -338,7 +338,10 @@ modified. This function is notmuch addaptation of > ;; We need to convert any string input, eg from rmail-start-mail. > (dolist (h other-headers other-headers) > (if (stringp (car h)) (setcar h (intern (capitalize (car h > - (args (list yank-action send-actions))) > + (args (list yank-action send-actions)) > + ;; Cause `message-setup-1' to do things relevant for mail, > + ;; such as observe `message-default-mail-headers'. > + (message-this-is-mail t)) > ;; message-setup-1 in Emacs 23 does not accept return-action > ;; argument. Pass it only if it is supplied by the caller. This > ;; will never be the case when we're called by `compose-mail' in ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
message-default-mail-headers not working in notmuch 0.22
Hi, After upgrading to notmuch 0.22, my emacs config seems broken: (setq message-default-mail-headers "Reply-to: m...@example.com\nBcc: m...@example.com") When creating a new mail, it has no header other than "To:" and "Subject:". Since I cannot find any item in the NEWS related to this release, is this expected behaviour? Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Search mail from people with different addresses and incorrectly configured clients
Hi, Sometimes, people's mail clients are configured incorrectly and do not show the sender name. Often the same person uses different email addresses. Sometimes they use different names for their alternate email addresses. When I search for an email originated from a specific person, I want the search to cover all messages that match the different criteria mentioned above. Has anyone found a good way to use tags to aggregate emails from the same person? Will it have some disadvantages? It sounds straightforward, but the management of this would be quite an effort. The alternative is to create long search strings that encompass all email addresses of the person. This has less management effort, but I would need to somewhere store all email addresses associated with a person. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Mail merge with notmuch
Hi, Is there a straightforward way to for mail merge with notmuch? I need to send emails with only minor modifications to a number of people. If I could send mails from the command line, then that would be perfect. Any ideas? Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Resending the same email
Hi, My previous mail editor had a useful feature to resend already sent emails. It's essentially opening an already sent email and have the senders, subject, and body pre-filled as well as all attachments attached. Is this easy to achieve in notmuch? The attachments seem a bit tricky. Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] custom search prefix
--- emacs/notmuch.el | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ab00454..c9cd31a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -851,6 +851,12 @@ See `notmuch-tag' for information on the format of TAG-CHANGES." (concat "*notmuch-search-" query "*")) ))) +(defcustom notmuch-query-prefix nil + "Add a prefix to the standard query." + :type 'string + :group 'notmuch-search) + + (defun notmuch-read-query (prompt) "Read a notmuch-query from the minibuffer with completion. @@ -883,7 +889,7 @@ PROMPT is the string to prompt with." ;; this was simpler than convincing completing-read to accept spaces: (define-key keymap (kbd "TAB") 'minibuffer-complete) (let ((history-delete-duplicates t)) - (read-from-minibuffer prompt nil keymap nil + (read-from-minibuffer prompt notmuch-query-prefix keymap nil 'notmuch-search-history current-query nil) (defun notmuch-search-get-query () -- 2.3.5
[PATCH] custom search prefix
Hi, I found this handy to provide a specific prefix for searches. For example, when you always want to search only the last 2 years of emails, then you can set the variable notmuch-query-prefix to "date:2y..now ". Sebastian Sebastian Fischmeister (1): custom prefix emacs/notmuch.el | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.3.5
[PATCH] custom search prefix
--- emacs/notmuch.el | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ab00454..c9cd31a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -851,6 +851,12 @@ See `notmuch-tag' for information on the format of TAG-CHANGES. (concat *notmuch-search- query *)) ))) +(defcustom notmuch-query-prefix nil + Add a prefix to the standard query. + :type 'string + :group 'notmuch-search) + + (defun notmuch-read-query (prompt) Read a notmuch-query from the minibuffer with completion. @@ -883,7 +889,7 @@ PROMPT is the string to prompt with. ;; this was simpler than convincing completing-read to accept spaces: (define-key keymap (kbd TAB) 'minibuffer-complete) (let ((history-delete-duplicates t)) - (read-from-minibuffer prompt nil keymap nil + (read-from-minibuffer prompt notmuch-query-prefix keymap nil 'notmuch-search-history current-query nil) (defun notmuch-search-get-query () -- 2.3.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] custom search prefix
Hi, I found this handy to provide a specific prefix for searches. For example, when you always want to search only the last 2 years of emails, then you can set the variable notmuch-query-prefix to date:2y..now . Sebastian Sebastian Fischmeister (1): custom prefix emacs/notmuch.el | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.3.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
UnicodeDecodeError with python API
> My first guess is that the file's encoding doesn't match your locale. > Do you have a non-ASCII locale set? You can check with: It seems to be more tricky than I thought. I didn't have a locale set. When I set one, I can parse some emails with this: export LANG=en_US.latin-1 Others with this: export LANG=en_US.UTF-8 Others fail with either of the two. I can display all messages correctly in emacs though. Sebastian
UnicodeDecodeError with python API
Hi, I'm trying to use the python API for notmuch, and get the following error: --- Traceback (most recent call last): File "./test.py", line 66, in print(type(y.get_part(1))) File "/usr/lib/python3.4/site-packages/notmuch/message.py", line 602, in get_part parts = self.get_message_parts() File "/usr/lib/python3.4/site-packages/notmuch/message.py", line 591, in get_message_parts email_msg = email.message_from_file(fp) File "/usr/lib/python3.4/email/__init__.py", line 56, in message_from_file return Parser(*args, **kws).parse(fp) File "/usr/lib/python3.4/email/parser.py", line 54, in parse data = fp.read(8192) File "/usr/lib/python3.4/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3447: ordinal not in range(128) --- The code works for most messages though. How can I get around this problem? Is it a problem in my code or the binding? I'm using notmuch 0.19 with python 3.4.3. Thanks, Sebastian
UnicodeDecodeError with python API
Hi, I'm trying to use the python API for notmuch, and get the following error: --- Traceback (most recent call last): File ./test.py, line 66, in module print(type(y.get_part(1))) File /usr/lib/python3.4/site-packages/notmuch/message.py, line 602, in get_part parts = self.get_message_parts() File /usr/lib/python3.4/site-packages/notmuch/message.py, line 591, in get_message_parts email_msg = email.message_from_file(fp) File /usr/lib/python3.4/email/__init__.py, line 56, in message_from_file return Parser(*args, **kws).parse(fp) File /usr/lib/python3.4/email/parser.py, line 54, in parse data = fp.read(8192) File /usr/lib/python3.4/encodings/ascii.py, line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3447: ordinal not in range(128) --- The code works for most messages though. How can I get around this problem? Is it a problem in my code or the binding? I'm using notmuch 0.19 with python 3.4.3. Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: UnicodeDecodeError with python API
My first guess is that the file's encoding doesn't match your locale. Do you have a non-ASCII locale set? You can check with: It seems to be more tricky than I thought. I didn't have a locale set. When I set one, I can parse some emails with this: export LANG=en_US.latin-1 Others with this: export LANG=en_US.UTF-8 Others fail with either of the two. I can display all messages correctly in emacs though. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
strange search behaviour in emacs
> I suspect this is related to asynch loading. The first query is still > filling into the buffer, and emacs doesn't starting filling the second > buffer until the first search finishes. In my experiments it > _eventually_ does the second query. You are correct. I confirm that the second query eventually gets executed. > It just takes a while. I agree it would be nice if there was some UI > hint before the first result arrives. Yes, a simple update in the statusbar for the mode name would be a possible approach. Sebastian
strange search behaviour in emacs
Hi, I have some strange behaviour when performing searches on notmuch in emacs. The following works just fine: M-: (notmuch-search "from:foo") ;;not me M-: (notmuch-search "bar") The following *always* returns an empty list, even when I see an email with "bar" right there in the list after the first search: M-: (notmuch-search "from:sfischme") ;;me M-: (notmuch-search "bar") It appears to only occur when the "from:XY" search was for what I have set in my notmuch config for the primary_email address. I have no clue why this is happening. Any ideas? Especially, any ideas how to fix it? I'm using notmuch 0.19 (package 0.19-2 on archlinux). Thanks, Sebastian
Re: strange search behaviour in emacs
I suspect this is related to asynch loading. The first query is still filling into the buffer, and emacs doesn't starting filling the second buffer until the first search finishes. In my experiments it _eventually_ does the second query. You are correct. I confirm that the second query eventually gets executed. It just takes a while. I agree it would be nice if there was some UI hint before the first result arrives. Yes, a simple update in the statusbar for the mode name would be a possible approach. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
strange search behaviour in emacs
Hi, I have some strange behaviour when performing searches on notmuch in emacs. The following works just fine: M-: (notmuch-search from:foo) ;;not me M-: (notmuch-search bar) The following *always* returns an empty list, even when I see an email with bar right there in the list after the first search: M-: (notmuch-search from:sfischme) ;;me M-: (notmuch-search bar) It appears to only occur when the from:XY search was for what I have set in my notmuch config for the primary_email address. I have no clue why this is happening. Any ideas? Especially, any ideas how to fix it? I'm using notmuch 0.19 (package 0.19-2 on archlinux). Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Undo function or history log
Hi, I very much appreciate the ability to have simple shortcuts set tags, refresh the view, etc. Unfortunately, sometimes, things happen accidentally --- think of the cat walking on the keyboard --- and consequently somethings might get lost due to wrong tags. Does anyone have a good solution for an undo function for setting or deleting tags? Sebastian
Undo function or history log
Hi, I very much appreciate the ability to have simple shortcuts set tags, refresh the view, etc. Unfortunately, sometimes, things happen accidentally --- think of the cat walking on the keyboard --- and consequently somethings might get lost due to wrong tags. Does anyone have a good solution for an undo function for setting or deleting tags? Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Images being displayed inline depending on the window size
Hi, I have an email with 8 pictures attached. When I open the email (notmuch-search-show-thread), some of them are opened and shown inline, others are not. It seems that notmuch only shows the ones that fit on the screen depending on how much space emacs has. E.g., the ones with a size of 800x600 are usually displayed in full-screen mode but not the ones with 600x800. Is there a way to control this behaviour? Sebastian
Images being displayed inline depending on the window size
Hi, I have an email with 8 pictures attached. When I open the email (notmuch-search-show-thread), some of them are opened and shown inline, others are not. It seems that notmuch only shows the ones that fit on the screen depending on how much space emacs has. E.g., the ones with a size of 800x600 are usually displayed in full-screen mode but not the ones with 600x800. Is there a way to control this behaviour? Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
email snoozing in notmuch
Hi Richard,
Thanks for the nice and simple solution. I prefer this one to a solution
like notmuch-snooze that stores the desnoozing in an external program
and thus complicates backups.
Sebastian
Richard Lawrence writes:
> Franz Fellner
> writes:
>
>> Sebastian Fischmeister wrote:
>
>>> I'm thinking of how to realize the mail snoozing feature with notmuch,
>>> so that certain emails won't become visible (in the search) until a
>>> certain day/time (e.g., 10 days from now).
>>>
>>> Using the tag as an absolute date when the mail should become visible
>>> again, tags should be searchable and interpretable as dates. The search
>>> would then be something like: notmuch search tag-as-date < now and
>>> tag:inbox
>>
>> It is not neccessary to make notmuch interpret tags as date - just interpret
>> them yourself ;)
>> You can easily run your own scripts and modify tags/mails. So a simple
>> solution might be:
>> * Add "snoozed" to your notmuch exclude_tags (see config file)
>> * To snooze a mail run in your mail client "tag +snoozed +snoozeby-10-days"
>> or "tag +snoozed +snoozeuntil-2015-01-09"
>> * Your script (e.g. run as cronjob or after notmuch new) now
>> - queries for "tag:snoozed"
>> - looks for snoozeuntil-* tag and parses the tag into a date. If date <
>> now remove snooze-tags.
>> - looks for (relative) snoozeby tag and transform it into (absolute)
>> snoozeuntil tag.
>> (should be not too hard using e.g. the python or ruby bindings)
>
> I actually do something like this. It's not everything Sebastian was
> looking for, but it's very simple, and works great for me.
>
> I use a combination of a "pending" tag and a "byMMDD" tag.
>
> From cron, I run the following to refile pending mail back to the inbox
> when it comes due:
>
> #!/bin/bash
> DATE_STR=$(date +'%Y%m%d')
> notmuch tag +inbox -pending -by$DATE_STR -- tag:by$DATE_STR
>
> and in Emacs, I use the following key binding to snooze mail (or in the Mutt
> terminology I borrowed, `postpone' it, hence the key):
>
> (define-key notmuch-search-mode-map "P"
> (lambda ()
> "postpone message (remove inbox tag, add pending tag and refile date)"
> (interactive)
> (let* ((date-string (format-time-string "%Y%m%d" (org-read-date nil t)))
> (date-tag (concat "+by" date-string)))
> (notmuch-search-tag `("-inbox" "+pending" ,date-tag)
>
> (The `org-read-date' function gives me a nice easy way to pick a date
> from a calendar. I bind "P" to the same function in
> notmuch-show-mode-map, too.)
>
> Hope that helps!
>
> Best,
> Richard
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Re: email snoozing in notmuch
Hi Richard, Thanks for the nice and simple solution. I prefer this one to a solution like notmuch-snooze that stores the desnoozing in an external program and thus complicates backups. Sebastian Richard Lawrence richard.lawre...@berkeley.edu writes: Franz Fellner alpine.art...@gmail.com writes: Sebastian Fischmeister wrote: I'm thinking of how to realize the mail snoozing feature with notmuch, so that certain emails won't become visible (in the search) until a certain day/time (e.g., 10 days from now). Using the tag as an absolute date when the mail should become visible again, tags should be searchable and interpretable as dates. The search would then be something like: notmuch search tag-as-date now and tag:inbox It is not neccessary to make notmuch interpret tags as date - just interpret them yourself ;) You can easily run your own scripts and modify tags/mails. So a simple solution might be: * Add snoozed to your notmuch exclude_tags (see config file) * To snooze a mail run in your mail client tag +snoozed +snoozeby-10-days or tag +snoozed +snoozeuntil-2015-01-09 * Your script (e.g. run as cronjob or after notmuch new) now - queries for tag:snoozed - looks for snoozeuntil-* tag and parses the tag into a date. If date now remove snooze-tags. - looks for (relative) snoozeby tag and transform it into (absolute) snoozeuntil tag. (should be not too hard using e.g. the python or ruby bindings) I actually do something like this. It's not everything Sebastian was looking for, but it's very simple, and works great for me. I use a combination of a pending tag and a byMMDD tag. From cron, I run the following to refile pending mail back to the inbox when it comes due: #!/bin/bash DATE_STR=$(date +'%Y%m%d') notmuch tag +inbox -pending -by$DATE_STR -- tag:by$DATE_STR and in Emacs, I use the following key binding to snooze mail (or in the Mutt terminology I borrowed, `postpone' it, hence the key): (define-key notmuch-search-mode-map P (lambda () postpone message (remove inbox tag, add pending tag and refile date) (interactive) (let* ((date-string (format-time-string %Y%m%d (org-read-date nil t))) (date-tag (concat +by date-string))) (notmuch-search-tag `(-inbox +pending ,date-tag) (The `org-read-date' function gives me a nice easy way to pick a date from a calendar. I bind P to the same function in notmuch-show-mode-map, too.) Hope that helps! Best, Richard ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
email snoozing in notmuch
Hi, I'm thinking of how to realize the mail snoozing feature with notmuch, so that certain emails won't become visible (in the search) until a certain day/time (e.g., 10 days from now). Using the tag as an absolute date when the mail should become visible again, tags should be searchable and interpretable as dates. The search would then be something like: notmuch search tag-as-date < now and tag:inbox Using the receive date as base and encoding the delay as relative time from that, would still need the ability to interpret tag values as numbers: notmuch search date:01012011..15days and tag-as-number < 10 and tag:inbox Any ideas how the snoozing feature can be implemented with what is already present in notmuch? Thanks, Sebastian
email snoozing in notmuch
Hi, I'm thinking of how to realize the mail snoozing feature with notmuch, so that certain emails won't become visible (in the search) until a certain day/time (e.g., 10 days from now). Using the tag as an absolute date when the mail should become visible again, tags should be searchable and interpretable as dates. The search would then be something like: notmuch search tag-as-date now and tag:inbox Using the receive date as base and encoding the delay as relative time from that, would still need the ability to interpret tag values as numbers: notmuch search date:01012011..15days and tag-as-number 10 and tag:inbox Any ideas how the snoozing feature can be implemented with what is already present in notmuch? Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Better support for helm in the address completion
> (setq notmuch-address-selection-function > (lambda (prompt collection initial-input) > (completing-read prompt (cons initial-input collection) nil t nil > 'notmuch-address-history))) > > there (or use customize to do that (?)). That's perfectly fine as well, and even simpler to use. Maybe adding this to the emacstips page [1] under "Address completion when composing" would be a good idea. Sebastian PS: http://notmuchmail.org/emacstips/
Re: Better support for helm in the address completion
(setq notmuch-address-selection-function (lambda (prompt collection initial-input) (completing-read prompt (cons initial-input collection) nil t nil 'notmuch-address-history))) there (or use customize to do that (?)). That's perfectly fine as well, and even simpler to use. Maybe adding this to the emacstips page [1] under Address completion when composing would be a good idea. Sebastian PS: http://notmuchmail.org/emacstips/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Better support for helm in the address completion
Hi,
I noticed that the completing-read in notmuch-address-selection-function
was eating the first returned address when using helm. Here's a patch
that fixes it. The defaults are as they used to be.
For helm use:
(setq notmuch-address-suggest-initial-match nil)
If you don't want to enter a new address in the selection (with helm)
use:
(setq notmuch-address-require-match t)
Sebastian
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index fa65cd5..d9b66cd 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -42,11 +42,25 @@ to know how address selection is made by default."
:group 'notmuch-send
:group 'notmuch-external)
+(defcustom notmuch-address-suggest-initial-match t
+ "Pass an initial match to the address completing read."
+ :type 'boolean
+ :group 'notmuch-send)
+
+(defcustom notmuch-address-require-match nil
+ "Require a match in the address selection in
`notmuch-address-selection-function'."
+ :type 'boolean
+ :group 'notmuch-send)
+
(defun notmuch-address-selection-function (prompt collection initial-input)
"Call (`completing-read'
PROMPT COLLECTION nil nil INITIAL-INPUT 'notmuch-address-history)"
(completing-read
- prompt collection nil nil initial-input 'notmuch-address-history))
+ prompt
+ (if notmuch-address-suggest-initial-match 'collection (list initial-input
collection))
+ nil notmuch-address-require-match
+ (if notmuch-address-suggest-initial-match 'initial-input nil)
+ 'notmuch-address-history))
(defvar notmuch-address-message-alist-member
'("^\\(Resent-\\)?\\(To\\|B?Cc\\|Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):"
Better support for helm in the address completion
Hi, I noticed that the completing-read in notmuch-address-selection-function was eating the first returned address when using helm. Here's a patch that fixes it. The defaults are as they used to be. For helm use: (setq notmuch-address-suggest-initial-match nil) If you don't want to enter a new address in the selection (with helm) use: (setq notmuch-address-require-match t) Sebastian diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index fa65cd5..d9b66cd 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -42,11 +42,25 @@ to know how address selection is made by default. :group 'notmuch-send :group 'notmuch-external) +(defcustom notmuch-address-suggest-initial-match t + Pass an initial match to the address completing read. + :type 'boolean + :group 'notmuch-send) + +(defcustom notmuch-address-require-match nil + Require a match in the address selection in `notmuch-address-selection-function'. + :type 'boolean + :group 'notmuch-send) + (defun notmuch-address-selection-function (prompt collection initial-input) Call (`completing-read' PROMPT COLLECTION nil nil INITIAL-INPUT 'notmuch-address-history) (completing-read - prompt collection nil nil initial-input 'notmuch-address-history)) + prompt + (if notmuch-address-suggest-initial-match 'collection (list initial-input collection)) + nil notmuch-address-require-match + (if notmuch-address-suggest-initial-match 'initial-input nil) + 'notmuch-address-history)) (defvar notmuch-address-message-alist-member '(^\\(Resent-\\)?\\(To\\|B?Cc\\|Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\): ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
SVG attachment crashes emacs
Here's the svg image. It seems that the problem is with emacs calling inkscape. Inkscape then does something that causes emacs to crash. I don't know why emacs calls inkscape when I open the message with the svg file. I can directly open the svg file in emacs and it's displayed correctly. Sebastian -- next part -- A non-text attachment was scrubbed... Name: severity.svg Type: image/svg+xml Size: 5227 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140820/3e8efd6e/attachment.svg> -- next part -- MaDhAt2r writes: > I am on arch, you could send me the sample image and I will see if it > works on my end. > > On Aug 18 at 08:27 PM, David Bremner scrawled: >> Sebastian Fischmeister writes: >> >>> GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of >>> 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc >>> >>> ~$ notmuch --version >>> notmuch 0.18.1 >>> >>> What happens is that emacs invokes inkscape to do something to the svg. >>> >> >> I wonder if this is specific to the way emacs is compiled on arch. I >> just deleted inkscape and the image you sent me still renders fine on >> Debian testing, same emacs and notmuch version. >> >> Out of curiousity, is your emacs linked to libxml2? >> >> It could also be something to do with mime type configuration, which is >> a bit of an impenetrable thicket to me. >> >> d >> ___ >> notmuch mailing list >> notmuch at notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch
Re: SVG attachment crashes emacs
Here's the svg image. It seems that the problem is with emacs calling inkscape. Inkscape then does something that causes emacs to crash. I don't know why emacs calls inkscape when I open the message with the svg file. I can directly open the svg file in emacs and it's displayed correctly. Sebastian MaDhAt2r madha...@dukefoo.com writes: I am on arch, you could send me the sample image and I will see if it works on my end. On Aug 18 at 08:27 PM, David Bremner scrawled: Sebastian Fischmeister sfisc...@uwaterloo.ca writes: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc ~$ notmuch --version notmuch 0.18.1 What happens is that emacs invokes inkscape to do something to the svg. I wonder if this is specific to the way emacs is compiled on arch. I just deleted inkscape and the image you sent me still renders fine on Debian testing, same emacs and notmuch version. Out of curiousity, is your emacs linked to libxml2? It could also be something to do with mime type configuration, which is a bit of an impenetrable thicket to me. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
SVG attachment crashes emacs
GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc ~$ notmuch --version notmuch 0.18.1 What happens is that emacs invokes inkscape to do something to the svg. Sebastian David Bremner writes: > Sebastian Fischmeister writes: > >> For example, the attached svg file causes a crash. >> >> Sebastian >> > > It displays ok for me. What version of emacs are you using? > > d
Re: SVG attachment crashes emacs
GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc ~$ notmuch --version notmuch 0.18.1 What happens is that emacs invokes inkscape to do something to the svg. Sebastian David Bremner da...@tethera.net writes: Sebastian Fischmeister sfisc...@uwaterloo.ca writes: For example, the attached svg file causes a crash. Sebastian It displays ok for me. What version of emacs are you using? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
SVG attachment crashes emacs
Hi, When I receive an SVG attachment, it first makes emacs freeze and then crash. It might not be a problem of notmuch but a helper application, but I don't know how to debug it; so maybe someone here can help me. Any ideas? Btw. it seems that the general problem is the the message mode tries to process attachments. For example when I receive a large .tgz file, the message mode in notmuch tries to decompress and parse the file, which may take a while. Thanks, Sebastian
SVG attachment crashes emacs
Hi, When I receive an SVG attachment, it first makes emacs freeze and then crash. It might not be a problem of notmuch but a helper application, but I don't know how to debug it; so maybe someone here can help me. Any ideas? Btw. it seems that the general problem is the the message mode tries to process attachments. For example when I receive a large .tgz file, the message mode in notmuch tries to decompress and parse the file, which may take a while. Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Log of tagging actions
> I use a C wrapper to do the same (with date prefixes like 2014-05-09 > (Fri) 12:47:19) -- I originally did it to do argument conversions > around .. to have date-based searches before those came to notmuch > (and I am still using it, as I don't have to type date: prefix) Having a wrapper script possible, however, it is quite a hack and doesn't potentially collect everything. There's already a .notmuch-config file, so adding a logging directive should be straightforward. It's more about whether something like this becomes part of notmuch directly. >> Would be nice to be able to log all operations done via libnotmuch >> too though. > > IIRC someone suggested/asked whether we'd get logs where all > Message-ID:s affected were logged. That could be useful (and produce > lot of log when one does notmuch tag +foobar '*') I'm not worried about the size of the logfiles. Drives are large and many utilities exist to create a rolling removal and compression of log files. Sebastian
Re: Log of tagging actions
I use a C wrapper to do the same (with date prefixes like 2014-05-09 (Fri) 12:47:19) -- I originally did it to do argument conversions around .. to have date-based searches before those came to notmuch (and I am still using it, as I don't have to type date: prefix) Having a wrapper script possible, however, it is quite a hack and doesn't potentially collect everything. There's already a .notmuch-config file, so adding a logging directive should be straightforward. It's more about whether something like this becomes part of notmuch directly. Would be nice to be able to log all operations done via libnotmuch too though. IIRC someone suggested/asked whether we'd get logs where all Message-ID:s affected were logged. That could be useful (and produce lot of log when one does notmuch tag +foobar '*') I'm not worried about the size of the logfiles. Drives are large and many utilities exist to create a rolling removal and compression of log files. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Log of tagging actions
Hi, The amazing thing about the notmuch emacs interface is that with just a couple of keystrokes you can quickly manipulate a lot of emails and thus be very efficient. The big disadvantage is that with just a couple of keystrokes you can manipulate a lot of emails and thus quickly completely mess up your emails. Just think about the scenario of a cat wandering across your keyboard. Is there a possibility to log all tagging actions done in notmuch? Something like: timestamp, msgid, old set of tags new set of tags It would be helpful for restoring things in case something went wrong, and it could be the start of an undo function. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ido address lookup for notmuch
Hi,
This is a function that I find really useful. I adapted it a bit based
on the original from Jacek Generowicz. Maybe others will find it helpful
as well.
Sebastian
;; original
https://groups.google.com/group/mu-discuss/browse_thread/thread/551b7a6487a0aeb3
(setq notmuch-compose-complete-ignore-address-regexp (regexp-opt '("failed" "DO
NOT REPLY" "donotreply" "no-reply" "noreply" "Google Drive")))
(defun jmg/ido-select-recipient ()
"Inserts a contact from the addrlookup cache.
Uses ido to select the contact from all those present in the database."
(interactive)
(insert
(ido-completing-read
"Recipient: "
(mapcar (lambda (contact-string)
(let* ((data (split-string contact-string " "))
(address (car data))
(name (when (> (length (cadr data)) 0) (cadr data)))
)
(if name
(format "%s <%s>" name address)
address)))
(remove-if (lambda (string) (string-match
notmuch-compose-complete-ignore-address-regexp string))
(remove-if (lambda (string) (= 0 (length string)))
(split-string (shell-command-to-string
(concat "addrlookup " (thing-at-point 'word) )) "\n")))
ido address lookup for notmuch
Hi, This is a function that I find really useful. I adapted it a bit based on the original from Jacek Generowicz. Maybe others will find it helpful as well. Sebastian ;; original https://groups.google.com/group/mu-discuss/browse_thread/thread/551b7a6487a0aeb3 (setq notmuch-compose-complete-ignore-address-regexp (regexp-opt '(failed DO NOT REPLY donotreply no-reply noreply Google Drive))) (defun jmg/ido-select-recipient () Inserts a contact from the addrlookup cache. Uses ido to select the contact from all those present in the database. (interactive) (insert (ido-completing-read Recipient: (mapcar (lambda (contact-string) (let* ((data (split-string contact-string)) (address (car data)) (name (when ( (length (cadr data)) 0) (cadr data))) ) (if name (format %s %s name address) address))) (remove-if (lambda (string) (string-match notmuch-compose-complete-ignore-address-regexp string)) (remove-if (lambda (string) (= 0 (length string))) (split-string (shell-command-to-string (concat addrlookup (thing-at-point 'word) )) \n))) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
