Re: [O] a patch to org.el of git version

[Nicolas Goaziou]

Hello,

Tokuya Kameshima  writes:

> This is a tiny patch to `org-show-children' which shoule be an
> interactive function but not.

Thank you. However, `org-show-children' is not meant to be interactive,
because its functionality is incomplete within Org. It also needs
`org-show-entry'.

In any case, I fixed its docstring since it was misleading.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: The headers' anchors from custom ids should be at the beginning, and not at the end, of these headers [8.3.1 (8.3.1-129-ga7c8d2-elpa @ /home/bitouze/.emacs.d/elpa/org-20150921/)]

[Nicolas Goaziou]

Hello,

dbito...@wanadoo.fr (Denis Bitouzé) writes:

> The following org file:
>
> #+begin_src org
> * Heading with custom id
> :PROPERTIES:
> :CUSTOM_ID: custom-id-heading
> :END:
>
> * Heading bis with custom id and very very very very very very very very very 
> very very very very very very very very very very very very very very very 
> long text
> :PROPERTIES:
> :CUSTOM_ID: custom-id-heading-bis
> :END:
>
> See [[#custom-id-heading-bis][heading bis with custom id and very long text]].
> #+end_src
>
> is exported as markdown to:
>
> #+begin_src markdown
> 
> Table of Contents
> 
> 
> 1. Heading with custom id
> 2. Heading bis with custom id and very 
> very very very very very very very very very very very very very very very 
> very very very very very very very very long text
> 
> 
> 
>
> # Heading with custom id
>
> # Heading bis with custom id and very very very very very very very very very 
> very very very very very very very very very very very very very very very 
> long text
>
> See [heading bis with custom id and very long text](#custom-id-heading-bis).
> #+end_src
>
> As you can see, the anchor in the .md file is at the end of the header and, in
> case this header contains long text, clicking on a link to this anchor would
> lead us to the end, eventually not at the first line, of this header.

True. But there's a trade-off: putting anchor at the beginning of the
heading is less readable.

So I'm not sure it is a clear win.

Regards,

-- 
Nicolas Goaziou

Re: [O] Avoiding open buffers when clocking in

[Julian M. Burgos]

Actually, the solution is obvious... I should think before posting.

(defun my-org-clock-in ()
 "Clock in and close all unmodified buffers."
  (interactive)
  (org-clock-in)
  (mapc 'kill-buffer (cdr (buffer-list (current-buffer
)



Julian M. Burgos writes:

> Thanks Kyle, I did not knew this one.  I was manually using this
> function
>
> (defun only-current-buffer () 
>   (interactive)   
> 
> (mapc 'kill-buffer (cdr (buffer-list (current-buffer)
>
> to kill all buffers after clocking in, but your solution is simpler.  
>
>
>
> Kyle Meyer writes:
>
>> "Julian M. Burgos"  writes:
>>
>>> When clocking in at some particular task, org-mode opens all my agenda
>>> files (I assume to check if there are dangling clocks).  I have many
>>> agenda files, and I rather avoid opening tons of new buffers.  Is there any
>>> way to make org-mode not check for dangling clocks in other agenda
>>> files?
>>
>> If you're ok with disabling automatic clock resolution entirely, setting
>> org-clock-auto-clock-resolution to nil should work.

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnun/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: jul...@hafro.is

Re: [O] Bug: The headers' anchors from custom ids should be at the beginning, and not at the end, of these headers [8.3.1 (8.3.1-129-ga7c8d2-elpa @ /home/bitouze/.emacs.d/elpa/org-20150921/)]

[Denis Bitouzé]

Le 22/09/15 à 21h39, Nicolas Goaziou  a écrit :

> Hello,

Hello,

>> As you can see, the anchor in the .md file is at the end of the header and, 
>> in
>> case this header contains long text, clicking on a link to this anchor would
>> lead us to the end, eventually not at the first line, of this header.
>
> True. But there's a trade-off: putting anchor at the beginning of the
> heading is less readable.

I don't see your point.

1. What is less readable: the anchor or, if the anchor is at its
   beginning, the heading ?
2. At what level is it less readable: .org or .md or .html, etc.?

Regards,
-- 
Denis

Re: [O] Show presence of zero width spaces using overlay

[timor]

Hi,

(this is my first post on this list, to a message that I don't have in
my inbox, so I don't know if it will thread correctly)

Kaushal Modi  writes:

> The suggestion to use zero width spaces to sort of "escape" stuff in org
> mode has come up many times. I have started using it a lot and suggest that
> to other people now.
>
> Here is one such recent QnA on emacs.SE:
> http://emacs.stackexchange.com/a/16702/115
>
> The OP of that question made a valid point that while using zero width
> spaces is convenient, it is not apparent where it has been used in the
> document.
>
> To resolve that, I am requesting a feature.
>
> Can the zero width spaces be optionally represented with something like a
> single space overlay with a colored background (like purple)?
>
> Making this officially part of org-mode will probably make more people make
> use of it.
>
> .. Or should people use zero width spaces?

I am the OP of that QnA

I am wondering why there is no simple backslash-escaping of org-mode syntax?

regards,
timor

Re: [O] funny bug if shifting scheduled items

[Nicolas Goaziou]

Hello,

Detlef Steuer  writes:

> Met this funny bug in the morning.
>
> (orgmode version: git from today)
>
> Given the file
>
> * Testappointment
>   SCHEDULED: <2015-09-21 Mo 23:00-23:55>
>
> If I now shift the *starttime* using shift-uparrow
> the *endtime* goes to 24:00, 24:05 etc.
>
> If I keep shifting the *endtime* goes from
> 24:55 to 24:00 again.
>
> The *starttime* correctly rolls over to 0:00 .

Fixed, somewhat. Thank you.

Note that it can still produce meaningless timestamps, e.g.,

  <2015-09-21 Mo 23:00-23:55> => <2015-09-21 Mo 23:05-00:00>

but at least, it is predictable.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: The headers' anchors from custom ids should be at the beginning, and not at the end, of these headers [8.3.1 (8.3.1-129-ga7c8d2-elpa @ /home/bitouze/.emacs.d/elpa/org-20150921/)]

[Nicolas Goaziou]

Denis Bitouzé  writes:

> I don't see your point.
>
> 1. What is less readable: the anchor or, if the anchor is at its
>beginning, the heading ?

The latter.

> 2. At what level is it less readable: .org or .md or .html, etc.?

.md


Regards,

Re: [O] [PATCH] ox-latex: Add scrartcl LaTeX class

[Rasmus]

Eric S Fraga  writes:

>> Some people might hate the margin choices to the extend that they'd
>> need geometry to make KOMA-script bearable.  Now we have two new
>> dependencies...
>
> yes.  The real question is not the dependencies but what would we like
> new users to when they try exporting a document to PDF for the first
> time?  Is the LaTeX default article good enough or would using koma
> impress them more?  I don't know the answer to this...

Having to do a lot of work on a restricted system with e.g. a very old R,
I can tell you that dependencies matter!  I have to check dependencies and
install packages.

I'm not against ox-fancy-latex.el, but it's more work than adding
KOMA-scrip as a default class...

If we want to make a great first impression, libertine-pkg is more likely
to please drive-by testers than KOMA.

Rasmus


-- 
The Kids call him Billy the Saint

Re: [O] Avoiding open buffers when clocking in

[Julian M. Burgos]

Thanks Kyle, I did not knew this one.  I was manually using this
function

(defun only-current-buffer () 
  (interactive) 
  
(mapc 'kill-buffer (cdr (buffer-list (current-buffer)

to kill all buffers after clocking in, but your solution is simpler.  



Kyle Meyer writes:

> "Julian M. Burgos"  writes:
>
>> When clocking in at some particular task, org-mode opens all my agenda
>> files (I assume to check if there are dangling clocks).  I have many
>> agenda files, and I rather avoid opening tons of new buffers.  Is there any
>> way to make org-mode not check for dangling clocks in other agenda
>> files?
>
> If you're ok with disabling automatic clock resolution entirely, setting
> org-clock-auto-clock-resolution to nil should work.

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnun/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: jul...@hafro.is

Re: [O] PROPERTIES attached to results blocks - Was: Set or update timestamp after evaluation of code block?

[Charles C. Berry]

On Tue, 22 Sep 2015, Rainer M Krug wrote:


Grant Rettke  writes:


Might be nice to have properties attached to result blocks. That is a nice idea.


True. These could be used for in the long run many
purposes, like formating for export. If the formating would be defined
in the properties of the result block, it would make it easy to have
different formating for export when using multiple result blocks.



This is available through babel as in the `latex' language src blocks.

Add a new babel language - `results', says. Use :wrap or :post to setup 
the `results' src block:


--8<---cut here---start->8---

#+BEGIN_SRC emacs-lisp :wrap "src results :properties abc"
1
#+END_SRC

#+RESULTS:
#+BEGIN_src results :properties abc
1
#+END_src

--8<---cut here---end--->8---

... then define a babel language 'results' along the line of ob-latex.el 
with suitable `org-babel-header-args:results' and you are there.


HTH,

Chuck

Re: [O] [PATCH] ox-latex: Add scrartcl LaTeX class

[Eric S Fraga]

On Tuesday, 22 Sep 2015 at 13:21, Rasmus wrote:
> Key word being 'arguably'.

indeed!

> Some people might hate the margin choices to the extend that they'd
> need geometry to make KOMA-script bearable.  Now we have two new
> dependencies...

yes.  The real question is not the dependencies but what would we like
new users to when they try exporting a document to PDF for the first
time?  Is the LaTeX default article good enough or would using koma
impress them more?  I don't know the answer to this...

For not so novice users, customising org-latex-classes is relatively
painless.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.5.1, Org release_8.3.1-239-gd01560

[O] Avoiding open buffers when clocking in

[Julian M. Burgos]

Dear list,

When clocking in at some particular task, org-mode opens all my agenda
files (I assume to check if there are dangling clocks).  I have many
agenda files, and I rather avoid opening tons of new buffers.  Is there any
way to make org-mode not check for dangling clocks in other agenda
files?  I only clock time in a single file (my journal.org file), so
I know already that there will not be dangling clocks in other files.

Or it is possible to automatically close the buffers *after* the check for 
dangling
clocks is done?

Many thanks,

Julian

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnun/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: jul...@hafro.is

[O] standardizing slideshow outpout, a la pandoc

[Matt Price]

Hi everyone,

I'm co-teaching a class this term and my co-instructor is a markdown user,
so I am getting to know a little bit about pandoc.  One feature I really
love is the unified slideshow export:

http://pandoc.org/demo/example19/Producing-slide-shows-with-Pandoc.html

All the export filters use the same syntax for slide divisions, slide
"builds" (dynamic appearance of slide contents), and sub-slides (reveal.js
creates two-dimensional slideshows), as well as for speaker notes.  The use
of standard markdown features also makes the writing process very
convenient.

By contrast, some of these features can be a little confusing in Org, and
moving from one export format to another can take a certain amount of
work.  If I want a "build" to work properly in both deck.js and reveal.js,
for instance, I need both a properties drawer and an #+ATTR_HTML line.  In
pandoc I need neither.

Does anyone else think it would be worthwhile to standardize some of these
features within org itself -- either by adding new syntax/options, or by
interpreting existing syntax in a uniform way across export filters?  The
first option is less invasive, I think, while the second option would be
slightly more convenient going forward (for new users at least).  Pandoc
chooses the second option -- new slides are indicated by a horizontal rule,
for instance.

If other people like the idea I would be willing to draw up a more complete
proposal and write some preliminary code for the export back-ends I'm
familiar with.  I am unfortunately a slow coder though, so a positive
resolution would still be a ways away.

Looking forward to hearing what you all think.
Thanks!
Matt

Re: [O] inter-word space in org -> latex

[Marcin Borkowski]

On 2015-09-22, at 22:17, Marcin Borkowski  wrote:

> On 2015-09-14, at 16:42, Dan Griswold  wrote:
>
>> How should I mark in org mode that I want a space following a period
>> concluding an abbreviation to be seen by LaTeX as an interword space?
>
> #+LATEX_HEADER: \frenchspacing
>
> and never worry again.
>
> OTOH, it would be relatively easy to write a filter which converts Emacs
> rules wrt. spaces (single/double space) into LaTeX ones.

And here it is:

--8<---cut here---start->8---
;; Convert single spaces after periods etc. to "\ " when exporting to LaTeX

(defun my-latex-filter-nonfrenchspacing (text backend info)
  "Convert single spaces after dots to \"\ \"."
  (when (and (org-export-derived-backend-p backend 'latex)
 sentence-end-double-space)
(replace-regexp-in-string
 (concat "\\(" sentence-end-base "\\)"
 "[ \u00a0]\\([^ \t\u00a0\n]\\)")
 "\\1 \\2" text)))

(add-to-list 'org-export-filter-plain-text-functions
 'my-latex-filter-nonfrenchspacing)
--8<---cut here---end--->8---

It is a bit simplistic (after all, I wrote it just now in 15 minutes),
but it seems to work fine.  It makes a few assumptions, though.  One of
them is that you don't mess with sentence-end-base too much: I assumed
that there are no non-shy groups there.  (By default there are not, and
I don't see any reason for them to be there, but what do I know.)  Also,
I assume that for the period to /not/ end the sentence, it should be
followed by one space and something non-spacey.

Probably the biggest drawback is that non-breaking spaces get converted
to breaking ones.  However, if you care about those, you can always
use the filter given in the example for filters in the Org manual, and
make sure it runs before the above one.  (TeX considers tildes as
normal-sized spaces.)

Also, note that while Emacs' way of differentiating between
a sentence-ending period and a non-sentence-ending period are fairly
simple, (La)TeX's rules are a bit more complicated (look up "space
factor" in The TeXbook).  For instance, LaTeX assumes that a period
after a capital letter /never/ ends the sentence, and you have to use \@
before such period to change that.  The algorithm TeX uses is really
clever, and can be (ab)used in funny ways to do funny stuff in
low-level, hackish TeX ways (been there, done that - for instance, when
I once reimplemented the theorem-like environments, I used space factor
to make sure that if a theorem begins with an enumeration, it looks
fine.  The "standard" LaTeX implementation of theorem-like environments
is kind of crazy, even if it works in typical cases.  Try typesetting
a theorem with a long optional argument in a narrow column and see what
happens, for instance.).

TL;DR: just use \frenchspacing.  Everyone will be happier.

Hth,

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

Re: [O] inter-word space in org -> latex

[Rasmus]

Marcin Borkowski  writes:

> ;; Convert single spaces after periods etc. to "\ " when exporting to LaTeX
>
> (defun my-latex-filter-nonfrenchspacing (text backend info)
>   "Convert single spaces after dots to \"\ \"."
>   (when (and (org-export-derived-backend-p backend 'latex)
>sentence-end-double-space)
> (replace-regexp-in-string
>  (concat "\\(" sentence-end-base "\\)"
>"[ \u00a0]\\([^ \t\u00a0\n]\\)")
>  "\\1 \\2" text)))
>
> (add-to-list 'org-export-filter-plain-text-functions
>'my-latex-filter-nonfrenchspacing)
>
> It is a bit simplistic (after all, I wrote it just now in 15 minutes),
> but it seems to work fine.  It makes a few assumptions, though.  One of
> them is that you don't mess with sentence-end-base too much: I assumed
> that there are no non-shy groups there.  (By default there are not, and
> I don't see any reason for them to be there, but what do I know.)  Also,
> I assume that for the period to /not/ end the sentence, it should be
> followed by one space and something non-spacey.

Here'a an alternative implementation with other limitation, e.g. only
looking at [A-Z] for capitals:

   http://permalink.gmane.org/gmane.emacs.orgmode/101176

> Also, note that while Emacs' way of differentiating between
> a sentence-ending period and a non-sentence-ending period are fairly
> simple, (La)TeX's rules are a bit more complicated (look up "space
> factor" in The TeXbook).  For instance, LaTeX assumes that a period
> after a capital letter /never/ ends the sentence, and you have to use \@
> before such period to change that.  The algorithm TeX uses is really
> clever, and can be (ab)used in funny ways to do funny stuff in
> low-level, hackish TeX ways (been there, done that - for instance, when
> I once reimplemented the theorem-like environments, I used space factor
> to make sure that if a theorem begins with an enumeration, it looks
> fine.  The "standard" LaTeX implementation of theorem-like environments
> is kind of crazy, even if it works in typical cases.  Try typesetting
> a theorem with a long optional argument in a narrow column and see what
> happens, for instance.).

But isn't a lot of the cruft from TeX "fixed" in LaTeX.  E.g. I believe
the correct space is automatically used after emphasis.


> TL;DR: just use \frenchspacing.  Everyone will be happier.

Or not.

-- 
The Kids call him Billy the Saint

Re: [O] [BUG] R src blocks untabify literal constant TABs

[Charles C. Berry]

On Tue, 22 Sep 2015, Charles C. Berry wrote:

Just to tie this up, this is an issue with `org-src-preserve-indentation', 
see


(info "(org) Editing source code")

for the best documentation. I found the "replace sequences of spaces with 
tab characters" for nil values confusing. The opposite is happening in 
this example.


Anyway this shows the behavior I expected. I guess that my cry of "BUG!" 
was unawarranted.


--8<---cut here---start->8---

#+BEGIN_SRC R  :results raw :wrap "src R -i"
   res <- paste0("A","\t","B")
   paste0("nchar(\"",res,"\")")
#+END_SRC

#+RESULTS:
#+BEGIN_src R -i
nchar("A   B")
#+END_src

#+RESULTS:
: 3

--8<---cut here---end--->8---

Chuck

[O] [BUG] R src blocks untabify literal constant TABs

[Charles C. Berry]

ECM follows:

Make a string of three characters :'A', '', and 'B':

#+BEGIN_SRC R
res <- paste0("A","\t","B")
nchar(res)
#+END_SRC

#+RESULTS:
: 3

Make a src block in which the string appears literally, then execute the 
resulting src block:


#+BEGIN_SRC R  :results raw :wrap "src R"
  res <- paste0("A","\t","B")
  paste0("nchar(\"",res,"\")")
#+END_SRC

#+RESULTS:
#+BEGIN_src R
nchar("A   B")
#+END_src

#+RESULTS:
: 10

Ouch!

--

I don't have time to dig into this now, but thought I'd get it on the 
record.



Chuck

Re: [O] inter-word space in org -> latex

[Marcin Borkowski]

On 2015-09-14, at 16:42, Dan Griswold  wrote:

> Dear org-mode community,
>
> In LaTeX, a space after a period is treated as an inter-sentence space,
> which is wider than an inter-word space. This can lead to overly wide
> spacing after a period that ends an abbreviation rather than a space. The
> way to cover this in LaTeX is to use a backslash prior to the space, as in:
>
> Mr.\ Henry Higgins.
>
> I have some documents in org that have the same issue: periods concluding
> abbreviations, with the result that LaTeX puts more space than I want after
> the abbreviation. Yet the use of "\ " does not work, as the backslash is
> exported to LaTeX as a literal backslash.
>
> How should I mark in org mode that I want a space following a period
> concluding an abbreviation to be seen by LaTeX as an interword space?

#+LATEX_HEADER: \frenchspacing

and never worry again.

OTOH, it would be relatively easy to write a filter which converts Emacs
rules wrt. spaces (single/double space) into LaTeX ones.

BTW: Bringhurst claims that using larger spaces at the end of the
sentence is Bad Style™.

> Thanks,
>
> Dan


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

Re: [O] Bug: The headers' anchors from custom ids should be at the beginning, and not at the end, of these headers [8.3.1 (8.3.1-129-ga7c8d2-elpa @ /home/bitouze/.emacs.d/elpa/org-20150921/)]

[Denis Bitouzé]

Le 22/09/15 à 22h01, Nicolas Goaziou  a écrit :

> Denis Bitouzé  writes:
>
>> I don't see your point.
>>
>> 1. What is less readable: the anchor or, if the anchor is at its
>>beginning, the heading ?
>
> The latter.
>
>> 2. At what level is it less readable: .org or .md or .html, etc.?
>
> .md

OK but, AFAICS, markdown export from org mode is usually not intended to
be read, isn't it?

Regards.
-- 
Denis

Re: [O] [PATCH v3] fix SETUPFILE pathname expansion with subdirectories

[Richard Hansen]

Any other feedback on this patch?

Thanks,
Richard


On 2015-09-20 01:28, Richard Hansen wrote:
> * lisp/org-macro.el (org-macro--collect-macros): cd to the directory
> containing the SETUPFILE before recursing so that relative pathnames
> in the SETUPFILE are expanded properly.
> 
> * lisp/org.el (org--setup-collect-keywords): cd to the directory
> containing the SETUPFILE before recursing so that relative pathnames
> in the SETUPFILE are expanded properly.
> 
> * lisp/ox.el (org-export--get-inbuffer-options,
> org-export--list-bound-variables): cd to the directory containing the
> SETUPFILE before recursing so that relative pathnames in the SETUPFILE
> are expanded properly.
> 
> If /path/to/foo.org contains:
> 
> #+SETUPFILE: settings/beamer.org
> 
> and /path/to/settings/beamer.org contains:
> 
> #+SETUPFILE: common.org
> 
> then we want to read /path/to/settings/common.org, not
> /path/to/common.org.
> 
> TINYCHANGE
> ---
> Patch changelog:
>   v3: use (setq default-directory ...) instead of (cd ...)
>   v2: fix a couple more cases; add some tests
> 
>  lisp/org-macro.el  | 2 ++
>  lisp/org.el| 1 +
>  lisp/ox.el | 4 
>  testing/examples/setupfile.org | 7 +--
>  testing/examples/setupfile3.org| 6 ++
>  testing/examples/subdir/setupfile2.org | 1 +
>  6 files changed, 15 insertions(+), 6 deletions(-)
>  create mode 100644 testing/examples/setupfile3.org
>  create mode 100644 testing/examples/subdir/setupfile2.org
> 
> diff --git a/lisp/org-macro.el b/lisp/org-macro.el
> index 65795f6..e808972 100644
> --- a/lisp/org-macro.el
> +++ b/lisp/org-macro.el
> @@ -106,6 +106,8 @@ Return an alist containing all macro templates found."
> (org-remove-double-quotes val
>  (unless (member file files)
>(with-temp-buffer
> +(setq default-directory
> +  (file-name-directory file))
>  (org-mode)
>  (insert (org-file-contents file 'noerror))
>  (setq templates
> diff --git a/lisp/org.el b/lisp/org.el
> index 74fe4ae..bd5a183 100755
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -5194,6 +5194,7 @@ Return value contains the following keys: `archive', 
> `category',
>   (org-remove-double-quotes value)
>  (when (and f (file-readable-p f) (not (member f files)))
>(with-temp-buffer
> +(setq default-directory (file-name-directory f))
>  (insert-file-contents f)
>  (setq alist
>;; Fake Org mode to benefit from cache
> diff --git a/lisp/ox.el b/lisp/ox.el
> index bfdfeba..477fc06 100644
> --- a/lisp/ox.el
> +++ b/lisp/ox.el
> @@ -1455,6 +1455,8 @@ Assume buffer is in Org mode.  Narrowing, if any, is 
> ignored."
>;; Avoid circular dependencies.
>(unless (member file files)
>  (with-temp-buffer
> +  (setq default-directory
> +(file-name-directory file))
>(insert (org-file-contents file 'noerror))
>(let ((org-inhibit-startup t)) (org-mode))
>(setq plist (funcall get-options
> @@ -1586,6 +1588,8 @@ an alist where associations are (VARIABLE-NAME VALUE)."
>   (org-remove-double-quotes val
>(unless (member file files)
>  (with-temp-buffer
> +  (setq default-directory
> +(file-name-directory file))
>(let ((org-inhibit-startup t)) (org-mode))
>(insert (org-file-contents file 'noerror))
>(setq alist
> diff --git a/testing/examples/setupfile.org b/testing/examples/setupfile.org
> index a85dbc0..71acfca 100644
> --- a/testing/examples/setupfile.org
> +++ b/testing/examples/setupfile.org
> @@ -1,6 +1 @@
> -#+BIND: variable value
> -#+DESCRIPTION: l2
> -#+LANGUAGE: en
> -#+SELECT_TAGS: b
> -#+TITLE: b
> -#+PROPERTY: a 1
> +#+SETUPFILE: subdir/setupfile2.org
> diff --git a/testing/examples/setupfile3.org b/testing/examples/setupfile3.org
> new file mode 100644
> index 000..a85dbc0
> --- /dev/null
> +++ b/testing/examples/setupfile3.org
> @@ -0,0 +1,6 @@
> +#+BIND: variable value
> +#+DESCRIPTION: l2
> +#+LANGUAGE: en
> +#+SELECT_TAGS: b
> +#+TITLE: b
> +#+PROPERTY: a 1
> diff --git a/testing/examples/subdir/setupfile2.org 
> b/testing/examples/subdir/setupfile2.org
> new file mode 100644
> index 000..31586fa
> --- /dev/null
> +++ b/testing/examples/subdir/setupfile2.org
> @@ -0,0 +1 

Re: [O] [BUG] R src blocks untabify literal constant TABs

[Charles C. Berry]

Sorry, I just walked in the door and didn't put on my thinking cap...

On Tue, 22 Sep 2015, Charles C. Berry wrote:


On Tue, 22 Sep 2015, Grant Rettke wrote:


On Tue, Sep 22, 2015 at 5:04 PM, Charles C. Berry  wrote:


ECM follows:


I just ran it and got 10 chars like you expected:


I got 10, too. That is the problem. Maybe that is what you meant?

What I expected was 3 characters like the first src block gave. 
The reason the block just below fails is that some un-tab-ing puts spaces 
where a tab should be.




#+BEGIN_src R
nchar("AB")
#+END_src

#+RESULTS:
: 10


10 is not what I expected. Should be 3 characters.

Be sure to run the second src block (which creates the third with the three 
character string) before running the third.




If you do run the second block, the third block should have A, , and 
B in the quoted string. It does for me. And then when executed gives the 
erroneous 10.



But thanks for checking.

Chuck




Chuck

Re: [O] [BUG] R src blocks untabify literal constant TABs

[Grant Rettke]

On Tue, Sep 22, 2015 at 5:04 PM, Charles C. Berry  wrote:
>
> ECM follows:

I just ran it and got 10 chars like you expected:

#+BEGIN_src R
nchar("AB")
#+END_src

#+RESULTS:
: 10

---

Emacs Version: src_emacs-lisp{emacs-version} {{{results("24.4.1")}}}
Org Version from Git: src_emacs-lisp{org-version} {{{results("8.3.1")}}}

Init file:

;; -*- lexical-binding: t -*-

(setq load-prefer-newer t)
(add-to-list 'load-path "~/src/org-mode/lisp")
(add-to-list 'load-path "~/src/org-mode/contrib/lisp")
(setq org-list-allow-alphabetical t)
(setq org-enforce-todo-checkbox-dependencies t)
(require 'org)
(org-babel-do-load-languages
 'org-babel-load-languages
 '((emacs-lisp . t)
   (org . t)
   ;;
   (C . t)
   (R . t)
   (python . t)
   (sass . t)
   (scheme . t)
   (sql . t)
   ;;
   (latex . t)
   ;;
   (makefile . t)
   (sh . t)
   ;;
   (ditaa . t)
   (dot . t)
   (plantuml . t)))

Re: [O] [BUG] R src blocks untabify literal constant TABs

[Charles C. Berry]

On Tue, 22 Sep 2015, Grant Rettke wrote:


On Tue, Sep 22, 2015 at 5:04 PM, Charles C. Berry  wrote:


ECM follows:


I just ran it and got 10 chars like you expected:

#+BEGIN_src R
nchar("AB")
#+END_src

#+RESULTS:
: 10


10 is not what I expected. Should be 3 characters.

Be sure to run the second src block (which creates the third with the 
three character string) before running the third.


But thanks for checking.

Chuck

Re: [O] a patch to org.el of git version

[Tokuya Kameshima]

Hi Nicolas,

Thank you for the update.
But it looks like `org-show-children' is a replacement of `show-children'.
Actually the key bind for `show-children' (C-c TAB in my case) is remapped
to `org-show-children' as below.

org.el:5733:
> (define-key org-mode-map [remap show-children] 'org-show-children)

When I typed C-C TAB on an org-mode buffer, I got the following error:

Wrong type argument: commandp, org-show-children

Thanks,
--Tokuya

On Tue, 22 Sep 2015 21:27:08 +0200,
Nicolas Goaziou  wrote:
>
> Hello,
> 
> Tokuya Kameshima  writes:
> 
> > This is a tiny patch to `org-show-children' which shoule be an
> > interactive function but not.
> 
> Thank you. However, `org-show-children' is not meant to be interactive,
> because its functionality is incomplete within Org. It also needs
> `org-show-entry'.
> 
> In any case, I fixed its docstring since it was misleading.
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Re: [O] Avoiding open buffers when clocking in

[Kyle Meyer]

"Julian M. Burgos"  writes:

> When clocking in at some particular task, org-mode opens all my agenda
> files (I assume to check if there are dangling clocks).  I have many
> agenda files, and I rather avoid opening tons of new buffers.  Is there any
> way to make org-mode not check for dangling clocks in other agenda
> files?

If you're ok with disabling automatic clock resolution entirely, setting
org-clock-auto-clock-resolution to nil should work.

-- 
Kyle

[O] PROPERTIES attached to results blocks - Was: Set or update timestamp after evaluation of code block?

[Rainer M Krug]

Grant Rettke  writes:

> Might be nice to have properties attached to result blocks. That is a nice 
> idea.

True. These could be used for in the long run many
purposes, like formating for export. If the formating would be defined
in the properties of the result block, it would make it easy to have
different formating for export when using multiple result blocks.

Rainer


> Grant Rettke
> --
> g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
> “Wisdom begins in wonder.” --Socrates
> “All creativity is an extended form of a joke.” --Kay
> ((λ (x) (x x)) (λ (x) (x x)))
> “Life has become immeasurably better since I have been forced to stop
> taking it seriously.” --Thompson
>
>
> On Mon, Sep 21, 2015 at 1:43 PM, Rainer M Krug  wrote:
>> John Kitchin  writes:
>>
>>> Here is one approach:
>>>
>>> #+name: update-timestamp
>>> #+BEGIN_SRC emacs-lisp :var data=""
>>> (concat
>>>  "Last run: "
>>>  (format-time-string "[%Y-%m-%d %a %H:%M:%S]" (current-time))
>>>  "\n" data)
>>> #+END_SRC
>>>
>>>
>>> #+BEGIN_SRC python :post update-timestamp(data=*this*)
>>> print('hello')
>>> #+END_SRC
>>>
>>> #+RESULTS:
>>> : Last run: [2015-09-21 Mon 11:09:18]
>>> : hello
>>
>> Thanks John - that looks nice and I like the idea of using
>> (current-time) and the possibility to format the time string, but this
>> info will be part of the export - and I only would like tho have the
>> info in the org file and not in the exported document.
>>
>>
>> Rainer
>>
>>>
>>>
>>>
>>> Rainer M Krug writes:
>>>
 Eric S Fraga  writes:

> On Monday, 21 Sep 2015 at 14:46, Rainer M Krug wrote:
>
> [...]
>
>> Is it possible to set a timestamp (ur update it when it exists already)
>> when a code block has been evaluated, so that I have e record when it
>> was updated?
>
> Could you make use of the :post header argument to invoke emacs lisp and
> execute org-time-stamp-inactive in some way?

 Thanks - sounds possible? But if I just use

 ,
 | :post (org-time-stamp-inactive)
 `

 1) an input is required and
 2) the time stamp is inserted before the #+begin_src and makes the block
 invalid.

 How can I put the time stamp in the line after the #+end_src or possibly
 even in the same line, as this does not seem to have an impact on the
 source block?

 Thanks,

 Rainer
>>>
>>> --
>>> Professor John Kitchin
>>> Doherty Hall A207F
>>> Department of Chemical Engineering
>>> Carnegie Mellon University
>>> Pittsburgh, PA 15213
>>> 412-268-7803
>>> @johnkitchin
>>> http://kitchingroup.cheme.cmu.edu
>>
>> --
>> 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

Re: [O] [PATCH] ox-latex: Add scrartcl LaTeX class

[Eric S Fraga]

On Monday, 21 Sep 2015 at 21:46, Nicolas Goaziou wrote:

[...]

> Thank you. But can't users needing a non-default class customize their
> own `org-latex-classes? Or is there an entitling reason to offer it out
> of the box?

Only that the koma-script classes are arguably better defaults than the
actual defaults...  Personally, I cannot see any reason to use the
standard article/report/letter classes!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.5.1, Org release_8.3.1-239-gd01560

Re: [O] Agenda Tag filtering - has the behaviour changed?

[Suvayu Ali]

On Thu, Sep 17, 2015 at 12:16:44PM -0400, Bernt Hansen wrote:
> Nicolas Goaziou  writes:
> 
> > Hello,
> >
> > Robert Klein  writes:
> >
> >> Looking through the commit messages this may come from commit
> >> 6c6ae990c10dbe7f96b24fccf840fe9f6d81a3b8
> >
> > Indeed. It seems related to this NEWS entry
> >
> >   *** Minor refactoring of ~org-agenda-filter-by-tag~
> >   Now uses the argument arg and optional argument exclude instead of
> >   strip and narrow.  ARG because the argument has multiple purposes and
> >   makes more sense than strip now.  The term narrowing is changed to
> >   exclude.
> >
> >   The main purpose is for the function to make more logical sense when
> >   filtering on tags now when tags can be structured in hierarchies.
> 
> Thanks both.
> 
> So was this an intended usability change?  I can probably live with it -
> I just need to retrain my fingers -- but it does take longer to achieve
> the result I want now since I have to clear the agenda tags before
> selecting a new filter and wait for the agenda update each time (my
> agenda has lots of entries).
> 
> The old behaviour was faster to use.
> 
> I haven't done anything with hierarchical tags yet.

FWIW, I think hierarchical tags should be opt-in.  The current behaviour
is a very nice feature, but probably a less common use case than the old
behaviour.  Maybe there can be a toggle?

I tried looking at the source, but it looked non-trivial.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Set or update timestamp after evaluation of code block?

[Rainer M Krug]

John Kitchin  writes:

> so picky ;)

Jup - aren't all org users like that?

> Maybe something like this will put that stamp in a comment
> that won't export.
>
> #+BEGIN_SRC emacs-lisp
> (defun j-add-ts ()
>   (save-excursion
> (re-search-forward "#\\+END_SRC")
> (forward-line)
> (beginning-of-line)
> (when (looking-at "# Last run:")
>   (kill-line))
> (insert (concat
>  "# Last run: "
>  (format-time-string "[%Y-%m-%d %a %H:%M:%S]" (current-time))
>
>
> (add-hook 'org-babel-after-execute-hook
>   'j-add-ts)
>
> ;(remove-hook 'org-babel-after-execute-hook
> ; 'j-add-ts)
> #+END_SRC

Perfect! I added it to my emacs.org just now and I relly like it.

Thanks a lot,

Rainer

>
>
> Rainer M Krug writes:
>
>> John Kitchin  writes:
>>
>>> Here is one approach:
>>>
>>> #+name: update-timestamp
>>> #+BEGIN_SRC emacs-lisp :var data=""
>>> (concat
>>>  "Last run: "
>>>  (format-time-string "[%Y-%m-%d %a %H:%M:%S]" (current-time))
>>>  "\n" data)
>>> #+END_SRC
>>>
>>>
>>> #+BEGIN_SRC python :post update-timestamp(data=*this*)
>>> print('hello')
>>> #+END_SRC
>>>
>>> #+RESULTS:
>>> : Last run: [2015-09-21 Mon 11:09:18]
>>> : hello
>>
>> Thanks John - that looks nice and I like the idea of using
>> (current-time) and the possibility to format the time string, but this
>> info will be part of the export - and I only would like tho have the
>> info in the org file and not in the exported document.
>>
>>
>> Rainer
>>
>>>
>>>
>>>
>>> Rainer M Krug writes:
>>>
 Eric S Fraga  writes:

> On Monday, 21 Sep 2015 at 14:46, Rainer M Krug wrote:
>
> [...]
>
>> Is it possible to set a timestamp (ur update it when it exists already)
>> when a code block has been evaluated, so that I have e record when it
>> was updated?
>
> Could you make use of the :post header argument to invoke emacs lisp and
> execute org-time-stamp-inactive in some way?

 Thanks - sounds possible? But if I just use

 ,
 | :post (org-time-stamp-inactive)
 `

 1) an input is required and
 2) the time stamp is inserted before the #+begin_src and makes the block
 invalid.

 How can I put the time stamp in the line after the #+end_src or possibly
 even in the same line, as this does not seem to have an impact on the
 source block?

 Thanks,

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

-- 
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] A book produced using Org

[Rasmus]

Suvayu Ali  writes:

> After this patch from Rasmus:
>
>   
>
> it's as simple as adding a
>
>   #+latex_program: xelatex

It's not pushed yet, though.  I have to add documentation before this can
happen.  I will hopefully do so one of these nights...

Rasmus

-- 
Together we'll stand, divided we'll fall

Re: [O] Set or update timestamp after evaluation of code block?

[Rainer M Krug]

Rainer M Krug  writes:

> John Kitchin  writes:
>
>> so picky ;)
>
> Jup - aren't all org users like that?
>
>> Maybe something like this will put that stamp in a comment
>> that won't export.
>>
>> #+BEGIN_SRC emacs-lisp
>> (defun j-add-ts ()
>>   (save-excursion
>> (re-search-forward "#\\+END_SRC")
>> (forward-line)
>> (beginning-of-line)
>> (when (looking-at "# Last run:")
>>   (kill-line))
>> (insert (concat
>>  "# Last run: "
>>  (format-time-string "[%Y-%m-%d %a %H:%M:%S]" (current-time))
>>
>>
>> (add-hook 'org-babel-after-execute-hook
>>   'j-add-ts)
>>
>> ;(remove-hook 'org-babel-after-execute-hook
>> ; 'j-add-ts)
>> #+END_SRC
>
> Perfect! I added it to my emacs.org just now and I relly like it.

I modified it a bit so that I get the following time stamp before the
source block. Can the fact that I use #+ cause problems? Because I like
the coloring of the LASTRUN line.

Additional question: if I execute the code block from a preceding
e.g. #+NAME: line which belongs to the code block, the line gets
obviously inserted in front of the code block before.

Is there some org wizardry so that I can search the property #+LASTRUN:
which belongs to the code block and replace or insert it?

Or g=can I somehow jump to the beginning of the code block when I am in
a preceding #+ line?

Thanks,

Rainer

--8<---cut here---start->8---
#+LASTRUN: [2015-09-22 Tue 11:37:43]
#+begin_src emacs-lisp 
(defun rmk/org-babel-add-time-stamp-after-execute-before-src-block ()
  (save-excursion
(re-search-backward "#\\+BEGIN_SRC")
(forward-line -1)
(beginning-of-line)
(when (not (or
(looking-at "[[:space:]]*$")
(looking-at "#\\+LASTRUN:")))
  (forward-line 1)
  (newline)
  (forward-line -1))
(when (looking-at "#\\+LASTRUN:")
  (kill-line))
(insert (concat
 "#+LASTRUN: "
 (format-time-string "[%Y-%m-%d %a %H:%M:%S]" (current-time
))

(add-hook 'org-babel-after-execute-hook
  'rmk/org-babel-add-time-stamp-after-execute-before-src-block)
#+end_src
--8<---cut here---end--->8---

>
> Thanks a lot,
>
> Rainer
>
>>
>>
>> Rainer M Krug writes:
>>
>>> John Kitchin  writes:
>>>
 Here is one approach:

 #+name: update-timestamp
 #+BEGIN_SRC emacs-lisp :var data=""
 (concat
  "Last run: "
  (format-time-string "[%Y-%m-%d %a %H:%M:%S]" (current-time))
  "\n" data)
 #+END_SRC


 #+BEGIN_SRC python :post update-timestamp(data=*this*)
 print('hello')
 #+END_SRC

 #+RESULTS:
 : Last run: [2015-09-21 Mon 11:09:18]
 : hello
>>>
>>> Thanks John - that looks nice and I like the idea of using
>>> (current-time) and the possibility to format the time string, but this
>>> info will be part of the export - and I only would like tho have the
>>> info in the org file and not in the exported document.
>>>
>>>
>>> Rainer
>>>



 Rainer M Krug writes:

> Eric S Fraga  writes:
>
>> On Monday, 21 Sep 2015 at 14:46, Rainer M Krug wrote:
>>
>> [...]
>>
>>> Is it possible to set a timestamp (ur update it when it exists already)
>>> when a code block has been evaluated, so that I have e record when it
>>> was updated?
>>
>> Could you make use of the :post header argument to invoke emacs lisp and
>> execute org-time-stamp-inactive in some way?
>
> Thanks - sounds possible? But if I just use
>
> ,
> | :post (org-time-stamp-inactive)
> `
>
> 1) an input is required and
> 2) the time stamp is inserted before the #+begin_src and makes the block
> invalid.
>
> How can I put the time stamp in the line after the #+end_src or possibly
> even in the same line, as this does not seem to have an impact on the
> source block?
>
> Thanks,
>
> Rainer

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

-- 
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] ox-latex: Add scrartcl LaTeX class

[Rasmus]

Eric S Fraga  writes:

>> Thank you. But can't users needing a non-default class customize their
>> own `org-latex-classes? Or is there an entitling reason to offer it out
>> of the box?
>
> Only that the koma-script classes are arguably better defaults than the
> actual defaults...  Personally, I cannot see any reason to use the
> standard article/report/letter classes!

Key word being 'arguably'.  Some people might hate the margin choices to
the extend that they'd need geometry to make KOMA-script bearable.  Now we
have two new dependencies...

Rasmus

-- 
Need more coffee. . .

Re: [O] [PATCH] ox-latex: Add scrartcl LaTeX class

[Grant Rettke]

On Tue, Sep 22, 2015 at 2:20 AM, Eric S Fraga  wrote:
> On Monday, 21 Sep 2015 at 21:46, Nicolas Goaziou wrote:

> Only that the koma-script classes are arguably better defaults than the
> actual defaults...  Personally, I cannot see any reason to use the
> standard article/report/letter classes!

Good to know! I've never tried anything other than the default! :) Now
I'm curious.