[Top][All Lists]

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

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

From: Nicolas Goaziou
Subject: Re: [O] please read: bug when marking tasks done
Date: Sat, 12 Jan 2019 12:24:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)


cesar mena <address@hidden> 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
scheduled and deadlines, but also to plain time stamps. This is an
important feature.

However, this is not related to the commit we're talking about.

> they're plain lists that haven't changed after they've been written. one
> could use them for billing reports etc ...

Of course.

What I mean is Org has no way to know the meaning of the contents, or
what you want to do with them, if you don't put markers or some special
syntax somewhere.

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

The main question is: what to do with an "inactive time stamp with

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

> yes, i see where you're coming from. i like to keep it simple.
>   (setq org-for-mere-mortal t)

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.


Nicolas Goaziou

reply via email to

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