sounds like a reasonable fix.
hello,
Nicolas Goaziou writes:
> Hello,
>
> cesar mena writes:
>
>> Nicolas Goaziou writes:
>>> However, we still need to move forward. So, I suggest to revert the
>>> change about inactive timestamps. Inactive timestamps cannot be
>>> repeated. This is less disruptive than the current
Hello,
cesar mena writes:
> Nicolas Goaziou writes:
>> However, we still need to move forward. So, I suggest to revert the
>> change about inactive timestamps. Inactive timestamps cannot be
>> repeated. This is less disruptive than the current situation.
>
> yes, agreed.
Done in maint.
>>
Nicolas Goaziou writes:
> Hello,
>
> Samuel Wales writes:
>
>> commented repeater cookies does not have any of the above drawbacks.
>> it might require a 3rd party tool to update its re if that tool uses
>> repeaters. this is not unprecedented. the inactive repeater feature
>> might already
Nicolas Goaziou writes:
> However, I also suggest to add a new hook, run after repeating
> timestamps. With this hook, and a proper, user-specific, markup, it
> should be possible to pick inactive timestamps in the section and
> "repeat" them manually, i.e., on a case-by-case basis.
>
> WDYT?
>
Hello,
Samuel Wales writes:
> commented repeater cookies does not have any of the above drawbacks.
> it might require a 3rd party tool to update its re if that tool uses
> repeaters. this is not unprecedented. the inactive repeater feature
> might already require a 3rd party tool to update
[correction: never mind the ranges part.]
some possibly obvious observations:
nobody will want repeating inactive to be changed by org for the bug
case. those are sacrosanct in that sense.
but if the variable solution is chosen as the sole solution, setting
it to allow changed inactive repeaters will make logbooks no longer
reliable.
hello,
On Sun, Jan 13, 2019 at 3:16 PM Nicolas Goaziou
wrote:
> Hello,
>
> cesar mena writes:
>
> > i'm ok going with the verbatim syntax - rescheduled lines will now look
> > like (w/o the double quotes?):
> >
> > - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>
>
Samuel Wales writes:
> dunno best solution.
>
> another option is to comment out repeater intervals like ;.+2d instead
> of .+0d or =[... .+2d]=.
>
> this would also allow you to know what the interval was [currently
> that information is lost]. it would avoid overloading face. it would
> be
dunno best solution.
another option is to comment out repeater intervals like ;.+2d instead
of .+0d or =[... .+2d]=.
this would also allow you to know what the interval was [currently
that information is lost]. it would avoid overloading face. it would
be under user control for every ts. it
Hello,
cesar mena writes:
> i'm ok going with the verbatim syntax - rescheduled lines will now look
> like (w/o the double quotes?):
>
> - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
Thinking about it, another possibility is to add a variable, e.g.,
Hello,
Samuel Wales writes:
> manual> Text in the code and
> verbatim string is not processed for Org mode specific syntax, it is
> exported verbatim.
>
> i assumed that meant /during export/.
Only the second part of the sentence refers to exporting. The current
wording is the following, note
there is a related bug.
when there are multiple repeaters, closing a task with -1 can only
zero the first.
probably it should zero all mutable repeaters.
* MOOT hi
CLOSED: [2019-01-12 Sat 13:54]
<2019-01-13 Sun .+0d>
<2019-01-13 Sun .+1d>
=<2019-01-12 Sat .+1d>=
~<2019-01-12 Sat .+1d>~
hi
manual> Text in the code and
verbatim string is not processed for Org mode specific syntax, it is
exported verbatim.
i assumed that meant /during export/. it is in the markup section.
thus, someplace in manual, perhaps say that verbatim and code have
more effects than just export.
On 1/12/19,
hello,
Nicolas Goaziou writes:
>>> Now, we might make its contents by marking them as verbatim, for
>>> example. E.g.,
>>>
>>> - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>>
>> that's not a bad idea, but what about the other way round?
>>
>> that is, inactive
Hello,
cesar mena writes:
> ok, so "current headline" is taken broadly. but what about the
> deadline/scheduled part? what makes a time stamp "deadline/scheduled"?
> those are the ones that should change as per the doc.
You are right the docstring is inaccurate here. It is not limited to
hi nicolas,
Nicolas Goaziou writes:
> Hello,
>
> cesar mena writes:
>
>> from the docstring:
>>
>> |--- org-auto-repeat-maybe
>> | Check if the *current headline* contains a repeated time-stamp.
>> |
>> | If yes, set TODO state back to what
Hello,
cesar mena writes:
> from the docstring:
>
> |--- org-auto-repeat-maybe
> | Check if the *current headline* contains a repeated time-stamp.
> |
> | If yes, set TODO state back to what it was and change the base date
> | of repeating
hello nicolas,
Nicolas Goaziou writes:
> Hello,
>
> cesar mena writes:
>
>> as per the documentation for "org-auto-repeat-maybe" only the base date
>> of repeating deadline/scheduled time stamps should change. AFAICT the
>> patch changes every occurrence of an inactive repeating timestamp that
Nicolas Goaziou writes:
> Anyway, I don't really have any other idea besides dropping the repeater
> part from automatically inserted inactive time stamps.
When I unschedule (and log) a habit I don't want to lose the detail
about the repeat interval. My workaround for this is to break the
Hello,
cesar mena writes:
> as per the documentation for "org-auto-repeat-maybe" only the base date
> of repeating deadline/scheduled time stamps should change. AFAICT the
> patch changes every occurrence of an inactive repeating timestamp that is
> not a comment.
The base date of a time stamp
hi nicolas,
Nicolas Goaziou writes:
> Hello,
>
> cesar mena writes:
>
>> hello everyone,
>>
>> in the maint branch, marking a repeatable task as DONE causes the
>> "Rescheduled from" dates to be lost in the :LOGBOOK:.
>>
>> in the below diff all of the from dates are rewritten with the new
>>
Nicolas Goaziou writes:
> Hello,
>
> cesar mena writes:
>
>> hello everyone,
>>
>> in the maint branch, marking a repeatable task as DONE causes the
>> "Rescheduled from" dates to be lost in the :LOGBOOK:.
>>
>> in the below diff all of the from dates are rewritten with the new
>> scheduled
Hello,
cesar mena writes:
> hello everyone,
>
> in the maint branch, marking a repeatable task as DONE causes the
> "Rescheduled from" dates to be lost in the :LOGBOOK:.
>
> in the below diff all of the from dates are rewritten with the new
> scheduled date:
>
> - SCHEDULED: <2018-12-04
hello everyone,
in the maint branch, marking a repeatable task as DONE causes the
"Rescheduled from" dates to be lost in the :LOGBOOK:.
in the below diff all of the from dates are rewritten with the new
scheduled date:
- SCHEDULED: <2018-12-04 Tue .+1m>
+ SCHEDULED: <2019-02-05
26 matches
Mail list logo
