Re: Notmuch emacs client is slow when opening inbox.

Subject: Re: Notmuch emacs client is slow when opening inbox.

Date: Mon, 19 Sep 2022 06:46:58 -0300

To: Jose A Ortega Ruiz,


From: David Bremner

Jose A Ortega Ruiz <> writes:

> On Sun, Sep 18 2022, David Bremner wrote:
>> Jose A Ortega Ruiz <> writes:
>>> interesting!  if we were to have this, i think i'd prefer pagination
>>> rather than increasing the limit and keeping the old ones, and make it
>>> work for tree searches too.  and perhaps the limit (page size) could be
>>> a query parameter, so that one could have different page sizes for
>>> different queries.  if that makes sense (and i'm not missing a better
>>> way already in place), i might try to implement it when i have a bit of
>>> time.
>> Before going to far with pagination, maybe get Jani to recap the
>> difficulties he saw at the time that led him to propose the simpler
>> approach.
>> I can think of a few issues, but I don't really know if they are
>> blockers.
>> - the result set is going to vary dynamically as messages are added and
>>   removed from the database
>> - As far as I can tell, there isn't really an easy way to jump to page
>> n of the results.
> fwiw, my idea here was to always run the full, non-paginated query, and
> populate its result buffer just as now, but show, instead of that
> buffer, an indirect buffer pointing to it, narrowed to the page at hand.
> not as efficient as a limit/offset query per page, but i think the
> bottleneck here is in displaying results rather than running the query
> in most cases, isn't it?

Ah, indeed that sounds like a different approach than was previously
mooted. I guess it might be a simple-ish way of making the display more
lazy, which I agree is most likely the bottleneck most people are seeing.
notmuch mailing list --
To unsubscribe send an email to