all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: cesar mena <cesar.mena@gmail.com>
Cc: Leo Gaspard <orgmode@leo.gaspard.io>,
	emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: please read: bug when marking tasks done
Date: Sat, 12 Jan 2019 12:24:43 +0100	[thread overview]
Message-ID: <87y37qxgn8.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87muo88up0.fsf@gnu.org> (cesar mena's message of "Thu, 10 Jan 2019 09:15:55 -0500")

Hello,

cesar mena <cesar.mena@gmail.com> 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
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.

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

Regards,

-- 
Nicolas Goaziou

  reply	other threads:[~2019-01-12 11:24 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
2019-01-12 11:24             ` Nicolas Goaziou [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y37qxgn8.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=cesar.mena@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=orgmode@leo.gaspard.io \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.