From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SFFwCl3YGGA6NQAA0tVLHw (envelope-from ) for ; Tue, 02 Feb 2021 04:43:09 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id qAopBl3YGGBREQAAB5/wlQ (envelope-from ) for ; Tue, 02 Feb 2021 04:43:09 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4B9339403AC for ; Tue, 2 Feb 2021 04:43:08 +0000 (UTC) Received: from localhost ([::1]:53320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6nWs-0007PQ-7q for larch@yhetil.org; Mon, 01 Feb 2021 23:43:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6nWV-0007PI-5i for emacs-orgmode@gnu.org; Mon, 01 Feb 2021 23:42:44 -0500 Received: from out2.migadu.com ([2001:41d0:2:aacc::]:42257) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6nWR-0001mt-LC for emacs-orgmode@gnu.org; Mon, 01 Feb 2021 23:42:42 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1612240953; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9SUbLpUW8zJji8gM8JlDubiL9GXWUbothpAaHw1hyuQ=; b=POdaupFLfoWYwp66AMXs/A12wFoBo/9r9Cx0WcL8ZpP9UYzUfHrPT79jnEA0eN7NGlP/6F BsCohzTQ9rSsdYbDTTSHwHNpTwNg1WkEz2lwT7oKXZOPyn8tsOL7wqzS8FGTs4AUQFxdpq pjzH0g/bAO+i/IhNeFEopnxA7L1Z+x8A+3dppVTexbUc++8Z2QNCPyNAFnnxYWTnyhJKyG 4vIrwA0h6swYWrkGNHZEGqMhYbxYjUK/BAW/KCP9UlA0yxR1oGsqcDEh6W/ZeCipVEG1gA M2uJWE7pXQ+JsTGG3xumcx3J0/Np/jZjCq2hOt8Js83G02nMYa3UV2P6R/0hbQ== From: Kyle Meyer To: Richard Lawrence Subject: Re: [PATCH] capture: Fix handling of time range for :time-prompt In-Reply-To: <87a6spz7b5.fsf@aquinas> References: <878s8pll2g.fsf@kyleam.com> <87a6spz7b5.fsf@aquinas> X-Woof-Patch: applied Date: Mon, 01 Feb 2021 23:42:31 -0500 Message-ID: <87v9bbxeq0.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Auth-User: kyle@kyleam.com Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=kyle@kyleam.com; helo=out2.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.56 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=kyleam.com header.s=key1 header.b=POdaupFL; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 4B9339403AC X-Spam-Score: -2.56 X-Migadu-Scanner: scn0.migadu.com X-TUID: opBrxU8AMrPx Richard Lawrence writes: > Kyle Meyer writes: > >> Testing that against the cases in your initial report, I believe it >> leads to the same results as your patch, so here's a cleaned-up version. > > I confirm that this cleaned up version works for me and gets the same > results for my test cases. I think it should be applied (modulo one > nitpick below). Are you willing to apply it, Kyle? I don't have commit > rights myself. Sure. Thank you for testing it. >> - (cond ((and (or (not (boundp 'org-time-was-given)) >> - (not org-time-was-given)) >> - (not (= (time-to-days prompt-time) (org-today)))) >> - ;; Use 00:00 when no time is given for another [...] >> + (if (and (or (not org-time-was-given)) > > Nitpick: (or (not org-time-was-given)) is equivalent to (not org-time-was-given) Eh, thanks for spotting my sloppy conversion. Fixed, though I ended up rearranging things a bit more to avoid unnecessary `not's that were in the original code. Pushed (3e64d3475). > As for this: > >> The original change came in b61ff117b (org-capture.el: >> Set a correct time value with file+datetree+prompt, 2012-09-24), and I >> believe the related thread is >> . > > Thanks for the reference to this thread. I would like to be able to do > exactly what Gregor mentioned there: > > - be prompted when capturing for the date and time / time range of the > event/appointment. > - record the event/appointment in a date tree under the date entered at > the prompt > - have a timestamp with the full time information entered at the prompt > appear in the resulting heading > > In short: enter the full date and time information *once*, and use this > both to place the entry in the datetree and to give it a timestamp. This isn't functionality I use myself, so I'm not sure I have things straight in my head, but, yeah, sounds reasonable. > > As far as I can tell, that is not fully possible today, even with this > patch. The reason is that time *range* information entered at the prompt > generated by :time-prompt gets thrown away. The reason for *that* is > that org-read-date is called with t as its to-time argument (the second > argument), so that the date is returned in Emacs' internal time > representation, which doesn't represent ranges. Hmm. Is it really about the TO-TIME argument? If org-read-date is called with TO-TIME as nil, doesn't it still throw away the end of the range? (let ((org-time-was-given nil) (org-end-time-was-given nil)) (org-read-date nil nil nil "Date for tree entry:")) ;; enter "3pm-4pm" => "2021-02-01 15:00" Or, actually, it stores the end in org-end-time-was-given, but it does that regardless of the TO-TIME argument. ;; TO-TIME nil (let ((org-time-was-given nil) (org-end-time-was-given nil)) (org-read-date nil nil nil "Date for tree entry:") org-end-time-was-given) ;; enter "3pm-4pm" => "16:00" ;; TO-TIME t (let ((org-time-was-given nil) (org-end-time-was-given nil)) (org-read-date nil t nil "Date for tree entry:") org-end-time-was-given) ;; enter "3pm-4pm" => "16:00" And the org-time-stamp command uses a non-nil TO-TIME, formatting the time stamp with something like this: ;; org-time-stamp (let* ((org-time-was-given nil) (org-end-time-was-given nil)) (org-insert-time-stamp (org-read-date nil t nil "Date for tree entry:") org-time-was-given nil nil nil (list org-end-time-was-given))) ;; enter "3pm-4pm" => "16:00" => <2021-02-01 Mon 15:00-16:00> > Bastien's recommended solution back then was to use %^t and %^T in the > capture template instead of %t and %T. The problem with that is that it > requires entering the date twice: once at the prompt generated by > :time-prompt, and once at the prompt to replace the %^T in the template. > > Could we instead save, say, :start-time and :end-time values in > org-capture-plist after the :time-prompt, and use them to populate %T, > %U, etc. in the template? This seems like the right solution to me, but > it might require modifying org-read-date, which is a hairy piece of > code. What do others think about this? Should I come up with a patch for > this, or is there a different solution that the community and > maintainers would prefer? I don't have a good grasp of all the details here yet, but something in that direction sounds worth considering to me. And perhaps by carrying along org-end-time-was-given, you won't need to modify org-read-date. Thanks.