[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is this proper time format?
From: |
David Masterson |
Subject: |
Re: Is this proper time format? |
Date: |
Sat, 10 Jun 2023 17:01:25 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Ihor Radchenko <yantar92@posteo.net> writes:
> David Masterson <dsmasterson@gmail.com> writes:
>
>>>> Maybe I'm not explicit enough. In section 8.1 of the Org 9.6 manual is
>>>> a subsection "Time/Date Range" that *implies* times are supported in
>>>> ranges by the use of words "time" and "timestamp" when, above, you're
>>>> saying they are undefined (unsupported?) for now. I'm merely saying
>>>> adjust the manual to remove the implication.
>>>
>>> Please check the manual from main branch of Org. It has more text:
>>
>> I disagree. I cloned Org from Savannah and made the attached patch
>> file from the main branch. First time for me attaching a file to a
>> message. Does it work for you?
>
> Yes. Though it would be better to attach the diff with proper (.diff or
> .patch) extension.
I hope you saw that I provided a "patch,txt" file in a following message
(forgot about the naming convention -- been a long time...)
> Even better would be providing commit message and formatting the patch
> properly. See https://orgmode.org/worg/org-contribute.html#first-patch
> Not mandatory though - I can format things properly on your behalf.
Thank you. I haven't "patched" anything on Savannah and assumed I might
have to do the GNU copyright assignment. For this, I thought it would
be easy for you.
>> - Two timestamps connected by =--= denote a range.
>> + Two timestamps connected by =--= denote a date range. NOTE: time is
>> + not specified in these timestamps -- just dates,
>
> I'd avoid this NOTE. Time is actually allowed, but agenda does nothing
> with it. But only agenda. The rest of Org will handle date ranges like
> <2023-06-10 Sat 14:00>--<2023-06-12 Mon 18:00> correctly.
>
>> -#+cindex: timestamps
>> -#+cindex: ranges, time
>> -#+cindex: date stamps
>> -#+cindex: deadlines
>> -#+cindex: scheduling
>
> Is there any particular reason why you removed index entries here and
> further in the diff?
No, there isn't. I think what happened here is that I noticed section
8.1 in org-guide and org-manual were almost (but not quite) the same. I
assumed (incorrectly?) that they were supposed to be the same, but got
out of sync. So I made my patch to org-guide and then replaced section
8.1 in org-manual with the one from org-guide. I think these "cindex"
statements got dropped because of that. If they are important in
org-manual, but not org-guide, then please put them back.
>> A timestamp may contain a /repeater interval/, indicating that it
>> applies not only on the given date, but again and again after
>> - a certain interval of N hours (h), days (d), weeks (w), months (m),
>> - or years (y). The following shows up in the agenda every Wednesday:
>> + a certain interval of N days (d), weeks (w), months (m), or years
>> + (y). The following shows up in the agenda every Wednesday:
>
> Why did you remove hours?
Oh! Another difference between org-guide and org-manual that came over
in trying to resync the two.
>> For more complex date specifications, Org mode supports using the
>> - special expression diary entries implemented in the
>> - [[info:emacs#Special Diary Entries][Emacs Calendar package]][fn:20].
>> - For example, with optional time:
>> + special expression diary entries implemented in the Emacs Calendar
>> + package. For example, with optional time:
>
> Why did you remove the links and the footnote?
Again, another diff between org-guide and org-manual, :-\
I'm relooking at this patch. Testing finds that these work in the
timegrid agenda as expected:
* <2023-02-03 Thu 10:00-11:00>--<2023-02-04 Fri 10:00-11:00>
** Can't mark one done -- you have to mark them all done
*** Kind of expected for this form
* <2023-02-03 Thu 10:00-11:00 +1d>
** Can you limit the number of repeats? If so, how?
** Marking it DONE removes current one from agenda
*** reasonable
I have to rethink section 8.1. With the above in mind, 8.1 is not quite
right, but it's more subtle than I thought. Not sure how in the weeds
it should get for a user's manual.
--
David Masterson
- Re: Is this proper time format?, (continued)
- Re: Is this proper time format?, David Masterson, 2023/06/05
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/08
- Re: Is this proper time format?, David Masterson, 2023/06/08
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/09
- Re: Is this proper time format?, David Masterson, 2023/06/09
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/10
- Re: Is this proper time format?,
David Masterson <=
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/11
- Re: Is this proper time format?, David Masterson, 2023/06/11
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/12
- Re: Is this proper time format?, David Masterson, 2023/06/11
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/11
- Re: Is this proper time format?, David Masterson, 2023/06/11
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/12
- Re: Is this proper time format?, David Masterson, 2023/06/12
- Re: Is this proper time format?, Ihor Radchenko, 2023/06/13
- Re: Is this proper time format?, David Masterson, 2023/06/14