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

Hi, sorry Nicolas I totally missed your review comments!

> John Lee <j...@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 

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 via email to