emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Kyle Meyer <kyle@kyleam.com>
To: Richard Lawrence <richard.lawrence@uni-tuebingen.de>
Cc: emacs-orgmode@gnu.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: <87v9bbxeq0.fsf@kyleam.com> (raw)
In-Reply-To: <87a6spz7b5.fsf@aquinas>

Richard Lawrence writes:

> Kyle Meyer <kyle@kyleam.com> 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

  (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:")
  ;; 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:")
  ;; 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-read-date nil t nil "Date for tree entry:")
     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.


  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:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9bbxeq0.fsf@kyleam.com \
    --to=kyle@kyleam.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=richard.lawrence@uni-tuebingen.de \
    --subject='Re: [PATCH] capture: Fix handling of time range for :time-prompt' \


* 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:


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).