Re: [O] bug in orgmode parsing of results

[daimrod]

On 12/27/16 19:11, Charles C. Berry wrote:
> On Tue, 27 Dec 2016, daimrod wrote:
> 
>> Hi,
>>
>> I've found what I think is a bug in orgmode parsing.
>> When the following file is parsed :
>>
>> * Test
>> #+BEGIN_SRC emacs-lisp :exports results :results raw drawer
>> (format "- Test2")
>> #+END_SRC
>>
>> #+RESULTS:
>> :RESULTS:
>> - Test2
>> :END:
>>
> 
> [snip]
> 
>>
>> That is, it generates a DRAWER, which seems correct.
>>
>> However, when the following file is parsed :
>>
>> * Test
>> #+BEGIN_SRC emacs-lisp :exports results :results raw drawer
>> (format "* Test2")
>> #+END_SRC
>>
>> #+RESULTS:
>> :RESULTS:
>> * Test2
>> :END:
>>
> 
> [deleted]
> 
>> That is, it generates a PARAGRAPH which seems incorrect.
>>
>> WDYT?
>>
> 
> What I think is that you should run org-lint on your document. It will
> say something like this (but with different line numbers):
> 
>   Line Trust Warning
>  2 low   Forbidden combination in header ":results": raw, drawer
> 12 low   Forbidden combination in header ":results": raw, drawer
> 17 low   Possible incomplete drawer ":RESULTS:"
> 
> The last one should catch your eye.

Didn't know about org-lint. Thanks.

> If you want to generate results that have lines that start with `*' you
> need to protect them. A good way to do this is to wrap them in a src
> block or export block like this:
> 
> #+BEGIN_SRC emacs-lisp :exports results :wrap export latex
> (format "* Test2")
> #+END_SRC

The thing about :wrap export html is that I've to generate the HTML
myself, whereas when I export the :RESULTS: drawer, org-mode generates
the HTML. AFAIK there is no export block for org (no begin_export org).

As a workaround I can always use `:results raw` but then it can not
replace the result automatically. However, that's not a problem for my
use case I think...

Thanks for your help.

Best,



signature.asc
Description: OpenPGP digital signature

Re: [O] bug in orgmode parsing of results

[daimrod]

On 12/27/16 19:09, Nicolas Goaziou wrote:
> Hello,
> 
> daimrod <daim...@gmail.com> writes:
> 
>> #+RESULTS:
>> :RESULTS:
>> * Test2
>> :END:
>>
> [...]
> 
>> (paragraph
>>  (:begin 98 :end 119 :contents-begin 109 :contents-end 119 :post-blank 0
>> :post-affiliated 109 :results
>>  (\"\")
>>  :parent #2)
>>  #(\":RESULTS:\\n\" 0 10
>>(:parent #3)))
>>
>> That is, it generates a PARAGRAPH which seems incorrect.
> 
> The parser is correct. A drawer cannot contain a headline.

Hmm, OK.

> Regards,
> 
> 



signature.asc
Description: OpenPGP digital signature

[O] bug in orgmode parsing of results

[daimrod]

Hi,

I've found what I think is a bug in orgmode parsing.
When the following file is parsed :

* Test
#+BEGIN_SRC emacs-lisp :exports results :results raw drawer
(format "- Test2")
#+END_SRC

#+RESULTS:
:RESULTS:
- Test2
:END:

The truncated result of `org-element-parse-buffer' is :
(src-block
 (:language \"emacs-lisp\" :switches nil :parameters \":exports results
:results raw drawer\" :begin 8 :end 98 :number-lines nil
:preserve-indent nil :retain-labels t :use-labels t :label-fmt nil
:value \"(format \\\"- Test2\\\")\\n\" :post-blank 1 :post-affiliated 8
:parent #2))
(drawer
 (:begin 98 :end 133 :drawer-name \"RESULTS\" :contents-begin 119
:contents-end 127 :post-blank 0 :post-affiliated 109 :results
 (\"\")
 :parent #2))

That is, it generates a DRAWER, which seems correct.

However, when the following file is parsed :

* Test
#+BEGIN_SRC emacs-lisp :exports results :results raw drawer
(format "* Test2")
#+END_SRC

#+RESULTS:
:RESULTS:
* Test2
:END:

The (truncated) result of `org-element-parse-buffer' is :
(src-block
 (:language \"emacs-lisp\" :switches nil :parameters \":exports results
:results raw drawer\" :begin 8 :end 98 :number-lines nil
:preserve-indent nil :retain-labels t :use-labels t :label-fmt nil
:value \"(format \\\"* Test2\\\")\\n\" :post-blank 1 :post-affiliated 8
:parent #2))
(paragraph
 (:begin 98 :end 119 :contents-begin 109 :contents-end 119 :post-blank 0
:post-affiliated 109 :results
 (\"\")
 :parent #2)
 #(\":RESULTS:\\n\" 0 10
   (:parent #3)))

That is, it generates a PARAGRAPH which seems incorrect.

WDYT?



signature.asc
Description: OpenPGP digital signature

Re: [O] Obsolete org contrib package

[daimrod]

On 11/10/16 10:50, Joost Kremers wrote:
> 
> On Tue, Nov 08 2016, Joost Kremers wrote:
>> Hi,
>>
>> On Tue, Nov 08 2016, Nicolas Goaziou wrote:
>>> So you mean there is no equivalent to both
>>>
>>>   (ebib-cur-entry-key)
>>
>> This one was what I was worried about, but on second thought, it
>> should be possible to simply use:
>>
>> (ebib--get-key-at-point)
>>
>>> and
>>>
>>>   (ebib-db-get-field-value 'title key ebib-cur-db)
>>
>> That one's easier:
>>(ebib-db-get-field-value "title" key ebib--cur-db)
>>
>>> "org-ebib.el" is already compatible with Org 9.0.
>>
>> Ah, good, I didn't realise that.
>>
>>> I'm Cc'ing the author. Ideally this library should be updated to new
>>> Ebib and moved to some ELPA.
>>>
>>> If Grégoire doesn't want to take care of it and no one volunteers to
>>> maintain that file, we can remove it.
>>
>> I was actually planning to add this functionality to Ebib itself. So
>> if Grégoire isn't interested in it anymore, I could put it in the Ebib
>> repo, or create a separate repo for it, either on Github or somewhere
>> else, wherever you prefer.
> 
> I received the following reply from Grégoire (which, although it was
> sent to the mailing list as well, apparently didn't show up there):
> 
> 
> ==
> 
> On 11/08/16 13:23, Nicolas Goaziou wrote:
>> I'm Cc'ing the author. Ideally this library should be updated to new
>> Ebib and moved to some ELPA.
>>
>> If Grégoire doesn't want to take care of it and no one volunteers to
>> maintain that file, we can remove it.
> 
> I don't use this package anymore.
> If anyone uses it, s/he take over it, otherwise we can just remove it
> from org-contrib.
> 
> ==
> 
> Like I said, I'd be happy to take over maintainance. Just let me know
> how to go about making it available to org-contrib. (If there is a way
> to keep the file in the main Ebib repository, that would be my preference.)

IMHO it's best if you can maintain org-ebib as part of ebib itself.
We can remove org-ebib from contrib and you can add it to ebib.

Best,

> Best,
> 
> Joost
> 
> 
> 
> 

Re: [O] Obsolete org contrib package

[daimrod]

On 11/08/16 13:23, Nicolas Goaziou wrote:
> Hello,
> 
> Joost Kremers  writes:
> 
>> I just ran into org-ebib.el, a file that's part of org-contrib.
>> I noticed that it uses functions from Ebib that were renamed pretty
>> much exactly two years ago. (They're internal functions and thus got
>> an extra dash.) This could in principle be fixed by changing the
>> relevant function calls in org-ebib.el, but as it happens I'm about to
>> push some changes to Ebib that will make it less straightorward to fix
>> org-ebib.el.
> 
> OK.
> 
> So you mean there is no equivalent to both
> 
>   (ebib-cur-entry-key)
> 
> and
> 
>   (ebib-db-get-field-value 'title key ebib-cur-db)
> 
> ?
> 
>> So perhaps it would be best to simply remove org-ebib.el from
>> org-contrib? It doesn't seem to have been used by anyone the past two
>> years and all it does is define a function to store an org link to an
>> Ebib entry, which, IIUC, is done in a completely different way in Org
>> 9.0.
> 
> "org-ebib.el" is already compatible with Org 9.0.
> 
> I'm Cc'ing the author. Ideally this library should be updated to new
> Ebib and moved to some ELPA.
> 
> If Grégoire doesn't want to take care of it and no one volunteers to
> maintain that file, we can remove it.

I don't use this package anymore.
If anyone uses it, s/he take over it, otherwise we can just remove it
from org-contrib.

Best,

> 
> We should at least wait for a week in any case.
> 
> Regards,
> 



signature.asc
Description: OpenPGP digital signature

Re: [O] match on any TODO state

[Daimrod]

Xebar Saram zelt...@gmail.com writes:

 Hi 
 I created this function which works well.

  (defun z/org-sparse-todo ()
     (interactive)
     (org-match-sparse-tree t +TODO=\TODO\))

 my question is how can i match on ANY todo state and not just literaly TODO
 ie if i have this in my org file 

 #+TODO: TODO(t) EXP(e) | SUBMITTED(s) K_TRACK(k) PAUSED(p) DONE(d) 

 how can i match it by all the todos like TODO and EXP

In the agenda match, I use TODO.
That is, all TODO keywords that aren't empty.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: Catch 'nextfile in org-contacts-db

[Daimrod]

phcrama.e...@gmx.com writes:

 Hi Nicolas and Greg,

Hi Philippe, sorry for the late reply :(

 Thank you for applying my initial patch.

 Inspired by Greg's improvements to my patch, I'd like to propose the attached 
 (presumptuously named) better-patch that I believe fixes the TODO of my 
 initial patch.

 Sorry it isn't quite in the format of the previous one/recommended by the 
 project but I'm not on my main machine now.

 --- org.elFri Jun 19 12:07:26 2015
 +++ org-modif.el  Wed Jun 24 09:13:10 2015
 @@ -18097,17 +18097,28 @@
  (defun org-file-menu-entry (file)
(vector file (list 'find-file file) t))
  
 -(defun org-check-agenda-file (file)
 -  Make sure FILE exists.  If not, ask user what to do.
 +(defun org-check-agenda-file-1 (file)
 +  Make sure FILE exists.  If not, ask user what to do.
 +
 +Possible outcomes:
 +1. File exists - return NIL.
 +2. File doesn't exist and user requests to remove it - throws 'nextfile.
 +3. File doesn't exist and user requests to remove it - raise error 
 \Abort\.
 +
 +You probably want `org-check-agenda-file'.
(when (not (file-exists-p file))
  (message Non-existent agenda file %s.  [R]emove from list or [A]bort?
(abbreviate-file-name file))
  (let ((r (downcase (read-char-exclusive
(cond
 ((equal r ?r)
 - (org-remove-file file)
   (throw 'nextfile t))
 (t (error Abort))

The 3. item looks wrong to me. I think it should be:
3. File doesn't exist and user requests to abort - raise error \Abort\.

 +(defun org-check-agenda-file (file)
 +  Make sure FILE exists, else if user agrees, remove FILE from 
 `org-agenda-files'.
 +  (when (catch 'nextfile (org-check-agenda-file-1 file))
 +(org-remove-file file)))
  
  (defun org-get-agenda-file-buffer (file)
Get a buffer visiting FILE.  If the buffer needs to be created, add
 
 
 --- org-contacts.el   Fri Jun 19 12:07:20 2015

Moreover, I'm not sure about changing the behaviour of an existing
function. Though the change looks good to me, it is very likely users
(or maybe even other parts of org-mode, I'haven't check) rely on it, and
expect to catch exceptions.

 +++ org-contacts-modif.el Wed Jun 24 09:13:56 2015
 [snip]

I agree with the modifications of org-contacts.el.


Maybe org-contacts.el should have its own version of
`org-check-agenda-file' (e.g. named `org-contacts-check-contacts-file')
until we find a better solution...

WDYT?


Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] org-log-reschedule: inactive time-stamp instead

[Daimrod]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 M elwood...@web.de writes:

 I wonder if I get something wrong, but in the variable org-log-note-headings
 I see

   Heading when rescheduling
   String: Rescheduled from %S on %t
 Shouldn't the %S represent a TODO state (which makes no sense)?

 %S represents the last state. If you change a TODO keyword, is also
 a TODO keyword (or lack thereof). If you alter a timestamp, it is that
 timestamp.

 Can I replace it by an inactive timestamp?

 Is there any use case for an active timestamp at this location anyway?
 If there is not, we could automatically convert it to an inactive
 timestamp.

 WDYT?

I don't have any use for an active location here. IMO it clutters the agenda
with senseless entries.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] org-log-reschedule: inactive time-stamp instead

[Daimrod]

M elwood...@web.de writes:

 Karl Voit devnull at Karl-Voit.at writes:
  Those active time-stamps clutter my daily agenda a bit. Therefore:
 
  ,[ what I would like to get ]
  | :LOGBOOK:
  | - Rescheduled from [2014-12-17 Mi] on [2014-12-16 Di 17:01]
  | :END:
  `
 
  So can someone please add an option for this variable to get
  inactive time-stamps?
 

 Hi Karl,
 did you find a solution in the meantime? I'm having the same problem and the
 active timestamps are also bothering me as rescheduled tasks which
 originally were scheduled for today stay in my daily agenda and clutter it.

 I wonder if I get something wrong, but in the variable org-log-note-headings
 I see

   Heading when rescheduling
   String: Rescheduled from %S on %t
 Shouldn't the %S represent a TODO state (which makes no sense)?
 Can I replace it by an inactive timestamp?

Hi,

I had the same problem and implemented a quick'n dirty solution :

(defun dmd-org-active-timestamp-to-inactive-when-rescheduled ()
  Convert some variable with active timestamp to inactive one.
  (when (eq org-log-note-purpose 'reschedule)
(setq org-log-note-previous-state
  (substitute ?\] ?\ (substitute ?\[ ?\ org-log-note-previous-state 
:test #'char-equal)
  :test #'char-equal

(add-hook 'org-log-buffer-setup-hook 
'dmd-org-active-timestamp-to-inactive-when-rescheduled)

It works for me but it should probably be fixed in org-mode itself.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Filters lost after reviving buried, sticky agenda

[Daimrod]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Daimrod daim...@gmail.com writes:

 Here is an updated version of the second patch :

 Both look good. Could you can push them. Thank you.

Done, thank you.

 Regards,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Filters lost after reviving buried, sticky agenda

[Daimrod]

Err, I should have tested it before sending the patch, sorry.

Here is an updated version of the second patch :

From 11ef3cc8dd804a9498edc856350d5e57d9ce3fff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr
Date: Tue, 23 Jun 2015 10:42:25 +0200
Subject: [PATCH 2/2] lisp/org-agenda.el: Fix non-persistent category filters
 in sticky agenda

* lisp/org-agenda.el (org-agenda-prepare): Use the correct key for
  category filter.

`org-agenda-prepare-window' uses 'cat whereas `org-agenda-prepare' used 'car.
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a07eead..32509a5 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3647,7 +3647,7 @@ FILTER-ALIST is an alist of filters we need to apply when
 			(list `(tag . ,org-agenda-tag-filter)
   `(re . ,org-agenda-regexp-filter)
   `(effort . ,org-agenda-effort-filter)
-  `(car . ,org-agenda-category-filter))
+  `(cat . ,org-agenda-category-filter))
 (if (org-agenda-use-sticky-p)
 	(progn
 	  (put 'org-agenda-tag-filter :preset-filter nil)
-- 
1.9.1


Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Filters lost after reviving buried, sticky agenda

[Daimrod]

Nick Dokos ndo...@gmail.com writes:

 What happened to the effort filter?

Good catch! Thanks.

Here is an updated patch plus another one to fix the regexp and category 
filters.

From 59cd3eb256d9473db42f9a1629755140c0d648cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr
Date: Fri, 12 Jun 2015 17:35:30 +0200
Subject: [PATCH 1/2] lisp/org-agenda.el : Fix non-persistent filters when
 refreshing sticky agenda

* lisp/org-agenda.el (org-agenda-prepare): Fix non-persistent filters when refreshing sticky agenda

When a sticky agenda is buried, then reviving and refreshing, existing
filters are ignored even when org-agenda-persistent-filter is `t'.

Reported and fixed by Daniel Borchmann
---
 lisp/org-agenda.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index f5d1022..a07eead 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3642,10 +3642,12 @@ FILTER-ALIST is an alist of filters we need to apply when
 
 (defun org-agenda-prepare (optional name)
   (let ((filter-alist (if org-agenda-persistent-filter
-			  (list `(tag . ,org-agenda-tag-filter)
-`(re . ,org-agenda-regexp-filter)
-`(effort . ,org-agenda-effort-filter)
-`(car . ,org-agenda-category-filter)
+			  (with-current-buffer
+			  (get-buffer-create org-agenda-buffer-name)
+			(list `(tag . ,org-agenda-tag-filter)
+  `(re . ,org-agenda-regexp-filter)
+  `(effort . ,org-agenda-effort-filter)
+  `(car . ,org-agenda-category-filter))
 (if (org-agenda-use-sticky-p)
 	(progn
 	  (put 'org-agenda-tag-filter :preset-filter nil)
-- 
1.9.1

From 3dc0e17b0887b182309696b2f790dac9ad3ca018 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr
Date: Tue, 23 Jun 2015 10:42:25 +0200
Subject: [PATCH 2/2] lisp/org-agenda.el: Fix non-persistent regexp and
 category filters in sticky agenda

* lisp/org-agenda.el (org-agenda-prepare): Use the correct key for
  category and regexp filters.

`org-agenda-finalize' uses 'regexp and 'category whereas
`org-agenda-prepare' used 're and 'car.
---
 lisp/org-agenda.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a07eead..8efc037 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3645,9 +3645,9 @@ FILTER-ALIST is an alist of filters we need to apply when
 			  (with-current-buffer
 			  (get-buffer-create org-agenda-buffer-name)
 			(list `(tag . ,org-agenda-tag-filter)
-  `(re . ,org-agenda-regexp-filter)
+  `(regexp . ,org-agenda-regexp-filter)
   `(effort . ,org-agenda-effort-filter)
-  `(car . ,org-agenda-category-filter))
+  `(category . ,org-agenda-category-filter))
 (if (org-agenda-use-sticky-p)
 	(progn
 	  (put 'org-agenda-tag-filter :preset-filter nil)
-- 
1.9.1




-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Filters lost after reviving buried, sticky agenda

[Daimrod]

Daniel Borchmann daniel.borchm...@tu-dresden.de writes:

 Dear all,

 I regularly lose all my filters when I bury a sticky agenda and revive
 it later.  In that case, the variable `org-agenda-tag-filter' is set to
 nil, although it was non-nil before burying.

 I played around a bit, and found out that `org-agenda-tag-filter' is
 buffer-local (which is not a surprise).  When the agenda buffer is
 revived, the function `org-agenda-prepare' is called, which, among
 others, should reset the filters (provided that
 `org-agenda-persistent-filter' is set).  The beginning of the function
 is

 ---8---
 (defun org-agenda-prepare (optional name)
   (let ((filter-alist (if org-agenda-persistent-filter
   (list `(tag . ,org-agenda-tag-filter)
 `(re . ,org-agenda-regexp-filter)
 `(car . ,org-agenda-category-filter)
   ...))
 ---8---

 It seems to me that `org-agenda-tag-filter' is read *before* the old
 agenda buffer is poped up (i.e., made current), and thus results in a
 `nil' value.  Indeed, if I replace the definition of `filter-alist' by

 ---8---
 (let ((filter-alist (if org-agenda-persistent-filter
 (with-current-buffer
 (get-buffer org-agenda-buffer-name)
   (list `(tag . ,org-agenda-tag-filter)
 `(re . ,org-agenda-regexp-filter)
 `(car . ,org-agenda-category-filter))
   ...)
 ---8---

 then the bug (seems to) disappear.

 My question is now: is this correct, or did I understand something
 wrong?  If my understanding is correct, how this bug be fixed more
 elegantly?

It doesn't work at startup when agenda hasn't been built yet. The
following patch does seem to fix that. If it's ok, I can push it.
From d2e8fef81585c249f33fa37260f6228709a67017 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr
Date: Fri, 12 Jun 2015 17:35:30 +0200
Subject: [PATCH] lisp/org-agenda.el : Fix non-persistent filters when
 refreshing sticky agenda

* lisp/org-agenda.el (org-agenda-prepare): Fix non-persistent filters when refreshing sticky agenda

When a sticky agenda is buried, then reviving and refreshing, existing
filters are ignored even when org-agenda-persistent-filter is `t'.

Reported and fixed by Daniel Borchmann
---
 lisp/org-agenda.el | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index f5d1022..3a1f5bc 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3642,10 +3642,11 @@ FILTER-ALIST is an alist of filters we need to apply when
 
 (defun org-agenda-prepare (optional name)
   (let ((filter-alist (if org-agenda-persistent-filter
-			  (list `(tag . ,org-agenda-tag-filter)
-`(re . ,org-agenda-regexp-filter)
-`(effort . ,org-agenda-effort-filter)
-`(car . ,org-agenda-category-filter)
+			  (with-current-buffer
+			  (get-buffer-create org-agenda-buffer-name)
+			(list `(tag . ,org-agenda-tag-filter)
+  `(re . ,org-agenda-regexp-filter)
+  `(car . ,org-agenda-category-filter))
 (if (org-agenda-use-sticky-p)
 	(progn
 	  (put 'org-agenda-tag-filter :preset-filter nil)
-- 
1.9.1


Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: Catch 'nextfile in org-contacts-db

[Daimrod]

Philippe Crama phcrama.e...@gmx.com writes:

 Hi,

Hello Philippe,

 This is a small patch to catch the 'nextfile thrown by
 `org-check-agenda-file' in `org-contacts-db'.

 I don't know how to fix the TODO in the comment myself, sorry.  At
 least, with the patch, the execution doesn't abort anymore.

Thanks for the report and the patch. I've attached a patch inspired by
yours. WDYT?

From b3bb252c6e2138fa65b7c960060d68ea8c260873 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr
Date: Mon, 15 Jun 2015 09:36:36 +0200
Subject: [PATCH] org-contacts.el: Handle missing files in `org-contacts-files'
 gracefully

* contrib/lisp/org-contacts.el (org-contacts-files): Catch 'nextfile
From `org-check-agenda-file' and update `org-contacts-files' if
modified.

(org-contacts-db): Don't call `org-check-agenda-file' now called in
`org-contacts-files'.

When `org-agenda-files' contains non-existent files, remove them if
the user asks for it instead of failing.

Modified from a patch proposal by Philippe Crama
---
 contrib/lisp/org-contacts.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el
index bc07fc1..3e14c7e 100644
--- a/contrib/lisp/org-contacts.el
+++ b/contrib/lisp/org-contacts.el
@@ -227,7 +227,12 @@ A regexp matching strings of whitespace, `,' and `;'.)
 
 (defun org-contacts-files ()
   Return list of Org files to use for contact management.
-  (or org-contacts-files (org-agenda-files t 'ifmode)))
+  (org-remove-if (lambda (file)
+		   (when (catch 'nextfile
+			   (org-check-agenda-file file))
+		 (customize-save-variable 'org-contacts-files
+	  (delete file org-contacts-files
+		 (or org-contacts-files (org-agenda-files t 'ifmode
 
 (defun org-contacts-db-need-update-p ()
   Determine whether `org-contacts-db' needs to be refreshed.
@@ -261,7 +266,6 @@ to dead or no buffer.
 	 (make-progress-reporter Updating Org Contacts Database... 0 (length org-contacts-files)))
 	(i 0))
 	(dolist (file (org-contacts-files))
-	  (org-check-agenda-file file)
 	  (with-current-buffer (org-get-agenda-file-buffer file)
 	(unless (eq major-mode 'org-mode)
 	  (error File %s is not in `org-mode' file))
-- 
1.9.1



 Regards,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Filters lost after reviving buried, sticky agenda

[Daimrod]

Daniel Borchmann daniel.borchm...@tu-dresden.de writes:

 ghItlhpu' Daimrod daim...@gmail.com:
 My question is now: is this correct, or did I understand something
 wrong?  If my understanding is correct, how this bug be fixed more
 elegantly?

 It doesn't work at startup when agenda hasn't been built yet. The
 following patch does seem to fix that. If it's ok, I can push it.

 It works for me.

Great! If nobody complains in the next days, I'll push it.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

[O] [BUG] Bad escape with Babel + org-mode

[Daimrod]

Hi,

I've encountered a bug when using org-mode in source blocks. I'm using
the latest version of org-mode from git:
Org-mode version 8.3beta (release_8.3beta-1195-g1a7364 [...])

I have no problem with the following snippet:
#+BEGIN_SRC org
,* test 1
,* test 2
,* test 3
,* test 4
,* test 5
,* test 6
,* test 7
,* test 8
,* test 9
,* test 10

#+END_SRC

But I have an error with this one when I hit C-' to go back to my org
file:

error in `org-escape-code-in-region' while: Invalid search bound (wrong side 
of point)
#+BEGIN_SRC org
,* test 1
,* test 2
,* test 3
,* test 4
,* test 5
,* test 6
,* test 7
,* test 8
,* test 9
,* test 10
,* test 11

#+END_SRC

And with the following snippet:
#+BEGIN_SRC org
,* test 1
,* test 2
,* test 3
,* test 4
,* test 5
,* test 6
,* test 7
,* test 8
,* test 9
,* test 10
,* test 11
,* test 12
#+END_SRC

When I hit C-' to go back to the org file the block isn't properly
escaped, it becomes:

#+BEGIN_SRC org
,* test 1
,* test 2
,* test 3
,* test 4
,* test 5
,* test 6
,* test 7
,* test 8
,* test 9
,* test 10
,* test 11
* test 12
#+END_SRC

I've tried to understand what's the problem and it looks like the
position returned by `re-search-forward' in `org-escape-code-in-region'
is wrong, but I don't know why. By wrong, I mean that the position
returned isn't immediately after the expression found but slightly
after, and the error increases which is why it doesn't fail with 10
items or less.

e.g.
* test 1
 ^ point
* test 2
  ^ point
* test 3
   ^ point
...

Best,

--
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [BUG] Bad escape with Babel + org-mode

[Daimrod]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I've encountered a bug when using org-mode in source blocks. I'm using
 the latest version of org-mode from git:
 Org-mode version 8.3beta (release_8.3beta-1195-g1a7364 [...])

 I have no problem with the following snippet:
 #+BEGIN_SRC org
 ,* test 1
 ,* test 2
 ,* test 3
 ,* test 4
 ,* test 5
 ,* test 6
 ,* test 7
 ,* test 8
 ,* test 9
 ,* test 10

 #+END_SRC

 But I have an error with this one when I hit C-' to go back to my org
 file:

 error in `org-escape-code-in-region' while: Invalid search bound (wrong 
 side of point)
 #+BEGIN_SRC org
 ,* test 1
 ,* test 2
 ,* test 3
 ,* test 4
 ,* test 5
 ,* test 6
 ,* test 7
 ,* test 8
 ,* test 9
 ,* test 10
 ,* test 11

 #+END_SRC

 And with the following snippet:
 #+BEGIN_SRC org
 ,* test 1
 ,* test 2
 ,* test 3
 ,* test 4
 ,* test 5
 ,* test 6
 ,* test 7
 ,* test 8
 ,* test 9
 ,* test 10
 ,* test 11
 ,* test 12
 #+END_SRC

 When I hit C-' to go back to the org file the block isn't properly
 escaped, it becomes:

 #+BEGIN_SRC org
 ,* test 1
 ,* test 2
 ,* test 3
 ,* test 4
 ,* test 5
 ,* test 6
 ,* test 7
 ,* test 8
 ,* test 9
 ,* test 10
 ,* test 11
 * test 12
 #+END_SRC

 Fixed in f91d194d4fe4644de9cac94a807a08c220ab521d. Thank you.

Confirmed.

Thanks !

 Regards,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

[O] ':post' Direct execution via Emacs Lisp

[Daimrod]

Hi,

We can read in the manual:
14.8.2.25 ‘:post’

The ‘:post’ header argument is used to post-process the results of a
code block execution.  When a post argument is given, the results of the
code block will temporarily be bound to the ‘*this*’ variable.  This
variable may then be included in header argument forms such as those
used in *note var:: header argument specifications allowing passing of
results to other code blocks, or direct execution via Emacs Lisp.
 ^^^

IIUC, it means that we can post process the data in Emacs Lisp, that is,
by calling an Emacs Lisp function, not another source block. However,
the example only shows how to do it with another source block.

Is my understanding correct or not? If so, how can I post process the
result with an Emacs Lisp function?

Cheers,

-- 
Daimrod/Greg

Re: [O] Extra empty line at the top of the page when tangling.

[Daimrod]

Ivanov Dmitry usr...@gmail.com writes:

Hi,

 Code:

 #+BABEL: :cache yes :tangle yes :noweb yes

 #+NAME: top_block
 #+begin_src perl :tangle test.pl :noweb tangle

From (info (org) padline):
 14.8.2.10 ‘:padline’
 
 
 Control in insertion of padding lines around code block bodies in
 tangled code files.  The default value is ‘yes’ which results in
 insertion of newlines before and after each tangled code block.  The
 following arguments are accepted.
 
• ‘yes’ Insert newlines before and after each code block body in
  tangled code files.
• ‘no’ Do not insert any newline padding in tangled output.

You can use the following block declaration:
#+begin_src perl :tangle test.pl :noweb tangle :padline no

   #!/usr/bin/perl

   use strict;
   use warnings;

   open(my $fh, , test.txt)
   or die cannot open  file name: $!;
   output-all
   close($fh);
 #+end_src

 #+NAME: output-all
 #+begin_src perl
   while (my $line = $fh) {
   print $line;
   }
 #+end_src

 Outputs a perl file, where the 1-st line is blank. What should I do to remove 
 it?

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Link to named block

[Daimrod]

Bastien b...@gnu.org writes:

 Hi Greg,

Hi Bastien,

 Daimrod daim...@gmail.com writes:

 I've made a small function to link to a named block in org files.

 #+BEGIN_SRC emacs-lisp
 (defun dmd--org-link-to-named-block ()
   Create an org-link to the named block at point.

 Blocks are named with #+NAME.
   (when (eq major-mode 'org-mode)
 (let* ((el (org-element-at-point))
(name (org-element-property :name el)))
   (when name
 (org-store-link-props
  :link name)
 #+END_SRC

 Do you think it should be added to org? I find it useful to add a link
 to a figure when I'm exporting to latex.

 I'm not sure how to use the function above -- how do you set the link
 itself, not just its properties?

I don't. The link name is enough because named block usually have nice
name. For example, given the following named block:

#+NAME: fig:my-fig
[[file:my-fig.png]]

Then link will be [[fig:my-fig]].

 I tried to add it to `org-store-link` but it's a big function and I
 wonder why it's not splitted in smaller functions. (e.g.
 org-help-store-link, org-w3-store-link, org-image-store-link, ...).
 If you agree, I could split it.

 Yes, please go ahead.

noted.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

[O] Link to named block

[Daimrod]

Hi,

I've made a small function to link to a named block in org files.
#+BEGIN_SRC emacs-lisp
(defun dmd--org-link-to-named-block ()
  Create an org-link to the named block at point.

Blocks are named with #+NAME.
  (when (eq major-mode 'org-mode)
(let* ((el (org-element-at-point))
   (name (org-element-property :name el)))
  (when name
(org-store-link-props
 :link name)
#+END_SRC

Do you think it should be added to org? I find it useful to add a link
to a figure when I'm exporting to latex.

I tried to add it to `org-store-link` but it's a big function and I
wonder why it's not splitted in smaller functions. (e.g.
org-help-store-link, org-w3-store-link, org-image-store-link, ...).
If you agree, I could split it.

WDYT?

Best,

--
Daimrod/Greg


signature.asc
Description: PGP signature

[O] Help on org-export-filter-link-functions

[Daimrod]

Hi,

I've wrote a simple filter to customize how links are exported in
latex:
#+BEGIN_SRC
(defun dmd--latex-bib-link-filter (data backend info)
  Convert a bib link to a citation (e.g. bib:foo93 - \cite{foo93}).
  (let* ((beg (next-property-change 0 data))
 (link (if beg (get-text-property beg :parent data
(cond ((and link
(org-export-derived-backend-p backend 'latex)
(string= (org-element-property :type link) bib))
   (format \\cite{%s} (org-element-property :path link)))
  ((and link
(org-export-derived-backend-p backend 'latex)
(string= (org-element-property :type link) file)
(string= (org-element-property :path link) ~/.bib.bib))
   (format \\cite{%s} (org-element-property :search-option link)))
  (t data
#+END_SRC

And I was wondering whether there is an easier way to retrieve the org
properties stored in the text properties of DATA.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] doing a capture and jumping to the file

[Daimrod]

Alan Schmitt alan.schm...@polytechnique.org writes:

 Hello,

Hello Alan,

 I often find myself doing the following: use a capture template to
 nicely setup an entry (often a date tree entry with a link to the
 current document), then jump to the newly created headline to start
 adding notes. I typically do this during meetings, as I do not want to
 stay in the capture buffer all the time.

 Is there a way to setup a capture template such that it directly opens
 the target file and set-up entry, instead of the capture buffer?

 I tried a universal argument before calling org-capture, but it only
 jumps to the capture destination and does not set up the entry.

You can customize your capture templates with `M-x org-capture RET C'.
Look especially at the plist keywords `:immediate-finish` and
`:jump-to-captured`.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] org-elements-parse-buffer and weird property drawers

[Daimrod]

Eike e...@eknet.org writes:

 Hello,

 Nicolas Goaziou writes:
 Eike n...@eknet.org writes:

 I'm playing with the functions in org-elements.el and the following
 effect seems strange to me:

 I have a few propery drawers with empty propertys, like

 #+BEGIN_EXAMPLE
 :PROPERTIES:
 :date: [2014-08-29 Fr]
 :chf:  21.76
 :eur:
 :END:
 #+END_EXAMPLE

 If I do org-elements-parse-buffer, the empty one is not there, but the
 first one is duplicated. At least, there are two node-property
 elements in the tree like that:

 #+BEGIN_EXAMPLE
 (node-property (:key chf :value 21.76 :begin 38 :end 58 :post-blank 0 
 :post-affiliated 38 :parent #4))
 (node-property (:key chf :value 21.76 :begin 58 :end 67 :post-blank 0 
 :post-affiliated 58 :parent #4))
 #+END_EXAMPLE

 The function call was this:

 #+begin_src emacs-lisp
 (with-current-buffer test-exp.org
   (org-element-parse-buffer))
 #+end_src

 And here is the test-exp.org org file:

 #+BEGIN_EXAMPLE
 * Sonstiges
 ** Pizza
:PROPERTIES:
:chf:  21.76
:eur:
:END:
 #+END_EXAMPLE

 This should be fixed. Thank you for reporting it.

 Many thanks! It works here now.

Hi,

Since the change to `org-re-property' I have problems to display org
files. My *Message* buffer is spammed with the following error:

Error during redisplay: (jit-lock-function 1119) signaled (error No match 3 in 
highlight (3 (quote org-property-value) t))
    this number changes

I know the problem lies in org-re-property because if I revert the
change, it works as it did before.

Test file:
* TODO Test
  :PROPERTIES:
  :TEST: test
  :END:


Best,

--
Daimrod/Greg

Re: [O] org-elements-parse-buffer and weird property drawers

[Daimrod]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 Since the change to `org-re-property' I have problems to display org
 files. My *Message* buffer is spammed with the following error:

 Error during redisplay: (jit-lock-function 1119) signaled (error No match 3 
 in highlight (3 (quote org-property-value) t))
 this number changes

 Fixed. Thank you.

It works, thanks.

 Regards,

-- 
Daimrod/Greg

Re: [O] [PATCH] docstring improvement of org-agenda-refile

[Daimrod]

Charles Millar mill...@verizon.net writes:

 Charles Millar wrote:
 Daimrod wrote:
 +When GOTO is '(14) or \\[universal-argument]
 \\[universal-argument], go to the location of the last refiled
 item.
 ^^
  '(16)
 Just opened my own reply and the '(16) may be misaligned.

Good catch.

I've applied the patch with the correction.

--
Daimrod/Greg

Re: [O] Tab completion for link to file

[Daimrod]

Chris Henderson henders...@gmail.com writes:

Hi Chris,

 How can I get auto tab completion for links to files?

Is C-u C-c C-l what you're looking for?

From the *Help* of `org-insert-link':
 With a C-u prefix, prompts for a file to link to.  The file name can
 be selected using completion.



 e.g. [[file+sys:///Users/chris/projects/marketing 2014]]

 Thanks.

-- 
Daimrod/Greg

[O] [PATCH] docstring improvement of org-agenda-refile

[Daimrod]

Hi,

Here is a small patch to improve the docstring of `org-agenda-refile'.
Can I apply it?

From acd2830755849a055ce46a34b65af89b9547fcb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com
Date: Sun, 10 Aug 2014 01:41:16 +0200
Subject: [PATCH] lisp/org-agenda.el (org-agenda-refile): Documentation
 improvement

* lisp/org-agenda.el (org-agenda-refile): State explicitly that
  '(16) = C-u C-u and that '(64) = C-u C-u C-u.
---
 lisp/org-agenda.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 3919328..8244eeb 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8475,8 +8475,8 @@ If this information is not given, the function uses the tree at point.
 (defun org-agenda-refile (optional goto rfloc no-update)
   Refile the item at point.
 
-When GOTO is 0 or '(64), clear the refile cache.
-When GOTO is '(16), go to the location of the last refiled item.
+When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] \\[universal-argument], clear the refile cache.
+When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item.
 RFLOC can be a refile location obtained in a different way.
 When NO-UPDATE is non-nil, don't redo the agenda buffer.
   (interactive P)
-- 
1.8.0.2722.gc0242e5


-- 
Daimrod/Greg

[O] [PATCH] docstring improvement of org-agenda-refile

[Daimrod]

Hi,

Here is a small patch to improve the docstring of `org-agenda-refile'.
Can I apply it?

From acd2830755849a055ce46a34b65af89b9547fcb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com
Date: Sun, 10 Aug 2014 01:41:16 +0200
Subject: [PATCH] lisp/org-agenda.el (org-agenda-refile): Documentation
 improvement

* lisp/org-agenda.el (org-agenda-refile): State explicitly that
  '(16) = C-u C-u and that '(64) = C-u C-u C-u.
---
 lisp/org-agenda.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 3919328..8244eeb 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8475,8 +8475,8 @@ If this information is not given, the function uses the tree at point.
 (defun org-agenda-refile (optional goto rfloc no-update)
   Refile the item at point.
 
-When GOTO is 0 or '(64), clear the refile cache.
-When GOTO is '(16), go to the location of the last refiled item.
+When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] \\[universal-argument], clear the refile cache.
+When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item.
 RFLOC can be a refile location obtained in a different way.
 When NO-UPDATE is non-nil, don't redo the agenda buffer.
   (interactive P)
-- 
1.8.0.2722.gc0242e5


-- 
Daimrod/Greg

[O] [feature request] Matching tags and properties

[Daimrod]

Hi all,

ATM, it is possible to look for date in properties using special
keywords such as now, today and tomorrow. Unfortunately, the last
two keywords doesn't match on timestamps that include time information.

e.g. [2014-08-04 Mon] can be matched, but not [2014-08-04 Mon 21:20].

I think it would make sense to allow the later to be matched with
today, that is, to ignore time information.

WDYT?

-- 
Daimrod/Greg

Re: [O] per file org-todo-keywords?

[Daimrod]

Xebar Saram zelt...@gmail.com writes:

 Hi all

Hi,

 i would like to know if its possible to have per file org-todo-keywords? i 
 know you can have custom TODO states in the top of the file/buffer but
 then you loose the fast access to TODO states tight?

No, it still works.

 currently i have something like this:

 (setq org-todo-keywords (quote ((sequence TODO(t) NEXT(n) | DONE(d)) 
 (sequence WAITING(w@/!) HOLD(h@/!) | CANCELLED(c@/!)  

 but i woud like different  TODO keywords for specific file that i can use 
 fast access for

 any ideas?

It's all in the documentation. see (info (org) Tracking TODO state changes)

You can use the exact same syntax for setting logging preferences
 local to a buffer:
  #+TODO: TODO(t) WAIT(w@/!) | DONE(d!) CANCELED(c@)

-- 
Daimrod/Greg

Re: [O] org-contact Export

[Daimrod]

Esben Stien b...@esben-stien.name writes:

 Daimrod daim...@gmail.com writes:

 It wasn't possible, but it is now. I've slightly modified
 `org-contacts-export-as-vcard' so that it will prompt for a user name
 when called with a prefix argument.

 This is in git?
Yes.

 The new function's behovior when called interactively is the following:
 1. no prefix : do as before, export all contacts to
   `org-contacts-vcard-file'.
 2. C-u : prompt for a contact name and use the contact at point if it
   exists, then export the matching contacts to
   `org-contacts-vcard-file'.
 3. C-u C-u : same as 2. but prompt for a file name where to export
instead of `org-contacts-vcard-file'.
 4. C-u C-u C-u : same as 3. but prompt for a buffer name instead of a
file name.

 How about export to kill-ring?

Do you mean in the kill-ring instead of the buffer? or with another
prefix level (C-u C-u C-u C-u)?

-- 
Daimrod/Greg

Re: [O] org-contact Export

[Daimrod]

Esben Stien b...@esben-stien.name writes:

Hello Esben,

 Is there any way to retrieve a single org-contact as CSV or maybe a VCF
 file?

 I know I can export all of them, but is there a function to get just the
 one under point?

It wasn't possible, but it is now. I've slightly modified
`org-contacts-export-as-vcard' so that it will prompt for a user name
when called with a prefix argument.

The new function's behovior when called interactively is the following:
1. no prefix : do as before, export all contacts to
  `org-contacts-vcard-file'.
2. C-u : prompt for a contact name and use the contact at point if it
  exists, then export the matching contacts to
  `org-contacts-vcard-file'.
3. C-u C-u : same as 2. but prompt for a file name where to export
   instead of `org-contacts-vcard-file'.
4. C-u C-u C-u : same as 3. but prompt for a buffer name instead of a
   file name.

When the function isn't called interactively it behaves as it did
before.

WDYT?

Best,

--
Daimrod/Greg

Re: [O] Bug: org-contacts show Non-existent agenda file ~/org/* virexit. [R]emove from list or [A]bort? when trying to find contacts with M-x org-contactsRET [8.2.7b (8.2.7b-dist @ c:/Users/Seam/A

[Daimrod]

seamw...@gmail.com writes:

 I put my captured contacts to ~/.orgmode/data/contact.org and I can
 successfully capture the contacts, however, when I eval the function
 org-contacts in org mode, it just shows the message in the title.

 if the contact file is empty, it does not show the message, but org-contacts
 show an empty match.

--
 org-contacts show Non-existent agenda file ~/org/* virexit. [R]emove
 from list or [A]bort? when trying to find contacts with M-x
 org-contactsRET [8.2.7b (8.2.7b-dist @
 c:/Users/Seam/AppData/Roaming/.emacs.d/orgmode/lisp/)]
--

It looks like you had added a file named '* virexit' to the agenda list,
but that file doesn't exist anymore.

`org-contacts' uses the agenda views to display contacts. I don't know
the internals of `org-agenda' very well but I guess that it checks for
agenda files even if the caller doesn't need them, hence the error.

I don't know (yet) if it's possible to disable this behavior, but in the
meantime you can remove the file from the agenda list.

Best,

-- 
Daimrod/Greg

Re: [O] how to hide titles marked with DONE

[Daimrod]

bofe hust.hu...@gmail.com writes:

 Hi,
   I use org to manage my projects. When some works are finished ,I
 marked the titles “DONE”,but as time goes by ,there are too many of
 them, that I can’t focus on the rest of unfinished works.
   Is there a way to hide the “DONE titles,rather than delete them?

You can toggle the archive tag (C-c C-x a) or archive the tasks
(C-c C-x C-a).

-- 
Daimrod/Greg

Re: [O] org-contacts email completion by tags

[Daimrod]

Daimrod daim...@gmail.com writes:

 Thanks, but I'm refactoring org-contacts a bit, and I think I have found
 a slightly better way to do that, but in the meantime you can use the
 aforementioned hook for your function.

It turns out that my idea was wrong, so I have used a version very
similar to yours.

The function is triggered by the prefix '#' (customizable) and can be
used to match tags and properties.
e.g. the following expression:
#work-phdBIRTHDAY
will look for contacts with the tag 'work' but not the tag 'phd' and for
which there is a BIRTHDAY properties.

Best,

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Matt Lundin m...@imapmail.org writes:

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 With the latest git, I've experienced three lock-ups/freezes this
 evening when a) archiving a subtree to a file, b) changing a todo state
 with repeating timestamp, and 3) calling C-c C-c in an org-capture
 buffer. (I don't think this is due to a recent change - I've been
 running into these lockups sporadically for several months.)

 The freezes are very difficult to replicate reliably. When they happen,
 emacs is unresponsive and can only be killed from the outside. Any tips
 on how to debug this would be greatly appreciated.

See my previous post:
http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263

You can wrap `jit-lock--debug-fontify' with:

(advice-add 'jit-lock--debug-fontify :around
(lambda (fun rest args)
  (with-local-quit (apply fun args

and then force emacs to break and display a backtrace by sending the
SIGUSR2 to the emacs process.

Best,

--
Daimrod/Greg

Re: [O] org-contacts email completion by tags

[Daimrod]

John Kitchin jkitc...@andrew.cmu.edu writes:

Hi,

First, sorry for the late reply.

 Here is what I finally ended up with to allow completion with tag
 expressions. I did not figure out how to avoid overwriting an
 org-contacts function. I thought I could find the right hooks to use,
 but I could not figure it out. It is only a one line modification to the
 org-contacts function.

I've added a new hook `org-contacts-complete-functions' that you can use
to plug your function.

 This works for tag expressions, but I have not
 gotten it to work with properties.

 (defun org-contacts-complete-tags (start end tag-expression)
   insert emails from org-contacts that match the tags expression. For 
 example:
 group-phd will match entries tagged with group but not with phd.
   (let* ((completion-ignore-case org-contacts-completion-ignore-case)
(group-completion-p t))
 (let ((result (mapconcat 'identity
(loop for contact in (org-contacts-db)
  for contact-name = (car contact)
  for email = (org-contacts-strip-link (car 
 (org-contacts-split-property
 (or
  (cdr 
 (assoc-string org-contacts-email-property
   
   (caddr contact)))
  
  for tags = (cdr (assoc TAGS (nth 2 contact)))
  for tags-list = (if tags
  (split-string (substring (cdr 
 (assoc TAGS (nth 2 contact))) 1 -1) :)
'())
  if (let ((todo-only nil))
   (eval (cdr (org-make-tags-matcher 
 tag-expression
  
  collect (org-contacts-format-email contact-name 
 email))
,)))
   (when (not (string=  result))
   ;; return (start end function)
   (lexical-let* ((to-return result))
 (list start end
   (lambda (string pred optional to-ignore) to-return)))


Thanks, but I'm refactoring org-contacts a bit, and I think I have found
a slightly better way to do that, but in the meantime you can use the
aforementioned hook for your function.

Best,

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Daimrod daim...@gmail.com writes:

 My guess is that the lockup happens in `org-element--cache-key-less-p',
 called by `org-element--cache-process-request'.

 Probably, but it doesn't mean that this particular function is buggy.
 The lockup happens there because the cache gets corrupted at some point.

I see.

 After investigating a little while, it appears that switching
 input-method to latin-postfix alone is sufficient to corrupt it.
 Though, setting `org-element-cache-sync-idle-time' to a high value
 prevents the problem, which means that the corruption happens only when
 cache is synchronized during idle time.

Ok.

 That's where I am for the time being. I don't know much about input
 methods, so I have no clue about the reasons behind this. I'm still
 investigating.

I would help if I knew about input-methods or the caching mechanism, but
I do not. :-(

Thanks for investigating.

Best,

-- 
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message

[Daimrod]

Bastien b...@gnu.org writes:

 Nicolas Richard theonewiththeevill...@yahoo.fr writes:

 Perhaps this isn't the right place to ask, but I wonder how
 (save-excursion (set-window-start (selected-window) (window-start)))
 isn't a noop.

 Perhaps it is a noop -- The purpose of `org-fix-ellipsis-at-bol'
 is to remove the ellipsis overlay that outline-mode may leave
 when navigating through folded regions.  At least this was the
 purpose of the original version, and using recenter did the
 job.  I'll try to reproduce the original bug, see if the new
 version of `org-fix-ellipsis-at-bol' does the job and if not,
 why.

In `org-fix-ellipsis-at-bol', the change wasn't
: (save-excursion (set-window-start (selected-window) (window-start)))

but
: (save-excursion (set-window-start (selected-window) (point-min)))

which is not a noop.

But it does the wrong thing with isearch.

When isearch is done, that is, when it has found a match and we leave
isearch with RET for example. Then it calls `isearch-done' which runs
`org-fix-ellipsis-at-bol' because it is in `isearch-mode-end-hook' (I
didn't look to find why).

Because of this, if the pattern found isn't at the top of the buffer,
then the point won't be at the pattern, but at the top of the buffer.

Best,

--
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message

[Daimrod]

Nicolas Richard theonewiththeevill...@yahoo.fr writes:

 Daimrod daim...@gmail.com writes:
 PS: The change about throwing an error when recentering a window
 that does not display the current buffer breaks ~37 tests in Org
 master branch, even with this fix.  I need to digg this further.

 Err, what's the rational behind this change?

 It is meant to catch cases where recenter acts on the wrong window.
 Think of the cases where (recenter) is called from within a timer or a
 process filter function.

 See the discussion entitled
 comint-preoutput-filter-functions and flickering redisplay in TTY
 on emacs devel.

Thanks!

-- 
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message

[Daimrod]

Daimrod daim...@gmail.com writes:

 Nicolas Richard theonewiththeevill...@yahoo.fr writes:

 Daimrod daim...@gmail.com writes:
 PS: The change about throwing an error when recentering a window
 that does not display the current buffer breaks ~37 tests in Org
 master branch, even with this fix.  I need to digg this further.

 Err, what's the rational behind this change?

 It is meant to catch cases where recenter acts on the wrong window.
 Think of the cases where (recenter) is called from within a timer or a
 process filter function.

 See the discussion entitled
 comint-preoutput-filter-functions and flickering redisplay in TTY
 on emacs devel.

 Thanks!

Okay, so is there another fix than `(when (eq (current-buffer)
(window-buffer)))' or removing the call?

If not, why does it raise an error instead of doing nothing silently?

Best,

-- 
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message

[Daimrod]

Daimrod daim...@gmail.com writes:

 Daimrod daim...@gmail.com writes:

 Nicolas Richard theonewiththeevill...@yahoo.fr writes:

 Daimrod daim...@gmail.com writes:
 PS: The change about throwing an error when recentering a window
 that does not display the current buffer breaks ~37 tests in Org
 master branch, even with this fix.  I need to digg this further.

 Err, what's the rational behind this change?

 It is meant to catch cases where recenter acts on the wrong window.
 Think of the cases where (recenter) is called from within a timer or a
 process filter function.

 See the discussion entitled
 comint-preoutput-filter-functions and flickering redisplay in TTY
 on emacs devel.

 Thanks!

 Okay, so is there another fix than `(when (eq (current-buffer)
 (window-buffer)))' or removing the call?

 If not, why does it raise an error instead of doing nothing silently?

I've read the fix in org-mode and I understand that it was a silly
question. Please ignore it.

Best,

-- 
Daimrod/Greg

Re: [O] can show inline images anymore in orgmode

[Daimrod]

Xebar Saram zelt...@gmail.com writes:

 Hi all
Hi,

 i have a weird problem. in the last few weeks i cant get orgmode to show 
 inline images anymore. when i use org-toggle-inline-images i get the
 following error:

 progn: Wrong type argument: stringp, nil [2 times]

 can anyone help me to debug this?

1. M-x toggle-debug-on-error RET
2. report the backtrace

FWIW, I don't have this error using the latest version (HEAD) of
org-mode.

Regards,

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Daimrod daim...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I've attached part of the traces (the whole traces are way too big) and
 the backtraces.

 Thanks for looking into this. However, you are running a compiled Org,
 which renders backtraces less useful.

 Ok, I was wondering why the backtraces was so ugly, I didn't think about
 byte-compilation... Thanks for the tip.

 Also, you may want to disable cache refresh on idle time with, e.g.,

   (setq org-element-cache-sync-idle-time 3600)

 It could make the bug easier to reproduce.

 Thanks, I'll try again this w.e.

Okay, so I've found a more or less reliable way to reproduce this bug (on my
machine at least).

1. $ emacs -Q -l debug.el test.org
2. Expand headline (S-TAB)
3. go below the first headline (C-n)
4. press `i' a couple of seconds ~10 chars
5. delete the line (C-a C-k)
6. goto 4 until if locks up

As I said, it's not completely reliable but so far the lockup always
happens. Sometimes it happens after the third iteration, sometimes after
the tenth iteration, but it always happen.

I've attached `debug.el' and `test.org'.

`debug.el' setup the environment to reproduce the bug, you may need to
change the path to your orgmode source base and you'll need
`adaptive-wrap-prefix-mode' (available on ELPA).

I've been able to reproduce the bug without `adaptive-wrap-prefix-mode'
though other people have reported the same symptoms without using it.


`test.org' is a simple org file with two headlines. It seems that two
headlines are required to trigger the cache mechanism (with
`org-element-cache--sync').


Do you confirm the lockup with this setting?

Best,


* i

* i
i


debug.el
Description: application/emacs-lisp


-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 Okay, so I've found a more or less reliable way to reproduce this bug (on my
 machine at least).

 1. $ emacs -Q -l debug.el test.org
 2. Expand headline (S-TAB)
 3. go below the first headline (C-n)
 4. press `i' a couple of seconds ~10 chars
 5. delete the line (C-a C-k)
 6. goto 4 until if locks up

 As I said, it's not completely reliable but so far the lockup always
 happens. Sometimes it happens after the third iteration, sometimes after
 the tenth iteration, but it always happen.

 I've attached `debug.el' and `test.org'.


 [...]

 Do you confirm the lockup with this setting?

 Yes, I do. I will investigate on this soon. Thank you for providing this
 recipe.

Cool!

Also, I should have mentioned that I didn't trace the function
`org-element--cache-key-less-p' because when I do so, Emacs stays locked
even when I send it the signal SIGUSR2. However, this function appears
in the backtrace produced by `xbacktrace' in a gdb session if I call it
during a lockup.

My guess is that the lockup happens in `org-element--cache-key-less-p',
called by `org-element--cache-process-request'.

Best,

-- 
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message

[Daimrod]

 @@ package ox-bibtex by Taru Karttunen.
 (call-interactively 'reftex-citation)))
 
  Functions extending outline functionality
+(defun org-recenter (optional arg)
+  Like `recenter' but ensure that the `current-buffer' is
+properly set.
+  (with-current-buffer (window-buffer)
+(recenter arg)))
 
 (defun org-beginning-of-line (optional arg)
   Go to the beginning of the current line.  If that is invisible, continue
-- 
1.8.0.2722.gc0242e5


-- 
Daimrod/Greg

[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message

[Daimrod]

Stefan Monnier monn...@iro.umontreal.ca writes:

 +(defun org-recenter (optional arg)
 +  Like `recenter' but ensure that the `current-buffer' is
 +properly set.
 +  (with-current-buffer (window-buffer)
 +(recenter arg)))
  
 This doesn't make much sense: in many case (window-buffer) can be
 a buffer completely unrelated to Org.

Hmm, what was the previous behaviour of `recenter'? (i.e. before it
reports an error)

Did it just do nothing?

Best,

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Eric Abrahamsen e...@ericabrahamsen.net writes:

 Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 [...]

 By the way, if you want to see in which part the infloop occurs, you can
 attach a gdb debugger to the running emacs, source the
 path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

 $ gdb path-to-emacs-executable emacs-pid
 gdb) source path-to-emacs-source/src/.gdbinit
 ...
 gdb) xbacktrace

 You can also use the `bt' command but it contains much more noise.

 I got another one just now (while moving from one org table cell to the
 next), and that was the gdb backtrace:

 avl-tree--do-delete (0xbfffe858)
 avl-tree-delete (0xbfffe998)
 byte-code (0xbfffeaa0)
 byte-code (0xbfffec30)
 org-element--cache-process-request (0xbfffedd8)
 byte-code (0xbfffeef0)
 org-element--cache-sync (0xb0a8)
 org-element-at-point (0xb1e8)
 org-mode-flyspell-verify (0xb338)
 flyspell-word (0xb478)
 byte-code (0xb580)
 flyspell-post-command-hook (0xb784)

It seems the lockup also happens in `org-element--cache-...'.

 Not much, and probably not that useful. I'll start running org
 uncompiled, and try the debug-on-event trick.

Thanks for you time!

 FWIW, this was the first lockup that *didn't* occur in a logbook
 drawer -- that's where I usually get them. Either a full lockup, or else
 the cache goes wonky so that adding log notes (or even just navigating
 in the drawer) gives me that bound on wrong side of point you get when
 you try to search forwards, backwards.

That's weird (in my cases it usually mess up with the input-method).

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I've attached part of the traces (the whole traces are way too big) and
 the backtraces.

 Thanks for looking into this. However, you are running a compiled Org,
 which renders backtraces less useful.

Ok, I was wondering why the backtraces was so ugly, I didn't think about
byte-compilation... Thanks for the tip.

 Also, you may want to disable cache refresh on idle time with, e.g.,

   (setq org-element-cache-sync-idle-time 3600)

 It could make the bug easier to reproduce.

Thanks, I'll try again this w.e.

Best,

-- 
Daimrod/Greg

[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

We can probably close this bug.

I haven't been able to reproduce it with the org-mode bundled with the
pretest version.

Sorry for the noise.

Regards,

-- 
Daimrod/Greg

Re: [O] org-contacts development

[Daimrod]

Michael Strey mst...@strey.biz writes:
Hi Michael,

 Reading http://orgmode.org/worg/dev/org-syntax.html#Node_Properties
 I just realised that my clumsy property keys are against the rules since
 they are containing whitespace characters.

 Nevertheless I still like the idea of having a Type, a number and a
 Value for every property that can occur multiple.  Thus the properties
 can be easily mapped to the VCard scheme as well as to any other scheme.

 Thus, what I would like to propose is the following scheme:


 #+BEGIN_SRC org
 :PROPERTIES:
 :Contact_Type: individual or organisation
 :Organization_1_Type: company
 :Organization_1_Name: The company name
 :Organization_1_Department: department, business unit, division
 :Organization_1_Title: job title of an individual
 :FN: The full name
 :GivenName:
 :FamilyName:
 :Name_Prefix:
 :Name_Suffix:
 :Nickname:
 :Email_1_Type: Work
 :Email_1_Value: n...@company.fr
 :Address_1_Type: Work
 :Address_1_Street: The street can contain multiple lines \\ second line
 :Address_1_Box: Postal box
 :Address_1_Extension: other extensions that can occur in addresses
 :Address_1_City: The city
 :Address_1_Region: Region, federal state etc.
 :Address_1_Code: 12100
 :Address_1_Country: France
 :Phone_1_Type: Work
 :Phone_1_Value: +33 565 623740
 :Phone_2_Type: Fax
 :Phone_2_Value: +33 565 623070
 :Website_1_Type: Work
 :Website_1_Value: http://www.domain.fr
 :Birthday:
 :Language: en
 :Salutation:
 :END:
 #+END_SRC


Hmm, I kinda like this. It seems a bit verbose but it's better than
having multiple values per properties (IMHO).

Though, if we adopt this scheme, we would need to add some helper
bindings/functions so that we don't have to fill this by hands.

 Other user defined properties can be added and mapped to the appropriate
 user defined keys during export.

I'm not sure to understand what you mean. Could you give more details
and maybe an example?


 [snip]

 Please note that org-collector tries to convert property values from
 strings into numbers if possible.  For postal codes with leading Zeros
 this can lead to unexpected results.  I did not find any other way to
 solve this problem than to add a national code like in the following
 example

 :Address_1_Code:  01169
 would lead to 1169 in the propview table.

 so I replaced it with
 :Address_1_Code:  DE-01169

What is `org-collector' and when does it happen?

I've done a quick test and the 0 appears in `org-contacts-db'.

Best,

-- 
Daimrod/Greg

Re: [O] org-contacts development

[Daimrod]

Alexis flexibe...@gmail.com writes:

 Daimrod daim...@gmail.com writes:

 So, as you said, we would need to define and document a specification
 for org-contacts. And we need to be clear from the beginning about
 what it can do and what it can not do. For example, it is unlikely
 that org-contacts will be a 1:1 mapping with the vCard format in its
 current form because vCard properties can have values.

 e.g.
 PROP1;PROP2=VAL:FOO BAR
   ^

 Agreed. But it seem to me we could at least map e.g. TEL;CELL: (which
 is how my Android phone vCard-exports a mobile number) to
 e.g. :MOBILE: or :PHONE_CELL:. And we could map things like
 e.g. EMAIL;TYPE=work: to e.g. :EMAIL_WORK:. This is just
 brainstorming, however. :-)

Sure, but then how would we define the map? with a fixed set of rules?
with a user customizable map (e.g. '((MOBILE - TELL;CELL)
(EMAIL_WORK - EMAIL;TYPE=work)))?

I'm not saying that it's impossible nor that we shouldn't do it but that
we need to think about it first. :)

 An approach would be to keep using properties whenever it's possible
 to keep the format simple when possible and use subtree instead of
 properties when necessary.

 e.g.
 #+BEGIN_SRC org
   ,* Contact Name
   ,** PHONE
  :PROPERTIES:
  :TYPE: WORK
  :END:
   - num1
   - num2
 #+END_SRC

 But then we would need a special property to indicate that a subtree
 is a contact and ignore subtree without this property (just like it
 does with the EMAIL property ATM).

 #+BEGIN_SRC org
   ,* Contact Name
 :PROPERTIES:
 :TYPE: org-contacts
 :END:

   ,** PHONE
  :PROPERTIES:
  :TYPE: WORK
  :END:
   - num1
   - num2
 #+END_SRC

 And of course it would be nice if we could keep as much compatibility
 with the current format :)

 Well, to me this looks broadly similar to what Esben has proposed:

 https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html

 Although i like the idea of such a format in principle, my concern (as i
 noted in my reply to Esben) is that this might require a substantial
 modification of org-contacts.el, both to accommodate this format and to
 ensure backwards-compatibility. If this is indeed the case, and someone
 else is willing to commit to being the lead on undertaking that work,
 then i'll certainly support that work and write relevant MobileOrg code
 to work with both the new and old formats. Otherwise, from my
 perspective of wanting to simply add some more fields and be able to
 transfer contact details between MobileOrg and my phone's Contacts
 system, it's more than i'm willing to take on at this point.

Well, if people are willing to help, I'll see if I can come up with a
proposal.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] org-contacts development

[Daimrod]

Alexis flexibe...@gmail.com writes:

 Hi all,
Hi,

 [snip...]

 Fleshing out an extended spec for org-contacts data could be part of the
 process of making org-contacts a first-class citizen of org-mode, and
 provide a more solid foundation on which people can build (and share)
 the org-contacts functionality they're after. And in my own particular
 case, it would greatly facilitate my work in org-contacts / Android
 Contacts integration. :-)

 What do people think?

IMHO, the problem with org-contacts isn't that it isn't part of
org-mode, but that its format isn't well defined enough.

Some fields accept only one value, some multiple values, with different
separators, etc... And on top of that, there is no easy way to access
the database (`car', `cadr', `caddr', ...) which makes it difficult to
read and write code.


So, as you said, we would need to define and document a specification
for org-contacts. And we need to be clear from the beginning about
what it can do and what it can not do. For example, it is unlikely
that org-contacts will be a 1:1 mapping with the vCard format in its
current form because vCard properties can have values.

e.g.
PROP1;PROP2=VAL:FOO BAR
  ^

And AFAIK we can't do that with org-mode properties.

An approach would be to keep using properties whenever it's possible
to keep the format simple when possible and use subtree instead of
properties when necessary.

e.g.
#+BEGIN_SRC org
  ,* Contact Name
  ,** PHONE
 :PROPERTIES:
 :TYPE: WORK
 :END:
  - num1
  - num2
#+END_SRC

But then we would need a special property to indicate that a subtree
is a contact and ignore subtree without this property (just like it
does with the EMAIL property ATM).

#+BEGIN_SRC org
  ,* Contact Name
:PROPERTIES:
:TYPE: org-contacts
:END:

  ,** PHONE
 :PROPERTIES:
 :TYPE: WORK
 :END:
  - num1
  - num2
#+END_SRC

And of course it would be nice if we could keep as much compatibility
with the current format :)

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Eric Abrahamsen e...@ericabrahamsen.net writes:

 On 05/19/14 23:21 PM, Daimrod wrote:
 Daimrod daim...@gmail.com writes:

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 Ok, so the good news is the `debug-on-event' trick works. If you got a
 lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to
 the Emacs process.

 The bad news is that I don't know yet how to reproduce the lockup. It
 seems to happen mostly (if not only) when I use org-mode +
 visual-line-mode + adaptive-wrap-prefix-mode + an input-method like
 latin-postfix.

 And it probably has to do with the cache mechanism. I'll try to
 reproduce it with the cache disabled but it hard to test because, as I
 said, I don't know how to reproduce it yet.

 I'll keep testing and see if I can reproduce it reliably.

 Stay tuned!

 Of course I haven't gotten a single lock-up since reporting in last time...

:D

Do you have a similar setup? That is visual-line-mode,
adaptive-wrap-prefix-mode, input-method?

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Daimrod daim...@gmail.com writes:

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

Ok, so the good news is the `debug-on-event' trick works. If you got a
lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to
the Emacs process.

The bad news is that I don't know yet how to reproduce the lockup. It
seems to happen mostly (if not only) when I use org-mode +
visual-line-mode + adaptive-wrap-prefix-mode + an input-method like
latin-postfix.

And it probably has to do with the cache mechanism. I'll try to
reproduce it with the cache disabled but it hard to test because, as I
said, I don't know how to reproduce it yet.

I'll keep testing and see if I can reproduce it reliably.

Stay tuned!

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 I've seen hiccups here and there, but generally, what happens is an
 error, not an infinite hanging.

 It happens often enough that I guess it's worth running emacs under some
 kind of debugger -- at least, I assume that's the best way of catching
 the bug. I'm not really sure how to go hunting, though, so if anyone had
 any advice in this direction, that would be great.

 I'd hunt for some infloop in parsing -- but cannot detail more than
 that, problably Nicolas could.

 In the meantime, is there any way of interrupting emacs so it quits
 whatever its doing, without having to kill it? I've played around with
 sending different signals using kill, just for fun, but everything
 I've tried either does nothing, or kills emacs altogether.

 I have no suggestion here either, sorry :/

I have also semi-regular lockup with org-mode. I have opened a bug on
debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

I'll try to see what I can find this week end and report back.

By the way, if you want to see in which part the infloop occurs, you can
attach a gdb debugger to the running emacs, source the
path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

$ gdb path-to-emacs-executable emacs-pid
gdb) source path-to-emacs-source/src/.gdbinit
...
gdb) xbacktrace

You can also use the `bt' command but it contains much more noise.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

Bastien b...@gnu.org writes:

 Daimrod daim...@gmail.com writes:

 I wonder if it is because `org-adaptive-fill-function' doesn't mix well
 with `adaptive-wrap-prefix-mode'...

 (Nicolas has been doing some rewrite for filling functions in the
 master branch, maybe it's worth checking whether this bug affects
 the master branch too, not just the Emacs-24 version of Org.)

I am using the master branch, I didn't check if it also happens in the
Emacs-24 version of Org.

Sorry, I should have mentioned that in my initial report. :(

-- 
Daimrod/Greg

Re: [O] still seeing semi-regular lockups

[Daimrod]

Eric Abrahamsen e...@ericabrahamsen.net writes:

 Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 After Nicolas made the last round of improvements to the caching
 mechanism I got far fewer hangs with Org, but they are still happening.
 Maybe once a day or so, on average, editing something in an Org buffer
 causes emacs to hang, and my fans to spin up, and there we are until I
 kill emacs.

 [...]

 I have also semi-regular lockup with org-mode. I have opened a bug on
 debbugs and here is what Stefan told me to try to debug this:

 You can try `debug-on-event'.
 
 There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
 So you'll need to additionally use
 
(advice-add 'jit-lock--debug-fontify :around
  (lambda (fun rest args)
(with-local-quit (apply fun args
 
 Of course sometimes this doesn't work because jit-lock-debug-mode
 changes the way things are executed and the bug may not manifest itself
 any more, but it's worth a try.
 
 Another source of info is to
 
   M-x trace-function RET org-adaptive-fill-function RET
   M-x trace-function RET org-element-at-point RET
   M-x trace-function RET org-element--cache-sync RET
   M-x trace-function RET org-element--cache-process-request RET
 
 Then reproduce the hang, then break the hang somehow (maybe with the
 jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
 C-g, ...), then look at the *trace..* buffer.

 I'll try to see what I can find this week end and report back.

 By the way, if you want to see in which part the infloop occurs, you can
 attach a gdb debugger to the running emacs, source the
 path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command.

 $ gdb path-to-emacs-executable emacs-pid
 gdb) source path-to-emacs-source/src/.gdbinit
 ...
 gdb) xbacktrace

 You can also use the `bt' command but it contains much more noise.

 Thanks! This is the sort of thing I assumed I'd have to do, and it's
 good to have an actual recipe. If you're on it, I might take the lazy
 option and spectate for now... :)

No problem, but could you attach gdb during a lockup, source .gdbitinit
and use the `xbacktrace' command to see if the lockup happens at the
same place?

-- 
Daimrod/Greg

[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

Bastien b...@altern.org writes:

 Daimrod daim...@gmail.com writes:

 Bastien b...@gnu.org writes:

 Daimrod daim...@gmail.com writes:

 I wonder if it is because `org-adaptive-fill-function' doesn't mix well
 with `adaptive-wrap-prefix-mode'...

 (Nicolas has been doing some rewrite for filling functions in the
 master branch, maybe it's worth checking whether this bug affects
 the master branch too, not just the Emacs-24 version of Org.)

 I am using the master branch, I didn't check if it also happens in the
 Emacs-24 version of Org.

 Okay, then it would be good to know if it happens in the Org version
 included in the Emacs pretest, as this is the one that needs heavy
 testing right now :)

So far I haven't manage to reproduce it with the Org bundled with the
Emacs pretest. I'll continue to use it for a while and see what happens.

Best,

-- 
Daimrod/Greg

[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

Stefan Monnier monn...@iro.umontreal.ca writes:

 gdb) xbacktrace
 avl-tree-delete (0x54b0)
 byte-code (0x55a0)
 byte-code (0x5760)
 org-element--cache-process-request (0x5990)
 byte-code (0x5aa0)
 org-element--cache-sync (0x5ce0)
 org-element-at-point (0x5e00)
 byte-code (0x60d0)
 org-adaptive-fill-function (0x6300)
 fill-match-adaptive-prefix (0x6480)
 fill-context-prefix (0x6620)
 adaptive-wrap-fill-context-prefix (0x67d0)
 adaptive-wrap-prefix-function (0x6a18)
 run-hook-with-args (0x6a10)
 0x4d89f80 PVEC_COMPILED
 funcall (0x6b30)
 jit-lock-fontify-now (0x6e38)
 jit-lock-function (0x6fc8)
 vertical-motion (0xdca8)
 end-of-visual-line (0xde08)
 call-interactively (0xdfc0)
 org-end-of-line (0xe198)
 call-interactively (0xe350)
 command-execute (0xe478)

 I wonder if it is because `org-adaptive-fill-function' doesn't mix well
 with `adaptive-wrap-prefix-mode'...

 As mentioned earlier, the immediate problem is that
 org-adaptive-fill-function does not terminate (or at least takes too
 long to terminate).

Ok.

 Now, one reason why this might happen here is that
 adaptive-wrap-prefix-mode calls org-adaptive-fill-function everywhere,
 so it might be called in places where it usually (i.e. when
 adaptive-wrap-prefix-mode isn't in use) isn't triggered.

Is there a way to disable the effect of `inhibit-quit' in `jit-lock' so
C-g interrupt again in order to get an elisp-backtrace with
`debug-on-quit'.

Otherwise, what's the best way to debug this? Looking closer at
`org-adaptive-fill-function'?

-- 
Daimrod/Greg

[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

Stefan Monnier monn...@iro.umontreal.ca writes:

 So, that's an org-mode bug, I'll try to see if I can reproduce it

 Right: org-adaptive-fill-function should finish fairly promptly.

 (though I wonder why it uses `inhibit-quit' in the first place).

 It's not org-mode which binds inhibit-quit but the C code that runs
 jit-lock.  The C code binds inhibit-quit basically any time we run
 asynchronous code (i.e. code run from redisplay, timers,
 process-filters, ...) since the user usually doesn't really know that
 such is running, so if she hits C-g she doesn't mean for it to interrupt
 that code, but instead to do something else (e.g. get out of the
 minibuffer).

Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is
called by `org-capture'.

I have found 7 places were `inhibit-quit' was set to T in org-mode.

 The flip side is that all code run from jit/font-lock, process filters
 and timers should be super extra careful to finish promptly and never
 ever get into an inf-loop.

I can see why. :)

-- 
Daimrod/Greg

[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

Daimrod daim...@gmail.com writes:

 Stefan Monnier monn...@iro.umontreal.ca writes:

 So, that's an org-mode bug, I'll try to see if I can reproduce it

 Right: org-adaptive-fill-function should finish fairly promptly.

 (though I wonder why it uses `inhibit-quit' in the first place).

 It's not org-mode which binds inhibit-quit but the C code that runs
 jit-lock.  The C code binds inhibit-quit basically any time we run
 asynchronous code (i.e. code run from redisplay, timers,
 process-filters, ...) since the user usually doesn't really know that
 such is running, so if she hits C-g she doesn't mean for it to interrupt
 that code, but instead to do something else (e.g. get out of the
 minibuffer).

 Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is
 called by `org-capture'.

You were right, it's not a problem with `org-capture', I had a another
freeze without using it.

Here is the xbacktraces:
gdb) xbacktrace
avl-tree-delete (0x54b0)
byte-code (0x55a0)
byte-code (0x5760)
org-element--cache-process-request (0x5990)
byte-code (0x5aa0)
org-element--cache-sync (0x5ce0)
org-element-at-point (0x5e00)
byte-code (0x60d0)
org-adaptive-fill-function (0x6300)
fill-match-adaptive-prefix (0x6480)
fill-context-prefix (0x6620)
adaptive-wrap-fill-context-prefix (0x67d0)
adaptive-wrap-prefix-function (0x6a18)
run-hook-with-args (0x6a10)
0x4d89f80 PVEC_COMPILED
funcall (0x6b30)
jit-lock-fontify-now (0x6e38)
jit-lock-function (0x6fc8)
vertical-motion (0xdca8)
end-of-visual-line (0xde08)
call-interactively (0xdfc0)
org-end-of-line (0xe198)
call-interactively (0xe350)
command-execute (0xe478)

I wonder if it is because `org-adaptive-fill-function' doesn't mix well
with `adaptive-wrap-prefix-mode'...

-- 
Daimrod/Greg

[O] [PATH] Customize org-annotate-file

[Daimrod]

Hi,

Here is a small patch for contrib/lisp/org-annotate-file.el.

This patch creates a customization group for org-annotate-file (child of
the org group) and convert defvars to defcustoms.

Okay to push?

From ea5be445776f7d139f52b38306552e0012b47d0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com
Date: Fri, 9 May 2014 14:58:59 +0900
Subject: [PATCH] contrib/lisp/org-annotate-file.el: Create a customization
 group and convert `defvar' customization variables to `defcustom'

* contrib/lisp/org-annotate-file.el (org-annotate-file): New customization
group.

(org-annotate-file-storage-file org-annotate-file-add-search
org-annotate-file-always-open): Convert `defvar' symbols to `defcustom' using the new group.
---
 contrib/lisp/org-annotate-file.el | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/contrib/lisp/org-annotate-file.el b/contrib/lisp/org-annotate-file.el
index 8fbb590..b8e8bd9 100644
--- a/contrib/lisp/org-annotate-file.el
+++ b/contrib/lisp/org-annotate-file.el
@@ -59,14 +59,24 @@
 
 (require 'org)
 
-(defvar org-annotate-file-storage-file ~/.org-annotate-file.org
-  File in which to keep annotations.)
-
-(defvar org-annotate-file-add-search nil
-  If non-nil, add a link as a second level to the actual file location.)
-
-(defvar org-annotate-file-always-open t
-  If non-nil, always expand the full tree when visiting the annotation file.)
+(defgroup org-annotate-file nil
+  Org Annotate
+  :group 'org)
+
+(defcustom org-annotate-file-storage-file ~/.org-annotate-file.org
+  File in which to keep annotations.
+  :group 'org-annotate-file
+  :type 'file)
+
+(defcustom org-annotate-file-add-search nil
+  If non-nil, add a link as a second level to the actual file location.
+  :group 'org-annotate-file
+  :type 'boolean)
+
+(defcustom org-annotate-file-always-open t
+  If non-nil, always expand the full tree when visiting the annotation file.
+  :group 'org-annotate-file
+  :type 'boolean)
 
 (defun org-annotate-file-ellipsify-desc (string optional after)
   Return shortened STRING with appended ellipsis.
-- 
1.8.0.2722.gc0242e5


-- 
Daimrod/Greg

Re: [O] [PATH] Customize org-annotate-file

[Daimrod]

Bastien b...@gnu.org writes:

 Daimrod daim...@gmail.com writes:

 Okay to push?

 Please go ahead, thanks,

done.

-- 
Daimrod/Greg

Re: [O] loading all agenda files at startup

[Daimrod]

Eric Abrahamsen e...@ericabrahamsen.net writes:

Hi Eric,

 I've got a few top-level user commands, related to org, that load at
 startup. Specifically org-agenda and org-ido-switchb are bound to keys
 that are available after emacs starts up. Before Org loads properly,
 however, things like the agenda file list and the list of valid tags and
 TODO keywords are unavailable. That makes it hard to boot emacs and go
 directly into a call to `org-todo-list': the TODO keywords aren't loaded
 yet.

 I've looked into this before but couldn't find a single function that
 would boot my local data. `org-agenda-files' reads the file list, but
 it doesn't actually parse the files and do all the setup routines.

 Is there a single-function entry point that I could put in my init
 files, that would get me where I want to be? ie, in a state as though
 `org-agenda' had already been called, though it hasn't yet?

I call `org-agenda-list' in my `after-init-hook' but it is not silent,
that is, it displays the agenda list.

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] How to write a org babel hook, which can manupulate result

[Daimrod]

Feng Shu tuma...@gmail.com writes:

 Hi:
Hi Feng,

Look at the :post header argument.
(info (org) post)

 I want to write a hook to menupulate org babel output,
 The problem is: How can I get two points info: [pointA] and [pointB]
 in my hook function?

 #+begin_src R :results output raw drawer
 tbl - data.frame(a=c(1,2,3),b=c(3,2,1))
 print(ascii(tbl),type=org)
 #+END_SRC

 #+RESULTS:
 :RESULTS:
 [pointA]
 |   |a |b |
 |---+--+--|
 | 1 | 1.00 | 3.00 |
 | 2 | 2.00 | 2.00 |
 | 3 | 3.00 | 1.00 |
 [pointB]
 :END:

-- 
Daimrod/Greg

Re: [O] How to write a org babel hook, which can manupulate result

[Daimrod]

Feng Shu tuma...@gmail.com writes:

 Daimrod daim...@gmail.com writes:

 Feng Shu tuma...@gmail.com writes:

 Hi:
 Hi Feng,

 Look at the :post header argument.
 (info (org) post)

 How to use elisp in :post directly,

I don't think you can.

You have to use it this way (not tested):

#+NAME: align-multi-table
#+BEGIN_SRC emacs-lisp :var content=nil :results raw
  (align-multi-table content)
#+END_SRC
#+begin_src R :results output raw drawer :post align-multi-table(content=*this*)
  content
#+end_src

 for example:

 #+begin_src R :results output raw drawer :post (align-multi-table)
   content
 #+end_src
 #+begin_comment
 (defun align-multi-table (optional content)
   (interactive)
   (let ((content (or content *this*)))
 (with-temp-buffer
   (insert content)
   (goto-char (point-min))
   (while (not (eobp))
   (when (org-at-table-p)
 (org-table-align))
   (forward-line))
   (buffer-string
 #+end_comment


 I want to write a hook to menupulate org babel output,
 The problem is: How can I get two points info: [pointA] and [pointB]
 in my hook function?

 #+begin_src R :results output raw drawer
 tbl - data.frame(a=c(1,2,3),b=c(3,2,1))
 print(ascii(tbl),type=org)
 #+END_SRC

 #+RESULTS:
 :RESULTS:
 [pointA]
 |   |a |b |
 |---+--+--|
 | 1 | 1.00 | 3.00 |
 | 2 | 2.00 | 2.00 |
 | 3 | 3.00 | 1.00 |
 [pointB]
 :END:

-- 
Daimrod/Greg

Re: [O] [PATCH] Support for links to Ebib's entries

[Daimrod]

Bastien b...@gnu.org writes:

 Hi Greg,

 Daimrod daim...@gmail.com writes:

 I've attached a small patch to support links (opening and storing) to
 Ebib's[1] entries.

 Can I integrate it?

 Sure, please go ahead, thanks!

Done.

Best,
-- 
Daimrod/Greg

[O] [PATCH] Support for links to Ebib's entries

[Daimrod]

Hi,

I've attached a small patch to support links (opening and storing) to
Ebib's[1] entries.

Can I integrate it?

1: http://joostkremers.github.io/ebib/

From acd007302d56d40189659853ef146407bb64ba20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com
Date: Wed, 12 Mar 2014 08:06:13 +0900
Subject: [PATCH] contrib/lisp/org-ebib.el: Support for links to Ebib's entries

* contrib/lisp/org-ebib.el: Support for links to Ebib's entries.
(org-ebib-open): Open an Ebib's entry.
(org-ebib-store-link): Store a link to an Ebib's entry.
---
 contrib/lisp/org-ebib.el | 47 +++
 1 file changed, 47 insertions(+)
 create mode 100644 contrib/lisp/org-ebib.el

diff --git a/contrib/lisp/org-ebib.el b/contrib/lisp/org-ebib.el
new file mode 100644
index 000..2136a13
--- /dev/null
+++ b/contrib/lisp/org-ebib.el
@@ -0,0 +1,47 @@
+;;; org-ebib.el - Support for links to Ebib's entries in Org
+;;
+;; Author: Grégoire Jadi daim...@gmail.com
+;;
+;; This file is not yet part of GNU Emacs.
+;;
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see http://www.gnu.org/licenses/.
+;
+;;
+;;; Commentary:
+
+(require 'org)
+
+(org-add-link-type ebib 'org-ebib-open)
+
+(add-hook 'org-store-link-functions 'org-ebib-store-link)
+
+(defun org-ebib-open (key)
+  Open Ebib and jump to KEY.
+  (ebib nil key))
+
+(defun org-ebib-store-link ()
+  Store a key to an Ebib entry.
+  (when (memq major-mode '(ebib-index-mode ebib-entry-mode))
+;; This is an Ebib entry
+(let* ((key (ebib-cur-entry-key))
+   (link (concat ebib: key))
+   (description (ignore-errors (ebib-db-get-field-value 'title key ebib-cur-db
+  (org-store-link-props
+   :type ebib
+   :link link
+   :description description
+
+(provide 'org-ebib)
+
+;;; org-ebib.el ends here
-- 
1.8.0.2722.gc0242e5


-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Some links not working anymore for me

[Daimrod]

François Pinard pin...@iro.umontreal.ca writes:

 Hi, Org people.

Hello,

 For a little while, I've not been able to follow links to Org files,
 when the link contains a search to some header, and the searched header
 itself contains white space or non-ASCII characters.  I just made this
 patch that apparently helps me out of this new little misery :-).  The
 patch is only indicative: I'm not sure it is the proper way to solve the
 difficulty, as I do not really understand all the code surrounding it!

See this commit 8 days ago:
567ec87 * | Unescape links before opening them

 diff --git a/lisp/org.el b/lisp/org.el
 index a0ed137..5c41b52 100644
 --- a/lisp/org.el
 +++ b/lisp/org.el
 @@ -10555,7 +10555,8 @@ is used internally by `org-open-link-from-string'.
(cond ((not option) nil)
  ((org-string-match-p \\`[0-9]+\\' option)
   (list (string-to-number option)))
 -(t (list nil option
 +(t (list nil
 + (org-link-unescape option)
  ((assoc type org-link-protocols)
   (funcall (nth 1 (assoc type org-link-protocols)) path))
  ((equal type help)

 François


-- 
Daimrod/Greg

Re: [O] can org-mode file export to markdown file

[Daimrod]

jenenliu jenen...@gmail.com writes:
Hello,

 Can I write a org file and then export it as a markdown file ?

Sure, just load the library `ox-md' then you can export to a markdown
file with C-c C-e m m

-- 
Daimrod/Greg

Re: [O] analog of org-element-at-point for objects?

[Daimrod]

John Kitchin jkitc...@andrew.cmu.edu writes:
Hi John,

 Is there an easy way to to get the object at point? I found
 org-element-at-point, but what I need is to determine if point is on a
 link of a particular type, and links appear to be objects rather than
 elements.

I think that `org-element-context' is what you're looking for.

 an alternative solution for me would be how do you move point to the
 beginning of a link (if it is on a link)? I found org-next-link and
 org-previous-link, but neither of these move you to the beginning of
 the current link. Then, I could use org-element-link-parser, but that
 only works with point at the beginning of a link.

 The reason I was looking into this is here: 
 http://kitchingroup.cheme.cmu.edu/blog/2014/03/07/Storing-label-links-in-org-mode/

 It just seems there must be a better way than I implemented. thanks!

Best,

-- 
Daimrod/Greg

Re: [O] [Bug] org-open-at-point adds file+

[Daimrod]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I think that since its recent rewrite, `org-open-at-point' adds 'file+'
 before the name of the application before trying to find the correct
 application.

 For example the following link:

 #+BEGIN_EXAMPLE
 [[docview:foo.pdf]]
 #+END_EXAMPLE

 won't trigger the `org-docview-open' handler

 This should be fixed. Thank you for reporting it.

Thanks for the fast reply.

 Regards,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I think that there is a bug in `org-element-context' because it doesn't
 seem to parse link with spaces consistently.

 For example:

 #+BEGIN_EXAMPLE
 v
 [[file:test 1 2 3]]
 ^
 #+END_EXAMPLE

 If the cursor is before the '1', then `org-element-context' will return:

 #+BEGIN_EXAMPLE
 (link (:type file :path test :raw-link file:test :application nil 
 :search-option nil :begin 26 ...))
 #+END_EXAMPLE

 if the cursor is one or after the '1', then `org-element-context' will 
 return:

 #+BEGIN_EXAMPLE
 (link (:type file :path test%201%202%203 :raw-link 
 file:test%201%202%203 :application nil :search-option nil :begin 1 ...))
 #+END_EXAMPLE

 I cannot reproduce it. What Org version do you use? Did you try to
 disable `org-element-use-cache'?

Sorry, it happens with:
#+BEGIN_EXAMPLE
[[file:test%201%202%203][file:test 1 2 3]]
#+END_EXAMPLE

I use org-mode version release_8.0.2-101-gce5988 (I follow the git
upstream) and I tried it with `org-element-use-cache' set to nil.


It doesn't happen with:
#+BEGIN_EXAMPLE
[[file:test 1 2 3]]
#+END_EXAMPLE
but as soon as the cursor leaves the link, org-mode rewrite the link to:
#+BEGIN_EXAMPLE
[[file:test%201%202%203][file:test 1 2 3]]
#+END_EXAMPLE


Best,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Daimrod daim...@gmail.com writes:

 I use org-mode version release_8.0.2-101-gce5988 (I follow the git
 upstream) and I tried it with `org-element-use-cache' set to nil.

 There was no `org-element-use-cache' in Org 8.0. Could you update Org
 and try again?

I had forgotten to rerun make after I pulled the latest version.
`org-version' now returns 8.2.5h.

And you're right, it doesn't happen when `org-element-use-cache' is set
to nil.

However, when `org-element-use-cache' is set to t, then it looks like
`org-element-context' uses the link's title instead of the link's value.
e.g.
#+BEGIN_EXAMPLE
  v-- with the cursor here, it returns (link (:type file :path foo ...))
[[file:foo][file:test 1 2 3]]
   ^-^
when the cursor is in this zone, it returns (link (:type file :path 
test ...))
  ^-- when the cursor is after this point (after the
  first space) it returns (link (:type file :path test 1 
2 3 ...))
#+END_EXAMPLE

Best,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Daimrod daim...@gmail.com writes:

 I had forgotten to rerun make after I pulled the latest version.
 `org-version' now returns 8.2.5h.

 This is still not right. 8.2.5h refers to maint branch, where cache
 doesn't exist.

 When I compile the latest release on master, I get:

   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)

 So, I'm confused. On what branch are you?

I really don't understand. I am on the master branch, the latest commit
I see is yours (51718d9 Fix last commit).

I'm trying with a fresh clone.

 Regards,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Bastien b...@gnu.org writes:

 Hi Nicolas and Greg,

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Daimrod daim...@gmail.com writes:

 I had forgotten to rerun make after I pulled the latest version.
 `org-version' now returns 8.2.5h.

 This is still not right. 8.2.5h refers to maint branch, where cache
 doesn't exist.

 I think Greg did C-h v org-version RET, which returns 8.2.5h both
 from the maint and the master branch.

 Greg: M-x org-version RET gives all the information we need.

Awww that's tricky, M-x org-version doesn't have the same behavior than
M-: (org-version)

M-x org-version returns: Org-mode version 8.2.5h (release_8.2.5h-678-gd8c717 @ 
...)

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Daimrod daim...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Daimrod daim...@gmail.com writes:

 I had forgotten to rerun make after I pulled the latest version.
 `org-version' now returns 8.2.5h.

 This is still not right. 8.2.5h refers to maint branch, where cache
 doesn't exist.

 When I compile the latest release on master, I get:

   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)

 So, I'm confused. On what branch are you?

 I really don't understand. I am on the master branch, the latest commit
 I see is yours (51718d9 Fix last commit).

 I'm trying with a fresh clone.

Still the same with a fresh clone.

 Regards,

-- 
Daimrod/Greg

[O] [Bug] org-open-at-point adds file+

[Daimrod]

Hello,

I think that since its recent rewrite, `org-open-at-point' adds 'file+'
before the name of the application before trying to find the correct
application.

For example the following link:
#+BEGIN_EXAMPLE
[[docview:foo.pdf]]
#+END_EXAMPLE
won't trigger the `org-docview-open' handler
because the following code:
#+BEGIN_SRC emacs-lisp
(or (let ((app (org-element-property :application context)))
 (nth 1 (assoc (concat file (and app (concat + 
app)))
   org-link-protocols)))
   #'org-open-file)
#+END_SRC
adds `file+' and then search in `org-link-protocols'.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

[O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Hello,

I think that there is a bug in `org-element-context' because it doesn't
seem to parse link with spaces consistently.

For example:
#+BEGIN_EXAMPLE
v
[[file:test 1 2 3]]
^
#+END_EXAMPLE
If the cursor is before the '1', then `org-element-context' will return:
#+BEGIN_EXAMPLE
(link (:type file :path test :raw-link file:test :application nil 
:search-option nil :begin 26 ...))
#+END_EXAMPLE
if the cursor is one or after the '1', then `org-element-context' will return:
#+BEGIN_EXAMPLE
(link (:type file :path test%201%202%203 :raw-link file:test%201%202%203 
:application nil :search-option nil :begin 1 ...))
#+END_EXAMPLE

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] http link character mistranslated

[Daimrod]

Daimrod daim...@gmail.com writes:

Fixed by ngz in commit 567ec87

 mirko mirko.vuko...@gmail.com writes:

 Hi,

 Hello,

 (Org-mode version 8.2.5h (release_8.2.5h-651-g897b60)

 I have an https address with an equal sign `=':
https://forums.virtualbox.org/viewforum.php?f=3

 When I try to access the link, the `=' is translated as `%D':
https://forums.virtualbox.org/viewforum.php?f%3D3

 I have the same problem here. It causes problem with docview and gnus
 links.

 I looked in org-open-at-point, and the translation appears somewhere in
 org-element-property.  I did not look deeper.

 IIUC, since I don't know when, org-mode encode links with percent
 encoding (you can check it by turning off org-mode (e.g. M-x
 fundamental-mode)).

 My guess is that it is now the job of the link handler (FOLLOW arg in
 org-add-link-type) to unescape the path if necessary, but I'm not sure
 of it.

 I tested this in an Emacs session with only org mode loaded (no user init)

 Thanks,

 Mirko



-- 
Daimrod/Greg

Re: [O] http link character mistranslated

[Daimrod]

mirko mirko.vuko...@gmail.com writes:

 Hi,

Hello,

 (Org-mode version 8.2.5h (release_8.2.5h-651-g897b60)

 I have an https address with an equal sign `=':
https://forums.virtualbox.org/viewforum.php?f=3

 When I try to access the link, the `=' is translated as `%D':
https://forums.virtualbox.org/viewforum.php?f%3D3

I have the same problem here. It causes problem with docview and gnus
links.

 I looked in org-open-at-point, and the translation appears somewhere in
 org-element-property.  I did not look deeper.

IIUC, since I don't know when, org-mode encode links with percent
encoding (you can check it by turning off org-mode (e.g. M-x
fundamental-mode)).

My guess is that it is now the job of the link handler (FOLLOW arg in
org-add-link-type) to unescape the path if necessary, but I'm not sure
of it.

 I tested this in an Emacs session with only org mode loaded (no user init)

 Thanks,

 Mirko



-- 
Daimrod/Greg

Re: [O] orc-contacts contacting ww.gravatar.com! -- How to switch off?

[Daimrod]

AW alexander.will...@t-online.de writes:

 Hi,

 I'm exploring the org-contacts. When I do M-x org-contacts, Emacs tries to 
 contact www.gravatar.com:80

 How can I switch that off?

You can set `org-contacts-icon-use-gravatar' to nil.

 Besides that, what I really miss is a comprehensive manual on org-contact. 
 OK, 
 I can search for a name as described above, I can add a new contact with M-x 
 org-capture, but what else?

 Thank you,

 Regards,

 Alexander


-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer

[Daimrod]

Øyvind Stegard oyvi...@ifi.uio.no writes:

 Daimrod daim...@gmail.com writes:

 [...]

 Thanks for the bug report!

 Don't you think that checking if one of the buffer would be enough and
 faster?
 With something like (every #'get-file-buffer org-contacts-files)

 Hi,

 I thought about that, yes. But what about when an org-contacts buffer is
 killed and subsequently re-opened (like using `find-alternate-file' with
 same file name). Then the buffer will exist for the file, but it will be
 a new instance, and the markers in org-contacts-db will still be dead.
 That's why I decided to just check the markers instead.

You're right, good catch!

I've installed the patch and haven't felt any slowdown, but I've a small
contacts file. If people complain about slowdown we could add a buffer
local hook to ask before killing contacts files.

 Regards,

 Øyvind

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer

[Daimrod]

Øyvind Stegard oyvi...@ifi.uio.no writes:

 Hi list,

Hello,

 In contrib/lisp/org-contacts.el:

 The function `org-contacts-db-need-update-p' does two checks to
 determine if the contacts cache should be updated:
 1. If the variable `org-contacts-last-update' is nil.
 2. If modification time of any file containing contacts is more recent than
timestamp recorded in `org-contacts-last-update'.

 There is another case where an update is required: when marker objects
 contained in the contact cache `org-contacts-db' suddenly point to no
 buffer. If a buffer containing contacts is killed, but underlying file
 is not modified, org-contacts will not detect this, and cached markers
 that pointed to the now killed buffer will become dead (have no buffer
 associated with them). This seems to cause problems at least in
 `org-contacts-anniversaries', which if used as diary sexp in an agenda
 file, will cause Bad sexp errors.

 I have not done any thorough analysis of `org-contacts-anniversaries'
 itself, but it seems to work OK whenever the markers in
 `org-contacts-db' are OK. And it looks like the markers are used in that
 code.

 To reproduce:
 1. Load up org-contacts and do a query with M-x org-contacts.
 2. Kill at least one org-buffer containing a contact with BIRTHDAY
property set (but do not save underlying file).
 3. Make sure to use %%(org-contacts-anniversaries) in some agenda file.
 4. Opening agenda should produce a Bad sexp error.


 I've attached a patch (against git master) which I am currently using.
 It will cause org-contacts to re-load if a marker is found in cache that
 points to no buffer. This looked to me like the quickest approach for
 fixing it without getting to know org-contacts.el better.


Thanks for the bug report!

Don't you think that checking if one of the buffer would be enough and
faster?
With something like (every #'get-file-buffer org-contacts-files)


 Regards,

 Øyvind

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Circular lists/shared structures in org-element parse-tree

[Daimrod]

Thorsten Jolitz tjol...@gmail.com writes:

 Hi List, 

 I wonder how I can find out in a (elisp) program the points in the parse
 tree (returned by org-element-parse-buffer) where shared structures are
 used. 

 In the read-syntax, its easy to see (especially with `print-circle' set
 to non-nil):

 #+begin_src emacs-lisp
   #2=(org-data nil #1=(headline (:raw-value header 1
[...] :parent #2#) [...]  
 #+end_src

 but when processing the parse tree as a list in elisp, how can I detect the
 fact that 

 ,
 | :parent #2#
 `

 refers to 

 ,-
 | #2=(org-data nil
 `-

 i.e. points back to an already existing structure?

AFAIK you have to track all pointers inspected to see if one has already
be seen.

For example, I've implemented a version of equal[1] to compare this kind
of lists (to add tests to org-sync).

[1] https://github.com/daimrod/Emacs-config/blob/master/elisp/dmd-utils.el#L25

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts: Provide ordering when using cycle completion

[Daimrod]

Øyvind Stegard oyvi...@ifi.uio.no writes:

 Hello list,

Hello,

Merged into master, thanks for patch!

 I have recently switched to using org-contacts, after several years of
 BBDB usage. When completing contacts in message-mode, I prefer cycling
 the completion alternatives, for instance when a single contact has
 multiple email addresses. So I set `completion-cycle-threshold' to some
 value other than nil.

 However, the cycle ordering was not consistent with the order in which
 email addresses appeared in the contact (actually, cycle order was
 shortest candidate first, which I understand is a default). So the
 preferred email address (or the first one defined in :EMAIL: property
 of contact node) was typically not always chosen as first completion
 suggestion in the cycle.

 I attach a patch here (against current org-mode git) which also provides
 the display sort function for cycle completions in metadata. That seems
 to resolve the problem for me.


 Regards,

 Øyvind Stegard
 -- 
  Øyvind Stegard
   http://stegard.net/


 From 64623274f0a040c452df43b2a3f7b23b0af8fd57 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?=C3=98yvind=20Stegard?= oyvind.steg...@ifi.uio.no
 Date: Mon, 10 Jun 2013 11:08:56 +0200
 Subject: [PATCH] org-contacts: Provide ordering when using cycle completion

 * contrib/lisp/org-contacts.el (org-contacts-metadata-prefix):
 Provide same function for cycle ordering as is used for display ordering
 in completion metadata.

 When using cycle completion style for contacts, by setting
 `completion-cycle-threshold' to some value, the ordering was not consistent
 with order of email addresses in contact definition, nor the order
 which was used for regular display completion. Fix that by also
 supplying sort function for cycle completion in metadata.
 ---
  contrib/lisp/org-contacts.el | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el
 index 5d63fcc..71f7bf4 100644
 --- a/contrib/lisp/org-contacts.el
 +++ b/contrib/lisp/org-contacts.el
 @@ -452,7 +452,8 @@ prefixes rather than just the beginning of the string.
  
  (defun org-contacts-metadata-prefix (string collection predicate)
'(metadata .
 -  ((display-sort-function . org-contacts-display-sort-function
 +  ((cycle-sort-function . org-contacts-display-sort-function)
 +   (display-sort-function . org-contacts-display-sort-function
  
  (defun org-contacts-complete-group (start end string)
Complete text at START from a group.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [patch] Add a complex org-contacts template to the file header

[Daimrod]

Feng Shu tuma...@gmail.com writes:

Thanks for the patch!

It's merged, I've taken the liberty to fix some typos.

Regards,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] Handling outdated contact information

[Daimrod]

Karl Voit devn...@karl-voit.at writes:

 * Daimrod daim...@gmail.com wrote:

 Hi Karl,

 Hi Daimrod!

 This is a very good patch, fixing an issue I also do have currently.

 I am curious, what was the issue?

 Sure: I do use contacts.org by myself and I tend to collect data
 about people and never delete any. For example, previously used
 phone numbers are quite handy in order to get a connection between
 old text messages or phone call logs and a person.

 However, I do not want to mess up current phone numbers with old
 ones.

 With this ignore feature, I am able to address this issue (in the
 future). For now, I do not export contact information from Org-mode
 to somewhere else (except: lbdb - mutt). In the future, I plan to
 add a workflow that gets contact information form Org-mode (my
 central point of information) to my phone and so forth.

I see, thanks for the explanation.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: add expire feature

[Daimrod]

Feng Shu tuma...@gmail.com writes:

 Daimrod daim...@gmail.com writes:


 This is not very idiomatic elisp, I would write something more like:
 #+BEGIN_SRC emacs-lisp
   (remove-if (lambda (el)
(member el expire-list)) 
  list)
 #+END_SRC

 Thanks!

 Is this possible?

  test1@g  =  te...@gmail.com

Yes, you could do it like this:
#+BEGIN_SRC emacs-lisp
  (remove-if (lambda (el)
   (find-if (lambda (x)
  (string-match-p x el))
expire-list))
 list)
#+END_SRC

This way you can use regular expressions in the ignore list.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: add expire feature

[Daimrod]

Feng Shu tuma...@gmail.com writes:

 Hi Daimrod!
 This is the 3 updated patch, if possible, please include it to master.

It's merged and pushed. I've also pushed another commit to fix the
formatting in some parts of the code and I've found a bug in
`org-contacts-split-property', but it should be fixed now.

 Thanks for your help!

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [Patch] phone links...

[Daimrod]

Michael Strey mst...@strey.biz writes:

Hello Michael,

While merging a patch (from Feng Shu) I have found a bug in
`org-contacts-split-property'. Though the docstring says that OMIT-NULLS
is forced to t when SEPARATORS is nil (just like `split-string'), it
wasn't the case. I've pushed a fix; could you check on your side that it
doesn't break anything in your workflow?

Thanks,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: add expire feature

[Daimrod]

Karl Voit devn...@karl-voit.at writes:

Hi Karl,

 This is a very good patch, fixing an issue I also do have currently.

I am curious, what was the issue?

Regards,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: add expire feature

[Daimrod]

-property properties
(head (format BEGIN:VCARD\nVERSION:3.0\nN:%s\nFN:%s\n n name))
 +  (expire-list (when expire (setq expire-list 
 (org-contacts-split-property expire
emails-list result phones-list)
  (concat head
   (when email (progn
 -   (setq emails-list (org-contacts-split-property email))
 +   (setq emails-list 
 (org-contacts-remove-expired-property expire-list 
 (org-contacts-split-property email))) ;

There is a leading semi-colon.  
  

 (setq result )
 (while emails-list
   (setq result (concat result  EMAIL: 
 (org-contacts-strip-link (car emails-list)) \n))
 @@ -886,7 +908,7 @@ to do our best.
   (when addr
 (format ADR:;;%s\n (replace-regexp-in-string \\, ? ; addr)))
   (when tel (progn
 - (setq phones-list (org-contacts-split-property tel))
 + (setq phones-list (org-contacts-remove-expired-property 
 expire-list (org-contacts-split-property tel)))
   (setq result )
   (while phones-list
 (setq result (concat result  TEL: 
 (org-contacts-strip-link (car phones-list)) \n))
 -- 
 1.7.10.4

[1] http://orgmode.org/worg/org-contribute.html#sec-5

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] [PATCH] org-contacts.el: add expire feature

[Daimrod]

Feng Shu tuma...@gmail.com writes:

  (defun org-contacts-complete-name (start end string)
Complete text at START with a user name and email.
(let* ((completion-ignore-case org-contacts-completion-ignore-case)
 @@ -484,10 +497,17 @@ A group FOO is composed of contacts with the tag FOO.
   ;; The contact name is always the car of the assoc-list
   ;; returned by `org-contacts-filter'.
   for contact-name = (car contact)
 +
 + ;; Build the list of the email addresses which has
 + ;; been expired
 + for expire-list = (org-contacts-split-property (or
 + (cdr 
 (assoc-string org-contacts-expire-property
 + 
(caddr contact))) ))
   ;; Build the list of the user email addresses.
 - for email-list = (org-contacts-split-property (or
 - (cdr (assoc-string 
 org-contacts-email-property
 -(caddr 
 contact))) ))
 + for email-list = (org-contacts-remove-expired-property 
 expire-list
 +
 (org-contacts-split-property (or
 + 
  (cdr (assoc-string org-contacts-email-property
 + 
 (caddr contact))) )))

I forgot to ask, why do you also modify org-contacts-complete-name? This
function isn't used to export to VCARD, but to complete the email in
Gnus.

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] org-element

[Daimrod]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

Hello Nicolas,

 Daimrod daim...@gmail.com writes:

 I'm playing a bit with org-element for org-contacts and I wanted to know
 what is the prefered way to change an element.

 For example, ATM, when I want to change an element property to add a new
 value, I do:

 #+BEGIN_SRC emacs-lisp
   (org-entry-put nil property
  (concat (org-entry-get nil property)
new-value))
 #+END_SRC

 See `org-element-put-property' and friends.

I've tried to use `org-element-put-property' but it only modifies the
object in memory, not the element in the file. Is there a way to write
the object into a file?

 Regards,

-- 
Daimrod/Greg


pgpx5qxLaG4B3.pgp
Description: PGP signature

[O] org-element

[Daimrod]

Hi,

I'm playing a bit with org-element for org-contacts and I wanted to know
what is the prefered way to change an element.

For example, ATM, when I want to change an element property to add a new
value, I do:

#+BEGIN_SRC emacs-lisp
  (org-entry-put nil property
 (concat (org-entry-get nil property)
   new-value))
#+END_SRC

Is it the correct way? IMHO it would be nicer if we could modify an
object created by the new parser and write it back but I don't think
it is possible (yet?).

Regards,

-- 
Daimrod/Greg


pgpZ70aTA0Nyn.pgp
Description: PGP signature

Re: [O] require a feature: merge many contacts which have the same name.

[Daimrod]

Feng Shu tuma...@gmail.com writes:

 I think org-contacts.el shoule have the feature which can merge many
 contacts which have the same name into one, for example:
 #+begin_example

 * name
  :PROPERTIES: 
  :EMAIL: [[mailto:a...@a.com]] [[mailto:b...@b.com]] 
  :PHONE: [[tel:123456789]]
  :ALIAS:a
  :END: 

 * name
  :PROPERTIES: 
  :EMAIL: [[mailto:c...@a.com]] [[mailto:d...@b.com]] 
  :PHONE: [[tel:987654321]]
  :ALIAS:b
  :END: 

 * name
  :PROPERTIES: 
  :EMAIL: [[mailto:e...@a.com]] [[mailto:f...@b.com]] 
  :PHONE: [[tel:111]]
  :ALIAS:c
  :END: 


 #+end_example

 how can I get the result:
 #+begin_example
 * name
  :PROPERTIES: 
  :EMAIL: [[mailto:a...@a.com]] [[mailto:b...@b.com]] [[mailto:c...@a.com]] 
 [[mailto:d...@b.com]] [[mailto:e...@a.com]] [[mailto:f...@b.com]] 
  :PHONE: [[tel:123456789]] [[tel:987654321]] [[tel:]]
  :ALIAS:a b c
  :END: 

 #+end_example
Hi Feng,

It's noted, I'll see what I can do this week-end.

-- 
Daimrod/Greg


pgpgoAyLvZ17T.pgp
Description: PGP signature

[O] bug#14374: bug#14374: Possibly incorrect custom :types

[Daimrod]

Glenn Morris r...@gnu.org writes:
Hi Glenn,

Thanks for this detailled report.

May I ask how you did you tests? I can't find cus-test.el in my Emacs.

I've attached a diff patch where I fix some of this.

 Package: org-mode

 cus-test.el suggests the following variables may have incorrect
 custom :types. (There may be some false positives.)
 This refers to Org mode in current Emacs trunk.

 Eg, org-footnote-auto-adjust does not have nil as an option.

 org-refile-target-verify-function
It's a function with no function by default and I don't know how to fix
it. Should we use '(choice function nil)?

 org-icalendar-combined-description
Seems fine to me.

 org-link-frame-setup
Patched (I've only interferred the functions name could VM users
confirmed that they are correct).

 org-export-with-archived-trees
Patched.

 org-bibtex-prefix
It's suppose to be a string and after a quick look at the code I think
it's safe to set it to nil but I'm not sure.

 org-log-note-headings
Patched.

 org-structure-template-alist
Patched.

 org-export-html-postamble-format
I think it's named `org-html-postamble-format' in master. The docstring
and the type talks about an alist but the default value is not. I don't
know which one is correct (the default value or the description).

 org-get-priority-function
Same problem than `org-refile-target-verify-function'.

 org-export-odt-content-template-file
Now `org-odt-content-template-file', the type is a file but the default
value is nil. Should we use '(choice file nil)?

 org-export-latex-quotes
I couldn't find this variable in master.

 org-export-html-toplevel-hlevel
Now `org-html-toplevel-hlevel' and it doesn't seem to be wrong.

 org-agenda-ndays
The type is an integer but the default value is nil. Should we use
'(choice integer nil)?

I've just seen Carsten's mail so I'll stop here.

 org-export-initial-scope
 org-plantuml-jar-path
 org-export-blocks-witheld
 org-make-link-description-function
 org-export-html-postamble
 org-babel-lob-files
 org-agenda-export-html-style
 org-clock-heading-function
 org-show-notification-handler
 org-agenda-custom-commands
 org-beamer-outline-frame-options
 org-agenda-day-face-function
 org-use-fast-tag-selection
 org-export-docbook-xsl-fo-proc-command
 org-link-translation-function
 org-export-docbook-xslt-stylesheet
 org-export-docbook-xslt-proc-command
 org-columns-modify-value-for-display-function
 org-export-html-preamble-format
 org-agenda-auto-exclude-function
 org-export-docbook-doctype
 org-wl-namazu-default-index
 org-agenda-inactive-leader
 org-export-ascii-underline
 org-sparse-tree-default-date-type
 org-footnote-auto-adjust
 org-protocol-default-template-key



defcustom-fixes.path
Description: Binary data

-- 
Daimrod/Greg


pgp38ECem9JSK.pgp
Description: PGP signature