Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?
Thanks, David! I'm giving this a try now. So far, so good! Best, Jonathan David Bremner writes: David Bremner writes: jonat...@teamwilner.com writes: I've got about 52K items with the tag "inbox". Should be "notmuch" right? :-) Here's the problem - if I want to view that in tree view, it can take multiple minutes for notmuch to return a result. In general there should be some results right away, with the rest of the buffer being filled asynchronously. Unfortunately notmuch-emacs only handles the one asynchronous query, so if there is already a long running query, you will indeed have to wait for the whole tree/list of headers to be read into emacs. I think I see what is probably going on for you. You are probably first opening the query with notmuch-search-mode, then switching to notmuch-tree mode, This leads to the original query running in the background, blocking your second (tree-mode) query from running. I suggest trying M-x notmuch-tree directly (say in a fresh Emacs instance) and see if it has the same delay. If it works better, you can set the default mode to open a saved search by customizing notmuch-saved-searches. It's been a while since I looked at the async code, maybe David E or Mark have some ideas about how hard it would be to improve the current behaviour of one async query blocking all others. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] configure: detect version by compiler for build
On 2020-07-28 08:25:00-0300, David Bremner wrote: > Đoàn Trần Công Danh writes: > > > > > Other compile and try run linked with libraries in (autotools') host > > architecture. > > > > Linking with build's libraries doesn't make sense, hence I ignored it. > > And patched downstream. > > > > I don't mind dropping this change and carry it downstream. > > > > I'm afraid I don't understand the reference to autotools here. Are you > embedding the build of notmuch in some packaging system that thinks > everything is autotools? Yes, this patch was inspired by patching for a packaging system that have all autotools' required variable exported. > I agree with Tomi that changing this one > relatively minor use of CC in isolation does not make sense. I'm not > opposed to upstreaming packaging inspired changes, but generally I would > like to see how they help more than just one packager. Nowaday, most distro only cross-compiles some base system then build other packages native-like with qemu-user-static. Except very limited set of distro and some distro for embedded system, but notmuch is unlikely shipped notmuch, so this could help only single packager. So, I think this patch should be dropped. -- Danh ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] configure: drop check for default xapian backend
On 2020-07-28 08:17:49-0300, David Bremner wrote: > Đoàn Trần Công Danh writes: > > > Starting from xapian 1.3.5, xapian switched default backend to glass. > > > > From 00cdfe10 (build: drop support for xapian versions less than 1.4, > > 2020-04-22), we only support xapian 1.4.0+. Effectively, we don't need > > to check for default xapian backend anymore. > > > > Let's drop it. > > This is not wrong, but I wonder if we will need to put it all back in a > slightly modified form when Xapian 1.6 releases with a new default > backend. I guess we can start by reverting this patch if that happens? I have a quick skim over current codebase, if I have not missed anything, this check is only applicable for testing. I think a future-proof move would be moving this check to a runtime check in "make test". What do you think? -- Danh ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: simplify handling of writable database modes
Tomi Ollila writes: > On Sun, Jul 26 2020, David Bremner wrote: > >> As the last commit message mentions, it is a bit hard to be sure one >> is using static_cast correctly, so this series eliminates >> the use of static_cast for Xapian database objects. >> >> As a bonus, it deletes more code than it adds. >> >> Based on a suggestion from Olly Betts. > > > Series LGTM. > > Tomi applied to master ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v3 0/4] Adjust test for changes in Emacs 27
Jonas Bernoulli writes: > This reroll explains why the variable's default value is -100. > It also adds an additional commit, which removes a misguided > abstraction that is related to those very same variables. > > Jonas Bernoulli (4): > gitignore: Ignore generated sphinx.config > test: Deal with Emacs 27 switching to lexical scope by default > test: Remove misguided emacs testing utilities > test: Explicitly state that we want to sign with sender Applied v3 to master. Sorting .gitignores left for a future cleanup. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] configure: detect version by compiler for build
Đoàn Trần Công Danh writes: > > Other compile and try run linked with libraries in (autotools') host > architecture. > > Linking with build's libraries doesn't make sense, hence I ignored it. > And patched downstream. > > I don't mind dropping this change and carry it downstream. > I'm afraid I don't understand the reference to autotools here. Are you embedding the build of notmuch in some packaging system that thinks everything is autotools? I agree with Tomi that changing this one relatively minor use of CC in isolation does not make sense. I'm not opposed to upstreaming packaging inspired changes, but generally I would like to see how they help more than just one packager. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] configure: drop check for default xapian backend
Đoàn Trần Công Danh writes: > Starting from xapian 1.3.5, xapian switched default backend to glass. > > From 00cdfe10 (build: drop support for xapian versions less than 1.4, > 2020-04-22), we only support xapian 1.4.0+. Effectively, we don't need > to check for default xapian backend anymore. > > Let's drop it. This is not wrong, but I wonder if we will need to put it all back in a slightly modified form when Xapian 1.6 releases with a new default backend. I guess we can start by reverting this patch if that happens? d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?
David Bremner writes: > jonat...@teamwilner.com writes: > >> I've got about 52K items with the tag "inbox". Should be "notmuch" >> right? :-) Here's the problem - if I want to view that in tree view, >> it can take multiple minutes for notmuch to return a result. > > In general there should be some results right away, with the rest of the > buffer being filled asynchronously. Unfortunately notmuch-emacs only > handles the one asynchronous query, so if there is already a long > running query, you will indeed have to wait for the whole tree/list of > headers to be read into emacs. > I think I see what is probably going on for you. You are probably first opening the query with notmuch-search-mode, then switching to notmuch-tree mode, This leads to the original query running in the background, blocking your second (tree-mode) query from running. I suggest trying M-x notmuch-tree directly (say in a fresh Emacs instance) and see if it has the same delay. If it works better, you can set the default mode to open a saved search by customizing notmuch-saved-searches. It's been a while since I looked at the async code, maybe David E or Mark have some ideas about how hard it would be to improve the current behaviour of one async query blocking all others. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
