Re: [O] [PATCH] Selectively archive by timestamp
On Sat, Dec 13, 2014 at 03:23:34PM +0100, Nicolas Goaziou wrote:
It's a fairly straightforward one, which simply adds a useful new
archiving function without touching much else.
Archiving by date seems such an obvious omission from the existing
archiving commands, I wouldn't have thought this patch was too
controversial. (Unless someone doesn't like the choice of keybinding, in
which case by all means change it!)
Looks good. Could you send it again so I can apply it?
Here it is again (attached).
Best,
Toby
--
Dr T. S. Cubitt
Royal Society University Research Fellow
Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge
email: ts...@cantab.net
web: www.dr-qubit.org
From 3183bcf9c005a0d5633dcc8be1719e55e3dfa8c5 Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Fri, 17 Jan 2014 15:14:13 +
Subject: [PATCH] Add org-archive-all-old to archive entries with timestamps
before today.
Can be invoked from org-archive-subtree command with double prefix-arg.
---
doc/org.texi| 4
lisp/org-archive.el | 68 +++--
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 7d98d51..d2e61a8 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7469,6 +7469,10 @@ the archive. To do this, each subtree is checked for open TODO entries.
If none are found, the command offers to move it to the archive
location. If the cursor is @emph{not} on a headline when this command
is invoked, the level 1 trees will be checked.
+@orgkey{C-u C-u C-c C-x C-s}
+As above, but check subtree for timestamps instead of TODO entries. The
+command will offer to archive the subtree if it @emph{does} contain a
+timestamp, and that timestamp is in the past.
@end table
@cindex archive locations
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 700e59b..418af3a 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -198,9 +198,11 @@ The archive can be a certain top-level heading in the current file, or in
a different file. The tree will be moved to that location, the subtree
heading be marked DONE, and the current time will be added.
-When called with prefix argument FIND-DONE, find whole trees without any
+When called with a single prefix argument FIND-DONE, find whole trees without any
open TODO items and archive them (after getting confirmation from the user).
-If the cursor is not at a headline when this command is called, try all level
+When called with a double prefix argument, find whole trees with timestamps before
+today and archive them (after getting confirmation from the user).
+If the cursor is not at a headline when these commands are called, try all level
1 trees. If the cursor is on a headline, only try the direct children of
this heading.
(interactive P)
@@ -213,8 +215,10 @@ this heading.
(org-archive-subtree ,find-done))
org-loop-over-headlines-in-active-region
cl (if (outline-invisible-p) (org-end-of-subtree nil t
-(if find-done
- (org-archive-all-done)
+(cond
+ ((equal find-done '(4)) (org-archive-all-done))
+ ((equal find-done '(16)) (org-archive-all-old))
+ (t
;; Save all relevant TODO keyword-relatex variables
(let ((tr-org-todo-line-regexp org-todo-line-regexp) ; keep despite compiler
(tr-org-todo-keywords-1 org-todo-keywords-1)
@@ -375,7 +379,7 @@ this heading.
(message Subtree archived %s
(if (eq this-buffer buffer)
(concat under heading: heading)
- (concat in file: (abbreviate-file-name afile))
+ (concat in file: (abbreviate-file-name afile)))
(org-reveal)
(if (looking-at ^[ \t]*$)
(outline-next-visible-heading 1
@@ -456,13 +460,50 @@ sibling does not exist, it will be created at the end of the subtree.
If the cursor is not on a headline, try all level 1 trees. If
it is on a headline, try all direct children.
When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
- (let ((re org-not-done-heading-regexp) re1
- (rea (concat .*: org-archive-tag :))
+ (org-archive-all-matches
+ (lambda (beg end)
+ (unless (re-search-forward org-not-done-heading-regexp end t)
+ no open TODO items))
+ tag))
+
+(defun org-archive-all-old (optional tag)
+ Archive sublevels of the current tree with timestamps prior to today.
+If the cursor is not on a headline, try all level 1 trees. If
+it is on a headline, try all direct children.
+When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
+ (org-archive-all-matches
+ (lambda (beg end)
+ (let (ts)
+ (and (re-search-forward org-ts-regexp end t)
+ (setq ts (match-string 0))
+ ( (org-time-stamp-to-now ts) 0)
+ (if (not (looking-at
+ (concat --\\( org-ts-regexp \\
+ (concat old timestamp ts)
+ (setq ts (concat old timestamp ts (match-string 0)))
+ (and (
Re: [O] [PATCH] Selectively archive by timestamp
On Tue, Dec 16, 2014 at 10:52:09PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
Here it is again (attached).
Thank you. However, could you provide an appropriate commit message
(functions modified, reason...)?
Sorry for not catching that earlier.
Sorry, not sure why I forgot to do that. Here's an updated version with
suitable commit message.
Best,
Toby
--
Dr T. S. Cubitt
Royal Society University Research Fellow
Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge
email: ts...@cantab.net
web: www.dr-qubit.org
From e4ad9035f2fe50d2f4272621453bf5761c5802fa Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Fri, 17 Jan 2014 15:14:13 +
Subject: [PATCH] org-archive.el: Add command to archive entries with
timestamps before today.
* lisp/org-archive.el (org-archive-all-old): archive all entries with
timestamps prior to today.
(org-archive-subtree): double prefix argument invokes
org-archive-all-old.
(org-archive-all-matches, org-archive-all-done): factor out common
code into org-archive-all-matches.
---
doc/org.texi| 4
lisp/org-archive.el | 68 +++--
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index d617259..10463ff 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7512,6 +7512,10 @@ the archive. To do this, each subtree is checked for open TODO entries.
If none are found, the command offers to move it to the archive
location. If the cursor is @emph{not} on a headline when this command
is invoked, the level 1 trees will be checked.
+@orgkey{C-u C-u C-c C-x C-s}
+As above, but check subtree for timestamps instead of TODO entries. The
+command will offer to archive the subtree if it @emph{does} contain a
+timestamp, and that timestamp is in the past.
@end table
@cindex archive locations
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 96ef021..3e14291 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -204,9 +204,11 @@ The archive can be a certain top-level heading in the current file, or in
a different file. The tree will be moved to that location, the subtree
heading be marked DONE, and the current time will be added.
-When called with prefix argument FIND-DONE, find whole trees without any
+When called with a single prefix argument FIND-DONE, find whole trees without any
open TODO items and archive them (after getting confirmation from the user).
-If the cursor is not at a headline when this command is called, try all level
+When called with a double prefix argument, find whole trees with timestamps before
+today and archive them (after getting confirmation from the user).
+If the cursor is not at a headline when these commands are called, try all level
1 trees. If the cursor is on a headline, only try the direct children of
this heading.
(interactive P)
@@ -219,8 +221,10 @@ this heading.
(org-archive-subtree ,find-done))
org-loop-over-headlines-in-active-region
cl (if (outline-invisible-p) (org-end-of-subtree nil t
-(if find-done
- (org-archive-all-done)
+(cond
+ ((equal find-done '(4)) (org-archive-all-done))
+ ((equal find-done '(16)) (org-archive-all-old))
+ (t
;; Save all relevant TODO keyword-relatex variables
(let ((tr-org-todo-line-regexp org-todo-line-regexp) ; keep despite compiler
(tr-org-todo-keywords-1 org-todo-keywords-1)
@@ -383,7 +387,7 @@ this heading.
(message Subtree archived %s
(if (eq this-buffer buffer)
(concat under heading: heading)
- (concat in file: (abbreviate-file-name afile))
+ (concat in file: (abbreviate-file-name afile)))
(org-reveal)
(if (looking-at ^[ \t]*$)
(outline-next-visible-heading 1
@@ -464,13 +468,50 @@ sibling does not exist, it will be created at the end of the subtree.
If the cursor is not on a headline, try all level 1 trees. If
it is on a headline, try all direct children.
When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
- (let ((re org-not-done-heading-regexp) re1
- (rea (concat .*: org-archive-tag :))
+ (org-archive-all-matches
+ (lambda (beg end)
+ (unless (re-search-forward org-not-done-heading-regexp end t)
+ no open TODO items))
+ tag))
+
+(defun org-archive-all-old (optional tag)
+ Archive sublevels of the current tree with timestamps prior to today.
+If the cursor is not on a headline, try all level 1 trees. If
+it is on a headline, try all direct children.
+When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
+ (org-archive-all-matches
+ (lambda (beg end)
+ (let (ts)
+ (and (re-search-forward org-ts-regexp end t)
+ (setq ts (match-string 0))
+ ( (org-time-stamp-to-now ts) 0)
+ (if (not (looking-at
+ (concat --\\( org-ts-regexp \\
+ (concat old timestamp ts)
+ (setq ts
Re: [O] [PATCH] Selectively archive by timestamp
Did this patch get lost in the noise?
It's a fairly straightforward one, which simply adds a useful new
archiving function without touching much else.
Archiving by date seems such an obvious omission from the existing
archiving commands, I wouldn't have thought this patch was too
controversial. (Unless someone doesn't like the choice of keybinding, in
which case by all means change it!)
Best,
Toby
On Mon, Sep 29, 2014 at 08:27:35PM +0100, Toby Cubitt wrote:
Sometimes I want to selectively archive all entries in a subtree with
timestamps in the past, whilst keeping all entries with timestamps in the
future.
`org-archive-subtree' only lets you selectively archive entries depending
on whether they have open TODO items.
The attached patch adds a new `org-archive-all-old' counterpart to
`org-archive-all-done' which does timestamp-selective archiving. It also
extends `org-archive-subtree' so it can optionally be invoked for
timestamp-based archiving instead of TODO-based archiving.
Toby
From 3183bcf9c005a0d5633dcc8be1719e55e3dfa8c5 Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Fri, 17 Jan 2014 15:14:13 +
Subject: [PATCH] Add org-archive-all-old to archive entries with timestamps
before today.
Can be invoked from org-archive-subtree command with double prefix-arg.
---
doc/org.texi| 4
lisp/org-archive.el | 68
+++--
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 7d98d51..d2e61a8 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7469,6 +7469,10 @@ the archive. To do this, each subtree is checked for
open TODO entries.
If none are found, the command offers to move it to the archive
location. If the cursor is @emph{not} on a headline when this command
is invoked, the level 1 trees will be checked.
+@orgkey{C-u C-u C-c C-x C-s}
+As above, but check subtree for timestamps instead of TODO entries. The
+command will offer to archive the subtree if it @emph{does} contain a
+timestamp, and that timestamp is in the past.
@end table
@cindex archive locations
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 700e59b..418af3a 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -198,9 +198,11 @@ The archive can be a certain top-level heading in the
current file, or in
a different file. The tree will be moved to that location, the subtree
heading be marked DONE, and the current time will be added.
-When called with prefix argument FIND-DONE, find whole trees without any
+When called with a single prefix argument FIND-DONE, find whole trees
without any
open TODO items and archive them (after getting confirmation from the user).
-If the cursor is not at a headline when this command is called, try all level
+When called with a double prefix argument, find whole trees with timestamps
before
+today and archive them (after getting confirmation from the user).
+If the cursor is not at a headline when these commands are called, try all
level
1 trees. If the cursor is on a headline, only try the direct children of
this heading.
(interactive P)
@@ -213,8 +215,10 @@ this heading.
(org-archive-subtree ,find-done))
org-loop-over-headlines-in-active-region
cl (if (outline-invisible-p) (org-end-of-subtree nil t
-(if find-done
- (org-archive-all-done)
+(cond
+ ((equal find-done '(4)) (org-archive-all-done))
+ ((equal find-done '(16)) (org-archive-all-old))
+ (t
;; Save all relevant TODO keyword-relatex variables
(let ((tr-org-todo-line-regexp org-todo-line-regexp) ; keep despite
compiler
(tr-org-todo-keywords-1 org-todo-keywords-1)
@@ -375,7 +379,7 @@ this heading.
(message Subtree archived %s
(if (eq this-buffer buffer)
(concat under heading: heading)
-(concat in file: (abbreviate-file-name afile))
+(concat in file: (abbreviate-file-name afile)))
(org-reveal)
(if (looking-at ^[ \t]*$)
(outline-next-visible-heading 1
@@ -456,13 +460,50 @@ sibling does not exist, it will be created at the end
of the subtree.
If the cursor is not on a headline, try all level 1 trees. If
it is on a headline, try all direct children.
When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
- (let ((re org-not-done-heading-regexp) re1
- (rea (concat .*: org-archive-tag :))
+ (org-archive-all-matches
+ (lambda (beg end)
+ (unless (re-search-forward org-not-done-heading-regexp end t)
+ no open TODO items))
+ tag))
+
+(defun org-archive-all-old (optional tag)
+ Archive sublevels of the current tree with timestamps prior to today.
+If the cursor is not on a headline, try all level 1 trees. If
+it is on a headline, try all direct children
[O] Selectively archive by timestamp
Sometimes I want to selectively archive all entries in a subtree with
timestamps in the past, whilst keeping all entries with timestamps in the
future.
`org-archive-subtree' only lets you selectively archive entries depending
on whether they have open TODO items.
The attached patch adds a new `org-archive-all-old' counterpart to
`org-archive-all-done' which does timestamp-selective archiving. It also
extends `org-archive-subtree' so it can optionally be invoked for
timestamp-based archiving instead of TODO-based archiving.
Toby
--
Dr T. S. Cubitt
Royal Society University Research Fellow
Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge
email: ts...@cantab.net
web: www.dr-qubit.org
From 3183bcf9c005a0d5633dcc8be1719e55e3dfa8c5 Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Fri, 17 Jan 2014 15:14:13 +
Subject: [PATCH] Add org-archive-all-old to archive entries with timestamps
before today.
Can be invoked from org-archive-subtree command with double prefix-arg.
---
doc/org.texi| 4
lisp/org-archive.el | 68 +++--
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 7d98d51..d2e61a8 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7469,6 +7469,10 @@ the archive. To do this, each subtree is checked for open TODO entries.
If none are found, the command offers to move it to the archive
location. If the cursor is @emph{not} on a headline when this command
is invoked, the level 1 trees will be checked.
+@orgkey{C-u C-u C-c C-x C-s}
+As above, but check subtree for timestamps instead of TODO entries. The
+command will offer to archive the subtree if it @emph{does} contain a
+timestamp, and that timestamp is in the past.
@end table
@cindex archive locations
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 700e59b..418af3a 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -198,9 +198,11 @@ The archive can be a certain top-level heading in the current file, or in
a different file. The tree will be moved to that location, the subtree
heading be marked DONE, and the current time will be added.
-When called with prefix argument FIND-DONE, find whole trees without any
+When called with a single prefix argument FIND-DONE, find whole trees without any
open TODO items and archive them (after getting confirmation from the user).
-If the cursor is not at a headline when this command is called, try all level
+When called with a double prefix argument, find whole trees with timestamps before
+today and archive them (after getting confirmation from the user).
+If the cursor is not at a headline when these commands are called, try all level
1 trees. If the cursor is on a headline, only try the direct children of
this heading.
(interactive P)
@@ -213,8 +215,10 @@ this heading.
(org-archive-subtree ,find-done))
org-loop-over-headlines-in-active-region
cl (if (outline-invisible-p) (org-end-of-subtree nil t
-(if find-done
- (org-archive-all-done)
+(cond
+ ((equal find-done '(4)) (org-archive-all-done))
+ ((equal find-done '(16)) (org-archive-all-old))
+ (t
;; Save all relevant TODO keyword-relatex variables
(let ((tr-org-todo-line-regexp org-todo-line-regexp) ; keep despite compiler
(tr-org-todo-keywords-1 org-todo-keywords-1)
@@ -375,7 +379,7 @@ this heading.
(message Subtree archived %s
(if (eq this-buffer buffer)
(concat under heading: heading)
- (concat in file: (abbreviate-file-name afile))
+ (concat in file: (abbreviate-file-name afile)))
(org-reveal)
(if (looking-at ^[ \t]*$)
(outline-next-visible-heading 1
@@ -456,13 +460,50 @@ sibling does not exist, it will be created at the end of the subtree.
If the cursor is not on a headline, try all level 1 trees. If
it is on a headline, try all direct children.
When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
- (let ((re org-not-done-heading-regexp) re1
- (rea (concat .*: org-archive-tag :))
+ (org-archive-all-matches
+ (lambda (beg end)
+ (unless (re-search-forward org-not-done-heading-regexp end t)
+ no open TODO items))
+ tag))
+
+(defun org-archive-all-old (optional tag)
+ Archive sublevels of the current tree with timestamps prior to today.
+If the cursor is not on a headline, try all level 1 trees. If
+it is on a headline, try all direct children.
+When TAG is non-nil, don't move trees, but mark them with the ARCHIVE tag.
+ (org-archive-all-matches
+ (lambda (beg end)
+ (let (ts)
+ (and (re-search-forward org-ts-regexp end t)
+ (setq ts (match-string 0))
+ ( (org-time-stamp-to-now ts) 0)
+ (if (not (looking-at
+ (concat --\\( org-ts-regexp \\
+ (concat old timestamp ts)
+ (setq ts (concat old timestamp ts (match-string 0)))
+ (and (
Re: [O] Bugs x2: fast tag selection broken, column view broken?
On Fri, Mar 29, 2013 at 12:10:10AM +, Toby Cubitt wrote: On Thu, Mar 28, 2013 at 10:29:06PM +0100, Bastien wrote: 2. Column view mode is completely broken for me. In old org files where column view used to work fine, I now just get grey boxes obscuring the headings, and nothing in the columns. I've attached a minimal example file, and a screenshot. I can't reproduce this one. Can you reproduce it with emacs -Q? Hmmm... I can't reproduce it from emacs -Q. Sorry, I should of course have checked this first before posting. Must be something in my config. I'll investigate and try to narrow down what exactly is causing it. This one's weird. It seems to be caused by an interaction between flyspell and org. I can reproduce it with the following minimal recipe (using the column-view.org file from my previous post, though enabling column view mode in any org file should reproduce the problem): 1. Create a .emacs with the following contents: (add-to-list ~/path/to/org-mode/lisp/) (require 'flyspell) (require 'org) 2. emacs --daemon 3. emacsclient -c column-view.org 4. C-c C-x C-c Reversing the order in which flyspell and org are loaded fixes the problem. I'm running a recent bzr version of Emacs, and a recent git version of Org mode. Best, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Centre for Quantum Information and Foundations DAMTP, University of Cambridge email: ts...@cantab.net web: www.dr-qubit.org
[O] Bugs x2: fast tag selection broken, column view broken?
I'm experiencing two unrelated new bugs in the latest git: 1. In agenda view, the list of fast-tag-selection keys in the `org-agenda-filter-by-tag' prompt is always empty, and fast tag selection no longer works. (I have fast-tag-selection keys configured in `org-tag-alist', and my `org-use-fast-tag-selection' is set to `auto'.) 2. Column view mode is completely broken for me. In old org files where column view used to work fine, I now just get grey boxes obscuring the headings, and nothing in the columns. I've attached a minimal example file, and a screenshot. Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Centre for Quantum Information and Foundations DAMTP, University of Cambridge email: ts...@cantab.net web: www.dr-qubit.org column-view.org Description: Lotus Organizer attachment: column-view.png
Re: [O] Bugs x2: fast tag selection broken, column view broken?
On Thu, Mar 28, 2013 at 10:29:06PM +0100, Bastien wrote: Hi Toby, Toby Cubitt ts...@cantab.net writes: I'm experiencing two unrelated new bugs in the latest git: 1. In agenda view, the list of fast-tag-selection keys in the `org-agenda-filter-by-tag' prompt is always empty, and fast tag selection no longer works. (I have fast-tag-selection keys configured in `org-tag-alist', and my `org-use-fast-tag-selection' is set to `auto'.) I fixed this. Thanks! 2. Column view mode is completely broken for me. In old org files where column view used to work fine, I now just get grey boxes obscuring the headings, and nothing in the columns. I've attached a minimal example file, and a screenshot. I can't reproduce this one. Can you reproduce it with emacs -Q? Hmmm... I can't reproduce it from emacs -Q. Sorry, I should of course have checked this first before posting. Must be something in my config. I'll investigate and try to narrow down what exactly is causing it. Best, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Centre for Quantum Information and Foundations DAMTP, University of Cambridge email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Tue, Nov 20, 2012 at 11:12:10AM -0500, Mike McLean wrote: On Sat, Nov 17, 2012 at 11:02 AM, Toby Cubitt ts...@cantab.net wrote: On Sat, Nov 17, 2012 at 03:42:24PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: I've replaced the cons cells with additional plist properties, as you suggested. The resulting customization ui still isn't wonderful in my opinion. But it does the job, and I'm not sure how much scope there is for improving it further. If you see a way, by all means feel free to make the changes yourself. I really don't mind what format you go with for org-time-clocksum-format, as long as it supports the new formatting features implemented in the patch. Considering I'm not an expert in customize ui, it's good enough as it is. OK. If someone thinks of a way to improve the customization ui (keeping the same data type), it's easy to change it later without breaking anything. I've applied your patch (with some small changes in a docstring). Thank you again for all that work. Glad we finally found a good implementation. Thanks to you for all your helpful feedback. I like the new implementation and customization options, but now when I do ~C-c C-x C-c~ to get a sub-tree time, I get nothing but zeros (~0d 0:00~) for every subtree. Argh. This is a bug in org-hours-to-clocksum-string, which doesn't truncate the computed number of minutes to an integer. Instead of changing org-hours-to-clocksum-string, it's probably preferable to make org-minutes-to-clocksum-string more robust, so it copes correctly with floating point arguments. The attached patch does this. Sorry for letting this slip through. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 24c646916a1195b3291067ef6e54d9e99a1201da Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Tue, 20 Nov 2012 18:15:21 +0100 Subject: [PATCH] Fix org-minutes-to-clocksum-string to cope with floating point arguments. --- lisp/org.el | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index dc411b8..e3354c6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16773,19 +16773,19 @@ The format is determined by `org-time-clocksum-format', (format org-time-clocksum-fractional-format (/ m 60.0))) ;; choice of fractional formats for different time units ((and (setq fmt (plist-get org-time-clocksum-fractional-format :years)) - ( (/ m (* 365 24 60)) 0)) + ( (/ (truncate m) (* 365 24 60)) 0)) (format fmt (/ m (* 365 24 60.0 ((and (setq fmt (plist-get org-time-clocksum-fractional-format :months)) - ( (/ m (* 30 24 60)) 0)) + ( (/ (truncate m) (* 30 24 60)) 0)) (format fmt (/ m (* 30 24 60.0 ((and (setq fmt (plist-get org-time-clocksum-fractional-format :weeks)) - ( (/ m (* 7 24 60)) 0)) + ( (/ (truncate m) (* 7 24 60)) 0)) (format fmt (/ m (* 7 24 60.0 ((and (setq fmt (plist-get org-time-clocksum-fractional-format :days)) - ( (/ m (* 24 60)) 0)) + ( (/ (truncate m) (* 24 60)) 0)) (format fmt (/ m (* 24 60.0 ((and (setq fmt (plist-get org-time-clocksum-fractional-format :hours)) - ( (/ m 60) 0)) + ( (/ (truncate m) 60) 0)) (format fmt (/ m 60.0))) ((setq fmt (plist-get org-time-clocksum-fractional-format :minutes)) (format fmt m)) @@ -16805,27 +16805,27 @@ The format is determined by `org-time-clocksum-format', (format org-time-clocksum-format (setq n (/ m 60)) (- m (* 60 n))) ;; separate formats components (and (setq fmt (plist-get org-time-clocksum-format :years)) - (or ( (setq n (/ m (* 365 24 60))) 0) + (or ( (setq n (/ (truncate m) (* 365 24 60))) 0) (plist-get org-time-clocksum-format :require-years)) (setq clocksum (concat clocksum (format fmt n)) m (- m (* n 365 24 60 (and (setq fmt (plist-get org-time-clocksum-format :months)) - (or ( (setq n (/ m (* 30 24 60))) 0) + (or ( (setq n (/ (truncate m) (* 30 24 60))) 0) (plist-get org-time-clocksum-format :require-months)) (setq clocksum (concat clocksum (format fmt n)) m (- m (* n 30 24 60 (and (setq fmt (plist-get org-time-clocksum-format :weeks)) - (or ( (setq n (/ m (* 7 24 60))) 0) + (or ( (setq n (/ (truncate m) (* 7 24 60))) 0) (plist-get org-time-clocksum-format :require-weeks)) (setq clocksum (concat clocksum (format fmt n)) m (- m (* n 7 24 60 (and (setq fmt (plist-get org-time-clocksum-format :days)) - (or ( (setq n (/ m (* 24 60))) 0) + (or ( (setq n (/ (truncate m) (* 24 60))) 0) (plist-get org-time-clocksum-format :require-days)) (setq clocksum (concat clocksum (format fmt n)) m (- m (* n 24 60 (and (setq fmt (plist-get org-time
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Sat, Nov 17, 2012 at 09:48:09AM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: Here's an updated patch. Now both org-time-clocksum-format and org-time-clocksum-fractional-format can be plists, as discussed. That was quick. Thank you. In the org-time-clocksum-format case, I made the values cons cells which specify both a format string and a boolean. The latter indicates whether the time component should always be included in the formatted duration, even if its value is 0. This is needed for the hours component to reproduce the current default format, and I figured I might as well make it general. I understand. It is a necessary evil. Though, instead of asking for cons cells, maybe the boolean could be provided as another property. I.e. '(:hour ... :persistent-hour t) would be a replacement for: '(:hour (... . t)) And, better, '(:hour ...) would the become a replacement for '(:hour (... . nil)) What do you think about it? The name of the property is only a suggestion. Good idea. I agree, additional keys are cleaner than cons cells. I used a somewhat complex customization type in the defcustoms, instead of a straight plist, in order to produce a better ui for the customization interface. I'm still not completely satisfied with it. E.g. it would be nice to get rid of the Cons cell tag entirely, and use a checkbox for the boolean. But I can't figure out how to do that (without defining new customization types/widgets, which I don't have the patience for). The advantage of the method above it that it would /de facto/ get rid of the Cons cell tag. I've replaced the cons cells with additional plist properties, as you suggested. The resulting customization ui still isn't wonderful in my opinion. But it does the job, and I'm not sure how much scope there is for improving it further. If you see a way, by all means feel free to make the changes yourself. I really don't mind what format you go with for org-time-clocksum-format, as long as it supports the new formatting features implemented in the patch. +(org-add-props (concat (format %s (make-string l ?*)) + (org-minutes-to-clocksum-string time) + (format %s (make-string (- 16 l) ?\ ))) You forgot to change that. Ooops. Fixed in the attached version. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 6e87864c125676093d8072111519c37cf9dd126c Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Sun, 11 Nov 2012 22:20:24 + Subject: [PATCH] Allow more flexible customization of clocksum format * lisp/org.el (org-time-clocksum-format, org-time-clocksum-fractional-format): in addition to a single format string, the clocksum formats can now be plists specifying separate formats for different time units. * lisp/org.el (org-minutes-to-clocksum-string): new function to replace org-minutes-to-hh:mm-string, which converts a number of minutes to a string according to the customization options. * lisp/org-colview.el (org-columns-number-to-string): use new org-minutes-to-clocksum-string function to format clocksum durations. * lisp/org-clock.el: always call new org-minutes-to-clocksum-string function when formatting time durations, instead of calling org-minutes-to-hh:mm-string or passing org-time-clocksum-format directly to format. --- lisp/org-clock.el | 51 +- lisp/org-colview.el |3 +- lisp/org.el | 190 --- 3 files changed, 198 insertions(+), 46 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 84eb2fd..54e4018 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -556,28 +556,23 @@ pointing to it. If an effort estimate was defined for the current item, use 01:30/01:50 format (clocked/estimated). If not, show simply the clocked time like 01:50. - (let* ((clocked-time (org-clock-get-clocked-time)) - (h (floor clocked-time 60)) - (m (- clocked-time (* 60 h + (let ((clocked-time (org-clock-get-clocked-time))) (if org-clock-effort (let* ((effort-in-minutes (org-duration-string-to-minutes org-clock-effort)) - (effort-h (floor effort-in-minutes 60)) - (effort-m (- effort-in-minutes (* effort-h 60))) (work-done-str (org-propertize - (format org-time-clocksum-format h m) + (org-minutes-to-clocksum-string clocked-time) 'face (if (and org-clock-task-overrun (not org-clock-task-overrun-text)) 'org-mode-line-clock-overrun 'org-mode-line-clock))) - (effort-str (format org-time-clocksum-format effort-h effort-m)) + (effort-str (org-minutes-to-clocksum-string effort-in-minutes)) (clockstr (org-propertize (concat [%s/ effort
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Sat, Nov 17, 2012 at 03:42:24PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: I've replaced the cons cells with additional plist properties, as you suggested. The resulting customization ui still isn't wonderful in my opinion. But it does the job, and I'm not sure how much scope there is for improving it further. If you see a way, by all means feel free to make the changes yourself. I really don't mind what format you go with for org-time-clocksum-format, as long as it supports the new formatting features implemented in the patch. Considering I'm not an expert in customize ui, it's good enough as it is. OK. If someone thinks of a way to improve the customization ui (keeping the same data type), it's easy to change it later without breaking anything. I've applied your patch (with some small changes in a docstring). Thank you again for all that work. Glad we finally found a good implementation. Thanks to you for all your helpful feedback. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Wed, Nov 14, 2012 at 05:20:14PM +0100, Toby Cubitt wrote:
On Wed, Nov 14, 2012 at 05:09:38PM +0100, Nicolas Goaziou wrote:
Toby Cubitt ts...@cantab.net writes:
I can easily allow org-time-clocksum-fractional-format to be a list of
formats. But 1d 3.4h doesn't seem very useful to me. Probably it should
work a bit differently: format the time as a fractional quantity, using
the largest time unit which will give a non-zero integer part.
Does that sound reasonable?
That's the idea, yes. Though, it will be the largest time unit _with
a format string_ which will give a non-zero integer part.
Yes, that's what I meant.
OK, but in this case I think the single-format-string option is still
useful. It gives users a simpler way of customizing the format if they
don't want to do anything fancy.
If they don't want to do anything fancy, they use the default value,
whatever it may be. ;) I don't mind keeping the single format string
option anyway.
I'll leave it in my patch. If you want to remove it for 8.0, it'll be a
simple case of deleting some code.
I'll post an updated patch when I get time to make the changes.
Since it's for 8.0, there's no hurry. I'll wait for you to merge the two
patches and make subsequent changes.
Here's an updated patch. Now both org-time-clocksum-format and
org-time-clocksum-fractional-format can be plists, as discussed.
In the org-time-clocksum-format case, I made the values cons cells which
specify both a format string and a boolean. The latter indicates whether
the time component should always be included in the formatted duration,
even if its value is 0. This is needed for the hours component to
reproduce the current default format, and I figured I might as well make
it general.
I used a somewhat complex customization type in the defcustoms, instead
of a straight plist, in order to produce a better ui for the
customization interface. I'm still not completely satisfied with it.
E.g. it would be nice to get rid of the Cons cell tag entirely, and use
a checkbox for the boolean. But I can't figure out how to do that
(without defining new customization types/widgets, which I don't have the
patience for).
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
From 639baf9c942df97e7355f402a9df38e6c9b6ef88 Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Sun, 11 Nov 2012 22:20:24 +
Subject: [PATCH] Allow more flexible customization of clocksum format
* lisp/org.el (org-time-clocksum-format, org-time-clocksum-fractional-format):
in addition to a single format string, the clocksum formats can now be
plists specifying separate formats for different time units.
* lisp/org.el (org-minutes-to-clocksum-string): new function to
replace org-minutes-to-hh:mm-string, which converts a number of
minutes to a string according to the customization options.
* lisp/org-colview.el (org-columns-number-to-string): use new
org-minutes-to-clocksum-string function to format clocksum durations.
* lisp/org-clock.el: always call new org-minutes-to-clocksum-string
function when formatting time durations, instead of calling
org-minutes-to-hh:mm-string or passing org-time-clocksum-format
directly to format.
---
lisp/org-clock.el | 51 +--
lisp/org-colview.el |3 +-
lisp/org.el | 175 +++---
3 files changed, 183 insertions(+), 46 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 84eb2fd..c768491 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -556,28 +556,23 @@ pointing to it.
If an effort estimate was defined for the current item, use
01:30/01:50 format (clocked/estimated).
If not, show simply the clocked time like 01:50.
- (let* ((clocked-time (org-clock-get-clocked-time))
- (h (floor clocked-time 60))
- (m (- clocked-time (* 60 h
+ (let ((clocked-time (org-clock-get-clocked-time)))
(if org-clock-effort
(let* ((effort-in-minutes
(org-duration-string-to-minutes org-clock-effort))
- (effort-h (floor effort-in-minutes 60))
- (effort-m (- effort-in-minutes (* effort-h 60)))
(work-done-str
(org-propertize
- (format org-time-clocksum-format h m)
+ (org-minutes-to-clocksum-string clocked-time)
'face (if (and org-clock-task-overrun (not org-clock-task-overrun-text))
'org-mode-line-clock-overrun 'org-mode-line-clock)))
- (effort-str (format org-time-clocksum-format effort-h effort-m))
+ (effort-str (org-minutes-to-clocksum-string effort-in-minutes))
(clockstr (org-propertize
(concat [%s/ effort-str
] ( (replace-regexp-in-string % %% org-clock-heading) ))
'face 'org-mode-line-clock)))
(format clockstr work-done-str))
- (org-propertize (format
- (concat [ org-time-clocksum-format (%s
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Wed, Nov 14, 2012 at 04:04:05PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: Thanks for your work. Some comments below. The second patch: - further extends org-time-clocksum-format to allow separate month and year components (where a month is taken to be 30 days, a year to be 365 days). I suggest to add week instead of month, as the duration of the former is more stable and [1;52[ range is still readable. Yes, not sure why I didn't think of adding weeks. But using months and years is optional and not the default, so I see no great harm in including them too (as long as the fact that 1 month = 30 days and 1 year = 365 days here is well documented). The reason for retaining separate org-time-clocksum-format and org-time-clocksum-fractional-format's is that (i) it doesn't make much sense to have a list of formats for separate components when using the fractional format (see Nicolas' examples earlier in this discussion thread); Then, my examples weren't clear. It is useful to have a list of formats when using fractional time as the unit used may change: 1.2 dor1.2 h I can easily allow org-time-clocksum-fractional-format to be a list of formats. But 1d 3.4h doesn't seem very useful to me. Probably it should work a bit differently: format the time as a fractional quantity, using the largest time unit which will give a non-zero integer part. Does that sound reasonable? I'm not wedded to new customization type I've used in org-time-clocksum-format. If you prefer a plist, or a different ordering of the format strings in the list, or a different customization ui, that's fine by me. I think a plist would be clearer. More on that below. +(org-add-props (concat (format %s (make-string l ?*)) + (org-minutes-to-clocksum-string time) + (format %s (make-string (- 16 l) ?\ ))) Shouldn't it be: (org-add-props (concat (make-string l ?*) (org-minutes-to-clocksum-string time) (make-string (- 16 l) ? )) Yes. This was an artifact of converting the previous code over to org-minutes-to-clocksum-string. -(defcustom org-time-clocksum-format %d:%02d +(defcustom org-time-clocksum-format '(:%02d %d %dd ) ;%d:%02d The format string used when creating CLOCKSUM lines. -This is also used when org-mode generates a time duration. +This is also used when org-mode generates a time duration. This is not about your patch, but while you're working in this area: in documentation, it should be Org mode. OK. +The value can be a single format string containing two +%-sequences, which will be filled with the number of hours and +minutes in that order. Ok, for backward compatibility. Note that, for a major release (8.0), such changes are acceptable even without it. OK, but in this case I think the single-format-string option is still useful. It gives users a simpler way of customizing the format if they don't want to do anything fancy. +Alternatively, the value can be a list of up to three format +strings. In this case, the first format string in the list is +used for the number of minutes, the second for the number of +hours, and the third for the number of days if the duration is +longer than 1 day. The complete formatted duration is obtained by +concatenating these in the order: days, minutes, hours. + +If the list contains fewer than three format strings, it +restricts the largest time unit in the formatted duration to be +the largest one in the list. A two-element list means the +duration will always be expressed in hours and minutes, a +one-element list means the duration will always be expressed in +minutes. There, I think we would benefit from using a plist. Indeed, a two-element list might mean that duration should be expressed in days and hours instead. Also I suggest to report duration targeted at missing format strings to the smaller unit. Good idea. This adds (yet more) flexibility, and it makes customization more transparent too. So: '(:day nil :hour %d :minute :%02d) will be the equivalent of the current default format string. Then we can specify that %d:%02d is still available but should be deprecated. I don't see any pressing need to deprecate the old format. It would also allow to skip months/weeks. +(defalias 'org-minutes-to-hh:mm-string 'org-minutes-to-clocksum-string) +(make-obsolete 'org-minutes-to-hh:mm-string 'org-minutes-to-clocksum-string + org-mode version 7.9.3) Good idea. Don't forget to fix the WHEN argument when the patch is applied. I'll post an updated patch when I get time to make the changes. Cheers, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Wed, Nov 14, 2012 at 05:09:38PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: I can easily allow org-time-clocksum-fractional-format to be a list of formats. But 1d 3.4h doesn't seem very useful to me. Probably it should work a bit differently: format the time as a fractional quantity, using the largest time unit which will give a non-zero integer part. Does that sound reasonable? That's the idea, yes. Though, it will be the largest time unit _with a format string_ which will give a non-zero integer part. Yes, that's what I meant. OK, but in this case I think the single-format-string option is still useful. It gives users a simpler way of customizing the format if they don't want to do anything fancy. If they don't want to do anything fancy, they use the default value, whatever it may be. ;) I don't mind keeping the single format string option anyway. I'll leave it in my patch. If you want to remove it for 8.0, it'll be a simple case of deleting some code. I'll post an updated patch when I get time to make the changes. Since it's for 8.0, there's no hurry. I'll wait for you to merge the two patches and make subsequent changes. OK. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Attached is a new two-patch series implementing finer-grained control
over the format of clocksum durations (only in overlays and the
mode-line; the format of the CLOCK entries stored in org files remains
unchanged and hard-coded, as before).
The first patch:
- defines a new org-minutes-to-clocksum-string function (replacing
org-minutes-to-hh:mm-string) for formatting time durations according to
customization options;
- unifies the formatting of clocksum durations throughout org-colview.el
and org-clock.el by always calling org-minutes-to-clocksum-string to do
the formatting;
- extends the org-time-clocksum-format defcustom, allowing it to either
be a single format string (as before), or a list of between 1 and 3
format strings for the minutes, hours and days components of a time
duration;
- retains the org-time-clocksum-use-fractional and
org-time-clocksum-fractional-format defcustoms, whose meaning is
unchanged.
The second patch:
- further extends org-time-clocksum-format to allow separate month and
year components (where a month is taken to be 30 days, a year to be 365
days).
Both patches maintain backwards-compatibility with any existing
customizations users may have made to these variables. They just add an
additional type for org-time-clocksum-format.
The reason for retaining separate org-time-clocksum-format and
org-time-clocksum-fractional-format's is that (i) it doesn't make much
sense to have a list of formats for separate components when using the
fractional format (see Nicolas' examples earlier in this discussion
thread); (ii) it maintains backwards-compatibility; (iii) it side-steps
the issue of making users customize the format whenever they modify
org-time-clocksum-use-fractional.
I'm not wedded to new customization type I've used in
org-time-clocksum-format. If you prefer a plist, or a different ordering
of the format strings in the list, or a different customization ui,
that's fine by me.
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
From 812b6704191d96a8fc255e9c282eeef8deb091cf Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Sun, 11 Nov 2012 22:20:24 +
Subject: [PATCH 1/2] Allow more flexible customization of clocksum format
* lisp/org.el (org-time-clocksum-format): as well as a single format
string, can now be a list of up to three format strings which
determine how the minutes, hours and days compontents of a clocksum
duraction should be formated.
* lisp/org.el (org-minutes-to-clocksum-string): function replacing
org-minutes-to-hh:mm-string, which converts a number of minutes to a
string according to the customization options.
* lisp/org-colview.el (org-columns-number-to-string): use new
org-minutes-to-clocksum-string function to format clocksum durations.
* lisp/org-clock.el: instead of calling org-minutes-to-hh:mm-string or
passing org-time-clocksum-format directly to format in order to format
a clock duration as a string, always call the new
org-minutes-to-clocksum-string function to do this.
---
lisp/org-clock.el | 51 +
lisp/org-colview.el |3 +-
lisp/org.el | 69 +-
3 files changed, 81 insertions(+), 42 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 84eb2fd..c768491 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -556,28 +556,23 @@ pointing to it.
If an effort estimate was defined for the current item, use
01:30/01:50 format (clocked/estimated).
If not, show simply the clocked time like 01:50.
- (let* ((clocked-time (org-clock-get-clocked-time))
- (h (floor clocked-time 60))
- (m (- clocked-time (* 60 h
+ (let ((clocked-time (org-clock-get-clocked-time)))
(if org-clock-effort
(let* ((effort-in-minutes
(org-duration-string-to-minutes org-clock-effort))
- (effort-h (floor effort-in-minutes 60))
- (effort-m (- effort-in-minutes (* effort-h 60)))
(work-done-str
(org-propertize
- (format org-time-clocksum-format h m)
+ (org-minutes-to-clocksum-string clocked-time)
'face (if (and org-clock-task-overrun (not org-clock-task-overrun-text))
'org-mode-line-clock-overrun 'org-mode-line-clock)))
- (effort-str (format org-time-clocksum-format effort-h effort-m))
+ (effort-str (org-minutes-to-clocksum-string effort-in-minutes))
(clockstr (org-propertize
(concat [%s/ effort-str
] ( (replace-regexp-in-string % %% org-clock-heading) ))
'face 'org-mode-line-clock)))
(format clockstr work-done-str))
- (org-propertize (format
- (concat [ org-time-clocksum-format (%s)])
- h m org-clock-heading)
+ (org-propertize (concat [ (org-minutes-to-clocksum-string clocked-time)
+ (format (%s) org-clock-heading) ])
'face
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Thu, Nov 08, 2012 at 01:26:48AM +0100, Nicolas Goaziou wrote: Format string for clock lines is hard-coded (see line 1493 in org-clock.el), which means we don't have to limit ourselves to parse-able format. Back to point 1. Good. That's what I thought. Then, I'm fine with format strings. Following your suggestion, what about the following variables: - one to determine format of data: fractional or regular. - one to determine display format. Its value would be a list of 3 format strings associated to days, hours and minutes. Sounds good to me. I think your idea of separating out the format strings for days, hours and minutes is better. Minor point: I would order the format strings minutes, hours, days. In case we ever want to extend to months or years, that way we can simply extend the list and it will be completely backwards compatible. One other thing that needs some thought (which I already mentioned previously). The minutes format string needs to change, depending on whether the data format is fractional or regular. So if a user wants to switch to fractional, it's not enough to set the first variable; they have to *also* change the minute format string. If they don't the durations will be garbled. A customization setter function could be used to change the value of the second variable when the first one is modified through customize. But that quickly gets complex, e.g. we have to be careful about clobbering any customizations the user has already made to the format strings. The simpler solution would be to always have two format strings for the minutes in the list: a fractional format, and a regular format. This shouldn't be too confusing as long as it's documented in the variable docstring and there are good descriptive :tags for each list element in the customization type. Internally, the duration is computed as a list of three integers or nil if data is regular, or a list of one float and two nil if data is fractional. Format strings from the second variable will be concatenated only when value is non-nil. If no format string is found for a given unit, it's value will be converted into a lesser unit. Examples: | var1| var2| internal representation | display | |-+-+-+-| | 'regular| (%dd %d h %d min) | (nil 11 35) | 11 h 35 min | | 'fractional | (%.2fd %.2fh %.2fmin) | (nil 11.3 nil) | 11.30h | | 'regular| (%dd %d: %02d) | (1 3 5) | 1d 3:05 | | 'regular| (nil %d: %02d) | (1 3 5) | 27:05 | We can extend it to years if needed. Looks good to me, and lets me do what I wanted in my original patch. Now I just need to find time to code it up... Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] end-of-line behaviour [was: (no subject)]
This sounds like it might be related to recent end-of-line changes and an even more recent (not yet applied) patch I posted. On Wed, Nov 07, 2012 at 12:50:20PM -0600, Kevin Buchs wrote: I would like to solve a problem I have: C-e (org-end-of-line) does not move to the end of the line with long lines that are not headings. I find myself wanting to get to the end of a long line often and have to hit multiple C-e sequences to get there. I don't have the org-special-ctrl-a/e set to non-nil. Which version of org-mode are you running? I can't reproduce this in a recent git checkout. With visual-line-mode off and org-special-ctrl-a/e nil, C-e goes straight to the (real) end of the line in one go. On the other hand, with the same settings, C-a doesn't go back to the *beginning* of the line in one go for me. This bug is fixed by the patch I posted to the list. My line-move-visual value is the default value of t, so I get the end-of-visual-line movement one screen's worth. At least in the latest git, end-of-line doesn't even check the value of line-move-visual, so it's setting shouldn't have any effect at all on org-end-of-line. (org-beginning-of-line *does* check line-move-visual; my patch fixes this to check visual-line-mode instead.) Before I start hacking, I thought I should be clear on the design goals here. It seems as if the declaration of line-move-visual says it is dealing with vertical motion, not horizontal motion. I don't see any behavior elsewhere that uses the interpretation that line-move-visual is for horizontal motion. Anyone have thoughts on this subject? Agreed (see the recent discussion thread about my patch). BTW - I posted this back in May, but I neglected to keep the topic alive. Looks like you're not the only one trying to fix this :) Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 11:45:24PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: This is not far from your own suggestion to provide different functions depending on which output is desired, I just happen to think that these functions would all be so similar that they should be rolled into a single function that can produce different outputs. I think there'd only be a handful of possible values for fmt based on the current usage and that suggests just another cond form would be needed in implementing this function rather than a full-blown format string interpreter. It seems to me your `org--format-time' function would end up looking very like what I sketched. A cond to switch between hh:mm, hh.mm, dd hh:mm or dd hh.mm based only on the contents of the fmt argument would have to check whether fmt contains 2 or 3 %-sequences, then check if it contains . or : Again, these are strange and very limiting rules. What if I want to have 5 h 32 min? And 5,3 days? Good point. Achim didn't specify how he conceives the FMT argument. One possibility would be to have a placeholder-based template with, i.e. %d, %h, %m, %w for respectively number of days, hours, minutes and weeks. But it's still less flexible than functions because you need to have a fixed number of placeholders in every template. Indeed. None of the format-only proposals would let me reproduce the setup I have currently (with my earlier patch): 5d 3h for durations longer than a day, 3:15 for durations shorter than a day. I still think functions are the way to go. Three options in the defcustom: - One to provide regular time (i.e 14:40 or 3d 18:32) - One to provide decimal time with the highest unit available (i.e. 18,75 h or 2,5 d). - One free slot for an user-defined function. I like the flexibility of functions. But one drawback of this is that you can't produce your 5 h 32 min or 5,3 days examples without defining a new function. It would be nice if tweaking just the format (without changing the numbers themselves) could be done by changing a simple format string. Because the number of placeholders in a format string is fixed, I don't see how to avoid the need for multiple format strings. Perhaps we need a second defcustom that holds a list of format strings, to be used by the functions in your first two choices. The first format string for durations 1 day (or for all durations if this is the only string in the list), the second for durations = 1 day. One nice thing is that this could easily be extended in the obvious way if one wanted to allow different formats for durations = 1 month or = 1 year. It's slightly ugly that the defaults for the format-string defcustom would have to change depending on the value of the function defcustom. I guess one could either have the format-string defcustom default to nil, and use hard-coded defaults in the functions (which are overridden by a non-nil format string value). Or put both functions and format strings into a single defcustom, e.g. as a list with the function in the first element. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Tue, Nov 06, 2012 at 11:57:25AM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: I still think functions are the way to go. Three options in the defcustom: - One to provide regular time (i.e 14:40 or 3d 18:32) - One to provide decimal time with the highest unit available (i.e. 18,75 h or 2,5 d). - One free slot for an user-defined function. I like the flexibility of functions. But one drawback of this is that you can't produce your 5 h 32 min or 5,3 days examples without defining a new function. It would be nice if tweaking just the format (without changing the numbers themselves) could be done by changing a simple format string. Because the number of placeholders in a format string is fixed, I don't see how to avoid the need for multiple format strings. Perhaps we need a second defcustom that holds a list of format strings, to be used by the functions in your first two choices. The first format string for durations 1 day (or for all durations if this is the only string in the list), the second for durations = 1 day. One nice thing is that this could easily be extended in the obvious way if one wanted to allow different formats for durations = 1 month or = 1 year. It's slightly ugly that the defaults for the format-string defcustom would have to change depending on the value of the function defcustom. I guess one could either have the format-string defcustom default to nil, and use hard-coded defaults in the functions (which are overridden by a non-nil format string value). Or put both functions and format strings into a single defcustom, e.g. as a list with the function in the first element. Actually the number of functions defined doesn't matter much. What matters is the number of functions exposed to the end-user, which is 0 in this situation (or 1 if he decides to write his own). Here, all is solved with one defcustom. You don't even need to create multiple functions for that. The defcustom can store `regular', `decimal' symbols or a function. Sure, I'm familiar with how defcustoms work. Then you can write a generic duration format function that will be used across code base with the following template: #+begin_src emacs-lisp (defun org-build-format-duration (n) Format duration N according to `org-duration-format' variable. N is the duration to display, as a number, expressed in minutes. Return formatted duration as a string. (cond ((functionp org-duration-format) (funcall org-duration-format)) ((eq org-duration-format 'regular) ...) ((eq org-duration-format 'decimal) ...) (t (error Invalid `org-duration-format' value #+end_src The issue I pointed out has nothing to do with the internal implementation. One variable exposed to the user. One function exposed to the developer. It's much simpler. You're missing my point (which probably means I didn't explain it well). How do I produce the format 5 h 32 min with your defcustom, without requiring the user to define their own function? (Assuming that 'regular produces the current default 5:32 format.) You still need a way to allow users to supply format strings, so they can customize the appearance of the `regular' and `decimal' formats. Your own 5 h 32 min and 5,3 days examples demonstrate this. This either implies a second defcustom for the format strings, or it implies storing both the format strings and choice of function choice in the same defcustom. Furthermore, one format string isn't be enough because you might want to different numbers of placeholders depending on the duration (which is what my original patch allowed). Cheers, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] [PATCH] Make org-[beginning|end]-of-line respect visual-line-mode
Subject line and commit message says it all. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From bca045ffd27d41630c52a67390767cd622544bb9 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Tue, 6 Nov 2012 13:25:15 +0100 Subject: [PATCH] Make org-end-of-line respect visual-line-mode * lisp/org.el (org-beginning-of-line, org-end-of-line): Use beginning-of-visual-line and end-of-visual-line to move to beginning/end of line in visual-line-mode. --- lisp/org.el | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 2aa70bd..4ce4ed3 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21567,7 +21567,8 @@ beyond the end of the headline. (car org-special-ctrl-a/e) org-special-ctrl-a/e)) refpos) -(if (org-bound-and-true-p line-move-visual) +(if (or (org-bound-and-true-p visual-line-mode) + (org-bound-and-true-p line-move-visual)) (beginning-of-visual-line 1) (beginning-of-line 1)) (if (and arg (fboundp 'move-beginning-of-line)) @@ -21578,7 +21579,9 @@ beyond the end of the headline. (if (org-truely-invisible-p) (while (and (not (bobp)) (org-truely-invisible-p)) (backward-char 1) - (beginning-of-line 1)) + (if (org-bound-and-true-p visual-line-mode) + (beginning-of-visual-line 1) + (beginning-of-line 1))) (forward-char 1 (when special (cond @@ -21633,7 +21636,8 @@ the cursor is already beyond the end of the headline. (cond ((or (not special) arg) (call-interactively - (if (fboundp 'move-end-of-line) 'move-end-of-line 'end-of-line))) + (if (org-bound-and-true-p visual-line-mode) 'end-of-visual-line + (if (fboundp 'move-end-of-line) 'move-end-of-line 'end-of-line ((memq type '(headline inlinetask)) (let ((pos (point))) (beginning-of-line 1) @@ -21657,7 +21661,8 @@ the cursor is already beyond the end of the headline. (when (org-invisible-p2) (backward-char))) (t (call-interactively - (if (fboundp 'move-end-of-line) 'move-end-of-line 'end-of-line + (if (org-bound-and-true-p visual-line-mode) 'end-of-visual-line + (if (fboundp 'move-end-of-line) 'move-end-of-line 'end-of-line) (org-no-warnings (and (featurep 'xemacs) (setq zmacs-region-stays t) (define-key org-mode-map \C-a 'org-beginning-of-line) -- 1.7.8.6
Re: [O] [PATCH] Make org-[beginning|end]-of-line respect visual-line-mode
On Tue, Nov 06, 2012 at 01:31:41PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: Subject line and commit message says it all. `org-end-of-line' has been patched already. Is there a bug in `org-beginning-of-line'? I forgot to pull and rebase before posting, so missed the recent fix. Sorry for the noise. org-beginning-of-line uses org-beginning-of-visual-line when line-move-visual is enabled. I'm not sure if line-mode-visual can be disabled when visual-line-mode is enabled. If so, org-beginning-of-line should maybe test for either line-mode-visual *or* visual-line-mode. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Tue, Nov 06, 2012 at 01:29:02PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: How do I produce the format 5 h 32 min with your defcustom, without requiring the user to define their own function? (Assuming that 'regular produces the current default 5:32 format.) Why without defining their own function? My proposal was to use functions instead of format strings to customize output. Because customizing a format string is easier than defining a new function when you don't want to do anything more fancy than modifying the textual formatting. (If you want to do something conditional on the duration, then defining a new function is natural.) You still need a way to allow users to supply format strings, so they can customize the appearance of the `regular' and `decimal' formats. Your own 5 h 32 min and 5,3 days examples demonstrate this. In my proposal, customizing `regular' and `decimal' format wasn't expected. This either implies a second defcustom for the format strings, or it implies storing both the format strings and choice of function choice in the same defcustom. Furthermore, one format string isn't be enough because you might want to different numbers of placeholders depending on the duration (which is what my original patch allowed). But let's forget about it, it's a false good idea, anyway. I'm shooting myself in the foot: custom formats mean parsing hell. No. It's possible to do it with standard format strings. You just need to (optionally) allow multiple format strings, one for each duration. So either: 1. We define a new format, non customizable, but possibly conditional, which can describe a duration, in order to include days. 2. We allow customization as overlays (much like timestamps). 3. We leave it as-is. I'm not very fond of 2, so I think this whole customization problem is moot anyway. Or 4. We replace the existing muddle with two defcustoms, one selecting regular or decimal (or user-defined function), and one specifying a list of standard format strings that the function can choose between, depending on the duration. No custom format required, no format string parsing required. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Make org-[beginning|end]-of-line respect visual-line-mode
On Tue, Nov 06, 2012 at 06:02:40PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: org-beginning-of-line uses org-beginning-of-visual-line when line-move-visual is enabled. I'm not sure if line-mode-visual can be disabled when visual-line-mode is enabled. If so, org-beginning-of-line should maybe test for either line-mode-visual *or* visual-line-mode. `beginning-of-visual-line' either set locally `line-move-visual' to t or use `vertical-motion', which doesn't care about `lime-move-visual' value. Thus, as one could expect, `line-move-visual' has no effect on horizontal scrolling. IMO, checking this variable is a no-op. I'm confused. Which variable are you talking about here? Anyway, I see that `visual-line-mode's sets `line-move-visual' to t buffer-locally. So checking only `line-move-visual' in `org-beginning-of-line' is fine... ...which strongly suggests that the recent fix to `org-end-of-line' is wrong. Shouldn't it also be checking `line-move-visual' and not `visual-line-mode', like `org-beginning-of-line'? Btw, if you plan to patch this area, could you provided tests for it (see test-org/end-of-line in test-org.el)? As I can testify, there is a high risk of regression in that area. Thanks, I'll try to remember. Though I have no plans to patch anything else in this area. Cheers, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Make org-[beginning|end]-of-line respect visual-line-mode
On Tue, Nov 06, 2012 at 06:30:47PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: I'm confused. Which variable are you talking about here? `line-move-visual' Anyway, I see that `visual-line-mode's sets `line-move-visual' to t buffer-locally. So checking only `line-move-visual' in `org-beginning-of-line' is fine... ...which strongly suggests that the recent fix to `org-end-of-line' is wrong. Shouldn't it also be checking `line-move-visual' and not `visual-line-mode', like `org-beginning-of-line'? Doesn't `visual-line-mode' set C-e to `end-of-visual-line'? As I tried to explain, unless I'm mistaken, `line-move-visual' has nothing to do with beginning or end of current line. Aha! You may well be right. In which case why is `org-beginning-of-line' doing this: (if (org-bound-and-true-p line-move-visual) (beginning-of-visual-line 1) (beginning-of-line 1)) Shouldn't it be doing this instead? (if (org-bound-and-true-p visual-line-mode) (beginning-of-visual-line 1) (beginning-of-line 1)) Or maybe I'm missing a subtle difference between org-beginning-of-line and org-end-of-line... Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Make org-[beginning|end]-of-line respect visual-line-mode
On Tue, Nov 06, 2012 at 06:46:27PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: Aha! You may well be right. In which case why is `org-beginning-of-line' doing this: (if (org-bound-and-true-p line-move-visual) (beginning-of-visual-line 1) (beginning-of-line 1)) Shouldn't it be doing this instead? (if (org-bound-and-true-p visual-line-mode) (beginning-of-visual-line 1) (beginning-of-line 1)) Indeed. Do you want to provide a patch (you get bonus points for regression tests)? I guess you want regression tests for `end-of-line' with `visual-line-mode' enabled? (There aren't any tests for beginning-of-line in test-org.el currently, and the fix to org-beginning-of-line won't actually change the behaviour, just make the code more correct.) I've made an attempt in the attached patch, which also fixes org-beginning-of-line as discussed. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From c91b6bee12d27d43e4c2ba90c339c1b86010be67 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Tue, 6 Nov 2012 19:06:26 +0100 Subject: [PATCH] Bug fix in org-beginning-of-line visual line motion * lisp/org.el (org-beginning-of-line): check `visual-line-mode' instead of `line-visual-mode' to determine whether to move by visual lines. * lisp/org.el (org-kill-line): use of org-bound-and-true-p macro. * testing/lisp/test-org.el (test-org/end-of-line): add regression test for `org-end-of-line' in `visual-line-mode' buffers. --- lisp/org.el |4 ++-- testing/lisp/test-org.el |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ad2863b..080b527 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21577,7 +21577,7 @@ beyond the end of the headline. (car org-special-ctrl-a/e) org-special-ctrl-a/e)) refpos) -(if (org-bound-and-true-p line-move-visual) +(if (org-bound-and-true-p visual-line-mode) (beginning-of-visual-line 1) (beginning-of-line 1)) (if (and arg (fboundp 'move-beginning-of-line)) @@ -21704,7 +21704,7 @@ depending on context. (not (y-or-n-p Kill hidden subtree along with headline? ))) (error C-k aborted - would kill hidden subtree))) (call-interactively - (if (and (boundp 'visual-line-mode) visual-line-mode) 'kill-visual-line 'kill-line))) + (if (org-bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line))) ((looking-at (org-re .*?\\S-\\([ \t]+\\(:[[:alnum:]_@#%:]+:\\)\\)[ \t]*$)) (kill-region (point) (match-beginning 1)) (org-set-tags nil t)) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 98957ac..a2115bf 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -477,6 +477,13 @@ http://article.gmane.org/gmane.emacs.orgmode/21459/; (should (org-test-with-temp-text Some text\nSome other text (progn (org-end-of-line) (eolp + ;; Standard test with `visual-line-mode'. + (should + (org-test-with-temp-text + A long line of text\nSome other text + (progn (forward-char 2) (cl-dotimes (i 1000) (insert very )) + (visual-line-mode 1) (goto-char (point-min)) (org-end-of-line) + (thing-at-point-looking-at very ;; At an headline with special movement. (should (org-test-with-temp-text * Headline :tag: -- 1.7.8.6
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Tue, Nov 06, 2012 at 06:41:06PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: 4. We replace the existing muddle with two defcustoms, one selecting regular or decimal (or user-defined function), and one specifying a list of standard format strings that the function can choose between, depending on the duration. No custom format required, no format string parsing required. I'm talking about the other parsing: from the displayed duration to a number of minutes. It cannot be done if we allow user-defined functions. I doubt it can be done now, since we already allow user-defined format strings. Where are displayed durations formatted with org-time-clocksum-format et al. parsed back to a number of minutes in the current code? If there is anywhere, it's surely broken because a user-supplied `org-time-clocksum-format' or `org-time-clocksum-fractional-format' could already format the duration in arbitrarily bizarre ways as things are currently. Also, I'd rather have one defcustom than two for a simple thing like duration display. There are currently three, four with my original patch. Reducing this to two whilst simultaneously increasing customizability and ensuring a uniform format doesn't seem so bad :) We're trying to allow two fundamentally different things here: 1. Change the values that are computed and displayed (e.g. condition on 1 day vs. = 1 day; use fractional minutes or not). 2. Customize the way those values are formatted (3:15 vs. 3h 15min). It seems fairly natural to separate these into two defcustoms, rather than try to somehow mash two rather different types of customization into one. The same logic was presumably lurking behind the separation of org-time-clocksum-use-fractional and org-time-clocksum-[fractional-]format. If we want to allow the kind of flexibility you were proposing, then pre-canned options (or user-defined function) are a good fit to 1. and format strings are the natural choice for 2. If all we want to do is allow the existing regular or fractional formats to be conditioned on the duration, a 100% backwards-compatible alternative could be to allow org-time-clocksum-[fractional-]format to be either a single format string (as currently) or a list of format strings. In the latter case, the first element would be used for durations 1 day, the second for durations = 1 day (extending to months/years/decades in the obvious way if desired). The benefits of this over my original patch are: (a) it avoids introducing any new defcustoms or changing the existing ones in a backwards-incompatibility way; (b) it could easily be generalised if desired (now or in future) to condition the format on further duration ranges. The disadvantages are: (i) it doesn't have the flexibility of user-defined format functions; (ii) it doesn't simplify the existing defcustoms. So, I still suggest to provide an unique, although conditional, display for duration. If you still want to allow customization, make sure it can be parsed back (or better, provide the parser). I'm not fundamentally against format strings. You mean abandon any sort of customizable format string (since that inherently can't be parsed back in general), and use a hard-coded conditional hh:mm or dd hh:mm format? (Possibly retaining one customisation option, org-time-clocksum-use-fractional, to switch this to hh.mm or dd hh.mm?) That would give me the format I want, but it's a feature regression. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Tue, Nov 06, 2012 at 07:42:54PM +0100, Achim Gratz wrote: Nicolas Goaziou writes: Again, these are strange and very limiting rules. What if I want to have 5 h 32 min? And 5,3 days? You provide a format string like you do now. That means if you want a format that's conditional on the duration, then you have to use whatever hard-coded formats are provided by the canned options. Conversely, if you want to customize the format you can't make it conditional on the duration. Same applies to regular vs. fractional if we also decide do that via canned formats, to reduce the ridiculous number of defcustoms (3) to customize this simple feature (which has also taken a ridiculous number of emails to discuss ;-) Achim didn't specify how he conceives the FMT argument. I thought that's obvious: the canned formats (the ones you'd want to use functions for) will by symbols that the cond compares against and anything else must be a string that can be given to format, like the custom we have now. That also takes care of staying backwards compatible (some folks might actually have customized that variable). If that turns out to be too limiting we can still decide to parse fancier format strings and feed the correct arguments into them. Including the changes in my patch, we're trying to customize three orthogonal things: 1. Conditioning what we display on the duration. 2. Regular vs. fractional minutes. 3. Customizing the formatting. Any combination of choices for these three factors is valid. 1 affects which values we compute. 2 affects how we compute one of the values. 3 affects how we display those values. Your proposal doesn't allow 3 to be customized independently of 1 and 2. But it seems Nicolas wants to get rid of customizable format strings anyway, to allow clocksum durations to be parsed back into a number of minutes (see other part of this thread). For this, a single defcustom for choosing pre-canned formats with no user-defined functions and no customizable format strings is the only (sane) option. In which case this discussion is somewhat moot. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Tue, Nov 06, 2012 at 08:55:12PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: I doubt it can be done now, since we already allow user-defined format strings. I'm more focused on what we will be able to do. Where are displayed durations formatted with org-time-clocksum-format et al. parsed back to a number of minutes in the current code? If there is anywhere, it's surely broken because a user-supplied `org-time-clocksum-format' or `org-time-clocksum-fractional-format' could already format the duration in arbitrarily bizarre ways as things are currently. In org-element.el. But that only needs to parse clock strings stored in properties/drawers, not the ones displayed in overlays (column view) or in the mode-line. Are the clock strings stored in properties/drawers formatted using the existing org-time-clocksum-* defcustoms? I can't easily tell from the org-clock.el code... The only sane answer ought to be no (which doesn't mean that it is ;) It would clearly be better if the clock strings stored in org buffers used a single fixed format, which could be mangled as desired for display in overlays and the mode-line. You mean abandon any sort of customizable format string (since that inherently can't be parsed back in general), and use a hard-coded conditional hh:mm or dd hh:mm format? (Possibly retaining one customisation option, org-time-clocksum-use-fractional, to switch this to hh.mm or dd hh.mm?) We can allow a limited set of conses of format strings (with or without days), possibly defined in the same defcustom (see `org-table-number-regexp' customize interface). If we know the format string used, we can parse it back. Ugh. Wouldn't it be far better to make sure the customization options only affect the visual display of clocksum durations (in overlays/mode-line), and not the strings stored in the file? Then the parser can be kept simple and reliable. That would give me the format I want, but it's a feature regression. There are features more honoured in the breach than in the observance. I want to have a parseable Org syntax, for its own good. Best way to achieve this is to separate style from content! That would allow the visual clocksum format can be customized to our hearts content, whilst keeping the parser simple and therefore reliable. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 10:14:27AM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: Personally, I find the time duration 123:15 much harder to parse mentally than 5d 3:15. The attached patch adds a new customization option `org-time-clocksum-days-format'. When non-nil, this is used instead of `org-time-clocksum-format' for clocksum durations longer than 1 day. It gets passed three values: # days, # hours, # mins. (Note that you don't have to use all three in the format if, say, you don't feel the need to display the minutes for such long durations.) In the patch, I've set the default value for this new customization option to a non-nil value. If you prefer to keep the current behaviour as the default, just make the default value nil. Toby PS: I guess the logical extrapolation of this is to add even more `org-time-clocksum-[months|years|decades]-format' options. (Or, probably better, abandon printf formats for long durations and just add an `org-time-clocksum-format-function' option, leaving it up users to define a function to format the time as they wish.) I haven't done this in the patch, because I think 64d 3:15 is no harder to parse than 2m 4d 3:15 (plus there's the thorny issue of how many days should be in a month). And by the time you get to 535d 3:15 vs. 2y 5d 3:15, the duration is so long that you probably don't care much about the exact value, except that it's a very long-running task indeed! Thanks for your patch. I like the idea, but it would be better to avoid introducing yet another defcustom for this. There is already: - org-time-clocksum-format - org-time-clocksum-use-fractional - org-time-clocksum-fractional-format As you suggest, I think a better plan is to replace all of them with a single `org-time-clocksum-display-function'. Its expected value would be a function accepting 2 arguments: hours and minutes, as numbers and it should return a string. We can also provide default functions for current behaviour (i.e. fractional time and Hs:MM) and for the one you suggest. It's more work, but it simplifies the whole thing in the end. What do you think? Do you want to give it a try? Sounds like a good plan, and it won't be very difficult to implement. I'm happy to have a go, but I'm somewhat short on spare time just at the moment, so it might take me a few weeks to get around to it. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 11:47:12AM +0100, Achim Gratz wrote: Nicolas Goaziou writes: As you suggest, I think a better plan is to replace all of them with a single `org-time-clocksum-display-function'. Its expected value would be a function accepting 2 arguments: hours and minutes, as numbers and it should return a string. Actually, it seems an even better plan IMHO to just have one single function that takes a format string and the total time in minutes or seconds and allow customization of the format string. A format string isn't sufficient. It requires the number of time components (days, hours, minutes, etc.) to be fixed in advance. Whereas a function can decide whether to display e.g. days+hours or hours+minutes depending on whether the time is longer or shorter than 24h. A defcustom that can either be a format string *or* a function might be an option. Or maybe I've misunderstood what you're proposing? Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 12:13:25PM +0100, Achim Gratz wrote: Toby Cubitt writes: A format string isn't sufficient. It requires the number of time components (days, hours, minutes, etc.) to be fixed in advance. Whereas a function can decide whether to display e.g. days+hours or hours+minutes depending on whether the time is longer or shorter than 24h. You can define the format specification with any semantics you want, including alternatives like those suggested above. OK, I get it now. I was interpreting format specification to mean format string, but that's not what you meant. A defcustom that can either be a format string *or* a function might be an option. What I'm saying is that this whole business of exposing formatting functions to the user is somewhat superfluous. But defining a custom format semantics just for this one rather simple case also seems somewhat superfluous. We already have a clean, well-known, well-understood semantics for expressing conditionals: Elisp. I'm not sure we've hit upon the clean solution yet... Looking through the code, it seems the clocksum format options are used in two places: org-colview.el and org-clock.el. For some reason, only the latter honours `org-time-clocksum-use-fractional'. In my patch, only the former honoured the new `org-time-clocksum-days-format'. Some rationalisation of all these options is clearly needed. Most users are probably happy with the defaults. So the question is how best to allow the small minority who want to tweak the clocksum format to do so. A couple of questions: 1. Is there any real need to allow the org-colview and org-clock formats to be customized independently? Making them the same would simplify things and probably be clearer for users. 2. What are the different formats that users are likely to want? The list can't be very long. I can think of: hh:mm, hh.mm (fractional), dd hh:mm (separate days), dd hh.mm, and possibly MM dd hh:mm and YY MM dd hh:mm. If the above covers everything we want, then what about getting rid of every customization option except `org-time-clocksum-format', and parsing the format string itself to decide how many and what arguments to pass to it? More precisely, if the format string contains :, . or , then the smallest time component is minutes; otherwise it's hours. Pass as many time components as necessary to fill all the % expandos in the format string, from largest to smallest, with either hours or minutes as the smallest. If the format string contains . or , then pass the number of minutes as a fraction (, is used as the decimal separator in many European languages). This would simplify things, and make the format string just do the right thing in all the cases I listed above. On the other hand, it won't allow unusual formats that don't fit the above scheme (but they're not possible now, anyway). Thoughts? Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 01:20:48PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: [snip] [...] what about getting rid of every customization option except `org-time-clocksum-format', and parsing the format string itself to decide how many and what arguments to pass to it? More precisely, if the format string contains :, . or , then the smallest time component is minutes; otherwise it's hours. Pass as many time components as necessary to fill all the % expandos in the format string, from largest to smallest, with either hours or minutes as the smallest. If the format string contains . or , then pass the number of minutes as a fraction (, is used as the decimal separator in many European languages). That would be over-engineering it. This would simplify things, and make the format string just do the right thing in all the cases I listed above. On the other hand, it won't allow unusual formats that don't fit the above scheme (but they're not possible now, anyway). Thoughts? I think it's too much complicated: it requires to know about strange formatting rules. I suggest to keep it simple: just specify a function with fixed arguments to do the job and provide default functions to handle most common cases. I'm fine with a function + sensible defaults, but Achim didn't like it and proposed a custom format syntax instead. org-time-clocksum-format is used all over the place in org-clock.el, often concatenated with other bits of format string. So the changes needed to change it into one function to rule them all are more extensive, though fairly trivial. I'd prefer to see some agreement before I waste time coding something that won't get accepted. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 06:40:20PM +0100, Achim Gratz wrote: Nicolas Goaziou writes: Then let's wait for Achim (Cc'ed) to illustrate what he has in mind, because his proposal is too vague yet to permit discussion about it. What I had in mind was to remove org-time-clocksum-format and replace the associated format calls with a formatting function that has customizable behaviour (how customizable is t.b.d.). (format org-time-clocksum-format h m) = (org--format-time n fmt) Even if nothing else changes, that removes a lot of unnecessary code duplication, like the seven or so different ways to split the hours from the minutes that may or may not agree on their results. I think whatever we end up doing, it's going simply things and remove duplicate code. Which I agree is definitely a good thing. This is not far from your own suggestion to provide different functions depending on which output is desired, I just happen to think that these functions would all be so similar that they should be rolled into a single function that can produce different outputs. I think there'd only be a handful of possible values for fmt based on the current usage and that suggests just another cond form would be needed in implementing this function rather than a full-blown format string interpreter. It seems to me your `org--format-time' function would end up looking very like what I sketched. A cond to switch between hh:mm, hh.mm, dd hh:mm or dd hh.mm based only on the contents of the fmt argument would have to check whether fmt contains 2 or 3 %-sequences, then check if it contains . or : If these 4 options are the only ones that are ever going to be useful, we could instead just have a single defcustom with a 4-way choice (between 4 different descriptive symbols). This would remove some flexibility from the existing version (as well as adding some), but it's simpler than partially parsing the fmt string. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] [PATCH] Separate clocksum format for durations = 1 day
Personally, I find the time duration 123:15 much harder to parse mentally than 5d 3:15. The attached patch adds a new customization option `org-time-clocksum-days-format'. When non-nil, this is used instead of `org-time-clocksum-format' for clocksum durations longer than 1 day. It gets passed three values: # days, # hours, # mins. (Note that you don't have to use all three in the format if, say, you don't feel the need to display the minutes for such long durations.) In the patch, I've set the default value for this new customization option to a non-nil value. If you prefer to keep the current behaviour as the default, just make the default value nil. Toby PS: I guess the logical extrapolation of this is to add even more `org-time-clocksum-[months|years|decades]-format' options. (Or, probably better, abandon printf formats for long durations and just add an `org-time-clocksum-format-function' option, leaving it up users to define a function to format the time as they wish.) I haven't done this in the patch, because I think 64d 3:15 is no harder to parse than 2m 4d 3:15 (plus there's the thorny issue of how many days should be in a month). And by the time you get to 535d 3:15 vs. 2y 5d 3:15, the duration is so long that you probably don't care much about the exact value, except that it's a very long-running task indeed! -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 2891e0500265df24461d85493e70c1d31c095408 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Wed, 17 Oct 2012 20:48:41 +0200 Subject: [PATCH] Allow separate format for clocksum lines longer than 1 day. Configured by new org-time-clocksum-days-format customization option. --- lisp/org-colview.el |7 +-- lisp/org.el |6 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index 9d58b5f..244458f 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -1058,8 +1058,11 @@ Don't set this, this is meant for dynamic scoping.) ((memq fmt '(estimate)) (org-estimate-print n printf)) ((not (numberp n)) ) ((memq fmt '(add_times max_times min_times mean_times)) -(let* ((h (floor n)) (m (floor (+ 0.5 (* 60 (- n h)) - (format org-time-clocksum-format h m))) +(let* ((h (floor n)) (m (floor (+ 0.5 (* 60 (- n h) (d (/ h 24))) + (if (or (= d 0) (null org-time-clocksum-days-format)) + (format org-time-clocksum-format h m) + (setq h (- h (* 24 d))) + (format org-time-clocksum-days-format d h m ((eq fmt 'checkbox) (cond ((= n (floor n)) [X]) (( n 1.) [-]) diff --git a/lisp/org.el b/lisp/org.el index 2aa70bd..2eb65d6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -2720,6 +2720,12 @@ This is also used when org-mode generates a time duration. :group 'org-time :type 'string) +(defcustom org-time-clocksum-days-format %dd %d:%02d + The format string used for CLOCKSUM lines longer than 1 day. +If null, fall back to `org-time-clocksum-format'. + :group 'org-time + :type '(choice (string :tag format) (const :tag disabled nil))) + (defcustom org-time-clocksum-use-fractional nil If non-nil, \\[org-clock-display] uses fractional times. org-mode generates a time duration. -- 1.7.8.6
[O] [PATCH] Fix bug in org-agenda-diary-sexp-prefix
The commit message in the attached patch explains the problem, and the simple fix. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From b777c7ca29c74476893dd62599c344c0ff5998e6 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Fri, 26 Oct 2012 14:06:28 +0200 Subject: [PATCH] Fix bug in org-agenda-diary-sexp-prefix * lisp/org-agenda.el (org-agenda-get-sexps): reset `extra' to nil at beginning of re-search-forward loop, otherwise next iteration picks up `extra' value from previous entry. --- lisp/org-agenda.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index b9588bb..a2ed3b6 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -5482,7 +5482,8 @@ Do we have a reason to ignore this TODO entry because it has a time stamp? tags (save-excursion (org-backward-heading-same-level 0) (org-get-tags-at)) todo-state (org-get-todo-state) - warntime (org-entry-get (point) APPT_WARNTIME)) + warntime (org-entry-get (point) APPT_WARNTIME) + extra nil) (dolist (r (if (stringp result) (list result) -- 1.7.8.6
[O] bug#11774: bug#11774: bug#11774: org-mode causes undo boundaries to be lost
On Tue, Jul 03, 2012 at 05:18:50PM -0700, Samuel Wales wrote: On 7/3/12, Stefan Monnier monn...@iro.umontreal.ca wrote: self-insert-command. Even just turning that magic 20 number into a variable would help. Providing it as a variable would be very easy, indeed. Therefore, IF we have that variable, then undo-boundary considerations should be simply to DTRT for undo-tree, org-self-insert-command, and other code, in such a way that subtle bugs are prevented. Just to clarify the situation with undo-tree: it doesn't care how or when undo boundaries are inserted, and never did. The problem was only that undo boundaries that had nothing to do with self-insert-command were being *deleted*, due to the subtle interaction between the new Emacs-24 self-insert-command and org-mode's org-self-insert-cluster-for-undo feature. I've already pushed a change to the git version of undo-tree to make it work even if something else deletes undo boundaries that it shouldn't have touched (e.g. org-mode + Emacs-24). Deleting boundaries that have nothing to do with self-insert-command is still a bug, in my opinion, but it's a bug that no longer has catastrophic consequences in undo-tree-mode. It sounds from the preceding discussion that the right solution is simply to disable org-self-insert-cluster-for-undo in Emacs-24, since the purpose of org-mode's clustering was to recover the normal clustering behaviour and the standard self-insert-command clustering now works in org-mode with Emacs-24. The question of how to customize the clustering granularity seems to me to be a separate question (which can presumably be solved by making the hard-coded 20 into a variable). Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
On Mon, Jul 02, 2012 at 08:51:48AM +0200, Martin Pohlack wrote: I'm still not entirely convinced that the boundary discarding logic in org-self-insert-command is correct. For example, if I do the following: 1. Type some text at some location in an org-mode buffer 2. Move to another location very far away (without invoking any commands other than point motion) 3. Type some more text then org-self-insert-cluster-for-undo collapses the undo changesets for these two changes into one. Undoing then reverts both sets of changes at once, even though those changes might be so far apart that they aren't both visible at the same time in the buffer. That seems very undesirable to me. Having been involved in org-mode's collapsing code I am interested in this, but I cannot reproduce your problem. I used a very large org-mode file, inserted some text, moved down some pages and inserted some text again (3 chars each). Undoing was split between both parts, exactly as desired. Could you provide more details please? Sure. The following steps produce the effect I described, at least for me. This is on a fairly recent (a couple of weeks old) bzr build of Emacs, and a similarly recent git build of org-mode: 1. $ emacs -Q 2. C-x C-f test.org 3. M-x org-mode [not really necessary since already in org-mode] 5. C-u 50 M-x newline 6. M- 7. type a 8. M- 9. type bc buffer-undo-list now contains: (nil (52 . 54) (1 . 2) nil (1 . 51) (t . -1)) Note the lack of undo boundary between (52 . 54) and (1 . 2), which means that undoing once (C-/) deletes both bc *and* a in one step. HTH, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] bug#11774: org-mode causes undo boundaries to be lost
On Sun, Jun 24, 2012 at 11:52:41PM +0200, Toby Cubitt wrote: On Sun, Jun 24, 2012 at 11:39:08PM +0200, Bastien wrote: Hi Toby, Toby Cubitt ts...@cantab.net writes: For some unknown reason, org-mode is causing the undo boundary between the (2 . 4) and (1 . 2) entries to be removed from `buffer-undo-list'. Can you try again with (setq org-self-insert-cluster-for-undo nil) and report? Yup, that fixes the problem. I don't fully understand the purpose of `org-self-insert-cluster-for-undo', given that the Emacs command loop already groups consecutive undo entries together, but presumably it enables a more aggressive form of clustering. [snip] I could try to work around this in undo-tree-mode, but it seems to me that org-mode shouldn't be throwing away an undo boundary that comes before an entry which definitely shouldn't be clustered with anything (namely the undo-tree-canary symbol, which is meaningless to org-mode). I've now added a work-around for this in undo-tree-mode (currently only in git, but I'll push to ELPA once it's sufficiently tested). I'm still not entirely convinced that the boundary discarding logic in org-self-insert-command is correct. For example, if I do the following: 1. Type some text at some location in an org-mode buffer 2. Move to another location very far away (without invoking any commands other than point motion) 3. Type some more text then org-self-insert-cluster-for-undo collapses the undo changesets for these two changes into one. Undoing then reverts both sets of changes at once, even though those changes might be so far apart that they aren't both visible at the same time in the buffer. That seems very undesirable to me. But as I can work around it in undo-tree-mode, I'll leave it up to Bastien to decide whether or not this feature needs reworking in org-mode. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] Filter depending on item level
On Sun, Apr 29, 2012 at 09:27:50PM -0500, Marcelo de Moraes Serpa wrote: Is there a way to filter the agenda based on the level of the item. Try the special LEVEL search property, documented in the Matching tags and properties section of the manual. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
On Thu, Apr 26, 2012 at 10:59:50AM +0200, Bastien wrote: Hi Matt, Matt Lundin m...@imapmail.org writes: Note: It seems that adding the optional argument KEEPDATE is necessary for parsing to work. With the following line instead of the one above org-read-date works as expected: (org-eval-in-calendar '(setq cursor-type nil) t) that's right -- I pushed this fix to master. Thanks for reporting this and for detailing the solution! Thanks for the fix! What exactly does KEEPDATE argument do? The `org-eval-in-calendar' docstring doesn't mention it anywhere, which is probably why I missed it in my patch. Looking at the code, it seems that the part about storing the cursor date in org-ans2 only happens for a non-nil KEEPDATE? I'd post an update to improve the `org-eval-in-calendar' docstring, but I don't feel like I really understand what the KEEPDATE argument does well enough. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Allow %num escapes to capture templates, expanded to text entered in num'th prompt
On Tue, Apr 24, 2012 at 11:57:02AM +0200, Bastien wrote: I've pushed a change to this new feature: http://orgmode.org/w/?p=org-mode.git;a=commit;h=1666b9 Using %n is not good, because it will match many escaped strings that you don't want to match. Using %\n looks good to me as it resonates with \1 in replace-regexp. Toby, let me know if you agree with this change. I'm fine with it. But I don't understand, what other escapes will it match? None of the other % escapes documented in org-capture-templates start with a digit, they all start with a letter or punctuation. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Allow %num escapes to capture templates, expanded to text entered in num'th prompt
On Tue, Apr 24, 2012 at 02:51:29PM +0200, Bastien wrote: Toby Cubitt ts...@cantab.net writes: On Tue, Apr 24, 2012 at 11:57:02AM +0200, Bastien wrote: I've pushed a change to this new feature: http://orgmode.org/w/?p=org-mode.git;a=commit;h=1666b9 Using %n is not good, because it will match many escaped strings that you don't want to match. Using %\n looks good to me as it resonates with \1 in replace-regexp. Toby, let me know if you agree with this change. I'm fine with it. But I don't understand, what other escapes will it match? None of the other % escapes documented in org-capture-templates start with a digit, they all start with a letter or punctuation. It is not the escapes from the capture template itself, but at the time the capture buffer is prepared, links go to `org-make-link-string' which calls `org-link-escape' which might in turn insert %20 strings. Ah, I get it now. Your %\n syntax looks to be a good choice. I'll pull your changes and update my org-capture-template setting. Thanks! Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] Simplify repeated same section with different variable value
On Tue, Apr 24, 2012 at 03:01:44PM +0200, Rainer M Krug wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/04/12 14:36, Myles English wrote: On Tue, 24 Apr 2012 14:22:48 +0200, Rainer M Krug said: Hi I have a section which I want to repeat for different variable values. At the moment I am copying them, but I do not like it at all: ** Species one :PROPERTIES: :var: SPECIES=sp1 :END: *** Data Checks Here is some text #+header: :results output #+begin_src R checkData(species=SPECIES) #+end_src ** Species 2 :PROPERTIES: :var: SPECIES=sp2 :END: *** Data Checks Here is some text #+header: :results output #+begin_src R checkData(species=SPECIES) #+end_src I am sure there must be an easier way with org? How about using yasnippet? Yasnippets would help in filling the file with the repeated code - but if I want to change e.g. some text to some more text, I still have to do it manually. Nevertheless, if I could define the org section once and repeat it with different variable values, this would enable me to change it only once. I don't personally know of an org-specific way. But you can do amazing things with `query-replace-regexp' in Emacs, especially the \# and \, escapes which, respectively, let you embed the replacement counter and arbitrary elisp code in the replacement string. (See the docstring or Emacs manual for details.) Whether you consider writing regexps and elisp snippets easier is open to debate... Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Allow %num escapes to capture templates, expanded to text entered in num'th prompt
On Mon, Apr 23, 2012 at 02:54:31PM +0200, Bastien wrote: Toby Cubitt ts...@cantab.net writes: Currently, capture templates provide no way of prompting for some text, then inserting that text into multiple places in the template. Thanks for the patch, I applied it. I also updated the documentation in doc/org.texi -- please provide documentation in the patch containing code changes if relevant next times. Ah, I forgot about the texinfo docs. Sorry. I'll try to remember them next time. One tiny thing: the documentation said that %0 would match the first occurrence but while I tested the first occurrence was on %1, which looks better to me. So I updated the documentation accordingly. Yes, you're right, it starts from 1. That's what comes of adding the documentation later, as an after-thought...(bad programming practice!) And now I look at it again, there's a bug in the regexp (my fault): the regexp %\\([1-9]\\)+ currently matches any sequence of 1-9's, which is clearly wrong. The two possible fixes are: - Drop the final + from the regexp so that it reads %\\([1-9]\\), to match any single non-zero digit, as per the current docs. (The regexp group must be kept, because it's used later in the code.) - Change the regexp to %\\([1-9][0-9]*\\), to match any positive integer, and update the docs accordingly. It seems unlikely anyone would ever want to refer back to more than 9 prompts in a capture template. (I think back-references in Emacs regexps are similarly limited to single digits). On the other hand, whenever someone says it seems unlikely anyone would ever want to... about Emacs, up pops someone who wants to do exactly that ;-) Your call. If you tell me which fix you prefer, I can supply a patch if you want one (though the change is so small I imagine it'll be easier to do it manually). Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Allow %num escapes to capture templates, expanded to text entered in num'th prompt
On Mon, Apr 23, 2012 at 05:12:51PM +0200, Bastien wrote:
Hi Toby,
Toby Cubitt ts...@cantab.net writes:
Ah, I forgot about the texinfo docs. Sorry. I'll try to remember them
next time.
No problem.
- Change the regexp to %\\([1-9][0-9]*\\), to match any positive
integer, and update the docs accordingly.
Please send a patch for this solution.
Attached (this time including a texinfo documentation update ;-)
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
From 4407cd46e3cf8339a9c90d4dde8337b7dbaca048 Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Mon, 23 Apr 2012 17:20:19 +0200
Subject: [PATCH] org-capture.el: Fixed bug in org-capture-templates %n
expandos
* lisp/org-capture.el (org-capture-fill-template): Fixed regexp for
%n expandos to match any positive integer.
(org-capture-templates): Updated docstring accordingly.
* doc/org.texi: Updated documentation accordingly.
---
doc/org.texi|4 ++--
lisp/org-capture.el |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index a25572d..bb98713 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -6700,8 +6700,8 @@ dynamic insertion of content. The templates are expanded in the order given her
@r{You may specify a default value and a completion table with}
@r{%^@{prompt|default|completion2|completion3...@}.}
@r{The arrow keys access a prompt-specific history.}
-%n@r{Insert the text entered for at the nth %^{prompt}, where n}
-@r{represents a digit, 1 to 9.}
+%n@r{Insert the text entered at the nth %^{prompt}, where n is}
+@r{a number, starting from 1.}
%? @r{After completing the template, position cursor here.}
@end smallexample
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 7fbd438..d507cc2 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -248,8 +248,8 @@ be replaced with content and expanded in this order:
A default value and a completion table ca be specified like this:
%^{prompt|default|completion2|completion3|...}.
%? After completing the template, position cursor here.
- %nInsert the text entered for at the nth %^{prompt}, where n
- represents a digit, 1 to 9.
+ %nInsert the text entered at the nth %^{prompt}, where n is
+ a number, starting from 1.
Apart from these general escapes, you can access information specific to the
link type that is created. For example, calling `org-capture' in emails
@@ -1480,7 +1480,7 @@ The template may still contain \%?\ for cursor positioning.
;; Replace %n escapes with nth %^{...} string
(setq strings (nreverse strings))
(goto-char (point-min))
- (while (re-search-forward %\\([1-9]\\)+ nil t)
+ (while (re-search-forward %\\([1-9][0-9]*\\) nil t)
(unless (org-capture-escaped-%)
(replace-match
(nth (1- (string-to-number (match-string 1))) strings)
--
1.7.8.5
Re: [O] make fails on current version
On Mon, Apr 23, 2012 at 09:57:25AM -0700, Richard Stanton wrote:
I just updated org-mode and typed make. Two problems:
1) The doc file seems to have trouble:
org.texi:6703: Misplaced {.
org.texi:6703: Misplaced }.
makeinfo: Removing output file `org' due to errors; use --force to
preserve.
The problem's in the texinfo documentation for the new %n capture
template expandos...but please don't shoot me, it's not my fault! (I just
modified the change that Bastien had already committed to org.texi.)
From the texinfo documentation, it looks like literal { and } have to
be escaped with @. Patch attached.
2) org-install.el doesn't get created.
From org-version.el, this is git version release_7.8.09-375-gb7982a
(org-version just returns N/A).
No idea about this one.
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
From 9fd3ba1bdfbb3b608fcd86ded73f02c53d50e05d Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Mon, 23 Apr 2012 19:25:57 +0200
Subject: [PATCH] Fixed bug in texinfo documentation.
* doc/org.texi: Escape literal {}'s.
---
doc/org.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index bb98713..18dba90 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -6700,7 +6700,7 @@ dynamic insertion of content. The templates are expanded in the order given her
@r{You may specify a default value and a completion table with}
@r{%^@{prompt|default|completion2|completion3...@}.}
@r{The arrow keys access a prompt-specific history.}
-%n@r{Insert the text entered at the nth %^{prompt}, where n is}
+%n@r{Insert the text entered at the nth %^@{prompt@}, where n is}
@r{a number, starting from 1.}
%? @r{After completing the template, position cursor here.}
@end smallexample
--
1.7.8.5
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
On Sun, Apr 22, 2012 at 08:46:03AM +0200, Bastien wrote: Toby Cubitt ts...@cantab.net writes: Was there some reason to reject Eli's suggested fix of enlarging the calendar window by 1 line? As it stands, if anyone customizes the new org-date-selected face to be bold (the highlighted date *is* a little less visible now), it will cause the same problem as before. And the fact that it's caused by making the font bold is not at all obvious...at least, it wasn't obvious to me! Eli's fix works more generally. This general solution comes with a cost -- enlarging the window by one-line for everyone just because a few users will use bold fonts and have a problem while displaying... does not feel right to me. Fair enough. Anyway, since I now know how to patch things if I do decide I want a bold font, it's not a big issue for me. In the patch I posted, I also took the opportunity to set `cursor-type' to nil when opening the calendar in `org-read-date'. The cursor obscures one digit of the selected date, making that bit harder to read (as well as looking ugly). Did you intend to reject this change too? I did because I found the not-bold-anymore face wasn't visible enough, and the shallow cursor made it visible. I use inverse-video now for this face, so cursor-type nil is okay, I applied a patch with this. Inverse-video is a good solution - thanks! Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] [PATCH] Extract prefix information from diary sexp entries for agenda display
This patch adds a new org-agenda-diary-sexp-prefix customization option. It can be set to a regexp which is used to match the part of the text produced by a diary sexp entry that should be treated as deadlining/scheduling information (the prefix), and displayed as such in agenda views. For example, let's say diary-remind-message is set to '(In (format %3d d. days) : diary-entry) to match the default format used for upcoming deadlines in org-mode. Then the following diary-remind entry %%(diary-remind '(diary-date t 4 30) -14) Don't forget this birthday will produce a line something like this: In 7 d.: Don't forget this birthday in agenda views. But the In 7 d.: part will be displayed as part of the entry, *not* in the prefix column where org-mode displays deadline and scheduling information for normal org items, which looks like this: In 2 d.: TODO Important thing to do soon In 7 d.: Don't forget this birthday Deadline: TODO Do this today or else! Setting org-agenda-diary-sexp-prefix to the regexp ^In +[0-9]+ d\\.: will extract the In x days: part of a diary sexp entry, and display it as the prefix (i.e. deadline/scheduling info) for the entry in agenda views, aligning it with the prefixes from org-mode's own deadline entries: In 2 d.: TODO Important thing to do soon In 7 d.: Don't forget this birthday Deadline: TODO Do this today or else! More generally, org-mode has access to a lot of structured information about its own agenda entries. But a diary sexp entry hands org-mode a lump of output text, with no structure to tell it what information is represented by different parts of that text. `org-agenda-diary-sexp-prefix' gives you a way of telling org-mode how to extract scheduling and deadline information from that lump of text. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 35e623da77892650b8a9ffab89a62a32192eab6c Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Sun, 29 Jan 2012 10:51:46 +0100 Subject: [PATCH] Agenda: Add org-agenda-diary-sexp-prefix customization option * lisp/org-agenda.el (org-agenda-diary-sexp-prefix): Regexp matching deadline/scheduling information to be displayed in diary sexp agenda items. (org-agenda-get-sexps): Extract deadline/scheduling information from diary sexp entries. --- lisp/org-agenda.el | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 796f158..1af37c1 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -1516,6 +1516,16 @@ to occupy a fixed space in the agenda display. :group 'org-agenda-line-format :type 'string) +(defcustom org-agenda-diary-sexp-prefix nil + A regexp that matches part of a diary sexp entry +which should be treated as scheduling/deadline information in +`org-agenda'. + +For example, you can use this to extract the `diary-remind-message' from +`diary-remind' entries. + :group 'org-agenda-line-format + :type '(choice (const :tag None nil) (regexp :tag Regexp))) + (defcustom org-agenda-timerange-leaders '( (%d/%d): ) Text preceding timerange entries in the agenda view. This is a list with two strings. The first applies when the range @@ -5046,7 +5056,7 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', (format mouse-2 or RET jump to org file %s (abbreviate-file-name buffer-file-name (regexp ^?%%() - marker category org-category-pos ee txt tags entry + marker category extra org-category-pos ee txt tags entry result beg b sexp sexp-entry todo-state) (goto-char (point-min)) (while (re-search-forward regexp nil t) @@ -5070,12 +5080,16 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', (dolist (r (if (stringp result) (list result) result)) ;; we expect a list here + (when (and org-agenda-diary-sexp-prefix + (string-match org-agenda-diary-sexp-prefix r)) + (setq extra (match-string 0 r) + r (replace-match nil nil r))) (if (string-match \\S- r) (setq txt r) (setq txt SEXP entry returned empty string)) (setq txt (org-agenda-format-item - txt category tags 'time)) + extra txt category tags 'time)) (org-add-props txt props 'org-marker marker) (org-add-props txt nil 'org-category category 'date date 'todo-state todo-state -- 1.7.8.5
[O] [PATCH] Add option to skip timestamp entries if already displayed as deadline entries in agenda
This one's pretty self-explanatory. It adds an `org-agenda-skip-timestamp-if-deadline-is-shown' customization option, precisely analogous to the existing `org-agenda-skip-scheduled-if-deadline-is-shown' option. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 5cae4b80d34ed7ba54532bf0a029384fcd1353a8 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Sun, 29 Jan 2012 13:02:27 +0100 Subject: [PATCH] Agenda: Add org-agenda-skip-timestamp-if-deadline-is-shown * lisp/org-agenda.el (org-agenda-skip-timestamp-if-deadline-is-shown): Skip timestamp items in agenda view if item is already shown as a deadline item. (org-agenda-skip-dealine-if-done): Pass deadline results to org-agenda-get-timestamps. (org-agenda-get-timestamps): Optionally take list of deadline results, so that timestamp results can be skipped if already included in deadline results. --- lisp/org-agenda.el | 27 +-- 1 files changed, 25 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 796f158..aa433fa 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -776,6 +776,20 @@ but not scheduled today. (const :tag Always t) (const :tag Not when scheduled today not-today))) +(defcustom org-agenda-skip-timestamp-if-deadline-is-shown nil + Non-nil means skip timestamp line if same entry shows because of deadline. +In the agenda of today, an entry can show up multiple times +because it has both a plain timestamp and has a nearby deadline. +When this variable is t, then only the deadline is shown and the +fact that the entry has a timestamp for or including today is not +shown. When this variable is nil, the entry will be shown +several times. + :group 'org-agenda-skip + :group 'org-agenda-daily/weekly + :type '(choice + (const :tag Never nil) + (const :tag Always t))) + (defcustom org-agenda-skip-deadline-if-done nil Non-nil means don't show deadlines when the corresponding item is done. When nil, the deadline is still shown and should give you a happy feeling. @@ -4785,7 +4799,7 @@ the documentation of `org-diary'. ((eq arg :timestamp) (setq rtn (org-agenda-get-blocks)) (setq results (append results rtn)) - (setq rtn (org-agenda-get-timestamps)) + (setq rtn (org-agenda-get-timestamps deadline-results)) (setq results (append results rtn))) ((eq arg :sexp) (setq rtn (org-agenda-get-sexps)) @@ -4937,7 +4951,7 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', (defconst org-agenda-no-heading-message No heading for this item in buffer or region.) -(defun org-agenda-get-timestamps () +(defun org-agenda-get-timestamps (optional deadline-results) Return the date stamp information for agenda display. (let* ((props (list 'face 'org-agenda-calendar-event 'org-not-done-regexp org-not-done-regexp @@ -4948,6 +4962,12 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', (format mouse-2 or RET jump to org file %s (abbreviate-file-name buffer-file-name (d1 (calendar-absolute-from-gregorian date)) + mm + (deadline-position-alist + (mapcar (lambda (a) (and (setq mm (get-text-property + 0 'org-hd-marker a)) + (cons (marker-position mm) a))) + deadline-results)) (remove-re (concat (regexp-quote @@ -5015,6 +5035,9 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', (if (not (re-search-backward org-outline-regexp-bol nil t)) (setq txt org-agenda-no-heading-message) (goto-char (match-beginning 0)) + (if (and (eq t org-agenda-skip-timestamp-if-deadline-is-shown) + (assoc (point) deadline-position-alist)) + (throw :skip nil)) (setq hdmarker (org-agenda-new-marker) tags (org-get-tags-at)) (looking-at \\*+[ \t]+\\([^\r\n]+\\)) -- 1.7.8.5
[O] [PATCH] Allow %num escapes to capture templates, expanded to text entered in num'th prompt
Currently, capture templates provide no way of prompting for some text,
then inserting that text into multiple places in the template.
This patch allow you to do this, by adding %n escapes to the template
syntax (where n is a digit, 0 to 9), which expand to the text entered
for the nth prompt in the template (as specified in the template using
the usual %^{prompt} syntax).
Useful for populating a subtree with an entire sequence of related TODOs,
capturing a multi-step task.
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
From 0e917539324fdc32cd0878b0819cb28b79f30f01 Mon Sep 17 00:00:00 2001
From: Toby S. Cubitt ts...@cantab.net
Date: Sat, 28 Jan 2012 17:04:05 +0100
Subject: [PATCH] Capture: Add %num escapes to org capture templates
* lisp/org-capture.el (org-capture-fill-template): Expand %num
escape sequences into text entered for num'th %^{PROMPT} escape.
---
lisp/org-capture.el | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index f0afc70..2daca72 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -248,6 +248,8 @@ be replaced with content and expanded in this order:
A default value and a completion table ca be specified like this:
%^{prompt|default|completion2|completion3|...}.
%? After completing the template, position cursor here.
+ %nInsert the text entered for at the nth %^{prompt}, where n
+ represents a digit, 0 to 9.
Apart from these general escapes, you can access information specific to the
link type that is created. For example, calling `org-capture' in emails
@@ -1326,7 +1328,7 @@ The template may still contain \%?\ for cursor positioning.
(org-startup-folded nil)
(org-inhibit-startup t)
org-time-was-given org-end-time-was-given x
- prompt completions char time pos default histvar)
+ prompt completions char time pos default histvar strings)
(setq org-store-link-plist
(plist-put org-store-link-plist :annotation v-a)
@@ -1468,11 +1470,21 @@ The template may still contain \%?\ for cursor positioning.
nil nil (list org-end-time-was-given)))
(t
(let (org-completion-use-ido)
- (insert (org-completing-read-no-i
- (concat (if prompt prompt Enter string)
- (if default (concat [ default ]))
- : )
- completions nil nil nil histvar default)))
+ (push (org-completing-read-no-i
+ (concat (if prompt prompt Enter string)
+ (if default (concat [ default ]))
+ : )
+ completions nil nil nil histvar default)
+ strings)
+ (insert (car strings)))
+ ;; Replace %n escapes with nth %^{...} string
+ (setq strings (nreverse strings))
+ (goto-char (point-min))
+ (while (re-search-forward %\\([1-9]\\)+ nil t)
+ (unless (org-capture-escaped-%)
+ (replace-match
+ (nth (1- (string-to-number (match-string 1))) strings)
+ nil t)))
;; Make sure there are no empty lines before the text, and that
;; it ends with a newline character
(goto-char (point-min))
--
1.7.8.5
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
On Fri, Apr 20, 2012 at 01:57:55PM +0200, Bastien wrote: Toby Cubitt ts...@cantab.net writes: On Mon, Apr 16, 2012 at 05:50:50AM +0300, Eli Zaretskii wrote: Date: Sun, 15 Apr 2012 23:04:16 +0200 Cc: 11...@debbugs.gnu.org, emacs-orgmode@gnu.org From: Toby Cubitt toby-dated-1335733484.f89...@dr-qubit.org The obvious solution is for org-mode to use a face that doesn't enlarge the characters. Another solution would be to enlarge the calendar window by one line. I've attached a patch that does exactly this. As expected, it fixes the bug for me. As discussed previously, the alternative solution would be to change the default face used to highlight the current date to something that doesn't set the :bold attribute (which would probably mean introducing a separate face for this, instead of reusing org-warning). But expanding the calendar window is a more general solution, as it fixes the problem for (almost) any face. I introduced a new face `org-date-selected' which is now the one in use in the calendar and which is not bold. Thanks for the fix. I notice that the new face's dosctring still says Face for deadlines and TODO keywords, which needs changing. Was there some reason to reject Eli's suggested fix of enlarging the calendar window by 1 line? As it stands, if anyone customizes the new org-date-selected face to be bold (the highlighted date *is* a little less visible now), it will cause the same problem as before. And the fact that it's caused by making the font bold is not at all obvious...at least, it wasn't obvious to me! Eli's fix works more generally. Anyway, since I now know how to patch things if I do decide I want a bold font, it's not a big issue for me. In the patch I posted, I also took the opportunity to set `cursor-type' to nil when opening the calendar in `org-read-date'. The cursor obscures one digit of the selected date, making that bit harder to read (as well as looking ugly). Did you intend to reject this change too? Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] Various org-mode patches
On Fri, Apr 20, 2012 at 01:59:42PM +0200, Bastien wrote: Hi Toby, Toby Cubitt ts...@cantab.net writes: I finally found time to gather various local patches to org-mode together in a public clone of the org-mode git repo, at: http://www.dr-qubit.org/git/org-mode.git If there are patches that still need to be applied from this branch, can you send them one by one on the list? Sure, no problem. As you've no doubt seen, I already sent some of them separately. But I didn't want to bombard you with too many all at once ;-) So I paused on sending out the others. I'll post the others one by one when I find a spare moment. Cheers, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Allow more control over inserted whitespace in capture templates
Was there any feedback on this patch, or did it get lost in the noise? At least for me, org-capture breaks the document heading layout by inserting incorrect amounts of whitespace. And there's no way to configure capture templates to make it work correctly. The patch I posted fixes this behaviour. (Or am I missing some already-existing way of doing this? See below for a detailed description of the problem.) Toby On Mon, Feb 13, 2012 at 01:26:09PM +0100, Toby Cubitt wrote: When capturing an item as a subheading, the capture template :empty-lines property is not sufficient to ensure the correct document layout is maintained after capturing. This patch fixes the capture behaviour to insert new subheadings immediately after the previous heading (rather than immediately before the next one). And it adds new :empty-lines-before and :empty-lines-after capture template properties. (I can split these two changes into separated patches, if desired.) When set, the new :empty-lines-before and :empty-lines-after properties take precedence over :empty-lines in determining the amount of whitespace to add before or after the captured item, respectively. Together, these changes allow the correct document layout to be achieved after capturing, without any manual editing. (Since the whole idea of org-capture is to rapidly capture new ideas or todos, having to manually edit whitespace after capturing to fix the document layout is far from ideal.) To give a more detailed example of why I think these changes are needed, consider for example an org-mode document in which headings are separated by two empty lines, and subheadings are separated by a single empty line. (This is a natural layout if one wants headings to be separated by whitespace when folded, but subheadings not to be separated when folded): * heading 1 ** subheading 1.1 ** subheading 1.2 * heading 2 ** subheading 2.1 Let's say I want add a captured item as a new subheading 1.3 under heading 1, preserving this layout structure. Then we need to add the new item immediately after subheading 1.2, inserting one empty line before and two empty lines after. There appears to be no way to do this using :empty-lines. In fact, the existing implementation adds the new capture item immediately *before* the *following* heading (heading 2 in this case), which seems to be altogether wrong, as it effectively forces two empty lines before the new item, regardless of the :empty-lines setting. Currently, setting :empty-lines to 0 leaves the document looking like this: * heading 1 ** subheading 1.1 ** subheading 1.2 ** subheading 1.3 * heading 2 ** subheading 2.1 whilst setting :empty-lines to 1 leaves the document looking like this: * heading 1 ** subheading 1.1 ** subheading 1.2 ** subheading 1.3 * heading 2 ** subheading 2.1 neither of which are likely to ever be what we want. With this patch, setting the new :empty-lines-before to 1 and :empty-lines-after to 2 results in the correct structure after capturing: * heading 1 ** subheading 1.1 ** subheading 1.2 ** subheading 1.3 * heading 2 ** subheading 2.1 I think this patch is largely orthogonal to the recent removing whitespace from new captures patch (currently in patchwork). That patch causes `whitespace-cleanup' to be called in the CAPTURE buffer before finalizing, which doesn't affect the additional whitespace inserted later on by the :empty-lines property. This patch allows more control over the latter, by providing a fairly simple extension of the existing :empty-lines property. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
On Mon, Apr 16, 2012 at 05:50:50AM +0300, Eli Zaretskii wrote: Date: Sun, 15 Apr 2012 23:04:16 +0200 Cc: 11...@debbugs.gnu.org, emacs-orgmode@gnu.org From: Toby Cubitt toby-dated-1335733484.f89...@dr-qubit.org The obvious solution is for org-mode to use a face that doesn't enlarge the characters. Another solution would be to enlarge the calendar window by one line. I've attached a patch that does exactly this. As expected, it fixes the bug for me. As discussed previously, the alternative solution would be to change the default face used to highlight the current date to something that doesn't set the :bold attribute (which would probably mean introducing a separate face for this, instead of reusing org-warning). But expanding the calendar window is a more general solution, as it fixes the problem for (almost) any face. Arguably, it might be worth defining a separate face for highlighting the date in the calendar during org-read-date, even if this patch is applied, so that it can be customized separately from the face for impending todo deadlines etc. If there's interest in adding a new calendar-date-highlight face, I can post a separate patch for that. For the record, one can already change the face used to highlight the date in the calendar from within .emacs, via (overlay-put org-date-ovl 'face 'new-face) But that's much less discoverable than defining a separate face for this. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 107b18f3ee306c0cd28566c8e7e5ba94c4b9268c Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Mon, 16 Apr 2012 14:22:35 +0200 Subject: [PATCH] Enlarge calendar by 1 line to fix scrolling bug when selecting date. * lisp/org.el (org-read-date): Enlarge calendar window by 1 line, and make cursor invisible. --- lisp/org.el |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 170ddc9..18ae685 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15106,6 +15106,8 @@ user. (save-excursion (save-window-excursion (calendar) + (org-eval-in-calendar + '(progn (enlarge-window 1) (setq cursor-type nil))) (unwind-protect (progn (calendar-forward-day (- (time-to-days org-def) -- 1.7.8.5
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
On Sun, Apr 15, 2012 at 11:41:00PM +0300, Eli Zaretskii wrote: Date: Sun, 15 Apr 2012 21:24:39 +0200 From: Toby Cubitt ts...@cantab.net Steps to reproduce: 1. emacs -Q 2. M-x calendar 3. M-: (setq o (make-overlay 1 2)) 4. M-: (overlay-put o 'face 'font-lock-warning-face) 5. Use C-n to move point to date in the last line of calendar Symptoms: When the point moves to the last line of the calendar in step 5., the calendar buffer scrolls down, so that the top part of the calendar scrolls off the top of the window and can't be seen. This is not a bug, but a feature: Emacs does not allow the cursor to enter a partially visible line; it scrolls the buffer to make the line with the cursor fully visible. Displaying characters in the font-lock-warning-face makes them slightly larger (because that face makes the characters bold), and that can cause the last line to exceed the visible portion of the window. Aha, that makes sense. The above steps are a minimal sequence needed to reproduce the bug. In everyday Emacs use, the bug is triggered by date selection via `org-read-date' in org-mode (which uses an overlay with non-null 'face property in the calendar buffer to highlight the current date). If that face also enlarges the characters, this is a feature of the Emacs display engine. Yup, I chose `font-lock-warning-face' in the steps to reproduce because org-mode sets `org-warning' face to this by default. Even if this behaviour is related to a display engine feature, this is nonetheless a bug in `org-read-date'. It's very irritating to have the top part of the calendar scroll off the top of the window. Apart from being ugly, it hides the month and day names (in addition to half the dates), making it very difficult to select the desired date. The obvious solution is for org-mode to use a face that doesn't enlarge the characters. I imagine that would mean defining a separate org-mode face specifically for highlighting the date in the calendar, since `org-warning' is used for all kinds of other things in org-mode for which bold characters make sense (e.g. warning about todo items whose deadline is due). I've copied this to the org-mode mailing list, since presumably the org-mode maintainers will have to take care of this. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [dev] Implement ref link types
On Sun, Feb 19, 2012 at 08:41:45PM +0100, Nicolas Goaziou wrote:
Suggestion: On export, how about enabling automatic element
descriptions for references following the type:name convention, so
that e.g. just
: in [[ref:tab:numbers]] we can see...
would expand to
in Table 2 we can see...
If implemented, this should be user-customizable e.g. through an alist
like
((fig . Figure) (tab . Table) (map . Map))
That's another possibility, but I'd rather follow LaTeX usage. I think
it gives user more latitude in the end. Indeed, You don't have to think
about a name prefix ; you can also have constructs like Tables
[[ref:table1]], [[ref:table2]] and [[ref:table3]] for Tables 1, 2 and
3, etc.
Note that the behaviour you suggest can easily be implemented using
filters in the new exporter.
Note that for LaTeX export, there's no need to explicitly add names to
references -- LaTeX can figure them out for itself from the label alone,
with a little of help.
There are various CTAN packages implementing this, such as cleveref,
hyperref's \autoref command, varioref's \labelformat command... Cleveref
is arguably the most powerful of these, as you can just chuck references
into a \cref command (which replaces \ref):
\cref{figure1,table1,table3,table2}, and it sorts them all out for you,
to produce Figure~1, and Tables~1 to~3. (Disclaimer: I'm the author of
cleveref.)
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
Re: [O] [PATCH] org-goto before headline
On Mon, Feb 13, 2012 at 12:08:48AM +, Andrea Crotti wrote: On 02/10/2012 02:42 PM, Toby Cubitt wrote: On Fri, Feb 10, 2012 at 02:19:27PM +, Andrea Crotti wrote: What is exactly the reason for org-goto to need to be at least in the first headline to work? I always get this error when I just try to jump in the first line: byte-code: Before first headline at position 1 in buffer .. Do you by any chance have `org-goto-interface' set to outline-path-completion (or are you using org-goto with a prefix argument)? If so, I've also come across this problem. I think it's a bug in org-goto, which should pass NO-EXCLUDE to org-refile-get-location (but doesn't). The attached patch fixes this for me (or you can pull the org-goto branch from http://www.dr-qubit.org/git/org-mode.git). HTH, Toby Is the patch already pushed to master then? Just to check, it would be sad if it gets lost in the way.. I inserted the magic [PATCH] tag in the subject line, so it's been picked up by patchwork (patchwork.newartisans.com/project/org-mode/list/), and will get reviewed by the org-mode maintainers in due course. But they've got a fairly large stack of patches to review, so give them a chance to get to it! The fact that I already have copyright papers for emacs on file with the FSF might help speed things up a bit if it's accepted. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] [PATCH] Allow more control over inserted whitespace in capture templates
When capturing an item as a subheading, the capture template :empty-lines property is not sufficient to ensure the correct document layout is maintained after capturing. This patch fixes the capture behaviour to insert new subheadings immediately after the previous heading (rather than immediately before the next one). And it adds new :empty-lines-before and :empty-lines-after capture template properties. (I can split these two changes into separated patches, if desired.) When set, the new :empty-lines-before and :empty-lines-after properties take precedence over :empty-lines in determining the amount of whitespace to add before or after the captured item, respectively. Together, these changes allow the correct document layout to be achieved after capturing, without any manual editing. (Since the whole idea of org-capture is to rapidly capture new ideas or todos, having to manually edit whitespace after capturing to fix the document layout is far from ideal.) To give a more detailed example of why I think these changes are needed, consider for example an org-mode document in which headings are separated by two empty lines, and subheadings are separated by a single empty line. (This is a natural layout if one wants headings to be separated by whitespace when folded, but subheadings not to be separated when folded): * heading 1 ** subheading 1.1 ** subheading 1.2 * heading 2 ** subheading 2.1 Let's say I want add a captured item as a new subheading 1.3 under heading 1, preserving this layout structure. Then we need to add the new item immediately after subheading 1.2, inserting one empty line before and two empty lines after. There appears to be no way to do this using :empty-lines. In fact, the existing implementation adds the new capture item immediately *before* the *following* heading (heading 2 in this case), which seems to be altogether wrong, as it effectively forces two empty lines before the new item, regardless of the :empty-lines setting. Currently, setting :empty-lines to 0 leaves the document looking like this: * heading 1 ** subheading 1.1 ** subheading 1.2 ** subheading 1.3 * heading 2 ** subheading 2.1 whilst setting :empty-lines to 1 leaves the document looking like this: * heading 1 ** subheading 1.1 ** subheading 1.2 ** subheading 1.3 * heading 2 ** subheading 2.1 neither of which are likely to ever be what we want. With this patch, setting the new :empty-lines-before to 1 and :empty-lines-after to 2 results in the correct structure after capturing: * heading 1 ** subheading 1.1 ** subheading 1.2 ** subheading 1.3 * heading 2 ** subheading 2.1 I think this patch is largely orthogonal to the recent removing whitespace from new captures patch (currently in patchwork). That patch causes `whitespace-cleanup' to be called in the CAPTURE buffer before finalizing, which doesn't affect the additional whitespace inserted later on by the :empty-lines property. This patch allows more control over the latter, by providing a fairly simple extension of the existing :empty-lines property. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 37cfa6214f0875ed7ddceae27948394cf78d18d6 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Sun, 29 Jan 2012 16:52:08 +0100 Subject: [PATCH] Capture: Allow more control over inserted whitespace in capture templates * lisp/org-capture.el (org-capture-place-entry): Place captured entry immediately after last subheading of target, instead of just before next heading at same level as target. * lisp/org-capture.el (org-capture-templates): Document new capture template properties. * lisp/org-capture.el (org-capture-place-entry, org-capture-empty-lines-before): Make new :empty-lines-before property override :empty-lines when inserting empty lines before captured captured entry. * lisp/org-capture.el (org-capture-finalize, org-capture-empty-lines-after): Make new :empty-lines-after property override :empty-lines when inserting empty lines after captured captured entry. --- lisp/org-capture.el | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 01ec85d..d79c5a4 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -183,6 +183,14 @@ properties are: before and after the new item. Default 0, only common other value is 1. + :empty-lines-before Set this to the number of lines the should be inserted + before the new item. Overrides :empty-lines for the + number lines inserted before. + + :empty-lines-after Set this to the
[O] [PATCH] Fix org-agenda-skip-if bug
There appears to be a bug in how org-agenda-skip-if parses the list of CONDITIONS supplied to it. The combination '(nottodo todo) is a valid condition, matching todo items whose state isn't a todo-type keyword (according to the keyword types defined in `org-todo-keywords'). But `org-agenda-skip-if' tests first for conditions of the form '(todo x) using (memq 'todo conditions), which mistakenly picks up '(nottodo todo) as well. Simply reversing the order of the memq tests for 'todo and 'nottodo fixes this particular case, which is what the attached patch does. Note that there's still a slightly different issue with combinations of multiple todo tests, which this patch does not fix. The docstring suggests that CONDITIONS is allowed to be a list of multiple tests. E.g. '(nottodo CANCELLED todo done) should match any done state except CANCELLED. But, faced with this combination, `organ-agenda-skip-if' will only apply the first '(nottodo CANCELLED) test, and ignores the second. However, it's not clear to me whether this is a problem with the code or the docstring. Perhaps it was never intended to support combinations of multiple todo tests. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 3eb5cd877ca48a2c0d2e907cf4ab7adf32520020 Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Sat, 28 Jan 2012 18:21:52 +0100 Subject: [PATCH 1/2] Agenda: Fix bug that broke '(nottodo todo) skip condition * lisp/org-agenda.el (org-agenda-skip-if): Fix bug in test for '(nottodo todo) skip condition. Note: certain combinations of multiple conditions may still be broken. --- lisp/org-agenda.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 38fd589..ad706eb 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4285,8 +4285,8 @@ that can be put into `org-agenda-skip-function' for the duration of a command. (stringp (nth 1 m)) (not (re-search-forward (nth 1 m) end t))) (and (or - (setq m (memq 'todo conditions)) - (setq m (memq 'nottodo conditions))) + (setq m (memq 'nottodo conditions)) + (setq m (memq 'todo conditions))) (org-agenda-skip-if-todo m end))) end))) -- 1.7.3.4
[O] [PATCH] Add new '[not]todo-unblocked tests to org-agenda-skip-if
This patch adds two new tests to `org-agenda-skip-if': 'todo-unblocked and 'nottodo-unblocked. These match like 'todo and 'nottodo, but only on unblocked todo items. This type of test is useful when compiling custom agenda views containing lists of currently actionable todo items. Whilst it's possible to code such tests in `org-agenda-custom-commands' directly (well, Elisp is Turing-complete: you can in principle code anything!), it's far less convenient than a simple `org-agenda-skip-if' test which can reuse much of the existing machinery. Note that the attached patch applies on top of my other Fix org-agenda-skip-if bug patch, though this new feature is independent of that bug-fix. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From 4e52c8c724f57c981206db18c95f9fe285af Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Sat, 28 Jan 2012 18:26:21 +0100 Subject: [PATCH 2/2] Agenda: Add new todo-unblocked and nottodo-unblocked skip conditions * lisp/org-agenda.el (org-agenda-skip-if, org-agenda-skip-if-todo): Add new todo-unblocked and nottodo-unblocked skip conditions. These match as for todo and nottodo, but only for unblocked todo items. --- lisp/org-agenda.el | 26 -- 1 files changed, 20 insertions(+), 6 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index ad706eb..d411732 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4286,15 +4286,18 @@ that can be put into `org-agenda-skip-function' for the duration of a command. (not (re-search-forward (nth 1 m) end t))) (and (or (setq m (memq 'nottodo conditions)) + (setq m (memq 'todo-unblocked conditions)) + (setq m (memq 'nottodo-unblocked conditions)) (setq m (memq 'todo conditions))) (org-agenda-skip-if-todo m end))) end))) (defun org-agenda-skip-if-todo (args end) Helper function for `org-agenda-skip-if', do not use it directly. -ARGS is a list with first element either `todo' or `nottodo'. -The remainder is either a list of TODO keywords, or a state symbol -`todo' or `done' or `any'. +ARGS is a list with first element either `todo', `nottodo', +`todo-unblocked' or `nottodo-unblocked'. The remainder is either +a list of TODO keywords, or a state symbol `todo' or `done' or +`any'. (let ((kw (car args)) (arg (cadr args)) todo-wds todo-re) @@ -4318,9 +4321,20 @@ The remainder is either a list of TODO keywords, or a state symbol (concat ^\\*+[ \t]+( (mapconcat 'identity todo-wds \\|) \\)\\)) -(if (eq kw 'todo) - (re-search-forward todo-re end t) - (not (re-search-forward todo-re end t) +(cond + ((eq kw 'todo) (re-search-forward todo-re end t)) + ((eq kw 'nottodo) (not (re-search-forward todo-re end t))) + ((eq kw 'todo-unblocked) + (catch 'unblocked + (while (re-search-forward todo-re end t) + (or (org-entry-blocked-p) (throw 'unblocked t))) + nil)) + ((eq kw 'nottodo-unblocked) + (catch 'unblocked + (while (re-search-forward todo-re end t) + (or (org-entry-blocked-p) (throw 'unblocked nil))) + t)) + ))) ;;;###autoload (defun org-agenda-list-stuck-projects (rest ignore) -- 1.7.3.4
Re: [O] [PATCH] org-goto before headline
On Fri, Feb 10, 2012 at 02:19:27PM +, Andrea Crotti wrote: What is exactly the reason for org-goto to need to be at least in the first headline to work? I always get this error when I just try to jump in the first line: byte-code: Before first headline at position 1 in buffer .. Do you by any chance have `org-goto-interface' set to outline-path-completion (or are you using org-goto with a prefix argument)? If so, I've also come across this problem. I think it's a bug in org-goto, which should pass NO-EXCLUDE to org-refile-get-location (but doesn't). The attached patch fixes this for me (or you can pull the org-goto branch from http://www.dr-qubit.org/git/org-mode.git). HTH, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org From f0cfaa5cb13996ba7a24bffa998e1c2a327d95be Mon Sep 17 00:00:00 2001 From: Toby S. Cubitt ts...@cantab.net Date: Wed, 8 Feb 2012 10:21:13 +0100 Subject: [PATCH] Fix bug in org-goto `outline-path-completion' interface * lisp/org.el (org-goto): call org-refile-get-location with NO-EXCLUDE argument set, otherwise not only are headlines in the current subtree excluded, but it throws an error if point happens not to be within a subtree (e.g. at start of buffer). --- lisp/org.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 882a41c..7030847 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6812,7 +6812,7 @@ hierarchy above. (selected-point (if (eq interface 'outline) (car (org-get-location (current-buffer) org-goto-help)) - (let ((pa (org-refile-get-location Goto))) + (let ((pa (org-refile-get-location Goto nil nil t))) (org-refile-check-position pa) (nth 3 pa) (if selected-point -- 1.7.3.4 signature.asc Description: Digital signature
[O] Various org-mode patches
I finally found time to gather various local patches to org-mode together
in a public clone of the org-mode git repo, at:
http://www.dr-qubit.org/git/org-mode.git
Each unrelated set of changes is in a separate branch, rebased onto a
recent checkout of org master. (All of the branches also merge cleanly
with each other.)
Let me know if you'd prefer me to generate patches for patchwork, and
send them to the list for consideration that way.
Here's a brief description of the changes in each branch (fuller details
are in the Changelog-style commit messages):
agenda-diary-sexp-prefix:
Add org-agenda-diary-sexp-prefix customization option, used to match
deadline/scheduling information within a diary sexp entry for display in
an agenda view.
agenda-prefix-format:
Optionally allow org-agenda-prefix-format to be a raw lisp sexp, to be
used directly in org-prefix-format-compiled.
agenda-skip-if:
Fix bug in '(nottodo todo) skip condition combination, and add new
todo-unblocked and nottodo-unblocked skip conditions which match like
todo and nottodo, but only on unblocked todo entries (2 separate
commits).
agenda-skip-timestamp-if-deadline:
Add org-agenda-skip-timestamp-if-deadline-is-shown customization option,
analogous to org-agenda-skip-scheduled-if-deadline-is-shown.
capture-empty-lines:
Fix bug in placement of captured subtree entries, and add
:empty-lines-before and :empty-lines-after capture template properties,
and (2 separate commits).
capture-escapes:
Add %num escapes to org capture templates, which expand to the text
entered for the num'th %^{PROMPT} escape.
daily-todo:
Implement daily todo list functionality.
toby
--
Dr T. S. Cubitt
email: ts...@cantab.net
web: www.dr-qubit.org
