James Cook writes:
> It is possible that a short note indicating that detailed descriptions
> will follow, placed at the top of the man page and/or at the top of the
> "Functions" section, would have saved me from my impatience. I think I
> do tend to read the first sentence or two of a man page
On Sat, Apr 15, 2023 at 12:26:33PM -0300, David Bremner wrote:
> James Cook writes:
>
> > Hi list,
> >
> > If I'm not mistaken, calling notmuch_database_open_with_config with
> > config_path = NULL causes notmuch to try to find the config file
> > automatically.
> >
> > It would be nice if that
James Cook writes:
> Hi list,
>
> If I'm not mistaken, calling notmuch_database_open_with_config with
> config_path = NULL causes notmuch to try to find the config file
> automatically.
>
> It would be nice if that were documented in the notmuch(3) man page. I
> can try drafting a patch if that
On Thu, Apr 13, 2023 at 2:25 PM Tomi Ollila wrote:
> On Sun, Apr 09 2023, David Bremner wrote:
> I would just use [ "${VAR-}" = 1 ] in shell script code (or barely
> [[ ${VAR-0} == 1 ]] if desired not to have ""s around variables...but...)
>
> ... using [ "${VAR-}" = 1 ] is also good in a sense
bash: line 1: AAA: unbound variable
weirder...:
$ bash -eu -c 'a="x"; [[ $a -eq 2 ]]'
bash: line 1: x: unbound variable
wat, as $a is not numeric, it tries to re-eval $x ???
$ bash -eu -c 'x=3; a="x"; [[ $a -eq 2 ]] && echo 1 || echo 0'
0
$ bash -eu -c 'x=2
On Thu, Apr 13 2023, Felipe Contreras wrote:
> On Sun, Apr 9, 2023 at 9:26 AM David Bremner wrote:
>>
>> It is desirable to have the tests consider these variables being
>> undefined as equivalent to the feature not being present, and in
>> particular for the tests not to generate errors.
>
>
Jakub Wilk writes:
> ---
> doc/man1/notmuch-config.rst | 2 +-
> doc/man1/notmuch-git.rst | 4 ++--
> doc/man7/notmuch-sexp-queries.rst | 8
> doc/notmuch-emacs.rst | 6 +++---
> 4 files changed, 10 insertions(+), 10 deletions(-)
applied to master,
thanks
On Sun, Apr 9, 2023 at 9:26 AM David Bremner wrote:
>
> It is desirable to have the tests consider these variables being
> undefined as equivalent to the feature not being present, and in
> particular for the tests not to generate errors.
This can be done easily with `[ ${FOO-0} -eq 1 ]`, or as
Felipe Contreras writes:
> Not used anymore now that we return an array of strings directly.
series applied to master, with one whitespace tweak in patch 2/3
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
ght now I am not sure
> that re-implementing all the idiosyncrasies of notmuch queries and
> Message-Id munging within notmuch-mutt is the way to go, especially
> since Message-Id fields that intersect with notmuch features are rare.
The code that does removal of spaces and () delited sequence
eem saner to manually construct queries in, but it would
still be better to have a query construction library, otherwise
programs are going to get it wrong all the time, even within notmuch.
> It doesn't do the message-id munging you mention (yet?),
This is a big part of the query construction
Paul Wise writes:
> So I think that it would be good if there were a library for notmuch
> query construction that would take care of all the different quoting
> levels, Message-Id munging etc. This could then get language bindings
> so that notmuch based tools and MUAs could use them for
query and
that changes the meaning of the query but I couldn't find any way to
prevent an arbitrary Message-Id from inserting parentheses into the
query. Also notmuch converts Message-Id (test)@hostname to just
@hostname in the Xapian database. I think that right now I am not sure
that re-implementi
Carl Worth writes:
>
> What it could also do is create some placeholder file like
> .NOTMUCH-MUTT-OUTPUT-DIR when it writes its output. And then it could
> check for that file's existence before removing a directory.
>
Sounds reasonable to me. Would someone like to make a patch for
notmuch-mutt?
Paul Wise writes:
> +search($results_dir, $remove_dups, qq{thread:"{id:$mid}"});
did you test this with a message-id with spaces in it? the quoting is a
delicate.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email
Felipe Contreras writes:
> On Tue, Apr 4, 2023 at 12:54 PM David Bremner wrote:
>>
>> This sounds right. Can we use the detection of missing messages in
>> wr_export to reset the appropriate counters? It looks like yes, given
>> the call to store_lastmod.
[snip]
> I would rather go for a
On Tue, Apr 4, 2023 at 12:54 PM David Bremner wrote:
>
> Felipe Contreras writes:
>
> > On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote:
>
> > Or we could say that after jumping a certain threshold of lastmod we
> > delete all the messages and start from scratch, perhaps every 1000
> >
Hello Alex and David,
I also came across this issue: inline image are not displayed only when
`notmuch-show-indent-content` is non-nil. However, even when
`notmuch-show-indent-content` is `nil` they are displayed but cannot be hidden.
As Alex Murray pointed out, the reason is that the function
Felipe Contreras writes:
> On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote:
> Or we could say that after jumping a certain threshold of lastmod we
> delete all the messages and start from scratch, perhaps every 1000
> revisions.
>
> Or maybe the query could generate a virtual tag if a
Felipe Contreras writes:
>
> I'm not familiar with git-annex, I would need to see an example of
> such merging happening.
I was confused, git-annex is using the builtin merge strategy "union",
which is not eliminating duplicates or sorting, so probably not
applicable here. I still have to try
On Tue, Apr 04 2023, Justus Winter wrote:
> My desktop now behaves exactly like my laptop, and it is really
> annoying. Surely I'm not the only one with this problem. Can no one
> else reproduce this?
I haven't tried using the reproduction test, but I did just refresh my
inbox and I saw the
On Tue, Apr 04 2023, Michael J. Gruber wrote:
>> It's really unfortunate if notmuch-mutt makes it that easy to throw away
>> your email.
>>
>> That sounds like a nasty bug that should be fixed in that program.
>
> To be fair to notmuch-mutt:
> ```
> --output-dir DIR
>
> Store search results as
Justus Winter writes:
> David Bremner writes:
>
>> Justus Winter writes:
>>
>>> I think I found a reproducer:
>>>
>>> mkdir -p /tmp/selection-bug/{tmp,new,cur}
>>> echo "[database]
>>> path=/tmp/selection-bug" > /tmp/selection-bug/notmuch-config
>>>
Am Di., 4. Apr. 2023 um 00:54 Uhr schrieb Carl Worth :
>
> Ouch.
>
Yes, we're feeling with you, Fulvio :|
> It's really unfortunate if notmuch-mutt makes it that easy to throw away
> your email.
>
> That sounds like a nasty bug that should be fixed in that program.
To be fair to notmuch-mutt:
On Mon, Apr 3, 2023 at 5:46 AM David Bremner wrote:
>
> David Bremner writes:
>
> >
> > I'm intrigued (and indeed I hadn't really thought about the degree to
> > which we were re-inventing git-fast-import and friends); however so far
> > my experiments did n
On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote:
>
> Felipe Contreras writes:
>
> >
> > That should work to update existing tags, but how are we going to
> > detect if a message has disappeared? Or is that not a thing?
>
> Indeed the same thought had occurred to me not long ago. I remembered
Felipe Contreras writes:
>
> That should work to update existing tags, but how are we going to
> detect if a message has disappeared? Or is that not a thing?
Indeed the same thought had occurred to me not long ago. I remembered
(belately) that I'd been through some similar thought process with
Ouch.
It's really unfortunate if notmuch-mutt makes it that easy to throw away
your email.
That sounds like a nasty bug that should be fixed in that program.
As for recovering, I suppose there _is_ a fair amount of detail in your
notmuch index from all of the position-indexed terms, (as long as
On Mon, Apr 03, 2023 at 08:39:02PM +0200, Michael J Gruber wrote:
> Am Mo., 3. Apr. 2023 um 20:17 Uhr schrieb Fulvio Pizzigoni
> :
> >
> >
> >
> >
> >
> >
> > Hi Carl e thanks for your prompt answer.
> >
> > As you suggested, I add notmuch@notmuchmail.org email as well.
> >
> > This is what I did:
On Mon, Apr 03, 2023 at 03:38:21PM -0300, David Bremner wrote:
> Fulvio Pizzigoni writes:
> >
> > After this my .mutt directory (~ 4 GB di mail-boxess) appears so:
> > fulvio@linux:~$ ll .mutt
> > totale 12
> > drwxr-xr-x 2 fulvio fulvio 4096 18 feb 20.32 cur
> > drwxr-xr-x 2 fulvio fulvio 4096
On Mon, Apr 3, 2023 at 2:40 PM David Bremner wrote:
>
> David Bremner writes:
>
> > Indeed that speeds up the initial clone on this machine from 39 minutes
> > (I switched machines) to 30s. I will play with it a bit more, and report
> > back.
>
> It's not a showstopper, but "git pull" takes
David Bremner writes:
> Indeed that speeds up the initial clone on this machine from 39 minutes
> (I switched machines) to 30s. I will play with it a bit more, and report
> back.
It's not a showstopper, but "git pull" takes about 1/2 the wall time
(about 2/3 of the CPU time) of the original
Felipe Contreras writes:
> By distributing the files in multiple directories like notmuch-git
> does using BLAKE2b, the operation is much faster.
>
> I've pushed the changes, now there's a dependency, but you can just
> `gem install blake2b`.
>
> I'm able to clone the database of the performance
Am Mo., 3. Apr. 2023 um 20:17 Uhr schrieb Fulvio Pizzigoni
:
>
>
>
>
>
>
> Hi Carl e thanks for your prompt answer.
>
> As you suggested, I add notmuch@notmuchmail.org email as well.
>
> This is what I did:
> fulvio@linux:~$ notmuch setup
> Your full name [fulvio]:
> Your primary email address [my
Fulvio Pizzigoni writes:
>
> After this my .mutt directory (~ 4 GB di mail-boxess) appears so:
> fulvio@linux:~$ ll .mutt
> totale 12
> drwxr-xr-x 2 fulvio fulvio 4096 18 feb 20.32 cur
> drwxr-xr-x 2 fulvio fulvio 4096 18 feb 20.32 new
> drwxr-xr-x 2 fulvio fulvio 4096 18 feb 20.32 tmp
Hi
Hi Carl e thanks for your prompt answer.
As you suggested, I add notmuch@notmuchmail.org email as well.
This is what I did:
fulvio@linux:~$ notmuch setup
Your full name [fulvio]:
Your primary email address [my address]: return
Additional email address [Press 'Enter' if none]: return
On Mon, Apr 3, 2023 at 4:49 AM David Bremner wrote:
> Performance-wise the initial clone seems pretty slow. For my 600k
> messages I have been waiting a while now. htop tells me that
> git-fast-import has about 45 minutes of CPU time at this point. This
> machine is not that fast, but for
notmuch [2]. If
> > you have this script (`git-remote-nm`) anywhere in your path, git will
> > interpret URLs prefixed with "nm::" as notmuch transports, and you can
> > do:
> >
> > git clone nm::$HOME/mail
>
> I'm intrigued (and indeed I hadn't re
David Bremner writes:
>
> I'm intrigued (and indeed I hadn't really thought about the degree to
> which we were re-inventing git-fast-import and friends); however so far
> my experiments did not get far enough to say anything conclusive.
>
I did manage to finish, about 70
"nm::" as notmuch transports, and you can
> do:
>
> git clone nm::$HOME/mail
I'm intrigued (and indeed I hadn't really thought about the degree to
which we were re-inventing git-fast-import and friends); however so far
my experiments did not get far enough to say anything c
On Sun, Apr 2, 2023 at 5:18 PM David Bremner wrote:
>
> Felipe Contreras writes:
>
> > We don't need a Tags enumerable object only for a small number of strings,
> > we
> > can just get them directly.
> >
> > This fixes an interaction problem where we might request two tags iterables
> > from
David Bremner writes:
> This obsoletes the series starting with
>
> id:20220903232839.1473915-2-da...@tethera.net
>
> Compared to that series this is rebased against master, it has some
> more tests (including both positive and negative tests) and it
> documents the non-anchoredness of the
Felipe Contreras writes:
> We don't need a Tags enumerable object only for a small number of strings, we
> can just get them directly.
>
> This fixes an interaction problem where we might request two tags iterables
> from the same message:
>
> tags_0 = notmuch_message_get_tags(message);
I
On Fri, Mar 31, 2023 at 5:07 AM David Bremner wrote:
>
> Felipe Contreras writes:
>
> > Essentially we want to do notmuch_database_open_with_config() and load the
> > default database.
> >
>
> Applied to master. Thanks for this change, both are things I'd wanted to
> fix.
Good. Since you chose
Kevin Boulain writes:
> This replaces two instances of Xapian::Query::MatchAll with the
> equivalent but thread-safe alternative Xapian::Query(std::string()).
> Xapian::Query::MatchAll maintains an internal pointer to a refcounted
> Xapian::Internal::QueryTerm.
>
Applied to master, thanks, and
Felipe Contreras writes:
> Essentially we want to do notmuch_database_open_with_config() and load the
> default database.
>
Applied to master. Thanks for this change, both are things I'd wanted to
fix.
d
___
notmuch mailing list --
hu Mar 30 07:56:17 2023 -0300
test: reveal notmuch_message_remove_all_properties as broken
Close and re-open the database to show that the removal is not
committed to the database.
I also had to manually deal with a merge conflict for the last patch, so
you might want to double
Kevin Boulain writes:
> These two functions don't fail gracefully when editing a removed
> message:
> BROKEN edit property on removed message without uncaught exception
> --- T610-message-property.20.EXPECTED 2023-02-27 11:33:25.792764376
> +
> +++
On 2023-03-29 at 08:32 -03, David Bremner wrote:
> It would be nice to structure this in terms of a known broken test
> (perhaps modify the existing one to reopen the database and dump the
> properties)
> that is then fixed by patch adding the sync.
I have restructured the commits to hopefully
On 2023-03-29 at 07:42 -03, David Bremner wrote:
> Thanks for the speedy update. I hate to do this but I think the message
> is now _too_ specific. Goldilocks and the three tests I guess.
>
> In particular, is there some reason to think that the number 54 is
> stable here? I'm worried about the
On Wed, Mar 29, 2023 at 3:50 AM Michael J Gruber
wrote:
>
> Am Mi., 29. März 2023 um 10:41 Uhr schrieb Felipe Contreras
> :
> >
> > Hi,
> >
> > I noticed you promoted notmuch-git as a user tool to toy around with it.
> >
> > Very quickly I realized that most of what it does is something I've
> >
Kevin Boulain writes:
>
> Yeah, talloc's documentation confirms that when the context is free'd
> every child is also free'd. Not quite sure what style is preferred
> (explicit or implicit, implicit sure leads to nicer code here).
In general implicit de-allocation is fine.
Kevin Boulain writes:
> On 2023-03-03 at 00:39 +02, Tomi Ollila wrote:
>> Somehow testkey1 = testvalue1 disappeared from the test code (which is
>> probably expected -- perhaps the commit message of the *change* 1/2
>> tried to point to that ;D)
>
> Yes, that proves
Kevin Boulain writes:
> +== stderr ==
> +A Xapian exception occurred at message-property.cc:XXX: No termlist for
> document 54
> +EOF
> +test_expect_equal_file EXPECTED OUTPUT
> +
> +add_email_corpus
Hi Kevin;
Thanks for the speedy update. I hate to do this but I think the message
is now
Am Mi., 29. März 2023 um 10:41 Uhr schrieb Felipe Contreras
:
>
> Hi,
>
> I noticed you promoted notmuch-git as a user tool to toy around with it.
>
> Very quickly I realized that most of what it does is something I've
> been working on for at least 10 years: making git work with other
> tools.
>
On Tue, Mar 28, 2023 at 12:47 AM Felipe Contreras
wrote:
> We can replace the Foo object any other kind of Enumerable, and the
> code works just the same:
>
> foo = %w[inbox unread]
I realized this might be too idiomatic of Ruby, it's the same thing as:
foo = [ 'inbox', 'unread' ]
>
On Mon, Mar 27, 2023 at 6:13 PM David Bremner wrote:
>
> Felipe Contreras writes:
>
> > We don't need a FileNames enumerable object only for a small number of
> > strings,
> > we can just get them directly.
> >
> > This iterator is meant to be transient and works only once, so we better
> >
Felipe Contreras writes:
> We don't need a FileNames enumerable object only for a small number of
> strings,
> we can just get them directly.
>
> This iterator is meant to be transient and works only once, so we better just
> iterate it once.
>
> This is the same approach I took with the Tags
On 2023-03-27 at 08:30 -03, David Bremner wrote:
> So you should probably test that the status is not success, and
> ideally print the message. You can see some examples in
> T560-lib-error.sh, in particular in the created file c_tail which
> handles checking the error code and printing the
Kevin Boulain writes:
> Since libnotmuch exposes a C interface there's no way for clients to
> diff --git a/test/T610-message-property.sh b/test/T610-message-property.sh
> index 944e1810..f7cabe4d 100755
> --- a/test/T610-message-property.sh
> +++ b/test/T610-message-property.sh
> @@ -363,7
On Thu, May 5, 2022 at 9:16 AM David Bremner wrote:
>
> arcnmx writes:
>
> > Hi, I've been running into rare crashes via notmuch-vim for a while now and
> > finally got around to tracking down the problem. I apologize for the size
> > of the reproduction case, but at least it can be reproduced!
On Sat, Apr 30, 2022 at 5:09 PM arcnmx wrote:
>
> Hi, I've been running into rare crashes via notmuch-vim for a while now and
> finally got around to tracking down the problem. I apologize for the size of
> the reproduction case, but at least it can be reproduced!
Thanks for the reproduction
Atanas Janackovski writes:
> I have justed strated using `notmuch' in Emacs (doom configuration), and I
> love
> it! However, there are a couple of things I'd like help with.
>
> 1. I have a number of accounts that I use. How do I configure my config to
> save
>draft messages based on the
On Tue, Mar 07 2023, Atanas Janackovski wrote:
> I have justed strated using `notmuch' in Emacs (doom configuration),
> and I love it!
Great! I'm glad it's useful for you.
> 1. I have a number of accounts that I use. How do I configure my
> config to save draft messages based on the "From"
On 2023-03-03 at 00:39 +02, Tomi Ollila wrote:
> Somehow testkey1 = testvalue1 disappeared from the test code (which is
> probably expected -- perhaps the commit message of the *change* 1/2
> tried to point to that ;D)
Yes, that proves notmuch_message_remove_all_properties is broken without
the
On Wed, Mar 01 2023, Kevin Boulain wrote:
> _notmuch_message_remove_all_properties wasn't syncing the message back
> to the database but was still invalidating the metadata, giving the
> impression the properties had actually been removed.
>
> Also move the metadata invalidation to
On Sat, 2023-02-25 at 09:48:08 -0400, David Bremner wrote:
> David Bremner writes:
>
>> Alex Murray writes:
>>
>> I tried replacing indent-rigidly with a simplified version the and that
>> leaves the image inserted, but unfortunately doesn't indent it
>> properly. If you want to play with it,
Antoine Beaupré writes:
>
> Still, one has to wonder: if emacs can just dump core if someone messes
> with my eln-cache, that's... bad, no?
Yes, it is bad, but the native compilation functionality is new, so
hopefully things will get better over time.
On 2023-02-22 16:23:27, David Bremner wrote:
> Antoine Beaupré writes:
>
>> When I have the attached email in my `inbox` and hit ENTER on the email
>> (notmuch-search-show-thread here), Emacs crashes completely with:
>>
>> fév 22 11:57:10 angela emacs[112721]:
>>
Kevin Boulain writes:
> Likely missed in 86cbd215e, when notmuch_query_search_messages_st was
> renamed to notmuch_query_search_messages.
> ---
Applied to master, thanks.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an
Kevin Boulain writes:
> This is what can be expected from the tests when they fail:
>== stderr ==
> +==
> +WARNING: ThreadSanitizer: data race (pid=207931)
> + Read of size 1 at 0x7b1001a0 by thread T2:
> +#0 memcpy (libtsan.so.2+0x62506)
> +#1 void
Kevin Boulain writes:
>
> Thoughts? Should clients using the library gate every function call to
> Notmuch behind a lock instead?
Ideally that should not be necessary. On the other hand, it may take some time
to fix
issues with concurrent access.
> I can also start a discussion in sfsexp's
Kevin Boulain writes:
> Likely missed in 86cbd215e, when notmuch_query_search_messages_st was
> renamed to notmuch_query_search_messages.
> ---
> lib/notmuch.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/notmuch.h b/lib/notmuch.h
> index ce375c04..73e246e0
David Bremner writes:
> Alex Murray writes:
>
> I tried replacing indent-rigidly with a simplified version the and that
> leaves the image inserted, but unfortunately doesn't indent it
> properly. If you want to play with it, my half working patch is
> attached.
>
Actually, the current
Alex Murray writes:
> Hi folks,
>
> I have noticed that inline image display doesn't work anymore in
> emacs-29 / git master and have tracked it down to a change to the way
> mm-inline-image inserts an image into the buffer.
>
> In
>
David Bremner writes:
> Jon Fineman writes:
>
>> When I try and open one specific email, I get a message of
>> "Fontifying..." and then the mouse pointer turns into a watch.
>>
>> If I C-G it breaks out and shows the email message with a red warning
>> at the top of "[some mark read tag
Antoine Beaupré writes:
> When I have the attached email in my `inbox` and hit ENTER on the email
> (notmuch-search-show-thread here), Emacs crashes completely with:
>
> fév 22 11:57:10 angela emacs[112721]:
>
Kevin Boulain writes:
> The documentation of MatchNothing says it's thread-safe.
>
> If you'd like, I'm happy to submit a patch (likely very small, given the
> limited number of occurrences) after I review a bit more the
> documentation and the code (I'm just starting with Notmuch and Xapian so
On 2023-02-21 at 07:59 -04, David Bremner wrote:
> Thanks for tracking this down. I did try some experiments a while ago
> with multi-threaded indexing (which is where the locking you mentioned
> arose), but overall it isn't well tested (by me).
To be honest I struggled a bit, notably on GLib
David Bremner writes:
> Apparently the macro setq-local only takes two arguments in Emacs 26.1
> ---
> emacs/notmuch-tree.el | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index 14775d59..b58fa6a6 100644
> ---
Am Di., 21. Feb. 2023 um 12:49 Uhr schrieb David Bremner :
>
> Apparently the macro setq-local only takes two arguments in Emacs 26.1
> ---
> emacs/notmuch-tree.el | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
>
Kevin Boulain writes:
> So, is Notmuch expected to be thread safe? There are some indications it
> should be (e.g.: lib/init.cc has locking) but all instances of
> Xapian::Query::MatchAll would have to be replaced.
> Xapian states it's thread safe:
>
David Bremner writes:
> This one use a more reasonable error code. As far as showing up every
> time, it does if I use --full-scan. That is the same (for me) as
> non-email files.
series applied to master.
d
___
notmuch mailing list --
"Jose A. Ortega Ruiz" writes:
> On Mon, Dec 26 2022, David Bremner wrote:
>
>> Amended by db: Copy docstring to manual and edit for presentation. Add
>> two tests.
>
> Thanks for the grunt work, David. Just a comment on a sloppy comment of
> mine below:
>
>> --- a/emacs/notmuch-tree.el
>> +++
Jon Fineman writes:
> When I try and open one specific email, I get a message of
> "Fontifying..." and then the mouse pointer turns into a watch.
>
> If I C-G it breaks out and shows the email message with a red warning
> at the top of "[some mark read tag changes may have failed]", but
> since
David Bremner writes:
> Michael J Gruber writes:
>
>>
>> Yes, the extra ones all are ghosts, and I slowly remember that they
>> scared me in the past already ...
>>
>> These ghosts appear to be pretty common. It happens all the time that
>> I am joined to an existing discussion thread where I
Michael J Gruber writes:
>
> Yes, the extra ones all are ghosts, and I slowly remember that they
> scared me in the past already ...
>
> These ghosts appear to be pretty common. It happens all the time that
> I am joined to an existing discussion thread where I do not have all
> references.
I
Am Di., 14. Feb. 2023 um 02:47 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
>
> > That is really weird:
> > ```
> > xapian-delve -t G00021229 .
> > Posting List for term 'G00021229' (termfreq 115, collfreq 0,
> > wdf_max 0): 146259 ...
> > ```
> > with 115 record
Michael J Gruber writes:
> That is really weird:
> ```
> xapian-delve -t G00021229 .
> Posting List for term 'G00021229' (termfreq 115, collfreq 0,
> wdf_max 0): 146259 ...
> ```
> with 115 record numbers, all different.
> Doing `xapian-delve -1r` for each of them and grepping
Am Mo., 13. Feb. 2023 um 21:23 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
> >
> > It has 5, as confirmed by the search output and that of `notmuch
> > count`. But it is matched by `count 115`.
> > `xapian-check` is happy. (There used to be some issue with additional
> > thread
Michael J Gruber writes:
>
> It has 5, as confirmed by the search output and that of `notmuch
> count`. But it is matched by `count 115`.
> `xapian-check` is happy. (There used to be some issue with additional
> thread entries at some point.)
>
> Michael
A simple test to try is
% xapian-delve
Am Mo., 13. Feb. 2023 um 17:32 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
>
> > I am getting a few surprising matches, e.g.
> > ```
> > notmuch search --query=sexp '(thread (count 115)))'
> > thread:00021229 2021-05-17 [5/5] Michael J Gruber ... redacted
> > notmuch count
Michael J Gruber writes:
> I am getting a few surprising matches, e.g.
> ```
> notmuch search --query=sexp '(thread (count 115)))'
> thread:00021229 2021-05-17 [5/5] Michael J Gruber ... redacted
> notmuch count --exclude=false thread:00021229
> 5
> ```
> It could be some
Am Mo., 13. Feb. 2023 um 13:26 Uhr schrieb David Bremner :
>
> So for this only supports counting messages in threads, and the sexp
> based query parser. It seems useful to expand it to other fields
> (from, e.g.). I'm not sure how motivated I am to shim this into the
> infix query parser, but we
Vishal Chourasia writes:
> Thanks! Installing the emacs-notmuch package from epel 8 worked.
>
Great, thanks for letting us know.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Thanks! Installing the emacs-notmuch package from epel 8 worked.
On 2/9/23 20:10, David Bremner wrote:
Vishal Chourasia writes:
On 2/7/23 19:53, David Bremner wrote:
Which distribution? At least on Debian based distributions, the emacs
interface is packaged seperately as elpa-notmuch
RHEL
Vishal Chourasia writes:
> On 2/7/23 19:53, David Bremner wrote:
>> Which distribution? At least on Debian based distributions, the emacs
>> interface is packaged seperately as elpa-notmuch
> RHEL
Fedora has a separate emacs-notmuch package. Perhaps that also exists in
RHEL? The page
RHEL
On 2/7/23 19:53, David Bremner wrote:
Vishal Chourasia writes:
Greetings,
where can I find the notmuch.el file when notmuch was installed from the
distribution's package repository?
# notmuch --version
notmuch 0.35
Which distribution? At least on Debian based distributions, the
On 2/7/23 19:53, David Bremner wrote:
Which distribution? At least on Debian based distributions, the emacs
interface is packaged seperately as elpa-notmuch
RHEL
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
Vishal Chourasia writes:
> Greetings,
>
>
> where can I find the notmuch.el file when notmuch was installed from the
> distribution's package repository?
>
> # notmuch --version
> notmuch 0.35
Which distribution? At least on Debian based distributions, the emacs
interface is packaged
401 - 500 of 17154 matches
Mail list logo
