Re: [O] Bug: horizontal lines in tables [8.2.10 (release_8.2.10 @ /usr/local/share/emacs/24.5/lisp/org/)]

[Nicolas Goaziou]

Guido Kraemer  writes:

> If you do |- TAB and the table does not have to be realigned, then the
> horizontal line will not show up until the next time the table has to
> be realigned.

Could you show an example?

Regards,

Re: [O] prompt for deadline in capture template?

[Christian Moe]

Matt Lundin writes:

>> Xebar Saram writes:
>>
>>> Hi guys
>>>
>>> i looked in the capture docu but couldn't seem to find it. anyone knows how
>>> to prompt for deadline in capture template?
>
> If you want to do it more pragmatically, you could use something like
> this (adjust the template as needed).
>
> (add-to-list 'org-capture-templates
>  '("d" "Deadline" entry
>(file "~/org/inbox.org")
>"* %^{Headline}\n DEADLINE: %^t"))
>
> See (info "(org) Template expansion")

My template for work projects includes this fragment:

"* TODO %^{Title} %^g\n SCHEDULED: %^{Scheduled to begin}t DEADLINE:
%^{Deadline}T\n [...]"

Note the t's after the prompts, asking specifically for the date (t) to
start work and and date + time (T) for the deadline.

Yours,
Christian

Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[Nicolas Goaziou]

Hello,

Puneeth Chaganti  writes:

> Here is a patch that works for the case you describe.

Thank you. Some comments follow.

> +  (org-id-show id 'org-pop-to-buffer-same-window))

  (org-id-show id #'org-pop-to-buffer-same-window)

> +(defun org-id-show (id cmd)
> +  "Show an entry with id ID by buffer-switching using CMD."

You should explain what is CMD. If it is a function, you should spell
out its signature.

> +  (let ((m (org-id-find id 'marker)))
> +(unless m
> +  (error "Cannot find entry with ID \"%s\"" id))
> +(if (not (equal (current-buffer) (marker-buffer m)))
> + (funcall cmd (marker-buffer m)))

(unless (eq (current-buffer) (marker-buffer m))
 ...)
 
> +(when (and (org-buffer-narrowed-p)
> +(let ((pos (marker-position m)))
> +  (or (< pos (point-min))
> +  (> pos (point-max)
> +  (widen))

`org-buffer-narrowed-p' is not useful here since you check boundaries
right after its call.

  (when (let ((pos (marker-position m)))
  (or (< pos (point-min))
  (> pos (point-max
(widen))

> +(goto-char m)
> +(move-marker m nil)
> +(org-show-context)))

I think this should be (org-show-context 'link-search) according to
`org-show-context-detail'.

>  ;; id link type
>  
>  ;; Calling the following function is hard-coded into `org-store-link',
> @@ -659,25 +669,15 @@ optional argument MARKERP, return the position as a new 
> marker."
>  (defun org-id-open (id)
>"Go to the entry with id ID."
>(org-mark-ring-push)
> -  (let ((m (org-id-find id 'marker))
> - cmd)
> -(unless m
> -  (error "Cannot find entry with ID \"%s\"" id))
> -;; Use a buffer-switching command in analogy to finding files
> -(setq cmd
> -   (or
> -(cdr
> - (assq
> -  (cdr (assq 'file org-link-frame-setup))
> -  '((find-file . switch-to-buffer)
> -(find-file-other-window . switch-to-buffer-other-window)
> -(find-file-other-frame . switch-to-buffer-other-frame
> -'switch-to-buffer-other-window))
> -(if (not (equal (current-buffer) (marker-buffer m)))
> - (funcall cmd (marker-buffer m)))
> -(goto-char m)
> -(move-marker m nil)
> -(org-show-context)))
> +  (let ((cmd (or
> +   (cdr
> +(assq
> + (cdr (assq 'file org-link-frame-setup))
> + '((find-file . switch-to-buffer)
> +   (find-file-other-window . switch-to-buffer-other-window)
> +   (find-file-other-frame . switch-to-buffer-other-frame
> +   'switch-to-buffer-other-window)))

  #'switch-to-buffer-other-window

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Fix `org-capture-templates' type declaration

[Nicolas Goaziou]

Hello,

Grégoire Jadi  writes:

> The attached patch fix the type declaration of org-capture-templates by
> allowing the user to use file, variable, function and sexp as target's
> file to match the documentation

Thank you.

> - (file :tag "  File"))
> + (choice :tag "  File"
> + file variable function sexp))

Shouldn't there be an entry for each type instead of stuffing everything
within "File" descriptor ?


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[Puneeth Chaganti]

Hi Nicolas,

On Sun, Oct 25, 2015 at 2:08 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Puneeth Chaganti  writes:
>
>> Here is a patch that works for the case you describe.
>
> Thank you. Some comments follow.

Thanks for your careful review and detailed comments.  I've attached
an updated patch.

-- Puneeth
From 5f0746566cc63c37634b20070a50601c5bb990ab Mon Sep 17 00:00:00 2001
From: Puneeth Chaganti 
Date: Sun, 25 Oct 2015 14:36:16 +0530
Subject: [PATCH] Widen if target id location is not in the narrow.

If the target location for `org-id-goto' or `org-id-open' is in a
narrowed buffer but not in the narrowed region, the buffer is widened.
---
 lisp/org-id.el | 54 --
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index f86ef22..0e8ba75 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -292,13 +292,7 @@ It returns the ID of the entry.  If necessary, the ID is created."
   "Switch to the buffer containing the entry with id ID.
 Move the cursor to that entry in that buffer."
   (interactive "sID: ")
-  (let ((m (org-id-find id 'marker)))
-(unless m
-  (error "Cannot find entry with ID \"%s\"" id))
-(org-pop-to-buffer-same-window (marker-buffer m))
-(goto-char m)
-(move-marker m nil)
-(org-show-context)))
+  (org-id-show id #'org-pop-to-buffer-same-window))
 
 ;;;###autoload
 (defun org-id-find (id  markerp)
@@ -634,6 +628,24 @@ optional argument MARKERP, return the position as a new marker."
 		(move-marker (make-marker) pos buf)
 	  (cons file pos
 
+(defun org-id-show (id cmd)
+  "Show an entry with id ID by buffer-switching using CMD.
+CMD is a function that takes a buffer or a string (buffer name)
+as an argument, which will be used to switch to the buffer
+containing the entry with id ID."
+  (let ((m (org-id-find id 'marker)))
+(unless m
+  (error "Cannot find entry with ID \"%s\"" id))
+(unless (equal (current-buffer) (marker-buffer m))
+  (funcall cmd (marker-buffer m)))
+(when (let ((pos (marker-position m)))
+	(or (< pos (point-min))
+		(> pos (point-max
+  (widen))
+(goto-char m)
+(move-marker m nil)
+(org-show-context 'link-search)))
+
 ;; id link type
 
 ;; Calling the following function is hard-coded into `org-store-link',
@@ -659,25 +671,15 @@ optional argument MARKERP, return the position as a new marker."
 (defun org-id-open (id)
   "Go to the entry with id ID."
   (org-mark-ring-push)
-  (let ((m (org-id-find id 'marker))
-	cmd)
-(unless m
-  (error "Cannot find entry with ID \"%s\"" id))
-;; Use a buffer-switching command in analogy to finding files
-(setq cmd
-	  (or
-	   (cdr
-	(assq
-	 (cdr (assq 'file org-link-frame-setup))
-	 '((find-file . switch-to-buffer)
-	   (find-file-other-window . switch-to-buffer-other-window)
-	   (find-file-other-frame . switch-to-buffer-other-frame
-	   'switch-to-buffer-other-window))
-(if (not (equal (current-buffer) (marker-buffer m)))
-	(funcall cmd (marker-buffer m)))
-(goto-char m)
-(move-marker m nil)
-(org-show-context)))
+  (let ((cmd (or
+	  (cdr
+	   (assq
+		(cdr (assq 'file org-link-frame-setup))
+		'((find-file . switch-to-buffer)
+		  (find-file-other-window . switch-to-buffer-other-window)
+		  (find-file-other-frame . switch-to-buffer-other-frame
+	  #'switch-to-buffer-other-window)))
+(org-id-show id cmd)))
 
 (org-add-link-type "id" 'org-id-open)
 
-- 
2.5.0

[O] [PATCH] make org-clock-time% respect org-effort-durations and related

[Jan Malakhovski]

Hi.

The first patch here is a must, because it fixes a bug I stumble upoon
daily. Middle two are just to make the names consistent. While doing
all those changes I read quite a lot of code and the last patch adds a
FIXME for a particularly ugly place I'm not sure how to fix (I think
don't ever consciously use that code path and I'm not sure what it
supposed to do).

Cheers,
  Jan

Jan Malakhovski (4):
  org-clock: make org-clock-time% respect org-effort-durations
  org: move org-duration-string-to-minutes to a better place
  rename org-duration-string-to-minutes to org-clocksum-string-to-minutes 
everywhere
  org-colview: add a FIXME

 contrib/lisp/org-depend.el |  2 +-
 contrib/lisp/ox-taskjuggler.el |  2 +-
 lisp/org-agenda.el |  2 +-
 lisp/org-clock.el  | 39 +--
 lisp/org-colview.el|  5 +++-
 lisp/org.el| 52 +++---
 6 files changed, 51 insertions(+), 51 deletions(-)

-- 
2.5.3

[O] [PATCH 3/4] rename org-duration-string-to-minutes to org-clocksum-string-to-minutes everywhere

[Jan Malakhovski]

---
 contrib/lisp/org-depend.el |  2 +-
 contrib/lisp/ox-taskjuggler.el |  2 +-
 lisp/org-agenda.el |  2 +-
 lisp/org-clock.el  | 14 +++---
 lisp/org-colview.el|  2 +-
 lisp/org.el| 14 +-
 6 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/contrib/lisp/org-depend.el b/contrib/lisp/org-depend.el
index 1cd4130..7b263bc 100644
--- a/contrib/lisp/org-depend.el
+++ b/contrib/lisp/org-depend.el
@@ -270,7 +270,7 @@ This does two different kinds of triggers:
(effort (when (or effort-up effort-down)
  (let ((effort (get-text-property (point) 
'org-effort)))
(when effort
- (org-duration-string-to-minutes 
effort))
+ (org-clocksum-string-to-minutes 
effort))
(push (list (point) todo-kwd priority tags effort)
  items))
  (unless (org-goto-sibling)
diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index 2bd47e6..b425b1b 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -861,7 +861,7 @@ a unique id will be associated to it."
  (and complete (format "  complete %s\n" complete))
  (and effort
   (format "  effort %s\n"
-  (let* ((minutes (org-duration-string-to-minutes effort))
+  (let* ((minutes (org-clocksum-string-to-minutes effort))
  (hours (/ minutes 60.0)))
 (format "%.1fh" hours
  (and priority (format "  priority %s\n" priority))
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e7a3776..bdb69c5 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7655,7 +7655,7 @@ E looks like \"+<2:25\"."
   ((equal op ??) op)
   (t '=)))
 (list 'org-agenda-compare-effort (list 'quote op)
- (org-duration-string-to-minutes e
+ (org-clocksum-string-to-minutes e
 
 (defun org-agenda-compare-effort (op value)
   "Compare the effort of the current line with VALUE, using OP.
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 6cbd132..2f254e1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -668,7 +668,7 @@ If not, show simply the clocked time like 01:50."
   (let ((clocked-time (org-clock-get-clocked-time)))
 (if org-clock-effort
(let* ((effort-in-minutes
-   (org-duration-string-to-minutes org-clock-effort))
+   (org-clocksum-string-to-minutes org-clock-effort))
   (work-done-str
(org-propertize
 (org-minutes-to-clocksum-string clocked-time)
@@ -749,10 +749,10 @@ clocked item, and the value displayed in the mode line."
  ;; A string.  See if it is a delta
  (setq sign (string-to-char value))
  (if (member sign '(?- ?+))
- (setq current (org-duration-string-to-minutes current)
+ (setq current (org-clocksum-string-to-minutes current)
value (substring value 1))
(setq current 0))
- (setq value (org-duration-string-to-minutes value))
+ (setq value (org-clocksum-string-to-minutes value))
  (if (equal ?- sign)
  (setq value (- current value))
(if (equal ?+ sign) (setq value (+ current value)
@@ -770,7 +770,7 @@ clocked item, and the value displayed in the mode line."
   "Show notification if we spent more time than we estimated before.
 Notification is shown only once."
   (when (org-clocking-p)
-(let ((effort-in-minutes (org-duration-string-to-minutes org-clock-effort))
+(let ((effort-in-minutes (org-clocksum-string-to-minutes org-clock-effort))
  (clocked-time (org-clock-get-clocked-time)))
   (if (setq org-clock-task-overrun
(if (or (null effort-in-minutes) (zerop effort-in-minutes))
@@ -1193,7 +1193,7 @@ make this the default behavior.)"
   (setq org-clock-notification-was-shown nil)
   (org-refresh-properties
org-effort-property '((effort . identity)
-(effort-minutes . org-duration-string-to-minutes)))
+(effort-minutes . org-clocksum-string-to-minutes)))
   (catch 'abort
 (let ((interrupting (and (not org-clock-resolving-clocks-due-to-idleness)
 (org-clocking-p)))
@@ -2869,13 +2869,13 @@ TIME:  The sum of all time spend in this tree, in 
minutes.  This time
   "Compute a time fraction in percent.
 TOTAL s a total time string.
 STRINGS is a list of strings that should be checked for a time.
-Strings are parsed using `org-duration-string-to-minutes`.
+Strings are parsed using `org-clocksum-string-to-minutes`.
 The first string that does have a time will be used. This
 function is made for clock tables."
   

Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[Nicolas Goaziou]

Puneeth Chaganti  writes:

> Thanks for your careful review and detailed comments.  I've attached
> an updated patch.

Thank you. I have another suggestion about it.

> +(defun org-id-show (id cmd)
> +  "Show an entry with id ID by buffer-switching using CMD.
> +CMD is a function that takes a buffer or a string (buffer name)
> +as an argument, which will be used to switch to the buffer
> +containing the entry with id ID."
> +  (let ((m (org-id-find id 'marker)))
> +(unless m
> +  (error "Cannot find entry with ID \"%s\"" id))
> +(unless (equal (current-buffer) (marker-buffer m))
> +  (funcall cmd (marker-buffer m)))

Nitpick: (eq (current-buffer) (marker-buffer m))
  
> +(when (let ((pos (marker-position m)))
> + (or (< pos (point-min))
> + (> pos (point-max
> +  (widen))
> +(goto-char m)
> +(move-marker m nil)
> +(org-show-context 'link-search)))

If CMD raises an error, you have a dangling marker in the buffer, which
is not a great idea. I suggest to wrap everything into
a `unwind-protect' and add (set-marker m nil) as an unwindform, i.e.,

  (let ((m (org-id-find id 'marker)))
(unless m (error "Cannot find entry with ID \"%s\"" id))
(unwind-protect
(progn
  (unless (eq (current-buffer) (marker-buffer m))
(funcall cmd (marker-buffer m)))
  (when (let ((pos (marker-position m)))
  (or (< pos (point-min))
  (> pos (point-max
(widen))
  (goto-char m)
  (org-show-context 'link-search))
  (set-marker m nil)))

Regards,

Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[Puneeth Chaganti]

> If CMD raises an error, you have a dangling marker in the buffer, which
> is not a great idea. I suggest to wrap everything into
> a `unwind-protect' and add (set-marker m nil) as an unwindform, i.e.,

Fixed. Thanks!
From 8ec4f777a2e1078e1fadc48a7c91366200a0d37b Mon Sep 17 00:00:00 2001
From: Puneeth Chaganti 
Date: Sun, 25 Oct 2015 14:36:16 +0530
Subject: [PATCH] Widen if target id location is not in the narrow.

If the target location for `org-id-goto' or `org-id-open' is in a
narrowed buffer but not in the narrowed region, the buffer is widened.
---
 lisp/org-id.el | 55 +--
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index f86ef22..73e8f54 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -292,13 +292,7 @@ It returns the ID of the entry.  If necessary, the ID is created."
   "Switch to the buffer containing the entry with id ID.
 Move the cursor to that entry in that buffer."
   (interactive "sID: ")
-  (let ((m (org-id-find id 'marker)))
-(unless m
-  (error "Cannot find entry with ID \"%s\"" id))
-(org-pop-to-buffer-same-window (marker-buffer m))
-(goto-char m)
-(move-marker m nil)
-(org-show-context)))
+  (org-id-show id #'org-pop-to-buffer-same-window))
 
 ;;;###autoload
 (defun org-id-find (id  markerp)
@@ -634,6 +628,25 @@ optional argument MARKERP, return the position as a new marker."
 		(move-marker (make-marker) pos buf)
 	  (cons file pos
 
+(defun org-id-show (id cmd)
+  "Show an entry with id ID by buffer-switching using CMD.
+CMD is a function that takes a buffer or a string (buffer name)
+as an argument, which will be used to switch to the buffer
+containing the entry with id ID."
+  (let ((m (org-id-find id 'marker)))
+(unless m (error "Cannot find entry with ID \"%s\"" id))
+(unwind-protect
+(progn
+  (unless (eq (current-buffer) (marker-buffer m))
+(funcall cmd (marker-buffer m)))
+  (when (let ((pos (marker-position m)))
+  (or (< pos (point-min))
+  (> pos (point-max
+(widen))
+  (goto-char m)
+  (org-show-context 'link-search))
+  (set-marker m nil
+
 ;; id link type
 
 ;; Calling the following function is hard-coded into `org-store-link',
@@ -659,25 +672,15 @@ optional argument MARKERP, return the position as a new marker."
 (defun org-id-open (id)
   "Go to the entry with id ID."
   (org-mark-ring-push)
-  (let ((m (org-id-find id 'marker))
-	cmd)
-(unless m
-  (error "Cannot find entry with ID \"%s\"" id))
-;; Use a buffer-switching command in analogy to finding files
-(setq cmd
-	  (or
-	   (cdr
-	(assq
-	 (cdr (assq 'file org-link-frame-setup))
-	 '((find-file . switch-to-buffer)
-	   (find-file-other-window . switch-to-buffer-other-window)
-	   (find-file-other-frame . switch-to-buffer-other-frame
-	   'switch-to-buffer-other-window))
-(if (not (equal (current-buffer) (marker-buffer m)))
-	(funcall cmd (marker-buffer m)))
-(goto-char m)
-(move-marker m nil)
-(org-show-context)))
+  (let ((cmd (or
+	  (cdr
+	   (assq
+		(cdr (assq 'file org-link-frame-setup))
+		'((find-file . switch-to-buffer)
+		  (find-file-other-window . switch-to-buffer-other-window)
+		  (find-file-other-frame . switch-to-buffer-other-frame
+	  #'switch-to-buffer-other-window)))
+(org-id-show id cmd)))
 
 (org-add-link-type "id" 'org-id-open)
 
-- 
2.5.0

[O] [PATCH 2/2] org-notmuch: add date support to org-notmuch-store-link

[Jan Malakhovski]

---
 contrib/lisp/org-notmuch.el | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/contrib/lisp/org-notmuch.el b/contrib/lisp/org-notmuch.el
index 712ec5a..265742e 100644
--- a/contrib/lisp/org-notmuch.el
+++ b/contrib/lisp/org-notmuch.el
@@ -71,15 +71,16 @@ Should accept a notmuch search string as the sole argument."
 (defun org-notmuch-store-link ()
   "Store a link to a notmuch search or message."
   (when (eq major-mode 'notmuch-show-mode)
-(let* ((message-id (notmuch-show-get-prop :id))
+(let* ((message-id (notmuch-show-get-message-id t))
   (subject (notmuch-show-get-subject))
   (to (notmuch-show-get-to))
   (from (notmuch-show-get-from))
+  (date (org-trim (notmuch-show-get-date)))
   desc link)
-  (org-store-link-props :type "notmuch" :from from :to to
+  (org-store-link-props :type "notmuch" :from from :to to :date date
:subject subject :message-id message-id)
   (setq desc (org-email-link-description))
-  (setq link (concat "notmuch:"  "id:" message-id))
+  (setq link (concat "notmuch:id:" message-id))
   (org-add-link-props :link link :description desc)
   link)))
 
-- 
2.5.3

[O] [PATCH 1/2] factor out date-timestamp* calculations to org-store-link-props

[Jan Malakhovski]

---
 contrib/lisp/org-mew.el | 11 +--
 contrib/lisp/org-vm.el  | 11 +--
 contrib/lisp/org-wl.el  | 10 +-
 doc/org.texi|  4 ++--
 lisp/org-gnus.el| 15 +--
 lisp/org-mhe.el | 10 +-
 lisp/org-rmail.el   | 11 +--
 lisp/org.el | 15 +--
 8 files changed, 21 insertions(+), 66 deletions(-)

diff --git a/contrib/lisp/org-mew.el b/contrib/lisp/org-mew.el
index eb0afc0..35fdd8b 100644
--- a/contrib/lisp/org-mew.el
+++ b/contrib/lisp/org-mew.el
@@ -167,19 +167,10 @@ with \"t\" key."
   (from (mew-header-get-value "From:"))
   (to (mew-header-get-value "To:"))
   (date (mew-header-get-value "Date:"))
-  (date-ts (and date (format-time-string
-  (org-time-stamp-format t)
-  (date-to-time date
-  (date-ts-ia (and date (format-time-string
- (org-time-stamp-format t t)
- (date-to-time date
   (subject (mew-header-get-value "Subject:"))
   desc link)
- (org-store-link-props :type "mew" :from from :to to
+ (org-store-link-props :type "mew" :from from :to to :date date
:subject subject :message-id message-id)
- (when date
-   (org-add-link-props :date date :date-timestamp date-ts
-   :date-timestamp-inactive date-ts-ia))
  (setq message-id (org-remove-angle-brackets message-id))
  (setq desc (org-email-link-description))
  (setq link (concat "mew:" folder-name "#" message-id))
diff --git a/contrib/lisp/org-vm.el b/contrib/lisp/org-vm.el
index 5d30f64..da242cb 100644
--- a/contrib/lisp/org-vm.el
+++ b/contrib/lisp/org-vm.el
@@ -77,12 +77,6 @@
  (message-id (vm-su-message-id message))
  (link-type (if (vm-imap-folder-p) "vm-imap" "vm"))
 (date (vm-get-header-contents message "Date"))
-(date-ts (and date (format-time-string
-(org-time-stamp-format t)
-(date-to-time date
-(date-ts-ia (and date (format-time-string
-   (org-time-stamp-format t t)
-   (date-to-time date
 folder desc link)
 (if (vm-imap-folder-p)
(let ((spec (vm-imap-find-spec-for-buffer (current-buffer
@@ -95,10 +89,7 @@
 (setq folder (replace-match "" t t folder)
 (setq message-id (org-remove-angle-brackets message-id))
(org-store-link-props :type link-type :from from :to to :subject subject
- :message-id message-id)
-   (when date
- (org-add-link-props :date date :date-timestamp date-ts
- :date-timestamp-inactive date-ts-ia))
+ :message-id message-id :date date)
(setq desc (org-email-link-description))
(setq link (concat (concat link-type ":") folder "#" message-id))
(org-add-link-props :link link :description desc)
diff --git a/contrib/lisp/org-wl.el b/contrib/lisp/org-wl.el
index 632c9e3..2cc333c 100644
--- a/contrib/lisp/org-wl.el
+++ b/contrib/lisp/org-wl.el
@@ -198,12 +198,6 @@ ENTITY is a message entity."
 (xref (org-wl-message-field 'xref wl-message-entity))
 (subject (org-wl-message-field 'subject wl-message-entity))
 (date (org-wl-message-field 'date wl-message-entity))
-(date-ts (and date (format-time-string
-(org-time-stamp-format t)
-(date-to-time date
-(date-ts-ia (and date (format-time-string
-   (org-time-stamp-format t t)
-   (date-to-time date
 desc link)
 
;; remove text properties of subject string to avoid possible bug
@@ -243,9 +237,7 @@ ENTITY is a message entity."
  (setq desc (org-email-link-description))
  (setq link (concat "wl:" folder-name "#" message-id-no-brackets))
  (org-add-link-props :link link :description desc)))
-   (when date
- (org-add-link-props :date date :date-timestamp date-ts
- :date-timestamp-inactive date-ts-ia))
+   (org-add-link-props :date date)
(or link xref)))
 
 (defun org-wl-open-nntp (path)
diff --git a/doc/org.texi b/doc/org.texi
index c1fe56e..30cc0e4 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7314,8 +7314,8 @@ Link type|  Available keywords
 
-+--
 bbdb |  %:name %:company
 irc   

[O] [PATCH] remove some copy-paste and add date support to org-notmuch-store-link

[Jan Malakhovski]

Cheers,
  Jan

Jan Malakhovski (2):
  factor out date-timestamp* calculations to org-store-link-props
  org-notmuch: add date support to org-notmuch-store-link

 contrib/lisp/org-mew.el | 11 +--
 contrib/lisp/org-notmuch.el |  7 ---
 contrib/lisp/org-vm.el  | 11 +--
 contrib/lisp/org-wl.el  | 10 +-
 doc/org.texi|  4 ++--
 lisp/org-gnus.el| 15 +--
 lisp/org-mhe.el | 10 +-
 lisp/org-rmail.el   | 11 +--
 lisp/org.el | 15 +--
 9 files changed, 25 insertions(+), 69 deletions(-)

-- 
2.5.3

Re: [O] Macro question

[Fabrice Popineau]

2015-10-24 19:02 GMT+02:00 Eric S Fraga :

> On Saturday, 24 Oct 2015 at 13:37, Fabrice Popineau wrote:
>
> [...]
>
> > I find that using headers as in beamer is not pleasant (maybe that is
> just
> > me ?)
>
> Just to help you understand the positive aspect of headlines for
> structure in beamer, the use of headlines makes it incredibly easy to
> switch columns around, for instance, or to copy/move them from slide to
> slide.
>

You are right. This needs to be put forward.
In this case, the parameter that has to be made easily editable
is the width of the column. (Thinking about a common interface for
beamer and reveal)


> With respect to the HTML issue, what if you do not put blank lines
> between the different bits?  The blank lines are defining paragraphs, as
> far as I understand it.
>
>
It is possible to hack the reveal/html exporter.
Knowing that

{{{bFoo}}}
...
{{{eFoo}}}

gets exported to









The macros could be defined:
#+macro: bFoo @@html:@@
#+macro: eFoo @@html:@@

and this way you get spurious paragraphs, but valid html
However, I'm not sure I want to follow this path !

Best regards,

Fabrice

Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[John Kitchin]

In my solution I do store the buffer. Maybe for some reason the id is in
another buffer with narrowing, and you want to preserve that narrowing
when you return. I originally did that with a marker, so you could
restore point to, but I decided to take that out. I wasn't aware you
could have dangling markers! I guess you would want to use more global
variables, so there would only be two. and hopefully you don't follow
multiple id links through narrowed buffers in a row!


Rasmus writes:

> John Kitchin  writes:
>
>> I like the idea too. I worked out a partial solution for id links here:
>> http://kitchingroup.cheme.cmu.edu/blog/2015/10/24/Saving-the-current-restriction-and-restoring-it-while-following-links/
>> using the idea for saving and restoring the restriction.
>
> Thanks, John.
>
> You will probably want to use markers since one might edit stuff
> in-between the widening and going back to the narrow.
>
>  
> http://www.gnu.org/software/emacs/manual/html_node/elisp/Overview-of-Markers.html#Overview-of-Markers
>
> Markers should be cleaned up, which might prove difficult since one might
> not go back with C-c &, but you can at least ensure that at most two loose
> markers exists (potentially per Org buffer).
>
> Also, I wonder if there exits cases where you would need to store the
> buffer as well as the narrow points...  I guess not?
>
> Thanks,
> Rasmus

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] [PATCH] org-id-goto doesn't work if buffer is narrowed.

[Rasmus]

Hi Puneeth,

Puneeth Chaganti  writes:

>> However, you need to make sure that it only widens if ID is in the same
>> buffer and outside of the narrow.  In particular, when ID is in another
>> file you shouldn’t widen.  When it’s within the scope of the narrow it
>> shouldn’t widen.  This ALREADY seems to be the case.
>
> I will fix the patch to widen only when the target location is not
> within the narrow. But, I don't understand why we shouldn't be
> widening if the target location is in a different buffer. Can you
> explain?

Reading your latest patch it seems to be correct.  I mean, if I click
[[id:myid]] in narrowed buffer A and myid is in buffer B, then you
shouldn’t widen in buffer A.  Since you switch buffer there’s no such
issue.

>> However, your patch doesn’t work for me in the following example, starting
>> from emacs -q, adding /tmp/test.org (with the below content) to my agenda
>> list and requiring org-id, org-narrow-to-subtree on foo, and then
>> org-open-at-point on the link
>
> I had patched `org-id-goto' and looks like clicking on links uses
> `org-id-open'.  I will resend a patch.  I wonder if these two
> functions can reuse common code.

The latest patch from

Date: Sun, 25 Oct 2015 14:36:16 +0530

looks good to me.  Thanks!

Rasmus

-- 
The second rule of Fight Club is: You do not talk about Fight Club

Re: [O] [PATCH] Fix `org-capture-templates' type declaration

[Grégoire Jadi]

Nicolas Goaziou writes:

> Hello,

Hi,

Thanks for the reply.

> Grégoire Jadi  writes:
>
>> The attached patch fix the type declaration of org-capture-templates by
>> allowing the user to use file, variable, function and sexp as target's
>> file to match the documentation
>
> Thank you.
>
>> -(file :tag "  File"))
>> +(choice :tag "  File"
>> +file variable function sexp))
>
> Shouldn't there be an entry for each type instead of stuffing everything
> within "File" descriptor ?

With my patch, the customization interface looks like this
- for a file :
Target location: Value Menu File:
  File: Value Menu File: ~/org/notes.org

- for a variable :
Target location: Value Menu File:
  File: Value Menu Variable: nil

- for a function :
Target location: Value Menu File:
  File: Value Menu Function: ignore

- for an Emacs Lisp form :
Target location: Value Menu File:
  File: Value Menu Lisp expression: nil

What kind of rendering do you think would be better/clearer?

Best,
> Regards,

-- 
Grégoire Jadi


signature.asc
Description: PGP signature

Re: [O] Org-mode reinvented?

[John Kitchin]

Interesting. One day I imagine something like this, or sharelatex exists
for collaborating on org-files with people who don't like Emacs...

Marcin Borkowski writes:

> Hi all,
>
> I've just stumbled over this: https://gingkoapp.com/ .  From a cursory
> glance it seems like a web-based, proprietary, simplified version of
> Org-mode for non-geeks.  Not that I'm inclined to try it out - I've got
> Org - but maybe someone would find it interesting/inspiring.
>
> Disclosure: I am not related to the author or the company who produces
> that app.  I'm just curious if anyone has seen this, and whether some
> features might be an inspiration for e.g. new Org-mode features/modules.
> For instance, they say in the "quick intro" that they have /templates/
> for common things, like writing screenplays.  That /might/ (or might
> not) be an interesting thing to implement in Org-mode.
>
> Best,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Macro question

[Eric S Fraga]

On Sunday, 25 Oct 2015 at 10:45, Fabrice Popineau wrote:

[...]

> In this case, the parameter that has to be made easily editable
> is the width of the column. (Thinking about a common interface for
> beamer and reveal)

Column mode is great for editing such things.  However, we would need
(as has been suggested elsewhere) a common set of properties that are
backend agnostic, such as COLUMN_WIDTH instead of BEAMER_col.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

[O] [PATCH 4/4] org-colview: add a FIXME

[Jan Malakhovski]

---
 lisp/org-colview.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 1113adc..4f09766 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -1113,6 +1113,9 @@ display, or in the #+COLUMNS line of the current buffer."
((memq fmt '(checkbox checkbox-n-of-m checkbox-percent))
 (if (equal s "[X]") 1. 0.01))
((memq fmt '(estimate)) (org-string-to-estimate s))
+   ;; FIXME: does this duplicate org-clocksum-string-to-minutes in a most 
peculiar way?
+   ;; I can guess that long time ago this used org-hh:mm-string-to-minutes
+   ;; and all this ugliness derives from that
((string-match (concat "\\([0-9.]+\\) *\\("
  (regexp-opt (mapcar 'car org-effort-durations))
  "\\)") s)
-- 
2.5.3

[O] [PATCH 2/4] org: move org-duration-string-to-minutes to a better place

[Jan Malakhovski]

---
 lisp/org.el | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 088913c..453ed37 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18329,6 +18329,26 @@ If no number is found, the return value is 0."
 (string-to-number (match-string 1 s)))
(t 0)))
 
+(defun org-duration-string-to-minutes (s  output-to-string)
+  "Convert a duration string S to minutes.
+
+A bare number is interpreted as minutes, modifiers can be set by
+customizing `org-effort-durations' (which see).
+
+Entries containing a colon are interpreted as H:MM by
+`org-hh:mm-string-to-minutes'."
+  (let ((result 0)
+   (re (concat "\\([0-9.]+\\) *\\("
+   (regexp-opt (mapcar 'car org-effort-durations))
+   "\\)")))
+(while (string-match re s)
+  (incf result (* (cdr (assoc (match-string 2 s) org-effort-durations))
+ (string-to-number (match-string 1 s
+  (setq s (replace-match "" nil t s)))
+(setq result (floor result))
+(incf result (org-hh:mm-string-to-minutes s))
+(if output-to-string (number-to-string result) result)))
+
 (defcustom org-image-actual-width t
   "Should we use the actual width of images when inlining them?
 
@@ -18387,26 +18407,6 @@ The value is a list, with zero or more of the symbols 
`effort', `appt',
   :package-version '(Org . "8.3")
   :group 'org-agenda)
 
-(defun org-duration-string-to-minutes (s  output-to-string)
-  "Convert a duration string S to minutes.
-
-A bare number is interpreted as minutes, modifiers can be set by
-customizing `org-effort-durations' (which see).
-
-Entries containing a colon are interpreted as H:MM by
-`org-hh:mm-string-to-minutes'."
-  (let ((result 0)
-   (re (concat "\\([0-9.]+\\) *\\("
-   (regexp-opt (mapcar 'car org-effort-durations))
-   "\\)")))
-(while (string-match re s)
-  (incf result (* (cdr (assoc (match-string 2 s) org-effort-durations))
- (string-to-number (match-string 1 s
-  (setq s (replace-match "" nil t s)))
-(setq result (floor result))
-(incf result (org-hh:mm-string-to-minutes s))
-(if output-to-string (number-to-string result) result)))
-
  Files
 
 (defun org-save-all-org-buffers ()
-- 
2.5.3

[O] [PATCH 1/4] org-clock: make org-clock-time% respect org-effort-durations

[Jan Malakhovski]

This also fixes a bug with time percents looking pretty much random and adding
to a number that is less than 100% when a clock report has long intervals
(e.g. days).
---
 lisp/org-clock.el | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 5d7c6b4..6cbd132 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2867,27 +2867,20 @@ TIME:  The sum of all time spend in this tree, in 
minutes.  This time
 
 (defun org-clock-time% (total  strings)
   "Compute a time fraction in percent.
-TOTAL s a time string like 10:21 specifying the total times.
+TOTAL s a total time string.
 STRINGS is a list of strings that should be checked for a time.
-The first string that does have a time will be used.
-This function is made for clock tables."
-  (let ((re "\\([0-9]+\\):\\([0-9]+\\)")
-   tot s)
-(save-match-data
+Strings are parsed using `org-duration-string-to-minutes`.
+The first string that does have a time will be used. This
+function is made for clock tables."
+  (save-match-data
+(let (tot s cur)
   (catch 'exit
-   (if (not (string-match re total))
-   (throw 'exit 0.)
- (setq tot (+ (string-to-number (match-string 2 total))
-  (* 60 (string-to-number (match-string 1 total)
- (if (= tot 0.) (throw 'exit 0.)))
+   (setq tot (org-duration-string-to-minutes total))
+   (if (= tot 0.) (throw 'exit 0.))
(while (setq s (pop strings))
- (if (string-match "\\([0-9]+\\):\\([0-9]+\\)" s)
- (throw 'exit
-(/ (* 100.0 (+ (string-to-number (match-string 2 s))
-   (* 60 (string-to-number
-  (match-string 1 s)
-   tot
-   0
+ (setq cur (org-clocksum-string-to-minutes s))
+ (if (not (equal cur nil)) (throw 'exit (/ (* 100.0 cur) tot
+   nil
 
 ;; Saving and loading the clock
 
-- 
2.5.3

[O] Some projects

[Nicolas Goaziou]

Hello,

I'd like to see some features moving forward, and some important issues
fixed, hopefully, in the next months. I'm sharing them here so that
anyone interested can help.


* Features

** Citations

Development apparently stopped for some reason. We have a citation
syntax for Org in wip-cite and some work done in wip-cite-awe and
probably elsewhere.

I think we could at least provide features defined in Org Ref using the
new syntax (minus hydra/helm related functions).

We don't need a silver bullet. Just something with a non-empty user
base, and extensible. In any case, the work done so far shouldn't be
wasted.

** Annotations

It would be nice to allow annotating text in Org. I already made
a proposal for that feature a few months ago, without much success.
Anyway, I'd like to implement it, in a simplified form. For the record,
the idea is to use some markup for beginning and end of an annotation,
e.g.,

  [@:id].[@]

and store text within a dedicated section,

  * Annotations

  [@:id] ...

Like footnotes, you could easily browse remotely annotations at point.
However, they would be, at least at the beginning, completely ignored
during export.

** Backslash escaping

Allowing to escape some symbols in plain text (e.g., emphasis markers,
square brackets...) would remove a limitation in verbatim/code objects.
As a small benefit, it would also permit to implement mid-word markup:
b*o*ld.

There are some gotchas, however.

* Important fixes

** Cache

The cache needs to be fixed. Its underlying implementation probably
needs to be changed, too. At the moment, it uses an AVL tree, which
isn't much tolerant and results in a freeze whenever the cache is
corrupted. Shifting to text properties could improve the situation.

Also, it needs to do better analysis in order to prevent those
corruptions. This is obviously the hardest part.

Again, an efficient cache can give us a better fontification mechanism,
since Org syntax is not regular.

** Link hexification

There are currently some subtle inconsistencies in link handling. See
for example `org-make-link-string'.

** Use lexical binding everywhere

This is the easiest part: add appropriate cookie at the beginning of the
file and fix resulting compiler warnings.

** Find a solution for orgstruct minor mode

Org struct is really different from Org. It prevents Org from using
better algorithms for outline navigation (see discussion about
`org-show-children' on this list).

I think Org struct should be removed from "org.el" (and org-footnote
...) and added in its own library. It should also be built on top of
Outline mode instead of Org mode. Org, OTOH, should remove dependencies
on Outline mode and implement better navigation functions.

I have the feeling that Org struct will need to be rewritten almost from
scratch in the process.


Here we are. I hope finding enough spare time (it also depends on the
quantity of bugs to fix...) to investigate most, if not all of these
issues. Of course, feedback is welcome.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] org-reveal questions

[Matt Price]

On Sun, Oct 25, 2015 at 4:46 PM, Eric S Fraga  wrote:

> Hello all,
>
> So, I decided I would play with org-reveal some more, just to see if I
> could get some of the functionality that Xebar wanted fairly
> easily.  It turns out that I could use a web based presentation for a
> small PR exercise...
>
> I've run into two stumbling blocks using org-reveal.
>
> First, the #+HTML: directive seems to be ignored although
> the #+BEGIN_HTML/#+END_HTML construct works.  This is only in reveal
> export, not HTML export.
>

could you file this as a bug report on github, and then post the URL? I'll
try to figure out the issue and fix it. I'm a slow coder and actually don't
use the #+HTML: directive, but have a ninterest in getting better.

>
> The second problem is more about HTML export than reveal
> specifically.  In LaTeX, an image is exported directly without any
> surrounding material if only the image is there.  Surrounding material,
> i.e. LaTeX figure environment, is only included if a caption is
> present.  In reveal, there doesn't seem to be an equivalent
> behaviour.  That is, all my images get exported within a figure
> .  I would like to have the option of a bare-bones  export
> without having to resort to direct HTML.  Is this possible?  It would
> seem to make sense to have the same type of logic apply to HTML export
> as it does to LaTeX?
>
> I doubt this is possible in reveal right now but it shouldn't be too hard
to add a (switch ) statement that exports a naked img if some condition is
met.  And I et a relevant patch could be submitted as a feature request.



> Thanks,
> eric
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33
>

Re: [O] Some projects

[Aaron Ecay]

Hi Nicolas,

Thanks for writing this up.  It is important to think about, and
ultimately solve, all the issues you raise.

2015ko urriak 25an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> I'd like to see some features moving forward, and some important issues
> fixed, hopefully, in the next months. I'm sharing them here so that
> anyone interested can help.
> 
> 
> * Features
> 
> ** Citations
> 
> Development apparently stopped for some reason. We have a citation
> syntax for Org in wip-cite and some work done in wip-cite-awe and
> probably elsewhere.
> 
> I think we could at least provide features defined in Org Ref using the
> new syntax (minus hydra/helm related functions).
> 
> We don't need a silver bullet. Just something with a non-empty user
> base, and extensible. In any case, the work done so far shouldn't be
> wasted.

I was working on this rather intensively at one time, but I had to stop
because other aspects of life intruded.  I have just been coming back
towards a situation where I can imagine myself having some (still small,
but non-zero) chunks of time to devote to working on org.  So I hope I
will be able to pick this back up, but (regrettably) I’m not able to
make any promises.

Based on my recollection, here’s what the problems were when I stopped:

- The only “off the shelf”-capable citation processing library that we
  found last time is in Haskell, which introduced some difficulties for
  distributing the resulting tool.  I know some projects
  (e.g. git-annex) are written in Haskell and distributed as static
  binaries for windows/mac/linux/etc.  We’d need to figure out how to do
  this, or find another citation processing library in an
  easier-to-distribute language.  (I should say, all the work on the
  external tool was done by Richard Lawrence; I worked on the exporter
  for the citation syntax including the interface with an external
  tool.)

- There is a difference between citations as done by latex/bibtex/etc.,
  and those done in every other format (handled through CSL).  Assuming
  latex users want to keep their native processing rather than
  delegating to CSL, we need to solve the myriad small inconsistencies
  between these two tools.  I think this is an area where it’s important
  to get things right: users of citations generally have exacting
  requirements.  “Approximately Chicago-style” or “almost MLA” aren’t
  worth anything.

When I start working again I will take your words about silver bullets
to heart, and come up with something that covers at least basic use
cases for users who can compile a haskell program themselves.  We can
expand from there.

(I should also say, if someone else is interested in working on this
please don’t hesitate to jump right in.  I will help you however I can!)

> 
> ** Annotations
> 
> It would be nice to allow annotating text in Org. I already made
> a proposal for that feature a few months ago, without much success.
> Anyway, I'd like to implement it, in a simplified form. For the record,
> the idea is to use some markup for beginning and end of an annotation,
> e.g.,
> 
>   [@:id].[@]
> 
> and store text within a dedicated section,
> 
>   * Annotations
> 
>   [@:id] ...
> 
> Like footnotes, you could easily browse remotely annotations at point.
> However, they would be, at least at the beginning, completely ignored
> during export.
> 
> ** Backslash escaping
> 
> Allowing to escape some symbols in plain text (e.g., emphasis markers,
> square brackets...) would remove a limitation in verbatim/code objects.
> As a small benefit, it would also permit to implement mid-word markup:
> b*o*ld.
> 
> There are some gotchas, however.
> 
> * Important fixes
> 
> ** Cache
> 
> The cache needs to be fixed. Its underlying implementation probably
> needs to be changed, too. At the moment, it uses an AVL tree, which
> isn't much tolerant and results in a freeze whenever the cache is
> corrupted. Shifting to text properties could improve the situation.
> 
> Also, it needs to do better analysis in order to prevent those
> corruptions. This is obviously the hardest part.
> 
> Again, an efficient cache can give us a better fontification mechanism,
> since Org syntax is not regular.
> 
> ** Link hexification
> 
> There are currently some subtle inconsistencies in link handling. See
> for example `org-make-link-string'.

At the risk of being a bit of an anarchist, I think this is somewhere we
could benefit from throwing backward compatibility out the window, at
least for brainstorming purposes.  The link-hexification bug threads
I’ve read give the impression of watching someone try to add one more
level onto a teetering house of cards.  It would be great if someone
could take inventory of the uses of links in org, and then try to design
a solid syntax that works for them from scratch.  We’d wait to worry
about implementation until having a well-engineered design.

(To give an example of what I have in mind, it may turn out that
hexification, 

[O] org-crypt & multiple recipients

[Nick Anderson]

I was playing with org-crypt today and it's pretty nifty.

While encrypting things for myself is the primary use case, I have other
team members that also use org-mode. It occurred to me that it would be
neat if I could specify a list of users to encrypt a node for. Then we
could share an org file and a node could be decrypted by individual.

Re: [O] Some projects

[Matt Price]

On Sun, Oct 25, 2015 at 3:02 PM, Rasmus  wrote:

> Hi,
>
> First, thanks for writing this up, Nicolas.  Org has been a bit slow
> lately, at least for my part.
>

ditto.  and thanks to eveyrone in the thread for their input.

>
>
>
> > ** Citations
> >
> > Development apparently stopped for some reason. We have a citation
> > syntax for Org in wip-cite and some work done in wip-cite-awe and
> > probably elsewhere.
> >
> > I think we could at least provide features defined in Org Ref using the
> > new syntax (minus hydra/helm related functions).
> >
> > We don't need a silver bullet. Just something with a non-empty user
> > base, and extensible. In any case, the work done so far shouldn't be
> > wasted.
>
> This is something I care deeply about, and I would like to work on it.
> I’m a bit short on time these days, but still it’s the most important
> missing feature IMO.
>
> We sort of got stuck on syntax discussions the last time (besides
> [cite]/[(cite)]), as well as tool choices (citeproc-java vs. some
> org-specific Haskell implementation).
>
> I would suggest we start with LaTeX, although it contains some danger of
> making choices that are hard to make work with citeproc.  I’m not sure how
> far Aaron got on this work.
>
>
> I also regard this as the most important missing feature from Org. From my
perspective, latex-centred approaches are I guess fine but don't
immediately solve any issues for me. My use cases are (a) publication to
the web, either of papers or, especially,  of teaching resources; and (b)
circulation of scholarly work in  .docx or (in rare best-case scenarios)
markdown.  I would really be grateful if work on citations left the door
open for these formats, which are going to be with us for a long time.

Again, thanks to all you guys for your work on this.

m

Re: [O] Some projects

[Anders Johansson]

Anders Johansson  gmail.com> writes:

> I hacked together something like this a while ago when I needed to add
> inline-comments that would later be exported as odt-comments (but I also
> made it work for latex).
> 
> I chose to implement it via a unicode-bracket ❰❙❱, like this:
> 
> ❰Simple comment❱
> ❰Text that is commented on❙Comment❱
> ❰[Author] Simple comment❱
> ❰Commented text❙[Author] Comment❱
> 
> These are inserted with a custom command to make it easy (including an
> author-history-list selectable with helm).
> 
> I've put it up in a gist if anyone finds it useful:
> https://gist.github.com/andersjohansson/6baa1e42ad4d7353e125
> 
> Cheers,
> Anders Johansson
> 

But taking a look at org-annotate (https://github.com/girzel/org-annotate) i
see that it is a much more complete first attempt at a solution. Stupid that
I didn't find that when I needed it this summer.

/Anders Johansson

Re: [O] Some projects

[Nicolas Goaziou]

Marcin Borkowski  writes:

> That sounds interesting, though I don't really see much difference
> between this and plain simple comments.

  1. you cannot simply inline comments (you need to create a new link
 type or some such);
  2. you cannot mark exactly where the comment applies.

>> ** Backslash escaping
>>
>> Allowing to escape some symbols in plain text (e.g., emphasis markers,
>> square brackets...) would remove a limitation in verbatim/code objects.
>> As a small benefit, it would also permit to implement mid-word markup:
>> b*o*ld.
>>
>> There are some gotchas, however.
>
> And this one is probably the most interesting to me.  If I can help
> (testing, suggestions, maybe coding - I'm in the process of transferring
> copyright for my Emacs/Org-mode/AUCTeX contributions to the FSF), please
> let me know.

Here, I don't even have clear specifications. So the first step would be
to define them.

1. It should be unintrusive, i.e., you only need to escape ambiguous
   cases. E.g., \[1] makes sure that [1] will not be treated as
   a footnote reference, but \[*] is equivalent to [*].

2. It should allow to insert "=" within verbatim and "~" within code
   markup.

3. It should only be used in paragraphs, verse blocks or table cells.
   E.g., there is no escaping in #+NAME: ... or in node properties.

Assuming you can escape #, :, |, [, {, <, *, +, _, ^, /, ~, =, you only
need to escape \ if it is followed by any of the previous characters.

So, \\= means \= but \\! means \\!.

Unfortunately, there is a special entity, "\_ " which is incompatible
with the previous definition.

Implementation-wise, I think it is enough to resolve backslash escaping
when parsing a paragraph (or equivalent).


Regards,

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-25, at 17:37, Nicolas Goaziou  wrote:

> Marcin Borkowski  writes:
>
>> Since your point is quite valid - and OTOH, I would like to put anything
>> (or almost anything) in =code= markup, for instance (my use case: Emacs
>> keybindings, try =C-x ,= - Org won't recognize it as code!).  I could
>> mess up with org-emphasis-regexp-components in e.g. file local
>> variables, but this is far from clean.
>
> I cannot think of any bad consequence if we tailor "border" in
> `org-emphasis-regexp-components' to allow everything but white spaces.

I don't know, I guess I would welcome such change!

>> Maybe a good solution would be to allow two syntaxes for markup:
>> "short", like *bold* or =code=, and "long", like \textbf{bold} and
>> \verb|code|.  If it is decided that such LaTeX-like syntax is fine, we
>> could only introduce escaping of backslash and curly braces, which seems
>> a decent compromise.
>
> I don't think LaTeX-like syntax is good. It doesn't belong to
> lightweight markup. Besides, Org already supports LaTeX macros so it
> would probably be ambiguous.

I see.  It was only a proposal.  Another possibility could be XML's
 ... .  Or maybe the whole idea of short and long syntax is
bad.  But I'm afraid that if we want "lightweight markup", we might get
"impossible to mark up certain strings" (like Emacs keystrokes, which
are sometimes rather weird, like =C-x ,= - which is unbound by default,
but possible to use).

> I suggest to keep as close as possible to the existing markup.
>
> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Nicolas Goaziou]

Jan Malakhovski  writes:

> Nicolas Goaziou  writes:
>
>>> * Pressing  on an entry in org-agenda-list moves the cursor to the
>>>   corresponding node.
>>>
>>>   Previously it moved the cursor to the corresponding CLOCK: line and I
>>>   used that a lot.
>>
>> According to `org-agenda-goto''s docstring, this doesn't look like
>> a feature. Besides, there is a function to jump to the running clock
>> already: `org-clock-goto'.
>
> I mean this sequence:
>
> * Press `M-x org-agenda-list`
> * Press `v l`
>   (or `v c`)
> * Select an entry (interval)
> * Press ``
>
> Previously it opened a window with the cursor on the CLOCK: line of the
> corresponding entry (interval), now it jumps to the header of the task
> this interval is an element of.

Could you provide an ECM with appropriate CLOCK lines?

Thank you.


Regards,

Re: [O] [PATCH] make org-clock-time% respect org-effort-durations and related

[Kyle Meyer]

Hello,

Jan Malakhovski  writes:

> Hi.
>
> The first patch here is a must, because it fixes a bug I stumble upoon
> daily. Middle two are just to make the names consistent. While doing
> all those changes I read quite a lot of code and the last patch adds a
> FIXME for a particularly ugly place I'm not sure how to fix (I think
> don't ever consciously use that code path and I'm not sure what it
> supposed to do).

Thanks for these patches, as well as the other series you sent [1].  I
haven't looked at the content in detail, but based on the diffstats,
these changes are touching enough lines to require copyright assignment
[2].  Also, please include a ChangeLog entry in the commit message [3].

Thanks again.

[1] http://thread.gmane.org/gmane.emacs.orgmode/102168
[2] http://orgmode.org/worg/org-contribute.html#orgheadline2
[3] http://orgmode.org/worg/org-contribute.html#orgheadline6

--
Kyle

Re: [O] Org-agenda-leaders

[Nicolas Goaziou]

Nick Dokos  writes:

> Oops - sorry: I didn't realize that. I didn't even notice the CLOCK
> defconst. As a matter of curiosity, what's the back story here?

Backward compatibility. What else? A defconst prevent anyone from using
anything else than "DEADLINE:" and "SCHEDULED:" (I cannot remember
exactly, but even though you can still modify them, it breaks something
elsewhere).

With a defvar, we tolerate users on the dark side of the syntax. But
really, no one should modify these keywords.

Regards,

Re: [O] Some projects

[Fabrice Popineau]

2015-10-25 18:57 GMT+01:00 Thomas S. Dye :


> would suggest an alternate wording.  In this case, it would be super
> helpful to have a function that replaced annotated text with the
> annotation, so the author could easily accept the editor's suggestion.
>
>
In this case, it would be nice if annotations could have an author too!

Regards,

Fabrice

Re: [O] Some projects

[Nicolas Goaziou]

Fabrice Popineau  writes:

> 2015-10-25 18:57 GMT+01:00 Thomas S. Dye :
>
>
>> would suggest an alternate wording.  In this case, it would be super
>> helpful to have a function that replaced annotated text with the
>> annotation, so the author could easily accept the editor's suggestion.
>>
>>
> In this case, it would be nice if annotations could have an author
> too!

The full proposal was at
 but it didn't get
much positive feedback. Therefore I suggested a simplified version, with
a single author.

Also, there is

  https://github.com/girzel/org-annotate

which is even simpler.

Regards,

Re: [O] [PATCH] Fix `org-capture-templates' type declaration

[Grégoire Jadi]

Nicolas Goaziou writes:

> Grégoire Jadi  writes:
>
>> With my patch, the customization interface looks like this
>> - for a file :
>> Target location: Value Menu File:
>>   File: Value Menu File: ~/org/notes.org
>>
>> - for a variable :
>> Target location: Value Menu File:
>>   File: Value Menu Variable: nil
>>
>> - for a function :
>> Target location: Value Menu File:
>>   File: Value Menu Function: ignore
>>
>> - for an Emacs Lisp form :
>> Target location: Value Menu File:
>>   File: Value Menu Lisp expression: nil
>>
>> What kind of rendering do you think would be better/clearer?
>
> :tag " File" is misleading. Perhaps " File, variable, function or
> S-expression" would be clearer, if a bit longish.

That's too long IMHO.

> Not sure how to make this beast clearer anyway.

Me neither.

If anyone has an opinion on this, s/he is welcome!

This patch can wait a little until we find a satisfactory solution.
AFAIK noone has reported this bug :)


Best,

-- 
Grégoire Jadi


signature.asc
Description: PGP signature

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> Matt Lundin  writes:
>
>> In short, org-habit seems to want a + notation for the purposes of the
>> agenda display and a .+ notation for the purposes of resetting the
>> timestamp. What is the best solution?
>
> Still looking for it.
>
> Meanwhile, I reverted the opinionated change in
> a427098b57c747ecc76feb0593f32922a1e12f67.

Another take on this in 3072cb28e8627066f465f1a4af85da88135d0549.

Re: [O] Some projects

[Thomas S . Dye]

Nicolas Goaziou  writes:

> Hello,
>
> I'd like to see some features moving forward, and some important issues
> fixed, hopefully, in the next months. I'm sharing them here so that
> anyone interested can help.
>
> ** Annotations
>
> It would be nice to allow annotating text in Org. I already made
> a proposal for that feature a few months ago, without much success.
> Anyway, I'd like to implement it, in a simplified form. For the record,
> the idea is to use some markup for beginning and end of an annotation,
> e.g.,
>
>   [@:id].[@]
>
> and store text within a dedicated section,
>
>   * Annotations
>
>   [@:id] ...
>
> Like footnotes, you could easily browse remotely annotations at point.
> However, they would be, at least at the beginning, completely ignored
> during export.

+1

As an editor, I would use annotations a lot.  Sometimes an annotation
would be a comment on the text, meant to remind the author of some fact
or to suggest some other point of view.  Other times the annotation
would suggest an alternate wording.  In this case, it would be super
helpful to have a function that replaced annotated text with the
annotation, so the author could easily accept the editor's suggestion.

Would annotations also apply to source code blocks?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

[O] How can I call the exporter from function?

[joakim]

I want to call the exporter in a certain way, so I don't have to type
the same options every time.

Basically I want to do first this:
(re-search-backward "^\\*\\* ")
(org-mark-subtree)

Then I want to export the marked subtree as odt.

With command keys it becomes something like:
c-c c-e c-s o o

... If I remember correctly. In this case I would rather do

m-x my-own-canned-exporter

I tried following the exporting dispatcher function but got lost in the
wilderness. Does anyone have a suggestion?
-- 
Joakim Verona

Re: [O] Some projects

[Thomas S . Dye]

Nicolas Goaziou  writes:

> Thomas S. Dye  writes:
>
>> Nicolas Goaziou  writes:
>>
>>> The full proposal was at
>>>  but it didn't get
>>> much positive feedback. Therefore I suggested a simplified version, with
>>> a single author.
>>
>> In my case, the lack of positive feedback was "too much org, too little
>> time".
>>
>> The original version, which includes the author Fabrice mentioned, seems
>> superior to me.  It potentially eases collaboration and also configuring
>> alternate versions of the same document.
>>
>> I'm not clear about affiliated keyword for source code blocks.  Would
>> tangling honor  #+OPTIONS:   :student1?
>
> The limitation is that you can only replace the code block as a whole,
> so with
>
>   #+annotate: bugfix
>   #+name: bikeshed
>   #+begin_src emacs-lisp
>   (paint 'bikeshed blue)
>   #+end_src
>
>   * Annotations
>
>   [@:bugfig:me]
>   # You're clearly wrong
>   #+begin_src emacs-lisp
>   (pain 'bikeshed green)
>   #+end_src
>
> when using
>
>   #+OPTIONS: @:me
>
> body becomes
>
>   #+name: bikeshed
>   #+begin_src emacs-lisp
>   (paint 'bikeshed green)
>   #+end_src

And also,

#+name: baz
#+begin_src emacs-lisp :noweb yes
(some code)
<>
(other code)
#+end_src

so the various :noweb options, including evaluation of baz in the Org
mode buffer, honor #+OPTIONS: @:me?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Some projects

[Samuel Wales]

i like some of these ideas, particularly lexical.

org already has a lot of syntax.  i am leery of introducing yet more
heterogenous syntax to org.  key word heterogenous.  i don't mind more
features if it is always using the same syntax framework and thus can
take advantage of everything else that uses it.  key word framework.

thus, i'd propose a single syntax framework that takes care of future
syntax.  a syntax framework like $[annotation ...] where ... is
specifiable as a lisp lambda list or similar could also be used for
other features, including long-form emphasis.

i don't think long-form emphasis is a bad idea at all.  it allows
export back end independence.  i only think it is bad if it means
introducing heterogenous, non-framework syntax.

a single framework takes care of future features too.  and as a bonus
it allows future subfeatures.  for example, there is no need to
implement authorship in annotations until we decide we want them
later.  when we do, just add a keyword option: $[annotation :author
"joe"].

and yet another bonus is that it could be used for user-defined
features.  all without adding heterogenous non-framework syntax.

===

i would need fontification to be able to fontify inline footnotes that
have more than one paragraph [i.e. have blank lines in them, which is
currently not allowed in 8.x org export.  fontification currently and
always has fontified them correctly from my perspective i.e. by
allowing multiple paragraphs].

Re: [O] Some projects

[Samuel Wales]

naturally, long-form emphasis can look like $[emphasis ...].

Re: [O] org-reveal questions

[Eric S Fraga]

Hello all,

So, I decided I would play with org-reveal some more, just to see if I
could get some of the functionality that Xebar wanted fairly
easily.  It turns out that I could use a web based presentation for a
small PR exercise...

I've run into two stumbling blocks using org-reveal.

First, the #+HTML: directive seems to be ignored although
the #+BEGIN_HTML/#+END_HTML construct works.  This is only in reveal
export, not HTML export.

The second problem is more about HTML export than reveal
specifically.  In LaTeX, an image is exported directly without any
surrounding material if only the image is there.  Surrounding material,
i.e. LaTeX figure environment, is only included if a caption is
present.  In reveal, there doesn't seem to be an equivalent
behaviour.  That is, all my images get exported within a figure
.  I would like to have the option of a bare-bones  export
without having to resort to direct HTML.  Is this possible?  It would
seem to make sense to have the same type of logic apply to HTML export
as it does to LaTeX?

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Some projects

[Anders Johansson]

Marcin Borkowski  mbork.pl> writes:

> 
> 
> On 2015-10-25, at 19:12, Nicolas Goaziou  nicolasgoaziou.fr> wrote:
> 
> > Fabrice Popineau  supelec.fr> writes:
> >
> >> 2015-10-25 18:57 GMT+01:00 Thomas S. Dye  tsdye.com>:
> >>
> >>
> >>> would suggest an alternate wording.  In this case, it would be super
> >>> helpful to have a function that replaced annotated text with the
> >>> annotation, so the author could easily accept the editor's suggestion.
> >>>
> >>>
> >> In this case, it would be nice if annotations could have an author
> >> too!
> >
> > The full proposal was at
> >  but it didn't get
> > much positive feedback. Therefore I suggested a simplified version, with
> > a single author.
> 
> I like it!  I'm not sure I would use it a lot (and definitely not with
> other people - there are not many people using Org-mode in my
> institution, in fact I guess I'm the only one), but it does seem
> useful.
> 
> One thing: there /must/ be a way to export annotations.  For LaTeX, the
> todonotes package (https://www.ctan.org/pkg/todonotes) seems a natural
> choice.
> 

I hacked together something like this a while ago when I needed to add
inline-comments that would later be exported as odt-comments (but I also
made it work for latex).

I chose to implement it via a unicode-bracket ❰❙❱, like this:

❰Simple comment❱
❰Text that is commented on❙Comment❱
❰[Author] Simple comment❱
❰Commented text❙[Author] Comment❱

These are inserted with a custom command to make it easy (including an
author-history-list selectable with helm).

I've put it up in a gist if anyone finds it useful:
https://gist.github.com/andersjohansson/6baa1e42ad4d7353e125

Cheers,
Anders Johansson

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-25, at 14:08, Nicolas Goaziou  wrote:

> Hello,
>
> I'd like to see some features moving forward, and some important issues
> fixed, hopefully, in the next months. I'm sharing them here so that
> anyone interested can help.
>
>
> * Features
>
> ** Citations
>
> Development apparently stopped for some reason. We have a citation
> syntax for Org in wip-cite and some work done in wip-cite-awe and
> probably elsewhere.
>
> I think we could at least provide features defined in Org Ref using the
> new syntax (minus hydra/helm related functions).
>
> We don't need a silver bullet. Just something with a non-empty user
> base, and extensible. In any case, the work done so far shouldn't be
> wasted.

Interesting.  I don't use Org for writing scientific articles, but many
people do, and this might be really helpful.

> ** Annotations
>
> It would be nice to allow annotating text in Org. I already made
> a proposal for that feature a few months ago, without much success.
> Anyway, I'd like to implement it, in a simplified form. For the record,
> the idea is to use some markup for beginning and end of an annotation,
> e.g.,
>
>   [@:id].[@]
>
> and store text within a dedicated section,
>
>   * Annotations
>
>   [@:id] ...
>
> Like footnotes, you could easily browse remotely annotations at point.
> However, they would be, at least at the beginning, completely ignored
> during export.

That sounds interesting, though I don't really see much difference
between this and plain simple comments.

> ** Backslash escaping
>
> Allowing to escape some symbols in plain text (e.g., emphasis markers,
> square brackets...) would remove a limitation in verbatim/code objects.
> As a small benefit, it would also permit to implement mid-word markup:
> b*o*ld.
>
> There are some gotchas, however.

And this one is probably the most interesting to me.  If I can help
(testing, suggestions, maybe coding - I'm in the process of transferring
copyright for my Emacs/Org-mode/AUCTeX contributions to the FSF), please
let me know.

> Here we are. I hope finding enough spare time (it also depends on the
> quantity of bugs to fix...) to investigate most, if not all of these
> issues. Of course, feedback is welcome.
>
> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Nicolas Goaziou]

Hello,

Jan Malakhovski  writes:

> * C-c C-x C-i clocks in into a wrong node.
>   Instead of clocking-in into the node under cursor it clock-ins into the
>   next one.

Fixed. Thank you.

> * Pressing  on an entry in org-agenda-list moves the cursor to the
>   corresponding node.
>
>   Previously it moved the cursor to the corresponding CLOCK: line and I
>   used that a lot.

According to `org-agenda-goto''s docstring, this doesn't look like
a feature. Besides, there is a function to jump to the running clock
already: `org-clock-goto'.


Regards,

-- 
Nicolas Goaziou

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-25, at 16:45, Eric S Fraga  wrote:

> On Sunday, 25 Oct 2015 at 14:08, Nicolas Goaziou wrote:
>> Hello,
>>
>> I'd like to see some features moving forward, and some important issues
>> fixed, hopefully, in the next months. I'm sharing them here so that
>> anyone interested can help.
>
> Nicolas,
>
> I look forward to all the advances you have proposed... except for this one:
>
>> ** Backslash escaping
>>
>> Allowing to escape some symbols in plain text (e.g., emphasis markers,
>> square brackets...) would remove a limitation in verbatim/code objects.
>> As a small benefit, it would also permit to implement mid-word markup:
>> b*o*ld.
>
> I'm concerned that it will make typing normal text more onerous.  Right
> now, org is quite non-intrusive in most of my writing yet is quite rich
> in what it can encode.  Having to backslash symbols that I use in text
> quite often (especially square brackets) would be annoying.  Maybe I
> misunderstood; if so, I apologise for the noise!

Eric, it's good that you write (IMO at least) - this is how the ideas
can get refined.

Since your point is quite valid - and OTOH, I would like to put anything
(or almost anything) in =code= markup, for instance (my use case: Emacs
keybindings, try =C-x ,= - Org won't recognize it as code!).  I could
mess up with org-emphasis-regexp-components in e.g. file local
variables, but this is far from clean.

Maybe a good solution would be to allow two syntaxes for markup:
"short", like *bold* or =code=, and "long", like \textbf{bold} and
\verb|code|.  If it is decided that such LaTeX-like syntax is fine, we
could only introduce escaping of backslash and curly braces, which seems
a decent compromise.

We could even use LaTeX-like constructs like \textbf, but with
\verb-like delimitation by two identical characters not present in the
text itself.  We might also use a convention that if the character right
after \textbf is an opening paren of some kind - the syntax table might
be reused for that - then we expect a closing one at the end, and if
not, we expect an identical one at the end.  This way, we could say
\textbf{Boldface} and \verb{verbatim}
but also
\textbf|{boldface in curly braces}| and \verb|C-x {|
etc.  This way only the backslash needs escaping.

There are a lot of possibilities, and plenty of time to settle on the
best one.

> Thanks,
> eric

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

Matt Lundin  writes:

> In short, org-habit seems to want a + notation for the purposes of the
> agenda display and a .+ notation for the purposes of resetting the
> timestamp. What is the best solution?

Still looking for it.

Meanwhile, I reverted the opinionated change in
a427098b57c747ecc76feb0593f32922a1e12f67.

Regards,

Re: [O] Some projects

[Nicolas Goaziou]

Marcin Borkowski  writes:

> Since your point is quite valid - and OTOH, I would like to put anything
> (or almost anything) in =code= markup, for instance (my use case: Emacs
> keybindings, try =C-x ,= - Org won't recognize it as code!).  I could
> mess up with org-emphasis-regexp-components in e.g. file local
> variables, but this is far from clean.

I cannot think of any bad consequence if we tailor "border" in
`org-emphasis-regexp-components' to allow everything but white spaces.

> Maybe a good solution would be to allow two syntaxes for markup:
> "short", like *bold* or =code=, and "long", like \textbf{bold} and
> \verb|code|.  If it is decided that such LaTeX-like syntax is fine, we
> could only introduce escaping of backslash and curly braces, which seems
> a decent compromise.

I don't think LaTeX-like syntax is good. It doesn't belong to
lightweight markup. Besides, Org already supports LaTeX macros so it
would probably be ambiguous.

I suggest to keep as close as possible to the existing markup.

Regards,

[O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Jan Malakhovski]

Hi.

Emacs   : GNU Emacs 24.5.2 (x86_64-unknown-linux-gnu, GTK+ Version 
2.24.28) of 2015-10-05 on localhost
Current  package: Org-mode version 8.3.2 (release_8.3.2-209-gba4d33 @ 
/home/oxij/repo/org-mode/lisp/) (actually, both master and maint)
Previous package: Org-mode version 8.2.10 (8.2.10-35-g19a7d6-elpaplus @ 
/run/current-system/sw/share/emacs/site-lisp/elpa/org-plus-contrib-20150406/)

Some regressions when moving from previous to current package:

* C-c C-x C-i clocks in into a wrong node.
  Instead of clocking-in into the node under cursor it clock-ins into the
  next one.
  Can be replicated with the following init.el:

#+BEGIN_SRC emacs-lisp
(add-to-list 'load-path "~/repo/org-mode/lisp")
(add-to-list 'load-path "~/repo/org-mode/contrib/lisp")
(require 'org)
#+END_SRC

  and attached minimal.org.

* Pressing  on an entry in org-agenda-list moves the cursor to the
  corresponding node.

  Previously it moved the cursor to the corresponding CLOCK: line and I
  used that a lot.

Cheers,
  Jan

* Test
** Test test
** Test test
* Test
* Test

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Jan Malakhovski]

Nicolas Goaziou  writes:

>> * Pressing  on an entry in org-agenda-list moves the cursor to the
>>   corresponding node.
>>
>>   Previously it moved the cursor to the corresponding CLOCK: line and I
>>   used that a lot.
>
> According to `org-agenda-goto''s docstring, this doesn't look like
> a feature. Besides, there is a function to jump to the running clock
> already: `org-clock-goto'.

I mean this sequence:

* Press `M-x org-agenda-list`
* Press `v l`
  (or `v c`)
* Select an entry (interval)
* Press ``

Previously it opened a window with the cursor on the CLOCK: line of the
corresponding entry (interval), now it jumps to the header of the task
this interval is an element of.

I'm sure this is a misfeature because now it's pretty much impossible to
quickly find CLOCK: entries that correspond to current org-agenda-list
items. For me this is critical, because I clock everything, have
megabytes of CLOCK: entries and edit them a lot.

Cheers,
  Jan

Re: [O] Some projects

[Eric S Fraga]

On Sunday, 25 Oct 2015 at 14:08, Nicolas Goaziou wrote:
> Hello,
>
> I'd like to see some features moving forward, and some important issues
> fixed, hopefully, in the next months. I'm sharing them here so that
> anyone interested can help.

Nicolas,

I look forward to all the advances you have proposed... except for this one:

> ** Backslash escaping
>
> Allowing to escape some symbols in plain text (e.g., emphasis markers,
> square brackets...) would remove a limitation in verbatim/code objects.
> As a small benefit, it would also permit to implement mid-word markup:
> b*o*ld.

I'm concerned that it will make typing normal text more onerous.  Right
now, org is quite non-intrusive in most of my writing yet is quite rich
in what it can encode.  Having to backslash symbols that I use in text
quite often (especially square brackets) would be annoying.  Maybe I
misunderstood; if so, I apologise for the noise!

Regarding citations, I have not played with the -wip branch at
all.  Maybe I should.  It just wasn't clear where that branch had got to
and whether it was at a point worth trying.  Can you (or somebody else)
update us with a summary of what is possible?  I'm always in the process
of writing papers so I may be happy to be a guinea pig.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Some projects

[Nicolas Goaziou]

Eric S Fraga  writes:

> I'm concerned that it will make typing normal text more onerous.  Right
> now, org is quite non-intrusive in most of my writing yet is quite rich
> in what it can encode.  Having to backslash symbols that I use in text
> quite often (especially square brackets) would be annoying.  Maybe I
> misunderstood; if so, I apologise for the noise!

This is also my concern. I don't want to add complexity to typing in
Org, at all. Yet, if this feature is correctly defined, this should
disambiguate some annoying situations (e.g., [1] when you do not want
a footnote reference).

> Regarding citations, I have not played with the -wip branch at
> all.  Maybe I should.  It just wasn't clear where that branch had got to
> and whether it was at a point worth trying.  Can you (or somebody else)
> update us with a summary of what is possible?

I cannot. I just implemented the syntax. Others implemented tools on top
of it. I don't know the current state of this.

Regards,

Re: [O] [PATCH] Fix `org-capture-templates' type declaration

[Nicolas Goaziou]

Grégoire Jadi  writes:

> With my patch, the customization interface looks like this
> - for a file :
> Target location: Value Menu File:
>   File: Value Menu File: ~/org/notes.org
>
> - for a variable :
> Target location: Value Menu File:
>   File: Value Menu Variable: nil
>
> - for a function :
> Target location: Value Menu File:
>   File: Value Menu Function: ignore
>
> - for an Emacs Lisp form :
> Target location: Value Menu File:
>   File: Value Menu Lisp expression: nil
>
> What kind of rendering do you think would be better/clearer?

:tag " File" is misleading. Perhaps " File, variable, function or
S-expression" would be clearer, if a bit longish.

Not sure how to make this beast clearer anyway.


Regards,

Re: [O] Org-mode reinvented?

[Ken Mankoff]

On 2015-10-25 at 07:12, John Kitchin  wrote:
> Interesting. One day I imagine something like this, or sharelatex
> exists for collaborating on org-files with people who don't like
> Emacs...

One can hope, but unfortunately it seems Markdown is the default implementation 
for people supporting a simple markup language.

  -k.

[O] Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return)

[Stefan-W. Hahn]

Mail von Stefan-W. Hahn, Sat, 24 Oct 2015 at 08:48:47 +0200:

Hello,

as I observed there is a change in behaviour of org-return from on

commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
Author: Nicolas Goaziou 
Date:   Sun Oct 18 09:36:15 2015 +0200

for timestamps, date ranges and any link.

The same change of behaviour was done for org-open-at-point from on

commit d75fa9febc676af4893fba9e4d53d5babbb801aa
Author: Nicolas Goaziou 
Date:   Sun Mar 2 10:32:51 2014 +0100

for timestamp, any link and footnote-reference (perhaps other I'm not sure).

For example of a link:

   [[link][description]]x

If cursor was at position x the old behaviour of org-return (hitting )
was to open a new line, and position the cursor at the beginning of the new
line. The old behaviour of org-open-at-point was to say "no link".

For me this seems consistent because if you go with the cursor over
position x you see no hint and mouse-click do nothing. You have to go
over the link to see face changing and be able to mouse-click top follow
the link.

Additonally description of org-open-at-point say "... When point is on a
link, follow it", not "on or after".

Also if you insert a link by yanking or org-insert-link cursor is positioned
directly after inserted link, cursor pos x s.o. With old behaviour you can
behaviour you can straight hit  to get a newline. With new behaviour
you have to add space before  or call open-line and position the
cursor.

For me the new behaviour seems inconsistend itself because everytime
I want to get a new line I noew have to check if cursor is positioned
right after a timestamp, or link. Or I have to shutoff org-return-follows-link.

Are there any other org'ers with opinions about this behaviour?
I'm really interested in your and others opinion about this behaviours
before building some workarounds for me personally. (Perhaps I have overseen
something in the big pictures?)


With kind regards,
Stefan

P.S. Excue me if not being subtle enough, its difficult to me beeing subtle
in a foreign language.

-- 
Stefan-W. Hahn  It is easy to make things.
It is hard to make things simple.

Re: [O] Some projects

[Eric S Fraga]

On Sunday, 25 Oct 2015 at 19:12, Nicolas Goaziou wrote:
> The full proposal was at
>  but it didn't get
> much positive feedback. Therefore I suggested a simplified version, with
> a single author.

It's a start and that's infinitely better than no provision for
annotations at all.  I know I would use this feature often.  I use
inlinetasks for annotations currently and this would be cleaner.

Multiple authors can be done manually for now, e.g. [@:1]blah[@] with
[1] later "ESF: I don't agree ;-)".

By the way, I personally would like inline annotations, along the lines
of inline footnotes.  Just saying...

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Some projects

[Nicolas Goaziou]

Marcin Borkowski  writes:

> On 2015-10-25, at 17:37, Nicolas Goaziou  wrote:
>
>> I cannot think of any bad consequence if we tailor "border" in
>> `org-emphasis-regexp-components' to allow everything but white spaces.
>
> I don't know, I guess I would welcome such change!

Done in b4af3f0. We'll see what horrible things happen.

> I see. It was only a proposal. Another possibility could be XML's
>  ... . Or maybe the whole idea of short and long syntax
> is bad.

IMO, the latter.

> But I'm afraid that if we want "lightweight markup", we might get
> "impossible to mark up certain strings" (like Emacs keystrokes, which
> are sometimes rather weird, like =C-x ,= - which is unbound by
> default, but possible to use).

The point of escaping mechanism is to extend the set of possible
strings, at the price of a lesser readability. We could see what such
a mechanism could give us.

Regards,

Re: [O] Bug: Regressions from 8.2.10 (8.2.10-35-g19a7d6-elpaplus) to master/maint

[Jan Malakhovski]

Nicolas Goaziou  writes:

> Could you provide an ECM with appropriate CLOCK lines?

Attached.

* Other files:
** init.el:

#+BEGIN_SRC emacs-lisp
(add-to-list 'load-path "~/repo/org-mode/lisp")
(add-to-list 'load-path "~/repo/org-mode/contrib/lisp")
(require 'org)

(setq org-directory "~/org"
  org-agenda-files "~/agenda-files")
#+END_SRC

** ~/agenda-files:

#+BEGIN_SRC emacs-lisp
~/org/minimal.org
#+END_SRC

* Process:
** Press `M-x org-agenda-list`
** Press `v l` (or `v c`)
** Select any of the two entries (intervals)
** Press ``
* Expected: cursor jump to the corresponding CLOCK:.
* Got: cursor jump to "Test" line.

Cheers,
  Jan

* Test
:LOGBOOK:
CLOCK: [2015-10-25 Sun 17:00]--[2015-10-25 Sun 18:00] =>  1:00
CLOCK: [2015-10-25 Sun 16:00]--[2015-10-25 Sun 17:00] =>  1:00
:END:

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-25, at 19:12, Nicolas Goaziou  wrote:

> Fabrice Popineau  writes:
>
>> 2015-10-25 18:57 GMT+01:00 Thomas S. Dye :
>>
>>
>>> would suggest an alternate wording.  In this case, it would be super
>>> helpful to have a function that replaced annotated text with the
>>> annotation, so the author could easily accept the editor's suggestion.
>>>
>>>
>> In this case, it would be nice if annotations could have an author
>> too!
>
> The full proposal was at
>  but it didn't get
> much positive feedback. Therefore I suggested a simplified version, with
> a single author.

I like it!  I'm not sure I would use it a lot (and definitely not with
other people - there are not many people using Org-mode in my
institution, in fact I guess I'm the only one;-)), but it does seem
useful.

One thing: there /must/ be a way to export annotations.  For LaTeX, the
todonotes package (https://www.ctan.org/pkg/todonotes) seems a natural
choice.

> Also, there is
>
>   https://github.com/girzel/org-annotate
>
> which is even simpler.

I'll look into it, too, thanks!

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-25, at 19:22, Eric S Fraga  wrote:

> By the way, I personally would like inline annotations, along the lines
> of inline footnotes.  Just saying...

+1

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Some projects

[Thomas S . Dye]

Nicolas Goaziou  writes:

> The full proposal was at
>  but it didn't get
> much positive feedback. Therefore I suggested a simplified version, with
> a single author.

In my case, the lack of positive feedback was "too much org, too little
time".

The original version, which includes the author Fabrice mentioned, seems
superior to me.  It potentially eases collaboration and also configuring
alternate versions of the same document.

I'm not clear about affiliated keyword for source code blocks.  Would
tangling honor  #+OPTIONS:   :student1?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Some projects

[Nicolas Goaziou]

Thomas S. Dye  writes:

> Nicolas Goaziou  writes:
>
>> The full proposal was at
>>  but it didn't get
>> much positive feedback. Therefore I suggested a simplified version, with
>> a single author.
>
> In my case, the lack of positive feedback was "too much org, too little
> time".
>
> The original version, which includes the author Fabrice mentioned, seems
> superior to me.  It potentially eases collaboration and also configuring
> alternate versions of the same document.
>
> I'm not clear about affiliated keyword for source code blocks.  Would
> tangling honor  #+OPTIONS:   :student1?

The limitation is that you can only replace the code block as a whole,
so with

  #+annotate: bugfix
  #+name: bikeshed
  #+begin_src emacs-lisp
  (paint 'bikeshed blue)
  #+end_src

  * Annotations

  [@:bugfig:me]
  # You're clearly wrong
  #+begin_src emacs-lisp
  (pain 'bikeshed green)
  #+end_src

when using

  #+OPTIONS: @:me

body becomes

  #+name: bikeshed
  #+begin_src emacs-lisp
  (paint 'bikeshed green)
  #+end_src


Regards,

Re: [O] Org-mode reinvented?

[Marcin Borkowski]

On 2015-10-25, at 16:55, Ken Mankoff  wrote:

> On 2015-10-25 at 07:12, John Kitchin  wrote:
>> Interesting. One day I imagine something like this, or sharelatex
>> exists for collaborating on org-files with people who don't like
>> Emacs...
>
> One can hope, but unfortunately it seems Markdown is the default 
> implementation for people supporting a simple markup language.

Yes.  Sometimes I wish Org-mode used Markdown by default.  Then, I start
to think "yes, fine, but /which/ Markdown?", and I feel better;-).

(The problem with Markdown seems to be that there is no "official"
version.  Also, if Org-mode were tied to some external standard, Org's
own development - like in "adding new features" - would become
problematic.)

>   -k.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Some projects

[Rasmus]

Hi,

First, thanks for writing this up, Nicolas.  Org has been a bit slow
lately, at least for my part.

Perhaps, we should keep a file in org-mode.git which links back to
discussions (TODO.org).  There’s a couple of other things that we
discussed recently.

> ** Citations
>
> Development apparently stopped for some reason. We have a citation
> syntax for Org in wip-cite and some work done in wip-cite-awe and
> probably elsewhere.
>
> I think we could at least provide features defined in Org Ref using the
> new syntax (minus hydra/helm related functions).
>
> We don't need a silver bullet. Just something with a non-empty user
> base, and extensible. In any case, the work done so far shouldn't be
> wasted.

This is something I care deeply about, and I would like to work on it.
I’m a bit short on time these days, but still it’s the most important
missing feature IMO.

We sort of got stuck on syntax discussions the last time (besides
[cite]/[(cite)]), as well as tool choices (citeproc-java vs. some
org-specific Haskell implementation).

I would suggest we start with LaTeX, although it contains some danger of
making choices that are hard to make work with citeproc.  I’m not sure how
far Aaron got on this work.


> ** Annotations

I still don’t care for this, but no point in reiteration.

> ** Backslash escaping

Would be nice at times.

I strongly disagree with introducing XML or LaTeX like syntax as is
suggested a bit further down in the thread.

> ** Cache

Probably to complicated for me...

> ** Link hexification
>
> There are currently some subtle inconsistencies in link handling. See
> for example `org-make-link-string'.

Indeed, this is annoying.  Thanks for bringing it up again.

> ** Use lexical binding everywhere

Sounds good.  I am under the impression (from git log) that you have
already fixed a number of files in this regard, right?

> ** Find a solution for orgstruct minor mode

I would also try to dedicate time towards this.

> Org struct is really different from Org. It prevents Org from using
> better algorithms for outline navigation (see discussion about
> `org-show-children' on this list).
>
> I think Org struct should be removed from "org.el" (and org-footnote
> ...) and added in its own library.

I agree.  Orgstruct is powered by black voodoo.

> It should also be built on top of Outline mode instead of Org mode.

I don’t have an opinion on this.  Would you not think that it would be
better if orgstruct is a collections of functions that wrap around Org?  I
fear that if change X is made to Org, we would have to also implement the
change in orgstruct.


> Org, OTOH, should remove dependencies on Outline mode and implement
> better navigation functions.

Perhaps.  I don’t understand where the benefit would be.

> I have the feeling that Org struct will need to be rewritten almost from
> scratch in the process.

... Which is not all that bad.

—Rasmus

-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts

Re: [O] Some projects

[Marcin Borkowski]

On 2015-10-25, at 20:02, Rasmus  wrote:

>> ** Backslash escaping
>
> Would be nice at times.
>
> I strongly disagree with introducing XML or LaTeX like syntax as is
> suggested a bit further down in the thread.

Since it seems I'm the only one that proposed (and liked) that idea, let
me reiterate that (1) I meant it only as a variant, that (2)
I personally would prefer LaTeX over XML, and that (3) if other ways of
making it possible to put /anything/ in =code= appear, that's completely
fine with me.

(Note also that I'm heavily biased, having been a (La)TeX user for about
two decades now.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Some projects

[Nicolas Goaziou]

Thomas S. Dye  writes:

> Would tangling honor #+OPTIONS:  :student1?

  #+OPTIONS: @:...

is for export, so I guess not. Though, it can be implemented later.

Regards,