[O] #+CALL get the first row of output table lost when using latex export
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
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
Aloha Pete, Pete Ley peteley11...@gmail.com 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
Hi, Pete Ley peteley11...@gmail.com 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
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 f...@miszellen.de 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
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 emac...@gmail.com
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 closein 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
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 emac...@gmail.com 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
On Fri, 14 Nov 2014, Nicolas Goaziou wrote:
Charles C. Berry ccbe...@ucsd.edu 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 fn
- :wrap wrapper
- :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
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
Hello, Florian Beck f...@fbeck.net 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
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
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 http://orgmode.org/worg/worg-git.html. TINYCHANGE You don't need that for Worg. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] inline src block results can be removed
Hello,
Aaron Ecay aarone...@gmail.com 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
Aloha Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr 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
