Re: [O] «Macro» expansion in source blocks; code-sharing between blocks

[Andreas Kiermeier]

I don't think you need the ":noweb yes" as part of the setup_fu
header, as this block is not pulling in other materials.

Having used this type of setup only over the last couple of days, I've
come up with another question. It appears that the setup_fu is
executed twice ... once as it's own source block (though by itself not
need) and once as part of the second noweb block. This isn't a problem
if the execution time is small, but I'm trying to create a summary
table in Latex format from 2 million records - so the time is
considerable.

My two blocks (with some code removed for simplicity) are as follow:

#+NAME: tbl-refyear
#+BEGIN_SRC R :results silent :exports none
  latex(tabular(   ))
#+END_SRC

#+BEGIN_SRC latex :noweb yes
\begin{table}[h]
\label{tbl:refyear}
\caption{Separation outcomes (death or any type of discharge) by
reference year.}
<>
\end{table}
#+END_SRC

I've tried :cache yes as part of the tbl-refyear source block, but
that didn't stop if from being run twice. Am I missing a suitable
header argument?

This is the only way I could find to wrap the latex table (which has
some complex formatting and hence why I've used it over just producing
a table) in a float with a caption (though I still can't properly
reference the label when I export to a PDF file).

Any thought would be greatly appreciated. TIA!

Andreas

On 18 September 2014 23:31, Eric S Fraga  wrote:
>
> On Thursday, 18 Sep 2014 at 13:26, Tobias Getzner wrote:
> > On Thu, 18 Sep 2014 13:17:14 +, Tobias Getzner wrote:
> >
> >> Are there any convenient inline-expansion methods I might have
> >> overlooked?
> >
> > To illustrate, I was wondering if any of the following is feasible
> > somehow:
>
> Yes, and you almost got it right with your syntactic expansion:
>
> #+begin_src org
>
>   ,* Syntactic expansion
>
>   ,#+name: setup_fu
>   ,#+begin_src sh :noweb yes
> echo 2
>   ,#+end_src
>
>   ,#+begin_src sh :results raw :noweb yes
> echo 1
> <>
> echo 3
>   ,#+end_src
>
>   ,#+results:
>   1
>   2
>   3
>
> #+end_src
>
> Org src blocks can reference other src blocks.  Note the ":noweb yes"
> option and the use of <<...>>.
>
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.1, Org release_8.3beta-366-gb2fca7

[O] list of agenda files in a file

[hymie!]

Greetings.

I'd like to add my _archive files to my agenda.  I don't need the entries
clogging up my day-to-day .org files, but I want the items to still
appear in my agenda.

I found this in the org manual:

>The information to be shown is normally collected from all agenda files,
>the files listed in the variable org-agenda-files[98].
>
>[98] If the value of that variable is not a list, but a single file name,
>then the list of agenda files will be maintained in that external file.

So based on that, I put this in my .emacs file:
  (setq org-agenda-files (quote ("~/org/agenda.file.list")))
but I cannot seem to get this to work.

When that file has a plain old list of filenames in it, I get an error
Agenda file ~/org/agenda.file.list is not in `org-mode'

When that file is empty, then there is nothing in my agenda.  I then
tried using C-c [ to add a file to the list, and I end up with
 '(org-agenda-files (quote ("~/org/file.org" "~/org/agenda.file.list")))
in my .emacs file.

Am I misunderstanding?  The manual sounds like I can maintain a file
that contains a list of files that the agenda should use.  But I can't
seem to make that happen, either automatically or manually.

What am I doing wrong?

--hymie!http://lactose.homelinux.net/~hymiehy...@lactose.homelinux.net

Re: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta (release_8.3beta-362-ga92789 /usr/local/share/emacs/site-lisp/org/)]

[Charles C. Berry]

On Thu, 18 Sep 2014, Charles C. Berry wrote:


On Thu, 18 Sep 2014, Cook, Malcolm wrote:


Hi,

Hmm, I spoke too soon the problem is only partially fixed by this 
patch...




Trying to work with in org-mode with R code blocks attached to persistent 
sessions (i.e. adding ':session myRsession' to the code block header ) 
makes things start to break again, at least in my hands.


Really? I have been working for hours using the :session header with no 
problems.


What exactly breaks? Do you have an example?

FWIW, this works when I move my cursor into the source block and C-c C-c.

--8<---cut here---start->8---
#+BEGIN_SRC R :session myRsession
abc <- 1
abc+1
#+END_SRC
--8<---cut here---end--->8---

Producing

--8<---cut here---start->8---
#+RESULTS:
: 2
--8<---cut here---end--->8---

which is what I expect.

I use Org-mode version 8.3beta (release_8.3beta-366-gb2fca7.

(updated a few hours back)



Forget to mention:

ess-version: 14.09 [git: 9c248f1a026b6990d0cd0cd326d82854d5cafb26]


Chuck

Re: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta (release_8.3beta-362-ga92789 /usr/local/share/emacs/site-lisp/org/)]

[Charles C. Berry]

On Thu, 18 Sep 2014, Cook, Malcolm wrote:


Hi,

Hmm, I spoke too soon the problem is only partially fixed by this patch...



Trying to work with in org-mode with R code blocks attached to 
persistent sessions (i.e. adding ':session myRsession' to the code block 
header ) makes things start to break again, at least in my hands.


Really? I have been working for hours using the :session header with no 
problems.


What exactly breaks? Do you have an example?

FWIW, this works when I move my cursor into the source block and C-c C-c.

--8<---cut here---start->8---
#+BEGIN_SRC R :session myRsession
abc <- 1
abc+1
#+END_SRC
--8<---cut here---end--->8---

Producing

--8<---cut here---start->8---
#+RESULTS:
: 2
--8<---cut here---end--->8---

which is what I expect.

I use Org-mode version 8.3beta (release_8.3beta-366-gb2fca7.

(updated a few hours back)



I'm going to wait till things settle down before trying to upgrade ESS again.


It would really help to be sure that this is not a problem with your 
setup. And if you can give a simple example that shows the problem, I'd 
appreciate it.


BTW, how does a 'persistent' session differ from all those other sessions?

Chuck

Re: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta (release_8.3beta-362-ga92789 /usr/local/share/emacs/site-lisp/org/)]

[Aaron Ecay]

Hi Malcom,

2014ko irailak 18an, "Cook, Malcolm"-ek idatzi zuen:
> 
> Hi,
> 
> Hmm, I spoke too soon the problem is only partially fixed by this
> patch...
> 
> Trying to work with in org-mode with R code blocks attached to
> persistent sessions (i.e. adding ':session myRsession' to the code
> block header ) makes things start to break again, at least in my
> hands.
> 
> I'm going to wait till things settle down before trying to upgrade ESS
> again.
> 
> Thanks for the patch anyway.

Can you give an ECM ?  I tried
to reconstruct what you are saying, but the patch seems to work as
expected for me.

(At the risk of being redundant, did you make sure that you are running
the most recent code including the patch?  The most foolproof way is to
navidate to the definition of ‘org-babel-R-initiate-session’ in ob-R.el,
verify that the call to ‘ess-wait-for-process’ is present, and use C-M-x
to reevaluate the defun.)

Thanks,

-- 
Aaron Ecay

Re: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta (release_8.3beta-362-ga92789 /usr/local/share/emacs/site-lisp/org/)]

[Cook, Malcolm]

Hi,

Hmm, I spoke too soon the problem is only partially fixed by this patch...

Trying to work with in org-mode with R code blocks attached to persistent 
sessions (i.e. adding ':session myRsession' to the code block header ) makes 
things start to break again, at least in my hands.

I'm going to wait till things settle down before trying to upgrade ESS again.

Thanks for the patch anyway.

Cheers,

Malcolm

 >-Original Message-
 >From: Cook, Malcolm
 >Sent: Wednesday, September 17, 2014 6:14 PM
 >To: 'Rainer M Krug'; 'Charles Berry'
 >Cc: 'emacs-orgmode@gnu.org'
 >Subject: RE: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta 
 >(release_8.3beta-362-ga92789 
 >/usr/local/share/emacs/site-lisp/org/)]
 >
 >Hiya,
 >
 >Likewise - same problem here is fixed with injection of patch.
 >
 >Thanks!
 >
 >~ malcolm_cook
 >
 >
 > >-Original Message-
 > >From: emacs-orgmode-bounces+mec=stowers@gnu.org 
 > >[mailto:emacs-orgmode-bounces+mec=stowers@gnu.org] On
 > >Behalf Of Rainer M Krug
 > >Sent: Wednesday, September 17, 2014 2:26 AM
 > >To: Charles Berry
 > >Cc: emacs-orgmode@gnu.org
 > >Subject: Re: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta 
 > >(release_8.3beta-362-ga92789 
 > >/usr/local/share/emacs/site-lisp/org/)]
 > >
 > >Rainer M Krug  writes:
 > >
 > >Using it, error is gone.
 > >
 > >Rainer
 > >
 > >> Charles Berry  writes:
 > >>
 > >>> Charles Berry  ucsd.edu> writes:
 > >>>
 > 
 >  Rainer M Krug  krugs.de> writes:
 > 
 >  >
 >  > Thanks - you came before me. I get the same error but managed to work
 >  > around.
 >  >
 >  > This is likely caused by the upgrade of ess,
 > 
 >  Likely.
 > 
 >  But it may not be an ESS problem per se.
 > 
 >  M-x R starts a process that runs asynchronously. In interactive use 
 >  there
 >  is no issue (barring something in .First() that slows the startup for
 >  a very long time).
 > 
 >  But, ...
 > 
 >  If the  (rename-buffer ...) in org-babel-R-initiate-session
 >  runs before all the setup that ESS performs in the process buffer is
 >  complete, chaos can result.
 > 
 >  Not sure what the best way is to fix this.
 > 
 > >>>
 > >>> OK. Looks like (ess-wait-for-process) fixes this. Here is a patch.
 > >>
 > >> Thanks.
 > >>
 > >> Haven't tried it yet, but I can't imagine any downside of this
 > >> patch. Could this be committed?
 > >>
 > >> Rainer
 > >>
 > >>>
 > >>> Chuck
 > >>> ==
 > >>>
 > >>> From 89472012d80ce9ad4c8722f304c0d29327efa1fc Mon Sep 17 00:00:00 2001
 > >>> From: chasberry 
 > >>> Date: Tue, 16 Sep 2014 19:57:59 -0700
 > >>> Subject: [PATCH] lisp/ob-R.el: use `ess-wait-for-process' to assure clean
 > >>>  session startup
 > >>>
 > >>> * lisp/ob-R.el (org-babel-R-initiate-session): Make sure that (R) has
 > >>> finished before `rename-buffer' is run.
 > >>>
 > >>> TINYCHANGE
 > >>> ---
 > >>>  lisp/ob-R.el | 3 +++
 > >>>  1 file changed, 3 insertions(+)
 > >>>
 > >>> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
 > >>> index 41b943c..7575acf 100644
 > >>> --- a/lisp/ob-R.el
 > >>> +++ b/lisp/ob-R.el
 > >>> @@ -35,6 +35,8 @@
 > >>>  (declare-function inferior-ess-send-input "ext:ess-inf" ())
 > >>>  (declare-function ess-make-buffer-current "ext:ess-inf" ())
 > >>>  (declare-function ess-eval-buffer "ext:ess-inf" (vis))
 > >>> +(declare-function ess-wait-for-process "ext:ess-inf"
 > >>> +  (&optional proc sec-prompt wait force-redisplay))
 > >>>  (declare-function org-number-sequence "org-compat" (from &optional to 
 > >>> inc))
 > >>>  (declare-function org-remove-if-not "org" (predicate seq))
 > >>>  (declare-function org-every "org" (pred seq))
 > >>> @@ -262,6 +264,7 @@ This function is called by 
 > >>> `org-babel-execute-src-block'."
 > >>>  ;; Session buffer exists, but with dead process
 > >>>  (set-buffer session))
 > >>>(require 'ess) (R)
 > >>> +  (ess-wait-for-process)
 > >>>(rename-buffer
 > >>> (if (bufferp session)
 > >>> (buffer-name session)
 > >
 > >--
 > >Rainer M. Krug
 > >email: Rainerkrugsde
 > >PGP: 0x0F52F982

Re: [O] Unexpected link behavior after exporting Org-mode file to HTML

[Bruce Gilstrap]

Thank you for fixing it. I have tested it and it works as expected now.

Bruce


On Thu, Sep 18, 2014 at 3:11 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Bruce Gilstrap  writes:
>
>> I am running Org-mode 8.2.7c in Emacs 24.3.1 on Windows 7 Ultimate and
>> have encountered a peculiarity with how links work in HTML exported
>> from Org-mode. I searched gmane.emacs.orgmode to see if someone else
>> has reported this before, but I didn't find anything exactly like
>> this. Please pardon me if I have missed something.
>>
>> I have used org-id extensively to assign unique IDs to headings in
>> Org-mode files (stored in the :PROPERTIES: drawer of the heading).
>> Before the new exporter framework was introduced in Org-mode 8.0 all
>> of these links worked without issue: no matter the level of the
>> heading's hierarchy, exported-HTML ID-based links worked fine.
>> However, using the new exporter framework produces different results.
>> Now, ID-based links always fail when the target heading lies at a
>> level below the headline level defined in the export settings, which
>> defaults to level 3 (H:3). Note: This is true only for the exported
>> HTML; ID-based links work perfectly within Emacs.
>
> This should be fixed. Thank you for reporting it.
>
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] help tracking down bad setting?

[Thorsten Jolitz]

Matt Price  writes:

> Removing the space between \C-c and \C-r worked.  I guess I really
> don't understand the syntax for setting keybindings in emacs -- every
> time I do it it's trial and error!

I think using (kbd ...) is the recommended way nowadays:

,[ C-h f kbd RET ]
| kbd is a compiled Lisp function in `subr.el'.
| 
| (kbd KEYS)
| 
| Convert KEYS to the internal Emacs key representation.
| KEYS should be a string constant in the format used for
| saving keyboard macros (see `edmacro-mode').
`

-- 
cheers,
Thorsten

[O] Bug: Add org-complete-tags-always-offer-target-tags

[carlosjosepita]

(Note: This is an RFE not a bug report, but I don't know how to RFE otherwise.)

My proposal is to add an option
org-complete-tags-always-offer-target-tags because both:

1) it's useful by itself for narrowed captures, and it's not quite
   exactly the same than org-complete-tags-always-offer-all-agenda-tags

2) for consistency with org-capture-templates escape sequences:

   %^g Prompt for tags, with completion on tags in target file.
   %^G Prompt for tags, with completion on all tags in all agenda files.

   you will have the tandem:

   org-complete-tags-always-offer-target-tags
   org-complete-tags-always-offer-all-agenda-tags


I think the consistency point is important. Nowadays you can initially
fill the tags for a capture using %^g or %^G. But say you change your
mind and do C-c C-q; now at best you have the %^G equivalent with
org-complete-tags-always-offer-all-agenda-tags.

Cheers
--
Carlos




Emacs  : GNU Emacs 24.3.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2014-08-27 on carlos
Package: Org-mode version 8.2.6 (release_8.2.6-1 @ 
/usr/share/emacs/24.3.93/lisp/org/)

Re: [O] help tracking down bad setting?

[Matt Price]

I meant to add: found the culprit by checking the value of org-mode-hook.
And also, thanks Thorsten!

Re: [O] help tracking down bad setting?

[Matt Price]

On Thu, Sep 18, 2014 at 3:46 PM, Matt Price  wrote:
> Hi everyone,
>
> When I load org-mode I get the following error:
>
> local-set-key: Key sequence C-c SPC C-r starts with non-prefix key C-c SPC
>
> I am pretty sure I set something to this value somewhere at some time,
> but I have no idea what, where, or when.  I have grepped through
>
> .emacs
> .emacs.d/*
>
> for local-set-key, "C-c SPC C-r" and "SPC" and I haven't found anything.
>

OK, I found it here:

  (local-set-key "\C-c  \C-r" 'org-decrypt-entry)

Removing the space between \C-c and \C-r worked.  I guess I really
don't understand the syntax for setting keybindings in emacs -- every
time I do it it's trial and error!

Matt

Re: [O] help tracking down bad setting?

[Thorsten Jolitz]

Matt Price  writes:

Hi,

> local-set-key: Key sequence C-c SPC C-r starts with non-prefix key C-c SPC

maybe the actual definition is not written SPC but SPACE,  or
something similar ..., even a literal space is possible AFAIK.

-- 
cheers,
Thorsten

Re: [O] Unexpected link behavior after exporting Org-mode file to HTML

[Nicolas Goaziou]

Hello,

Bruce Gilstrap  writes:

> I am running Org-mode 8.2.7c in Emacs 24.3.1 on Windows 7 Ultimate and
> have encountered a peculiarity with how links work in HTML exported
> from Org-mode. I searched gmane.emacs.orgmode to see if someone else
> has reported this before, but I didn't find anything exactly like
> this. Please pardon me if I have missed something.
>
> I have used org-id extensively to assign unique IDs to headings in
> Org-mode files (stored in the :PROPERTIES: drawer of the heading).
> Before the new exporter framework was introduced in Org-mode 8.0 all
> of these links worked without issue: no matter the level of the
> heading's hierarchy, exported-HTML ID-based links worked fine.
> However, using the new exporter framework produces different results.
> Now, ID-based links always fail when the target heading lies at a
> level below the headline level defined in the export settings, which
> defaults to level 3 (H:3). Note: This is true only for the exported
> HTML; ID-based links work perfectly within Emacs.

This should be fixed. Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou

[O] help tracking down bad setting?

[Matt Price]

Hi everyone,

When I load org-mode I get the following error:

local-set-key: Key sequence C-c SPC C-r starts with non-prefix key C-c SPC

I am pretty sure I set something to this value somewhere at some time,
but I have no idea what, where, or when.  I have grepped through

.emacs
.emacs.d/*

for local-set-key, "C-c SPC C-r" and "SPC" and I haven't found anything.

org still seems to run, but some process is interrupted, I think ,as
any function which calls (org-mode) will not run any code after that
call.

What do you think -- where should I look, and what should I search for?

Thanks a lot,

Matt

Re: [O] TODO items in lists (not headings)

[Gary Oberbrunner]

On Thu, Sep 18, 2014 at 12:23 PM, Subhan Michael Tindall <
subh...@familycareinc.org> wrote:

>  Lists are very explicitly not intended to contain TODO items.
>
> Checkboxes provide a bit of this functionality, sort of a ‘TODO lite’
>
> ...
>
> The problem is that list items/checkbox items are NOT headlines, and all
> the TODO code etc. is tied to headlines.
>
>
>
> I haven’t looked at the code but I suspect an extensive rewrite to
> integrate it with the rest of the headline code.  Not as much if it’s kept
> as an isolated extension.
>
>
>

I suspected as much.  Although having TODOs in lists would be awesome,
checkboxes will do for me now.

Thanks all!

-- 
Gary

[O] [PATCH][mini] bulk-mark-regexp and -toggle also with time grid

[marcowahlsoft]

Hi!

>From the documentation for * in an agenda-buffer (C-h k *):

--8<---cut here---start->8---
* runs the command org-agenda-bulk-mark-all (found in
  org-agenda-mode-map), which is an interactive compiled Lisp function
  in `org-agenda.el'.

It is bound to *,.

(org-agenda-bulk-mark-all)

Mark all entries for future agenda bulk action.
--8<---cut here---end--->8---

Currently this is not true if there is a time grid in the agenda buffer.

--8<---cut here---start->8---
G runs the command org-agenda-toggle-time-grid (found in...
--8<---cut here---end--->8---

Please consider to apply the attached patch.


Ciao,  Marco
-- 
http://www.wahlzone.de
PGP: 0x0A3AE6F2
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index dbc9861..c8808e5 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9680,7 +9680,7 @@ This is a command that has to be installed in `calendar-mode-map'."
 	  (overlay-put ov 'type 'org-marked-entry-overlay))
 	(end-of-line 1)
 	(or (ignore-errors
-	  (goto-char (next-single-property-change (point) 'txt)))
+	  (goto-char (next-single-property-change (point) 'org-hd-marker)))
 	(beginning-of-line 2))
 	(while (and (get-char-property (point) 'invisible) (not (eobp)))
 	  (beginning-of-line 2))
@@ -9734,7 +9734,7 @@ This is a command that has to be installed in `calendar-mode-map'."
   (save-excursion
 (goto-char (point-min))
 (while (ignore-errors
-	 (goto-char (next-single-property-change (point) 'txt)))
+	 (goto-char (next-single-property-change (point) 'org-hd-marker)))
   (org-agenda-bulk-toggle
 
 (defun org-agenda-bulk-toggle ()

Re: [O] TODO items in lists (not headings)

[Subhan Michael Tindall]

Lists are very explicitly not intended to contain TODO items.
Checkboxes provide a bit of this functionality, sort of a ‘TODO lite’
I use something like this quite a lot:
** TODO notes from meeting:meeting:steve:susan:jane:bob:action:
   DEADLINE: <2014-09-19 Fri>
   :PROPERTIES:
   :LastWorked: [2014-09-18 Thu 09:14]
  :END:
- Item 1
- Item 2
- [ ] action item 1
  - [X] sub action item
  - [ ] sub action item 2
- Item 3
extended meeting notes here

I’ve not used them at all, but there may be a way to set a statistics cookie 
for the headline, or if not a simple function to update a statistics-type 
cookie or property when an action item changes state

I do sometimes wish that I could include a TODO headline or tag a list item, 
but that is simply not possible under current implementations.
IE something like this:
** meeting
- TODO Item 1 tags: “tag1:tag2” LastWorked: [2014-09-18 Thu 09:14]
- item 2

With properties etc. handled in a way similar to BEGIN_SRC block headers

The problem is that list items/checkbox items are NOT headlines, and all the 
TODO code etc. is tied to headlines.

I haven’t looked at the code but I suspect an extensive rewrite to integrate it 
with the rest of the headline code.  Not as much if it’s kept as an isolated 
extension.



From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org 
[mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On Behalf Of 
Gary Oberbrunner
Sent: Wednesday, September 17, 2014 5:45 AM
To: Orgmode Mailing List
Subject: Re: [O] TODO items in lists (not headings)



On Tue, Sep 16, 2014 at 11:48 PM, Thomas S. Dye 
mailto:t...@tsdye.com>> wrote:
Aloha Gary,

Gary Oberbrunner mailto:ga...@oberbrunner.com>> writes:

> Gary:
>   My reason for not using TODO is just that it'd be ugly and confusing to
> put a heading in the middle of a list.
>
>   Compare this:
> * Meeting report
> ** Meeting 1
>   - a thing that happened
>   - another thing that happened
>   - TODO: email everyone about all the things
>   - some more things that happened
>
>   to this:
> * Meeting report
> ** Meeting 1
>   - a thing that happened
>   - another thing that happened
> ***TODO: email everyone about all the things
>   - some more things that happened

One solution is to use a capture template for TODO items and then refile
them.  I picked this up from Bernt Hansen and like it a lot:

http://doc.norang.ca/org-mode.html#Capture

Wow, that guy is serious!  I don't think his setup solves what I'm looking for, 
but there is so much great stuff in there it'll take me weeks to check it all 
out.

--
Gary

This message is intended for the sole use of the individual and entity to which 
it is addressed and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If you are not the intended 
addressee, nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone the 
message or any information contained in the message. If you have received this 
message in error, please immediately advise the sender by reply email and 
delete the message.  Thank you.

Re: [O] Changed behaviours of LaTeX exporter in version 8.0+

[Richard Lawrence]

Hi Joseph,

"Kyeong Soo (Joseph) Kim"  writes:

> Sorry for asking another question; this time it is for the
> cross-referencing in LaTeX export, which existed before (e.g., Sec. 16 of
> manual for <8.0) but is gone now.
> ...
> Now with 8.2.7c and the following org internal link to a section
>
> ... described in Sec. [[*SectionOne][SectionOne]] ...
>
> LaTeX export generates the following code:
>
> ... described in Sec. \texttt{SectionOne}, ...

I think the problem here is that you don't have a link type, and the new
LaTeX exporter doesn't convert links it doesn't understand into
references.

I use a series of custom link types to make references to document
parts in my dissertation.  Here's the code I use; you will probably want
to adapt it to your use case:

#+BEGIN_SRC elisp
;; use CUSTOM_ID properties to generate labels
(setq org-latex-custom-id-as-label t)

(defun org-find-headline-by-custom-id (prefix path)
  "Find a headline in the current buffer by CUSTOM_ID value PREFIX:PATH."
  (save-excursion
(goto-char (point-min))
 (and
  ; borrowed from org.el; there doesn't seem to be a function that searches
  ; for a headline with a specific property value
  (re-search-forward
   (concat "^[ \t]*:CUSTOM_ID:[ \t]+" prefix ":" path "[ \t]*$") nil t)
  (setq pos (match-beginning 0
   (if pos
   (progn
 (goto-char pos)
 (org-back-to-heading t))
 (message (format "Headline with CUSTOM_ID %s:%s not found." prefix path

(defun org-export-dissertation-link (prefix path desc format)
  "Export a link to a dissertation section, etc.

In LaTeX, the exported link will look like:
  DESC~\\ref{PREFIX:PATH}
"
(when (member format '(latex linguistics))
  (format "%s~\\ref{%s:%s}" desc prefix path)))

; Parts:
(org-add-link-type
 "part"
 (lambda (path)
   (org-find-headline-by-custom-id "part" path))
 (lambda (path desc format)
   (org-export-dissertation-link "part" path (or desc "Part") format)))

; Chapters:
(org-add-link-type
 "chap"
 (lambda (path)
   (org-find-headline-by-custom-id "chap" path))
 (lambda (path desc format)
   (org-export-dissertation-link "chap" path (or desc "Chapter") format)))

; Sections:
(org-add-link-type
 "sec"
 (lambda (path)
   (org-find-headline-by-custom-id "sec" path))
 (lambda (path desc format)
   (org-export-dissertation-link "sec" path (or desc "Section") format)))

; Tables:
(org-add-link-type
 "tab"
 (lambda (path) (org-link-search (concat "tab:" path)))
 (lambda (path desc format)
   (org-export-dissertation-link "tab" path (or desc "Table") format)))

#+END_SRC

So a link like "[[sec:foo]]" renders as "Section~\ref{sec:foo}",
"[[chap:foo]]" renders as "Chapter~\ref{chap:foo}", etc. when exported
to LateX, and you can follow links to jump to the appropriate document
headline.

Note that this works by giving my document sections fixed labels by
setting the CUSTOM_ID property.  I give headlines a descriptive name in
this property, using the LaTeX convention of prefixing "sec:", etc. to
keep my labels straight; Org then generates \label commands for document
parts using the CUSTOM_ID property.  This requires setting
org-latex-custom-id-as-label.  For example, a headline like

*** Another interesting section
:PROPERTIES:
:CUSTOM_ID: sec:interesting
:END:

is exported as

\section{Another interesting section}
\label{sec:interesting}

(The prefixes are important, since they function both as link types and
as parts of label/ref keys.  As you'll notice, the
org-export-dissertation-link function adds them back in to the key.)

I find this setup keeps things working well across revisions,
re-ordering and re-naming of sections, etc.

Hope that helps!

Best,
Richard

Re: [O] Changed behaviours of LaTeX exporter in version 8.0+

[Richard Lawrence]

Hi Joseph,

"Kyeong Soo (Joseph) Kim"  writes:

> I just found out that, if I close Emacs and relaunch it, all variables for
> filter (i.e., 'org-export-filter-*') are not defined. As a result, the
> following elisp codes for the workaround based on both your suggestion and
> the filter example in the manual causes void variable error (i.e.,
> "Symbol's value as variable is void:
> org-export-filter-special-block-function"):

Try adding:

(require 'ox)

before your filter definition.

Best,
Richard

Re: [O] org-babel-load-file misleading function name, wrong behavior

[Nick Dokos]

Marcin Antczak  writes:

> Hi,
>
> I would like to suggest changing the name to 'org-babel-load-lisp' as
> current name of this function doesn't emphasise that it can tangle and
> load "emacs-lisp" code blocks only.
>
> Another problem is that currently 'compile' option is performed every time.
> Which is plain wrong.
>
> Compile option is supposed to improve load time and should be
> performed only when it's neccessary.
>
>

The name was probably picked in analogy to the corresponding emacs-lisp
function `load-file' which also loads lisp files only. The latter is
much too well entrenched to ever consider renaming. The org-babel
version is certainly not, so renaming it is a possibility, although IMO
it's a hassle without much payoff: C-h f org-babel-load-file tells you
what you need to know.

Nick

Re: [O] [PATCH] WAS Re: Bug: problem w/ R code blocks [8.3beta (release_8.3beta-362-ga92789 /usr/local/share/emacs/site-lisp/org/)]

[Charles C. Berry]

On Wed, 17 Sep 2014, Aaron Ecay wrote:


Hi all,

I have pushed the patch to the master branch, thanks to Chuck and to
Rainer and Malcom for testing it.

Chuck, it looks like you have already provided another “preliminary
patch” for org back in 2012 (commit 578a7f5a).  If it’s possible for
you, it might be good to do the copyright assignment described at
 before you run
out of lifetime eligibility for TINYCHANGEs (which is ultimately
controlled by the emacs core developers and/or FSF’s lawyers, but
it’s widely taken to be 15 lines or fewer).



OK. I just sent my form in.

Chuck

[O] resize multiple image within a row or paragraph

[alban bernard]

Hi Folks,

My wife and I use the marvelous org-mode to design a complete set
of student courses. These courses are first written in org-mode then
exported to html to ease distribution to students (and save some paper).

We wonder what is the correct way to resize multiple images those links
are within a single paragraph:

"This is a phrase with [[./image1.png]] and [[./image2.png]] inline images."
 
With the following, the only first image is resized (as expected):

 #+ATTR_HTML: :width 50%
 This is a phrase with [[./image1.png]] and [[./image2.png]] inline images.
 
The tutorial about caption in a row shows what is possible while working
only with images
http://orgmode.org/worg/org-tutorials/images-and-xhtml-export.html#sec-5-2:

 #+HTML_HEAD: 
 #+HTML_HEAD:
 #+HTML_HEAD: 

 #+CAPTION:
 #+ATTR_HTML: :width 10%
 [[./image1.png]]
 #+CAPTION:
 #+ATTR_HTML: :width 10%
 [[./image2.png]]

Here, image1 and image2 are displayed and resized in a single row. 
But we don't know how to mix text within this block so that all is 
displayed as a single paragraph with resized images.

I tested all of this with the following version combos:
Debian Jessie/Emacs 24.3.1/Orgmode 8.2.5h-1 (debian)
Debian Jessie/Emacs 24.3.1/Orgmode latest git

Thanks for any hint that could help.

~Alban.

PS: the "Show the source" button of 
http://orgmode.org/worg/org-tutorials/images-and-xhtml-export.html
redirects to:
http://orgmode.org/worg/org-tutorials/images-and-xorg.html-export.org.html
rather than:
http://orgmode.org/worg/org-tutorials/images-and-xhtml-export.org.html

[O] Unexpected link behavior after exporting Org-mode file to HTML

[Bruce Gilstrap]

Hello,

I am running Org-mode 8.2.7c in Emacs 24.3.1 on Windows 7 Ultimate and
have encountered a peculiarity with how links work in HTML exported
from Org-mode. I searched gmane.emacs.orgmode to see if someone else
has reported this before, but I didn't find anything exactly like
this. Please pardon me if I have missed something.

I have used org-id extensively to assign unique IDs to headings in
Org-mode files (stored in the :PROPERTIES: drawer of the heading).
Before the new exporter framework was introduced in Org-mode 8.0 all
of these links worked without issue: no matter the level of the
heading's hierarchy, exported-HTML ID-based links worked fine.
However, using the new exporter framework produces different results.
Now, ID-based links always fail when the target heading lies at a
level below the headline level defined in the export settings, which
defaults to level 3 (H:3). Note: This is true only for the exported
HTML; ID-based links work perfectly within Emacs.

Here is a minimal example that demonstrates this behavior when I
export it to HTML (see annotations for details):

#+OPTIONS: toc:nil
* Headline Level 1
** Headline Level 2
*** Headline Level 3
:PROPERTIES:
:ID:   307db49e-e001-4a7b-9541-96eee2ae6f06
:END:
 <>Non-headline level
:PROPERTIES:
:ID:   3be9179d-f838-4052-93ca-6c76c9aff12d
:END:
* Headline Level 1
Now I want to link to information that appears elsewhere in the file.
Links work as expected within Emacs. When exported to HTML, however,
links do not work as they did before the new exporter framework was
introduced in Org-mode 8.0.
[[id:307db49e-e001-4a7b-9541-96eee2ae6f06][ID-based link to 1.1.1]]
This link /does/ work. Using IDs always works for links to any
headline level. By "headline level" I mean any Org-mode heading that
is defined as a headline (default H:3).
[[id:3be9179d-f838-4052-93ca-6c76c9aff12d][ID-based link to Non-headline level]]
This link using the ID /doesn't/ work when exported to HTML using the
new exporter framework. Now, using IDs as the target for links
/always/ fails for links to any headline lower than the headline level
defined in the export settings.
[[heading-level-4][Non-ID-based link to Non-headline level]]
Using an internal link works, but I have /many/ existing files that
depend on IDs for links at heading levels lower than the levels I want
treated as (numbered) headlines.

You can view the exported HTML file here:
http://work.gilstraps.org/org/demo-links.html

I believe the relevant function in ox-html.el is org-html-headline,
but I'm a novice (at best) with elisp.

My questions are these:
1. Is this behavior by design?
2. If so, how can I make ID-based links to non-headlines work the way
I expect them to?
3. If not, shouldn't this be treated as a bug?

Thanks,
Bruce

Re: [O] «Macro» expansion in source blocks; code-sharing between blocks

[Tobias Getzner]

On Thu, 18 Sep 2014 15:01:37 +0100, Eric S Fraga wrote:

>>> Are there any convenient inline-expansion methods I might have
>>> overlooked?
> Org src blocks can reference other src blocks.  Note the ":noweb yes"
> option and the use of <<...>>.

Nice! And I see I get «semantic» expansion when I add call syntax after 
the block’s name. This is quite awesome.

Not being familiar with the term, «noweb» must have slipped my attention 
when I was skimming through that section. Thanks very much for the 
pointer!

Best,
T.

Re: [O] «Macro» expansion in source blocks; code-sharing between blocks

[Eric S Fraga]

On Thursday, 18 Sep 2014 at 13:26, Tobias Getzner wrote:
> On Thu, 18 Sep 2014 13:17:14 +, Tobias Getzner wrote:
>
>> Are there any convenient inline-expansion methods I might have
>> overlooked?
>
> To illustrate, I was wondering if any of the following is feasible 
> somehow:

Yes, and you almost got it right with your syntactic expansion:

#+begin_src org

  ,* Syntactic expansion

  ,#+name: setup_fu
  ,#+begin_src sh :noweb yes
echo 2
  ,#+end_src

  ,#+begin_src sh :results raw :noweb yes
echo 1
<>
echo 3
  ,#+end_src

  ,#+results:
  1
  2
  3

#+end_src

Org src blocks can reference other src blocks.  Note the ":noweb yes"
option and the use of <<...>>.


-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.1, Org release_8.3beta-366-gb2fca7


signature.asc
Description: PGP signature

Re: [O] «Macro» expansion in source blocks; code-sharing between blocks

[Tobias Getzner]

On Thu, 18 Sep 2014 13:17:14 +, Tobias Getzner wrote:

> Are there any convenient inline-expansion methods I might have
> overlooked?

To illustrate, I was wondering if any of the following is feasible 
somehow:

* Semantic expansion
  #+name setup_fu
  #+begin_src sh :results raw
  echo 2
  #+end_src

  #+begin_src sh :results raw
  echo 1
  echo {{{call_setup_fu()}}} ← some sort of escape syntax
  echo 3
  #+end_src

  #+results:
  1
  2
  3

* Syntactic expansion
  #+begin_macro setup_fu
  echo 2
  #+end_macro

  #+begin_src sh :results raw
  echo 1
  {{{setup_fu()}}}
  echo 3
  #+end_src

  #+results:
  1
  2
  3

[O] «Macro» expansion in source blocks; code-sharing between blocks

[Tobias Getzner]

Hello,

I was wondering whether there exists some way of sharing literal code 
(or, possibly, code results) between subsequent code blocks. E.g., I was 
trying to create a document containing several tikz graphics, and I would 
like to share a number of style definitions between these. When I only 
export to LaTeX, I can of course just use isolated BEGIN_LATEX blocks, 
and refer to shared stuff using LaTeX semantics. But I was wondering if 
something like this could possibly be done using code blocks only.

It seemed to me that there are two «expansion mechanisms» for source code 
in org: 1. Calling named source blocks; 2. macro expansion.

As for 1., calling a named block from within another isn’t currently 
handled, is it? As for 2., macro expansion only occurs upon export, 
right? While I found an interesting proposal to expand macros within 
source code at [1], this supposedly only works when either doing an 
export or when tangling an external file.

Are there any convenient inline-expansion methods I might have overlooked?

Best regards,
Tobias


[1] https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00843.html

Re: [O] async export not working for me

[Rasmus]

Hi Julien,

Julien Cubizolles  writes:

> I could get it to work at last, thank you a lot. I noticed something
> though: when I run org-latex-export-to-pdf async on a very simple test
> org file, the *Org Export Stack* buffer displays
>
>  latex0:07   /home/wilk/tmp/test.pdf
>
> and the minibuffer indicates that the process completed.
>
>
> When I publish a complex project, the line in this buffer is
>
>   exit   *Org Export Process*<6>
>
> same as if there had been a problem. There is no success message in the
> minibuffer, but no error message in the *Org Export Process* buffer.

Async is solid so most likely you're still facing a bug.  Maybe
something is missing from your async init file that is available to
Org when you export without async — 'cause I expect the file to export
just fine without async.

I debug async errors by starting emacs -q, evaling my asyc init file
and exporting my non-functioning buffer without async.

Alternatively you should look for clues in `temporary-file-directory'
cf. the docstring of `org-export-async-debug'.

Hope it helps,
Rasmus

-- 
The Kids call him Billy the Saint

[O] Bug: Face defined for quote/verse blocks, but not used?

[Tobias Getzner]

Hello,

I was looking into applying a custom font to certain org-mode faces, when 
I noticed that no dedicated face seems to be set for verse and quote 
blocks. Looking into org-faces.el, it looked (to non-Elisp-trained eyes) 
like there are faces set-up for these blocks, but for some reason they 
don’t seem to be applied. At least M-x describe-text-properties doesn’t 
show any face properties at point when in these blocks.

Best regards,
Tobias


Org-mode version 8.2.7c (8.2.7c-64-g01f736-elpa @ /home/tbz/.emacs.d/elpa/
org-20140915/)

Re: [O] [Feature request] org-babel-tangle-file add an option to tangle if target-file is older than file.

[Thorsten Jolitz]

Marcin Antczak  writes:

> As in topic.
>
> I think that if both parameters 'file' and 'target-file' are set and
> target-file' exists, 'org-babel-tangle-file' should tangle only if
> target-file' is older.

I think the Org based Emacs Starter Kit does this conditional tangling,
you might have a look there
(http://eschulte.github.io/emacs24-starter-kit/) to see how it is done.

-- 
cheers,
Thorsten

Re: [O] Headline text special property

[Brett Witty]

Thanks! It'd be nice if there was a way to turn this into a property for
easy dynamic columnview blocks, but I guess you can't have everything :)

BrettW

On Wed, Sep 17, 2014 at 2:36 AM, Thorsten Jolitz  wrote:

> Brett Witty  writes:
>
> Hi,
>
> > Is there a special property that contains the text of a headline but
> > not the stars, todo, tags or any of that other data?
>
> not a property, but functions:
>
> ,[ C-h f org-heading-components RET ]
> | org-heading-components is a compiled Lisp function in `org.el'.
> |
> | (org-heading-components)
> |
> | Return the components of the current heading.
> | This is a list with the following elements:
> | - the level as an integer
> | - the reduced level, different if `org-odd-levels-only' is set.
> | - the TODO keyword, or nil
> | - the priority character, like ?A, or nil if no priority is given
> | - the headline text itself, or the tags string if no headline text
> | - the tags string, or nil.
> `
>
> * TODO Test :mytag:
>
> #+BEGIN_SRC emacs-lisp
> (save-excursion
>  (outline-previous-heading)
>   (nth 4 (org-heading-components)))
> #+END_SRC
>
> #+results:
> : Test
>
> or
>
> ,[ C-h f org-get-heading RET ]
> | org-get-heading is a compiled Lisp function in `org.el'.
> |
> | (org-get-heading &optional NO-TAGS NO-TODO)
> |
> | Return the heading of the current entry, without the stars.
> | When NO-TAGS is non-nil, don't include tags.
> | When NO-TODO is non-nil, don't include TODO keywords.
> `
>
> #+BEGIN_SRC emacs-lisp
> (save-excursion
>  (outline-previous-heading)
>   (org-get-heading t t))
> #+END_SRC
>
> #+results:
> : Test
>
> --
> cheers,
> Thorsten
>
>
>

[O] INCLUDE heading

[Rob Richmond]

Hi all,

I use org-mode to write both papers and slides. The code to generate tables
and figures is placed in source blocks. Most of the time I use the same
tables in my slides as in my papers, but a lot of preprocessing code is
needed to generate the tables. I'd like to put the generation of these
tables in its own org-mode file and just be able to include certain
headings in the paper or slide document. For example, I would have an
org-mode document called mytables.org:

* Heading 1

** Regressions

#+BEGIN_SRC R

cat("hello world")

#+END_SRC R

* Heading 2


And another document mypaper.org:

* Section 1

#+INCLUDE: "mytables.org" :heading "Heading 1/Regressions"

* Section 2

The content from below the ** Regression headline in mytables.org would be
included on export in mypaper.org. It would also be great to be able to
follow the INCLUDE to the file with C-c '. Org provides some facilities for
these includes, but does not allow for headings (
http://orgmode.org/manual/Include-files.html ). Obviously org does not have
the :heading parameter, but any suggestions for a solution to make this
work are greatly appreciated. It looks like org-export-expand-include-keyword
is doing a lot of the magic of including the files, but I'm not sure where
to go from there.

Thanks for any help.

Re: [O] Make html password protected?

[Rainer M Krug]

Ian Barton  writes:

> On 08/09/14 11:22, Rainer M Krug wrote:
>> Hi
>>
>> I do not have much experience with html and websites (what an
>> understatement!) but I would like to publish / export a simple html page
>> password protected. Is ther an easy way to do it in word?
>>
>> The content is not highly confidential or sensitive, just some analysis
>> for a paper of which I would like to provide regular feedback to my
>> co-authors and which should not be to easily readable by others.
>>
>> Any suggestions?
>>
>
> It depends if you have access to your web server configuration. If you
> are able to modify it the simplest way is to create an .htacess file
> in the directory containing your file:

Unfortunately I am not. I only have ftp access to the html directory.

Rainer

>
> AuthName"Journal"
> AuthTypeDigest file:
> AuthUserFile/etc/httpd/journal.passwd
> Require valid-user
> Order   allow,deny
> Satisfy any
>
> You can create a password file with:
>
> htdigest -c /etc/httpd/journal.passwd "Journal" username
>
> To add more users omit the -c argument, which will create a new file.
>
> Make sure you use digest authentication not basic (ie don't use
> htpasswd). Basic authentication transmits user names and passwords in
> plain text.
>
> Ian.
>
>

-- 
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


pgpBoXiugsDeF.pgp
Description: PGP signature

[O] Call speed-commands with prefix-arg?

[Thorsten Jolitz]

Hi List, 

is there a way to call Org speed-commands [fn:1] with a prefix-arg?
Does not work for me ...

* Footnotes

[fn:1] see M-x org-speed-command-help

-- 
cheers,
Thorsten

[O] [Feature request] org-babel-tangle-file add an option to tangle if target-file is older than file.

[Marcin Antczak]

As in topic.

I think that if both parameters 'file' and 'target-file' are set and 
'target-file' exists, 'org-babel-tangle-file' should tangle only if 
'target-file' is older.



Marcin

[O] org-babel-load-file misleading function name, wrong behavior

[Marcin Antczak]

Hi,

I would like to suggest changing the name to 'org-babel-load-lisp' as 
current name of this function doesn't emphasise that it can tangle and 
load "emacs-lisp" code blocks only.


Another problem is that currently 'compile' option is performed every time.
Which is plain wrong.

Compile option is supposed to improve load time and should be performed 
only when it's neccessary.



Marcin

Re: [O] Changed behaviours of LaTeX exporter in version 8.0+

[Kyeong Soo (Joseph) Kim]

Sorry for asking another question; this time it is for the
cross-referencing in LaTeX export, which existed before (e.g., Sec. 16 of
manual for <8.0) but is gone now.


Per the suggestion from the older manual for <8.0, I have the following
setting in my configuration file:

(setq org-export-latex-hyperref-format "\\ref{%s}") ; for cross-referencing


Now with 8.2.7c and the following org internal link to a section

... described in Sec. [[*SectionOne][SectionOne]] ...


LaTeX export generates the following code:

... described in Sec. \texttt{SectionOne}, ...


Regards,

Joseph


On Thu, Sep 18, 2014 at 3:07 PM, Kyeong Soo (Joseph) Kim <
kyeongsoo@gmail.com> wrote:

> Nicolas and All,
>
> One further question regarding your suggestion of the use of filter for
> special blocks in export:
>
> I just found out that, if I close Emacs and relaunch it, all variables for
> filter (i.e., 'org-export-filter-*') are not defined. As a result, the
> following elisp codes for the workaround based on both your suggestion and
> the filter example in the manual causes void variable error (i.e.,
> "Symbol's value as variable is void:
> org-export-filter-special-block-function"):
>
>
> ;; workaround solution (until 8.3.0) for case-sensitve handling of
> special-block for IEEE LaTeX class
> (defun my-latex-filter-ieeekeywords (text backend info)
>   "Upcase 'IEEE' in IEEEkeywords environment in LaTeX export."
>   (when (org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "ieeekeywords" "IEEEkeywords" text)))
>
> (add-to-list 'org-export-filter-special-block-functions
>  'my-latex-filter-ieeekeywords)
>
>
> It turns out that those variables are defined only after exporting org
> file into LaTeX.
>
> Again, any advice on propor addition of custom filter functions in the
> configuration file would be greatly appreciated; maybe the said example in
> the manual needs to be updated as well.
>
> Regards,
> Joseph
>
>
>
> On Thu, Sep 18, 2014 at 12:50 PM, Kyeong Soo (Joseph) Kim <
> kyeongsoo@gmail.com> wrote:
>
>> Hello Nicolas,
>>
>> Great thanks for the detailed instructions with clear explanations for
>> the problems.
>>
>> I have addressed all those issues per your suggestions, but put some
>> comments embedded below.
>>
>>
>> Again, many thanks for your great help!
>>
>> Joseph
>>
>>
>> On Thu, Sep 18, 2014 at 3:01 AM, Nicolas Goaziou 
>> wrote:
>>
>> -> snip <-
>>
>>>
>>> > 2. Accessing the value of "#+KEYWORDS:" and change of cases in
>>> > "org-special-blocks"
>>> >
>>> > For keywords section in IEEE papers, I used to have the following
>>> settings:
>>> >
>>> > #+KEYWORDS: AAA, BBB, CCC
>>> > ...
>>> > #+BEGIN_IEEEkeywords
>>> > {{{KEYWORDS}}}.
>>> > #+END_IEEEkeywords
>>>
>>> [...]
>>>
>>> > Version 8.2.7c, however, produces the following from the same settings:
>>> >
>>> > \begin{ieeekeywords}
>>> > .
>>> > \end{ieeekeywords}
>>>
>>> I'm surprised {{{KEYWORDS}}} even worked as, AFAIK, it wasn't
>>> documented.  Indeed, there is no such macro in Org 8.0.  However, you
>>> can define your own
>>>
>>
>> '{{{KEYWORDS}}}' worked without any issues in previous versions, which in
>> fact was suggested by someone in the mailing list or stackoverflow
>> (unfortunately, I couldn't find that via Google any longer).
>>
>> By the way, in Sec. 12.3 of the Org manual (ver. 8.2.7c), 'KEYWORDS' is
>> listed together with 'AUTHOR', 'TITLE' and so on as export keywords. Also,
>> according to Sec. 11.6, those predefined keywords (e.g.,  #+TITLE:,
>> #+AUTHOR:) can be accessed by {{{title}}} and {{{author}}} like
>> user-defined macros.
>>
>> It seems that there is some inconsistency between the actual behavior and
>> the corresponding manual in export engine of org-mode ver. 8.2.7c.
>>
>> -> snip <-
>>
>
>

Re: [O] Changed behaviours of LaTeX exporter in version 8.0+

[Kyeong Soo (Joseph) Kim]

Nicolas and All,

One further question regarding your suggestion of the use of filter for
special blocks in export:

I just found out that, if I close Emacs and relaunch it, all variables for
filter (i.e., 'org-export-filter-*') are not defined. As a result, the
following elisp codes for the workaround based on both your suggestion and
the filter example in the manual causes void variable error (i.e.,
"Symbol's value as variable is void:
org-export-filter-special-block-function"):


;; workaround solution (until 8.3.0) for case-sensitve handling of
special-block for IEEE LaTeX class
(defun my-latex-filter-ieeekeywords (text backend info)
  "Upcase 'IEEE' in IEEEkeywords environment in LaTeX export."
  (when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "ieeekeywords" "IEEEkeywords" text)))

(add-to-list 'org-export-filter-special-block-functions
 'my-latex-filter-ieeekeywords)


It turns out that those variables are defined only after exporting org file
into LaTeX.

Again, any advice on propor addition of custom filter functions in the
configuration file would be greatly appreciated; maybe the said example in
the manual needs to be updated as well.

Regards,
Joseph


On Thu, Sep 18, 2014 at 12:50 PM, Kyeong Soo (Joseph) Kim <
kyeongsoo@gmail.com> wrote:

> Hello Nicolas,
>
> Great thanks for the detailed instructions with clear explanations for the
> problems.
>
> I have addressed all those issues per your suggestions, but put some
> comments embedded below.
>
>
> Again, many thanks for your great help!
>
> Joseph
>
>
> On Thu, Sep 18, 2014 at 3:01 AM, Nicolas Goaziou 
> wrote:
>
> -> snip <-
>
>>
>> > 2. Accessing the value of "#+KEYWORDS:" and change of cases in
>> > "org-special-blocks"
>> >
>> > For keywords section in IEEE papers, I used to have the following
>> settings:
>> >
>> > #+KEYWORDS: AAA, BBB, CCC
>> > ...
>> > #+BEGIN_IEEEkeywords
>> > {{{KEYWORDS}}}.
>> > #+END_IEEEkeywords
>>
>> [...]
>>
>> > Version 8.2.7c, however, produces the following from the same settings:
>> >
>> > \begin{ieeekeywords}
>> > .
>> > \end{ieeekeywords}
>>
>> I'm surprised {{{KEYWORDS}}} even worked as, AFAIK, it wasn't
>> documented.  Indeed, there is no such macro in Org 8.0.  However, you
>> can define your own
>>
>
> '{{{KEYWORDS}}}' worked without any issues in previous versions, which in
> fact was suggested by someone in the mailing list or stackoverflow
> (unfortunately, I couldn't find that via Google any longer).
>
> By the way, in Sec. 12.3 of the Org manual (ver. 8.2.7c), 'KEYWORDS' is
> listed together with 'AUTHOR', 'TITLE' and so on as export keywords. Also,
> according to Sec. 11.6, those predefined keywords (e.g.,  #+TITLE:,
> #+AUTHOR:) can be accessed by {{{title}}} and {{{author}}} like
> user-defined macros.
>
> It seems that there is some inconsistency between the actual behavior and
> the corresponding manual in export engine of org-mode ver. 8.2.7c.
>
> -> snip <-
>