From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: Asynchronous org-agenda-redo Date: Mon, 23 Dec 2019 18:36:09 -0600 Message-ID: <87fthaa7ba.fsf@alphapapa.net> References: <87k172ot2m.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87pngtsppt.fsf@alphapapa.net> <87o8wda6nv.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87h824sos5.fsf@alphapapa.net> <87wob0fwsg.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87immk8szl.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <878snfsdt7.fsf@alphapapa.net> <87fthcrgto.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35581) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijYBR-0003CA-Ea for emacs-orgmode@gnu.org; Mon, 23 Dec 2019 19:36:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ijYBP-0002WX-GQ for emacs-orgmode@gnu.org; Mon, 23 Dec 2019 19:36:21 -0500 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:41844 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ijYBP-0002S4-9q for emacs-orgmode@gnu.org; Mon, 23 Dec 2019 19:36:19 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1ijYBM-000PnF-6n for emacs-orgmode@gnu.org; Tue, 24 Dec 2019 01:36:16 +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 Ihor Radchenko writes: > If you accidentally move the point in the buffer being processed by > agenda, the results may be unpredictable (org-agenda-get-* functions > move across the buffer with re-search-forward). I'm afraid that's the basic problem with threading in Emacs: shared state. I don't know of a way to work around that. I suppose you could modify a lot of the agenda code to, e.g. store the position of the current search in a variable and go to it before each search. Of course, that would also reduce performance to some extent. It's a hard problem.