[O] Prepended list item captures get placed among LOGBOOK entries

[Bruce V Chiarelli]

Hello,

I'll explain the problem with this example:


* Run this in =emacs -Q= with the latest org
  #+BEGIN_SRC emacs-lisp
;(add-to-list 'load-path "~/build/org-mode/lisp")
;;; ensure we are using the latest Org

(setq org-capture-templates (quote (("x" "Testing" item
  (file+headline "~/org/Testing.org" "Test 
headline")
  "- %U Thoughts:" :prepend t
(setq org-log-into-drawer t)
  #+END_SRC

* TODO Test headline
  SCHEDULED: <2017-06-09 Fri +1d>
  :PROPERTIES:
  :LAST_REPEAT: [2017-06-08 Thu 12:11]
  :END:
  :LOGBOOK:
  - State "DONE"   from "TODO"   [2017-06-08 Thu 12:11]
  :END:
  - I would expect the capture to go immediately above this line, but it
goes in the drawer instead.


If I use org-capture with template "x", the entry is placed into the
LOGBOOK drawer above the state change line.

Of course, if org-log-into-drawer set to nil, there is no good way of
keeping the state change list and the capture list separate at all (nor
should there be, IMO, as long as org-habit doesn't get confused). But at
least with the logbook drawer enabled, the current behavior seems wrong.

Re: [O] Insert datetree entry

[Bruce V Chiarelli]

Daniele Nicolodi writes:

> On 4/4/17 1:25 PM, Bruce V Chiarelli wrote:
>>
>> Daniele Nicolodi <dani...@grinta.net> writes:
> Hi Bruce,
>
> I modified your code as follow to be able to insert a datetree entry
> correctly being anywhere in an existing datetree. I also added the
> possibility of having a prefix argument to prompt for the date. It works
> for me, but I don't know if this is the most elegant way to obtain what
> I want. Comments are welcome.
>
>
> ;; look for datetree root
> (defun dnn-org-datetree-root ()
>   (let ((re
> "^\\([12][0-9]\\{3\\}\\)\\(-\\([01][0-9]\\)\\(-\\([0123][0-9]\\)\\)?\\)?
> \\w+$"))
> (while (string-match re (org-get-heading))
>   (org-up-heading-safe))
> (org-up-heading-safe)))
>
> ;; add a datetree entry
> (defun dnn-org-datetree-find-create (arg)
>   (interactive "P")
>   (let ((d (calendar-gregorian-from-absolute
>   (if arg (time-to-days (org-read-date nil t)) (org-today)
> (dnn-org-datetree-root)
> (org-datetree-find-date-create d 'subtree-at-point)))

Nice! I'm afraid I'm unqualified to give any comments/criticism on your
code, since I'm fairly new to elisp myself. Looks better than what I had
though, at least to work around the missing 'subtree-at-point
feature. Maybe someone else can chime in.

I did notice that with my function, org-up-heading-safe didn't always
behave the way I wanted it to (like if it was already *on* the root
headline). But I only needed the function a few times, so I didn't
bother with improving it.

> Cheers,
> Daniele
Best,
Bruce

Re: [O] Insert datetree entry

[Bruce V Chiarelli]

Daniele Nicolodi <dani...@grinta.net> writes:

>
> thanks for the hint, but I don't understand what `subtree-at-point` is
> in your code, it does not seem to be defined in my emacs and
> `org-datetree-find-date-create` has a third parameter that is
> interpreted as a boolean. I'm confused.

Ah, yes I forgot that this is a fairly new feature. Sorry for the
confusion. In the latest Org, the optional keep-restriction parameter can be

- t - make the datetree at the end of the current /view/ of the buffer,
- nil - make the datetree at the end of the file, even if it was narrowed
  to a subtree before, or
- 'subtree-at-point - put the datetree as a subheading at the end of the
  current heading. This one is new in Org 9.0.5.

The first two options have been around for a long time, so if you get
rid of 'subtree-at-point it should be fine. It will default to nil.

>
> Cheers,
> Daniele


--
Bruce V. Chiarelli
http://github.com/bccomm

Re: [O] Insert datetree entry

[Bruce V Chiarelli]

Daniele Nicolodi writes:

> Hello,
>
> there is a way in org-mode to insert a datetree entry without going
> through the org-capture?  Ideally the function would jump to the
> datetree and inser an headline for the current day if one is not
> present, or move to the end of it if one is present.
>
> I haven't found anything like this in the manual. I'm now digging in the
> code. Hopefully it is not something too hard to implement with my
> lacking elisp knowledge.

I don't believe there really is one, but I've had to do it a couple of
times myself. This is my solution (I'm not a lisp expert either, but it
did the job):

(defun bc/org-new-datetree-at-point
   (interactive)
   (org-up-heading-safe)
   (org-datetree-find-date-create
 (calendar-gregorian-from-absolute (org-today))
 'subtree-at-point))

This will make the datetree as a subheading of the current heading (or
find it if it already exists). Getting rid of 'subtree-at-point will
make the year a level 1 heading at the end of the file, like with
org-capture.

Bruce

--
Bruce V. Chiarelli
http://github.com/bccomm

Re: [O] Help needed tangling with orgmode v9

[Bruce V Chiarelli]

Guido Van Hoecke  writes:

> Hi,
>

Hi there,

> So I changed the #+PROPERTY lines into:
>
> #+PROPERTY:  header-args  :tangle emacs-guivho.el
> #+PROPERTY:  header-args  :padline yes
> #+PROPERTY:  header-args  :eval never
> #+PROPERTY:  header-args  :eval no
> #+PROPERTY:  header-args  :exports code
>

Just had the same problem myself not too long ago. It should be

#+PROPERTY:  header-args   :tangle emacs-guivho.el
#+PROPERTY:  header-args+  :padline yes
#+PROPERTY:  header-args+  :eval never
#+PROPERTY:  header-args+  :eval no
#+PROPERTY:  header-args+  :exports code

Be sure also to hit C-c somewhere in the header after updating them too,
so that Org is aware of the change.

Bruce Chiarelli

Re: [O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Bruce V. Chiarelli]

2016-10-31 17:04 GMT-07:00 Nicolas Goaziou <m...@nicolasgoaziou.fr>:
> "Bruce V. Chiarelli" <mano...@gmail.com> writes:
>
>> org-todo calls org-auto-repeat-maybe, which sees the ".+" style
>> repeater. It calls org-timestamp-change to move the timestamp up to
>> today. Point is left at the closing bracket. So far, so good.
>>
>> org-timestamp-change sets origin-cat to 'after and origin to (point).
>> It then changes the timestamp to today as advertized.
>>
>> Now these lines get evaluated
>>
>> (goto-char (cond
>> ;; `day' category ends before `hour' if any, or at
>> ;; the end of the day name.
>> ((eq origin-cat 'day)
>>  (min (or (match-beginning 7) (- (match-end 5) 2)) origin))
>> ((eq origin-cat 'hour) (min (match-end 7) origin))
>> ((eq origin-cat 'minute) (min (1- (match-end 8)) origin))
>> ((integerp origin-cat) (min (1- (match-end 0)) origin))
>> ;; `year' and `month' have both fixed size: point
>> ;; couldn't have moved into another part.
>> (t origin
>>
>> The since origin-cat is 'after, matching nothing else, we get
>> (goto-char origin).
>>
>> This seems to be where the problem lies. When "<2016-10-29 szo .+1>"
>> becomes "<2016-10-31 h .+1>" (today), origin is now two characters
>> ahead of where it should be, now on the next line in fact.
>
> I see. Thank you for the analysis.
>
> Does adding the following branch in the `cond' above, before the
> catch-all one, solves the issue?
>
>   ((eq origin-cat 'after) (match-end 0))

It does! Wonderful.

-BC

Re: [O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Bruce V. Chiarelli]

2016-10-31 8:23 GMT-07:00 Nicolas Goaziou <m...@nicolasgoaziou.fr>:
> Hello,
>
> "Bruce V. Chiarelli" <mano...@gmail.com> writes:
>
>> I've noticed some unusual behavior with repeating entries when the
>> system-time-locale variable is set. Specifically:
>>
>> It is Sunday, today, October 30th. I did not mark this task, which is
>> a habit, yesterday.
>>
>> -- If I have (setq system-time-locale "hu_HU.utf8"), Hungarian, then
>> marking this task DONE
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-29 szo .+1d>
>>
>> vbecomesv
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-30 v .+1d>
>>
>> Which is not correct. I marked it DONE today, so it should repeat tomorrow.
>>
>> -- If I have (setq system-time-locale "es_MX.utf8"), Mexican Spanish,
>> then doing the same thing:
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-29 szo .+1d>
>>
>> vbecomesv
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-31 lun .+1d>
>>
>> Which *is* correct. I have tried this with an unset
>> system-time-locale, and with it set to fa_IR, es_MX, en_GB, and hu_HU.
>> So far, hu_HU is the only one that behaves incorrectly. Note that it
>> doesn't seem to matter which language the day-of-the-week abbreviation
>> is already in, since every time I tried this, I reverted the file back
>> to the Hungarian line. Changing the date to <2016-10-29 Sat .+1d>
>> before marking it also had no effect.
>>
>> Of course, I could just set the date locale to "C" or unset it, but
>> there's still a bug somewhere.
>
> I tend to think this is not a bug in Org mode, since it correctly work
> with other locales, and we do not control locales.

I thought so too, to be honest, but I got my hands dirty and I think
I've figured out where the actual problem lies.

I did the bisect earlier, and the breaking change was right when the
code to handle native language day names was added as part of Org 8.0.
I got a bit disorganized and lost the exact commit, but I can try to
find it if need be. Anyway, I started the lisp debugger to trace what
was happening and found the real problem. I hope someone can confirm.

org-todo calls org-auto-repeat-maybe, which sees the ".+" style
repeater. It calls org-timestamp-change to move the timestamp up to
today. Point is left at the closing bracket. So far, so good.

org-timestamp-change sets origin-cat to 'after and origin to (point).
It then changes the timestamp to today as advertized.

Now these lines get evaluated

(goto-char (cond
;; `day' category ends before `hour' if any, or at
;; the end of the day name.
((eq origin-cat 'day)
 (min (or (match-beginning 7) (- (match-end 5) 2)) origin))
((eq origin-cat 'hour) (min (match-end 7) origin))
((eq origin-cat 'minute) (min (1- (match-end 8)) origin))
((integerp origin-cat) (min (1- (match-end 0)) origin))
;; `year' and `month' have both fixed size: point
;; couldn't have moved into another part.
(t origin

The since origin-cat is 'after, matching nothing else, we get
(goto-char origin).

This seems to be where the problem lies. When "<2016-10-29 szo .+1>"
becomes "<2016-10-31 h .+1>" (today), origin is now two characters
ahead of where it should be, now on the next line in fact.

So it returns fine at first, but when org-auto-repeat maybe calls
org-timestamp-change a second time to move the date into the future,
it throws the error "Not at a timestamp" and does nothing else. I
wasn't seeing this error until I was in the debugger, since
org-auto-repeat-maybe puts an "Entry repeats: ..." message in the echo
area. Oddly enough, that message shows the correct date since
org-last-changed-timestamp gets updated properly.

-BC

> Anyway, could you try bisecting and tell us when the bug was born?
>
> Regards,
>
> --
> Nicolas Goaziou

[O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Bruce V. Chiarelli]

Hello all,

I've noticed some unusual behavior with repeating entries when the
system-time-locale variable is set. Specifically:

It is Sunday, today, October 30th. I did not mark this task, which is
a habit, yesterday.

-- If I have (setq system-time-locale "hu_HU.utf8"), Hungarian, then
marking this task DONE

* TODO Anki basic reviews   :habit:study:
  SCHEDULED: <2016-10-29 szo .+1d>

vbecomesv

* TODO Anki basic reviews   :habit:study:
  SCHEDULED: <2016-10-30 v .+1d>

Which is not correct. I marked it DONE today, so it should repeat tomorrow.

-- If I have (setq system-time-locale "es_MX.utf8"), Mexican Spanish,
then doing the same thing:

* TODO Anki basic reviews   :habit:study:
  SCHEDULED: <2016-10-29 szo .+1d>

vbecomesv

* TODO Anki basic reviews   :habit:study:
  SCHEDULED: <2016-10-31 lun .+1d>

Which *is* correct. I have tried this with an unset
system-time-locale, and with it set to fa_IR, es_MX, en_GB, and hu_HU.
So far, hu_HU is the only one that behaves incorrectly. Note that it
doesn't seem to matter which language the day-of-the-week abbreviation
is already in, since every time I tried this, I reverted the file back
to the Hungarian line. Changing the date to <2016-10-29 Sat .+1d>
before marking it also had no effect.

Of course, I could just set the date locale to "C" or unset it, but
there's still a bug somewhere.

I am running the 1399f5 revision now, but I can reproduce this
behavior all the way back until version 7,

Cheers,
Bruce V C