Re: [O] Embedding diagrams in Org

[Sebastien Vauban]

Hello Andreas,

Andreas Leha wrote:
 I also use tikz in my org files.  I just include a slightly more
 involved version of Eric's example to show some of the beauty of org.

 This includes a caption for the diagram, and different output formats
 for different export routes.

 #+LATEX_HEADER: \usepackage{tikz}

 * tikz example

 #+name: tikz_example
 #+header: :packages '(( tikz))
 #+header: :file (by-backend (latex example_diagram.tikz) (html 
 example_diagram.svg) (t example_diagram.png))

Where is the `by-backend' function defined?

 #+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 
 800
 #+header: :results file raw
 #+header: :fit yes
 #+begin_src latex
   \begin{tikzpicture}
 \node[red!50!black] (a) {A};
 \node (b) [right of=a] {B};
 \draw[-] (a) -- (b);
   \end{tikzpicture}
 #+end_src

 #+caption: A tikz example diagram with a caption
 #+results: tikz_example
 [[file:example_diagram.png]]

What'd be nice is that you could say (in a *file* property) that the
extension for LaTeX always has to be .tikz, for HTML .svg and .png in
all the other cases.

Then, you could simply give the base name of the figure where
appropriate, in a DRY configuration.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Embedding diagrams in Org

[Sebastien Vauban]

Eric S Fraga wrote:
 I do wonder, however, why we need to turn languages on or off?  It
 would be nice if org-babel would do this automatically when a language
 specific src block is encountered...

That'd make some sense, indeed... Kind of autoloads for all the
languages...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] key binding for org-inlinetask-insert-task has gone missing?

[Eric S Fraga]

On Thursday, 19 Feb 2015 at 17:59, Rasmus wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 Hello all,

 Please ignore my previous email.  I have rebuilt org and restarted emacs
 and everything is back to normal.  I don't know why a particular key
 binding disappeared but maybe it was a cosmic ray incident :)

 [[http://xkcd.com/378/]]

 For what it is worth, I also sometimes lose the binding of inlinetasks and
 I don't know what causes it...

Thanks!  Makes me feel a little better :)

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

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again! The FSA-assignment is now complete. New patches are attached
and comments below.

On Sat, Jan 31, 2015 at 9:41 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:

 I suppose an FSF-assignment signature is needed before it can be
 included.

 Indeed.

Marked as done now, as stated above :-)

 - Grouptags don't have to be unique on a headline if added with [ ]
   instead of with { }: , | #+TAGS: [ group : include1 included2 ]
   `

 I'd rather not introduce yet another syntax for group tags. IIUC, the
 current one (with curly braces) can be extended.

 Also, I don't get the have to be unique on a headline part.

The reason for the use of [ ] is because { } already has another purpose
- it is used to make the tags within { } exclusive.

this example

,
| #+TAGS: { group : include1 include2 }
`

will only allow one of the tags on any specific headline. [ ] solves
this. Note that grouptags doesn't care if { } or [ ] is used. The only
difference is the exclusiveness. I.e both

,
| #+TAGS: [ group : include1 include2 ]
| #+TAGS: { group : include1 include2 }
`

will work. With some limitations on the second example due to the way {
} works since before.

   A new variable is defined `ORG-GROUP-TAGS-MAX-DEPTH' that is used
   to limit the depth of recursion when expanding tags. It defaults to
   2.

 I don't think this variable is necessary. However, a check for
 circular inclusions would be necessary.

Indeed. The variable is removed and the function `org-tags-expand' now
handles circular definitions with grace ;-)

Best regards
Gustav Wikström


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: Binary data


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-org-Nesting-grouptags.patch
Description: Binary data

Re: [O] [bug] org time stamp can't read time

[Nicolas Goaziou]

Hello,

Rasmus ras...@gmx.us writes:

 When I call org-time-stamp (C-c .) from Emacs -q and give a time such as
 11:00 and nothing else I get 2015-02-19.  I would expect something
 like 2015-02-19 11:00, as in v8.2.

Fixed in 38ab8b2af360085370eee5342e20827a3fb976e3. Thank you.


Regards,

-- 
Nicolas Goaziou

[O] Org-pomodoro showing number of pomodoros

[Renger van Nieuwkoop]

Hi
I just started using org-pomodoro and have one question: How can I see the 
number of pomodoros I finished during the day?
Cheers
Renger
_
Renger van Nieuwkoop
Swiss Federal Institute of Technology Zurich

[O] External compilation

[Rasmus]

Hi,

I want to translate some documents to pdf.  I'm currently doing it with
something like this

OX-FUN= emacs --batch --no-init-file --load conf.el $1 --funcall $2 
--kill
OX-LATEX  = $(call OX-FUN, $1, org-latex-export-to-pdf)

But this is very limiting (I am told) as it require me to maintain a
Makefile.  It's not as easy as latex.

I can move the call to  Emacs as file variable s.t.

# Local Variables:
# eval:  (unless (or user-init-file (window-system)) (load-file conf.el))
# End:

And export by calling:

emacs --batch --no-init-file --eval=(progn (setq enable-local-eval t) 
(require 'ox-latex)) $1 --funcall=org-latex-export-to-pdf

But this is kind of annoying as it disturbs opening the file

I tried to port my config to conf.org and let babel handle it, but
conf.org also defines the document class so I never get to the babel
evaluation stage.

Has anybody come up with a better method?

Ideally, what I would like would be to specify a per-file/project init
file.  Sort of like org-export-async-init-file, but as part of
org-export-options-alist to get the init.el-dependency inside the
Org-file.  It would be read when Org exports async or via batch.

—Rasmus

-- 
This message is brought to you by the department of redundant departments

Re: [O] [patch, ox-latex] better hyperref and title options

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 So irrespective of this, here's an updated patch that uses
 secondary-string parsing.  Should I add it to master before or after I get
 done with this moving description and keywords?

You can go ahead, after fixing some minor typos. Thanks.

 * ox-latex.el (org-latex-format-spec): New function with format-specs.

Typo in the name.

   (org-latex-template): Use org-latex-format-spec.
   (org-latex-hyperref-template): New defaults and use
   org-latex-format-spec.
   (org-latex-title-command): Use org-latex-format-spec.

Ditto (x3).

 +*** ~org-latex-hyperref-template~, ~org-latex-title-command~ formatting
 +New formatting keys are supported.  See ~org-latex-format-spec~.

See docstrings for more information (no need to talk about
`org-latex--format-spec').

 +(defun org-latex--format-spec (info)
 +  Create a format-spec for e.g. `org-latex-hyperref-template'.
 +Also used by `org-latex-title-command'

  Create a format-spec for document meta-data.
  INFO is..

is enough IMO.

 -  (let ((title (org-export-data (plist-get info :title) info)))
 +  (let ((title (org-export-data (plist-get info :title) info))
 + (spec (when (org-some 'stringp (list org-latex-hyperref-template
 +  org-latex-title-command))
 + (org-latex--format-spec info

Nitpick: #'stringp

Anyway, both `org-latex-hyperref-template' and `org-latex-title-command'
are always strings, per defcustom type. So you can drop the `when' part:

  (spec (org-latex--format-spec info))


Regards,

Re: [O] [ox-latex, bug?] :caption forces environment

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 This is a feature. A caption implies, at least, a table environment.

 Except when it doesn't¹ ...

That's your problem since Org didn't request the minipage in the first
place. You don't want a caption but still provide one.

 And in this case I told Org that it doesn't by specifying :environment
 nil. :environment should be stronger than :caption.

This is really a matter of taste. I don't mind either way.

 There no explicit interface for \captonof, and reading the manual of
 capt-of, I don't want to, as the author says care should be taken in
 documents where floats are also used.

Again, this is the user's problem. But it could be reasonable to use
captionof when no environment is explicitly required. IOW ox-latex
could fall-back to caption of when a caption is specified and there's no
environment to hold it.


Regards,

Re: [O] [ox-latex, bug?] :caption forces environment

[Nicolas Goaziou]

Hello,

Rasmus ras...@gmx.us writes:


 Consider this example:

 #+ATTR_LATEX: :environment nil :center nil :caption cap
 | t |

 Exporting to latex, it produces:

 \begin{table}[htb]
 cap
 \begin{tabular}{l}
 \toprule
 t\\
 \bottomrule
 \end{tabular}
 \end{table}

 I'd expect:

 cap
 \begin{tabular}{l}
 \toprule
 t\\
 \bottomrule
 \end{tabular}

This is a feature. A caption implies, at least, a table environment.

 The real usecase is that I want to use \captionof{table}{my caption}.

This feature existed before support for captionof. Of course, it is
now possible to make use of this macro and alter `org-latex--org-table'
accordingly.


Regards,

-- 
Nicolas Goaziou

[O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil

[Eli Zaretskii]

 From: Damian Nadales damian.nada...@asml.com
 Date: Tue, 17 Feb 2015 16:04:54 +
 
 Running Emacs 24.4, compiled from source I found I cannot kill a buffer when
 performing these steps:
 
 - Run emacs –Q
 
 - Create an org-mode file (i.e. ``myorgfile.org``)
 
 - Insert the following text:
 
 o #+BEGIN_SRC C++
 
 #+END_SRC
 
 - Edit the source block by placing the cursor inside the SRC block.
 
 - Start C++ mode (c++-mode)
 
 - Try to kill the buffer.

I cannot reproduce this.  I tried both Emacs 24.4 and the pretest of
24.5.  In both cases, Emacs asks me whether to kill a buffer that is
modified, and once I answer YES, the buffer is killed.

Is it possible that you are using Org mode from the Org repository,
not the one bundled with Emacs?

Re: [O] [ox-latex, bug?] :caption forces environment

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 This is a feature. A caption implies, at least, a table environment.

Except when it doesn't¹ ...  And in this case I told Org that it doesn't by
specifying :environment nil.  :environment should be stronger
than :caption.

 The real usecase is that I want to use \captionof{table}{my caption}.

 This feature existed before support for captionof. Of course, it is
 now possible to make use of this macro and alter `org-latex--org-table'
 accordingly.

There no explicit interface for \captonof, and reading the manual of
capt-of, I don't want to, as the author says care should be taken in
documents where floats are also used.

—Rasmus


Footnotes: 
¹   I need to put the table inside an minipage, and they don't hold floats.

-- 
. . . The proofs are technical in nature and provides no real
understanding

Re: [O] [ox-latex, bug?] :caption forces environment

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Again, this is the user's problem. But it could be reasonable to use
 captionof when no environment is explicitly required.

Do you consider it explicit when no environment is specified?  I would
/only/ use capt-of when :environment is nil.

  IOW ox-latex could fall-back to caption of when a caption is
 specified and there's no environment to hold it.

That would be nice, I guess.  Then I could also use #+CAPTION which is
arguably nicer than #+attr_latex :caption.

—Rasmus

-- 
⠠⠵

Re: [O] Embedding diagrams in Org

[Eric S Fraga]

On Wednesday, 18 Feb 2015 at 19:37, Andreas Leha wrote:

[...]

 I also use tikz in my org files.  I just include a slightly more
 involved version of Eric's example to show some of the beauty of org.

Thanks for adding to the example.  Your by-backend function looks
useful.  Would you post it to the list please?  I've done something
similar via nested if's but your approach is much cleaner.

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

Re: [O] How to get a column correctly formatted in Babel + R (w/ or w/o name)?

[Charles C. Berry]

On Thu, 19 Feb 2015, Sebastien Vauban wrote:


#+PROPERTY:  session *R*

* Source

#+name: table
| ID  | User1 | User2 |
|-+---+---|
| 26/0163 | lrp   | nil   |
| 37/0001 | nil   | nil   |
| 37/0003 | nil   | nil   |



[snip]


* First column (with name)

When I try to get the first column printed along with its name (ID), I have
troubles doing so...

#+begin_src R :var df=table :colnames yes
df[, 1]
#+end_src



Try this:

,
| #+begin_src R :var df=table :colnames yes
| df[, 1,drop=FALSE]
| #+end_src
|
| #+RESULTS:
| | ID  |
| |-|
| | 26/0163 |
| | 37/0001 |
| | 37/0003 |
`

Look at

#+BEGIN_SRC R :results output
  example(`[.data.frame`)
#+END_SRC

for some help on this.


HTH,

Chuck

Re: [O] [patch, ox-latex] better hyperref and title options

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rasmus ras...@gmx.us writes:

 So irrespective of this, here's an updated patch that uses
 secondary-string parsing.  Should I add it to master before or after I get
 done with this moving description and keywords?

 You can go ahead, after fixing some minor typos. Thanks.

Pushed.

-- 
The Kids call him Billy the Saint

[O] Publishing orgmode files

[Xavier Maillard]

Hello,

I am trying to publish my org project but I am lost in the way I can
tweak my projects.

Is there some good tutorial I can follow step by step in order to
publish several files at once ?

My site tree is like this:

web/
├── Makefile
├── css
│   └── style.css
├── gnupg.org
├── header
│   └── header.org
├── index.org
├── org-templates
│   └── level-0.org
└── publish_config.el

I am using a Makefile to build it from the command line but it is
just a gadget that just make a call to `org-publish-project'.

Where I am totally lost is with how I can tweak my publish option.

Turns out I can add many options directly into org-mode files but
that's not practical to clone/duplicate them in several places. This
is where org-templates should enter the dance but either I use them
bad or it just not the way to go.

I am tryng as a simple example, to replace the default (included)
style with my own (stored in css/style.css).

My org-templates/level-0.org has this:

#+STYLE: link rel=stylesheet type=text/css href=css/style.css /

# Local Variables:
# org-html-head-include-default-style: nil
# org-html-head-include-scripts: nil
# End:

All of this has been stolen here and there but it just does nothing.
Elsewhere I have seen we can embed :style in the
`org-publish-project-alist' (same result). Some people are using
#+HTML_HEAD_EXTRA instead.

So what is the way to go just for this basic stuff ?

I have nothing configured with org-mode (8.2.10 version by the way)
and I am using the defaults eveywhere.

Can someone help ?


Thank you.
--
Xavier


signature.asc
Description: PGP signature

Re: [O] Citation syntax: a revised proposal

[Melanie Bacou]

Just want to point out RMarkdown/Pandoc implementation of bibliographies 
and citations here 
http://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.html


One useful option is a `csl: biomed-central.csl` option in the preamble.

--Mel.


On 2/19/2015 12:06 PM, Richard Lawrence wrote:

Nicolas Goaziou m...@nicolasgoaziou.fr writes:



I wasn't clear. Subtype should be interpreted by back-ends means it has
no impact on syntax. However a user should be able to dictate what the
back-end should do with it, much like `org-add-link-type'.

A new library, e.g. org-cite.el would provide all the tools necessary
to build custom handlers for subtypes. Thus, power users can do whatever
they want with cite objects.


Ah, OK, I think I see...so this is basically the second option, with
users interpreting subtypes via a separate protocol, instead of via
filters.  Right?

What about this concern, then?


But that kind of situation is exactly what the extra-info part
of the syntax is for; in that case,

   [cite/my-subtype: ...]

would just be an exceptional way of writing

   [cite: ...]{:type my-subtype}

or whatever.  I'm not totally convinced yet that the convenience of the
former is worth blurring the line between `stuff that definitely works
on all backends' and `stuff that might not work on all backends'.




We have already seen a couple of examples in this thread of properties
that one might want to specify in a backend-agnostic way:
   - special-case capitalization
   - user-defined type/command/label/etc.

Other things one might want to do include:
   - indicating when a citation should be placed in a footnote
   - extracting arbitrary bibliographic field(s)


I disagree. These properties should be associated to the subtype.
Having two places to set them is asking for trouble.

IMO, there is little incentive to define a set of options for a single
use. Creating a dedicated subtype /once/ makes more sense.


Hmm, OK.  I agree in the abstract, but as far as I understand what a
`subtype' is, I am not sure how well that idea applies in this case.  If
a subtype encompasses a set of options, and the only way to specify
those options is by specifying a subtype, then changing one option means
changing to a whole different subtype, even when you want all the other
options to stay the same.  That will lead to a lot of duplication in
subtypes.  That in turn could lead to a lot of author frustration: now I
have to remember exactly which subtype encompasses the set of options I
need for this particular citation.

Look at the LaTeX citation commands.  There, you have a different
`type'/command for every possible combination of options, and there are
many commands because there are many options to deal with special cases.
In my mind, that is the wrong abstraction to emulate.  You end up making
trips to the manual to figure out exactly which one you need.

To me, it makes much more sense to have a basic citation command, and
then a way to `answer some questions' to toggle various things related
to special-case behavior, like:
   - should it be footnoted?
   - should it have special-case capitalization?
   - should it cite the volume?
   - should it deal with brackets in a context-sensitive manner?
   - should it use the genitive form of the author's name?
   - ...

I would guess that the answers to these questions *usually* have nothing
to do with one another, so it makes sense to be able to answer them
independently, and change your answer to one independently of your
answers to the others.  That's why I would want to be able to write

[cite: ...]{:footnoted t :capitalized t :author-title t ...}

rather than

[cite/footnoted-capitalized-author-title: ...]

In the former case, if I later figure out I don't need the `:capitalized
t' part, that's easy to remove without changing the other options.  In
the latter case, I need to remember what name I gave to the subtype for
footnoted-but-not-capitalized-author-titles, or whatever.

I don't know; maybe this is not a very serious concern in practice.
Maybe, in practice, you generally only need one `special case' option at
a time, so the number of subtypes will be small.  Still, I do not feel
comfortable declaring *in advance* that that is so; and the bewildering
array of LaTeX citation commands is at least some evidence that it
isn't.  Thus, I am in favor of allowing the greater flexibility provided
by the former syntax.

That's not to say that subtypes never make sense: you are quite right
that sometimes options *should* be grouped together into a subtype,
namely, when it makes sense to set or remove them *conjointly*.  But
that means the two syntaxes above actually have different purposes, even
though for some range of cases either one would do the job.

So although I would not be in favor of *only* allowing

[cite/subtype: ...]

I am basically OK with allowing this if we also allow the {:key val ...}
syntax.  Still, the /subtype form is not needed if we also allow

Re: [O] ox-html: stand-alone export option?

[Melanie Bacou]

Hi Rasmus, see below.

On 2/18/2015 5:39 AM, Rasmus wrote:

Hi Melanie,

Melanie Bacou m...@mbacou.com writes:


I'm using ox-html to work on shared documents with my
collaborators. We're working off a Dropbox account and converting our
org files to HTML periodically.


Cool.


Problem with all cloud storages is they don't work with relative links
inside HTML (links to external images, CSS, and JS resources).


I use git and ssh to a wm which I guess is different from cloud storages
so maybe I don't understand.  If you open the browser of my.html and you
have an absolute path to https://orgmode.org/logo.png the browser would
display it no?  Likewise for img/logo.png.  Probably I've
misunderstood. . .


You're right with Github or remote storages there's no problem (links to 
images like `./fig/my_fig.png` or local CSS or JS `./css/my_css_.css` 
are interpreted as usual. The problem is only on cloud storage services 
like Dropbox where each resource gets a unique (unknown a priori) ID. 
These make it difficult to publish HTML documents.





We would really benefit from having a stand-alone HTML exporter
feature that automatically embeds all external references into one
single HTML file, so they can be shared with Dropbox, Google Drive,
OneDrive and the likes.


Would you base64 encode images and inline code or do you have something
else in mind with single HTML file?  It's not built into Org ATM.


Yes indeed was thinking of a stand-alone option that would include 
base64 encoded images and also verbatim include all local CSS and JS in 
the document head.




In the short run maybe there's a tool that can do.  For instance, in
Firefox it will save auxiliary material when you save a page.  I don't
know if also save whatever scripts you rely on from whatever CDN far away...


Right, I looked at that too, but no true stand-alone option in FF or 
Chrome, both browsers include resources in a separate folder. Might 
spend a little more time searching for another utility.





Has this been discussed previously? Would there be any other work around?


I think there was one guy who had patch that would automatically download
external images.  Pretty neat.  I don't know if it was applied in the end.


I'd vote for this feature. In fact I believe it's now an option with 
RMarkdown/HTML documents.




—Rasmus



--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org

[O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil

[Damian Nadales]

 I cannot reproduce this.  I tried both Emacs 24.4 and the pretest of 24.5.  In
 both cases, Emacs asks me whether to kill a buffer that is modified, and once
 I answer YES, the buffer is killed.

[Damian Nadales]
That's weird. Which buffer are you killing, the Org buffer, or the new buffer 
that is created when pressing C-c ' inside the source block? Is the latter the 
one I cannot kill.


 Is it possible that you are using Org mode from the Org repository, not the
 one bundled with Emacs?
[Damian Nadales]
I've only installed packages through the emacs package manager, and Org mode 
was not one of them. The command ``org-version`` reports:

Org-mode version 8.2.10 (release_8.2.10 @ 
/home/dnadales/opt/share/emacs/24.4/lisp/org/)

I don't know if there is any other information I could give.

In any case thanks for your time.
-- The information contained in this communication and any attachments is 
confidential and may be privileged, and is for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. Unless explicitly stated otherwise in the body of this 
communication or the attachment thereto (if any), the information is provided 
on an AS-IS basis without any express or implied warranties or liabilities. To 
the extent you are relying on this information, you are doing so at your own 
risk. If you are not the intended recipient, please notify the sender 
immediately by replying to this message and destroy all copies of this message 
and any attachments. The sender nor the company/group of companies he or she 
represents shall be liable for the proper and complete transmission of the 
information contained in this communication, or for any delay in its receipt.

Re: [O] Citation syntax: a revised proposal

[Nicolas Goaziou]

Richard Lawrence richard.lawre...@berkeley.edu writes:

 Ah, OK, I think I see...so this is basically the second option, with
 users interpreting subtypes via a separate protocol, instead of via
 filters.  Right?

Correct.

 What about this concern, then?

 But that kind of situation is exactly what the extra-info part
 of the syntax is for; in that case,

   [cite/my-subtype: ...] 

 would just be an exceptional way of writing

   [cite: ...]{:type my-subtype}

 or whatever.  I'm not totally convinced yet that the convenience of the
 former is worth blurring the line between `stuff that definitely works
 on all backends' and `stuff that might not work on all backends'.

I think everything is in the category stuff that might not work on all
backends. Citations do not even make sense in all back-ends.

 Hmm, OK.  I agree in the abstract, but as far as I understand what a
 `subtype' is, I am not sure how well that idea applies in this case.  If
 a subtype encompasses a set of options, and the only way to specify
 those options is by specifying a subtype, then changing one option means
 changing to a whole different subtype, even when you want all the other
 options to stay the same.  That will lead to a lot of duplication in
 subtypes.  That in turn could lead to a lot of author frustration: now I
 have to remember exactly which subtype encompasses the set of options I
 need for this particular citation.

AFAICT, the most advanced use of citations is Thomas', and he is
basically only using subtype. So I'm pretty confident that 99.9% of
users will be fine with only these subtypes.

 Look at the LaTeX citation commands.  There, you have a different
 `type'/command for every possible combination of options, and there are
 many commands because there are many options to deal with special cases.
 In my mind, that is the wrong abstraction to emulate.  You end up making
 trips to the manual to figure out exactly which one you need.  

 To me, it makes much more sense to have a basic citation command, and
 then a way to `answer some questions' to toggle various things related
 to special-case behavior, like:
   - should it be footnoted?
   - should it have special-case capitalization?
   - should it cite the volume?
   - should it deal with brackets in a context-sensitive manner?
   - should it use the genitive form of the author's name?
   - ...

 I would guess that the answers to these questions *usually* have nothing
 to do with one another, so it makes sense to be able to answer them
 independently, and change your answer to one independently of your
 answers to the others.  That's why I would want to be able to write

 [cite: ...]{:footnoted t :capitalized t :author-title t ...}
  
 rather than

 [cite/footnoted-capitalized-author-title: ...]

 In the former case, if I later figure out I don't need the `:capitalized
 t' part, that's easy to remove without changing the other options.  In
 the latter case, I need to remember what name I gave to the subtype for
 footnoted-but-not-capitalized-author-titles, or whatever.

A good naming scheme can certainly help here. I'd choose

  [cite:FAT:...]

over

  [cite: ...]{:footnoted t :capitalized t :author-title t}

Moreover, we certainly can provide a menu offering the defined subtypes
(with a short summary) for completion.

 I don't know; maybe this is not a very serious concern in practice.
 Maybe, in practice, you generally only need one `special case' option at
 a time, so the number of subtypes will be small.  Still, I do not feel
 comfortable declaring *in advance* that that is so; and the bewildering
 array of LaTeX citation commands is at least some evidence that it
 isn't.  Thus, I am in favor of allowing the greater flexibility provided
 by the former syntax.

In fact, the former syntax provides less flexibility since you declare
/in advance/ what features, or properties, will be supported (or you let
users declare their own keywords, which is even worse).

It doesn't even help users because the handler for foo subtype has to
take into account all possible combinations of properties, and so has
bar subtype's handler. IOW, handlers become complicated to write.

 That's not to say that subtypes never make sense: you are quite right
 that sometimes options *should* be grouped together into a subtype,
 namely, when it makes sense to set or remove them *conjointly*.  But
 that means the two syntaxes above actually have different purposes, even
 though for some range of cases either one would do the job.

They have the same purpose. Your concern is that one may need a large
number of subtypes. That can be handled by appropriate tools.

 So although I would not be in favor of *only* allowing

 [cite/subtype: ...]

 I am basically OK with allowing this if we also allow the {:key val ...}
 syntax.  Still, the /subtype form is not needed if we also allow

 [cite: ...]{:type subtype}

Again, I don't think we need {:key val} at the moment. Also, it would be
nice to 

[O] How to get a column correctly formatted in Babel + R (w/ or w/o name)?

[Sebastien Vauban]

#+PROPERTY:  session *R*

* Source

#+name: table
| ID  | User1 | User2 |
|-+---+---|
| 26/0163 | lrp   | nil   |
| 37/0001 | nil   | nil   |
| 37/0003 | nil   | nil   |

#+begin_src R :var df=table :colnames yes
df
#+end_src

#+results:
| ID  | User1 | User2 |
|-+---+---|
| 26/0163 | lrp   | nil   |
| 37/0001 | nil   | nil   |
| 37/0003 | nil   | nil   |

We just checked that the table is correctly imported in R.

* First column (with name)

When I try to get the first column printed along with its name (ID), I have
troubles doing so...

#+begin_src R :var df=table :colnames yes
df[, 1]
#+end_src

#+results:
| x   |
|-|
| 26/0163 |
| 37/0001 |
| 37/0003 |

#+begin_src R :var df=table :colnames yes
as.data.frame(df[, 1])
#+end_src

#+results:
| df[, 1] |
|-|
| 26/0163 |
| 37/0001 |
| 37/0003 |

Here, maybe I'm lacking R knowledge?

* First column (without name)

Now, to get it without the column name:

#+begin_src R :var df=table :colnames no
df[, 1]
#+end_src

#+results:
| ID  |
| 26/0163 |
| 37/0001 |
| 37/0003 |

It's not much better, as I don't expect ID to be printed here!

Can you clear up things for me?  Bad R code?  Babel feature?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [ox-latex, bug?] :caption forces environment

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 Do you consider it explicit when no environment is specified?  I would
 /only/ use capt-of when :environment is nil.

I think you are confusing :environment and :float. :environment cannot
be nil.

  ‘:environment’
   Environment used for the table.  It can be set to any LaTeX table
   environment, like ‘tabularx’(1), ‘longtable’, ‘array’, ‘tabu’(2),
   ‘bmatrix’...  It defaults to ‘org-latex-default-table-environment’
   value.


  ‘:placement’
   The ‘:float’ specifies the float environment for the table.
   Possible values are ‘sideways’(3), ‘multicolumn’, ‘t’ and ‘nil’.
   When unspecified, a table with a caption will have a ‘table’
   environment.  Moreover, the ‘:placement’ attribute can specify the
   positioning of the float.  Note: ‘:placement’ is ignored for
   ‘:float sideways’ tables.

We could use captof with a caption and :float nil.

 That would be nice, I guess.  Then I could also use #+CAPTION which is
 arguably nicer than #+attr_latex :caption.

Indeed.

Regards,

Re: [O] [ox-latex, bug?] :caption forces environment

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Do you consider it explicit when no environment is specified?  I would
 /only/ use capt-of when :environment is nil.

 I think you are confusing :environment and :float. :environment cannot
 be nil.

I think you are right.

 We could use captof with a caption and :float nil.

Yeah, that makes perfect sense.

—Rasmus

-- 
Need more coffee. . .

Re: [O] External compilation

[Rasmus]

Sebastien Vauban sva-n...@mygooglest.com
writes:

 One side question.

 I guess that you meant --kill-emacs above (I don't see any function
 called kill); but, anyway, why do you need to kill Emacs?  Isn't that
 redundant with the --batch option?

Googles told me to put it there.  I obeyed.

In my experience it has no effect.

—Rasmus

-- 
You people at the NSA are becoming my new best friends!

Re: [O] [ANN] org-link-edit.el --- Slurp and barf with Org links

[Suvayu Ali]

On 19 February 2015 at 06:24, Kyle Meyer k...@kyleam.com wrote:
 Rasmus ras...@gmx.us wrote:
 Kyle Meyer k...@kyleam.com writes:

 remove description words like Paredit lets you do with S-expressions.
 I've put these Paredit-inspired slurping and barfing commands for Org
 link descriptions in org-link-edit.el

 That's so need!

 Did you/will you add it to contrib?

 I'm glad you think it looks useful.  I haven't added it contrib (I don't
 have push access and wasn't sure if others would be interested), but I'd
 be happy for it to be in contrib.

I think this is a great addition to contrib/.  Great command names, btw ;).

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] External compilation

[Sebastien Vauban]

Rasmus wrote:
 Sebastien Vauban writes:

 One side question.

 I guess that you meant --kill-emacs above (I don't see any function
 called kill); but, anyway, why do you need to kill Emacs?  Isn't
 that redundant with the --batch option?

 Googles told me to put it there.  I obeyed.

 In my experience it has no effect.

I have the same both experiences (Google + no effect). Thanks for
confirming!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] External compilation

[Sebastien Vauban]

Hi Rasmus,

Rasmus wrote:
 I want to translate some documents to pdf.  I'm currently doing it with
 something like this

 OX-FUN= emacs --batch --no-init-file --load conf.el $1 --funcall $2 
 --kill
 OX-LATEX  = $(call OX-FUN, $1, org-latex-export-to-pdf)

One side question.

I guess that you meant --kill-emacs above (I don't see any function
called kill); but, anyway, why do you need to kill Emacs?  Isn't that
redundant with the --batch option?

Best regards,
  Seb

-- 
Sebastien Vauban

[O] [ox-latex, bug?] :caption forces environment

[Rasmus]

Hi,

Consider this example:

#+ATTR_LATEX: :environment nil :center nil :caption cap
| t |

Exporting to latex, it produces:

\begin{table}[htb]
cap
\begin{tabular}{l}
\toprule
t\\
\bottomrule
\end{tabular}
\end{table}

I'd expect:

cap
\begin{tabular}{l}
\toprule
t\\
\bottomrule
\end{tabular}

The real usecase is that I want to use \captionof{table}{my caption}.

I can try to fix it myself later if that's better.

—Rasmus

-- 
. . . The proofs are technical in nature and provides no real understanding

Re: [O] key binding for org-inlinetask-insert-task has gone missing?

[Rasmus]

Eric S Fraga e.fr...@ucl.ac.uk writes:

 Hello all,

 Please ignore my previous email.  I have rebuilt org and restarted emacs
 and everything is back to normal.  I don't know why a particular key
 binding disappeared but maybe it was a cosmic ray incident :)

 [[http://xkcd.com/378/]]

For what it is worth, I also sometimes lose the binding of inlinetasks and
I don't know what causes it...

-- 
I hear there's rumors on the, uh, Internets. . .

Re: [O] Citation syntax: a revised proposal

[Richard Lawrence]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:


 I wasn't clear. Subtype should be interpreted by back-ends means it has
 no impact on syntax. However a user should be able to dictate what the
 back-end should do with it, much like `org-add-link-type'.

 A new library, e.g. org-cite.el would provide all the tools necessary
 to build custom handlers for subtypes. Thus, power users can do whatever
 they want with cite objects.

Ah, OK, I think I see...so this is basically the second option, with
users interpreting subtypes via a separate protocol, instead of via
filters.  Right?

What about this concern, then?

 But that kind of situation is exactly what the extra-info part
 of the syntax is for; in that case,

   [cite/my-subtype: ...] 

 would just be an exceptional way of writing

   [cite: ...]{:type my-subtype}

 or whatever.  I'm not totally convinced yet that the convenience of the
 former is worth blurring the line between `stuff that definitely works
 on all backends' and `stuff that might not work on all backends'.


 We have already seen a couple of examples in this thread of properties
 that one might want to specify in a backend-agnostic way:
   - special-case capitalization
   - user-defined type/command/label/etc.

 Other things one might want to do include:
   - indicating when a citation should be placed in a footnote 
   - extracting arbitrary bibliographic field(s)

 I disagree. These properties should be associated to the subtype.
 Having two places to set them is asking for trouble.

 IMO, there is little incentive to define a set of options for a single
 use. Creating a dedicated subtype /once/ makes more sense.

Hmm, OK.  I agree in the abstract, but as far as I understand what a
`subtype' is, I am not sure how well that idea applies in this case.  If
a subtype encompasses a set of options, and the only way to specify
those options is by specifying a subtype, then changing one option means
changing to a whole different subtype, even when you want all the other
options to stay the same.  That will lead to a lot of duplication in
subtypes.  That in turn could lead to a lot of author frustration: now I
have to remember exactly which subtype encompasses the set of options I
need for this particular citation.

Look at the LaTeX citation commands.  There, you have a different
`type'/command for every possible combination of options, and there are
many commands because there are many options to deal with special cases.
In my mind, that is the wrong abstraction to emulate.  You end up making
trips to the manual to figure out exactly which one you need.  

To me, it makes much more sense to have a basic citation command, and
then a way to `answer some questions' to toggle various things related
to special-case behavior, like:
  - should it be footnoted?
  - should it have special-case capitalization?
  - should it cite the volume?
  - should it deal with brackets in a context-sensitive manner?
  - should it use the genitive form of the author's name?
  - ...

I would guess that the answers to these questions *usually* have nothing
to do with one another, so it makes sense to be able to answer them
independently, and change your answer to one independently of your
answers to the others.  That's why I would want to be able to write

[cite: ...]{:footnoted t :capitalized t :author-title t ...}
 
rather than

[cite/footnoted-capitalized-author-title: ...]

In the former case, if I later figure out I don't need the `:capitalized
t' part, that's easy to remove without changing the other options.  In
the latter case, I need to remember what name I gave to the subtype for
footnoted-but-not-capitalized-author-titles, or whatever.

I don't know; maybe this is not a very serious concern in practice.
Maybe, in practice, you generally only need one `special case' option at
a time, so the number of subtypes will be small.  Still, I do not feel
comfortable declaring *in advance* that that is so; and the bewildering
array of LaTeX citation commands is at least some evidence that it
isn't.  Thus, I am in favor of allowing the greater flexibility provided
by the former syntax.

That's not to say that subtypes never make sense: you are quite right
that sometimes options *should* be grouped together into a subtype,
namely, when it makes sense to set or remove them *conjointly*.  But
that means the two syntaxes above actually have different purposes, even
though for some range of cases either one would do the job. 

So although I would not be in favor of *only* allowing

[cite/subtype: ...]

I am basically OK with allowing this if we also allow the {:key val ...}
syntax.  Still, the /subtype form is not needed if we also allow

[cite: ...]{:type subtype}

Best,
Richard

Re: [O] [ox-latex, bug?] :caption forces environment

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 We could use captof with a caption and :float nil.

You would also be able to do this with the awful float-package using the
H :placement, though I guess it's still a float (so I don't know if it
would work in e.g. minipage). 

AFAIK, we use float actively at one place, namely ;; Case 1.  No source
fontification.  Of org-latex-src-block.  In that particular case I guess
we could also use capt-of, actually.

At some point I wanted to get rid of float, until I became aware that
capt-of doesn't ensure that floats/non-floats appear in the right order.

-- 
Summon the Mothership!

Re: [O] [patch, ox-latex] better hyperref and title options

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 Pushed.

Thank you.

Regards,

Re: [O] [patch] better(?) indention for cdlatex-environment

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 Oh, I pushed this by accident (damn).  Should I revert it?

 http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=14a9510ce1b5535906ceb6a93238e132964fd45f

No, but you cannot let cl-loop and cl-incf in the code, since we still
support Emacs 23.

Regards,

Re: [O] Parent path for links

[Kyle Meyer]

Christian Wittern cwitt...@gmail.com wrote:
[...]
 Look at Section 4.6 Link Abbreviations in the manual.  What you would want
 to do is having

 #+LINK: wp ~/working/project

 in your header, than you can reference it as [[wp:your-project.org]] instead
 of [[~/working/project/your-project.org]].

Ahh... neat.  I didn't know about that.  Ignore my answer.

-- 
Kyle

Re: [O] how to get images support in Emacs on Windows?

[Yuri Niyazov]

It's not called image.dll, which may be a source of confusion.

Here are the instructions specifically for PNG images. For each type,
a different DLL is required:

http://stackoverflow.com/questions/2650041/emacs-under-windows-and-png-files

On Thu, Feb 19, 2015 at 3:19 PM, Herbert Sitz hes...@gmail.com wrote:
 I'm trying to use inline images on Windows and (I think?) I've gotten to the
 point where I understand that this is not available with the standard GNU
 Emacs installation on Windows.  My understanding is that I need an
 image.dll that I can put in the bin directory.  I think that comes as part
 of EmacsW32 install, but that install seems to be packaged as a single
 executable, not sure how to get image.dll without running a full install of
 EmacsW32, which I don't think I want.

 So, am I correct in understanding that all I need is that 'image.dll' to get
 inline image support on Windows (I'm running v24.4 of Emacs).  If not, what
 more do I need to do?  And how can I get (or make) a copy of that .dll?

 Thanks,

 Herbert

Re: [O] [patch] better(?) indention for cdlatex-environment

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rasmus ras...@gmx.us writes:

 Oh, I pushed this by accident (damn).  Should I revert it?

 http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=14a9510ce1b5535906ceb6a93238e132964fd45f

 No, but you cannot let cl-loop and cl-incf in the code, since we still
 support Emacs 23.

Color me confused.

E.g. org-latex--find-verb-separator or org-get-outline-path also uses
cl-loop (or at least loop which is an alias for cl-loop).

Is incf a recent function or why can you not use it?  Anyway, I don't
particularly mind (setq x (1+ x))...

—Rasmus

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

Re: [O] Parent path for links

[Christian Wittern]

On 2015-02-19 10:55, Giacomo M wrote:
 What happens is that in project.org http://project.org I end up specifying
 a lot of links all starting with ~/working/project/. This is useful as I can
 directly jump from organization to action, or just to switch in a
 quicker way across project files.
 
 I know there is an header arg (i.e. dir) for the path of code execution, but
 I am not aware of anything similar for link referencing.
Look at Section 4.6 Link Abbreviations in the manual.  What you would want
to do is having

#+LINK: wp ~/working/project

in your header, than you can reference it as [[wp:your-project.org]] instead
of [[~/working/project/your-project.org]].

Best, Christian

-- 
Christian Wittern, Kyoto

Re: [O] [patch] better(?) indention for cdlatex-environment

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rasmus ras...@gmx.us writes:

 E.g. org-latex--find-verb-separator or org-get-outline-path also uses
 cl-loop (or at least loop which is an alias for cl-loop).

 `loop' is fine. `cl-loop' is not, at least in Org 8.3. The same goes for
 `incf' instead of `cl-incf'.

Okay.  I removed the prefixes.

—Rasmus

PS: Is that also why the outline prefixes are being added?  It complains
about it when you compile org.

-- 
May the Force be with you

Re: [O] how to get images support in Emacs on Windows?

[Ben]

You can download the corresponding dlls from ezwinports [fn:1]
http://sourceforge.net/projects/ezwinports/files/ and put them into
emacs's `bin` directory.

There are some instructions in the Image support part on page [fn:2]
https://ftp.gnu.org/gnu/emacs/windows/.

[fn:1] http://sourceforge.net/projects/ezwinports/files/
[fn:2] https://ftp.gnu.org/gnu/emacs/windows/

On Fri, Feb 20, 2015 at 7:53 AM, Ista Zahn istaz...@gmail.com wrote:

 You could use http://vgoulet.act.ulaval.ca/en/emacs/windows/ which comes
 bundled with image support (and other stuff that you may or may not want).
 On Feb 19, 2015 6:20 PM, Herbert Sitz hes...@gmail.com wrote:

 I'm trying to use inline images on Windows and (I think?) I've gotten to
 the
 point where I understand that this is not available with the standard GNU
 Emacs installation on Windows.  My understanding is that I need an
 image.dll that I can put in the bin directory.  I think that comes as
 part
 of EmacsW32 install, but that install seems to be packaged as a single
 executable, not sure how to get image.dll without running a full install
 of
 EmacsW32, which I don't think I want.

 So, am I correct in understanding that all I need is that 'image.dll' to
 get
 inline image support on Windows (I'm running v24.4 of Emacs).  If not,
 what
 more do I need to do?  And how can I get (or make) a copy of that .dll?

 Thanks,

 Herbert

Re: [O] how to get images support in Emacs on Windows?

[Ista Zahn]

You could use http://vgoulet.act.ulaval.ca/en/emacs/windows/ which comes
bundled with image support (and other stuff that you may or may not want).
On Feb 19, 2015 6:20 PM, Herbert Sitz hes...@gmail.com wrote:

 I'm trying to use inline images on Windows and (I think?) I've gotten to
 the
 point where I understand that this is not available with the standard GNU
 Emacs installation on Windows.  My understanding is that I need an
 image.dll that I can put in the bin directory.  I think that comes as
 part
 of EmacsW32 install, but that install seems to be packaged as a single
 executable, not sure how to get image.dll without running a full install of
 EmacsW32, which I don't think I want.

 So, am I correct in understanding that all I need is that 'image.dll' to
 get
 inline image support on Windows (I'm running v24.4 of Emacs).  If not, what
 more do I need to do?  And how can I get (or make) a copy of that .dll?

 Thanks,

 Herbert

Re: [O] how to get images support in Emacs on Windows?

[Herbert Sitz]

Ben yfefyf at gmail.com writes:
 
 You can download the corresponding dlls from ezwinports [fn:1] and
put them into emacs's `bin` directory.
 
 There are some instructions in the Image support part on page [fn:2].
 
 [fn:1] http://sourceforge.net/projects/ezwinports/files/
 
 [fn:2] https://ftp.gnu.org/gnu/emacs/windows/
 

Ben, Ista, Yuri -- Thanks for all your help.  I finally got things going by
grabbing the dll's from the ezwinports project and putting them in emacs/bin
directory.  The zlib1.dll was packaged in the libpng zip file so that was
all I needed to get my png images to show.  Like many things was simple once
I knew how to do it.

That StackOverflow answer was on point but was dated; I don't think Emacs 24
will work with the files it mentions there, which are the ones from the
GnuWin32 project.  Turns out all this info was in the Gnu Emacs for Windows
readme/install instructions.  Unfortunately I installed long time ago and
didn't recall that info, and my web searches weren't turning it up.

Thanks for all your help.

-- Herbert

Re: [O] [patch] better(?) indention for cdlatex-environment

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 E.g. org-latex--find-verb-separator or org-get-outline-path also uses
 cl-loop (or at least loop which is an alias for cl-loop).

`loop' is fine. `cl-loop' is not, at least in Org 8.3. The same goes for
`incf' instead of `cl-incf'.


Regards,

Re: [O] [patch] better(?) indention for cdlatex-environment

[Rasmus]

Rasmus ras...@gmx.us writes:

 This is exactly what we want: indent (non empty) lines starting in
 [BEG ; END[. Or am I missing something?

 OK, the missing key is org-indent-line-to.  It works better in this case
 and I can use end.

 Another option: when ENV is inserted the first time, store (e.g., in N)
 how many (forward-line -1) are needed to go back to BEG. At the end of
 the process, move to BEG then (forward-line n). I assume point is always
 left on an empty lines. If it is not the case, you also need to store
 current column, relatively to end of line.

 OK it now does this.

Oh, I pushed this by accident (damn).  Should I revert it?

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=14a9510ce1b5535906ceb6a93238e132964fd45f

—Rasmus

-- 
With monopolies the cake is a lie!

[O] how to get images support in Emacs on Windows?

[Herbert Sitz]

I'm trying to use inline images on Windows and (I think?) I've gotten to the
point where I understand that this is not available with the standard GNU
Emacs installation on Windows.  My understanding is that I need an
image.dll that I can put in the bin directory.  I think that comes as part
of EmacsW32 install, but that install seems to be packaged as a single
executable, not sure how to get image.dll without running a full install of
EmacsW32, which I don't think I want.

So, am I correct in understanding that all I need is that 'image.dll' to get
inline image support on Windows (I'm running v24.4 of Emacs).  If not, what
more do I need to do?  And how can I get (or make) a copy of that .dll?

Thanks,

Herbert