On Fri, 08 Oct 2010 15:01:49 -0400, Bernt Hansen <bernt@norang.ca> wrote:
> 
> Eric S Fraga <ucecesf@ucl.ac.uk> writes:
> 
> > Recently, but I cannot say for how long, I have found that dates
> > entered, for instance using "j" in the standard agenda view, no longer
> > choose a time/day in the future but seem to default to the current
> > year.  For instance, today, typing "j 2 feb RET" (with a real space
> > between 2 and feb) jumps me to 2010 February 2, not 2011.

[...]

> 
> Hi Eric,
> 
> This was recently changed in commit
> 03b178d (Do not prefer future when jumping to a date in the agenda, 2010-09-21)
> by Carsten after an offline discussion with me.
> 
> The behaviour changed for the 'j' command in the agenda only but not for
> other date prompts.

Ah, okay, so I am not totally losing it... ;-)

> The justification for this was at the start of a new month you need to
> enter the year to go back to a date a week or two ago in the agenda
> which seemed inconvenient.
> 
> Carsten noticed that I had set org-read-date-prefer-future to nil in
> http://doc.norang.ca/org-mode.html and questioned why that was
> necessary.  After a short discussion he decided to change the default
> behaviour for the agenda j command only.
> 
> Please comment on whether this change is good or bad.  The docstring
> should be more clear about this change if we decide to keep it.
> 
> Regards,
> Bernt

Well, I must say that I prefer the old way as it is more likely (on a
simple probabilistic view considering the full twelve months of the
year) that I am going to want a future date if I refer to a month
before the current one.  I can understand your justification for
earlier in a month but I typically simply use, say, -7 or -10 then (as
I use +7 or +10 say for days in the future).  So, I guess my view is
that the change is more bad than good...  At the very least, I would
like this to be configurable, if that is at all possible?  If not, I
am sure I can adjust!

By the way, I guess I could see an argument for a date alone being for
the current month, whether future or past, much as time can be
considered already to be for the current day, whether future or past,
if the variable is configured as I have it (time), but even then we
should have a configurable variable?

Regardless, the docs definitely have to change!

Thanks,
eric