Re: S-left / S-right with (double) prefix C-u without scheduled time (only date)

2020-11-02 Thread Kyle Meyer
Martin Rottensteiner writes:

> In my setup in org 9.4 the behaviour is like this for a scheduled date
> without scheduled time (for example SCHEDULED: <2020-10-27>:
> C-u S-left: Date changes to date before (26th)
> C-u S-right: Date does not change
> C-u C-u S-left: Date changes to date before (26th)
> C-u C-u: S-right: Date does not change

Hmph, that discrepancy between left and right is odd...

Underneath org-timestamp-change is being called with WHAT as hour or
minute.  Regardless of whether the timestamp has a time, it's doing

(setq time
  (apply #'encode-time
 (or (car time0) 0)
 (+ (if (eq timestamp? 'minute) n 0) (nth 1 time0))
 (+ (if (eq timestamp? 'hour) n 0) (nth 2 time0))
 (+ (if (eq timestamp? 'day) n 0) (nth 3 time0))
 (+ (if (eq timestamp? 'month) n 0) (nth 4 time0))
 (+ (if (eq timestamp? 'year) n 0) (nth 5 time0))
 (nthcdr 6 time0)))

So that explains why left shifts the date, as it's essentially starting
from 00:00.

> I would prefer this behaviour instead (my proposal):
> C-u S-left: Add a default time (e.g. 6:00)
> C-u S-right: Add a default time (e.g. 6:00)
> C-u C-u S-left: Add a default time (e.g. 6:00)
> C-u C-u: S-right: Add a default time (e.g. 6:00)

C-u+ is an explicit request to operate on a time part, so that sounds
sensible to me.

> Scheduled date+time Timestamps can afterwards be changed as expected with
> C-u prefix(es).

Yes, and, based on the current design, it should even work without a
prefix for successive calls.

> What I found out until now:
> ( org-schedule nil "12:00" ) adds a time 12:00 to a SCHEDULED date property.
> (if (< (length (org-entry-get nil "SCHEDULED")) 16) (print
> 'scheduled_time_missing) (print 'scheduled_time_existent))
> org-timestamp-has-time-p: could maybe better be used instead for finding
> out if time is not present.
>
> I think this would be a better default behaviour or the current behaviour
> might even be a bug.

I think the current behavior falls into the oversight/bug category,
especially given the left/right discrepancy.  Here's a minimal fix that
results in your desired behavior (assuming you don't have a preference
for any particular range of initial times).


diff --git a/lisp/org.el b/lisp/org.el
index 03df139fb..04089c6ec 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14964,7 +14964,8 @@ (defun org-timestamp-change (n &optional what updown 
suppress-tmp-delay)
(setq extra (match-string 1 ts))
(when suppress-tmp-delay
  (setq extra (replace-regexp-in-string " --[0-9]+[hdwmy]" "" extra
-  (when (string-match "^.\\{10\\}.*?[0-9]+:[0-9][0-9]" ts)
+  (when (or (memq what '(hour minute))
+   (string-match "^.\\{10\\}.*?[0-9]+:[0-9][0-9]" ts))
(setq with-hm t))
   (setq time0 (org-parse-time-string ts))
   (when (and updown



S-left / S-right with (double) prefix C-u without scheduled time (only date)

2020-10-30 Thread Martin Rottensteiner
Hi list,

i often use shift with left or right arrow keys to change the date in
org-(super-)agenda. These key combinations can be used with prefix C-u and
double prefix C-u C-u.

In my setup in org 9.4 the behaviour is like this for a scheduled date
without scheduled time (for example SCHEDULED: <2020-10-27>:
C-u S-left: Date changes to date before (26th)
C-u S-right: Date does not change
C-u C-u S-left: Date changes to date before (26th)
C-u C-u: S-right: Date does not change

I would prefer this behaviour instead (my proposal):
C-u S-left: Add a default time (e.g. 6:00)
C-u S-right: Add a default time (e.g. 6:00)
C-u C-u S-left: Add a default time (e.g. 6:00)
C-u C-u: S-right: Add a default time (e.g. 6:00)

Scheduled date+time Timestamps can afterwards be changed as expected with
C-u prefix(es).

What I found out until now:
( org-schedule nil "12:00" ) adds a time 12:00 to a SCHEDULED date property.
(if (< (length (org-entry-get nil "SCHEDULED")) 16) (print
'scheduled_time_missing) (print 'scheduled_time_existent))
org-timestamp-has-time-p: could maybe better be used instead for finding
out if time is not present.

I think this would be a better default behaviour or the current behaviour
might even be a bug.

   Thanks, Martin :)