emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: cesar mena <cesar.mena@gmail.com>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: please read: bug when marking tasks done
Date: Thu, 10 Jan 2019 09:15:55 -0500	[thread overview]
Message-ID: <87muo88up0.fsf@gnu.org> (raw)
In-Reply-To: 87y37tzbrd.fsf@nicolasgoaziou.fr


hi nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> cesar mena <cesar.mena@gmail.com> 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 *deadline/scheduled time stamps to new date*
>>   |
>>   |  ...
>>   |-----------------------------------------------------------------
>>
>> thus we should not programmatically modify an arbitrary date in a
>> document just because it has a repeater. specially not one buried 300
>> lines deep in a :LOGBOOK: drawer.
>>
>> commit af81211fdc contradicts the established documentation.
>
> No, it doesn't. "current headline" is to be taken broadly, i.e., in the
> headline or the adjacent section. So, it doesn't matter if a time stamp
> is buried somewhere in the section: it is meant to be updated. 

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.

> Note that it was already the case for active time stamps before said
> commit.

wow! 10 years using org and i didn't know this. 

> For Org syntax, there is no such thing as a state-change entry. They are
> just plain lists. You could write anything in them.

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

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

>> an existing entry should not change because one marks a task as DONE.
> I disagree. This has always been the case, at least for active
> time-stamps.

yes, i see where you're coming from. i like to keep it simple.

  (setq org-for-mere-mortal t)

best,
-cm

  reply	other threads:[~2019-01-10 14:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-06  0:13 please read: bug when marking tasks done cesar mena
2019-01-06 23:49 ` Nicolas Goaziou
2019-01-07 14:52   ` Bernt Hansen
2019-01-07 15:20   ` cesar mena
2019-01-08 10:24     ` Nicolas Goaziou
2019-01-08 14:29       ` Bernt Hansen
2019-01-08 20:07       ` cesar mena
2019-01-09 22:50         ` Nicolas Goaziou
2019-01-10 14:15           ` cesar mena [this message]
2019-01-12 11:24             ` Nicolas Goaziou
2019-01-12 14:23               ` cesar mena
2019-01-12 19:37                 ` Samuel Wales
2019-01-12 21:02                   ` Samuel Wales
2019-01-13 15:00                   ` Nicolas Goaziou
2019-01-13 20:16                 ` Nicolas Goaziou
2019-01-13 21:52                   ` Samuel Wales
2019-01-15 14:24                     ` Bernt Hansen
2019-01-15 16:43                   ` cesar mena
2019-01-15 23:11                     ` Samuel Wales
2019-01-15 23:18                       ` Samuel Wales
2019-01-27 21:08                       ` Nicolas Goaziou
2019-01-29 14:58                         ` Robert Horn
2019-01-30 12:22                         ` cesar mena
2019-01-30 21:52                           ` Nicolas Goaziou
2019-01-31 10:25                             ` cesar mena
2019-01-31 23:17                               ` Samuel Wales

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=87muo88up0.fsf@gnu.org \
    --to=cesar.mena@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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