From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cody Goodman Subject: org-capture with :prepend t breaks :clock-resume functionality in 9.1.9 Date: Fri, 25 Oct 2019 12:35:44 -0500 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000cf1570595bf954a" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:46924) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iO3VI-0004Bp-D1 for emacs-orgmode@gnu.org; Fri, 25 Oct 2019 13:36:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iO3VG-0002j7-56 for emacs-orgmode@gnu.org; Fri, 25 Oct 2019 13:36:00 -0400 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:44737) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iO3VG-0002gb-0A for emacs-orgmode@gnu.org; Fri, 25 Oct 2019 13:35:58 -0400 Received: by mail-qt1-x835.google.com with SMTP id z22so4380545qtq.11 for ; Fri, 25 Oct 2019 10:35:56 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org --0000000000000cf1570595bf954a Content-Type: text/plain; charset="UTF-8" I found a bug and traced down relevant pieces of it, but haven't figured out how to fix the behavior of org-capture where `:prepend t` `:clock-resume` works with and clock data from `:clock-in t` is visible with: ``` (setq org-capture-templates '(("t" "Todo" entry (file+headline "file.org" "File") "* TODO %?" :clock-in t :clock-resume t))) ``` If you add prepend into the mix though: ``` (setq org-capture-templates '(("t" "Todo" entry (file+headline "file.org" "File") "* TODO %?" :clock-in t :clock-resume t :prepend t))) ``` You can no longer see the clocking data. Not the worst thing... right? Well, :clock-resume depends on the clock-data being before point-max of the capture buffer. Causing the part that resumes the previous clock to never fire in org-capture-finalize: ``` (and org-capture-clock-was-started org-clock-marker (eq (marker-buffer org-clock-marker) (buffer-base-buffer)) (>= org-clock-marker (point-min)) (< org-clock-marker (point-max))) ;; clock marker when :prepend t is past point-max ``` My versions are: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ /home/cody/.emacs.d/straight/build/org/) GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) --0000000000000cf1570595bf954a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I found a bug and traced down relevant pieces of it, but h= aven't figured out how to fix the behavior of org-capture where `:prepe= nd t`

`:clock-resume` works with and clock data from `:clock-in t` i= s visible with:

```
(setq org-capture-templates
'(("= t" "Todo" entry (file+headline "file.org" "File")
=C2=A0 "* TODO %?"=
=C2=A0 :clock-in t
=C2=A0 :clock-resume t)))
```

If yo= u add prepend into the mix though:

```
(setq org-capture-template= s
'(("t" "Todo" entry (file+headline "file.org" "File")
=C2=A0 &q= uot;* TODO %?"
=C2=A0 :clock-in t
=C2=A0 :clock-resume t
= =C2=A0 :prepend t)))
```

You can no longer see the clocking dat= a. Not the worst thing... right?

Well, :clock-resume depends on the = clock-data being before point-max of the capture buffer.

Causing the= part that resumes the previous clock to never fire in org-capture-finalize= :

```
(and org-capture-clock-was-started
=C2=A0 =C2=A0 org-c= lock-marker
=C2=A0 =C2=A0 (eq (marker-buffer org-clock-marker) (buffer= -base-buffer))
=C2=A0 =C2=A0 (>=3D org-clock-marker (point-min)) =C2=A0 =C2=A0 (< org-clock-marker (point-max))) ;; clock marker when = :prepend t is past point-max
```

My versions are:

Org mode= version 9.1.9 (release_9.1.9-65-g5e4542 @ /home/cody/.emacs.d/straight/bui= ld/org/)
GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3= .24.10)
--0000000000000cf1570595bf954a--