Re: [O] [PATCH] Fix ORG-NEWS typo from 173b0cb6d6

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> The attached patch fixes a typo that I made in a NEWS item for a recent
> commit.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] `org-get-category' and `org-entry-get' do not return the same value

[Nicolas Goaziou]

Hello,

Samuel Loury  writes:

> I use the version cd6fa4c15e8e35afa6beb9e89ad3723fb82df091 (git sha) of
> org-mode.
>
> Let's say I have a file looking like this:
>
> #+CATEGORY: c
> * foo
>   :PROPERTIES:
>   :CATEGORY: a
>   :END:
> ** bar
>:PROPERTIES:
>:CREATED:  [2015-01-30 Fri 08:37]
>:END:
>
> With the point on bar, `org-get-category' returns "a" while
> (org-entry-get (point) "CATEGORY" t) returns "c". Notice that it returns
> "c" even if the third argument is INHERIT.

This should be fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-expiry not compatible with the new drawer syntax

[Nicolas Goaziou]

Hello,

Samuel Loury  writes:

> I just realized that when creating a new entry in my org-diary
> (`org-agenda-add-entry-to-org-agenda-diary-file'), the entry looks like:
>
> ** test
>   <2015-01-30 Fri>
>:PROPERTIES:
>:CREATED:  [2015-01-30 Fri 08:00]
>:END:
>
> The property is added by an call to `org-expiry-insert-created' in the
> `org-insert-heading-hook'. see in contrib/lisp/org-expiry.el:179
>
> With more details:
>
> In the process in inserting the diary entry,
> `org-agenda-add-entry-to-org-agenda-diary-file'
> calls (lisp/org-agenda.el:9460)
> `org-agenda-insert-diary-as-top-level' (lisp/org-agenda.el:9479).
>
> The later then calls `org-insert-heading' (calling the org-expiry hook
> that creates the property drawer), and inserts the text of the heading
> followed by a new line, resulting in the insertion of:

Actually, AFAICT, the sole function calling `org-insert-heading' in
"org-agenda.el" is `org-agenda-insert-diary-make-new-entry'. I fixed it
so it properly puts point on the right spot in the entry.

Does it fix your issue?

> My opinion is that we should either consider that adding a property in
> `org-insert-heading-hook' is a bad practice or change the functions that
> create entries to make sure they move beyond a potentially created
> properties drawer before adding extra information such as timestamps.
>
> What is your opinion?

If a function calls on `org-insert-heading' and puts point in some
position for further processing, it should take into consideration
meta-data (i.e., planning info and properties drawer).


Regards,

-- 
Nicolas Goaziou

Re: [O] http://orgmode.org/worg/code/org-info-js/ broken

[Marco Wahl]

Svjatoslav Agejenko  writes:

> Button "Show Org source" on page
> http://orgmode.org/worg/code/org-info-js/ 
> does not work.

You could try the explicit
http://orgmode.org/worg/code/org-info-js/index.html instead.  The
button's action depends on the concrete form of the URL in particular
the substring "html".


HTH,  Marco
-- 
http://www.wahlzone.de
GPG: 0x49010A040A3AE6F2

Re: [O] [PATCH] org-agenda: Add only-window setup option

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> The variable org-agenda-window-setup provides several different options
> (current-window, other-window, reorganize-frame, other-frame).  For a
> while now, I've been using a different setup that deletes all other
> windows.  The attached patch adds this option to
> org-agenda-window-setup.
>
> Do others think this option is worth having?

It looks good. I applied it. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org.el: org-babel-load-file loads first tangle file

[Nicolas Goaziou]

Hello,

Sami Airaksinen  writes:

> I use quite sophisticated (read complicated) initialization of my emacs.
> Now I finally updated my emacs and org-mode upto date and found out that
> org-babel-load-file doesn't work as previously.
>
> I don't know if you have already noticed but if your tangled source
> org-mode file has multiple target files for the tangle blocks, it loads
> the file which was found last. This most often isn't the file name that
> was given as input. There could be more generic solution to this, but I
> though that it might be best to keep this patching simple as possible.
>
> This is my first patch proposal so I hope I'm doing right and adding it
> as an attachment to this post

It looks good, thank you.

However, could you also add a comment above the modified line in order
to explain the car+last call?

[...]

> Suggestion from a patch proposal by Sami Airaksinen

The line above is not necessary since you're the author of the patch
anyway.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-expiry not compatible with the new drawer syntax

[Samuel Loury]

Thank you for taking into account this problem.

Nicolas Goaziou  writes:

> Samuel Loury  writes:
>
>> I just realized that when creating a new entry in my org-diary
>> (`org-agenda-add-entry-to-org-agenda-diary-file'), the entry looks like:
>>
>> ** test
>>   <2015-01-30 Fri>
>>:PROPERTIES:
>>:CREATED:  [2015-01-30 Fri 08:00]
>>:END:
>>
>> The property is added by an call to `org-expiry-insert-created' in the
>> `org-insert-heading-hook'. see in contrib/lisp/org-expiry.el:179
>>
>> With more details:
>>
>> In the process in inserting the diary entry,
>> `org-agenda-add-entry-to-org-agenda-diary-file'
>> calls (lisp/org-agenda.el:9460)
>> `org-agenda-insert-diary-as-top-level' (lisp/org-agenda.el:9479).
>>
>> The later then calls `org-insert-heading' (calling the org-expiry hook
>> that creates the property drawer), and inserts the text of the heading
>> followed by a new line, resulting in the insertion of:
>
> Actually, AFAICT, the sole function calling `org-insert-heading' in
> "org-agenda.el" is `org-agenda-insert-diary-make-new-entry'. I fixed it
> so it properly puts point on the right spot in the entry.

The function `org-agenda-insert-diary-as-top-level' is a few line above
the one you patched.

I copied the code you've written in
`org-agenda-insert-diary-make-new-entry' and I've put it in
`org-agenda-insert-diary-as-top-level'. This fixes my problem. Please
find attached the associated patch.
From d826e7b8d4208a2cd9129c0b9f411aa662e6d67d Mon Sep 17 00:00:00 2001
From: Konubinix 
Date: Fri, 30 Jan 2015 11:19:45 +0100
Subject: [PATCH] Fix `org-agenda-insert-diary-as-top-level'

* lisp/org-agenda.el (org-agenda-insert-diary-as-top-level): Ensure
  point is at a real body line and not in front of meta data, so
  regular contents can be inserted safely after a call to this
  function.
---
 lisp/org-agenda.el | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e719c00..ed882ae 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9489,7 +9489,13 @@ a timestamp can be added there."
   (goto-char (point-max))
   (or (bolp) (insert "\n"))
   (org-insert-heading)
-  (insert text "\n")
+  (insert text)
+  (forward-line)
+  (when (org-looking-at-p org-planning-line-re) (forward-line))
+  (when (looking-at org-property-drawer-re)
+(goto-char (match-end 0))
+(forward-line))
+  (unless (bolp) (insert "\n"))
   (if org-adapt-indentation (org-indent-to-column 2)))
 
 (defun org-agenda-insert-diary-make-new-entry (text)
-- 
2.1.4


>> My opinion is that we should either consider that adding a property in
>> `org-insert-heading-hook' is a bad practice or change the functions that
>> create entries to make sure they move beyond a potentially created
>> properties drawer before adding extra information such as timestamps.
>>
>> What is your opinion?
>
> If a function calls on `org-insert-heading' and puts point in some
> position for further processing, it should take into consideration
> meta-data (i.e., planning info and properties drawer).
I suggest to provide a helper that would move point after the meta-data
part to avoid code duplication. Something like (no surprise :-)):
--8<---cut here---start->8---
(defun org-goto-after-metadata-part ()
  (when (org-looking-at-p org-planning-line-re) (forward-line))
  (when (looking-at org-property-drawer-re)
(goto-char (match-end 0))
(forward-line)))
--8<---cut here---end--->8---

I would have gladly provided a patch myself but I couldn't find neither
a good name for the function nor a correct location to store it. Should
it be in org.el? It is already 24850 lines long...

My best :-),
-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature

Re: [O] org-expiry not compatible with the new drawer syntax

[Samuel Loury]

Samuel Loury  writes:

> Nicolas Goaziou  writes:
>
>> Samuel Loury  writes:
>>
>>> I just realized that when creating a new entry in my org-diary
>>> (`org-agenda-add-entry-to-org-agenda-diary-file'), the entry looks like:
>>>
>>> ** test
>>>   <2015-01-30 Fri>
>>>:PROPERTIES:
>>>:CREATED:  [2015-01-30 Fri 08:00]
>>>:END:
>>>
>>> The property is added by an call to `org-expiry-insert-created' in the
>>> `org-insert-heading-hook'. see in contrib/lisp/org-expiry.el:179
>>>
>>> With more details:
>>>
>>> In the process in inserting the diary entry,
>>> `org-agenda-add-entry-to-org-agenda-diary-file'
>>> calls (lisp/org-agenda.el:9460)
>>> `org-agenda-insert-diary-as-top-level' (lisp/org-agenda.el:9479).
>>>
>>> The later then calls `org-insert-heading' (calling the org-expiry hook
>>> that creates the property drawer), and inserts the text of the heading
>>> followed by a new line, resulting in the insertion of:
>>
>> Actually, AFAICT, the sole function calling `org-insert-heading' in
>> "org-agenda.el" is `org-agenda-insert-diary-make-new-entry'. I fixed it
>> so it properly puts point on the right spot in the entry.
>
> The function `org-agenda-insert-diary-as-top-level' is a few line above
> the one you patched.
>
> I copied the code you've written in
> `org-agenda-insert-diary-make-new-entry' and I've put it in
> `org-agenda-insert-diary-as-top-level'. This fixes my problem. Please
> find attached the associated patch.

I just realized that the call to `org-insert-heading' was into one of my
local patches.

Actually, I think this patch may be worth applying to prior to the one I
just sent.

Please, find it attached to this email.
From b975ff7630dcf289a795a9eb0ec6f449d0efd621 Mon Sep 17 00:00:00 2001
From: Konubinix 
Date: Thu, 6 Nov 2014 11:02:23 +0100
Subject: [PATCH] Make use of `org-insert-heading' instead of inserting the *
 character

* lisp/org-agenda.el (org-agenda-insert-diary-as-top-level): Make
  use of `org-insert-heading' instead of inserting the * character

Therefore, the hooks associated to the insertion of a heading will
be triggered.
---
 lisp/org-agenda.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b83c331..e719c00 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9488,7 +9488,8 @@ a timestamp can be added there."
   (widen)
   (goto-char (point-max))
   (or (bolp) (insert "\n"))
-  (insert "* " text "\n")
+  (org-insert-heading)
+  (insert text "\n")
   (if org-adapt-indentation (org-indent-to-column 2)))
 
 (defun org-agenda-insert-diary-make-new-entry (text)
-- 
2.1.4


It makes sure the `org-insert-heading' is called instead of hard-coding
its behavior by inserting the "*" character. I initially made this patch
to make sure the org-expiry hook is called whenever I create diary
entries.

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature

Re: [O] parser: verbatim or code?

[Sebastien Vauban]

Aaron Ecay wrote:
> 2015ko urtarrilak 23an, Sebastien Vauban-ek idatzi zuen:
>>> Since = and ~ have been inverted, I think it'd make sense to make
>>> `org-babel-inline-result-wrap' now default to "~%s" (instead of
>>> "=%s"), for markup that produces verbatim text.
>> 
>> Here is the patch.
>
> If I understand this thread correctly, = is now consistently
> interpreted as verbatim and ~ as code.  I think verbatim (i.e. the
> status quo) is what makes sense for inline babel results – results are
> not generally speaking code (though of course in special cases they
> can be).
>
> I’m not sure what you mean by
>
>> That will put fix back as what they were for people having different
>> CSS or LaTeX styles applied to both markers.

I mean that some of us may have applied CSS to differentiate among
"code" and "verbatim" in HTML.

Anyway, I do agree with you that defaulting to verbatim (instead of
code) makes more sense, in fact, for results of inline babel code
blocks.

Case closed!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [PATCH] org.el: org-babel-load-file loads first tangle file

[Sami Airaksinen]

I got confused, do you want a comment in the source code or in the commit
message?

So comment in the source code would be something like,
"tangle-file traversal returns reversed list of tangled files and we want
to evaluate the first target"

If explanation is for car+last combo: (car (last ...)) the car is needed
because (last ...) returns the last link which is list of one element.

[O] Org Agenda Mode Line

[Tory S. Anderson]

Suddenly I see my org agenda mode line has, as the buffer name,
*Org Agenda(a:2015-01-24)

I've tried closing and restarting agenda but it persists. What does this mean? 
I can't seem to locate this in the documentation. 

Re: [O] [PATCH] Replace `org-ctrl-c-ctrl-c' by `org-babel-execute-maybe' in tests

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> Attached a patch that I certify working -- I've applied it myself
>> with success on a current master clone.
>
> Thanks.
>
> Good news is that I can apply it. Bad news is that some tests fail.
>
>   5 unexpected results:
>  FAILED  test-org-babel/inline-src_blk-default-results-replace-line-1
>  FAILED  test-org-babel/inline-src_blk-default-results-replace-line-2
>  FAILED  test-org-babel/inline-src_blk-manual-results-replace
>  FAILED  test-org-babel/inline-src_blk-results-raw
>  FAILED  test-org-babel/inline-src_blk-results-silent
>
> Could you look into it?

DONE!

The lines `(should-error (org-ctrl-c-ctrl-c))' hadn't to be replaced,
that's all...

It now passes tests in a breeze.

Best regards,
  Seb

-- 
Sebastien Vauban
>From 2147c1ef85d7f8f8f4a3d54411e0891e4f006c82 Mon Sep 17 00:00:00 2001
From: Sebastien Vauban 
Date: Fri, 30 Jan 2015 14:23:54 +0100
Subject: [PATCH] Replace `org-ctrl-c-ctrl-c' by `org-babel-execute-maybe'

* testing/lisp/test-ob-emacs-lisp.el, test-ob-ruby.el, test-ob.el: Replace `org-ctrl-c-ctrl-c' by `org-babel-execute-maybe'.
---
 testing/lisp/test-ob-emacs-lisp.el | 10 +++---
 testing/lisp/test-ob-ruby.el   |  8 ++---
 testing/lisp/test-ob.el| 62 +++---
 3 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el
index f771ee3..37d52a6 100644
--- a/testing/lisp/test-ob-emacs-lisp.el
+++ b/testing/lisp/test-ob-emacs-lisp.el
@@ -1,6 +1,6 @@
 ;;; test-ob-emacs-lisp.el
 
-;; Copyright (c) 2012, 2013, 2014 Free Software Foundation, Inc.
+;; Copyright (c) 2012-2015 Free Software Foundation, Inc.
 ;; Authors: Eric Schulte, Martyn Jago
 
 ;; This file is not part of GNU Emacs.
@@ -29,7 +29,7 @@
 ;;
 #+end_src"
 (org-babel-next-src-block)
-(org-ctrl-c-ctrl-c)
+(org-babel-execute-maybe)
 (should (re-search-forward "results:" nil t))
 (forward-line)
 (should
@@ -42,7 +42,7 @@
 #+end_src"
 
 (org-babel-next-src-block)
-(org-ctrl-c-ctrl-c)
+(org-babel-execute-maybe)
 (should (re-search-forward "results:" nil t))
 (forward-line)
 (should
@@ -56,7 +56,7 @@
 ;;
 #+end_src"
 (org-babel-next-src-block)
-(org-ctrl-c-ctrl-c)
+(org-babel-execute-maybe)
 (re-search-forward "results" nil t)
 (forward-line)
 (should (string=
@@ -69,7 +69,7 @@
 2;;
 #+end_src"
 (org-babel-next-src-block)
-(org-ctrl-c-ctrl-c)
+(org-babel-execute-maybe)
 (re-search-forward "results" nil t)
 (forward-line)
 (should (string=
diff --git a/testing/lisp/test-ob-ruby.el b/testing/lisp/test-ob-ruby.el
index ee7e837..eb5233b 100644
--- a/testing/lisp/test-ob-ruby.el
+++ b/testing/lisp/test-ob-ruby.el
@@ -1,6 +1,6 @@
 ;;; test-ob-ruby.el --- tests for ob-ruby.el
 
-;; Copyright (c) 2013 Oleh Krehel
+;; Copyright (c) 2013-2015 Oleh Krehel
 ;; Authors: Oleh Krehel
 
 ;; This program is free software; you can redistribute it and/or modify
@@ -28,7 +28,7 @@ s = \"2\"
 s = \"3\"
 puts s
 #+end_src"
-  (org-ctrl-c-ctrl-c)
+  (org-babel-execute-maybe)
   (substring-no-properties
(buffer-string)))
 		   "#+begin_src ruby :session :results output
@@ -47,7 +47,7 @@ puts s
 s = \"5\"
 puts s
 #+end_src"
-  (org-ctrl-c-ctrl-c)
+  (org-babel-execute-maybe)
   (substring-no-properties
(buffer-string)))
 		   "#+begin_src ruby :session :results output
@@ -63,7 +63,7 @@ puts s
 (should (equal (org-test-with-temp-text "#+begin_src ruby :session :results output
 puts s
 #+end_src"
-  (org-ctrl-c-ctrl-c)
+  (org-babel-execute-maybe)
   (substring-no-properties
(buffer-string)))
 		   "#+begin_src ruby :session :results output
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index a7e2fbe..3051990 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -1,6 +1,6 @@
 ;;; test-ob.el --- tests for ob.el
 
-;; Copyright (c) 2010-2014 Eric Schulte
+;; Copyright (c) 2010-2015 Eric Schulte
 ;; Authors: Eric Schulte, Martyn Jago
 
 ;; This file is not part of GNU Emacs.
@@ -299,18 +299,18 @@ this is simple"
 ;; src_ at bol line 1...
 (org-test-with-temp-text
 	test-line
-  (goto-char (point-min)) (org-ctrl-c-ctrl-c)
+  (goto-char (point-min)) (org-babel-execute-maybe)
   (should (string=
   (concat test-line " {{{results(=1=)}}}")
	   (buffer-substring-no-properties (point-at-bol) (point-at-eol
-  (forward-char) (org-ctrl-c-ctrl-c)
+  (forward-char) (org-babel-execute-maybe)
   (should (string=
   (concat test-line " {{{results(=1=)}}}")
	   (buffer-substring-no-properties (point-at-bol) (point-at-eol
   (re-search-forward "{{{")
  ;;(should-error (org-ctrl-c-ctrl-c))
   (backward-char 4) ;; last char of block body
-  (org-ctrl-c-ctrl-c)
+  (org-babel-execute-maybe)
   (should (strin

Re: [O] 63 failures for org-test-run-all-tests in an Emacs GUI

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> Here is a patch you can apply with no problem -- just checked it on
>> a fresh copy of master.
>
> Thanks.
>
> I can apply it but it introduces test failures.
>
>FAILED  ob-shell/generic-uses-no-arrays
>FAILED  ob-shell/generic-uses-no-assoc-arrays
>FAILED  ob-tangle/continued-code-blocks-w-noweb-ref
>FAILED  test-ob/specific-colnames
>
> Could you look into it?

I only see 3 problems right now (not `test-ob/specific-colnames'
anymore!?).

Regarding `ob-tangle/continued-code-blocks-w-noweb-ref', it's because
some `babel.shell' is now created (from a tangle operation) and is
inserted in the test in question:

  ┌
  │ (ert-deftest ob-tangle/continued-code-blocks-w-noweb-ref ()
  │   "Test that the :noweb-ref header argument is used correctly."
  │   (org-test-at-id "54d68d4b-1544-4745-85ab-4f03b3cbd8a0"
  │ (let ((tangled
  │"df|sed '1d'|awk '{print $5 \" \" $6}'|sort -n |tail -1|awk '{print 
$2}'"))
  │   (org-narrow-to-subtree)
  │   (org-babel-tangle)
  │   (with-temp-buffer
  │ (insert-file-contents "babel.shell") ;  was babel.sh
  │ (goto-char (point-min))
  │ (should (re-search-forward (regexp-quote tangled) nil t)))
  │   (delete-file "babel.shell" ;  was babel.sh
  └

Changing the file extension in the above test makes the problem
disappears, though I'm not sure it's the cleanest way to do it: the
shell block should be tangled to a file with the `sh' extension in the
first place, but why isn't it still the case?

Regarding `ob-shell/generic-uses-no-arrays' and
`ob-shell/generic-uses-no-assoc-arrays', they both make use of the code
block defined in the file `testing/examples/ob-shell-test.org':

  ┌
  │ * Array tests
  │   :PROPERTIES:
  │   :ID:   0ba56632-8dc1-405c-a083-c204bae477cf
  │   :END:
  │ ** Generic shell: no arrays
  │ #+begin_src shell :exports results :var array=sample_array
  │ # ^^^ was sh only
  │ echo ${array}
  │ #+end_src
  └

Still, I don't understand what's wrong in the tests, for example here
in `ob-shell/generic-uses-no-arrays':

  ┌
  │ ; A list of tests using the samples in ob-shell-test.org
  │ (ert-deftest ob-shell/generic-uses-no-arrays ()
  │   "No arrays for generic"
  │   (org-test-at-id "0ba56632-8dc1-405c-a083-c204bae477cf"
  │ (org-babel-next-src-block)
  │ (should (equal "one two three" (org-babel-execute-src-block)
  └

Any hint?

PS- Two tests are defined under the same name:

--8<---cut here---start->8---
./test-ob-shell.el:63:(ert-deftest ob-shell/generic-uses-no-assoc-arrays ()
./test-ob-shell.el:76:(ert-deftest ob-shell/generic-uses-no-assoc-arrays ()
--8<---cut here---end--->8---

Isn't there any protection mechanism against test name duplicates?

Best regards,
  Seb

[O] ERT test for checking HTML export: void-variable org-export-filters-alist

[Sebastien Vauban]

Hello,

I try to define an ERT test so that I can check that the new export of
some test file gives me the same HTML output (to the byte!) than the
export done in the past (and present onto disk).

Here is my code to do so:

--8<---cut here---start->8---
(require 'ox)

(defun compare-org-html-export-files (orgfile)
  "Compare current export of ORGFILE with HTML file already present on disk."
  (let* ((base-name
  (concat (file-name-directory orgfile) (file-name-base orgfile)))
 (htmlfile (concat base-name ".html"))
 htmlcontents)
(should
 (equal
  ;; new export
  (with-temp-buffer
(insert-file-contents orgfile)
(setq htmlcontents (org-export-as 'html))
(delete-region (point-min) (point-max))
(insert htmlcontents)
(buffer-string))
  ;; old export
  (with-temp-buffer
(insert-file-contents htmlfile)
(buffer-string))

(ert-deftest org-export/export-html-test-file ()
  (compare-org-html-export-files "~/test.org"))
--8<---cut here---end--->8---

I don't understand, though, the error that I always get:

--8<---cut here---start->8---
Selector: org-export/export-html-test-file
Passed:  0
Failed:  1 (1 unexpected)
Skipped: 0
Total:   1/1

Started at:   2015-01-30 15:30:56+0100
Finished.
Finished at:  2015-01-30 15:30:56+0100

F

F org-export/export-html-test-file
Compare current export of ORGFILE with HTML file already present on disk.
(void-variable org-export-filters-alist)
--8<---cut here---end--->8---

Any idea why the variable `org-export-filters-alist' is said to be void,
while I explicitly load both `ox' (where it's defined) and `ox-html'?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] ERT test for checking HTML export: void-variable org-export-filters-alist

[Sebastien Vauban]

Hello,

Sebastien Vauban wrote:
> Here is my code to do so:
>
> (require 'ox)
>
> (defun compare-org-html-export-files (orgfile)
>   "Compare current export of ORGFILE with HTML file already present on disk."
>   (let* ((base-name
>   (concat (file-name-directory orgfile) (file-name-base orgfile)))
>  (htmlfile (concat base-name ".html"))
>  htmlcontents)
> (should
>  (equal
>   ;; new export
>   (with-temp-buffer
> (insert-file-contents orgfile)
> (setq htmlcontents (org-export-as 'html))
> (delete-region (point-min) (point-max))
> (insert htmlcontents)
> (buffer-string))
>   ;; old export
>   (with-temp-buffer
> (insert-file-contents htmlfile)
> (buffer-string))
>
> Any idea why the variable `org-export-filters-alist' is said to be void,
> while I explicitly load both `ox' (where it's defined) and `ox-html'?

And adding the require of `ox' and/or `ox-html' inside the test (or the
defun `compare-org-html-export-files') does not change anything.

Best regards,
  Seb

-- 
Sebastien Vauban

[O] idempotency and inconsistency for org-babel-remove-inline-result

[Daniele Pizzolli]

Hello,

I really like the new inline results.  Thanks for this new cool feature.
I have only a few problems with it.

Is there a way to evaluate a buffer an then remove inline results or
better, to get the very same buffer after:

(org-babel-execute-buffer)
(org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))

Every call add an extra white space:

Original:

1 + 4 in R is src_R[:exports results]{1+4}.

After (org-babel-execute-buffer):

1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.

After: (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))

1 + 4 in R is src_R[:exports results]{1+4} .

After (org-babel-execute-buffer):

1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}} .

And so on...

I see that the function docs says: Extraneous leading whitespace is
trimmed. Is this the intended result?


Also, is there anything that prevents to make
org-babel-remove-inline-result interactive as is
org-babel-remove-result?  Wwhy not have also
org-babel-remove-inline-result-one-or-many and
org-babel-remove-all-result-one-or-many to remove all the babel result
with one function call?

I do no not know lisp a lot, but I can try to submit a patch if you
agree that will be useful.

Thanks in advance,
Daniele

[O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file

[Fabrice Niessen]

Eli Zaretskii wrote:
>> From: Fabrice Niessen 
>> Cc: dgu...@yandex.ru,  19...@debbugs.gnu.org
>> Date: Fri, 16 Jan 2015 13:04:00 +0100
>> 
>> (gdb) thread 1
>> [Switching to thread 1 (Thread 17252.0x44f0)]
>> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>> prop=62947906, object=118795585, limit=limit@entry=1356)
>> at ../../emacs-24.4/src/textprop.c:1034
>> 1034../../emacs-24.4/src/textprop.c: No such file or directory.
>> (gdb) backtrace
>> #0  0x01142191 in Fnext_single_property_change (position=position@entry=540,
>> prop=62947906, object=118795585, limit=limit@entry=1356)
>> at ../../emacs-24.4/src/textprop.c:1034
>> #1  0x0102e54f in handle_invisible_prop (it=0x889a14)
>> at ../../emacs-24.4/src/xdisp.c:4379
>> #2  0x01022e18 in handle_stop (it=it@entry=0x889a14)
>> at ../../emacs-24.4/src/xdisp.c:3478
>> #3  0x010231e9 in next_element_from_string (it=0x889a14)
>> at ../../emacs-24.4/src/xdisp.c:7915
>> #4  0x01025e1c in get_next_display_element (it=it@entry=0x889a14)
>> at ../../emacs-24.4/src/xdisp.c:6925
>> #5  0x0102b00f in display_line (it=)
>> at ../../emacs-24.4/src/xdisp.c:20183
>> #6  0x in ?? ()
>
> Looks like an infloop due to display or overlay strings with text
> properties.  Can you reproduce this in an unoptimized build?

Here it is (with GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2015-01-28 on
LEG570):

--8<---cut here---start->8---
$ gdb -p 8340
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
/cygdrive/d/Users/fni/.gdbinit:19: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.
Attaching to process 8340
[New Thread 8340.0x2568]
[New Thread 8340.0x32f0]
[New Thread 8340.0x1b00]
[New Thread 8340.0x2860]
[New Thread 8340.0x2244]
[New Thread 8340.0xfdc]
[New Thread 8340.0x2d04]
[New Thread 8340.0x2288]
[New Thread 8340.0x4fc]
[New Thread 8340.0x29a8]
[New Thread 8340.0x1980]
[New Thread 8340.0x3b68]
[New Thread 8340.0x1030]
[New Thread 8340.0x36b0]
Reading symbols from /cygdrive/c/Program Files 
(x86)/emacs-trunk/bin/emacs.exe...done.
0x7758f925 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 8340.0x2568)]
#0  0x01101915 in XSTRING (a=168379948) at C:/emacs/repo/src/lisp.h:974
(gdb) 974   C:/emacs/repo/src/lisp.h: No such file or directory.
backtrace
#0  0x01101915 in XSTRING (a=168379948) at C:/emacs/repo/src/lisp.h:974
#1  0x01103beb in set_string_intervals (s=168379948, i=0xe3f8b54) at 
C:/emacs/repo/src/lisp.h:3419
#2  0x01200220 in balance_possible_root_interval (interval=0xe3f8b54) at 
C:/emacs/repo/src/intervals.c:492
#3  0x01200726 in find_interval (tree=0xe3f8b54, position=135) at 
C:/emacs/repo/src/intervals.c:676
#4  0x01205d13 in validate_interval_range (object=168379948, begin=0x88b320, 
end=0x88b320, force=false) at C:/emacs/repo/src/textprop.c:194
#5  0x0120881d in Fnext_single_property_change (position=542, prop=18880, 
object=168379948, limit=1358) at C:/emacs/repo/src/textprop.c:1029
#6  0x01031bdf in handle_invisible_prop (it=0x88c0b0) at 
C:/emacs/repo/src/xdisp.c:4280
#7  0x0102fa80 in handle_stop (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:3377
#8  0x0103b998 in next_element_from_string (it=0x88c0b0) at 
C:/emacs/repo/src/xdisp.c:7803
#9  0x01039412 in get_next_display_element (it=0x88c0b0) at 
C:/emacs/repo/src/xdisp.c:6835
#10 0x01063121 in display_line (it=0x88c0b0) at C:/emacs/repo/src/xdisp.c:20151
#11 0x01057332 in try_window (window=24604037, pos=..., flags=1) at 
C:/emacs/repo/src/xdisp.c:16911
#12 0x010540b3 in redisplay_window (window=24604037, just_this_one_p=true) at 
C:/emacs/repo/src/xdisp.c:16384
#13 0x0104c66b in redisplay_window_1 (window=24604037) at 
C:/emacs/repo/src/xdisp.c:14216
#14 0x0119e4c4 in internal_condition_case_1 (bfun=0x104c635 
, arg=24604037, handlers=22582667, hfun=0x104c5c3 
) at C:/emacs/repo/src/eval.c:1359
#15 0x0104b9c8 in redisplay_internal () at C:/emacs/repo/src/xdisp.c:13859
#16 0x0104bfb1 in redisplay_preserve_echo_area (from_where=2) at 
C:/emacs/repo/src/xdisp.c:14045
#17 0x0100faf8 in Fredisplay (force=0) at C:/emacs/repo/src/dispnew.c:5796
#18 0x011a18ba in Ffuncall (nargs=1, args=0x88edd0) at 
C:/emacs/repo/src/eval.c:2705
#19 0x011e55cf in exec_byte_code (bytes

Re: [O] [PATCH] org.el: org-babel-load-file loads first tangle file

[Nicolas Goaziou]

Sami Airaksinen  writes:

> I got confused, do you want a comment in the source code or in the commit
> message?

The former.

> So comment in the source code would be something like,
> "tangle-file traversal returns reversed list of tangled files and we want
> to evaluate the first target"

That's fine.

> If explanation is for car+last combo: (car (last ...)) the car is needed
> because (last ...) returns the last link which is list of one element.

No it isn't about car+last but why we're interested in the last element
instead of the first one.

Thanks,

Re: [O] [PATCH] Replace `org-ctrl-c-ctrl-c' by `org-babel-execute-maybe' in tests

[Nicolas Goaziou]

Sebastien Vauban 
writes:

> The lines `(should-error (org-ctrl-c-ctrl-c))' hadn't to be replaced,
> that's all...
>
> It now passes tests in a breeze.

Applied. Thank you.


Regards,

Re: [O] Org Agenda Mode Line

[Kyle Meyer]

torys.ander...@gmail.com (Tory S. Anderson) wrote:
> Suddenly I see my org agenda mode line has, as the buffer name,
> *Org Agenda(a:2015-01-24)
>
> I've tried closing and restarting agenda but it persists. What does
> this mean?

That looks like a buffer name generated when org-agenda-sticky is
non-nil.  The text in parentheses tells you how the command was invoked.
For example, "*Org Agenda(s:term)*" means that after calling org-agenda,
you pressed 's' and searched for 'term'.  In your case, you used the 'a'
key, but I'm uncertain of how the '2015-01-24' was generated.

How are you trying to close the buffer?  With a sticky agenda, 'q' will
just bury the buffer.  You need to press 'Q' or call kill-buffer
directly to actually kill it.

-- 
Kyle

Re: [O] Org Agenda Mode Line

[Tory S. Anderson]

Hey, thanks for telling me about org-agenda-sticky. I'm going to use that in 
the future! Having tested, I seem to have gotten rid of the 2015-01-24 line; I 
notice, though, that it seems to include those messages of one sort or another 
in every case now. By default it now shows *Org Agenda(a)* and using some other 
agenda function will show something else. Is this behavior from a recent patch? 
I don't remember it previously. 


Kyle Meyer  writes:

> torys.ander...@gmail.com (Tory S. Anderson) wrote:
>> Suddenly I see my org agenda mode line has, as the buffer name,
>> *Org Agenda(a:2015-01-24)
>>
>> I've tried closing and restarting agenda but it persists. What does
>> this mean?
>
> That looks like a buffer name generated when org-agenda-sticky is
> non-nil.  The text in parentheses tells you how the command was invoked.
> For example, "*Org Agenda(s:term)*" means that after calling org-agenda,
> you pressed 's' and searched for 'term'.  In your case, you used the 'a'
> key, but I'm uncertain of how the '2015-01-24' was generated.
>
> How are you trying to close the buffer?  With a sticky agenda, 'q' will
> just bury the buffer.  You need to press 'Q' or call kill-buffer
> directly to actually kill it.

Re: [O] org-expiry not compatible with the new drawer syntax

[Nicolas Goaziou]

Samuel Loury  writes:

> I suggest to provide a helper that would move point after the meta-data
> part to avoid code duplication. Something like (no surprise :-)):
> (defun org-goto-after-metadata-part ()
>   (when (org-looking-at-p org-planning-line-re) (forward-line))
>   (when (looking-at org-property-drawer-re)
> (goto-char (match-end 0))
> (forward-line)))

Indeed.

> I would have gladly provided a patch myself but I couldn't find neither
> a good name for the function nor a correct location to store it. Should
> it be in org.el? It is already 24850 lines long...

I changed `org-end-of-meta-data-and-drawers' into
`org-end-of-meta-data'.

Could you merge your other patch and the use of this function?

Thanks,

Re: [O] idempotency and inconsistency for org-babel-remove-inline-result

[Charles C. Berry]

On Fri, 30 Jan 2015, Daniele Pizzolli wrote:


Hello,

I really like the new inline results.  Thanks for this new cool feature.
I have only a few problems with it.



Thanks for your feedback.


Is there a way to evaluate a buffer an then remove inline results or
better, to get the very same buffer after:

(org-babel-execute-buffer)
(org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))

Every call add an extra white space:

Original:

1 + 4 in R is src_R[:exports results]{1+4}.

After (org-babel-execute-buffer):

1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.

After: (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))

1 + 4 in R is src_R[:exports results]{1+4} .

After (org-babel-execute-buffer):

1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}} .

And so on...

I see that the function docs says: Extraneous leading whitespace is
trimmed. Is this the intended result?



It is intended to remove `extraneous' whitespace. But the way
`extraneous' is operationalized leaves something to be desired if
users wish to do as you have done. Maybe preserving whitespace (if any)
after the result and deleting all that is before it might work.

I'll take a look at changing the defn to deal with your ECM.




Also, is there anything that prevents to make
org-babel-remove-inline-result interactive as is
org-babel-remove-result?


AFAICS, no.


Wwhy not have also
org-babel-remove-inline-result-one-or-many and
org-babel-remove-all-result-one-or-many to remove all the babel result
with one function call?


Easy enough, but is this really needed? What about call block/line 
results?




I do no not know lisp a lot, but I can try to submit a patch if you
agree that will be useful.



The main issue (IMO) is figuring out what whitespace to delete around
a `{{{results(...)}}}' macro. I can get to this in a day or so, but
feel free to send a patch.

Chuck

Re: [O] idempotency and inconsistency for org-babel-remove-inline-result

[Daniele Pizzolli]

Hello Charles,

"Charles C. Berry" writes:

> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>
>> Hello,
>>
>> I really like the new inline results.  Thanks for this new cool feature.
>> I have only a few problems with it.
>>
>
> Thanks for your feedback.

Nice to hear.

>> Is there a way to evaluate a buffer an then remove inline results or
>> better, to get the very same buffer after:

[]

>> I see that the function docs says: Extraneous leading whitespace is
>> trimmed. Is this the intended result?
>
> It is intended to remove `extraneous' whitespace. But the way
> `extraneous' is operationalized leaves something to be desired if
> users wish to do as you have done. Maybe preserving whitespace (if any)
> after the result and deleting all that is before it might work.
>
> I'll take a look at changing the defn to deal with your ECM.

Thanks, see later.

>>
>> Also, is there anything that prevents to make
>> org-babel-remove-inline-result interactive as is
>> org-babel-remove-result?
>
> AFAICS, no.

Ok, patch attached.

>> Wwhy not have also
>> org-babel-remove-inline-result-one-or-many and
>> org-babel-remove-all-result-one-or-many to remove all the babel result
>> with one function call?
>
> Easy enough, but is this really needed? What about call block/line
> results?

This is useful for me because I want to easily discard the results to
have the commit with only the changes in the source.  I hope others find
this a reasonable facility.  It is like a 'make clean' for your org
files.

Patch attached.  I am not sure about the default of discarding keyword
Deleting the result line can cause some disorder, but it is the default
in org-babel-remove-result.  Also the naming can be confusing.

>> I do no not know lisp a lot, but I can try to submit a patch if you
>> agree that will be useful.
>>
>
> The main issue (IMO) is figuring out what whitespace to delete around
> a `{{{results(...)}}}' macro. I can get to this in a day or so, but
> feel free to send a patch.

This is above my lisp coding abilities, with too many org-related
function to get lost into org-babel-remove-inline-result...  I can wait,
but if you have any pointer I will be happy to do some exploration.

Thanks again,
Daniele

>From 4f484ac1f9ae4adcf5551bf6e77e5545f124f11b Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli 
Date: Fri, 30 Jan 2015 20:57:15 +0100
Subject: [PATCH 1/2] ob-core.el: add interactive to
 `org-babel-remove-inline-result'

* lisp/ob-core.el (org-babel-remove-inline-result): Add interactive.

TINYCHANGE
---
 lisp/ob-core.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index fcc44c1..ac9f63b 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2324,6 +2324,7 @@ INFO may provide the values of these header arguments (in the
   "Remove the result of the current inline-src-block or babel call.
 The result must be wrapped in a `results' macro to be
   removed. Extraneous leading whitespace is trimmed."
+  (interactive)
   (let* ((el (org-element-context))
 	 (post-blank (org-element-property :post-blank el)))
 (when (memq (org-element-type el) '(inline-src-block inline-babel-call))
-- 
2.1.4

>From b108f6b8dfd28d6c6ebcdfcabb428438fe348ad9 Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli 
Date: Fri, 30 Jan 2015 23:28:27 +0100
Subject: [PATCH 2/2] ob-core.el: Add `org-babel-remove-result-all'

* lisp/ob-core.el (org-babel-remove-result-all): New interactive
  function.

TINYCHANGE
---
 lisp/ob-core.el | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index ac9f63b..e09863d 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2348,6 +2348,16 @@ in the buffer."
   (org-babel-map-src-blocks nil (org-babel-remove-result))
 (org-babel-remove-result)))
 
+(defun org-babel-remove-result-all (x)
+  "Remove the results of all the source blocks and the results of all inline sources.
+If called with a prefix argument, keep the keyword in result
+blocks."
+  (interactive "P")
+  (if x
+  (org-babel-map-src-blocks nil (org-babel-remove-result nil t))
+(org-babel-map-src-blocks nil (org-babel-remove-result)))
+  (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result)))
+
 (defun org-babel-result-end ()
   "Return the point at the end of the current set of results."
   (save-excursion
-- 
2.1.4

[O] C-u org-clock-in-last not moving point

[David Aaron Fendley]

I'm encountering an issue when using C-u org-clock-in-last.

Whenever I select an item from the list, it either clocks me into the
the heading that my cursor is currently on, or it throws an error:

byte-code: Before first headline at position 2123 in buffer


My issue is identical to this unanswerd superuser question:
http://superuser.com/questions/810043/how-do-i-navigate-the-org-mode-clock-history-menu


I'm using version: Org-mode version 8.3beta (release_8.3beta-779-gfe63e5
@ /Users/tricon/.emacs.d/elpa/org-20130527/)

I get the same result with: emacs -q


I've traced through the org-mode code and understand that it attempts to
set a marker in the buffer for the selected heading, later moving the point
to it; but it doesn't appear to be doing so in practice.


Any thoughts?


David

[O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Charles C. Berry]

RFC: the patch to `org-babel-remove-inline-result-one-or-many' 
removes inline results, too.


Do you see any bad consequences?

On Fri, 30 Jan 2015, Daniele Pizzolli wrote:


Hello Charles,

"Charles C. Berry" writes:


On Fri, 30 Jan 2015, Daniele Pizzolli wrote:



[discussion of extra whitespace bug deleted]

There is now a bugfix on master. I've also added 'interactive' to 
`org-babel-remove-inline-result'.





Is there a way to evaluate a buffer an then remove inline results or
better, to get the very same buffer after:




Yes.

See attached patch which should clean *all* results (except `raw' results) 
from a buffer when `org-babel-remove-result-one-or-many' is called with a 
prefix.


Before pushing this, I'd like some feedback on the wisdom of doing what 
the patch does.



Wwhy not have also
org-babel-remove-inline-result-one-or-many and
org-babel-remove-all-result-one-or-many to remove all the babel result
with one function call?


Easy enough, but is this really needed? What about call block/line
results?


This is useful for me because I want to easily discard the results to
have the commit with only the changes in the source.  I hope others find
this a reasonable facility.  It is like a 'make clean' for your org
files.


I think extending `org-babel-remove-all-result-one-or-many' to cover 
inline results is innocuous. So if nobody raises an objection, I will 
push the patch.


I got that you want to clean up your buffer. But an issue with adding 
more functions is 'feature bloat'. If you really need 
`org-babel-remove-result-all' and 
`org-babel-remove-inline-result-one-or-many' you can have private 
functions.




Patch attached.


Thank you.

Regarding patches, if you haven't signed FSF copyright papers a TINYCHANGE 
is needed in the commit message.



I am not sure about the default of discarding keyword
Deleting the result line can cause some disorder, but it is the default
in org-babel-remove-result.  Also the naming can be confusing.


Alas. Then there is the user error I have made of re-using names.

Best,

ChuckFrom af94ed1c07a914ba686076c83a08f80c3b21c32b Mon Sep 17 00:00:00 2001
From: Charles Berry 
Date: Fri, 30 Jan 2015 19:14:51 -0800
Subject: [PATCH 2/2] ob-core.el: `org-babel-remove-result-one-or-many' removes
 inline results

* ob-core.el (org-babel-remove-result-one-or-many): Remove all results
  of babel executables, including inline results.
---
 lisp/ob-core.el | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index ceda1aa..6c8a587 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2339,13 +2339,16 @@ Leading whitespace is trimmed."
(org-element-property :post-blank el)
 
 (defun org-babel-remove-result-one-or-many (x)
-  "Remove the result of the current source block.
-If called with a prefix argument, remove all result blocks
-in the buffer."
+  "Remove the result of the current (inline) source block.
+If called with a prefix argument, remove all result blocks and
+macros in the buffer."
   (interactive "P")
   (if x
-  (org-babel-map-src-blocks nil (org-babel-remove-result))
-(org-babel-remove-result)))
+  (org-babel-map-executables nil
+   (org-babel-remove-result)
+   (org-babel-remove-inline-result))
+(org-babel-remove-result)
+(org-babel-remove-inline-result)))
 
 (defun org-babel-result-end ()
   "Return the point at the end of the current set of results."
-- 
1.9.3 (Apple Git-50)