Re: [O] Citation syntax: a revised proposal

[Thomas S. Dye]

Aloha Aaron,

Aaron Ecay  writes:

> I have made citeproc-java give output like:
>
> Smith2014
> Doe1999
> Smith et al.2005
>
> I parse that into lists of (author, year) pairs by splitting on the
> .  Then I expose a template to elisp: “%p%a (%y%s)” (for prefix,
> author, year, and suffix).  This template could be changed however it is
> desired by a user: using square brackets instead of round parens, for
> example.  I think people will likely want to customize things like this,
> and it seems difficult to get such flexibility from CSL.

The CSL web page says:

,-
| While CSL styles only define complete citations, e.g. “(Doe, 2002)”, the
| word processor plugins of Zotero, Mendeley, and Papers all allow you to 
| suppress the author(s) in individual citations, which would leave you   
| with just “(2002)”. You then have to write the author’s name by hand.   
`-

So, your implementation seems to be ahead in this respect.

I'd expect the author would want to have a list of templates for each
author-date CSL style, one for parenthetical citations, one for text
citations, another for genitive citations, etc.  It might even be nice
down the road to have a place where these could be stored and shared.

All the best,
Tom

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

Re: [O] Table caption in Latex export with :float nil

[Vikas Rawal]

This seems to work:

#+name: milk-consumption-india
#+attr_latex: :placement [H] :environment tabular :caption 
\captionof{table}{\label{milk-consumption-india}Average consumption of milk, 
India, kilograms per capita per annum}
| Year| Rural | Urban |  All |
|-+---+---+--|
| 1983|  38.7 |  55.6 | 44.7 |
| 1993–1994   |  50.3 |  66.4 | 54.3 |
| 2004–2005   |  50.2 |  69.3 |   55 |
| 2009–2010   |  51.7 |  71.6 | 57.1 |
| <4colc>Source: citet:anjani2014 |   |   |  |

Is :float deprecated?

Vikas

> On 11-Mar-2015, at 7:46 am, Vikas Rawal  
> wrote:
> 
> I need to insert a table in an mdframed box, for which I need to turn off 
> :float. The following, however, does not give me the caption:
> 
> #+name: milk-consumption-india
> #+attr_latex: :float nil :environment tabular :caption 
> \caption{\label{milk-consumption-india}Average consumption of milk, India, 
> kilograms per capita per annum}
> | Year| Rural | Urban |  All |
> |-+---+---+--|
> | 1983|  38.7 |  55.6 | 44.7 |
> | 1993–1994   |  50.3 |  66.4 | 54.3 |
> | 2004–2005   |  50.2 |  69.3 |   55 |
> | 2009–2010   |  51.7 |  71.6 | 57.1 |
> | <4colc>Source: citet:anjani2014 |   |   |  |
> 
> 
> I have also tried (along with #+latex_header: \usepackage{caption})
> 
> #+name: milk-consumption-india
> #+attr_latex: :float nil :environment tabular :caption 
> \captionof{table}{\label{milk-consumption-india}Average consumption of milk, 
> India, kilograms per capita per annum}
> | Year| Rural | Urban |  All |
> |-+---+---+--|
> | 1983|  38.7 |  55.6 | 44.7 |
> | 1993–1994   |  50.3 |  66.4 | 54.3 |
> | 2004–2005   |  50.2 |  69.3 |   55 |
> | 2009–2010   |  51.7 |  71.6 | 57.1 |
> | <4colc>Source: citet:anjani2014 |   |   |  |
> 
> Vikas
> 
> 

[O] Extraneous output from Python code blocks using :session option

[Richard Stanton]

I'm trying to use the :session option so I can import modules, etc., just once 
at the beginning of my document, like with am IPython notebook. Unfortunately, 
the output from these code blocks contains some extraneous characters. For 
example:

#+BEGIN_SRC python :session :results output
a = 2
b = 3
c = 4
print 'a=  ', a
print 'b = ', b
print 'a + b = ', a+b
#+END_SRC

#+RESULTS:
: 
: >>> >>> a=   2
: b =  3
: a + b =  5

How can I stop the production of all those ">" signs (sometimes they're dots), 
which don't appear if I run the same code block without the :session option?

Thanks.

Richard Stanton

Re: [O] Bleeding edge in elpa

[Aaron Ecay]

Hi Terry,

2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen:

> Of the things in your list, I think only the NEWS and Changelog are
> absent from the master branch in git.  Lots of us happily use Org master
> from git without them every day.  Do they really need to be done at
> all?

Many people are very happy not using org at all.  Perhaps we should just
all quit and find other hobbies.  OTOH, release milestones are important
to the health of a software project and so yes, really need to be done.

>
> If Emacs 25 is taking Org out of core, does the code still have to be
> merged into the trunk?

This is not on the table.  Rather, the (tentative) proposal from the
emacs side is for some packages to be developed in the GNU ELPA
repository, and be extracted from there and bundled with emacs release
tarballs (in addition to being released in ELPA).

Org is sometimes cited as an example of a package that would benefit from
this strategy, but there has been no discussion of this from the org
side, and AFAIK no decision has been made whether we’d take advantage of
this facility if/when it’s available.

>
> If the manpower does not exist to support both a maint and a master
> branch, maybe they should be merged.  Could that be done?
>
> Still just trying to make it easier to spread the gospel of Org,

Exposing new users to the vagaries of the master branch may rather lead
to atheism.

--
Aaron Ecay

Re: [O] Citation syntax: a revised proposal

[Aaron Ecay]

Hi Richard,

Thanks for your comments, and for your work on an implementation.

2015ko martxoak 10an, Richard Lawrence-ek idatzi zuen:
> I have actually been working on the same problem, using citeproc-hs as
> the CSL processor instead of citeproc-java.

This is an interesting approach.  What version of citeproc-hs are you
using?  The version under that name is no longer maintained, and I had
some trouble getting it to build.  The pandoc fork (under the name
pandoc-citeproc) seemed to me to lack command-line functionality.  (But
I only looked briefly and could have missed something.)

> I took a (very) brief look at your code; it seems like you are only
> communicating with citeproc-java via command line arguments and stdout.
> Is that right?

Yes.

>
> My approach to the problems you mention has been the following:
>   1) Generate JSON from citation objects on the Org side.
>   2) Pass that JSON to the processor via stdin.
>   3) Pass the output format, the CSL file, and the bibliography database
>  to the processor via command line arguments.
>   4) Return, to stdout, the formatted citations and the bibliography.
>  These are formatted such that there is one citation or entry per line,
>  and a recognizable separator separates the citations from the
>  bibliography.
>
> This allows passing formatting options for individual citations via the
> JSON object for that citation, so it allows citeproc-hs to do more of
> the work of formatting citations.
>
> (See http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#citation-data-object
> for documentation of the citation data JSON format.)

Very interesting.  But it looks like the CSL standard does not
differentiate parenthesized/not and capitalized/not citations, whereas
biblatex (taken as the best representative of the latex family of
citation processors) does.  I think we have decided we need to support
these.  So we will always need to do some post-processing of the CSL
output.  Then the question arises (for example) whether it’s better to
let CSL/citeproc handle the prefix and suffix, or to do it ourselves.

I don’t think we can decide this without looking at a working “sketch”
of both implementations.  It would be very good to see your draft code.

>
> I don't know whether this will ultimately be a good design, but the way
> I am picturing it right now is that exporting citations will work sort
> of like footnotes: the exporter will gather them all together as they
> are encountered, then generate the JSON and run a single call to the CSL
> processor at the end of the export process.  It can then replace the
> citations in the document with the result from the CSL processor, and
> insert the bibliography at the end of the document.

My code does something similar.  It processes all citations at the
beginning of export and stashes the data in the info plist, so that
it’s available to transcoders during the “main” export process.  IDK if
footnotes are handled in the same way, or rather processed in a late
step after the transcoders.  But it’s six of one, half a dozen of the
other I think.

>
> (The code is not very pretty yet, but it does generate citations and
> bibliographies in both plain text and HTML, and it would be
> straightforward to extend it to other output formats.  I can post it
> somewhere if anyone is interested in taking a look.)

Please do!

>
>> Some people have talked about supporting other CSL processors.  I don’t
>> see much utility in that, since CSL is a standard that all processors
>> should implement faithfully.
>
> Indeed!  Though as you have observed, `should' and `already does' come
> apart.  I doubt there are any implementations that are perfectly
> complete.  So it may be worth thinking about how Org can talk to CSL
> processors in a processor-independent way.  That way, different users
> can use different CSL processors if one works better for their
> particular document or environment.

I take your point, but any differences in the implementation just make
it potentially harder to be processor-independent.  I think we should
tightly integrate with one processor, working around whatever warts it
may have.

>
> I think the generate-and-pass-JSON approach is promising for that
> reason.  That is what citeproc-js accepts as input (so maybe that is
> what citeproc-java is doing internally?), and my code aims to allow
> citeproc-hs to interpret the same JSON format as citeproc-js.

... hmm.  Do you mean you’ve written Haskell code?

> I don't know Ruby, but I think it would be easy to make citeproc-ruby
> accept the same JSON format.  Do you have a sense of how easy it would
> be to coax citeproc-java into accepting JSON on stdin?

My understanding is that citeproc-java in its current form can read JSON
database files (in addition to bibtex).  However, it does not accept JSON
to control output of citations – it merely allows passing a key, for
which a “default” citation will be generated (no prefix/suffix/author
suppre

[O] Table caption in Latex export with :float nil

[Vikas Rawal]

I need to insert a table in an mdframed box, for which I need to turn off 
:float. The following, however, does not give me the caption:

#+name: milk-consumption-india
#+attr_latex: :float nil :environment tabular :caption 
\caption{\label{milk-consumption-india}Average consumption of milk, India, 
kilograms per capita per annum}
| Year| Rural | Urban |  All |
|-+---+---+--|
| 1983|  38.7 |  55.6 | 44.7 |
| 1993–1994   |  50.3 |  66.4 | 54.3 |
| 2004–2005   |  50.2 |  69.3 |   55 |
| 2009–2010   |  51.7 |  71.6 | 57.1 |
| <4colc>Source: citet:anjani2014 |   |   |  |


I have also tried (along with #+latex_header: \usepackage{caption})

#+name: milk-consumption-india
#+attr_latex: :float nil :environment tabular :caption 
\captionof{table}{\label{milk-consumption-india}Average consumption of milk, 
India, kilograms per capita per annum}
| Year| Rural | Urban |  All |
|-+---+---+--|
| 1983|  38.7 |  55.6 | 44.7 |
| 1993–1994   |  50.3 |  66.4 | 54.3 |
| 2004–2005   |  50.2 |  69.3 |   55 |
| 2009–2010   |  51.7 |  71.6 | 57.1 |
| <4colc>Source: citet:anjani2014 |   |   |  |

Vikas

Re: [O] Citation syntax: a revised proposal

[Aaron Ecay]

Hi Rasmus,

Thanks for your comments.  Some replies:

2015ko martxoak 10an, Rasmus-ek idatzi zuen:
>> These are then slurped by org, and used to fill in printf-style
>> templates.  Some people mentioned using citations as generated by
>> citeproc-java directly.  However, I don’t believe this is reliable since
>> (as also mentioned), it is difficult to control whether a certain style
>> uses parentheses around a citation or not, whether the citation is
>> capitalized*, the insertion of prefixes/suffixes within the parentheses,
>> etc.
>
> If so, is there *any* advantage is using a processors over say
> bibtex.el/reftex-cite.el/org-bibtex-parser.el?  We'd get a couple of more
> backends, right?  But this step can presumably be handled by other tools
> as necessary.
>
> If we have to do processing to the extend you describe (or I imagine that
> you describe), I'm not sure there's a point in relying on a external tool,
> which we cannot easily extend as opposed to fixing bugs we might encounter
> in reftex-cite or "forking"/reimplementing functions we need from
> there.

I have made citeproc-java give output like:

Smith2014
Doe1999
Smith et al.2005

I parse that into lists of (author, year) pairs by splitting on the
.  Then I expose a template to elisp: “%p%a (%y%s)” (for prefix,
author, year, and suffix).  This template could be changed however it is
desired by a user: using square brackets instead of round parens, for
example.  I think people will likely want to customize things like this,
and it seems difficult to get such flexibility from CSL.

So far, this has proved much easier than trying to implement all the
“proper” citation functionality in elisp.

CSL also gives the bibliography basically for free, including support
for zillions of highly specific formats.  (We do have to convert it from
HTML, but it is highly structured, in the sense that only a few tags and
styles can occur.  So the conversion can basically just handle those
cases one-by-one.)

>
>> So I think the only solution is to implement the formatting of the
>> in-text portion of citations ourselves, and use citeproc-java only to
>> extract authors and years.
>
> See above.  I then don't see the point.

It’s only the template for author-year in-text citations that I have
implemented in elisp.  CSL still gives us name parsing, disambiguation,
and bibliography formatting, which are each very complex.

> What I gather is that a big selling point of csl is the plentifulness of
> styles.  But you say we anyway need curated CSL styles to make it
> work.

I need just one such style, for our extraction of author + year for
in-text citations.  CSL styles are still used off-the-shelf for the
bibliography.

>> 2. Is it possible to support for implement importing citations from
>> jabref through the “lookup types” facility in my code?
>
> This is major.  I don't want to Jabref to manage citation and I would
> rather not give it write access to my citation library as it has encoding
> issues.

It would be one among many options: bibtex, org-bibtex, jabref, ...  You
would be free to pick the one(s) that hold your reference database, and
not bother with the others.

I hope that’s helpful,

--
Aaron Ecay

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Hello Aaron,

Aaron Ecay  writes:

>> If the goal is to have the latest and greatest version of Org available via
>> ELPA (for all the reasons some people use ELPA instead of git), there
>> are two obvious options:
>>
>> 1. Org could have a stable release every month or so.
>>
>> 2. The Org server could be configured to automatically package the
>> master version of Org every day, as the maint version is now.
>>
>> Option 1 is widely regarded as the best choice.  However, it requires a
>> lot of actual, repeated human effort.  As Debian repeatedly
>> demonstrates, this is very hard to do, even once.  If option 1 could be
>> done, it would already be done.
>>
>> Option 2 would be a one-time (mostly) human effort, and the daily work
>> would be automated.
>
> But what would not be automated is the actual human effort that goes into
> making a release: writing NEWS and documentation for new features, testing
> for regressions, generating the emacs Changelog files, merging changes
> from emacs trunk back into to org code base, merging org code into emacs
> trunk, ...  Someone still has to do all those things eventually.  Or not,
> and the quality of org as a software product suffers.

Refusing to make the git master version available through ELPA doesn't
help any of those things get done.  It simply denies the latest Org to
those unable or afraid of using git.

Of the things in your list, I think only the NEWS and Changelog are
absent from the master branch in git.  Lots of us happily use Org master
from git without them every day.  Do they really need to be done at
all?

If Emacs 25 is taking Org out of core, does the code still have to be
merged into the trunk?

If the manpower does not exist to support both a maint and a master
branch, maybe they should be merged.  Could that be done?

Still just trying to make it easier to spread the gospel of Org,
Terry
-- 
T.F. Torrey

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

Achim Gratz  writes:

> Richard Y. Kim writes:
>> # server.mk has the elpaplus makefile target
>> echo " include mk/server.mk" >> Makefile
> […]
>> # Undo the change made above
>> git checkout Makefile
>
> You know, local.mk was introduced specifically so you wouldn't have to
> do anything like that.

I did know that.  I remember the massive overhaul of the makefile
system (which, IIRC, you masterminded).

Unfortunately, I am not a makefile guru, so merely knowing that is not
enough.

I wish I had fewer dirty hacks in my life, but I'd rather get something
done with a dirty hack than not get it done at all.

All the best,
Terry
-- 
T.F. Torrey

Re: [O] What is quote-section? [eom]

[Marcin Borkowski]

On 2015-03-10, at 21:50, Rasmus  wrote:

> A remedy from the past cf. org-news.

Thanks!

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

[O] [PATCH} Re: Bug: problem when exporting a org-mode file with a lots of code blocks

[Charles C. Berry]

The patch causes an informative error message to be reported for src 
blocks like this (no language):


#+begin_src
(+ 1 2)
#_end_src

when exporting instead of failing with a cryptic error message.

Arguably, it would be better to skip the malformed src block as 
`org-babel-map-src-blocks' does or (as per John's message) 
org-babel-tangle does.


WDYT?

Chuck


On Tue, 10 Mar 2015, Charles Berry wrote:


XIE Yuheng  gmail.com> writes:




Bug: org-babel-parse-src-block-match reporting "Wrong type argument:
stringp, nil" when exporting a org-mode file with a lots of code blocks
[8.3beta (release_8.3beta-895-g375c83  
/usr/share/emacs/site-lisp/org/)]

the following is *Messages* buffer
   https://www.refheap.com/98243
the following is the org-mode file with a lot of code blocks
   https://github.com/the-little-language-designer/cicada-nymph/blob/

master/cicada-nymph.org


Look at the *Messages*  buffer and you will see a list of src blocks that were
processed without error.

The src block *after* the last block in the list (before the error message)
caused the error.

`org-babel-parse-src-block-match' expects a language for a src block.

Specify a language for every src block and it will export.

HTH,

Chuck



From f9859c09c5ad4790ef94d87477e7dfb97f264880 Mon Sep 17 00:00:00 2001
From: Charles Berry 
Date: Tue, 10 Mar 2015 14:09:52 -0700
Subject: [PATCH] ob-exp.el: org-babel-exp-process-buffer reports src block w/o
 language

* lisp/ob-exp.el (org-babel-exp-process-buffer): Issue an error when a
  src block with neither language nor headers is processed.

Throw an error with an informative message when trying to export buffer
containing `#+src_block\n'.

Reported-by: XIE Yuheng 

---
 lisp/ob-exp.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 4c53a55..d17e49f 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -268,7 +268,11 @@ may make them unreachable."
   ;; the block should be left as-is while an empty
   ;; string should remove the block.
   (let ((replacement
- (progn (goto-char match-start)
+ (progn (when (null (car headers))
+  (error
+   "No src block language or headers at line 
%S"
+   (line-number-at-pos)))
+(goto-char match-start)
 (org-babel-exp-src-block headers
 (cond ((not replacement) (goto-char end))
   ((equal replacement "")
-- 
1.9.3 (Apple Git-50)

Re: [O] What is quote-section? [eom]

[Rasmus]

A remedy from the past cf. org-news.

-- 
The second rule of Fight Club is: You do not talk about Fight Club

Re: [O] What is quote-section? [eom]

[Marc Ihm]

Am 10.03.2015 21:04, schrieb Marcin Borkowski:



Hi,

my emacs-installation does not know this as a function or a variable.

Does your emacs respond on `C-h f q u o t e - s e c t i o n' ?

(sorry, if I misunderstood your question)


best regards,
Marc

Re: [O] Bleeding edge in elpa

[T.F. Torrey]

emac...@gmail.com (Richard Y. Kim) writes:

> tftor...@tftorrey.com (T.F. Torrey) writes:
>
>> I wonder how much effort it would take to copy onto my own machine the
>> scripts on the server that package the git maint version into an ELPA
>> version, and modify them to package master instead.  Probably not much.
>
> The shell script below is what I use to create my own org-plus-contrib
> ELPA package.
>
> Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc.,
> I've been creating my own packages over the past year or so.  This way I
> know exactly which packages are installed in not only my emacs, but my
> colleagues who use my packages.  So far this has worked out great for
> me.

Looks excellent.  Thank you!

All the best,
Terry
-- 
T.F. Torrey

Re: [O] Possible bug

[Nicolas Goaziou]

Hello,

Subhan Michael Tindall  writes:

> I'm not sure if this counts as a bug or not:
>
> If I run a custom agenda (eg. "R") with sticky agendas, it displays in an 
> buffer with the name
> *Org Agenda (R)*
> If this buffer is then renamed to e.g.
> (rename-buffer "*R-Agenda*")

Why would you need that?

> *R-Agenda*
> And is then refreshed by hitting r, the agenda is properly rebuilt BUT in a 
> new buffer named *Org Agenda(R)*, resulting in two differing agendas.
>
> Is this appropriate behavior? It seems that rebuilding the agenda
> should respect the current buffer name. I'm very new at programing for
> lisp, so I'm not sure I'm using the right functions here.

IIRC, sticky agenda relies on buffer names to know if agenda needs to be
updated. So, it is not a good idea to rename agenda buffers.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Nicolas Goaziou]

Matthew Gidden  writes:

> Updated patch attached

Applied. Thank you.


Regards,

Re: [O] How to get LATEX_HEADER items to appear *after* default packages?

[Nick Dokos]

Richard Stanton  writes:

> When I export an org file to LaTeX using the class rhs-article, defined as 
> follows:
>
>‘("rhs-article"  
>  "\\documentclass{article}
> \\usepackage[top=1in, bottom=1.in, left=1in, right=1in]{geometry}
>  [PACKAGES]
>  [EXTRA]" ;;header-string
>  ("\\section{%s}" . "\\section*{%s}")
>  ("\\subsection{%s}" . "\\subsection*a{%s}")
>  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
>  ("\\paragraph{%s}" . "\\paragraph*{%s}")
>  ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>
> I see that my headers defined using #+LATEX_HEADER appear in the resulting 
> LaTeX file before the default packages defined in 
> org-latex-default-packages-alist. How can I get the default packages to 
> appear BEFORE the LATEX_HEADER items? Or better yet, how can I control things 
> so that I can choose whether a LATEX_HEADER item appears before or after the 
> default packages in the LaTeX file?
>

See the doc for org-latex-classes, in particular
the section entitled "The header string".

Nick

[O] Problem with org-protocol for capture with Adobe Acrobat Reader

[Memory Imprint Studio]

Dear Org-Mode Community,

I have been using Emacs org-mode for about 3 months now, loving every bit
of it so far.   One of  the killer feartures is the capture from external
applications (e.g. Web Browsers).  After some struggling, I can
successfully capture from Firefox and Chrome, but I am still having trouble
with Adobe Acrobat Reader.  After adapting XDG-open, I can only capture the
PDF file link (not the selection though), with two Firefox Windows popping
up and an error message.  I have documented this in my blogs (
http://tech.memoryimprintstudio.com/?p=160).

Any help or suggestions are greatly appreciated.

Tony

Re: [O] babel output as LaTeX code: help please!

[Thomas S. Dye]

Aloha Eric,

Eric S Fraga  writes:

> On Tuesday, 10 Mar 2015 at 08:42, Thomas S. Dye wrote:
>
> [...]
>
>> Have you tried
>>
>> #+call: drawlayout[:stdin solution]() :results raw
>>
>> or,
>>
>> #+call: drawlayout[:stdin solution]() :results latex
>>
>> which should make the print "#+begin_latex" etc. lines of drawlayout 
>> redundant?
>
> Both work perfectly.  Many thanks!
>
> The documentation confused me.  I see now that the end header arguments
> are not to be enclosed in [] whereas the inside ones are.  The
> documentation shows this in the example but the syntax seems to imply
> that the []s are required -- but in hindsight I guess the []s mean
> optional in this case.  However, they are not optional for the inside
> arguments...
>
> Ummm, the documentation is definitely confusing but I'm not sure how to
> improve it other than by adding a sentence making this explicit?

Perhaps the confusion comes from the fact that the syntax for #+call
lines differs from inline evaluation?  Inline evaluation requires [] for
the end header argument, but [] aren't used for the end header argument
of #+call lines.

I agree that this difference isn't easy to spot among all the ([<>]).
Perhaps a sentence pointing out the difference would be useful?

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

Re: [O] Internal Links with Spaces

[Jacob Gerlach]

On Tue, Mar 10, 2015 at 12:12 PM, John Kitchin  wrote:
> As far as I know you have only two options to use refs to a headline in
> Latex export.
>
> 1) Use a CUSTOM_ID property on a heading and then use [[#your-custom-id]] as
> your link. You have to put relevant text in like: see section
> [[#your-custom-id]]. If you want readable custom-ids you should make
> them yourself, e.g. C-c C-x p CUSTOM_ID your-custom-id, or craft an
> elisp function that prompts you for the custom-id and sets it for you,
> maybe even copying it to the kill-ring so it is easy to insert later.
>
> 2) Put \label{some-name} in the heading (yes, it is not pretty), e.g.
>
> * Results \label{sec-results}
>
> and use \ref{some-name} where you want the link to export to (or, if you
> use org-ref you can use ref:some-name which will be a clickable link,
> and also label:sec-results which is also a functional link). You still
> have to put relevant text in, e.g. see section ref:some-label.

Thanks to John for the recommendations, but given these options, I'm
more attracted to solving the original problem with the % escaped
spaces.

I came up with the following wrapper function - it successfully
replaces the hex encoded spaces (elisp feedback welcome):

(defun jg/insert-link-unescape-spaces ()
  (interactive)
  (org-insert-link)
  (save-excursion
(let ((beg (point)))
  (org-previous-link)
  (let ((end (point)))
(replace-string "%20" " " nil beg end)

After finally getting this function to work, I discovered that I had
the same problem as when I used org-id: the link description causes
exported latex references to use the headline text instead of the
\label{}.
Any (of several) attempts to insert a link so that it has no
description is foiled. I think this is done by org-make-link-string,
which just re-uses the link text for the description when none is
given.

In any case, here's an ugly hack to manually remove the description.
This works for me, but I'd love to find a more elegant approach:

(defun jg/insert-link-unescape-spaces ()
  (interactive)
  (org-insert-link)
  (save-excursion
(let ((beg (point)))
  (org-previous-link)
  (let ((end (point)))
(replace-string "%20" " " nil beg end
  ;expose the link so that search can see brackets
  (delete-char -1)
  (let ((end (point))
(beg (search-backward "[")))
(delete-region beg end)
(insert "]")))

Alternatively, if someone has a latex export hack that forces links to
reference labels instead of headline text (even when the org link has
a description), I'd be interested in that. It seems like this would be
a common request for exporting scientific writing to latex (unless
those users prefer one of the approaches John suggested above).

Regards,
Jake

[O] How to get LATEX_HEADER items to appear *after* default packages?

[Richard Stanton]

When I export an org file to LaTeX using the class rhs-article, defined as 
follows:

 ‘("rhs-article"  
   "\\documentclass{article}
\\usepackage[top=1in, bottom=1.in, left=1in, right=1in]{geometry}
 [PACKAGES]
 [EXTRA]" ;;header-string
   ("\\section{%s}" . "\\section*{%s}")
   ("\\subsection{%s}" . "\\subsection*a{%s}")
   ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
   ("\\paragraph{%s}" . "\\paragraph*{%s}")
   ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))

I see that my headers defined using #+LATEX_HEADER appear in the resulting 
LaTeX file before the default packages defined in 
org-latex-default-packages-alist. How can I get the default packages to appear 
BEFORE the LATEX_HEADER items? Or better yet, how can I control things so that 
I can choose whether a LATEX_HEADER item appears before or after the default 
packages in the LaTeX file?

Thanks for any suggestions.

Richard Stanton

Re: [O] babel output as LaTeX code: help please!

[Eric S Fraga]

On Tuesday, 10 Mar 2015 at 08:42, Thomas S. Dye wrote:

[...]

> Have you tried
>
> #+call: drawlayout[:stdin solution]() :results raw
>
> or,
>
> #+call: drawlayout[:stdin solution]() :results latex
>
> which should make the print "#+begin_latex" etc. lines of drawlayout 
> redundant?

Both work perfectly.  Many thanks!

The documentation confused me.  I see now that the end header arguments
are not to be enclosed in [] whereas the inside ones are.  The
documentation shows this in the example but the syntax seems to imply
that the []s are required -- but in hindsight I guess the []s mean
optional in this case.  However, they are not optional for the inside
arguments...

Ummm, the documentation is definitely confusing but I'm not sure how to
improve it other than by adding a sentence making this explicit?

Thanks again,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] babel output as LaTeX code: help please!

[Thomas S. Dye]

Hi Eric,

Eric S Fraga  writes:

> Hi,
>
> I am using babel with awk to generate some LaTeX code that I would like
> exported and interpreted as LaTeX.  I have the following which works if
> I were to use the src block directly but I wish to /call/ the src block
> with different tables:
>
> #+begin_src org
>   ,* layout
>   ,#+caption: Position of each circle
>   ,#+tblname: solution
>   |   | \(R_i\) |   \(r_i\) | \(\theta_i\) |  \(x\) |  \(y\) |
>   |---+-+---+--++|
>   | 1 |   6 | 19.834868 | 5.358859 |  11.95 | -15.83 |
>   | 2 |   7 | 21.443075 | 0.101102 |  21.33 |   2.16 |
>   | 3 |   8 | 19.005610 | 1.547045 |   0.45 |  19.00 |
>   | 4 |   9 | 20.688749 | 3.604317 | -18.51 |  -9.24 |
>   | 5 |  11 |  0.046762 | 3.863237 |  -0.04 |  -0.03 |
>   ,#+TBLFM: $5=$3*cos($4);R%.2f::$6=$3*sin($4);R%.2f
>
>   ,#+call: drawlayout[:stdin solution]()
>
>   ,#+name: drawlayout
>   ,#+header: :results raw
>   ,#+begin_src awk
> BEGIN {
> print "#+begin_latex"
> print "\\begin{tikzpicture}[scale=0.1]"
> print "\\draw"
> }
> /^[0-9]/ {
> printf("(%f,%f) circle (%f) node {%d}\n", $5, $6, $2, $1);
> }
> END {
> print ";"
> print "\\end{tikzpicture}"
> print "#+end_latex"
> }
>   ,#+end_src
> #+end_src
>
> I cannot figure out the magic incantation of [inside header arguments]
> and [end header arguments] that will export the output of the awk block
> when called as raw LaTeX code.
>
> If I put ":results raw" and ":exports results" on the src block,
> exporting that block works just fine.  The call however is wrapped in an
> EXAMPLE block which does me no good!
>
> Any suggestions welcome!

Have you tried

#+call: drawlayout[:stdin solution]() :results raw

or,

#+call: drawlayout[:stdin solution]() :results latex

which should make the print "#+begin_latex" etc. lines of drawlayout redundant?

All the best,
Tom

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

[O] babel output as LaTeX code: help please!

[Eric S Fraga]

Hi,

I am using babel with awk to generate some LaTeX code that I would like
exported and interpreted as LaTeX.  I have the following which works if
I were to use the src block directly but I wish to /call/ the src block
with different tables:

#+begin_src org
  ,* layout
  ,#+caption: Position of each circle
  ,#+tblname: solution
  |   | \(R_i\) |   \(r_i\) | \(\theta_i\) |  \(x\) |  \(y\) |
  |---+-+---+--++|
  | 1 |   6 | 19.834868 | 5.358859 |  11.95 | -15.83 |
  | 2 |   7 | 21.443075 | 0.101102 |  21.33 |   2.16 |
  | 3 |   8 | 19.005610 | 1.547045 |   0.45 |  19.00 |
  | 4 |   9 | 20.688749 | 3.604317 | -18.51 |  -9.24 |
  | 5 |  11 |  0.046762 | 3.863237 |  -0.04 |  -0.03 |
  ,#+TBLFM: $5=$3*cos($4);R%.2f::$6=$3*sin($4);R%.2f

  ,#+call: drawlayout[:stdin solution]()

  ,#+name: drawlayout
  ,#+header: :results raw
  ,#+begin_src awk
BEGIN {
print "#+begin_latex"
print "\\begin{tikzpicture}[scale=0.1]"
print "\\draw"
}
/^[0-9]/ {
printf("(%f,%f) circle (%f) node {%d}\n", $5, $6, $2, $1);
}
END {
print ";"
print "\\end{tikzpicture}"
print "#+end_latex"
}
  ,#+end_src
#+end_src

I cannot figure out the magic incantation of [inside header arguments]
and [end header arguments] that will export the output of the awk block
when called as raw LaTeX code.

If I put ":results raw" and ":exports results" on the src block,
exporting that block works just fine.  The call however is wrapped in an
EXAMPLE block which does me no good!

Any suggestions welcome!

Thanks,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] Bug: problem when exporting a org-mode file with a lots of code blocks

[Charles Berry]

XIE Yuheng  gmail.com> writes:

> 
> 
> Bug: org-babel-parse-src-block-match reporting "Wrong type argument:
> stringp, nil" when exporting a org-mode file with a lots of code blocks
> [8.3beta (release_8.3beta-895-g375c83
> /usr/share/emacs/site-lisp/org/)]
> 
> the following is *Messages* buffer
>https://www.refheap.com/98243
> the following is the org-mode file with a lot of code blocks
>https://github.com/the-little-language-designer/cicada-nymph/blob/
master/cicada-nymph.org


Look at the *Messages*  buffer and you will see a list of src blocks that were 
processed without error. 

The src block *after* the last block in the list (before the error message) 
caused the error.

`org-babel-parse-src-block-match' expects a language for a src block.

Specify a language for every src block and it will export.

HTH,

Chuck

Re: [O] Bleeding edge in elpa

[Achim Gratz]

Steinar Bang writes:
> Isn't this what's MELPA is for?
>  http://www.emacswiki.org/emacs/MELPA

MELPA is unable to provide a correctly installable package for Org since
they just pull down the tree and don't do the necessary build steps.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [O] Bug: problem when exporting a org-mode file with a lots of code blocks

[John Kitchin]

I could not reproduce this on 8.2.10. I tangled 106 blocks out with no
errors.

XIE Yuheng writes:

> Bug: org-babel-parse-src-block-match reporting "Wrong type argument:
> stringp, nil" when exporting a org-mode file with a lots of code blocks
> [8.3beta (release_8.3beta-895-g375c83 @ /usr/share/emacs/site-lisp/org/)]
>
>
>
> the following is *Messages* buffer
>https://www.refheap.com/98243
> the following is the org-mode file with a lot of code blocks
>
> https://github.com/the-little-language-designer/cicada-nymph/blob/master/cicada-nymph.org
> the following is an the fasm-mode I am using
>
> https://github.com/the-little-language-designer/fasm-mode/blob/master/fasm-mode.el
>
>
> Emacs  : GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.7)
>  of 2015-01-18 on bisson
> Package: Org-mode version 8.3beta (release_8.3beta-895-g375c83 @ 
> /usr/share/emacs/site-lisp/org/)
>
>
>
> current state:
> ==
> (setq
>  org-tab-first-hook '(org-hide-block-toggle-maybe 
> org-babel-hide-result-toggle-maybe org-babel-header-arg-expand)
>  org-speed-command-hook '(org-speed-command-default-hook 
> org-babel-speed-command-hook)
>  org-occur-hook '(org-first-headline-recenter)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-html-format-drawer-function '(lambda (name contents) contents)
>  org-src-window-setup 'current-window
>  org-latex-format-inlinetask-function 
> 'org-latex-format-inlinetask-default-function
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
>  org-babel-no-eval-on-ctrl-c-ctrl-c t
>  org-latex-format-headline-function 
> 'org-latex-format-headline-default-function
>  org-after-todo-state-change-hook '(org-clock-out-if-current)
>  org-latex-format-drawer-function '(lambda (name contents) contents)
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer 
> org-src-mode-configure-edit-buffer
>  (lambda nil (local-set-key (kbd "C-s C-s") (quote 
> org-edit-src-exit
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-mode-hook '((lambda nil (local-set-key (kbd "C-,") (quote 
> ska-jump-to-register))) t current-window 0 nil
>  #[nil "\300\301\302\303\304$\207" [org-add-hook 
> change-major-mode-hook org-show-block-all append local] 5]
>  #[nil "\300\301\302\303\304$\207" [org-add-hook 
> change-major-mode-hook org-babel-show-result-all append local] 5]
>  org-babel-result-hide-spec org-babel-hide-all-hashes)
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-ascii-format-drawer-function '(lambda (name contents width) contents)
>  org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point 
> org-babel-execute-safely-maybe)
>  org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
> org-cycle-hide-inline-tasks org-cycle-show-empty-lines
>   org-optimize-window-after-visibility-change)
>  org-todo-keywords '((sequence "><" "|" "><><" "|" "><><><") (sequence 
> "todo") (sequence "待") (sequence "note" "|" "test")
>  (sequence "記" "|" "測") (sequence "记" "|" "测"))
>  org-reveal-hlevel 2
>  org-babel-tangle-lang-exts '(("lisp" . "lisp") ("emacs-lisp" . "el") 
> ("elisp" . "el"))
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-src-ask-before-returning-to-edit-buffer nil
>  org-edit-src-content-indentation 0
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-html-format-headline-function 'org-html-format-headline-default-function
>  org-structure-template-alist '(("sf" "#+end_src\n?\n#+begin_src" " lang=\"?\">\n\n")
> ("s" "#+begin_src\n?\n#+end_src" " lang=\"?\">\n\n")
> ("picturef" "#+end_src\n?\n#+begin_src 
> picture" "\n\n")
> ("picture" "#+begin_src 
> picture\n?\n#+end_src" "\n\n")
> ("yamlf" "#+end_src\n?\n#+begin_src yaml" 
> "\n\n")
> ("yaml" "#+begin_src yaml\n?\n#+end_src" 
> "\n\n")
> ("bnff" "#+end_src\n?\n#+begin_src bnf" " lang=\"?\">\n\n")
> ("bnf" "#+begin_src bnf\n?\n#+end_src" " lang=\"?\">\n\n")
> ("coqf" "#+end_src\n?\n#+begin_src coq" " lang=\"?\">\n\n")
> ("coq" "#+begin_src coq\n?\n#+end_src" " lang=\"?\">\n\n")
> ("ljf" "#+end_src\n?\n#+begin_src lojban" 
> "\n\n")
> ("lj" "#+begin_src lojban\n?\n#+end_src" 
> "\n\n")
> ("ssf" "#+end_src\n?\n#+begin_src scheme" 
> "\n\n")
> ("ss" "#+begin_src scheme\n?\n#+end_src" 
> "\n\n")
> ("lispf" "#+end_src\n?\n#+begin_src lisp" 
> "\n\n")
> ("lisp" "#+beg

Re: [O] Citation syntax: a revised proposal

[Richard Lawrence]

Hi Aaron and all,

Aaron Ecay  writes:

> I’ve pushed an update to my branch.  The major change is to use
> citeproc-java for the generation of the bibliography and the parsing of
> names.

That is awesome!  Thank you for your work.

> The former is straightforward.  For the latter, I have created a CSL
> file which outputs author-year citations in an easy-to-parse format.
> These are then slurped by org, and used to fill in printf-style
> templates.  Some people mentioned using citations as generated by
> citeproc-java directly.  However, I don’t believe this is reliable
> since (as also mentioned), it is difficult to control whether a
> certain style uses parentheses around a citation or not, whether the
> citation is capitalized*, the insertion of prefixes/suffixes within
> the parentheses, etc.  So I think the only solution is to implement
> the formatting of the in-text portion of citations ourselves, and use
> citeproc-java only to extract authors and years.

I have actually been working on the same problem, using citeproc-hs as
the CSL processor instead of citeproc-java.  I took a (very) brief look
at your code; it seems like you are only communicating with
citeproc-java via command line arguments and stdout.  Is that right?

My approach to the problems you mention has been the following:
  1) Generate JSON from citation objects on the Org side.
  2) Pass that JSON to the processor via stdin.  
  3) Pass the output format, the CSL file, and the bibliography database
 to the processor via command line arguments.
  4) Return, to stdout, the formatted citations and the bibliography.
 These are formatted such that there is one citation or entry per line, 
 and a recognizable separator separates the citations from the
 bibliography. 

This allows passing formatting options for individual citations via the
JSON object for that citation, so it allows citeproc-hs to do more of
the work of formatting citations.

(See http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#citation-data-object
for documentation of the citation data JSON format.)

I don't know whether this will ultimately be a good design, but the way
I am picturing it right now is that exporting citations will work sort
of like footnotes: the exporter will gather them all together as they
are encountered, then generate the JSON and run a single call to the CSL
processor at the end of the export process.  It can then replace the
citations in the document with the result from the CSL processor, and
insert the bibliography at the end of the document.

(The code is not very pretty yet, but it does generate citations and
bibliographies in both plain text and HTML, and it would be
straightforward to extend it to other output formats.  I can post it
somewhere if anyone is interested in taking a look.)

> Some people have talked about supporting other CSL processors.  I don’t
> see much utility in that, since CSL is a standard that all processors
> should implement faithfully.  

Indeed!  Though as you have observed, `should' and `already does' come
apart.  I doubt there are any implementations that are perfectly
complete.  So it may be worth thinking about how Org can talk to CSL
processors in a processor-independent way.  That way, different users
can use different CSL processors if one works better for their
particular document or environment.

I think the generate-and-pass-JSON approach is promising for that
reason.  That is what citeproc-js accepts as input (so maybe that is
what citeproc-java is doing internally?), and my code aims to allow
citeproc-hs to interpret the same JSON format as citeproc-js.  I don't
know Ruby, but I think it would be easy to make citeproc-ruby accept the
same JSON format.  Do you have a sense of how easy it would be to coax
citeproc-java into accepting JSON on stdin?  If it could be done, I
think that would give us a common format for talking to the
best-developed CSL implementations in a processor-independent way.

Best,
Richard

[O] Possible bug

[Subhan Michael Tindall]

I'm not sure if this counts as a bug or not:

If I run a custom agenda (eg. "R") with sticky agendas, it displays in an 
buffer with the name
*Org Agenda (R)*
If this buffer is then renamed to e.g.
(rename-buffer "*R-Agenda*")
*R-Agenda*
And is then refreshed by hitting r, the agenda is properly rebuilt BUT in a new 
buffer named *Org Agenda(R)*, resulting in two differing agendas.

Is this appropriate behavior? It seems that rebuilding the agenda should 
respect the current buffer name. I'm very new at programing for lisp, so I'm 
not sure I'm using the right functions here.

I've poked around a bit in the code, but my elisp-fu is quite weak. I couldn't 
find an easy way to pass a buffer name in to org-agenda to be used, nor was it 
entirely clear to me how to modify org-agenda to grab & respect the buffer name 
when rebuilding a 'sticky' one.





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] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Richard Lawrence]

Hi Rasmus,

Thanks, your post was very informative.

Rasmus  writes:
> ...
>> Can you turn off the automatic addition of commas in BibLaTeX by setting
>> something in the preamble?
>
> Preamble or using \AtNextCite
>
>> If so, would that be the right solution here?  It might be easier to
>> remove punctuation on the LaTeX side than to get other backends to
>> duplicate LaTeX's implicit punctuating behavior.
>
> Perhaps.  Either looks like the famous can of worms.  I guess we should
> promote the option above in the manual and that's it.

I agree.  Let's make sure to mention this in documentation, but I think
a general solution is too hard right now.

Best,
Richard

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Richard Lawrence]

Eric S Fraga  writes:

> On Tuesday, 10 Mar 2015 at 09:50, Rasmus wrote:
>> Nicolas Goaziou  writes:
>>> Since this one is not much more intrusive than the previous one, we
>>> could as well drop @key in favor of @{key}.
>>
>> It seems like a moderately dear price to pay for everyone with "normal"
>> citation keys...  It's better than @key-with-',?.'{}.
>
> I agree.  I would rather type @key >90% of the time instead of
> @{key}.  For me, the alternative is more than a moderately high price to
> pay!

I too agree.  If we only allow one syntax, I much prefer to stick with
the original, and deal with the punctuation restriction elsewhere.

As far as I can tell, the only actual example we've seen of a key that
ends in punctuation is the one Vaidheeswaran sent, and that still seems
like an edge case to me: it should be corrected by adding data to the
reference database, not accommodated by Org's key syntax.

I think Tom's worry that we might see more of that kind of thing in the
future is fair, and deserves more thought.  I suggest we stick with the
original syntax for now, and revisit the issue in the future if it
becomes clear that there are lots of non-conforming keys `in the wild'.
In the meantime, tools that automatically insert keys from citation
managers can warn the user if they don't conform to the syntax.

Best,
Richard

Re: [O] Bleeding edge in elpa

[Grant Rettke]

`package-pinned-packages' seems to allow for user choice here. It is
still easy to muck up one's installation, but that is between the user
and package.el, not any particular package, I believe.

On Tue, Mar 10, 2015 at 6:01 AM, Alexis  wrote:
>
> On 2015-03-10T06:21:10+1100, T.F. Torrey  said:
>
> TFT> The biggest obstacle I to this that I see is that developers tend TFT>
> to hate the package manager and love git.
>
> This developer appreciates both, and thus particularly appreciates MELPA as
> well. :-)
>
>
> Alexis.
>



-- 
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: [O] Positioning of images - export to LaTeX

[Rainer M Krug]

John Hendy  writes:

> On Tue, Mar 10, 2015 at 9:13 AM, Rainer M Krug  wrote:
>> Hi
>>
>> I am struggling with float positioning. I would like to have a float at
>> the bottom of a page. Consider the following code:
>>
>> --8<---cut here---start->8---
>> * Some text
>> #+NAME: test
>> #+begin_src R :exports results :file-ext pdf :results graphics :width 8 
>> :height 3
>> plot(runif(100))
>> #+end_src
>>
>> #+RESULTS: test
>> [[file:test.pdf]]
>> --8<---cut here---end--->8---
>>
>> which produces a pdf with the float directly after the heading. Now I
>> would like to have the float at the bottom of the page.
>>
>> I know about the float placement option, but how can I use them from
>> org? I have seem
>> http://orgmode.org/manual/LaTeX-specific-attributes.html but where do I
>> c=have to put the
>>
>> ,
>> | #+ATTR_LATEX: :placement {b}
>> `
>>
>> so that the float is at the bottom of the page?
>
> Latex attributes have to go above the =#+results: name= line so that
> babel doesn't get confused. If you put it in between the name and file
> link, re-running the block will generate a new one, as babel won't
> recognize it. This seems to work for me, though from a previous email
> I took a cue that I believe you need to also specify it as a float.[1]
> Someone else can correct if that's wrong!

You are spot on. I was missing the =:float t= part.

Now it works.

Thanks a lot,

Rainer


>
> #+begin_src org
>
> #+attr_latex: :float t :placement [b]
> #+RESULTS: test
> [[file:test.pdf]]
>
> #+end_src
>
> I get this as a result:
>
> #+begin_src latex
>
> \section{Some text}
> \label{sec-1}
> \begin{figure}[b]
> \centering
> \includegraphics[width=.9\linewidth]{test2.pdf}
> \end{figure}
>
> #+end_src
>
> [1] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg82889.html
>
>
> This pushes it to the bottom for me!
>
>
>
> John
>
>>
>> Rainer
>>
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982
>
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Matthew Gidden]

Updated patch with updated commit message attached.

On Tue, Mar 10, 2015 at 9:45 AM, Matthew Gidden  wrote:

>
>
> On Tue, Mar 10, 2015 at 9:44 AM, Nicolas Goaziou 
> wrote:
>
>> Matthew Gidden  writes:
>>
>> > Another option would be to simply move BEAMER_HEADER to inject code
>> where I
>> > have implemented BEAMER_HEADER_EXTRA. That would provide the same
>> > functionality with a reasonable name. I still need to better format my
>> > commit message (I forgot to before submitting), so I can make any other
>> > updates that are deemed necessary.
>>
>> Fair enough. We can insert BEAMER_HEADER lines later and use
>> LATEX_HEADER for early lines.
>>
> I was writing a longer email confirming that I think this is the best way
> forward. I'll update the source and commit message and reply to this with a
> new patch. Let me know if I should make a new mail instead.
>
> Cheers,
> Matt
>
>>
>> Regards,
>>
>
>
>
> --
> Matthew Gidden
> Ph.D. Candidate, Nuclear Engineering
> The University of Wisconsin -- Madison
> Ph. 225.892.3192
>



-- 
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192
From dd0ac869afb9f13ce4d893bb34599864a9d43253 Mon Sep 17 00:00:00 2001
From: Matthew Gidden 
Date: Mon, 9 Mar 2015 16:25:15 -0500
Subject: [PATCH] org-beamer.el: Enable custom beamer input before
 \begin{document}

* lisp/ox-beamer.el (`beamer-header'): Move BEAMER_HEADER injection to
  final part of preamble (after themes, title, etc.). Allows for
  custom short titles, etc., with #+BEAMER_HEADER: \title[Short]{Long}.

Previously, TITLE was being injected after BEAMER_HEADER, so short
titles (and related) could not be added. BEAMER_HEADER now serves as a
final preamble injection point.

TINYCHANGE
---
 lisp/ox-beamer.el | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index e10d36c..359ccdc 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -239,7 +239,7 @@ Return overlay specification, as a string, or nil."
 (:beamer-font-theme "BEAMER_FONT_THEME" nil nil t)
 (:beamer-inner-theme "BEAMER_INNER_THEME" nil nil t)
 (:beamer-outer-theme "BEAMER_OUTER_THEME" nil nil t)
-(:beamer-header-extra "BEAMER_HEADER" nil nil newline)
+(:beamer-header "BEAMER_HEADER" nil nil newline)
 (:beamer-environments-extra nil nil org-beamer-environments-extra)
 (:beamer-frame-default-options nil nil org-beamer-frame-default-options)
 (:beamer-outline-frame-options nil nil org-beamer-outline-frame-options)
@@ -825,8 +825,7 @@ holding export options."
 	 (concat (org-element-normalize-string
 		  (plist-get info :latex-header))
 		 (org-element-normalize-string
-		  (plist-get info :latex-header-extra))
-		 (plist-get info :beamer-header-extra)
+		  (plist-get info :latex-header-extra))
 	  info)))
  ;; 3. Insert themes.
  (let ((format-theme
@@ -866,16 +865,20 @@ holding export options."
(format "\\date{%s}\n" (org-export-data date info)))
  ;; 7. Title
  (format "\\title{%s}\n" title)
- ;; 8. Hyperref options.
+ ;; 8. Beamer-header
+ (let ((beamer-header (plist-get info :beamer-header)))
+   (when beamer-header
+	 (format "%s\n" (plist-get info :beamer-header
+ ;; 9. Hyperref options.
  (when (plist-get info :latex-hyperref-p)
(format "\\hypersetup{\n  pdfkeywords={%s},\n  pdfsubject={%s},\n  pdfcreator={%s}}\n"
 	   (or (plist-get info :keywords) "")
 	   (or (plist-get info :description) "")
 	   (if (not (plist-get info :with-creator)) ""
 		 (plist-get info :creator
- ;; 9. Document start.
+ ;; 10. Document start.
  "\\begin{document}\n\n"
- ;; 10. Title command.
+ ;; 11. Title command.
  (org-element-normalize-string
   (cond ((not (plist-get info :with-title)) nil)
 	((string= "" title) nil)
@@ -884,7 +887,7 @@ holding export options."
 			   org-latex-title-command)
 	 (format org-latex-title-command title))
 	(t org-latex-title-command)))
- ;; 11. Table of contents.
+ ;; 12. Table of contents.
  (let ((depth (plist-get info :with-toc)))
(when depth
 	 (concat
@@ -896,16 +899,16 @@ holding export options."
 	(format "\\setcounter{tocdepth}{%d}\n" depth))
 	  "\\tableofcontents\n"
 	  "\\end{frame}\n\n")))
- ;; 12. Document's body.
+ ;; 13. Document's body.
  contents
- ;; 13. Creator.
+ ;; 14. Creator.
  (let ((creator-info (plist-get info :with-creator)))
(cond
 	((not creator-info) "")
 	((eq creator-info 'comment)
 	 (format "%% %s\n" (plist-get info :creator)))
 	(t (concat (plist-get info :creator) "\n"
- ;; 14. Document end.
+ ;; 15. Document end.
  "\\end{document}")))
 
 
-- 
1.9.1

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Matthew Gidden]

On Tue, Mar 10, 2015 at 9:44 AM, Nicolas Goaziou 
wrote:

> Matthew Gidden  writes:
>
> > Another option would be to simply move BEAMER_HEADER to inject code
> where I
> > have implemented BEAMER_HEADER_EXTRA. That would provide the same
> > functionality with a reasonable name. I still need to better format my
> > commit message (I forgot to before submitting), so I can make any other
> > updates that are deemed necessary.
>
> Fair enough. We can insert BEAMER_HEADER lines later and use
> LATEX_HEADER for early lines.
>
I was writing a longer email confirming that I think this is the best way
forward. I'll update the source and commit message and reply to this with a
new patch. Let me know if I should make a new mail instead.

Cheers,
Matt

>
> Regards,
>



-- 
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Matt Price]

On Tue, Mar 10, 2015 at 6:18 AM, Eric S Fraga  wrote:

> On Tuesday, 10 Mar 2015 at 09:50, Rasmus wrote:
> > Nicolas Goaziou  writes:
> >> Since this one is not much more intrusive than the previous one, we
> >> could as well drop @key in favor of @{key}.
> >
> > It seems like a moderately dear price to pay for everyone with "normal"
> > citation keys...  It's better than @key-with-',?.'{}.
>
> I agree.  I would rather type @key >90% of the time instead of
> @{key}.  For me, the alternative is more than a moderately high price to
> pay!
>
> If we don't want a proliferation of alternative syntax, maybe we need to
> impose the restriction already suggested of not allowing punctuation at
> the end of a key.  Solve the problem upstream... and not have the tail
> wag the dog!
>
> But, of course, don't let this tail (me) wag the dog (the rest of you)
> should the consensus be that the design is cleaner with @{key}.  I'll
> manage!  :)
>
> Thanks,
> eric
>

I also think a simpler key syntax will make htis much nmore usable.
Citations are in general somewhat distracting from the writing process;
every additional keystroke is gong to add to that distraction.  This is
true even if hand-added citations are likely to be the exception rather
than the norm.



>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
> release_8.3beta-843-ga5f1a3.dirty
>
>

Re: [O] Internal Links with Spaces

[Jacob Gerlach]

On Mon, Mar 9, 2015 at 7:28 PM, John Kitchin  wrote:
> I think you need to set
>
> (setq org-id-link-to-org-use-id 'create-if-interactive)

Indeed, this is a variation of what Leo suggested and customizing
org-id-link-to-org-use-id is almost working for me...

Unfortunately, I want the links to export to latex using latex
\ref{}'s and section labels. A link stored with a custom id has to
have a description to have a reasonably readable org buffer, but links
with descriptions are exported using the headline text instead of the
section number. Is there a workaround for this?

On Mon, Mar 9, 2015 at 4:50 PM, Jacob Gerlach  wrote:
> When exploring this, I found the function org-id-store-link. This
> seemed like what I wanted - it creates a custom ID if one doesn't
> exist, but it doesn't actually store a link (or at least, it wasn't
> available when I then ran org-insert-link). The docstring is pretty
> light, but it seems like this might be a bug. Is this the expected
> behavior?

After perusing the source code further, I think that my confusion
about org-id-store-link arose because this function isn't intended to
be called on it's own (it's called by org-store-link when appropriate
based on the value of org-id-link-to-org-use-id).

I've seen a double hyphen in function names to sometimes indicate
internal functions. Would this function be more appropriately named
org-id--store-link or am I misunderstanding the convention?



Regards,
Jake

Re: [O] Positioning of images - export to LaTeX

[Rasmus]

> I am struggling with float positioning. I would like to have a float at
> the bottom of a page.

Maybe something like this:

* Some text
#+LATEX_HEADER: \renewcommand{\topfraction}{1}
#+LATEX_HEADER: \renewcommand{\bottomfraction}{1}

#+NAME: test
#+begin_src R :exports results :file-ext pdf :results graphics :width 8 :height 
3
plot(runif(100))
#+end_src

#+ATTR_LATEX: :placement [b]
#+CAPTION: my fig
#+RESULTS: test
[[file:test.pdf]]


-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

[O] Positioning of images - export to LaTeX

[Rainer M Krug]

Hi

I am struggling with float positioning. I would like to have a float at
the bottom of a page. Consider the following code:

--8<---cut here---start->8---
* Some text
#+NAME: test
#+begin_src R :exports results :file-ext pdf :results graphics :width 8 :height 
3
plot(runif(100))
#+end_src

#+RESULTS: test
[[file:test.pdf]]
--8<---cut here---end--->8---

which produces a pdf with the float directly after the heading. Now I
would like to have the float at the bottom of the page.

I know about the float placement option, but how can I use them from
org? I have seem
http://orgmode.org/manual/LaTeX-specific-attributes.html but where do I
c=have to put the

,
| #+ATTR_LATEX: :placement {b}
`

so that the float is at the bottom of the page?

Rainer

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Positioning of images - export to LaTeX

[John Hendy]

On Tue, Mar 10, 2015 at 9:13 AM, Rainer M Krug  wrote:
> Hi
>
> I am struggling with float positioning. I would like to have a float at
> the bottom of a page. Consider the following code:
>
> --8<---cut here---start->8---
> * Some text
> #+NAME: test
> #+begin_src R :exports results :file-ext pdf :results graphics :width 8 
> :height 3
> plot(runif(100))
> #+end_src
>
> #+RESULTS: test
> [[file:test.pdf]]
> --8<---cut here---end--->8---
>
> which produces a pdf with the float directly after the heading. Now I
> would like to have the float at the bottom of the page.
>
> I know about the float placement option, but how can I use them from
> org? I have seem
> http://orgmode.org/manual/LaTeX-specific-attributes.html but where do I
> c=have to put the
>
> ,
> | #+ATTR_LATEX: :placement {b}
> `
>
> so that the float is at the bottom of the page?

Latex attributes have to go above the =#+results: name= line so that
babel doesn't get confused. If you put it in between the name and file
link, re-running the block will generate a new one, as babel won't
recognize it. This seems to work for me, though from a previous email
I took a cue that I believe you need to also specify it as a float.[1]
Someone else can correct if that's wrong!

#+begin_src org

#+attr_latex: :float t :placement [b]
#+RESULTS: test
[[file:test.pdf]]

#+end_src

I get this as a result:

#+begin_src latex

\section{Some text}
\label{sec-1}
\begin{figure}[b]
\centering
\includegraphics[width=.9\linewidth]{test2.pdf}
\end{figure}

#+end_src

[1] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg82889.html


This pushes it to the bottom for me!



John

>
> Rainer
>
> --
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982

Re: [O] Internal Links with Spaces

[John Kitchin]

I am not sure what the convention there is.

John

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


On Tue, Mar 10, 2015 at 10:05 AM, Jacob Gerlach 
wrote:

> On Mon, Mar 9, 2015 at 7:28 PM John Kitchin 
> wrote:
> >
> > I think you need to set
> >
> > (setq org-id-link-to-org-use-id 'create-if-interactive)
>
> Indeed, this is a variation of what Leo suggested and customizing
> org-id-link-to-org-use-id is working well for me.
>
> After perusing the source code further, I think that my confusion
> about org-id-store-link arose because this function isn't intended to
> be called on it's own (it's called by org-store-link when appropriate
> based on the value of org-id-link-to-org-use-id).
>
> I've seen a double hyphen in function names to sometimes indicate
> internal functions. Would this function be more appropriately named
> org-id--store-link or am I misunderstanding the convention?
>
> Regards,
> Jake
>

Re: [O] [PATCH] Adding a BEAMER_HEADER_EXTRA tag, allows short titles, etc.

[Nicolas Goaziou]

Matthew Gidden  writes:

> Another option would be to simply move BEAMER_HEADER to inject code where I
> have implemented BEAMER_HEADER_EXTRA. That would provide the same
> functionality with a reasonable name. I still need to better format my
> commit message (I forgot to before submitting), so I can make any other
> updates that are deemed necessary.

Fair enough. We can insert BEAMER_HEADER lines later and use
LATEX_HEADER for early lines.

Regards,

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Rainer M Krug]

Rainer M Krug  writes:

> John Kitchin  writes:
>
>> weird. I swear it worked in the little toy problem I made ;)
>>
>> I think this is a more robust function:
>>
>> #+BEGIN_SRC emacs-lisp
>> (defun update-results ()
>>   ;; get name of src block
>>   (let* ((name (org-element-property :name (org-element-at-point)))
>> (results (save-excursion
>>(goto-char (org-babel-find-named-result name))
>>(forward-line)
>>(buffer-substring
>>(point) (org-element-property :end 
>> (org-element-at-point)
>> (begin))
>> (save-excursion
>>   (goto-char (point-min))
>>   (while (setq begin (org-babel-find-named-result name (point)))
>> (goto-char begin)
>> (forward-line)
>> (setf (buffer-substring
>>(point)
>>(org-element-property :end (org-element-at-point)))
>>   results)
>> #+END_SRC
>>
>> I tested this one on two examples ;)
>
> And also on my example...
>
> Thanks John
>
> Works perfectly - added to my emacs.org.

Just realised that it produces an error if the code block has no name.

Cheers,

Rainer

>
> Any chance that you could put this into a patch so that it could go into org?
>
> Rainer
>
>>
>> Rainer M Krug writes:
>>
>>> Rainer M Krug  writes:
>>>
 John Kitchin  writes:

> I don't believe this is possible out of the box. The first RESULTS block
> from the beginning of the buffer will be updated, and not the others.
>
> You might be able to use a hook function to do this, something like:
>
> #+BEGIN_SRC emacs-lisp
> (defun update-results () (interactive)
>   ;; get name of src block
>   (let ((name (org-element-property :name (org-element-at-point)))
> (results))
> (when name
>   (org-element-map (org-element-parse-buffer) 'fixed-width
> (lambda (object)
>   (if results
>   ;; replace value in block
>   (setf
>(buffer-substring
> (org-element-property :begin  object)
> (org-element-property :end  object))
>results)
> ;; set results
> (setq results
>   (buffer-substring
>(org-element-property :begin  object)
>(org-element-property :end  object)
> #+END_SRC
> #+BEGIN_SRC emacs-lisp
> (add-hook 'org-babel-after-execute-hook 'update-results)
> #+END_SRC
>
> This worked on a small test example, but I did not test it
> thoroughly. your mileage might vary ;)

 This looks nice - I will try it out and see how it goes.
>>>
>>>
>>> I don't get it to work.
>>>
>>> I put the following into my emacs.org and evaluated it:
>>>
>>> --8<---cut here---start->8---
>>> (defun rmk/update-multiple-results-blocks () (interactive)
>>>;; get name of src block
>>>(let ((name (org-element-property :name (org-element-at-point)))
>>>  (results))
>>>  (when name
>>>(org-element-map (org-element-parse-buffer) 'fixed-width
>>>  (lambda (object)
>>>(if results
>>>;; replace value in block
>>>(setf
>>> (buffer-substring
>>>  (org-element-property :begin  object)
>>>  (org-element-property :end  object))
>>> results)
>>>  ;; set results
>>>  (setq results
>>>(buffer-substring
>>> (org-element-property :begin  object)
>>> (org-element-property :end  object)
>>>
>>> #+end_src
>>>
>>> #+RESULTS:
>>> : rmk/update-multiple-results-blocks
>>>
>>> Add this function to =org-babel=after-execute-hook=
>>> #+begin_src emacs-lisp
>>> (add-hook 'org-babel-after-execute-hook 'rmk/update-multiple-results-blocks)
>>> #+end_src
>>>
>>> #+RESULTS:
>>> | rmk/update-multiple-results-blocks |
>>> --8<---cut here---end--->8---
>>>
>>>
>>> I am using the following org file to test it:
>>>
>>> --8<---cut here---start->8---
>>> * The calculation
>>> #+NAME: testcode
>>> #+begin_src R :session test
>>> runif(10)
>>> #+end_src
>>>
>>> * summary of the results
>>> First time
>>> #+RESULTS: testcode
>>> |  0.471471928292885 |
>>> |  0.128247044514865 |
>>> |  0.398714824113995 |
>>> |  0.335577708436176 |
>>> | 0.0184990330599248 |
>>> |  0.952211205149069 |
>>> |  0.367342215497047 |
>>> |  0.581879974342883 |
>>> |  0.440492485417053 |
>>> | 0.0729096119757742 |
>>>
>>>
>>> #+RESULTS: testcode
>>> | 0.0095007149502635 |
>>> | 0.0898537992034107 |
>>> |  0.764667606214061 |
>>> | 0.0309854068327695 |
>>> |  0.510338442632928 |
>>> |  0.2209

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Rainer M Krug]

John Kitchin  writes:

> weird. I swear it worked in the little toy problem I made ;)
>
> I think this is a more robust function:
>
> #+BEGIN_SRC emacs-lisp
> (defun update-results ()
>   ;; get name of src block
>   (let* ((name (org-element-property :name (org-element-at-point)))
> (results (save-excursion
>(goto-char (org-babel-find-named-result name))
>(forward-line)
>(buffer-substring
>(point) (org-element-property :end 
> (org-element-at-point)
> (begin))
> (save-excursion
>   (goto-char (point-min))
>   (while (setq begin (org-babel-find-named-result name (point)))
> (goto-char begin)
> (forward-line)
> (setf (buffer-substring
>(point)
>(org-element-property :end (org-element-at-point)))
>   results)
> #+END_SRC
>
> I tested this one on two examples ;)

And also on my example...

Thanks John

Works perfectly - added to my emacs.org.

Any chance that you could put this into a patch so that it could go into org?

Rainer

>
> Rainer M Krug writes:
>
>> Rainer M Krug  writes:
>>
>>> John Kitchin  writes:
>>>
 I don't believe this is possible out of the box. The first RESULTS block
 from the beginning of the buffer will be updated, and not the others.

 You might be able to use a hook function to do this, something like:

 #+BEGIN_SRC emacs-lisp
 (defun update-results () (interactive)
   ;; get name of src block
   (let ((name (org-element-property :name (org-element-at-point)))
 (results))
 (when name
   (org-element-map (org-element-parse-buffer) 'fixed-width
 (lambda (object)
   (if results
   ;; replace value in block
   (setf
(buffer-substring
 (org-element-property :begin  object)
 (org-element-property :end  object))
results)
 ;; set results
 (setq results
   (buffer-substring
(org-element-property :begin  object)
(org-element-property :end  object)
 #+END_SRC
 #+BEGIN_SRC emacs-lisp
 (add-hook 'org-babel-after-execute-hook 'update-results)
 #+END_SRC

 This worked on a small test example, but I did not test it
 thoroughly. your mileage might vary ;)
>>>
>>> This looks nice - I will try it out and see how it goes.
>>
>>
>> I don't get it to work.
>>
>> I put the following into my emacs.org and evaluated it:
>>
>> --8<---cut here---start->8---
>> (defun rmk/update-multiple-results-blocks () (interactive)
>>;; get name of src block
>>(let ((name (org-element-property :name (org-element-at-point)))
>>  (results))
>>  (when name
>>(org-element-map (org-element-parse-buffer) 'fixed-width
>>  (lambda (object)
>>(if results
>>;; replace value in block
>>(setf
>> (buffer-substring
>>  (org-element-property :begin  object)
>>  (org-element-property :end  object))
>> results)
>>  ;; set results
>>  (setq results
>>(buffer-substring
>> (org-element-property :begin  object)
>> (org-element-property :end  object)
>>
>> #+end_src
>>
>> #+RESULTS:
>> : rmk/update-multiple-results-blocks
>>
>> Add this function to =org-babel=after-execute-hook=
>> #+begin_src emacs-lisp
>> (add-hook 'org-babel-after-execute-hook 'rmk/update-multiple-results-blocks)
>> #+end_src
>>
>> #+RESULTS:
>> | rmk/update-multiple-results-blocks |
>> --8<---cut here---end--->8---
>>
>>
>> I am using the following org file to test it:
>>
>> --8<---cut here---start->8---
>> * The calculation
>> #+NAME: testcode
>> #+begin_src R :session test
>> runif(10)
>> #+end_src
>>
>> * summary of the results
>> First time
>> #+RESULTS: testcode
>> |  0.471471928292885 |
>> |  0.128247044514865 |
>> |  0.398714824113995 |
>> |  0.335577708436176 |
>> | 0.0184990330599248 |
>> |  0.952211205149069 |
>> |  0.367342215497047 |
>> |  0.581879974342883 |
>> |  0.440492485417053 |
>> | 0.0729096119757742 |
>>
>>
>> #+RESULTS: testcode
>> | 0.0095007149502635 |
>> | 0.0898537992034107 |
>> |  0.764667606214061 |
>> | 0.0309854068327695 |
>> |  0.510338442632928 |
>> |  0.220906731439754 |
>> |  0.589271233882755 |
>> |  0.966699115466326 |
>> | 0.0183747289702296 |
>> |  0.734954049577937 |
>> --8<---cut here---end--->8---
>>
>> But only the first results block is updated. The function
>> =rmk/update-multiple

Re: [O] Bleeding edge in elpa

[Alexis]

On 2015-03-10T06:21:10+1100, T.F. Torrey  
said:


TFT> The biggest obstacle I to this that I see is that developers 
tend TFT> to hate the package manager and love git.


This developer appreciates both, and thus particularly appreciates 
MELPA as well. :-)



Alexis.

Re: [O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Nicolas Goaziou]

Eric Abrahamsen  writes:

> If we really want to get all the message-specific stuff refactored into
> orgstruct++ mode, I guess we could (in the `orgstruct++-mode' function)
> bind `normal-auto-fill-function' and `adaptive-fill-function' to new
> functions, which first check for message-mode specific stuff (and any
> other modes that need to be handled),then delegate to
> `org-auto-fill-function' and `org-adaptive-fill-function'.

Indeed. There's also `org-fill-paragraph' to purge from Message mode
stuff.

Ultimately, Orgstruct minor mode could be moved into its own library,
e.g., "org-struct.el".

> Actually, all `org-auto-fill-function' does is conditionally call
> `org-adaptive-fill-function', so maybe we could just have one new
> function, `orgstruct++-auto-fill-function', that does everything.

Probably, yes.

> How does that sound?

It sounds good.


Regards,

Re: [O] Bleeding edge in elpa

[Steinar Bang]

> Nikolai Weibull :

> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?

Isn't this what's MELPA is for?
 http://www.emacswiki.org/emacs/MELPA

Ie. GNU ELPA for the official releases and MELPA for git master HEAD.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Eric S Fraga]

On Tuesday, 10 Mar 2015 at 09:50, Rasmus wrote:
> Nicolas Goaziou  writes:
>> Since this one is not much more intrusive than the previous one, we
>> could as well drop @key in favor of @{key}.
>
> It seems like a moderately dear price to pay for everyone with "normal"
> citation keys...  It's better than @key-with-',?.'{}.

I agree.  I would rather type @key >90% of the time instead of
@{key}.  For me, the alternative is more than a moderately high price to
pay!

If we don't want a proliferation of alternative syntax, maybe we need to
impose the restriction already suggested of not allowing punctuation at
the end of a key.  Solve the problem upstream... and not have the tail
wag the dog!

But, of course, don't let this tail (me) wag the dog (the rest of you)
should the consensus be that the design is cleaner with @{key}.  I'll
manage!  :)

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty

Re: [O] Citation syntax: a revised proposal

[Rasmus]

Hi,

Aaron Ecay  writes:

> I’ve pushed an update to my branch.

Thank you Aaron!  I appreciate the work.  While the below may sound
bitter, it's not!

> These are then slurped by org, and used to fill in printf-style
> templates.  Some people mentioned using citations as generated by
> citeproc-java directly.  However, I don’t believe this is reliable since
> (as also mentioned), it is difficult to control whether a certain style
> uses parentheses around a citation or not, whether the citation is
> capitalized*, the insertion of prefixes/suffixes within the parentheses,
> etc.

If so, is there *any* advantage is using a processors over say
bibtex.el/reftex-cite.el/org-bibtex-parser.el?  We'd get a couple of more
backends, right?  But this step can presumably be handled by other tools
as necessary.

If we have to do processing to the extend you describe (or I imagine that
you describe), I'm not sure there's a point in relying on a external tool,
which we cannot easily extend as opposed to fixing bugs we might encounter
in reftex-cite or "forking"/reimplementing functions we need from there.

> So I think the only solution is to implement the formatting of the
> in-text portion of citations ourselves, and use citeproc-java only to
> extract authors and years.

See above.  I then don't see the point.

> Using citeproc gives us for free sophisticated disambiguation of authors
> that share a last name (by adding first initial) or works by the same
> author in the same year (by adding a letter suffix to the year).

That's a fair point, but I don't understand it.  I haven't looked at your
code!  I guess you'd have to generate the whole bibliography to get this
data?  It sounds messy...  Note, reftex.el + friends is probably equally
messy.  And I don't know if it offers any support for bibliographies.

What I gather is that a big selling point of csl is the plentifulness of
styles.  But you say we anyway need curated CSL styles to make it work.
But then, is there any advantage of it left?

A similar idea, explored on the list, is using Jabref as a processor.  I
don't know about the copyright status, though. 

> Some people have talked about supporting other CSL processors.  I don’t
> see much utility in that, since CSL is a standard that all processors
> should implement faithfully.

+1.

> 1. Is any important functionality lost by using citeproc-java as the CSL
>processor, rather than jabref?

I guess Jabref supports odt about of the box.  I don't know what the
sophistication of Jabref style language is viz-a-viz CSL.  I don't
understand if your work aims to support CSL or an "approved" subset of
CSL.

> 2. Is it possible to support for implement importing citations from
>jabref through the “lookup types” facility in my code?

This is major.  I don't want to Jabref to manage citation and I would
rather not give it write access to my citation library as it has encoding
issues.

> 3. How are citations formatted for export to ODT?  An example of the
>ODT/XML code for something like “as demonstrated by Smith (2015)”,
>where “Smith (2015)” has whatever fancy formatting a citation is
>expected to have in ODT, would be helpful.

It's a big mystery.  tex4ht/oolatex also manages.  Some sort of internal
database is generated.  I don't know how styling is managed.

—Rasmus

-- 
What will be next?

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Rainer M Krug]

Rainer M Krug  writes:

> John Kitchin  writes:
>
>> I don't believe this is possible out of the box. The first RESULTS block
>> from the beginning of the buffer will be updated, and not the others.
>>
>> You might be able to use a hook function to do this, something like:
>>
>> #+BEGIN_SRC emacs-lisp
>> (defun update-results () (interactive)
>>   ;; get name of src block
>>   (let ((name (org-element-property :name (org-element-at-point)))
>> (results))
>> (when name
>>   (org-element-map (org-element-parse-buffer) 'fixed-width
>> (lambda (object)
>>   (if results
>>   ;; replace value in block
>>   (setf
>>(buffer-substring
>> (org-element-property :begin  object)
>> (org-element-property :end  object))
>>results)
>> ;; set results
>> (setq results
>>   (buffer-substring
>>(org-element-property :begin  object)
>>(org-element-property :end  object)
>> #+END_SRC
>> #+BEGIN_SRC emacs-lisp
>> (add-hook 'org-babel-after-execute-hook 'update-results)
>> #+END_SRC
>>
>> This worked on a small test example, but I did not test it
>> thoroughly. your mileage might vary ;)
>
> This looks nice - I will try it out and see how it goes.


I don't get it to work.

I put the following into my emacs.org and evaluated it:

--8<---cut here---start->8---
(defun rmk/update-multiple-results-blocks () (interactive)
   ;; get name of src block
   (let ((name (org-element-property :name (org-element-at-point)))
 (results))
 (when name
   (org-element-map (org-element-parse-buffer) 'fixed-width
 (lambda (object)
   (if results
   ;; replace value in block
   (setf
(buffer-substring
 (org-element-property :begin  object)
 (org-element-property :end  object))
results)
 ;; set results
 (setq results
   (buffer-substring
(org-element-property :begin  object)
(org-element-property :end  object)

#+end_src

#+RESULTS:
: rmk/update-multiple-results-blocks

Add this function to =org-babel=after-execute-hook=
#+begin_src emacs-lisp 
(add-hook 'org-babel-after-execute-hook 'rmk/update-multiple-results-blocks)
#+end_src

#+RESULTS:
| rmk/update-multiple-results-blocks |
--8<---cut here---end--->8---


I am using the following org file to test it:

--8<---cut here---start->8---
* The calculation
#+NAME: testcode
#+begin_src R :session test
runif(10)
#+end_src

* summary of the results
First time
#+RESULTS: testcode
|  0.471471928292885 |
|  0.128247044514865 |
|  0.398714824113995 |
|  0.335577708436176 |
| 0.0184990330599248 |
|  0.952211205149069 |
|  0.367342215497047 |
|  0.581879974342883 |
|  0.440492485417053 |
| 0.0729096119757742 |


#+RESULTS: testcode
| 0.0095007149502635 |
| 0.0898537992034107 |
|  0.764667606214061 |
| 0.0309854068327695 |
|  0.510338442632928 |
|  0.220906731439754 |
|  0.589271233882755 |
|  0.966699115466326 |
| 0.0183747289702296 |
|  0.734954049577937 |
--8<---cut here---end--->8---

But only the first results block is updated. The function
=rmk/update-multiple-results-blocks= is executed.

I am using

,
| Org-mode version 8.3beta (release_8.3beta-884-g9ed426 @ 
/Users/rainerkrug/.emacs.d/org-mode/lisp/)
| GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 AppKit 
1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local
`

Any ideas what is going wrong?

Thanks,

Rainer


>
>
>>
>>
>> Rainer M Krug writes:
>>
>>> Hi
>>>
>>> Consider the following:
>>>
>>> --8<---cut here---start->8---
>>> * The calculation
>>> #+NAME: testcode :exports both
>>> #+begin_src R  :session test
>>> runif(10)
>>> #+end_src
>>>
>>>
>>> * summary of the results
>>> First time
>>> #+RESULTS: testcode :exports both
>>> |  0.772744940361008 |
>>> |  0.170518629485741 |
>>> | 0.0833237133920193 |
>>> |  0.149035625392571 |
>>> |  0.698798568220809 |
>>> |  0.627075897762552 |
>>> |  0.177144371205941 |
>>> | 0.0476319056469947 |
>>> |  0.289851602632552 |
>>> | 0.0296813279855996 |
>>>
>>> * and another
>>> testthingy
>>> #+RESULTS: testcode :exports both
>>>
>>> --8<---cut here---end--->8---
>>>
>>> If I update the calculation, the first results block is updated, but
>>> not the second one. I would like to have two RESULTS blocks which
>>> are both updated when the code block is evaluated.
>>>
>>> Is this possible?
>>>
>>> Thanks,
>>>
>>> Rainer
>>
>> --
>> Professor John Kitchin
>> Doherty Hall A207F
>> Department of Chemical 

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Rainer M Krug]

Aaron Ecay  writes:

> Hi Rainer,
>
> 2015ko martxoak 9an, Rainer M Krug-ek idatzi zuen:
>>
>> Hi
>>
>> Consider the following:
>>
>> --8<---cut here---start->8---
>> * The calculation
>> #+NAME: testcode :exports both
>
> It looks like you’ve tried to put a header argument into the name.  Is
> it merely an accident?  I ask because...

Accident - the header argument should be behind the code block beginning
and not the NAME - sorry.

>
>> #+begin_src R  :session test
>> runif(10)
>> #+end_src
>>
>>
>> * summary of the results
>> First time
>> #+RESULTS: testcode :exports both
>> |  0.772744940361008 |
>> |  0.170518629485741 |
>> | 0.0833237133920193 |
>> |  0.149035625392571 |
>> |  0.698798568220809 |
>> |  0.627075897762552 |
>> |  0.177144371205941 |
>> | 0.0476319056469947 |
>> |  0.289851602632552 |
>> | 0.0296813279855996 |
>>
>> * and another
>> testthingy
>> #+RESULTS: testcode :exports both
>
> ...here it reoccurs, in identical format.  This is fine, interpreted
> as just a weird block name (and not as an actual header argument).
> But if you’re trying to allow the header arguments to vary for the two
> result blocks I don’t think it will be very nice.  (It would require
> re-evaluating the code block for each different combination of header
> arguments, which would give unexpected behavior in the case of side
> effects, etc. etc.)

I think I clud do this by using =#+CALL testcode= but this is not w=hat
I wanted.

>
> Maybe it’s not very important, but I just figured I’d ask for
> clarification.

Sure - I should be looking more carefully when typing.

Is my brain really that slow, as I am not a fast typer...

Cheers,

Rainer

>
> Thanks,
>
> --
> Aaron Ecay
>
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Multiple (identical) RESULTS blocks of one code block?

[Rainer M Krug]

John Kitchin  writes:

> I don't believe this is possible out of the box. The first RESULTS block
> from the beginning of the buffer will be updated, and not the others.
>
> You might be able to use a hook function to do this, something like:
>
> #+BEGIN_SRC emacs-lisp
> (defun update-results () (interactive)
>   ;; get name of src block
>   (let ((name (org-element-property :name (org-element-at-point)))
> (results))
> (when name
>   (org-element-map (org-element-parse-buffer) 'fixed-width
> (lambda (object)
>   (if results
>   ;; replace value in block
>   (setf
>(buffer-substring
> (org-element-property :begin  object)
> (org-element-property :end  object))
>results)
> ;; set results
> (setq results
>   (buffer-substring
>(org-element-property :begin  object)
>(org-element-property :end  object)
> #+END_SRC
> #+BEGIN_SRC emacs-lisp
> (add-hook 'org-babel-after-execute-hook 'update-results)
> #+END_SRC
>
> This worked on a small test example, but I did not test it
> thoroughly. your mileage might vary ;)

This looks nice - I will try it out and see how it goes.


>
>
> Rainer M Krug writes:
>
>> Hi
>>
>> Consider the following:
>>
>> --8<---cut here---start->8---
>> * The calculation
>> #+NAME: testcode :exports both
>> #+begin_src R  :session test
>> runif(10)
>> #+end_src
>>
>>
>> * summary of the results
>> First time
>> #+RESULTS: testcode :exports both
>> |  0.772744940361008 |
>> |  0.170518629485741 |
>> | 0.0833237133920193 |
>> |  0.149035625392571 |
>> |  0.698798568220809 |
>> |  0.627075897762552 |
>> |  0.177144371205941 |
>> | 0.0476319056469947 |
>> |  0.289851602632552 |
>> | 0.0296813279855996 |
>>
>> * and another
>> testthingy
>> #+RESULTS: testcode :exports both
>>
>> --8<---cut here---end--->8---
>>
>> If I update the calculation, the first results block is updated, but
>> not the second one. I would like to have two RESULTS blocks which
>> are both updated when the code block is evaluated.
>>
>> Is this possible?
>>
>> 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
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Multicite syntax

[Vaidheeswaran C]

On Sunday 08 March 2015 09:58 PM, Nicolas Goaziou wrote:
> Agreed. I introduced yet another syntax change in "wip-cite" branch.
> 
> Now there are two separate objects "citation" and "citation-reference".
> So the following multicite 
> 
>   [cite:prefix; pre @a post; @b]
> 
> is parsed like
> 
>   (citation (:prefix "prefix" :parenthetical nil) 
>(citation-reference (:key "a" :prefix "pre" :suffix "post"))
>(citation-reference (:key "b")))

I have pushed the corresponding changes to
http://repo.or.cz/w/org-mode/org-cv.git.  The pull URL is
git://repo.or.cz/org-mode/org-cv.git.

I am attaching sample files for inspection.


cite-chicago-author-date.odt
Description: application/vnd.oasis.opendocument.text


cite-chicago-full-note.odt
Description: application/vnd.oasis.opendocument.text


cite.org
Description: Lotus Organizer


cite-numeric.odt
Description: application/vnd.oasis.opendocument.text

Re: [O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> And just for the heck of it, here's another patch that does it with
>> narrowing.
>
> Thanks for the patch.
>
> However, I don't think it belongs to `org-adaptive-fill-function' to
> handle this. All this Message mode processing should probably be
> delegated to the orgstruct level.

Makes sense!

If we really want to get all the message-specific stuff refactored into
orgstruct++ mode, I guess we could (in the `orgstruct++-mode' function)
bind `normal-auto-fill-function' and `adaptive-fill-function' to new
functions, which first check for message-mode specific stuff (and any
other modes that need to be handled), then delegate to
`org-auto-fill-function' and `org-adaptive-fill-function'.

Actually, all `org-auto-fill-function' does is conditionally call
`org-adaptive-fill-function', so maybe we could just have one new
function, `orgstruct++-auto-fill-function', that does everything.

How does that sound?

Eric

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Rasmus]

Nicolas Goaziou  writes:

> I'd rather have a single syntax for keys.

Me to.

> Since this one is not much more intrusive than the previous one, we
> could as well drop @key in favor of @{key}.

It seems like a moderately dear price to pay for everyone with "normal"
citation keys...  It's better than @key-with-',?.'{}.

How about other citations?  Are we talking the wholesale solution:

[cite: @{key}]
[(cite): @{key}]
[@{key}]

Otherwise, I don't see how we have come closer to one syntax from a user
point of view.  And I don't like the above.

—Rasmus


-- 
Vote for proprietary math!

Re: [O] including files and org-src-preserve-indentation

[Nicolas Goaziou]

Hello,

Linus Arver  writes:

> Meanwhile from the Org side, perhaps we can have a way to let the user
> select which program to use for syntax highlighting? Maybe something
> external like Pygments [3]?

Would you want to provide a patch for that?


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> And just for the heck of it, here's another patch that does it with
> narrowing.

Thanks for the patch.

However, I don't think it belongs to `org-adaptive-fill-function' to
handle this. All this Message mode processing should probably be
delegated to the orgstruct level.


Regards,

-- 
Nicolas Goaziou

Re: [O] [bug?] org-repair-property-drawers does not repair whole file

[Nicolas Goaziou]

Gregor Zattler  writes:

> As you might guess this part represents an email, the multi line
> node being the message body.  How would one incorporate such
> info in proper org-mode syntax?  Since as of now I do not query
> the name=value pairs this is no strict necessity for me.

It depends on what you want to do with that data. You may use another
drawer, e.g. :EMAIL: or a quote block, or an example block...

> Is there a syntax checker for org-mode files?

There is no invalid syntax in Org mode. What you wrote is a valid
drawer, albeit not a valid properties drawer.

Regards,

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Nicolas Goaziou]

Eric S Fraga  writes:

>> We keep the existing syntax for keys, which disallows key-ending
>> punctuation, but we also allow a second style of key, in which curly
>> braces surround the key name proper, like:
>>
>>   @{Doe1999}
>
> I like this much better.

I'd rather have a single syntax for keys. Since this one is not much
more intrusive than the previous one, we could as well drop @key in
favor of @{key}.


Regards,

[O] Bug: problem when exporting a org-mode file with a lots of code blocks

[XIE Yuheng]

Bug: org-babel-parse-src-block-match reporting "Wrong type argument:
stringp, nil" when exporting a org-mode file with a lots of code blocks
[8.3beta (release_8.3beta-895-g375c83 @ /usr/share/emacs/site-lisp/org/)]



the following is *Messages* buffer
   https://www.refheap.com/98243
the following is the org-mode file with a lot of code blocks
   
https://github.com/the-little-language-designer/cicada-nymph/blob/master/cicada-nymph.org
the following is an the fasm-mode I am using
   
https://github.com/the-little-language-designer/fasm-mode/blob/master/fasm-mode.el


Emacs  : GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.7)
 of 2015-01-18 on bisson
Package: Org-mode version 8.3beta (release_8.3beta-895-g375c83 @ 
/usr/share/emacs/site-lisp/org/)



current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe 
org-babel-hide-result-toggle-maybe org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(lambda (name contents) contents)
 org-src-window-setup 'current-window
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-babel-no-eval-on-ctrl-c-ctrl-c t
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function '(lambda (name contents) contents)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer
 (lambda nil (local-set-key (kbd "C-s C-s") (quote 
org-edit-src-exit
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((lambda nil (local-set-key (kbd "C-,") (quote 
ska-jump-to-register))) t current-window 0 nil
 #[nil "\300\301\302\303\304$\207" [org-add-hook 
change-major-mode-hook org-show-block-all append local] 5]
 #[nil "\300\301\302\303\304$\207" [org-add-hook 
change-major-mode-hook org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ascii-format-drawer-function '(lambda (name contents width) contents)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point 
org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
org-cycle-hide-inline-tasks org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-todo-keywords '((sequence "><" "|" "><><" "|" "><><><") (sequence "todo") 
(sequence "待") (sequence "note" "|" "test")
 (sequence "記" "|" "測") (sequence "记" "|" "测"))
 org-reveal-hlevel 2
 org-babel-tangle-lang-exts '(("lisp" . "lisp") ("emacs-lisp" . "el") ("elisp" 
. "el"))
 org-confirm-elisp-link-function 'yes-or-no-p
 org-src-ask-before-returning-to-edit-buffer nil
 org-edit-src-content-indentation 0
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-html-format-headline-function 'org-html-format-headline-default-function
 org-structure-template-alist '(("sf" "#+end_src\n?\n#+begin_src" "\n\n")
("s" "#+begin_src\n?\n#+end_src" "\n\n")
("picturef" "#+end_src\n?\n#+begin_src picture" 
"\n\n")
("picture" "#+begin_src picture\n?\n#+end_src" 
"\n\n")
("yamlf" "#+end_src\n?\n#+begin_src yaml" "\n\n")
("yaml" "#+begin_src yaml\n?\n#+end_src" "\n\n")
("bnff" "#+end_src\n?\n#+begin_src bnf" "\n\n")
("bnf" "#+begin_src bnf\n?\n#+end_src" "\n\n")
("coqf" "#+end_src\n?\n#+begin_src coq" "\n\n")
("coq" "#+begin_src coq\n?\n#+end_src" "\n\n")
("ljf" "#+end_src\n?\n#+begin_src lojban" "\n\n")
("lj" "#+begin_src lojban\n?\n#+end_src" "\n\n")
("ssf" "#+end_src\n?\n#+begin_src scheme" "\n\n")
("ss" "#+begin_src scheme\n?\n#+end_src" "\n\n")
("lispf" "#+end_src\n?\n#+begin_src lisp" "\n\n")
("lisp" "#+begin_src lisp\n?\n#+end_src" "\n\n")
("shenf" "#+end_src\n?\n#+begin_src shen" "\n\n")
("shen" "#+begin_src shen\n?\n#+end_src" "\n\n")
("clojuref" "#+end_src\n?\n#+begin_src clojure" 
"\n\n")
("clojure" "#+begin_src clojure\n?\n#+end_src" 

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Eric S Fraga]

On Monday,  9 Mar 2015 at 17:36, Richard Lawrence wrote:

[...]

> I feel the same as you do about this, so here's one more thought for the
> thread.  How about this alternative?
>
> We keep the existing syntax for keys, which disallows key-ending
> punctuation, but we also allow a second style of key, in which curly
> braces surround the key name proper, like:
>
>   @{Doe1999}

I like this much better.  

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org 
release_8.3beta-843-ga5f1a3.dirty