emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: John Lee <jjl@pobox.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-habit: allow overriding org-scheduled-past-days and always including time of day
Date: Sat, 02 Feb 2019 18:50:27 +0000	[thread overview]
Message-ID: <1549133427.1633527.1649374424.31A6A12F@webmail.messagingengine.com> (raw)
In-Reply-To: <87k1ladke0.fsf@nicolasgoaziou.fr>

On Sun, 18 Nov 2018, at 23:40, Nicolas Goaziou wrote:
> Hello,

Hi, sorry Nicolas I totally missed your review comments!

> John Lee <jjl@pobox.com> writes:

For context since it's months ago now:

> > My own workflow around this is similar to GTD, so I'm using SCHEDULED
> > as basically a way to get TODO items to show up after the scheduled
> > date, not to show up in the calendar except as a reminder that I have
> > new TODOs. For that reason I set org-scheduled-past-days to a low
> > value (3 right now). I also set org-agenda-todo-ignore-scheduled to
> > 'future and org-agenda-tags-todo-honor-ignore-options to t (not
> > directly relevant here except as context). For habits that causes
> > habits not to show up sometimes because of the short
> > org-scheduled-past-days, which isn't appropriate for my habits: if
> > I say .+5d, I still want to see the habit there if it's due, even if
> > it's been 4 days since the last done date (which is more than the
> > 3 days of org-scheduled-past-days). This motivates
> > `org-habit-scheduled-past-days'.
> 
> It sounds reasonable.
> 
> > Similarly, since I want to do some of my habits at a particular time
> > of day, org-agenda's omitting of the time of day from the scheduled
> > timestamp if this is a "repeat" (i.e. I missed doing the habit) is
> > unhelpful for habits, because now I have to scan though a long-ish
> > list of habits (5 or 10 right now!) and think "is now the right time,
> > should I have done that already?" for every habit in the list, rather
> > than just eyeballing it to see which ones are around now in time. This
> > motivates `org-habit-always-show-time'.
> 
> It sounds good too. However, I wonder if that shouldn't be the default.
> Hiding the time for a missed scheduled item hadn't the habits in mind
> (see http://lists.gnu.org/archive/html/emacs-orgmode/2016-11/msg00539.html).
> 
> To put it differently, is there any workflow wanting to hide the time
> for habits in this case?

I don't know.  There's always somebody :-)  Perhaps nobody has filed an issue before because some people find the current behaviour useful -- but perhaps it's only because nobody uses times for habits, maybe because of this very issue.

Trying hard to make up a reason for utility of the current behaviour: let's say your habits tend to be weekly and have an optimum time and weekday, but if you miss them it's just "as soon as possible".  But if anybody actually does see their habits that way, that would seem likely to vary by habit.  So I'd be surprised if the current behaviour was very useful.

Shall I make it the default, then?


> > I have not yet submitted the FSF copyright assignment form but am
> > prepared to do so.
> 
> This can go as a TINYCHANGE (you need to put that string at the end of
> the commit messages).
> 
> However, if you plan to be able to provide more code to Org, I suggest
> starting the copyright assignment nonetheless.

Thank you.  Right now I have one other change I'd like to submit which is also tiny, do I need to start the assignment process?


> > +(defcustom org-habit-scheduled-past-days nil
> > +  "Non-nil means the value of this variable will be used instead
> > +of org-scheduled-past-days, for habits only.
> 
> First line needs to be a full sentence. Also,

To me it looks like a full sentence?  Should it be something like this below (based on looking at other docstrings)?

"Value to use instead of `org-scheduled-past-days', for habits only.

If nil, `org-scheduled-past-days' is used."


> > +TODO items on a particular date, rather than as a means of
> > +creating calendar-based reminders."
> 
> as a mean of...

I think "as a mean of" is not correct English (I'm a native speaker in the UK).


> > +  :group 'org-habit
> > +  :type 'integer)
> 
> You need to add :package-version and :safe keywords.

Presumably I should use the version from the highest current git tag "plus one", i.e. 9.3?

    :package-version '(Org . "9.3")


Thanks for your comments

  reply	other threads:[~2019-02-02 19:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05  0:31 org-habit: allow overriding org-scheduled-past-days and always including time of day John Lee
2018-11-05 13:01 ` [PATCH] " John Lee
2018-11-18 23:40 ` Nicolas Goaziou
2019-02-02 18:50   ` John Lee [this message]
2019-02-02 21:45     ` Nicolas Goaziou
2019-02-03 15:53   ` John Lee

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=1549133427.1633527.1649374424.31A6A12F@webmail.messagingengine.com \
    --to=jjl@pobox.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /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).