> _string);
> + if (status_string) {
> + fputs (status_string, stderr);
> + free (status_string);
> + status_string = NULL;
> + }
> +
> switch (status) {
> case NOTMUCH_STATUS_NO_CONFIG:
>
pect_equal "$output" "false"
>
> test_begin_subtest "Bad utf8 reported as error"
> -test_subtest_known_broken
> cp initial-config bad-config
> printf '[query]\nq3=from:\xff\n' >>bad-config
> test_expect_code 1 "notmuch --config=./bad-config config list"
b2-2.76.1 installed, I'm back to the scenario where
'notmuch --config=.notmuch-config config list' outputs nothing with
exit status 0 (when it SHOULD have been reporting glib's error, "Key
file contains key “%s” with value “%s” which is not UTF-8").
--
Eric Blake, Principal So
On Wed, Sep 06, 2023 at 12:48:15PM -0300, David Bremner wrote:
> Eric Blake writes:
>
> >
> > I'm not sure if this is the best approach (as this is my first ever
> > patch to notmuch), but it's better than nothing.
>
> Unfortunately we can't just print from t
rror message to the user (serves
as a warning to a user that their hand-written invalid escapes are
being accepted anyways with 2.76.1, and gives the user an explanation
why notmuch isn't working with 2.76.5).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestf
glib 2.76.1 silently treats invalid escape sequences as two
characters, even though it is willing to set a GError warning about
it. While 'notmuch config set' never produces such sequences in the
config file, the fact that the config file is human-readable lends
itself to hand-written edits,
Python likes to leave behind cache files; noticeable when doing an
in-tree build.
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index f94d1480..eda6d9cf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@
be the preferred way to
modify the config file - but since it IS a human-readable file,
notmuch should do a much better job of reporting errors whenever
glib's gkeyfile API cannot parse the file (even if that failure to
parse is caused by an unintended regression in glib behavior for
rejecting somethi
t spaces or the "or" or
something -- anyway I got the impression that it couldn't accept
multi-part queries inside the "thread:{}" syntax. But looking at your
patch maybe I just needed to quote differently?
Anyway I'll give this a tes
uot; in my notmuch searches all the time for
emails to/from the specified contact.
--
Eric S Fraga via gnus (Emacs 29.0.50 2022-06-07) on Debian 11.3
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
buffer (or
ps-print-buffer-with-faces). These generate a postscript file which you
can easily convert to PDF (on Linux, at least).
--
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.1
___
notmuch mailing list -- notmuch@notmuchma
Carl Worth wrote:
> On Sat, May 01 2021, Eric Wong wrote:
> > I never had the interest in using notmuch since Maildirs are a
> > non-starter with millions of messages with current FSes/OSes.
>
> What bottleneck are you seeing here?
>
> I don't have million(s) of mes
Sean Whitton wrote:
> Hello,
>
> I was wondering whether anyone who previously read mailing lists via
> NNTP has stopped doing this after starting to use notmuch.
Fwiw, I have some slrn spool to Maildir translators here which should
work with notmuch:
Perl:
David Bremner wrote:
> Franz Fellner writes:
> > mail takes at least 10 seconds, sometimes even more. It can go into
> > minutes when I get lots of mail (~30...). When I run it after a
> > reboot I can have breakfast while notmuch starts up... This is all on
> > spinning rust. I thought of
ading,
notmuch's ability to access such files will mean that I may be looking
for a different solution to managing my email. That, of course, amy not
matter much to anyone else, but how many others will there be?
Eric
--
ms fnd in a lbry
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Hello, I'm neither a notmuch user or proficient in C++.
However, I noticed a bug while working on public-inbox (in Perl)
which shares Xapian thread linking logic with notmuch, and I
suspect notmuch is affected by the same problem as public-inbox.
The problem is in the _merge_threads function in
David Bremner <da...@tethera.net> writes:
> Eric Skoglund <e...@pagefault.se> writes:
>
>> David Bremner <da...@tethera.net> writes:
>>
>>>
>>> Yeah, --verify only works with one of the structured output formats
>>> (json or se
ng "sigstatus : [ { 'status': 'good' }]".
// Eric
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner <da...@tethera.net> writes:
> Eric Skoglund <e...@pagefault.se> writes:
>
>> Hello, I've recently started using notmuch (together with emacs) and
>> have now encountered some problems when trying to decrypt a
>> multipart/encrypted message.
>
.'.
I've verified that gpg-agent is running (v2.1.13), both using ps which
gives me: gpg-agent --homedir /home/eric/.gnupg --use-standard-socket
--daemon and the gpg-connect-agent /bye return code is 0.
I also tried to add the use-agent in gpg.conf but that hasn't helped at
all.
Signing and encrypting
David Bremner <da...@tethera.net> wrote:
> Eric Wong <e...@80x24.org> writes:
> > For mirroring existing lists, I started using public-inbox-watch
> > which currently watches Maildirs. The config knobs are sorta
> > documented from my announcement to git@vger:
>
"W. Trevor King" <wk...@tremily.us> wrote:
> On Sun, Aug 21, 2016 at 06:37:04PM +, Eric Wong wrote:
> > Btw, for public-inbox, I'm using git-fast-import now, so imports are
> > a bit faster and $GIT_DIR/ssoma.index is no longer used. This was
> > crucial f
"W. Trevor King" <wk...@tremily.us> wrote:
> On Fri, Nov 07, 2014 at 11:03:21AM -0800, W. Trevor King wrote:
> > Eric Wong has been working on some tools to store email in a Git
> > repository, and his client-side code is ssoma [1]. I wanted a bit
> > more
"W. Trevor King" <wk...@tremily.us> wrote:
> On Sun, Aug 21, 2016 at 12:08:52PM +, Eric Wong wrote:
> > "W. Trevor King" <wk...@tremily.us> wrote:
> > > This is the ssoma archive (with the data in it). I just set up a
> > > ba
uld be by a threading algorithm that doesn't use In-Reply-To, and I
would consider that a bug in said algorithm.
Actually I think there should be a "reply as new" option which uses
the other message but does not add either In-Reply-To or References
(and does not carry the latter forward if it exists).
Eric
--
ms fnd in a lbry
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
On Sun, 14 Feb 2016 13:05:28 +0100 (CET), Eric J <e...@deptj.eu> wrote:
>
Resending with additional information:
> I have been using notmuch for a while and I wanted to be able to use
> notmuch queries in some Tcl stuff I have been using for a rather longer
> while. I coul
On Sun, 21 Feb 2016 13:57:30 +0100 (CET), Eric J <e...@deptj.eu> wrote:
> On Wed, 17 Feb 2016 21:44:23 +0100 (CET), Eric J <e...@deptj.eu> wrote:
> > Using the API, I am adding single mail files, already in the maildir, to
> > the Notmuch database and tagging them. It
On Wed, 17 Feb 2016 21:44:23 +0100 (CET), Eric J <e...@deptj.eu> wrote:
> Using the API, I am adding single mail files, already in the maildir, to
> the Notmuch database and tagging them. It works, every time, as long as
> I run it one file at a time.
>
> However, if I do i
On Wed, 17 Feb 2016 21:03:13 -0400, David Bremner <da...@tethera.net> wrote:
> Eric J <e...@deptj.eu> writes:
>
> > However, if I do it twice, in different processes, at the same time, one
> > file is added and tagged properly, the other is not (totally unfindable
&
On Thu, 18 Feb 2016 16:30:34 +0200, Tomi Ollila <tomi.oll...@iki.fi> wrote:
> On Thu, Feb 18 2016, David Bremner <da...@tethera.net> wrote:
>
> > Eric J <e...@deptj.eu> writes:
> >
> >> However, if I do it twice, in different processes, at the same tim
message_maildir_flags_to_tags
message_get_filename
message_get_message_id
database_end_atomic
message_destroy
database_close
database_destroy
I didn't realise till it was mostly written, but it is pretty much like
add_new() in notmuch-new.c .
Eric
--
ms fnd in a lbry
ve no idea if or how the interface file would have to be changed
for other languages.
Eric
--
ms fnd in a lbry
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
David Edmondson writes:
> On Fri, Oct 24 2014, Eric Abrahamsen wrote:
>> David Belohrad writes:
>>
>>> Dear All,
>>>
>>> i'm using org. And I'm using notmuch (that's why I address both mailing
>>> lists). Now, writing an email in everyday bu
David Edmondson d...@dme.org writes:
On Fri, Oct 24 2014, Eric Abrahamsen wrote:
David Belohrad da...@belohrad.ch writes:
Dear All,
i'm using org. And I'm using notmuch (that's why I address both mailing
lists). Now, writing an email in everyday bussiness requires a
non-significant time
I'm a long-time nmh user, and I heard notmuch was supposed to
handle mh folders, so I gave it a shot.
It's crazy slow. The first 'notmuch new' took 4 hours, but maybe
that's expected. However, every 'notmuch new' takes 4 - 10
hours. The only time it completes faster is if I immediately
re-run
I'm a long-time nmh user, and I heard notmuch was supposed to
handle mh folders, so I gave it a shot.
It's crazy slow. The first 'notmuch new' took 4 hours, but maybe
that's expected. However, every 'notmuch new' takes 4 - 10
hours. The only time it completes faster is if I immediately
re-run
ack,
especially from the people who do most of the work on notmuch, is
somewhat high-handed.
Eric
--
ms fnd in a lbry
eaders, but each of these messages also has a References
> header; this seems to indicate a case missed by commit cf8aaafbad68.
>
This may not actually be any help, but both hypermail and mhonarc agree
that two messages form a separate thread from the rest. I believe that
the latter, at
also has a References
header; this seems to indicate a case missed by commit cf8aaafbad68.
This may not actually be any help, but both hypermail and mhonarc agree
that two messages form a separate thread from the rest. I believe that
the latter, at least, is the JWZ algorithm.
Eric
--
ms fnd
robably in any
algorithm, but the maintainers of the mail client should also be told to
fix it! (RFC2822)
Digression I know, but I just wanted to flag the need for more work in
general on threading in notmuch.
Eric
--
ms fnd in a lbry
; > In any case, if there is just a few broken symlinks, and you want to
> > ignore them, you can add them the ignore= line in .notmuch-config
>
> Thanks, I deleted some, and ignored others. Insofar my problem is
> solved.
Eric
--
ms fnd in a lbry
symlinks, and you want to
ignore them, you can add them the ignore= line in .notmuch-config
Thanks, I deleted some, and ignored others. Insofar my problem is
solved.
Eric
--
ms fnd in a lbry
___
notmuch mailing list
notmuch@notmuchmail.org
http
wanted to flag the need for more work in
general on threading in notmuch.
Eric
--
ms fnd in a lbry
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner writes:
> Eric Abrahamsen writes:
>
>> I saw another message about the same problem on this list, in January,
>> with the advice to upgrade to git, but I'm still seeing it on notmuch
>> 0.16+7~gdc51bf0. Forwarding a message from within emacs using
>>
-forward-message' on the same message, however,
creates what appears to be a raw message, properly encoded.
Is there something still amiss in the code? Am I using the wrong
command?
Thanks!
Eric
-forward-message' on the same message, however,
creates what appears to be a raw message, properly encoded.
Is there something still amiss in the code? Am I using the wrong
command?
Thanks!
Eric
___
notmuch mailing list
notmuch@notmuchmail.org
http
David Bremner da...@tethera.net writes:
Eric Abrahamsen e...@ericabrahamsen.net writes:
I saw another message about the same problem on this list, in January,
with the advice to upgrade to git, but I'm still seeing it on notmuch
0.16+7~gdc51bf0. Forwarding a message from within emacs using
Franz Fellner
writes:
> On Dienstag, 23. Juli 2013 11:30:28 CEST, Eric Abrahamsen wrote:
>>> I have a problem with notmuch-vim (now: git master from 10 min. ago)
>>> (also with alot and ner, not with 'notmuch show' or notmuch-emacs).
>>> UTF-8-encoded From: (a
Franz Fellner
writes:
> Hi,
>
> I have a problem with notmuch-vim (now: git master from 10 min. ago)
> (also with alot and ner, not with 'notmuch show' or notmuch-emacs).
> UTF-8-encoded From: (at least) does not show Umlauts but a weird
> encoded-string.
> Example:
> "Thomas L?bking" as one of
some simple keybindings to mark stuff as junk/unwatch in my
.emacs:
http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/.emacs#L552
Hope someone finds this of use,
--
eric casteleijn
https://launchpad.net/~thisfred
to mark stuff as junk/unwatch in my
.emacs:
http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/.emacs#L552
Hope someone finds this of use,
--
eric casteleijn
https://launchpad.net/~thisfred
___
notmuch mailing list
notmuch@notmuchmail.org
http
> Hi Eric,
>
> from notmuch/TODO:
>
>Add support for the user to specify custom headers to be indexed (and
>re-index these for existing messages at the next database upgrade).
>
> I think that Carl has plans to implement this feature for v0.4 together
> with
if there is a way to specify additional
headers to be indexed by notmuch, or if not, if others would find this a
worthwhile addition?
--
eric casteleijn
https://code.launchpad.net/~thisfred
http://thisfred.posterous.com/
Otherwise, those without keithp's .emacs would end up with reply mode
not being entered. Suggested by keithp.
---
notmuch.el |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 551048a..42d397a 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -49,6
In my script containing a series of queries to be run on new mail for
setting up tags, it's nice to see which query I typed wrong.
Signed-off-by: Eric Anholt
---
lib/query.cc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/query.cc b/lib/query.cc
index 75f22b3
55 matches
Mail list logo
