Am Sa., 25. Mai 2024 um 12:06 Uhr schrieb David Bremner :
>
> Teemu Likonen writes:
>
> >
> >> Perhaps the manual page needs a few more words to make it clear.
> >
> > --offset=[-]N
> > Skip displaying the first N results. With the leading '-',
> > start at the Nth
Teemu Likonen writes:
>
>> Perhaps the manual page needs a few more words to make it clear.
>
> --offset=[-]N
> Skip displaying the first N results. With the leading '-',
> start at the Nth result from the end.
>
> What if we change the first sentence to "Skip
* 2024-05-20 21:24:01+0300, Teemu Likonen wrote:
> It doesn't seem clear how offset is counted on command like
>
> notmuch search --output=files --offset=10 ...
>
> Does it skip 10 output files (which may belong to less than 10 messages)
> or does it skip 10 messages (so it possibly skips
I added the following definitions to my init.el file, which seems to solve the
problem:
(defun org-notmuch-search-open (path _)
"Follow a notmuch search link specified by PATH."
(notmuch-search path notmuch-search-oldest-first
notmuch-search-hide-excluded))
(defun
erik colson writes:
>
> Thanks for the hint, but tried setting the var with setq-default, but
> still same issue.. :
>
> notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’.
>
> Its value is nil
> Original value was t
> Local in buffer *notmuch-saved-tree-1week and
David Bremner writes:
> It might matter how you are setting notmuch-search-hide-excluded. It
> is buffer-local (that changed recently, I think) so you need to either
> use customize or setq-default.
Hi,
Thanks for the hint, but tried setting the var with setq-default, but
still same issue.. :
erik colson writes:
> Hi,
>
> I recently upgraded from an older version in which excluded tags in the
> notmuch config were nicely hidden. Now I have exactly the same problem
> as Stanton described. I can see notmuch-search-hide-excluded is set
> globally to t, but in every search buffer it
David Bremner writes:
> Richard Stanton writes:
>
>> I have spam and trash defined as excluded tags for notmuch searches and when
>> I run (at the command line) the command
>>
>> notmuch search tag:unread
>>
>> I get a list of unread messages that does *not* include unread spam or trash
>>
These were disabled (accidentally?) in f63d14a8c12a.
---
test/T460-emacs-tree.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/test/T460-emacs-tree.sh b/test/T460-emacs-tree.sh
index 6ef5c54a..9388a8ed 100755
--- a/test/T460-emacs-tree.sh
+++ b/test/T460-emacs-tree.sh
@@ -222,8 +222,6 @@
On Thu, May 16 2024, Richard Stanton wrote:
> Today I received an email with (raw) subject line
>
> Subject: =?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your
> =?UTF-8?Q?workout=0D=0A?=
>
> When displayed in Emacs in either unthreaded or tree mode, “^M” appears after
> the word “workout”, and the
Hello,
Thanks a lot for your answers, I'm happy to have received such thoughtful
replies. Like you both pointed out, and from what I get, Notmuch works with
message-ids, and since it may happen that several files in different
folders have the same message-id, it explains what I was seeing.
My
Am Mo., 13. Mai 2024 um 23:38 Uhr schrieb Carl Worth :
>
> Hi Renaud,
>
> I was able to see similar behavior in my own mail store. And I agree
> that this behavior is confusing!
>
> The documentation for the --files option of notmuch search documents the
> cause (and predicts that this will be
Hi Renaud,
I was able to see similar behavior in my own mail store. And I agree
that this behavior is confusing!
The documentation for the --files option of notmuch search documents the
cause (and predicts that this will be confusing):
Note that each message may have multiple filenames
Jon Fineman writes:
> I see that if I set this variable to the below value it will hide
> text/plain, which is what I would like.
>
> notmuch-multipart/alternative-discouraged '("text/plain" "multipart/related")
>
> However I see that when I forward an email that has a text/plain part
> that
>> The end result is that `notmuch-message-headers` variable has no effect.
> Not sure if you are still interested, but this should be fixed in
> notmuch 0.35 (see show.extra_headers in notmuch-config(1)).
I just stumbled over this issue when trying to add "Message-Id" to the
list of shown
In case anyone else is affected by this, the problem I was having was that
notmuch-search org links (defined in ol-notmuch.el) were returning results that
included spam and trash messages even though I had asked to exclude these. To
get around this, redefine org-notmuch-search-open to
Actually, I think the code might be working as intended. Calling notmuch-search
interactively things work just fine, and in the comments I see the note
"When called interactively, this will prompt for a query and use the configured
default sort order.”
This sounds like it deliberately ignores
I used edebug to trace through the execution of notmuch-search in notmuch.el.
At line 1096, we have the code
(let ((proc (notmuch-start-notmuch
"notmuch-search" buffer #'notmuch-search-process-sentinel
"search" "--format=sexp"
Running
(notmuch-search "tag:unread" t t)
gives the correct results, so it looks like notmuch-search-hide-excluded is not
getting set to the correct default value.
> On Apr 16, 2024, at 3:15 PM, Richard H. Stanton
> wrote:
>
> Oh, wait… It's not working on my office machine either. I’ll
Oh, wait… It's not working on my office machine either. I’ll start tracing
things and see what happens.
By the way,
(notmuch-config-get "search.exclude_tags”)
returns
"spam
trash"
which is what it should be returning.
> On Apr 16, 2024, at 12:00 PM, Richard H. Stanton
> wrote:
>
>
Thanks, David.
It all seems to be working fine on my work machine!
I can’t decide if that’s good or bad news… I suspect it’ll take me longer to
track down what’s going on than if the behavior were consistent on my two
machines.
> On Apr 16, 2024, at 7:23 AM, David Bremner wrote:
>
>
Richard Stanton writes:
> I have spam and trash defined as excluded tags for notmuch searches and when
> I run (at the command line) the command
>
> notmuch search tag:unread
>
> I get a list of unread messages that does *not* include unread spam or trash
> emails. But when I put the following
Jon Fineman writes:
> Jon Fineman writes:
>
>> "Richard H. Stanton" writes:
>>
>>> I’ve recently installed notmuch with lieer and now have it successfully
>>> bringing my mail over from gmail so I can read it locally inside Emacs.
>>> This is very nice, and I particularly love the speed of
Jon Fineman writes:
> "Richard H. Stanton" writes:
>
>> I’ve recently installed notmuch with lieer and now have it successfully
>> bringing my mail over from gmail so I can read it locally inside Emacs. This
>> is very nice, and I particularly love the speed of notmuch’s searches.
>>
Is there a way to have all searches use tree mode by default? I know I can set
this as part of each individual search, but it would save typing if there were
a setting to make this the default.
> On Apr 8, 2024, at 10:26 AM, Richard H. Stanton
> wrote:
>
> Thanks, Carl. Using tree mode
"Richard H. Stanton" writes:
> I’ve recently installed notmuch with lieer and now have it successfully
> bringing my mail over from gmail so I can read it locally inside Emacs. This
> is very nice, and I particularly love the speed of notmuch’s searches.
> However, I’m not seeing how to get
Thanks, Carl. Using tree mode seems to solve my problem.
> On Apr 8, 2024, at 10:23 AM, Carl Worth wrote:
>
> On Mon, Apr 08 2024, Richard H. Stanton wrote:
>> If I press RETURN to view a message, “n” and “p” move to the
>> next/previous message *in the thread*, but motion with “n” stops when
On Mon, Apr 08 2024, Richard H. Stanton wrote:
> If I press RETURN to view a message, “n” and “p” move to the
> next/previous message *in the thread*, but motion with “n” stops when
> you get to the end of the thread. Is there a way to set things so that
> “n” moves from the end of the current
David Bremner writes:
> Today someone asked me the (reasonable) question of how much
> performance impact there is from synching tags to maildir flags. It
> turns out it is noticeable, about a 50% overhead compared to
> non-synched tags (according to these tests). In practice I don't know
> if
Hi there,
> I might be wrong, but I don't think the Gnus agent can be easily reused
> from notmuch. We could perhaps save the message as a draft upon C-c C-j,
> and then have a periodic timer that checks if any of the drafts has
> expired (maybe using a special, additional tag for the search) and
Dmitry Bogatov writes:
> Some people (e.g: me) prefer to read their email with threaded
> representation by default.
>
Applied to master.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
jli...@fsfe.org writes:
>
> ;;; _
> -
> +;;;#autoload
> (define-mail-user-agent 'notmuch-user-agent
>'notmuch-mua-mail
>'notmuch-mua-send-and-exit
Applied to master with the deleted blank line put back
___
notmuch mailing list --
Hi all,
El dom. 24 de mar. 2024, Marc escribió:
> I am attaching a new patch that includes an additional test on
> T630-emacs-draft.sh.
>
> On the test only `References` is at the top (hence hidden by emacs), not
> `In-Reply-To`. I guess that does rely on some configuration.
>
> In any case, the
Hi there,
> I might be wrong, but I don't think the Gnus agent can be easily reused
> from notmuch. We could perhaps save the message as a draft upon C-c C-j,
> and then have a periodic timer that checks if any of the drafts has
> expired (maybe using a special, additional tag for the search) and
João Pedro writes:
> Ah, indeed message properties seem to be more appropriate. Are they
> persisted, or are they tied to an Emacs session?
They are persisted in the database, and backed up with notmuch dump.
>
>> but your periodic search would still have to search for all of the
>>
Em quarta, 03/04/2024 às 07:06 (-03), David Bremner
escreveu:
> Message properties might work a bit better than tags
Ah, indeed message properties seem to be more appropriate. Are they
persisted, or are they tied to an Emacs session? Because I would like to
have it so that even if I kill my
Jon Fineman writes:
> Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 22384
> 32216)
> scan-sexps(22384 1)
> forward-sexp()
> mml-expand-html-into-multipart-related((part (type . "text/html") (charset
> . "UTF-8") (nofile . "yes") (tag-location . 907) (contents . "
João Pedro writes:
> Em terça, 02/04/2024 às 02:05 (+01), Jose A Ortega Ruiz
> escreveu:
>
>> I might be wrong, but I don't think the Gnus agent can be easily reused
>> from notmuch. We could perhaps save the message as a draft upon C-c C-j,
>> and then have a periodic timer that checks if any
Em terça, 02/04/2024 às 02:05 (+01), Jose A Ortega Ruiz escreveu:
> I might be wrong, but I don't think the Gnus agent can be easily reused
> from notmuch. We could perhaps save the message as a draft upon C-c C-j,
> and then have a periodic timer that checks if any of the drafts has
> expired
Hi,
On Mon, Apr 01 2024, João Pedro wrote:
> I am using notmuch in Emacs, with mbsync and msmtp (I actually use
> smtpmail.el in Emacs, but it uses the `sendmail' command, which is
> symlinked to msmtp) and the only thing I miss from other mail clients
> is the ability to schedule a mail to be
Hi again,
El dom. 24 de mar. 2024, Marc escribió:
> El mié. 13 de mar. 2024, Carl escribió:
>> (...)
>> Could you put your fix together in the form of a git-appliable patch?
>> Such as by applying it to the notmuch source, running `git commit` and
>> then `git format-patch HEAD~` or similar.
>
>
Hello,
El mié. 13 de mar. 2024, Carl escribió:
> (...)
> Could you put your fix together in the form of a git-appliable patch?
> Such as by applying it to the notmuch source, running `git commit` and
> then `git format-patch HEAD~` or similar.
Please disregard the previous patch, consider the
Hello,
El mié. 13 de mar. 2024, Carl escribió:
> (...)
> Could you put your fix together in the form of a git-appliable patch?
> Such as by applying it to the notmuch source, running `git commit` and
> then `git format-patch HEAD~` or similar.
Please disregard the previous patch, consider the
On 2024-03-19 16:12:04, Antoine Beaupré wrote:
[...]
> The closest we have in the archive is (author in CC):
>
> <71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org>
>
> ... which writes a new `kea/notmuch-address-message-capf' function from
> scratch. It might, however, do a better job than
I have *just* realized, after writing all this code and sending the
patch, that someone else might have discussed this here. Oops.
So, turns out, it *has* been discussed, but it doesn't look like anyone
tackled that problem fully just yet.
The closest we have in the archive is (author in CC):
David Bremner writes:
> Jon Fineman writes:
>
>> Received this error while trying to forward a complex html email from ebay.
>>
>> Unfortunately there is probably some PII embedded in it, so trying to
>> remove that to include the email might confuse things.
>>
>> Any suggestions on how to find
Jon Fineman writes:
> Received this error while trying to forward a complex html email from ebay.
>
> Unfortunately there is probably some PII embedded in it, so trying to
> remove that to include the email might confuse things.
>
> Any suggestions on how to find the error?
>
>
> Sending...
>
David Bremner writes:
Michael Graham writes:
I have a bunch of saved searches, which I configure like this:
(push '(:name "Personal Unscreened"
:query "tag:inbox AND tag:unread AND (NOT
query:screened-addresses)" :key "u" :search-type 'tree)
notmuch-saved-searches)
Michael Graham writes:
> I'm new at notmuch (and the list), so I'm probably doing something
> wrong.
>
> I prefer tree view (notmuch-tree-mode) to search view
> (notmuch-search-mode), and I would like my saved searches to open
> in tree view automatically.
>
> I have a bunch of saved
Marc Fargas writes:
> I hope my previous e-mails was properly sent.
>
Yes, it worked fine.
> I have been testing the patch and.. does it work? The code looks proper
> to me but testing on my computer it is not working properly, as if the
> `without-restrictions` was being ignored.
It seems
Hi,
I hope my previous e-mails was properly sent.
I have been testing the patch and.. does it work? The code looks proper
to me but testing on my computer it is not working properly, as if the
`without-restrictions` was being ignored.
I think I do not understand `defmacro` properly to see where
On Wed, Mar 13 2024, Marc Fargas wrote:
> Hi there,
Hi, Marc!
> I'm not sure if this is the appropiate mailing list for bugs regarding
> notmuch.el (Notmuch in Emacs). Also, I'm not subscribed so please keep
> me in CC!
Yes, this is a fine place to report things
> I recently noticed that when
tomi.oll...@iki.fi writes:
> From: Tomi Ollila
>
> Executed aspell -l en -c NEWS
>
> and replaced few obvious cases.
Applied to master. Or should I say Aplyde to mastre, based on evidence
presented.
___
notmuch mailing list -- notmuch@notmuchmail.org
David Bremner writes:
Hi, sorry, took me so long to get back to this XD. I've opted to squash
the 3 separate commits in this patch series into one commit so that
should address the commit message questions.
> mohk...@kisara.moe writes:
>
>> + :excludedWhether to show mail with excluded
Charles Cazabon writes:
> David Bremner wrote:
>> Charles Cazabon writes:
>>
>> > Is there a way to have a wildcard, glob, or regex serve as the
>> > configuration for other_email?
>>
>> [...] the code currently assumes that is a list of literal email addresses.
>> I guess the emacs front-end
David Bremner wrote:
> Charles Cazabon writes:
>
> > Is there a way to have a wildcard, glob, or regex serve as the
> > configuration for other_email?
>
> [...] the code currently assumes that is a list of literal email addresses.
> I guess the emacs front-end would require some adaptation to
Charles Cazabon writes:
> I've searched the list archives but have only found references to setting
> user.other_email to a list of actual addresses. Is there a way to have a
> wildcard, glob, or regex serve as the configuration for other_email? Have I
> missed something in the documentation?
Thanks for your fast reply Sandra.
On So, Feb 25 2024 11:28, Sandra Snan wrote
> Huh, there is a bug here, apparently, looking at the raw version
> of what I sent. It doesn't properly insert the RFC 2646
> line-ending spaces.
In fact, it does not work for me either. I commented my lines of code
Awesome, and I see you're already upstreaming hooks. But I think you can
simplify this because every reply buffer has a hidden "In-Reply-To"
header (can be shown with `message-widen-and-recenter`). You should be
able to attach a hook to `message-setup-hook`, I think? Ideally you'd
use
Huh, there is a bug here, apparently, looking at the raw version
of what I sent. It doesn't properly insert the RFC 2646
line-ending spaces.
Sandra Snan writes:
Sandra Snan writes:
Instead, do this:
(add-hook 'message-mode-hook
(lambda ()
Sandra Snan writes:
Instead, do this:
(add-hook 'message-mode-hook
(lambda ()
(use-hard-newlines 3 t)))
While keeping auto-fill-mode on, I mean. This sets the format flowed
header according to RFC 2646 so that your fills reads as if they were
softwrapped
Jan Detke writes:
With that I got an issue where my text body is verry narrow
while composing/replying to mails (as you can see).
Instead, do this:
(add-hook 'message-mode-hook
(lambda ()
(use-hard-newlines 3 t)))
___
Steven Allen writes:
There's actually a pretty decent autocrypt package[1] for Emacs,
only lacking notmuch integration. But writing that based on the
mu4e integration should be pretty trivial.
[1]: https://git.sr.ht/~pkal/autocrypt/
I've been working on that actually so check out that
There's actually a pretty decent autocrypt package[1] for Emacs, only
lacking notmuch integration. But writing that based on the mu4e
integration should be pretty trivial.
[1]: https://git.sr.ht/~pkal/autocrypt/
___
notmuch mailing list --
On 2024-02-22 22:22:13, Antoine Beaupré wrote:
> On 2023-04-26 12:10:09, Antoine Beaupré wrote:
[...]
> ... but it feels a bit too intrusive... Do I really want to divulge my
> cryptographic identity to the world constantly? I'm using ed25519 keys
> now, so the header is small, but for other
On 2023-04-26 12:10:09, Antoine Beaupré wrote:
[...]
> And while autocrypt has a nice beautiful and brilliant spec that does
> everything, that's not what I'm looking at right now. And I don't think
> it's productive to block in this way at this point.
>
> So I made a bespoke implementation that
On Fri, Dec 22 2023, Lars Kotthoff wrote:
> The attached patch allows to customize the default ", " and "| "
> separators in author lists. The main rationale for supporting this is
> that the Python API uses the same functionality to get the list of
> authors -- if I want to separate them again
Any chance of this being included?
Thanks,
Lars
On Fri, 22 Dec 2023 14:15:32 -0700, Lars Kotthoff wrote:
> The attached patch allows to customize the default ", " and "| " separators
> in author lists. The main rationale for supporting this is that the Python
> API uses the same
* David Bremner:
> My assumption is that the overhead of multiple invocations is only
> noticible for (at a guess) 1000s of calls to notmuch-tag.
Well, that certainly would mean that my proposal has negligible merit in
terms of efficiency. Matters of convenience and aesthetics probably
don't
Ralph Seichter writes:
>
> notmuch-tag(1) states that batch tagging operations are "more efficient
> than repeated notmuch tag invocations" (this is not qualified further).
> I don't know if the efficiency advantage of batch tagging would justify
> the time/effort required to implement the
The current tags file system already makes common things simple and
efficient, while still keeping unusual things possible. Pretty happy
about that
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
* David Bremner:
> Is there a benefit beyond simplifying this shell script (and maybe
> aesthetics)?
In addition to what you mentioned, and more importantly, I am thinking
about efficiency.
notmuch-tag(1) states that batch tagging operations are "more efficient
than repeated notmuch tag
Ralph Seichter writes:
> I currently use a custom wrapper script to call notmuch-tag multiple
> times for this very reason. I would prefer being able to use the '-*'
> syntax shown in my OP with "notmuch tag --batch".
>
> Is this a reasonable new-feature-suggestion, or do you guys think it
> too
Ralph Seichter writes:
I currently use a custom wrapper script to call notmuch-tag
multiple times for this very reason.
That is the appropriate solution.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
* David Bremner:
> As far as I understand your request, this would currently need 3
> different calls to notmuch-tag (or some scripting in e.g. python).
I currently use a custom wrapper script to call notmuch-tag multiple
times for this very reason. I would prefer being able to use the '-*'
Ralph Seichter writes:
> Looking at the notmuch-tag(1) man page, I wonder if something like the
> following tag file content is currently possible:
>
> -* +deleted -- folder:.Trash
> -* +ancient -- date:..10_years_ago
> +foo -- from:f...@example.com
>
> What I am trying to achieve with
Just checking in to see how this is doing :)
On Sun, Oct 29 2023 08:49, Tony Zorman wrote:
> Hi,
>
> this adds a new custom variable, `notmuch-mua-subject-regexp`, and an
> associated function, `notmuch-mua-subject-check`, to warn the user when
> the subject contains potentially troublesome
Jakub Wilk writes:
> shutil was used only for the tempfile.TemporaryDirectory backport,
> which was removed in commit b7c31f658121a0cf ("CLI/git: drop support for
> python < 3.2").
Series applied to master.
___
notmuch mailing list --
On Mon, Jan 15, 2024 at 08:35:37PM -0400, David Bremner wrote:
> HGV writes:
>
> > Does anyone have experience syncing the notmuch database or an entire
> > maildir directory via iCloud? I keep most of my email archive offline
> > but since iCloud added end-to-end encryption, I've considered
HGV writes:
> Does anyone have experience syncing the notmuch database or an entire
> maildir directory via iCloud? I keep most of my email archive offline
> but since iCloud added end-to-end encryption, I've considered syncing my
> archived mail and notmuch database via iCloud. But I'm
Sławomir Grochowski writes:
> Dear All,
>
> I just have started using notmuch with Emacs.
>
> When I run `notmuch-poll-and-refresh-this-buffer` which run script
> '.notmuch/hooks/pre-new':
>
> #!/bin/sh
> mbsync -L gmail
>
> Most of the time it gives me an error & message:
> "notmuch-search:
Does anyone have experience syncing the notmuch database or an entire
maildir directory via iCloud? I keep most of my email archive offline
but since iCloud added end-to-end encryption, I've considered syncing my
archived mail and notmuch database via iCloud. But I'm worried that
iCloud might
Am Di., 9. Jan. 2024 um 13:38 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
>
> >>
> >> I agree the bindings documentation does not make much sense. I suspect
> >> that the bindings should follow the underlying library and return "" if
> >> the library does. I don't use the bindings
Michael J Gruber writes:
>>
>> I agree the bindings documentation does not make much sense. I suspect
>> that the bindings should follow the underlying library and return "" if
>> the library does. I don't use the bindings that much, so I am curious
>> what others think.
>
> I might be
Am Di., 9. Jan. 2024 um 00:09 Uhr schrieb David Bremner :
>
> Vojtěch Káně writes:
>
> > At first, this sounds reasonable: the subject is empty, so it is
> > effectively missing. That would indicate a bug in Lieer itself and would
> > be fixed by a try-catch block. Notmuch's source for
Vojtěch Káně writes:
> At first, this sounds reasonable: the subject is empty, so it is
> effectively missing. That would indicate a bug in Lieer itself and would
> be fixed by a try-catch block. Notmuch's source for Message.header,
> however, states:
>
>>:returns: The header value, an empty
Thanks for your suggestion! This doesn't work unfortunately because the author
string doesn't contain the email addresses, i.e. no @ symbols (unless somebody
includes that in their name).
Cheers,
Lars
On Fri, 22 Dec 2023 23:24:37 +0100, Sandra Snan
wrote:
> Curses, flowed again! I'm just
Curses, flowed again! I'm just gonna attach the file
email_list = "Diaz, Marco , s...@mewni.com, Marco Diaz , s...@mewni.com"
addresses = []
current_address = ""
for char in email_list:
if char == ',' and '@' in current_address:
addresses.append(current_address.strip())
Lars Kotthoff writes:
Python […] I have to split the returned string, which is
error-prone with comma separators (e.g. name in email address is
of form Lastname, Firstname).
email_list = "Diaz, Marco , s...@mewni.com, Marco
Diaz , s...@mewni.com" addresses = []
current_address = "" for
Lars Kotthoff writes:
Python […] I have to split the returned string, which is
error-prone with comma separators (e.g. name in email address is
of form Lastname, Firstname).
email_list = "Diaz, Marco , s...@mewni.com, Marco
Diaz , s...@mewni.com" addresses = []
current_address = "" for
David Bremner writes:
probably not out of the box, but I guess it might be easier to
hack notmuch-extract-* on the emacs side than to extend 'notmuch
show --format=mbox'
Those elpa-mailscripts also rely on calling notmuch show
--format=mbox.
The elisp files (similar to what I had been
Sandra Snan writes:
> David Bremner writes:
>> By the way, the mailscripts package (elpa-mailscripts on Debian)
>> contains some some add-on functions that might reduce the manual
>> labour in situations like this.
>
> That's what I had been using, do they really work when the patches
> are
David Bremner writes:
By the way, the mailscripts package (elpa-mailscripts on Debian)
contains some some add-on functions that might reduce the manual
labour in situations like this.
That's what I had been using, do they really work when the patches
are encrypted?
I've been trying to go
Sandra Snan writes:
> Finally saving the patches one by one with w in the Emacs interface to
> notmuch gave me patches I could apply. (Just in case someone else
> searches the mailing list for the same issue.)
By the way, the mailscripts package (elpa-mailscripts on Debian)
contains some some
Sandra Snan writes:
> David Bremner writes:
>> I guess we could add a second code path that parsed and
>> decrypted the messages before re-serializing them again.
>
> Or, as a stop gap measure, a warning when the flags are used
> together that mbox doesn't support decr
Sandra Snan writes:
> I did not run configure again, I just went straight to make. I'd think
> that after 20 years of using autotools I wouldn't make that mistake
> but that's what I found when I scrolled back up the buffer and looked
> more carefully.
Sounds like it's working for you now. I
David Bremner writes:
I guess we could add a second code path that parsed and
decrypted the messages before re-serializing them again.
Or, as a stop gap measure, a warning when the flags are used
together that mbox doesn't support decrypt.
I tried decrypting the pgp'd parts of the mbox
David Bremner writes:
Fair enough, but can you try without sudo to try to narrow down
where the issue is?
I found the problem. Sudo wasn't the issue. It was that after
./configure had failed to find some of the build deps and asked me
to
sudo apt-get install libxapian-dev
tches.
Hmm. The code (format_part_mbox in notmuch-show.c) is pretty simple, it
basically reads the raw messages (up to gunzip and '^From ' escaping. I
guess we could add a second code path that parsed and decrypted the
messages before re-serializing them again. At the moment I don't have a
clear idea how
Sandra Snan writes:
> I used sudo for the install because /tmp/ isn't gonna be my
> ultimate destdir and I don't want my own user to own these files,
> root should own them. I was planning to use fpm in --dir mode.
> Although I didn't get that far because it instead installed into
>
1 - 100 of 17117 matches
Mail list logo
