[O] #+CALL get the first row of output table lost when using latex export

[iemacs]

Hi,

I encounter a problem when I use #+CALL to create a table with latex
export.  The problem is that the first row of the table is missing, if
the table is created with #+CALL.

My Emacs version is GNU Emacs 24.4.3 (x86_64-apple-darwin13.4.0,
Carbon Version 157 AppKit 1265.21) of 2014-11-04 on Atago.local.  The
Org-mode version is: 8.2.10 from orgmode.org homepage.

I start emacs -q -l emacs.minimal, where emacs.minimal is
#+BEGIN_EXAMPLE
(add-to-list 'load-path (expand-file-name "~/myconfig/org-8.2.10/lisp"))
(add-to-list 'auto-mode-alist '("\\.\\(org\\  |org_archive\\|txt\\)$"
. org-mode))

(add-to-list 'load-path (expand-file-name "~/myconfig/org-8.2.10/contrib/lisp"))

(org-babel-do-load-languages
 'org-babel-load-languages
 '((python . t)
   (latex . t)))
#+END_EXAMPLE

The minimal table example is

#+BEGIN_EXAMPLE
#+NAME: t1
#+BEGIN_SRC python :exports results
  return [['A'],None,[2]]
#+END_SRC

#+CAPTION: T1
#+RESULTS: t1

#+NAME: t2
#+CALL: t1() :exports results

#+CAPTION: T2
#+RESULTS: t2
#+END_EXAMPLE

The latex output of Table T1 is:

#+BEGIN_EXAMPLE
\begin{table}[htb]
\caption{T1}
\centering
\begin{tabular}{r}
A\\
\hline
2\\
\end{tabular}
\end{table}
#+END_EXAMPLE

The latex output of Table T2 is:

#+BEGIN_EXAMPLE
\begin{table}[htb]
\caption{T2}
\centering
\begin{tabular}{r}
2\\
\end{tabular}
\end{table}
#+END_EXAMPLE

Compare with the latex output of the two tables, the first row and the
\hline in the first table is missing in the second one.


Kind regards,

Tian Qiu

[O] Float placement in org-latex

[Pete Ley]

Just a quick question for someone new to and quickly becoming enamored
with org-latex-export. 

I'm encountering a problem with my floats. Namely, I have a section with
not much text and several floats, it's probably about a page worth of
actual text and 7-10 gnuplot-generated graph images. I have the gnuplot
code inline in the text and the images are included from the #+RESULTS. 

My problem is that LaTeX keeps pushing them farther down the page until
some of them are at the end, after the appendices. Is there a way I can
maybe shrink the images to make them fit or force it to render them
inline even if it leaves some blank space on the page? I wouldn't mind
making them all quite small and having text flow around them but I'd
rather not have to put in these settings for each and every graph. Can I
do this as a default setting for all of them?

Is there a set of best practices for this kind of thing? Sorry if this
is a beginner question, but I haven't had much luck searching.

Re: [O] Float placement in org-latex

[Thomas S. Dye]

Aloha Pete,

Pete Ley  writes:

> Just a quick question for someone new to and quickly becoming enamored
> with org-latex-export. 
>
> I'm encountering a problem with my floats. Namely, I have a section with
> not much text and several floats, it's probably about a page worth of
> actual text and 7-10 gnuplot-generated graph images. I have the gnuplot
> code inline in the text and the images are included from the #+RESULTS. 
>
> My problem is that LaTeX keeps pushing them farther down the page until
> some of them are at the end, after the appendices. Is there a way I can
> maybe shrink the images to make them fit or force it to render them
> inline even if it leaves some blank space on the page? I wouldn't mind
> making them all quite small and having text flow around them but I'd
> rather not have to put in these settings for each and every graph. Can I
> do this as a default setting for all of them?
>
> Is there a set of best practices for this kind of thing? Sorry if this
> is a beginner question, but I haven't had much luck searching.

I think the variable you might want is
org-export-latex-image-default-option, which you can set in your .emacs,
or on a per-file basis, see
http://lists.gnu.org/archive/html/emacs-orgmode/2010-02/msg00355.html.

The problem you're describing with floats collecting at the end of a
document is a fact of life in LaTeX, and is often caused by one
too-large image.  One way is to set a smaller size for the image, and another
is to ensure that [p] is one of the letters in the placement
attribute--this lets a float appear on its own page.

hth,
Tom

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

Re: [O] Float placement in org-latex

[Rasmus]

Hi,

Pete Ley  writes:

> Just a quick question for someone new to and quickly becoming enamored
> with org-latex-export. 
>
> I'm encountering a problem with my floats. Namely, I have a section with
> not much text and several floats, it's probably about a page worth of
> actual text and 7-10 gnuplot-generated graph images. I have the gnuplot
> code inline in the text and the images are included from the #+RESULTS. 
>
> My problem is that LaTeX keeps pushing them farther down the page until
> some of them are at the end, after the appendices. Is there a way I can
> maybe shrink the images to make them fit or force it to render them
> inline even if it leaves some blank space on the page? I wouldn't mind
> making them all quite small and having text flow around them but I'd
> rather not have to put in these settings for each and every graph. Can I
> do this as a default setting for all of them?
>
> Is there a set of best practices for this kind of thing? Sorry if this
> is a beginner question, but I haven't had much luck searching.

Maybe you want to check the placeins package if they are pushed to far
away.  Further there's placement options h, H, p that may be of
interest to you.

You can access graphicx options using #+ATTR_LATEX as described in the
manual:

(info "(org) LaTeX specific attributes")

Hope it helps,
Rasmus

-- 
Together we will make the possible totay impossible!

[O] [PATCH] Fix error when inserting into diary from agenda

[Florian Beck]

Hi,

emacs trunk dropped some old aliases. This patch fixes it.

-- 
Florian Beck

>From e2188e0fb3fe322146a9950bfff74773dd54018a Mon Sep 17 00:00:00 2001
From: Florian Beck 
Date: Sat, 15 Nov 2014 19:14:27 +0100
Subject: [PATCH 9/9] Replace obsolete aliases of calendar functions.

* lisp/org-agenda.el (org-agenda-diary-entry): Replace obsolete functions.
---
 lisp/org-agenda.el | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 97970a6..2b5a8ec 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9526,13 +9526,13 @@ entries in that Org-mode file."
 		   (message "Diary entry: [d]ay [w]eekly [m]onthly [y]early [a]nniversary [b]lock [c]yclic")
 		   (read-char-exclusive)))
 	   (cmd (cdr (assoc char
-			'((?d . insert-diary-entry)
-			  (?w . insert-weekly-diary-entry)
-			  (?m . insert-monthly-diary-entry)
-			  (?y . insert-yearly-diary-entry)
-			  (?a . insert-anniversary-diary-entry)
-			  (?b . insert-block-diary-entry)
-			  (?c . insert-cyclic-diary-entry)
+			'((?d . diary-insert-entry)
+			  (?w . diary-insert-weekly-entry)
+			  (?m . diary-insert-monthly-entry)
+			  (?y . diary-insert-yearly-entry)
+			  (?a . diary-insert-anniversary-entry)
+			  (?b . diary-insert-block-entry)
+			  (?c . diary-insert-cyclic-entry)
 	   (oldf (symbol-function 'calendar-cursor-to-date))
 	   ;; (buf (get-file-buffer (substitute-in-file-name diary-file)))
 	   (point (point))
-- 
1.9.1

Re: [O] patch to add new link type "infoi" that leverages Info-index command

[Richard Y. Kim]

Hi Nicolas,

Thanks for your feedback.  Attached is new patch which incorporates all
your suggestions except the following:

> Not directly related to your patch, but shouldn't it be
>
>   (user-error "Could not open: %s" name)

I'm not sure what you mean by this.  Do you mean that the verb "open" is
more approrpriate than "find" in the error message, i.e., "Could not
open" rather than "Could not find"?  If so, then it seems like "find" is
more appropriate since "open" seems like there was a problem with
opening a file when the problem is that a particular node was not found
after successfully opening a file.  Please let me know if I
misunderstood.  Thanks again for your valuable feedbacks.

>From 16c25b88043f6f84c6d3df14ca3018040a09fe25 Mon Sep 17 00:00:00 2001
From: Kim 
Date: Sat, 15 Nov 2014 10:37:39 -0800
Subject: [PATCH] org-info: try info index if info node is not found

* lisp/org-info.el (org-info-follow-link): Attempt index lookup if node
  lookup fails.

* doc/org.texi (External links): Update info links.

Info index is almost always finer grain than info nodes.  For example
with this change, [[info:libc#close]] brings up not only
"(libc)Opening and Closing Files" info node, but also place the cursor
on the line that documents "close" function within the node.  This is
done by looking up "close"in the index upon failing to find a node
named "close".  Hence one can now link function, variable and other
names that are in the index rather than being limited to info node
names.  Typically there are far more index items than there are node
names.  For example libc manual has about 700 nodes, but over 4000
concept, type, function, and variables index items.  More examples of
new ways to create links are shown using org.info as example

- [[info:org#org-clock-idle-time]] uses "Variable Index"
- [[info:org#org-capture]] uses "Command and Function Index".
- [[info:org#timestamp]] uses "Main Index"
- [[info:org#C-c C-c]] uses "Key Index"

TINYCHANGE
---
 doc/org.texi |  2 +-
 lisp/org-info.el | 15 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index b01db2c..fcaee0c 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3575,7 +3575,7 @@ gnus:group@r{Gnus group link}
 gnus:group#id @r{Gnus article link}
 bbdb:R.*Stallman  @r{BBDB link (with regexp)}
 irc:/irc.com/#emacs/bob   @r{IRC link}
-info:org#External links   @r{Info node link}
+info:org#External links   @r{Info node or index link}
 shell:ls *.org@r{A shell command}
 elisp:org-agenda  @r{Interactive Elisp command}
 elisp:(find-file-other-frame "Elisp.org") @r{Elisp form to evaluate}
diff --git a/lisp/org-info.el b/lisp/org-info.el
index 8a2d717..7c828a6 100644
--- a/lisp/org-info.el
+++ b/lisp/org-info.el
@@ -67,11 +67,18 @@
   "Follow an Info file and node link specified by NAME."
   (if (or (string-match "\\(.*\\)[#:]:?\\(.*\\)" name)
   (string-match "\\(.*\\)" name))
-  (progn
+  (let ((filename (match-string 1 name))
+	(nodename-or-index (or (match-string 2 name) "Top")))
 	(require 'info)
-(if (match-string 2 name) ; If there isn't a node, choose "Top"
-(Info-find-node (match-string 1 name) (match-string 2 name))
-  (Info-find-node (match-string 1 name) "Top")))
+	;; If nodename-or-index is invalid node name, then look it
+	;; up in the index.
+	(condition-case nil
+	(Info-find-node filename nodename-or-index)
+	  (user-error (Info-find-node filename "Top")
+		  (condition-case nil
+			  (Info-index nodename-or-index)
+			(user-error (format "Could not find '%s' node or index entry" 
+	nodename-or-index))
 (message "Could not open: %s" name)))
 
 (provide 'org-info)
-- 
1.9.1

[O] [PATCH] org-contribute: fix a type by changing "column" to "colon"

[Richard Y. Kim]

Attached patch fixes a typo and also removes trailing white spaces.

The white spaces were removed due to adding a hook to remove them as
shown here:

(defun kimr-before-save-hook ()
  "Delete trailing white spaces only in a few modes."
  (when (eq major-mode 'org-mode)
(delete-trailing-whitespace)))

(add-hook 'before-save-hook 'kimr-before-save-hook)

Please let me know if trailing white spaces should not be removed in
general so that I will omit such changes in future patches.
Thanks.

>From 06bb6361813dad0f1ac111c573f5dd325c47d9e7 Mon Sep 17 00:00:00 2001
From: Kim 
Date: Sat, 15 Nov 2014 10:58:25 -0800
Subject: [PATCH] org-contribute: fix a type by changing "column" to "colon"

* worg/org-contribute.org: fixed a typo.  Also removed trailing white
  spaces in 8 lines.

TINYCHANGE
---
 org-contribute.org | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/org-contribute.org b/org-contribute.org
index cbcee3f..c763b25 100644
--- a/org-contribute.org
+++ b/org-contribute.org
@@ -4,7 +4,7 @@
 #+OPTIONS:H:3 num:nil toc:t \n:nil ::t |:t ^:t -:t f:t *:t tex:t d:(HIDE) tags:not-in-toc
 #+STARTUP:align fold nodlcheck hidestars oddeven lognotestate
 #+SEQ_TODO:   TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
-#+TAGS:   Write(w) Update(u) Fix(f) Check(c) 
+#+TAGS:   Write(w) Update(u) Fix(f) Check(c)
 #+LANGUAGE:   en
 #+PRIORITIES: A C B
 #+CATEGORY:   worg
@@ -34,7 +34,7 @@ where your contribution will be useful:
 
 - you can submit *patches* -- You can submit patches to the mailing
   list.  See the [[For Org contributors: preferred way of submitting patches][Preferred way of submitting patches]] section for
-  details.  You can run =make test= to check that your patch does 
+  details.  You can run =make test= to check that your patch does
   not introduce new bugs.
 
   If your patch is against a file that is part of Emacs, then your
@@ -42,7 +42,7 @@ where your contribution will be useful:
   15 lines/ (See the [[http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/etc/CONTRIBUTE][etc/CONTRIBUTE file in GNU Emacs]].)  If you
   contribute more, you have to assign the copyright of your
   contribution to the Free Software Foundation (see below).
-  
+
 - you can submit Org *add-ons* -- there are many Org add-ons.
   - The best way is to submit your code to [[file:org-mailing-list.org][the mailing list]] to discuss
 it with people.
@@ -271,7 +271,7 @@ A commit message should be constructed in the following way:
 - Line 1 of the commit message should always be a short description of
   the overall change.  Line 1 does /not/ get a dot at the end and does
   not start with a star.  Generally, it starts with the filename that
-  has been changed, followed by a column.
+  has been changed, followed by a colon.
 
 - Line 2 is an empty line.
 
@@ -283,7 +283,7 @@ A commit message should be constructed in the following way:
   : (org-timer-set-timer): Use the number of minutes in the Effort
   : property as the default timer value. Three prefix arguments will
   : ignore the Effort value property.
- 
+
 - After the changelog, another empty line should come before any
   additional information that the committer wishes to provide in order
   to explain the patch.
@@ -307,18 +307,18 @@ Here is an example for such a message:
 
 #+begin_example
   org-capture.el: Fix the case of using a template file
-  
+
   ,* lisp/org-capture.el (org-capture-set-plist): Make sure txt is a
   string before calling `string-match'.
   (org-capture-templates): Fix customization type.
 
   ,* doc/org.texi (Capture): Document using a file for a template.
-  
+
   The problem here was that a wrong keyword was given in the
   customization type.  This let to a string-match against a list value.
-  
+
   Modified from a patch proposal by Johan Friis.
-  
+
   TINYCHANGE
 #+end_example
 
-- 
1.9.1

Re: [O] [PATCH] inline src block results can be removed

[Charles C. Berry]

On Fri, 14 Nov 2014, Nicolas Goaziou wrote:


"Charles C. Berry"  writes:


More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
are patched.


Thanks.



[skipping to the bottom - omitting useful critiques of code and
 opinions about strategy and tactics from Nicolas]


WDYT?


After staring at `org-babel-insert-result' for too long, I am beginning to 
feel like Alice in Wonderland. As currently implemented, inline src blocks 
are somewhere between fragile and broken.  I worry about making them even 
more fragile, the logic in `org-babel-insert-result' has plenty of twists 
ans turns, and I cannot commit the effort to dig deeply into them. So I am 
looking for an easy way out.


For now, I'd be willing to make patches that will allow removal of the
inline src block results that do *not* involve these header args:

- :file 
- :wrap 
- :results latex html drawer org code

which I can do barely touching `org-babel-insert-result' and this
simplifies matters a lot.

I propose to do this by using the patches of ox.el and ob-exp.el from
my last post. For ob-core.el, I would

- leave defcustom org-babel-inline-wrap as "=%s=" (or use defconst - I
  do not have a strong opinion either way).
- allow replacement of exising results in `org-babel-insert-result'
  like so
  #+BEGIN_EXAMPLE
- (existing-result (unless inlinep
-(org-babel-where-is-src-block-result
+ (existing-result (if inlinep
+(org-babel-delete-results-macro)
+(org-babel-where-is-src-block-result
  #+END_EXAMPLE
  and defun `org-babel-delete-results-macro' per Nicolas' suggestions
  for `org-babel-delete-babel-snippet' (from earlier patch) to use
  `org-element-context' and friends (and not mess with export
  snippets).
- modify `org-babel-examplify-region' along these lines
  #+BEGIN_SRC emacs-lisp
(insert
 (replace-regexp-in-string
  "," "\\,"
  (format
   (concat "{{{results("
   org-babel-inline-result-wrap
   ")}}}"
   (prog1 (buffer-substring beg end)
 (delete-region beg end
  nil t))

  #+END_SRC


I believe that this is simple enough to avoid breaking idioms that
folks might use now.

As for the choice between "=%s=" and "%s", the latter was hard coded
until f285b7ed3d097dd1cbb55fa3c31bc92aa0149054 in February 2013 and
has been the default since. It also parallels what happens with
handling src block results. Going forward I do not think this
behavior should change.

I have too litle experience with #+MACROs to know if Aaron's
suggestion to let the user customize the macro is opening up potential
issues when users get `creative'.

I can do what I've outlined in the coming days.

If it is felt that more retooling of `org-babel-insert-results' is really 
needed, I can get to it early next year. In fact, I'll be out of email 
range from late this month till then, so any problems I create now will 
have to wait till then for me to work on them.


Thanks for the critique of my earlier patches and your thoughts.

Best,

Chuck

Re: [O] Problem with footnote in html export

[Nicolas Goaziou]

Hello,

t...@tsdye.com (Thomas S. Dye) writes:

> With the following org file, exporting the subtree to html gives this:
>
> ,--
> | org-html-footnote-reference: Format specifier doesn't match argument type
> `--

This is not related to ox-html, but

[...]

> #+AUTHOR: Tom Dye[fn:1]

You are using a footnote in a keyword, which is not supported by ox.el.
I don't think it should be either, because this data is too "volatile"
(it may or may not be present in the output, possibly messing with
footnote order, etc.).


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Fix error when inserting into diary from agenda

[Nicolas Goaziou]

Hello,

Florian Beck  writes:

> emacs trunk dropped some old aliases. This patch fixes it.

Applied. Thank you.

> Subject: [PATCH 9/9] Replace obsolete aliases of calendar functions.

Nitpick: no final dot on summary lines. I modified the commit message.


Regards,

-- 
Nicolas Goaziou

Re: [O] patch to add new link type "infoi" that leverages Info-index command

[Nicolas Goaziou]

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

> Thanks for your feedback.  Attached is new patch which incorporates all
> your suggestions

Applied. Thank you.

> except the following:
>
>> Not directly related to your patch, but shouldn't it be
>>
>>   (user-error "Could not open: %s" name)
>
> I'm not sure what you mean by this.  Do you mean that the verb "open" is
> more approrpriate than "find" in the error message, i.e., "Could not
> open" rather than "Could not find"?  If so, then it seems like "find" is
> more appropriate since "open" seems like there was a problem with
> opening a file when the problem is that a particular node was not found
> after successfully opening a file.  Please let me know if I
> misunderstood.  Thanks again for your valuable feedbacks.

This is simpler than that. I was just saying that (user-error ...) was
probably more appropriate than (message ...) in the last line of the
function. I changed that in another patch.

> Subject: [PATCH] org-info: try info index if info node is not found

Nitpick: Missing capitals after the colons. I fixed it in the patch.
> + (user-error (format "Could not find '%s' node or index 
> entry" 
> + nodename-or-index))

I changed this to (user-error "Could not ..." nodename-or-index) since
`format' is not necessary.


Regards,

Re: [O] [PATCH] org-contribute: fix a type by changing "column" to "colon"

[Nicolas Goaziou]

Hello,

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

> Attached patch fixes a typo and also removes trailing white spaces.

Applied. Thank you.
>

[...]

> Please let me know if trailing white spaces should not be removed in
> general so that I will omit such changes in future patches.
> Thanks.

In general, you only remove trailing white spaces from lines or function
you actually modify. However, we're talking about Worg here, where there
is no formal rule about patches and commit messages.

You can send your SSH public key to Bastien if you want to further
improve Worg. See .

> TINYCHANGE

You don't need that for Worg.

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] inline src block results can be removed

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> This is a step back from the present situation, where a user can get
> a custom format applied by default to all inline results by setting
> ‘org-babel-inline-result-wrap’.  I think it’s reasonable for users to
> want to set off babel results in a special font (to indicate that
> they are automatically generated, e.g.)  This proposal would add an
> additional overhead for generating this formatting to every inline
> call.

I expect Babel to provide a parameter to generate verbatim output, and
a way to use this parameter globally. If it doesn't, then we can keep
`org-babel-inline-result-wrap' and simply wrap {{{results(...)}}} macro
around the output.

> I think the method I sketched above will allow users to redefine the
> results macro in the same way as any other macro (via #+MACRO), thus
> allowing the possibility of user-specified special formatting.

Babel output is expected to be modified by Babel functions/variables.
I wouldn't want to see macro used as the main tool to modify inline
Babel output.

Of course, you can still do it. But you're on your own.
{{{results(...)}}} is just a wrapper.

> Indeed, this seems correct.  (The “const” designation is just a hint to
> users/developers – it doesn’t affect the ability of people who really
> want to customize the value to setq it to something else in their init
> file.)

Of course, users are free to break their local copy of Org.

>> With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even
>> if it is more verbose, I think a regular syntax is better.
>
> This doesn’t mesh with the suggestion to allow the results macro to
> supply formatting.

See above.


Regards,

-- 
Nicolas Goaziou

Re: [O] Problem with footnote in html export

[Thomas S. Dye]

Aloha Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> With the following org file, exporting the subtree to html gives this:
>>
>> ,--
>> | org-html-footnote-reference: Format specifier doesn't match argument type
>> `--
>
> This is not related to ox-html, but
>
> [...]
>
>> #+AUTHOR: Tom Dye[fn:1]
>
> You are using a footnote in a keyword, which is not supported by ox.el.
> I don't think it should be either, because this data is too "volatile"
> (it may or may not be present in the output, possibly messing with
> footnote order, etc.).

OK.  Thanks.

Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com