From mboxrd@z Thu Jan 1 00:00:00 1970 From: Justin Vallon Subject: PATCH: Re: Recurring TODO with hours not scheduled correctly Date: Sat, 7 Dec 2019 11:00:16 -0500 Message-ID: <9c4d4ccb-5a92-d12d-60ce-a778684b689a@gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------C8456E51A53BC3392C14D3C2" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33655) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idcrg-0002XN-NZ for emacs-orgmode@gnu.org; Sat, 07 Dec 2019 11:23:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idcre-0006bm-Kx for emacs-orgmode@gnu.org; Sat, 07 Dec 2019 11:23:28 -0500 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]:44255) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1idcre-0006bR-G3 for emacs-orgmode@gnu.org; Sat, 07 Dec 2019 11:23:26 -0500 Received: by mail-qt1-x82c.google.com with SMTP id g17so4624082qtp.11 for ; Sat, 07 Dec 2019 08:23:26 -0800 (PST) Received: from tzzpccd.dnsalias.net (pool-72-89-125-139.nycmny.fios.verizon.net. [72.89.125.139]) by smtp.gmail.com with ESMTPSA id l49sm7782178qtk.7.2019.12.07.08.00.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Dec 2019 08:00:17 -0800 (PST) In-Reply-To: Content-Language: en-US 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 This is a multi-part message in MIME format. --------------C8456E51A53BC3392C14D3C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/3/19 1:03 AM, Justin Vallon wrote: > Newbie org-mode user. Wondering about some odd recurrence behavior. =2E.. > My understanding of .+TERM is that the new scheduled time should be now= > + term. However, from this instance and testing with other terms, it > seems to be "current date + scheduled-time" + HOURS. Completing again > advances the time by one hour, leaving the date as today. >=20 > For ".+2d", the new scheduled date/time is 2d away (at the same time), > and re-completing does not change the new schedule time. Following up with a patch to make .+1h work "like" .+1d: - When computing the new scheduled date, the repeater-type "." would shift the scheduled date to today, then adjust by the interval. Shifting the date would leave the time unchanged - When shifting by hours, the old time would remain, and then be shifted by the interval - With the patch, ".+1h" will shift schedule-date to now (vs today), then add "1h" as before. ".+1d" will have the old behavior (shift date, but leave time alone). - That is: - ".+1d" is tomorrow at same scheduled time - ".+1h" is in one hour - ".+24h" is 24h from now. I would argue that the old behavior is broken (".+1h" advances the schedule time by an hour), so retaining the old behavior is not useful (ie: no option is required). Changes: - org-timestamp-change: Add a 'now tag to set the current time to now - org-auto-repeat-maybe: if interval is '.+Nh', relative time is "now" (instead of today) "now" might be usable when the interval is days, but I am not sure about the difference between (org-today) and (current-time) (ie: they seem different), so the patch only applies for intervals of hours. Patch is relative to org 9.3. --=20 -Justin JustinVallon@gmail.com --------------C8456E51A53BC3392C14D3C2 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="org.el.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="org.el.patch" LS0tIG9yZy5lbAkyMDE5LzEyLzA3IDE1OjM2OjMxCTEuMQorKysgb3JnLmVsCTIwMTkvMTIv MDcgMTU6Mzc6MTUKQEAgLTEwODI0LDkgKzEwODI0LDE0IEBACiAJCQkocmVwZWF0ZXItdHlw ZSAobWF0Y2gtc3RyaW5nIDEgdHMpKSkKIAkJICAgIChjb25kCiAJCSAgICAgKChlcXVhbCAi LiIgcmVwZWF0ZXItdHlwZSkKLQkJICAgICAgOzsgU2hpZnQgc3RhcnRpbmcgZGF0ZSB0byB0 b2RheS4KLQkJICAgICAgKG9yZy10aW1lc3RhbXAtY2hhbmdlICgtIChvcmctdG9kYXkpICh0 aW1lLXRvLWRheXMgdGltZSkpCi0JCQkJCSAgICAnZGF5KSkKKwkJICAgICAgKGNvbmQKKwkJ ICAgICAgICgoZXF1YWwgd2hhdCAiaCIpCisJCQk7OyBhZGp1c3QgdGltZXN0YW1wIHRvIG5v dworCQkJKG9yZy10aW1lc3RhbXAtY2hhbmdlIDAgJ25vdykpCisJCSAgICAgICAodAorCQkJ OzsgU2hpZnQgc3RhcnRpbmcgZGF0ZSB0byB0b2RheS4KKwkJCShvcmctdGltZXN0YW1wLWNo YW5nZSAoLSAob3JnLXRvZGF5KSAodGltZS10by1kYXlzIHRpbWUpKQorCQkJCQkgICAgICAn ZGF5KSkpKQogCQkgICAgICgoZXF1YWwgIisiIHJlcGVhdGVyLXR5cGUpCiAJCSAgICAgIChs ZXQgKChuc2hpZnRtYXggMTApCiAJCQkgICAgKG5zaGlmdCAwKSkKQEAgLTE1MzQ5LDYgKzE1 MzU0LDggQEAKIAkgIChzZXRjYXIgKG50aGNkciAxIHRpbWUwKSAob3IgKG50aCAxIHRpbWUw KSAwKSkKIAkgIChzZXRjYXIgKG50aGNkciAyIHRpbWUwKSAob3IgKG50aCAyIHRpbWUwKSAw KSkKIAkgIChzZXRxIHRpbWUgKGFwcGx5ICdlbmNvZGUtdGltZSB0aW1lMCkpKSkKKyAgICAg ICh3aGVuIChlcSB3aGF0ICdub3cpCisJKHNldHEgdGltZSAoY3VycmVudC10aW1lKSkpCiAg ICAgICA7OyBJbnNlcnQgdGhlIG5ldyB0aW1lLXN0YW1wLCBhbmQgZW5zdXJlIHBvaW50IHN0 YXlzIGluIHRoZSBzYW1lCiAgICAgICA7OyBjYXRlZ29yeSBhcyBiZWZvcmUgKGkuZS4gbm90 IGFmdGVyIHRoZSBsYXN0IHBvc2l0aW9uIGluIHRoYXQKICAgICAgIDs7IGNhdGVnb3J5KS4K --------------C8456E51A53BC3392C14D3C2--