From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco Wahl Subject: Re: org-today broken Date: Mon, 04 Feb 2019 12:10:56 +0100 Message-ID: <84h8djbygv.fsf@gmail.com> References: <874l9o9mev.fsf@kyleam.com> <84y36yjw8r.fsf@gmail.com> <874l9k4auv.fsf@kyleam.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:48822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqc9b-00030T-Jk for emacs-orgmode@gnu.org; Mon, 04 Feb 2019 06:11:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gqc9a-0004vL-IJ for emacs-orgmode@gnu.org; Mon, 04 Feb 2019 06:11:07 -0500 Received: from [195.159.176.226] (port=35144 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gqc9a-0004sy-BA for emacs-orgmode@gnu.org; Mon, 04 Feb 2019 06:11:06 -0500 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gqc9X-000Hfq-Bf for emacs-orgmode@gnu.org; Mon, 04 Feb 2019 12:11:03 +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 Hi Kyle, >> Occasionally I like to bend time to see what the agenda would look like >> if another day was current. This can be achieved conveniently when >> solely function "current-time" is the source for the current time. >> >> So I'm all for using the explicit calls to current-time instead of using >> alternatve sources for the current time. > > Sorry for making your time travel harder :] :[ > Emacs's c75f505dea6 argues for replacing current-time calls with nil > where possible because "nil is a bit more efficient and should have less > timing error". But if there are any particular spots where you'd like > to use current-time for the reasons you give above, please feel free to > make those changes. (There are already quite a few places where I've > done this because we depend on overriding current-time in tests.) Thanks for the clarification. I think it's a not so great idea to build on an assumption about some internal stuff, here concretely the expectation that the current time is retrieved per call to `current-time' everywhere in Org. If there shall be a time travel feature in Org this feature should be made explicit, I think, which BTW could be ensured with suitable tests. Possibly one could use external tools to get even more powerful timetravel, as Marcin proposed IIRC. So go ahead with every optimization you can find! Best regards, Marco