From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: Asynchronous org-agenda-redo Date: Thu, 12 Dec 2019 06:17:18 -0600 Message-ID: <87pngtsppt.fsf@alphapapa.net> References: <87k172ot2m.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:43526) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifNPR-0002In-72 for emacs-orgmode@gnu.org; Thu, 12 Dec 2019 07:17:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifNPP-0005n7-Aq for emacs-orgmode@gnu.org; Thu, 12 Dec 2019 07:17:33 -0500 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:50602 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ifNPO-0005it-Vc for emacs-orgmode@gnu.org; Thu, 12 Dec 2019 07:17:31 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1ifNPL-000T4e-45 for emacs-orgmode@gnu.org; Thu, 12 Dec 2019 13:17:27 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Be sure to read the Emacs Lisp manual regarding threads. They are cooperative, so functions called as threads must yield back to the main thread for Emacs to do anything else before the function returns. If you're feeling adventurous, you could experiment with adding yields in relevant agenda functions. But that wouldn't be suitable for merging into Org, because that yielding also decreases performance generally. As long as Elisp threads are cooperative, they are of very limited use. Generating agendas with async.el in a separate Emacs process is an interesting idea, but probably generally impractical for a few reasons: 1. The process would have to load the same Org buffers, which takes time, especially in large buffers. Depending on configuration, it can take some time, indeed. 2. The process would also have to load the same packages (or, at least, all the necessary ones, which depends on configuration), which takes time. 3. Ensuring that configuration and state between the main Emacs process and the separate, agenda-generating process is not necessarily simple. Consider as well that if a buffer had unsaved changes, those would not be readable by the other process, which would lead to invalid results. One could force the buffers to be saved first, but that may not always be desirable, as saving buffers can have side effects. If your agenda buffers are taking too long to refresh, you might consider org-ql's views/saved-searches as an alternative. The built-in caching in org-ql significantly improves performance, especially when refreshing views.