From: Kyle Meyer <firstname.lastname@example.org> To: Richard Lawrence <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH] capture: Fix handling of time range for :time-prompt Date: Mon, 01 Feb 2021 23:42:31 -0500 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <87a6spz7b5.fsf@aquinas> Richard Lawrence writes: > Kyle Meyer <firstname.lastname@example.org> 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 >> <https://orgmode.org/list/20120923194954.GE25237@boo.workgroup/T/#u>. > > 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.
next prev parent reply other threads:[~2021-02-02 4:43 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-24 10:42 Bug: incorrect timestamps with :time-prompt and datetrees Richard Lawrence 2020-12-24 12:07 ` Richard Lawrence 2021-01-06 12:16 ` Richard Lawrence 2021-01-12 8:41 ` [PATCH] " Richard Lawrence 2021-01-18 6:35 ` Bug: " Kyle Meyer 2021-01-19 2:25 ` [PATCH] capture: Fix handling of time range for :time-prompt Kyle Meyer 2021-01-31 11:15 ` Richard Lawrence 2021-02-02 4:42 ` Kyle Meyer [this message] 2021-02-02 16:59 ` Richard Lawrence
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] capture: Fix handling of time range for :time-prompt' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).