[O] resize png in org-toggle-latex-fragment

[Uwe Brauer]

Hello

I am using GNU emacs 25.0.50, and 8.3.1.

The png generated ny org-toggle-latex-fragment are too small for my
taste.

I found two solutions
http://emacs.stackexchange.com/questions/3387/how-to-enlarge-latex-fragments-in-org-mode-at-the-same-time-as-the-buffer-text


(defun update-org-latex-fragments ()
  (org-toggle-latex-fragment '(16))
  (plist-put org-format-latex-options :scale text-scale-mode-amount)
  (org-toggle-latex-fragment '(16)))
(add-hook 'text-scale-mode-hook 'update-org-latex-fragments)


(defun update-org-latex-fragment-scale ()
  (let ((text-scale-factor (expt text-scale-mode-step text-scale-mode-amount)))
(plist-put org-format-latex-options :scale (* 4.3 text-scale-factor

(add-hook 'text-scale-mode-hook 'update-org-latex-fragment-scale)

None of them worked for me.

Does somebody know a different one?

Thanks

Uwe Brauer  

Re: [O] Markup (=, ~) in word?

[Göktuğ Kayaalp]

On Thu, Oct 29 2015 at  5:07:55 pm EEST, Rainer M Krug  wrote:
> Göktuğ Kayaalp  writes:
>
>> On Thu, Oct 29 2015 at  2:21:17 pm EEST, Rainer M Krug  
>> wrote:
>>> Matt Price  writes:
>>>
 #+BEGIN_VERBATIM
 simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
 #+END_VERBATIM
>>>
>>> The other way round:
>>>
>>> I want the text, e.g. =SITE= as the markup, and not the whole text as
>>> verbatim - sorry for not being clear about what I want.
>>>
>>> Rainer
>>>
>>
>> AFAIK that is  impossible out of the box, Org  does not allow inter-word
>> markup,  as there  is no  escaping in  the syntax.   In the  thread with
>> subject  *Some  projects* on  this  list  they  talk also  about  adding
>> escaping.  You can still add some inline LaTeX for that though, I think,
>> or  maybe you  can  tweak  `org-emphasis-regexp-components', (also,  see
>> [1]):
>
> Thanks a lot for confirming my suspicion,

You're welcome.  Though I'm not that well-versed in Org, I merely use
it, maybe someone will have a suggestion that's less-known.

-gk

>
> Rainer
>
>>
>> ,[ C-h v org-emphasis-regexp-components RET ]
>> | org-emphasis-regexp-components is a variable defined in `org.el'.
>> | Its value is ("('\"{" "-   .,:!?;'\")}\\" "
>> | ,\"'" "." 1)
>> | 
>> | Documentation:
>> | Components used to build the regular expression for emphasis.
>> | This is a list with five entries.  Terminology:  In an emphasis string
>> | like " *strong word* ", we call the initial space PREMATCH, the final
>> | space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
>> | and "trong wor" is the body.  The different components in this variable
>> | specify what is allowed/forbidden in each part:
>> | 
>> | pre  Chars allowed as prematch.  Beginning of line will be allowed 
>> too.
>> | post Chars allowed as postmatch.  End of line will be allowed too.
>> | border   The chars *forbidden* as border characters.
>> | body-regexp  A regexp like "." to match a body character.  Don't use
>> |  non-shy groups here, and don't allow newline here.
>> | newline  The maximum number of newlines allowed in an emphasis exp.
>> | 
>> | You need to reload Org or to restart Emacs after customizing this.
>> | 
>> | [back]
>> `
>>
>>> [...]
>>
>> [1] http://orgmode.org/worg/dev/org-syntax.html#Emphasis_Markers
>>
>> Regards,
>> -gk

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Andreas,

2015ko urriak 28an, Andreas Leha-ek idatzi zuen:
> 
> Hi all,
> 
> Andreas Leha  writes:
>> Hi all,
>> 
>> babel's :cache seems to be ignored during export.  At least on #+call
>> lines.
>> 
>> In the example below the caching works fine for interactive evaluation,
>> i.e. C-c C-c on the #+call line returns immediately.
>> 
>> If I export the subtree with the #+call line, however, the code block
>> gets executed and the export is slow.

Export works by making a copy of the org buffer, modifying it in some
ways while executing babel code, then exporting the modified buffer
copy.  The modifications can under some circumstances change the
relevant features for the cache, leading to spurious re-evaluation.

I tried to write a patch that would do the buffer modifications in such
a way that they would not affect the cache.  But I was never happy with
the patch, and also could not find a nice simple test case for the
re-evaluation bug.  So this work never went anywhere.  (It was also 2
years ago, so things could have changed quite a bit.)  The simple patch
attached to this message fixes a bug that my testing indicated was
responsible for erroneous re-evaluations at least some of the time.

I personally regard the babel cache as dangerous and unpredictable in
its present form.  You’re much better off using language-specific
caching/memoization features and/or a disciplined regime of manual
reevaluation.

>> 
>> I'd expect no evaluation even during export.
>> 
>> Is this a bug or am I missing something?
>> 
>> Regards,
>> Andreas
>> 
>> PS: The example:
>> 
>> * Test Cached Export
>> ** A long running code block.
>> #+name: foo
>> #+begin_src emacs-lisp :var bar="baz"
>> (sit-for 15)
>> (message "bar=%S" bar)
>> #+end_src
>> 
>> #+RESULTS: foo
>> : bar="baz"
>> 
>> ** Calling
>> 
>> Exporting this subtree will demonstrate my problem.  I expect the call
>> line below to not execute anything.  This works for interactive
>> execution (C-c C-c).  But if I export this subtree only, the code is
>> executed.
>> 
>> This returns immediately thanks to the cached result.
>> #+call: foo("qux") :cache yes
>> 
>> #+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
>> : bar="qux"
> 
> 
> I should have added that adding :eval no-export to the #+call line does
> not help either.

There are two places you could add the :eval option.  See
(info "(org) Evaluating code blocks") .  You may have to experiment with
putting it in one or both places in order to get the desired result.
(If none of the possible combinations works, then it is a bug IMO.)

>From d7355798edc643bbbca7ab1ead2a2e11f37aa64c Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Thu, 29 Oct 2015 13:31:28 +
Subject: [PATCH] babel: fix header arg duplication

* lisp/ob-core.el (org-babel-process-params): Make idempotent.
* testing/lisp/test-ob.el (ob/process-params-no-duplicates): New test.
---
 lisp/ob-core.el |  8 +++-
 testing/lisp/test-ob.el | 12 
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 61753ce..fd6d785 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -1597,7 +1597,13 @@ shown below.
   (cons :result-type  (cond ((member "output" result-params) 'output)
 ((member "value" result-params) 'value)
 (t 'value
- (org-babel-get-header params :var 'other
+ (loop for item in params
+	   unless (memq (car item) '(:colname-names
+ :rowname-names
+ :result-params
+ :result-type
+ :var))
+	   collect item
 
 ;; row and column names
 (defun org-babel-del-hlines (table)
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 508a3ed..c2feb39 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -1477,6 +1477,18 @@ echo \"$data\"
   (should (equal "foo\\\"bar"
 		 (org-babel-script-escape "\"foo\\\"bar\""
 
+(ert-deftest ob/process-params-no-duplicates ()
+(should (equal (org-babel-process-params '((:colname-names . 1)
+   (:rowname-names . 1)
+   (:result-params . 1)
+   (:result-type . 1)
+   (:var . "\"foo\"")))
+   '((:var)
+		 (:colname-names . 1)
+		 (:rowname-names . 1)
+		 (:result-params . 1)
+		 (:result-type . value)
+
 (provide 'test-ob)
 
 ;;; test-ob ends here
-- 
2.6.2


-- 
Aaron Ecay

Re: [O] [PATCH] Prevent overwriting of output files from babel calls with nil result

[Aaron Ecay]

Hi Éibhear,

I’m afraid I don’t understand the problem the patch is trying to fix.
Can you provide a MWE (minimal working example) that illustrates the bug
you’re observing?

Thanks,

-- 
Aaron Ecay

Re: [O] Markup (=, ~) in word?

[Göktuğ Kayaalp]

On Thu, Oct 29 2015 at  2:21:17 pm EEST, Rainer M Krug  wrote:
> Matt Price  writes:
>
>> #+BEGIN_VERBATIM
>> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>> #+END_VERBATIM
>
> The other way round:
>
> I want the text, e.g. =SITE= as the markup, and not the whole text as
> verbatim - sorry for not being clear about what I want.
>
> Rainer
>

AFAIK that is  impossible out of the box, Org  does not allow inter-word
markup,  as there  is no  escaping in  the syntax.   In the  thread with
subject  *Some  projects* on  this  list  they  talk also  about  adding
escaping.  You can still add some inline LaTeX for that though, I think,
or  maybe you  can  tweak  `org-emphasis-regexp-components', (also,  see
[1]):

,[ C-h v org-emphasis-regexp-components RET ]
| org-emphasis-regexp-components is a variable defined in `org.el'.
| Its value is ("   ('\"{" "-   .,:!?;'\")}\\" "
| ,\"'" "." 1)
| 
| Documentation:
| Components used to build the regular expression for emphasis.
| This is a list with five entries.  Terminology:  In an emphasis string
| like " *strong word* ", we call the initial space PREMATCH, the final
| space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
| and "trong wor" is the body.  The different components in this variable
| specify what is allowed/forbidden in each part:
| 
| pre  Chars allowed as prematch.  Beginning of line will be allowed 
too.
| post Chars allowed as postmatch.  End of line will be allowed too.
| border   The chars *forbidden* as border characters.
| body-regexp  A regexp like "." to match a body character.  Don't use
|  non-shy groups here, and don't allow newline here.
| newline  The maximum number of newlines allowed in an emphasis exp.
| 
| You need to reload Org or to restart Emacs after customizing this.
| 
| [back]
`

> [...]

[1] http://orgmode.org/worg/dev/org-syntax.html#Emphasis_Markers

Regards,
-gk

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/

Re: [O] Markup (=, ~) in word?

[Rainer M Krug]

Göktuğ Kayaalp  writes:

> On Thu, Oct 29 2015 at  2:21:17 pm EEST, Rainer M Krug  
> wrote:
>> Matt Price  writes:
>>
>>> #+BEGIN_VERBATIM
>>> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>>> #+END_VERBATIM
>>
>> The other way round:
>>
>> I want the text, e.g. =SITE= as the markup, and not the whole text as
>> verbatim - sorry for not being clear about what I want.
>>
>> Rainer
>>
>
> AFAIK that is  impossible out of the box, Org  does not allow inter-word
> markup,  as there  is no  escaping in  the syntax.   In the  thread with
> subject  *Some  projects* on  this  list  they  talk also  about  adding
> escaping.  You can still add some inline LaTeX for that though, I think,
> or  maybe you  can  tweak  `org-emphasis-regexp-components', (also,  see
> [1]):

Thanks a lot for confirming my suspicion,

Rainer

>
> ,[ C-h v org-emphasis-regexp-components RET ]
> | org-emphasis-regexp-components is a variable defined in `org.el'.
> | Its value is (" ('\"{" "-   .,:!?;'\")}\\" "
> | ,\"'" "." 1)
> | 
> | Documentation:
> | Components used to build the regular expression for emphasis.
> | This is a list with five entries.  Terminology:  In an emphasis string
> | like " *strong word* ", we call the initial space PREMATCH, the final
> | space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
> | and "trong wor" is the body.  The different components in this variable
> | specify what is allowed/forbidden in each part:
> | 
> | pre  Chars allowed as prematch.  Beginning of line will be allowed 
> too.
> | post Chars allowed as postmatch.  End of line will be allowed too.
> | border   The chars *forbidden* as border characters.
> | body-regexp  A regexp like "." to match a body character.  Don't use
> |  non-shy groups here, and don't allow newline here.
> | newline  The maximum number of newlines allowed in an emphasis exp.
> | 
> | You need to reload Org or to restart Emacs after customizing this.
> | 
> | [back]
> `
>
>> [...]
>
> [1] http://orgmode.org/worg/dev/org-syntax.html#Emphasis_Markers
>
> Regards,
> -gk

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] [PATCH] ob-python: Fix python session initialization

[Aaron Ecay]

Hi Grégoire,

I’ve looked at ‘org-babel-python-initiate-session’ and I can’t see an
obvious bug.  Did you come up with a patch to fix the problems you were
seeing?

Thanks,

-- 
Aaron Ecay

Re: [O] problems with export and :cache

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> The simple patch attached to this message fixes a bug that my testing
> indicated was responsible for erroneous re-evaluations at least some
> of the time.

Thank you. A minor comment follows.

>(cons :result-type  (cond ((member "output" result-params) 'output)
>   ((member "value" result-params) 'value)
>   (t 'value
> - (org-babel-get-header params :var 'other
> + (loop for item in params
> +unless (memq (car item) '(:colname-names
> +  :rowname-names
> +  :result-params
> +  :result-type
> +  :var))
> +collect item

Using `loop' here is, IMO, over-doing it. You can use instead, e.g.,

  (org-remove-if
   (lambda (item)
 (memq (car item)
   '(:colname-names :rowname-names :result-params :result-type :var)))
   params)

Another option is to extend `org-babel-get-header' to accept a list of
keys instead of a single key.

In any case, this patch, or a variant thereof, should be applied to
maint.


Regards,

-- 
Nicolas Goaziou

[O] TODO list with future scheduled events excluded

[Georg Otto]

Dear all,

with the TODO list view (org-todo-list) I get all my TODO entries,
including the ones that are scheduled far in the future. This clutters
up this view quite a bit, and I would prefer to have a TODO list with
entries scheduled to future days excluded.

Maybe miss something obvious, but so far I did not find any
solution. Does anybody have an idea?

I am running emacs 24.3.1 and orgmode 7.9.3f 

Cheers,

Georg

Re: [O] resize png in org-toggle-latex-fragment

[Uwe Brauer]

>>> "Uwe" == Uwe Brauer  writes:

   > Hello
   > I am using GNU emacs 25.0.50, and 8.3.1.

   > The png generated ny org-toggle-latex-fragment are too small for my
   > taste.

   > I found two solutions



   > (defun update-org-latex-fragments ()
   >   (org-toggle-latex-fragment '(16))
   >   (plist-put org-format-latex-options :scale text-scale-mode-amount)
   >   (org-toggle-latex-fragment '(16)))
   > (add-hook 'text-scale-mode-hook 'update-org-latex-fragments)

Upgrade, this solution works, but I found out that via
org-format-latex-options

I could have a solution which I like more.

Re: [O] Bug? Improper interaction with python variable _ ?

[Aaron Ecay]

Hi Brian,

2015ko urriak 5an, Brian Beckman-ek idatzi zuen:
> 
> Please see the gist below for a self-explaining example
> copied here for convenience.  Emacs 24.5.1 with org-mode
> 8 something (not sure how to get it to report its exact
> version)... a very late version, I am sure.  Verified with
> no init.el, that is, with emacs -Q
> 
> https://gist.github.com/rebcabin/37f800da658f4b23ceaa
> 
> #+TITLE: Org-Babel Bug?
> #+AUTHOR: Brian Beckman
> #+EMAIL: bc.beck...@gmail.com
> 
> #+BEGIN_SRC emacs-lisp :exports results :results none
>   (setq org-confirm-babel-evaluate nil)
>   (org-babel-map-src-blocks nil (org-babel-remove-result))
> #+end_src
> 
> * Mystery Number 1
> 
> The first line of the first block must be blank, or we must =C-c C-c= the 
> block
> two times. But we want to eval the entire file /via/ =C-c C-v C-b=, and we 
> found
> that the first line must be empty.
> 
> If you =C-c C-v C-b= this entire file, the python session buffer, named
> =*bug-org-babel*=, contains an error message that suggests the variable =_= is
> implicated in an error.
> 
> We expect the value of this first block to be 999.  Make sure that the python
> session is clear by typing =quit()=, then evaluate this entire file by
> =C-c C-v C-b=.

I’m not entirely sure what the error you are seeing is.  I tried running
the below src block both with and without the initial blank line.  In
both cases the result was 999, as expected, and no errors were reported
in the session buffer.

It would be good if you could use M-x org-version to report the exact
version of org you are using.

> 
> #+NAME: probe
> #+BEGIN_SRC python :session bug-org-babel :exports both :results value
> 
>   999
> #+END_SRC
> 
> #+RESULTS: probe
> : 999
> 
> * Mystery Number 2
> 
> Now, we set the value of the variable =_= to something arbitray. In a real
> scenario, this variable may be set casually in a loop or some other context. 
> The
> variable =_= is often recommended for /ad-hoc/ use, as in "don't
> care."

In the python repl, _ is set to the result of the last statement.
ob-python uses that fact to extract the value from the python process.
I would expect that creating an overriding binding of _ would cause
strange problems like the one you reported.  So you should not assign to
_ in babel code.

-- 
Aaron Ecay

[O] Adding user-defined task state for agenda

[Peter Davis]

I'm trying to add a NOTE state so that I can use agenda to quickly view a list 
of notes that I've embedded in various documents. I
have

(setq org-todo-keywords
  '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY" "|" "DONE" 
"DELEGATED" "CANCELLED")))

in my .emacs, and I put

** NOTE This is an example of a note.

But when I view the agenda, I get this:

Global list of TODO items of type: NOTE
Available with `N r': (0)[ALL] (1)TODO (2)DONE (3)NOTE (4)APPT (5)CANCELLED 
(6)FEEDBACK (7)VERIFY (8)DELEGATED

and that's all. I can see that there's a NOTE state, but nothing shows up in 
the list.

Have I overlooked something?

Thank you!

-pd

Re: [O] Adding user-defined task state for agenda

[Peter Davis]

Kyle Meyer  writes:

> Peter Davis  writes:
>
>> I'm trying to add a NOTE state so that I can use agenda to quickly view a 
>> list of notes that I've embedded in various documents. I
>> have
>>
>> (setq org-todo-keywords
>>   '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY" "|" "DONE" 
>> "DELEGATED" "CANCELLED")))
>>
>> in my .emacs, and I put
>>
>> ** NOTE This is an example of a note.
>
> Is the Org heading above in one of your agenda files or in a file that
> you've restricted the agenda to (e.g, with "<")?

Sorry, yes, the heading is in an agenda file. I can see TODOs and DONEs in that 
file.

Thanks,
-pd

Re: [O] TODO list with future scheduled events excluded

[Matt Lundin]

Georg Otto  writes:

> Dear all,
>
> with the TODO list view (org-todo-list) I get all my TODO entries,
> including the ones that are scheduled far in the future. This clutters
> up this view quite a bit, and I would prefer to have a TODO list with
> entries scheduled to future days excluded.
>
> Maybe miss something obvious, but so far I did not find any
> solution. Does anybody have an idea?

You can customize the following variables:

- org-agenda-todo-ignore-scheduled
- org-agenda-todo-ignore-deadlines

E.g.,

(setq org-agenda-todo-ignore-scheduled 'future)

See http://orgmode.org/manual/Global-TODO-list.html

See also the docstrings of the variables for more information.

Matt

Re: [O] problems with export and :cache

[Andreas Leha]

Hi Aaron,

Aaron Ecay  writes:
> Hi Andreas,
>
> 2015ko urriak 28an, Andreas Leha-ek idatzi zuen:
>> 
>> Hi all,
>> 
>> Andreas Leha  writes:
>>> Hi all,
>>> 
>>> babel's :cache seems to be ignored during export.  At least on #+call
>>> lines.
>>> 
>>> In the example below the caching works fine for interactive evaluation,
>>> i.e. C-c C-c on the #+call line returns immediately.
>>> 
>>> If I export the subtree with the #+call line, however, the code block
>>> gets executed and the export is slow.
>
> Export works by making a copy of the org buffer, modifying it in some
> ways while executing babel code, then exporting the modified buffer
> copy.  The modifications can under some circumstances change the
> relevant features for the cache, leading to spurious re-evaluation.
>
> I tried to write a patch that would do the buffer modifications in such
> a way that they would not affect the cache.  But I was never happy with
> the patch, and also could not find a nice simple test case for the
> re-evaluation bug.  So this work never went anywhere.  (It was also 2
> years ago, so things could have changed quite a bit.)  The simple patch
> attached to this message fixes a bug that my testing indicated was
> responsible for erroneous re-evaluations at least some of the time.
>

Thanks a lot.  I applied your patch but it seems that your patch does
not solve the problem in this specific situation.  Or do I miss
something?


> I personally regard the babel cache as dangerous and unpredictable in
> its present form.  You’re much better off using language-specific
> caching/memoization features and/or a disciplined regime of manual
> reevaluation.

I agree and avoid the caching mechanism generally.  But all alternative
approaches do involve more work, so I am regularly tempted to use it
again.

Generally, I think that caching is a sensitive area.  And if we think
that it is unpredictable and advise people to stay off of it, we are
better off removing it than offering it in this state.  At least until
it behaves (more) predictable.


>
>>> 
>>> I'd expect no evaluation even during export.
>>> 
>>> Is this a bug or am I missing something?
>>> 
>>> Regards,
>>> Andreas
>>> 
>>> PS: The example:
>>> 
>>> * Test Cached Export
>>> ** A long running code block.
>>> #+name: foo
>>> #+begin_src emacs-lisp :var bar="baz"
>>> (sit-for 15)
>>> (message "bar=%S" bar)
>>> #+end_src
>>> 
>>> #+RESULTS: foo
>>> : bar="baz"
>>> 
>>> ** Calling
>>> 
>>> Exporting this subtree will demonstrate my problem.  I expect the call
>>> line below to not execute anything.  This works for interactive
>>> execution (C-c C-c).  But if I export this subtree only, the code is
>>> executed.
>>> 
>>> This returns immediately thanks to the cached result.
>>> #+call: foo("qux") :cache yes
>>> 
>>> #+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
>>> : bar="qux"
>> 
>> 
>> I should have added that adding :eval no-export to the #+call line does
>> not help either.
>
> There are two places you could add the :eval option.  See
> (info "(org) Evaluating code blocks") .  You may have to experiment with
> putting it in one or both places in order to get the desired result.
> (If none of the possible combinations works, then it is a bug IMO.)

True.  But can you explain to me why it is not possible to disable the
evaluation of a call line?  If the evaluation of a code block is
disabled (:eval never) there is no evaluation and no results.  If I
specify ':eval never' at the end of the #+call line I do not get any
results either but the called source block is unnecessarily and
unexpectedly evaluated.

So, basically I would argue that

  #+call: foo("qux") :eval never

should do what it says an evaluate never, i.e. it should behave as

  #+call: foo[:eval never]("qux") :eval never

Regards,
Andreas




>
> From d7355798edc643bbbca7ab1ead2a2e11f37aa64c Mon Sep 17 00:00:00 2001
> From: Aaron Ecay 
> Date: Thu, 29 Oct 2015 13:31:28 +
> Subject: [PATCH] babel: fix header arg duplication
>
> * lisp/ob-core.el (org-babel-process-params): Make idempotent.
> * testing/lisp/test-ob.el (ob/process-params-no-duplicates): New test.
> ---
>  lisp/ob-core.el |  8 +++-
>  testing/lisp/test-ob.el | 12 
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
> index 61753ce..fd6d785 100644
> --- a/lisp/ob-core.el
> +++ b/lisp/ob-core.el
> @@ -1597,7 +1597,13 @@ shown below.
>(cons :result-type  (cond ((member "output" result-params) 'output)
>   ((member "value" result-params) 'value)
>   (t 'value
> - (org-babel-get-header params :var 'other
> + (loop for item in params
> +unless (memq (car item) '(:colname-names
> +  :rowname-names
> +  :result-params
> +

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Andreas,

2015ko urriak 29an, Andreas Leha-ek idatzi zuen:
> Thanks a lot.  I applied your patch but it seems that your patch does
> not solve the problem in this specific situation.  Or do I miss
> something?

That patch only solves one possible source of the problem.  There are
others, which are likely affecting you.

> 
> 
>> I personally regard the babel cache as dangerous and unpredictable in
>> its present form.  You’re much better off using language-specific
>> caching/memoization features and/or a disciplined regime of manual
>> reevaluation.
> 
> I agree and avoid the caching mechanism generally.  But all alternative
> approaches do involve more work, so I am regularly tempted to use it
> again.
> 
> Generally, I think that caching is a sensitive area.  And if we think
> that it is unpredictable and advise people to stay off of it, we are
> better off removing it than offering it in this state.  At least until
> it behaves (more) predictable.

I agree.  I would be in favor of putting strong warnings in the
documentation that caching is not to be relied on.  (We shouldn’t
remove it from the codebase entirely for backwards compatibility
reasons.)  But we should hear a consensus from the community before
proceeding down this road.

-- 
Aaron Ecay

Re: [O] Adding user-defined task state for agenda

[Kyle Meyer]

Peter Davis  writes:

> I'm trying to add a NOTE state so that I can use agenda to quickly view a 
> list of notes that I've embedded in various documents. I
> have
>
> (setq org-todo-keywords
>   '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY" "|" "DONE" 
> "DELEGATED" "CANCELLED")))
>
> in my .emacs, and I put
>
> ** NOTE This is an example of a note.

Is the Org heading above in one of your agenda files or in a file that
you've restricted the agenda to (e.g, with "<")?

--
Kyle

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Nicolas,

2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> The simple patch attached to this message fixes a bug that my testing
>> indicated was responsible for erroneous re-evaluations at least some
>> of the time.
> 
> Thank you. A minor comment follows.
> 
>> (cons :result-type  (cond ((member "output" result-params) 'output)
>> ((member "value" result-params) 'value)
>> (t 'value
>> - (org-babel-get-header params :var 'other
>> + (loop for item in params
>> +   unless (memq (car item) '(:colname-names
>> + :rowname-names
>> + :result-params
>> + :result-type
>> + :var))
>> +   collect item
> 
> Using `loop' here is, IMO, over-doing it. You can use instead, e.g.,
> 
>   (org-remove-if
>(lambda (item)
>  (memq (car item)
>'(:colname-names :rowname-names :result-params :result-type :var)))
>params)

OK.  I’ll push this to maint later today.

> 
> Another option is to extend `org-babel-get-header' to accept a list of
> keys instead of a single key.

I’d like to remove this function, actually.  I hate the org functions
that do X most of the time, but the opposite of X when you pass them
an optional argument (in this case the third arg ‘other’).  Almost
all (a couple dozen in total) of the calls to o-b-get-header are in
the context (mapcar #'cdr (org-babel-get-header params :var)).  I’d
like to introduce a function org-babel--get-var-values to cover these
cases, and replace the remaining 2 calls in the codebase (which both
extract :column-names) with assq (since :column-names should appear
maximally once, unlike :var).  The sole use of the evil 'other arg is
refactored away by my patch.

Thoughts?

-- 
Aaron Ecay

[O] small caps

[Matt Price]

do we have a syntax for the "small caps" text attribute in Org? If not,
should we? It is available in odt, html, and latex, and is used in some
bibliographic styles.

m

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

[cesar mena]

On Wed, Oct 28, 2015 at 9:52 AM, Nicolas Goaziou  wrote:
> cesar mena  writes:
>
>> however the face is now `org-scheduled-today, as opposed to
>> `org-scheduled-previously, and the agenda sorting is wrong. instead of
>> bubbling to the top (since it is so late) it is staying within the
>> "scheduled today" range.
>
> I committed another attempt in master. Thank you.
>
> Regards,

hi nicolas, list,

everything works. thank you so much.

nice side-effect: the behaviour now allows one to use non "."
repeaters as a poor man's habit mode since the Sched.x header line
will inform one how many cycles are behind.  it's also much clearer.
before on marking as done, the item will just be automatically
rescheduled again with no feedback as to why.

thanks again.

-cm

Re: [O] small caps

[Nicolas Goaziou]

Hello,

Matt Price  writes:

> do we have a syntax for the "small caps" text attribute in Org?

No, we don't.

> If not, should we?

We cannot have a syntax for everything. A macro can probably replace
missing syntax. Also, you can hijack some emphasis marker (e.g., "+")
and have it do small caps in back-ends that support it (through
a filter, or a dedicated customization, e.g.
`org-latex-text-markup-alist').

Regards,

-- 
Nicolas Goaziou

Re: [O] small caps

[Thomas S . Dye]

Aloha Aaron,

Aaron Ecay  writes:

> Hi Nicolas,
>
> 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
>> 
>> Hello,
>> 
>> Matt Price  writes:
>> 
>>> do we have a syntax for the "small caps" text attribute in Org?
>> 
>> No, we don't.
>> 
>>> If not, should we?
>> 
>> We cannot have a syntax for everything. A macro can probably replace
>> missing syntax. 
>
> This is true.  But small-caps are meaningful in a variety of contexts,
> and they are not a truly new syntax (requiring extra code in the parser),
> but rather can be handled exactly as the other emphasis markers.  (They
> would require support from the exporters of course.)
>
> There’s also no rush.  Maybe we could revisit the question of adding
> small caps after the emphasis changes you indicated in the roadmap
> thread are decided on.  Those might change the cost:benefit evaluation
> for adding this feature.
>
> (FWIW, I’d be in favor of the addition unless some major new consideration
> is introduced by the emphasis changes.  A good proportion of the documents
> I write in Org use small caps somehow.  It would be good to know for how
> many other users that is the case.)

I use them in almost all my archaeology writing where it is conventional
to make AD, BC, and BP small caps.

All the best,
Tom

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

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Nicolas,

2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
> Could these 2 use cases be refactored?
> 
>   (mapcar #'cdr (org-babel-get-header params :var))
> 
> is not very far (but stlightly different) from
> 
>   (cadr (org-babel-get-header params :colname-names))
> 
> when there is a single association in PARAMS. Otherwise, it is up to the
> user to know that there can be multiple :var keys but only
> one :column-names.

But users know that anyway, since it’s implied by the semantics of
:colname-names.  Actually the most typical way of accessing the value
of :colname-names in the code is (cdr (assoc :colname-names params))
(~20 uses, which ought to use assq instead); using o-b-get-header for
:colname-names is an exception.

The issue is that o-b-g-h gives an API for accessing key-values in a
1:many mapping.  But :var is the only key that can actually be 1:many.
All other keys are singletons, and can be handled through the usual
emacs API for 1:1 mappings (assq and friends) – and in the existing
codebase they often are.  If we provide an API within babel, we should
make it as specific as possible.

(OTOH if we provide 1:many mapping access, we should name it
org-assq-multiple or something like that.  But it’s unnecessary in this
case.)

-- 
Aaron Ecay

Re: [O] Adding user-defined task state for agenda

[Peter Davis]

Kyle Meyer  writes:

> Peter Davis  writes:
>
>> Kyle Meyer  writes:
>>
>>> Peter Davis  writes:
>>>
 I'm trying to add a NOTE state so that I can use agenda to quickly view a 
 list of notes that I've embedded in various documents. I
 have

 (setq org-todo-keywords
   '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY" "|" "DONE" 
 "DELEGATED" "CANCELLED")))

 in my .emacs, and I put

 ** NOTE This is an example of a note.
>>>
>>> Is the Org heading above in one of your agenda files or in a file that
>>> you've restricted the agenda to (e.g, with "<")?
>>
>> Sorry, yes, the heading is in an agenda file. I can see TODOs and DONEs in 
>> that file.
>
> Hmm.. when I set org-todo-keywords to the value above, headings with the
> NOTE keyword show up.  Can you reproduce it with emacs -Q and a minimal
> Org configuration?

I'm not sure how to do that.

> What version of Org are you using?

8.3.2

Thanks,
-pd

Re: [O] small caps

[Aaron Ecay]

Hi Nicolas,

2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Matt Price  writes:
> 
>> do we have a syntax for the "small caps" text attribute in Org?
> 
> No, we don't.
> 
>> If not, should we?
> 
> We cannot have a syntax for everything. A macro can probably replace
> missing syntax. 

This is true.  But small-caps are meaningful in a variety of contexts,
and they are not a truly new syntax (requiring extra code in the parser),
but rather can be handled exactly as the other emphasis markers.  (They
would require support from the exporters of course.)

There’s also no rush.  Maybe we could revisit the question of adding
small caps after the emphasis changes you indicated in the roadmap
thread are decided on.  Those might change the cost:benefit evaluation
for adding this feature.

(FWIW, I’d be in favor of the addition unless some major new consideration
is introduced by the emphasis changes.  A good proportion of the documents
I write in Org use small caps somehow.  It would be good to know for how
many other users that is the case.)

-- 
Aaron Ecay

Re: [O] problems with export and :cache

[Nicolas Goaziou]

Andreas Leha  writes:

> Generally, I think that caching is a sensitive area.  And if we think
> that it is unpredictable and advise people to stay off of it, we are
> better off removing it than offering it in this state.  At least until
> it behaves (more) predictable.

Is it necessarily broken?

I mean, if the hash contains the current parameters and contents of the
current block, along with all hashes contents and parameters of related
code blocks (i.e., called or referenced in the block), shouldn't it be
predictable?

Regards,

Re: [O] [PATCH] Prevent overwriting of output files from babel calls with nil result

[Éibhear]

> Hi Éibhear,
>
> I'm afraid I don't understand the problem the patch is trying to fix.
> Can you provide a MWE (minimal working example) that illustrates the bug
> you're observing?
>
> Thanks,
>
> --
> Aaron Ecay
>

Hi Aaron,

Thanks for getting back to me.

Prerequisites:
- The dot utility from graphvis is available
- org-babel-load-languages includes '(dot . t)

See below for a sample org file.

For org-mode 8.2.10, invoking C-c C-c on the #+BEGIN_SRC line produces a
file called sample-flow.png, representing a simple flow from a "Start"
node to an "End" node.

In org-mode 8.3.1 and 8.3.2, sample-flow.png contains only the text "nil".

I believe the bug to be in `org-babel-execute:emacs-lisp', when the second
parameter to `org-babel-result-cond' is being evaluated. When `result' is
nil, it is converted to "nil", and this is being written into the
sample-flow.png file, overwriting the contents that the dot utility had
created.

My patch prevents a nil result being converted into a text string when
calling `org-babel-result-cond'. I believe this is an appropriate change.

Éibhear

-->8==
* Charts
** Chart from flows
   #+name: chart-from-flows
   #+HEADER: :var nodes=sample-elements graph=sample-connections
ranks=sample-ranks
   #+BEGIN_SRC emacs-lisp :file ./sample-flow.png :colnames yes :exports
results
(org-babel-execute:dot
 (concat
  "digraph {\n"
  "//rankdir=LR;\n" ;; remove comment characters '//' for
horizontal layout; add for vertical layout
  (mapconcat
   (lambda (x)
 (format "%s [label=\"%s\" shape=%s style=\"filled\"
fillcolor=\"%s\"]"
 (car x)
 (nth 1 x)
 (if (string= "" (nth 2 x)) "box" (nth 2 x))
 (if (string= "" (nth 3 x)) "none" (nth 3 x))
 )) nodes "\n")
  "\n"
  (mapconcat
   (lambda (x)
 (format "%s -> %s [taillabel=\"%s\" color=\"%s\" style=\"%s\"]"
 (car x)
 (nth 1 x)
 (nth 2 x)
 (if (string= "" (nth 3 x)) "black" (nth 3 x))
 (if (string= "" (nth 4 x)) "solid" (nth 4 x))
 )) graph "\n")
  "\n"
  (mapconcat
   (lambda (x)
 (format "{rank=%s %s}"
 (if (or (string= "min" (car x)) (string=
"max" (car x))) (car x) (concat "same; " (car
x))) (nth 1 x))) ranks "\n")
  "}\n") params)
   #+END_SRC

   #+RESULTS: chart-from-flows
   [[file:./sample-flow.png]]

** Development process flow
*** Flow elements
#+name: sample-elements
| *node* | *label* | *shape* | *fillcolor* |
|+-+-+-|
| start  | Start   | ellipse | |
| end| End | ellipse | |
*** Flow connections
#+name: sample-connections
| from  | to  | label | colour | style |
|---+-+---++---|
| start | end |   ||   |
*** Flow ranks
#+name: sample-ranks
| anchor | node  |
|+---|
| min| start |
| start  | end   |
-->8==



-- 
Éibhear Ó hAnluain,
Dublin, Ireland
+---++
| e-mail: eibhear@gmail.com | Web: [http://www.gibiris.org/] |
| Twitter: @eibhear | Google+: +Éibhear Ó hAnluain   |
| Mobile: +353 86 856 5666  | VoIP: sip:eibh...@linphone.org |
+---++

Re: [O] small caps

[Nicolas Goaziou]

Aaron Ecay  writes:

> This is true.  But small-caps are meaningful in a variety of contexts,
> and they are not a truly new syntax (requiring extra code in the
> parser),

Of course they do. You need to introduce yet another emphasis marker.


Regards,

Re: [O] Adding user-defined task state for agenda

[Kyle Meyer]

Peter Davis  writes:

> Kyle Meyer  writes:
>
>> Peter Davis  writes:
>>
>>> I'm trying to add a NOTE state so that I can use agenda to quickly view a 
>>> list of notes that I've embedded in various documents. I
>>> have
>>>
>>> (setq org-todo-keywords
>>>   '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY" "|" "DONE" 
>>> "DELEGATED" "CANCELLED")))
>>>
>>> in my .emacs, and I put
>>>
>>> ** NOTE This is an example of a note.
>>
>> Is the Org heading above in one of your agenda files or in a file that
>> you've restricted the agenda to (e.g, with "<")?
>
> Sorry, yes, the heading is in an agenda file. I can see TODOs and DONEs in 
> that file.

Hmm.. when I set org-todo-keywords to the value above, headings with the
NOTE keyword show up.  Can you reproduce it with emacs -Q and a minimal
Org configuration?  What version of Org are you using?

--
Kyle

Re: [O] problems with export and :cache

[Nicolas Goaziou]

Aaron Ecay  writes:

> I’d like to remove this function, actually.  I hate the org functions
> that do X most of the time, but the opposite of X when you pass them
> an optional argument (in this case the third arg ‘other’).

> Almost all (a couple dozen in total) of the calls to o-b-get-header
> are in the context (mapcar #'cdr (org-babel-get-header params :var)).
> I’d like to introduce a function org-babel--get-var-values to cover
> these cases, and replace the remaining 2 calls in the codebase (which
> both extract :column-names) with assq (since :column-names should
> appear maximally once, unlike :var). The sole use of the evil 'other
> arg is refactored away by my patch.
>
> Thoughts?

Could these 2 use cases be refactored?

  (mapcar #'cdr (org-babel-get-header params :var))

is not very far (but stlightly different) from

  (cadr (org-babel-get-header params :colname-names))

when there is a single association in PARAMS. Otherwise, it is up to the
user to know that there can be multiple :var keys but only
one :column-names.

IOW, aren't you after `org-babel-get-header' without the OTHER argument?

Regards,

Re: [O] small caps

[Thomas S . Dye]

Aloha Matt,

Nicolas Goaziou  writes:

> Hello,
>
> Matt Price  writes:
>
>> do we have a syntax for the "small caps" text attribute in Org?
>
> No, we don't.
>

I've been using this export filter, written by Eric Schulte.  It works
fine for my uses.

 Eric Schulte's filter for HTML small caps

#+name: es-small-caps
#+begin_src emacs-lisp
;;; "sc" links for the \sc{} latex command
(defun org-export-html-small-caps (string backend channel)
  (when (org-export-derived-backend-p backend 'html)
(let ((rx "{sc ")
  (fmt "%s"))
  (with-temp-buffer
(insert string)
(goto-char (point-min))
(while (re-search-forward rx nil t)
  (let* ((start (match-beginning 0))
 (end (progn (goto-char start)
 (forward-sexp)
 (point)))
 (content (buffer-substring (+ start 5) (- end 1
(delete-region start end)
(goto-char start)
(insert (format fmt content
(buffer-string)

(add-to-list 'org-export-filter-final-output-functions
 'org-export-html-small-caps)

(defun org-export-latex-sc (tree backend info)
  "Handle sc: links for latex export."
  (org-element-map tree 'link
(lambda (object)
  (when (equal (org-element-property :type object) "sc")
(org-element-insert-before
 (cond
  ((org-export-derived-backend-p backend 'latex)
   (list 'latex-fragment
 (list :value (format "{\\sc %s}"
  (org-element-property :path object))
   :post-blank (org-element-property
:post-blank object
  ((org-export-derived-backend-p backend 'html)
   (list 'export-snippet
 (list :back-end "html"
   :value
   (format "%s"
   (org-element-property :path object))
   :post-blank
   (org-element-property :post-blank object
  (:otherwise
   (error "unsupported backend for `org-export-latex-sc'")))
 object)
(org-element-extract-element object
  tree)

(org-add-link-type "sc")

(add-hook 'org-export-filter-parse-tree-functions
  'org-export-latex-sc)

#+end_src

hth,
Tom

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

Re: [O] Markup (=, ~) in word?

[Charles C. Berry]

On Thu, 29 Oct 2015, Rainer M Krug wrote:


Matt Price  writes:


#+BEGIN_VERBATIM
simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
#+END_VERBATIM


The other way round:

I want the text, e.g. =SITE= as the markup, and not the whole text as
verbatim - sorry for not being clear about what I want.

Rainer





Have a look at the `org-emphasis-regexp-components' docstring. If you feel 
bold (pun intended) you might see if adding '\.' to the first element 
works without causing mayhem elsewhere.


A safer hack might be to use markup like this:

simASM.'=SITE=.'=STRATEGY=.'=BUDGET=.'=FIREREGIME=.'=JOBID=.'=ARRAYID=

and add a filter to remove the apostrophes from the ".'\texttt" or 
".'" that results.


HTH,

Chuck

Re: [O] Adding user-defined task state for agenda

[Kyle Meyer]

Peter Davis  writes:

[...]

>>  Can you reproduce it with emacs -Q and a minimal Org configuration?
>
> I'm not sure how to do that.

You can put something like

(add-to-list 'load-path "/path/to/your/org-mode/lisp/")
(require 'org)

(setq org-todo-keywords
  '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY"
  "|" "DONE" "DELEGATED" "CANCELLED")))

(setq org-agenda-files '("/tmp/test.org"))

in a file, say org-minconfig.el.

And something like

* NOTE h1

* TODO h2

in /tmp/test.org.

Then, in the same directory as org-minconfig.el, start emacs with

$ emacs -Q -l org-minconfig.el --visit /tmp/test.org

and see if running "M-x org-agenda T NOTE" lists the NOTE heading.

--
Kyle

Re: [O] Adding user-defined task state for agenda

[Kyle Meyer]

Peter Davis  writes:

[...]

> Hmmm. It worked in the minimal case, but still doesn't work in my
> normal environment.

Well that gives you something to go on.  I'd recommend looking for parts
of your normal Org configuration that seem like they could affect this
and dumping small bits into the minimal config from above to see if any
result in NOTE not being listed.

  $ emacs -Q -l  --visit /tmp/test.org -f org-todo-list   

Or, if nothing stands out to you as suspicious, you could use a binary
search approach, similar to what git bisect does.  But the details of
doing that would depend on how your config files are organized.

--
Kyle

Re: [O] [PATCH] Prevent overwriting of output files from babel calls with nil result

[Aaron Ecay]

Hi Éibhear,

Thanks for sending the example.  I think it is not expected to work
going forward because the lisp block relies on being able to pick up the
value of ‘params’, which will not be possible now that org is moving to
lexical binding.  In general, org-babel-execute:foo are internal
functions, so trying to trick them int working properly in an elisp code
block is a bad idea.

The emacs-lisp babel backend is special, so I can’t predict what the
result would be of making it return the symbol nil instead of the string
“nil.”  (Though for the sake of consistency it ought to allow nil symbol
returns.)

On the balance, I recommend you do something like the following, using
two code blocks (untested):

,
| #+name: dot-code
| #+begin_src emacs-lisp :results verbatim
| (generate-dot-code)
| #+end_src
| 
| #+RESULTS: dot-code
| : "your dot code will appear here"
| 
| #+begin_src dot :file foo.png :var code=dot-code()
| $code
| #+end_src
|
| #+RESULTS:
| [[file:foo.png]]
`

Hope this helps,

-- 
Aaron Ecay

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Nicolas,

2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
> 
> Andreas Leha  writes:
> 
>> Generally, I think that caching is a sensitive area.  And if we think
>> that it is unpredictable and advise people to stay off of it, we are
>> better off removing it than offering it in this state.  At least until
>> it behaves (more) predictable.
> 
> Is it necessarily broken?

If this means “can it ever work?” then I think the answer is “yes it
can”.  But I think the current implementation is broken and likely to
remain so for the foreseeable future.  The issues are:

1. :cache only works for code which is a pure function of its header args
2. When combined with :session, the environment that the code is evaluated
   in is not created anew each time it is run.  This makes it much easier
   to leak references to (e.g.) variables defined in other blocks
3. The proper notion of purity is not easily defined when the code does
   things like modifying the emacs environment, touching the filesystem,
   or accessing the language’s RNG.
4. We (org devs) don’t actually understand how the semantics of cache
   interacts with other babel features.  See:
   .

1-3 are likely to be extremely confusing for users, especially less
technically sophisticated ones (what’s a “pure function” anyway)?  The
inability to give a clear introductory explanation of the feature in
combination with 4 indicating we don’t actually understand it ourselves
makes me feel like we should not be advertising, let alone recommending,
it.

The only other literate programming environment that I know of that
implements such a feature is knitr (for R).  They address these issues
by providing (optional) free-variable analysis to construct a dependency
graph between code blocks.  There is also some handling of RNG seed
values.  The documentation  is much
more comprehensive, including a prominent statement about the dangers of
side effect-ful code and a nuanced discussion of several issues,
including the RNG.

Aaron

PS I’ve looked through my old notes on the interaction of cache with
babel export.  I can’t reproduce any of my old test cases, so maybe that
bug has been fixed as a side effect of some other change.
 
-- 
Aaron Ecay

Re: [O] Adding user-defined task state for agenda

[Peter Davis]

Kyle Meyer  writes:

> Peter Davis  writes:
>
> [...]
>
>>>  Can you reproduce it with emacs -Q and a minimal Org configuration?
>>
>> I'm not sure how to do that.
>
> You can put something like
>
> (add-to-list 'load-path "/path/to/your/org-mode/lisp/")
> (require 'org)
>
> (setq org-todo-keywords
>   '((sequence "NOTE" "APPT" "TODO" "FEEDBACK" "VERIFY"
>   "|" "DONE" "DELEGATED" "CANCELLED")))
>
> (setq org-agenda-files '("/tmp/test.org"))
>
> in a file, say org-minconfig.el.
>
> And something like
>
> * NOTE h1
>
> * TODO h2
>
> in /tmp/test.org.
>
> Then, in the same directory as org-minconfig.el, start emacs with
>
> $ emacs -Q -l org-minconfig.el --visit /tmp/test.org
>
> and see if running "M-x org-agenda T NOTE" lists the NOTE heading.


Hmmm. It worked in the minimal case, but still doesn't work in my normal 
environment.

-pd

Re: [O] Markup (=, ~) in word?

[Rainer M Krug]

"Charles C. Berry"  writes:

> On Thu, 29 Oct 2015, Rainer M Krug wrote:
>
>> Matt Price  writes:
>>
>>> #+BEGIN_VERBATIM
>>> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>>> #+END_VERBATIM
>>
>> The other way round:
>>
>> I want the text, e.g. =SITE= as the markup, and not the whole text as
>> verbatim - sorry for not being clear about what I want.
>>
>> Rainer
>>
>>>
>
> Have a look at the `org-emphasis-regexp-components' docstring. If you
> feel bold (pun intended) you might see if adding '\.' to the first
> element works without causing mayhem elsewhere.

No - I never feel bold when it comes down to regexp.

>
> A safer hack might be to use markup like this:
>
> simASM.'=SITE=.'=STRATEGY=.'=BUDGET=.'=FIREREGIME=.'=JOBID=.'=ARRAYID=
>
> and add a filter to remove the apostrophes from the ".'\texttt" or
> ".'" that results.

That is an idea - but for the time being, I just put spaces around the
"." and that works find=e for now.

Thanks everybody,

Rainer

>
> HTH,
>
> Chuck
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Nicolas,

2015ko urriak 29an, Aaron Ecay-ek idatzi zuen:
>> Using `loop' here is, IMO, over-doing it. You can use instead, e.g.,
>> 
>> (org-remove-if
>> (lambda (item)
>> (memq (car item)
>> '(:colname-names :rowname-names :result-params :result-type :var)))
>> params)
> 
> OK.  I’ll push this to maint later today.

Pushed as 54d3032

-- 
Aaron Ecay

Re: [O] small caps

[Matt Price]

Tom,

Am I right that this should turn
{sc hello}

into

hello

?

If so, it doesn't seem to be working for me so far.  Thanks,
m


On Thu, Oct 29, 2015 at 12:55 PM, Thomas S. Dye  wrote:

> Aloha Matt,
>
> Nicolas Goaziou  writes:
>
> > Hello,
> >
> > Matt Price  writes:
> >
> >> do we have a syntax for the "small caps" text attribute in Org?
> >
> > No, we don't.
> >
>
> I've been using this export filter, written by Eric Schulte.  It works
> fine for my uses.
>
>  Eric Schulte's filter for HTML small caps
>
> #+name: es-small-caps
> #+begin_src emacs-lisp
> ;;; "sc" links for the \sc{} latex command
> (defun org-export-html-small-caps (string backend channel)
>   (when (org-export-derived-backend-p backend 'html)
> (let ((rx "{sc ")
>   (fmt "%s"))
>   (with-temp-buffer
> (insert string)
> (goto-char (point-min))
> (while (re-search-forward rx nil t)
>   (let* ((start (match-beginning 0))
>  (end (progn (goto-char start)
>  (forward-sexp)
>  (point)))
>  (content (buffer-substring (+ start 5) (- end 1
> (delete-region start end)
> (goto-char start)
> (insert (format fmt content
> (buffer-string)
>
> (add-to-list 'org-export-filter-final-output-functions
>  'org-export-html-small-caps)
>
> (defun org-export-latex-sc (tree backend info)
>   "Handle sc: links for latex export."
>   (org-element-map tree 'link
> (lambda (object)
>   (when (equal (org-element-property :type object) "sc")
> (org-element-insert-before
>  (cond
>   ((org-export-derived-backend-p backend 'latex)
>(list 'latex-fragment
>  (list :value (format "{\\sc %s}"
>   (org-element-property :path object))
>:post-blank (org-element-property
> :post-blank object
>   ((org-export-derived-backend-p backend 'html)
>(list 'export-snippet
>  (list :back-end "html"
>:value
>(format "%s"
>(org-element-property :path object))
>:post-blank
>(org-element-property :post-blank object
>   (:otherwise
>(error "unsupported backend for `org-export-latex-sc'")))
>  object)
> (org-element-extract-element object
>   tree)
>
> (org-add-link-type "sc")
>
> (add-hook 'org-export-filter-parse-tree-functions
>   'org-export-latex-sc)
>
> #+end_src
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>

Re: [O] Adding user-defined task state for agenda

[Peter Davis]

Kyle Meyer  writes:

> Peter Davis  writes:
>
> [...]
>
>> Hmmm. It worked in the minimal case, but still doesn't work in my
>> normal environment.
>
> Well that gives you something to go on.  I'd recommend looking for parts
> of your normal Org configuration that seem like they could affect this
> and dumping small bits into the minimal config from above to see if any
> result in NOTE not being listed.
>
>   $ emacs -Q -l  --visit /tmp/test.org -f org-todo-list   
>
> Or, if nothing stands out to you as suspicious, you could use a binary
> search approach, similar to what git bisect does.  But the details of
> doing that would depend on how your config files are organized.

Thanks, Kyle. I just tried saving one of my "real" org files as test.org, and 
repeated the experiment with the minimal config, and
it FAILED ... the NOTE headings did not show up.

I also tried saving the simple test.org file in my regular org files folder, 
and it FAILED again.

So I can't isolate either the emacs setup file or the org file itself.

-pd

Re: [O] Markup (=, ~) in word?

[Rasmus]

Rainer M Krug  writes:

> Hi
>
> I guess this is not possible (and has been asked before, but I can't
> find it t the moment...)- but how can I export the following markup?
>
> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>
>
> Export will be mainly LaTeX, but maybe also html.

You could separate with ZERO WIDTH SPACE.  AFAIR, this requires
(xe/lua)latex, though.  In org-mode-git, you can set #+latex_command.  You
can also remove the zero width spaces with a filter.

E.g.

(defcustom rasmus/org-latex-unicode-to-tex  '((" " "~")
(" " "\\,")
("​" ""))
  "list of re rep pairs which are replaced during latex export")

(defun rasmus/org-latex-unicode-to-tex (text backend info)
  "Replace unicode strings with their TeX equivalents.

  Currently:  ' ' (no break space) to '~'
  ' ' (thin space) to '\,'
  '​'  (zero width space) to ''."
  (when (org-export-derived-backend-p backend 'latex)
(cl-loop for (re rep) in rasmus/org-latex-unicode-to-tex do
 (setq text (replace-regexp-in-string re rep text t t)))
text))

(add-to-list 'org-export-filter-final-output-functions
 'rasmus/org-latex-unicode-to-tex)


-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone

[O] Resolving links breaks workflow using org-narrow-to-subtree

[Andreas Hock]

Hi,

I am using Org-mode version 8.3.2 (8.3.2-10-g00dacd-elpa) to organize
my lecture notes and export them to LaTeX.

The final PDF document is quite large (around 200 pages), so the
corresponding org-file has a decent size as well. To make editing
easier, I often narrow my org buffer down to the chapter I currently
work on with C-x n s (org-narrow-to-subtree).

When I want to quickly check what I've just written and to keep
compilation times down, I export just the currently visible part of the
buffer via C-c C-e l p.

Org-mode then checks if it can resolve all links in the visible part of
the buffer, which often fails, as the link target is in another
(hidden) part of the org-file. This breaks my workflow as I now can't
export my document.

The following minimal case exhibits the problem:



#+LATEX_CLASS: article

* Chapter 1
I'm not currently working on this chapter: <>
* Chapter 2
I'm currently working on this chapter and narrow the buffer down to it
[[target]]



I'm open for suggestions on how I could change my workflow to work
around this.


Thanks,
Andreas Hock

Re: [O] small caps

[Robert Klein]

Hi,

Matt Price wrote:
> do we have a syntax for the "small caps" text attribute in Org? If not,
> should we? It is available in odt, html, and latex, and is used in some
> bibliographic styles. 


You can add a link type, e.g.:

#+begin_src emacs-lisp
  (org-add-link-type
   "fm" nil
   (lambda (path desc format)
 (cond
  ((eq format 'html)
   (cond
((equal path "sc")
 (format "%s"
 desc))
((equal path "it")
 (format "%s" desc))
((equal path "bf")
 (format "%s" desc))
((equal path "tt")
 (format "%s" desc))
(t (format "%s" desc
  ;; "" )))
  ((eq format 'latex)
   (format "\\text%s{%s}" path desc))
  ((eq format 'odt)
   (cond
((equal path "sc")
 (format "hello" desc))
;; more code for it, bf, tt etc.
))
  (t Y
#+end_src

The odt stuff I typed right into this mail, so it probably doesn't
word out of the box. (don't ask me about the "(t Y)" at the end; don't
know...)

Anyway, now you can use small capitals as [[fm:sc][ad]] and you get
"ad" in small caps.

For my documents I set the following macros for small capitals and
teletype:

#+Macro: sc [[fm:sc][$1]]
#+Macro: tt [[fm:tt][$1]]

Now you can use the macros like {{{sc(ad)}}} or {{{sc(Text in Small
Caps)}}}. Note, the uppercase letters will remain uppercase.

Best regards
Robert

Re: [O] small caps

[Rasmus]

Matt Price  writes:

> do we have a syntax for the "small caps" text attribute in Org? If not,
> should we? It is available in odt, html, and latex, and is used in some

I use the following filter(s) (second one is not essential).

Example input:

CO_2
fOO
Fo1O
/FoO/

Example output:

 \textsc{co}\(_{\text{2}}\)
 f\textsc{oo}
 \textsc{f}o1\textsc{o}
 \emph{\textsc{f}o\textsc{o}}

For emph to play nice with textsc in latex use the slantsc package.


(defun rasmus/org-guess-textsc (content backend info)
"Automatically downcase and wrap all-caps words in textsc.
The function is a bit slow...

TODO: Make the function work with headlines, but without doing it
on subsequent text.

TODO: Add ODT support."
(if (org-export-derived-backend-p backend 'latex 'html)
(let* (case-fold-search
   (latexp (org-export-derived-backend-p backend 'latex))
   (wrap (if latexp "\\textsc{%s}"
 "%s")))
  (replace-regexp-in-string
   "\\w+"
   (lambda (str)
 (if (or (string-equal str (downcase str))
 (string-equal str (capitalize str)))
 str
   (replace-regexp-in-string
"[[:upper:]]+"
(lambda (x) (format wrap (downcase x)))
str t t)))
   content t t))
  content))

(add-to-list 'org-export-filter-plain-text-functions
 'rasmus/org-guess-textsc)

(defun rasmus/org-guess-textsc-html-cleanup-title (content backend info)
  (when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string
 "\\(.*\\)"
 (lambda (str0)
   (format
"%s"
(replace-regexp-in-string
 "\\(.*?\\)"
 (lambda (str) (upcase (match-string 1 str)))
 (match-string 1 str0
 content)))

-- 
⠠⠵

Re: [O] small caps

[Thomas S . Dye]

Aloha Matt,

Matt Price  writes:

> Tom,
>
> Am I right that this should turn
> {sc hello}
>
> into
>
> hello
>
> ?
>
> If so, it doesn't seem to be working for me so far.  Thanks,
> m

Sorry, I forgot to give an example.  I use it like this [[sc:ad][AD]].

The advantage of a link over a macro is that the link should export
correctly to both LaTeX and HTML.

If you intend to export to a single backend, then Nicolas' suggestion to
use a macro is simpler.

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] problems with export and :cache

[Thomas S . Dye]

Aloha all,

Aaron Ecay  writes:

> Hi Nicolas,
>
> 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
>> 
>> Andreas Leha  writes:
>> 
>>> Generally, I think that caching is a sensitive area.  And if we think
>>> that it is unpredictable and advise people to stay off of it, we are
>>> better off removing it than offering it in this state.  At least until
>>> it behaves (more) predictable.
>> 
>> Is it necessarily broken?
>
> If this means “can it ever work?” then I think the answer is “yes it
> can”.  But I think the current implementation is broken and likely to
> remain so for the foreseeable future.  The issues are:
>
> 1. :cache only works for code which is a pure function of its header args
> 2. When combined with :session, the environment that the code is evaluated
>in is not created anew each time it is run.  This makes it much easier
>to leak references to (e.g.) variables defined in other blocks
> 3. The proper notion of purity is not easily defined when the code does
>things like modifying the emacs environment, touching the filesystem,
>or accessing the language’s RNG.
> 4. We (org devs) don’t actually understand how the semantics of cache
>interacts with other babel features.  See:
>.
>
> 1-3 are likely to be extremely confusing for users, especially less
> technically sophisticated ones (what’s a “pure function” anyway)?  The
> inability to give a clear introductory explanation of the feature in
> combination with 4 indicating we don’t actually understand it ourselves
> makes me feel like we should not be advertising, let alone recommending,
> it.
>
> The only other literate programming environment that I know of that
> implements such a feature is knitr (for R).  They address these issues
> by providing (optional) free-variable analysis to construct a dependency
> graph between code blocks.  There is also some handling of RNG seed
> values.  The documentation  is much
> more comprehensive, including a prominent statement about the dangers of
> side effect-ful code and a nuanced discussion of several issues,
> including the RNG.
>
> Aaron
>
> PS I’ve looked through my old notes on the interaction of cache with
> babel export.  I can’t reproduce any of my old test cases, so maybe that
> bug has been fixed as a side effect of some other change.

FWIW, I think relying on cache to speed up export is the wrong
approach.  Having all code run during each export is, to me, a feature
that makes a document "live."  I'm willing to be patient during export
to get this feature.

If speed is important and a live document isn't desired, then one
solution is to rename the results and refer to this name in the
document, rather than to the name of the code block that produced the
results.  I do this manually, which is OK, but I've often wanted
something like :persist-as my-result so I can be certain to have a good
link from the results back to the code that produced them.

That said, points 2 and 4 seem to me serious issues that users must
understand if they choose to use :cache.  So, at the least, the
documentation needs revision.

All the best,
Tom

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

Re: [O] problems with export and :cache

[Andreas Leha]

Hi Thomas,

Thomas S. Dye  writes:
> Aloha all,
>
> Aaron Ecay  writes:
>
>> Hi Nicolas,
>>
>> 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
>>> 
>>> Andreas Leha  writes:
>>> 
 Generally, I think that caching is a sensitive area.  And if we think
 that it is unpredictable and advise people to stay off of it, we are
 better off removing it than offering it in this state.  At least until
 it behaves (more) predictable.
>>> 
>>> Is it necessarily broken?
>>
>> If this means “can it ever work?” then I think the answer is “yes it
>> can”.  But I think the current implementation is broken and likely to
>> remain so for the foreseeable future.  The issues are:
>>
>> 1. :cache only works for code which is a pure function of its header args
>> 2. When combined with :session, the environment that the code is evaluated
>>in is not created anew each time it is run.  This makes it much easier
>>to leak references to (e.g.) variables defined in other blocks
>> 3. The proper notion of purity is not easily defined when the code does
>>things like modifying the emacs environment, touching the filesystem,
>>or accessing the language’s RNG.
>> 4. We (org devs) don’t actually understand how the semantics of cache
>>interacts with other babel features.  See:
>>.
>>
>> 1-3 are likely to be extremely confusing for users, especially less
>> technically sophisticated ones (what’s a “pure function” anyway)?  The
>> inability to give a clear introductory explanation of the feature in
>> combination with 4 indicating we don’t actually understand it ourselves
>> makes me feel like we should not be advertising, let alone recommending,
>> it.
>>
>> The only other literate programming environment that I know of that
>> implements such a feature is knitr (for R).  They address these issues
>> by providing (optional) free-variable analysis to construct a dependency
>> graph between code blocks.  There is also some handling of RNG seed
>> values.  The documentation  is much
>> more comprehensive, including a prominent statement about the dangers of
>> side effect-ful code and a nuanced discussion of several issues,
>> including the RNG.
>>
>> Aaron
>>
>> PS I’ve looked through my old notes on the interaction of cache with
>> babel export.  I can’t reproduce any of my old test cases, so maybe that
>> bug has been fixed as a side effect of some other change.
>
> FWIW, I think relying on cache to speed up export is the wrong
> approach.  Having all code run during each export is, to me, a feature
> that makes a document "live."  I'm willing to be patient during export
> to get this feature.
>
> If speed is important and a live document isn't desired, then one
> solution is to rename the results and refer to this name in the
> document, rather than to the name of the code block that produced the
> results.  I do this manually, which is OK, but I've often wanted
> something like :persist-as my-result so I can be certain to have a good
> link from the results back to the code that produced them.

There we go again.  Another advice not to use the :cache.

>
> That said, points 2 and 4 seem to me serious issues that users must
> understand if they choose to use :cache.  So, at the least, the
> documentation needs revision.
>

Just to add (maybe that belongs to point 4 anyway): And the caching
should work predictably -- even during export.

Regards,
Andreas

Re: [O] problems with export and :cache

[Nicolas Goaziou]

Aaron Ecay  writes:

> But users know that anyway, since it’s implied by the semantics of
> :colname-names.  Actually the most typical way of accessing the value
> of :colname-names in the code is (cdr (assoc :colname-names params))
> (~20 uses, which ought to use assq instead); using o-b-get-header for
> :colname-names is an exception.
>
> The issue is that o-b-g-h gives an API for accessing key-values in a
> 1:many mapping.  But :var is the only key that can actually be 1:many.
> All other keys are singletons, and can be handled through the usual
> emacs API for 1:1 mappings (assq and friends) – and in the existing
> codebase they often are.  If we provide an API within babel, we should
> make it as specific as possible.

Ideally, the API should be transparent to the internal representation of
parameters used in Babel. Using `assq' means 1) you know that Babel
internally uses alists for parameters 2) you hope it will do it forever.

In any case, your suggestion is already better than the current
situation in Babel. So I'm fine with it. It might not be optimal
however.

Regards,

Re: [O] small caps

[Nicolas Goaziou]

Hello,

Thomas S. Dye  writes:

> I use them in almost all my archaeology writing where it is conventional
> to make AD, BC, and BP small caps.

I assume you are using PDF output. You can modify
`org-latex-text-markup-alist' or use

  #+MACRO: ad \textsc{ad}

and so on.


Regards,

-- 
Nicolas Goaziou

[O] [babel] :eval and #+call lines

[Andreas Leha]

Hi all,

Since this is not related to caching, I post this as a separate question
from [1].

I want to argue that specifying ':eval never' as argument to a #+call
line should transitively apply to the called block as well.

Here is the example:

--8<---cut here---start->8---
* Test
** A long running code block.
#+name: foo
#+begin_src emacs-lisp :var bar="baz"
  (sit-for 15)
  (message "bar=%S" bar)
#+end_src

** Calling

This should not execute anything IMO.
#+call: foo("qux") :eval never

I.e. it should behave as this:
#+call: foo[:eval never]("qux") :eval never
--8<---cut here---end--->8---

Regards,
Andreas



[1] http://permalink.gmane.org/gmane.emacs.orgmode/102349

[O] Markup (=, ~) in word?

[Rainer M Krug]

Hi

I guess this is not possible (and has been asked before, but I can't
find it t the moment...)- but how can I export the following markup?

--8<---cut here---start->8---
simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
--8<---cut here---end--->8---


Export will be mainly LaTeX, but maybe also html.

Thanks,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Markup (=, ~) in word?

[Matt Price]

#+BEGIN_VERBATIM
simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
#+END_VERBATIM

?

not perfect, but...

On Thu, Oct 29, 2015 at 7:06 AM, Rainer M Krug  wrote:

> Hi
>
> I guess this is not possible (and has been asked before, but I can't
> find it t the moment...)- but how can I export the following markup?
>
> --8<---cut here---start->8---
> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
> --8<---cut here---end--->8---
>
>
> Export will be mainly LaTeX, but maybe also html.
>
> Thanks,
>
> Rainer
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>
> PGP: 0x0F52F982
>

Re: [O] Markup (=, ~) in word?

[Rainer M Krug]

Matt Price  writes:

> #+BEGIN_VERBATIM
> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
> #+END_VERBATIM

The other way round:

I want the text, e.g. =SITE= as the markup, and not the whole text as
verbatim - sorry for not being clear about what I want.

Rainer

>
> ?
>
> not perfect, but...
>
> On Thu, Oct 29, 2015 at 7:06 AM, Rainer M Krug  wrote:
>
>> Hi
>>
>> I guess this is not possible (and has been asked before, but I can't
>> find it t the moment...)- but how can I export the following markup?
>>
>> --8<---cut here---start->8---
>> simASM.=SITE=.=STRATEGY=.=BUDGET=.=FIREREGIME=.=JOBID=.=ARRAYID=
>> --8<---cut here---end--->8---
>>
>>
>> Export will be mainly LaTeX, but maybe also html.
>>
>> Thanks,
>>
>> Rainer
>>
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
>> Biology, UCT), Dipl. Phys. (Germany)
>>
>> Centre of Excellence for Invasion Biology
>> Stellenbosch University
>> South Africa
>>
>> Tel :   +33 - (0)9 53 10 27 44
>> Cell:   +33 - (0)6 85 62 59 98
>> Fax :   +33 - (0)9 58 10 27 44
>>
>> Fax (D):+49 - (0)3 21 21 25 22 44
>>
>> email:  rai...@krugs.de
>>
>> Skype:  RMkrug
>>
>> PGP: 0x0F52F982
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature