emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] please read: bug when marking tasks done


From: cesar mena
Subject: Re: [O] please read: bug when marking tasks done
Date: Sat, 12 Jan 2019 09:23:19 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

hello,

Nicolas Goaziou <address@hidden> 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 timestamps with repeaters do not update unless they are
>> marked as you suggest.  this way current workflows are not affected and
>> inactive timestamps can be made to update if requested.
>
> The other way around is not possible because =...= means "verbatim".
> This would be contradictory.

i see. i didn't know =...= meant verbatim. so in light of this new
knowledge :) your solution makes a lot of sense. i was originally
opposed to it because it means current documents will have to change to
add =...= but in the end it seems the simplest. 

> The main question is: what to do with an "inactive time stamp with
> repeater".
>
> The original report, that lead to the incriminated commit, emphasized
> the "repeater" part, arguing a repeater should induce the time stamp is
> meant to be repeated, notwithstanding its nature.
>
> You are emphasizing the "inactive" part of it, arguing that anything
> inactive should not change dynamically.
>
> Both arguments can be heard. I agree yours is more conservative. Yet,
> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
> OP.

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]

> I'm trying to keep Org as simple as possible, but different users have
> different use cases, and, in some annoying situations like this one,
> these use cases conflict.

we are ever grateful.

best,
-cm




reply via email to

[Prev in Thread] Current Thread [Next in Thread]