Re: [O] [bug] corrupted export
Did you use Emacs 22? No, 23. Re: being stuck with Carbon Emacs 22 -- I found that plain GNU Emacs 23 compiled perfectly well on my old G4 PowerPC Mac, but I assume you've tried this already. Yours, Christian
Re: [O] some kind of bisect tool
On 26.5.2011, at 00:20, Bernt Hansen wrote: Samuel Wales samolog...@gmail.com writes: Hi Bernt, My proposal is for an Emacs command, not a shell script. The command would load source for org-mode each time and provide a command that the user can use to provide feedback to git interactively. It should ideally not depend on Magit. It should work in Emacs 22 and later versions. Hi Samuel, This sounds more complicated. If you go back in time to when variables weren't created yet your current emacs session will have those already defined (from the later commit you were on). I don't know how (or if) you can clean up the current emacs state without a restart in that case. The few times I've used git bisect run with Emacs org-mode I've used a script with some lisp code to test the conditions in a minimal emacs setup which is safely reproducible. Trying to reuse the current session with an org-reload probably won't work well for the general case. By the way, I am having trouble loading source with c-u c-c c-x ! . I notice that some commands, such as m-s-right, are still compiled. I have no idea what is going on here. I also notice that org-crypt.el does not load when I go to dired, mark all .el, and load all marked files. It says (void-function daemonp) . THis should be fixed now. - Carsten That might or might not be the reason c-u c-c c-x ! fails silently. There might be other issues. Emacs 22. Later versions of Emacs do not work on my computer. Ugh. Sounds painful. (Sorry) Regards, Bernt
Re: [O] org-reload (Re: some kind of bisect tool)
On 26.5.2011, at 04:04, Bernt Hansen wrote: Samuel Wales samolog...@gmail.com writes: On 2011-05-25, Bernt Hansen be...@norang.ca wrote: Trying to reuse the current session with an org-reload probably won't work well for the general case. Perhaps it will work for the cases for which org-reload was designed. By the way, I am having trouble loading source with c-u c-c c-x ! . I notice that some commands, such as m-s-right, are still compiled. I have no idea what is going on here. Org-reload is broken for me and so is loading of *.el. I think org-reload should error when it cannot load a file, and ideally all files would be loadable in any order. Don't know if this is possible. If org-reload has no use, perhaps org-reload should be deleted? But a restart of Emacs is very slow for every git checkout. I use M-x org-reload regularly when upgrading org-mode (instead of restarting Emacs). org-reload is great for moving forwards in the org-mode git history (to newer commits) without restarting Emacs. It's when you go backwards (removing new functionality and definitions) that things get a bit hairy since your current emacs lisp environment will have a mixture of new and old definitions. org-reload now just gets a list of files and loads them sequentially. The function could probably be enhanced to check the status of the load function call and doing something useful when it fails -- but that needs to be thought out. Carsten originally wrote this function and he may have more thoughts about this. org-reload only reloads files that already have been loaded. So if you have not loaded org-crypt yet, it will not be loaded again. I am not sure I remember why I did it like this, probably to solve problems with the sequence of loading. Org-reload is certainly not perfect. Using a minimal Emacs setup and just restart Emacs for the bisecting is probably best. - Carsten Does anyone know if there is a way to Regards, Bernt
Re: [O] Org table with long lines visibility
On 14.5.2011, at 17:14, Johnny wrote: Carsten Dominik carsten.domi...@gmail.com writes: On May 4, 2011, at 7:48 PM, Johnny wrote: ... any way to make the 'org-table-edit-field' to be permanently visible in a buffer, automatically updating while moving around in the table to view the full content of the current cell? this is a good idea, and it is now implemented. C-u C-u C-c C-` Impressive Carsten, thanks a lot for the quick update, I have now upgraded org to the development branch (apologies for the delay in feedback) and tested the feature, and it works great! A minor quirk is that if emptying a cell contents in the field editor and pressing C-c C-c, the cursor will be moved to the next column, but it would be more consistent to remain in the same cell as for any other edits. Yes, this was a bug, fixed now. Thanks. Regards - Carsten Finally, I'll take the opportunity to praise org-mode, a really really outstanding tool for organisation and getting things done, although I have barely scratched the surface yet! Great work, and many thanks! Regards, -- Johnny
Re: [O] org-contacts: error on message startup
Hi Michael Michael Markert markert.mich...@googlemail.com writes: Hi Sven, I run org-contacts on Emacs 23.3, there is a `completion-at-point-functions' and org-contacts works just fine. But I recall myself trying with Gnus and it didn't work because `completion-at-point' was not bound to keys. It is definitely not there in 23.1, the emacs-snapshot package which AFAIK is the orebokech version that seems not to have been updated since quite a while. I have checked the sources of minibuffer.el and it does not define completion-at-point-functions. This is a pity since Emacs Snapshot is the most actual you can get on Ubuntu without adding foreign repos or compiling. I have tried to use Emacs 24 from the emacs.naquadah.org repository which, however, does not contain a Natty section. With the Maverick packages org-contacts works. But in Emacs 24 Gnus is generally buggy (nnimap does not split mails). So I uninstalled it again. The only way I can see at the moment is exchanging minibuffer.el in Emacs 23.1 with a newer version. If this will result in a stable Emacs, I don't know. I had already converted my whole bbdb database to the org-contacts structure without testing it before. So I'm quite frustrated. Greetings, Sven
Re: [O] org-contacts: error on message startup
Hi Sven, On 26 May 2011, Sven Bretfeld wrote: Michael Markert markert.mich...@googlemail.com writes: Hi Sven, I run org-contacts on Emacs 23.3, there is a `completion-at-point-functions' and org-contacts works just fine. But I recall myself trying with Gnus and it didn't work because `completion-at-point' was not bound to keys. It is definitely not there in 23.1, the emacs-snapshot package which AFAIK is the orebokech version that seems not to have been updated since quite a while. I have checked the sources of minibuffer.el and it does not define completion-at-point-functions. Oh I didn't say that, just, that it happened before Emacs 24. Digging furher, you need (at least) Emacs 23.2: , Emacs Changelog | * Editing Changes in Emacs 23.2 | | snip | | ** Completion changes | | *** The new command `completion-at-point' provides mode-sensitive completion. ` So you could try the Emacs 23.2/23.3 `minibuffer.el' compared to a Emacs 24 version it should be more suitable. Good Luck, Michael pgpZTlVskgENw.pgp Description: PGP signature
Re: [O] org-beamer feaure request : single frame background
suvayu ali fatkasuvayu+li...@gmail.com writes:
You can try (untested):
#+LATEX: { %}
* This is a frame
The commented out closing brace is important. Otherwise the exporter
gets confused.
#+LATEX: }
This will not work as it is by definition inserted between
\begin{frame}...\end{frame}
like thus:
\begin{frame}
.
{
\end{frame}
\begin{frame}
.
}
\end{frame}
I think it it possible to write a function that prepends
{\myfunction..etc and appends } to the frame environment.
For the time being a property like BEAMER_BG: myfile.jpg could be
harvested and transformed into:
{
\setbeamertemplate{background canvas}{
\includegraphics[width=\paperwidth]{./myfile.jpg}
\begin{frame}
.
\end{frame}
}
The latex code could be a bit more elaborate and the image placement
attributes need some automagic, but as a proof of concept, this will do.
I do think I need a little help with this though, as I have no clue
about org's inner workings.
But let's take it one step at a time, like how does one harvest the
BEAMER_BG: myfile.jpg property ?
sndr
--
Me thinks:
You have an unusual equipment for success. Be sure to use it properly.
Re: [O] org babel support for tcl and awk
Hi Eric,
Eric Schulte wrote:
As you can see, I did not really mean any concurrent execution. Simply
being able to execute parts of code in-situ, in the Org buffer, to document
(and test) what I'm writing.
And to be able to assemble all the parts in one single script file, by the
means of literate programming.
I see, you want to be able to construct a large pipe chain STDOUTSTDIN,
That's it!
but you don't care if the parts of the chain (e.g., the code block) execute
in serial or concurrently (as they do in the shell).
For me, there is no concept of serial or concurrent execution here, as I am
executing manually the calls, when writing the Org document.
Not sure to understand you...
Are you talking of what happens for the export, maybe?
Are you talking of the shell constructs which will be used in the way the
full script is assembled?
The attached patch (can be applied with git am) implements this
behavior as I understand it. The result is a new :stdin header argument
with which org-mode references can be passed to shell scripts as
standard input. Given the technique used in this patch, I'll probably
re-write part of ob-awk.el.
Your patch is simply wonderful. It completely meets my need! Thanks a lot.
Look with the updated (and, now working) example of yesterday.
* Abstract
This script americanizes a European CSV file.
* Sample data
The following is a sample CSV file:
#+results: sample-csv
#+begin_example
Date;Amount;Account
28-05-2010;-6.806,25;999-1974050-30
04-06-2009;420,00;999-1500974-23
24-02-2009;-54,93;999-1974050-30
#+end_example
This input data will be used to show what the results of the transformations
are.
* Script
What the script must do is:
** Convert the date in American format
Convert the date in =MM/DD/= format.
#+srcname: convert-date
#+begin_src sh :stdin sample-csv :results output :exports both
sed -r 's/^([[:digit:]]{2})-([[:digit:]]{2})-([[:digit:]]{4})/\2\/\1\/\3/g'
#+end_src
#+results: convert-date
#+begin_example
Date;Amount;Account
05/28/2010;-6.806,25;999-1974050-30
06/04/2009;420,00;999-1500974-23
02/24/2009;-54,93;999-1974050-30
#+end_example
** Convert the separators
Apply the following operations in order to americanize the CSV file received
from the bank:
- remove the dot used as thousands separator (=.= - ==)
- replace the comma used as decimal separator by a dot (=,= - =.=)
- replace other commas by a dot (=,= - =.=)
- replace the semi-comma used as field separator by a comma (=;= - =,=)
#+srcname: convert-separators
#+begin_src sh :stdin convert-date :results output :exports both
sed -r 's/([[:digit:]])\.([[:digit:]]{3})/\1\2/g' |\
sed -r 's/([[:digit:]]),([[:digit:]]{2})/\1.\2/g' |\
sed -r 's/,/./g' |\
sed -r 's/;/,/g'
#+end_src
#+results: convert-separators
#+begin_example
Date,Amount,Account
05/28/2010,-6806.25,999-1974050-30
06/04/2009,420.00,999-1500974-23
02/24/2009,-54.93,999-1974050-30
#+end_example
* Full code
The script is then:
#+begin_src sh :tangle americanize-csv.sh :noweb yes
#!/bin/bash
# americanize-csv.sh -- Convert CSV file to American format
# Usage: americanize-csv FILE.CSV
cat $1 |\
convert-date |\
convert-separators
exit 0
# americanize-csv.sh ends here
#+end_src
* Conclusions
The new =stdin= option allows one to:
- execute parts of code in-situ, in the Org buffer, documenting (and testing)
them.
- assemble all the parts in one single script file, by the means of literate
programming.
Go for applying it!
Thanks a lot, Eric, for your time.
Best regards,
Seb
--
Sébastien Vauban
Re: [O] org-contacts: error on message startup
On Wed, May 25 2011, Sven Bretfeld wrote: Debugger entered--Lisp error: (void-variable completion-at-point-functions) add-to-list(completion-at-point-functions org-contacts-message-complete-function) (lambda nil (add-to-list (quote completion-at-point-functions) (quote org-contacts-message-complete-function)))() run-hooks(text-mode-hook message-mode-hook) apply(run-hooks (text-mode-hook message-mode-hook)) run-mode-hooks(message-mode-hook) message-mode() message-pop-to-buffer(*mail* nil) message-mail() gnus-group-mail(nil) call-interactively(gnus-group-mail nil nil) Have I missed a point in the setup? I just added (require 'org-contacts) and threw out all bbdb related code from .emacs and .gnus.el. Is there anything else to do? I've pushed a fix so you won't get the error in Emacs 23.3. But you won't get the completion neither. That would require writing a different completion function, which I don't plan to do soon. -- Julien Danjou ❱ http://julien.danjou.info pgp3A3Vll3ZUS.pgp Description: PGP signature
Re: [O] org-contacts: error on message startup
On Thu, May 26 2011, Sven Bretfeld wrote: It is definitely not there in 23.1, the emacs-snapshot package which AFAIK is the orebokech version that seems not to have been updated since quite a while. I have checked the sources of minibuffer.el and it does not define completion-at-point-functions. orebokech version is dead. This is a pity since Emacs Snapshot is the most actual you can get on Ubuntu without adding foreign repos or compiling. emacs-snapshot in Ubuntu is a joke. I have tried to use Emacs 24 from the emacs.naquadah.org repository which, however, does not contain a Natty section. With the Maverick packages org-contacts works. The Maverick ones should work flawlessly on Natty anyhow, as you discovered. -- Julien Danjou ❱ http://julien.danjou.info pgpz7mChjEtZe.pgp Description: PGP signature
Re: [O] org babel support for tcl and awk
Go for applying it! Great, happy it works. I've just pushed this up to the git repository. Thanks a lot, Eric, for your time. Its my pleasure. Best -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] org babel support for tcl and awk
Eric Schulte schulte.e...@gmail.com writes: Eric S Fraga e.fr...@ucl.ac.uk writes: Eric Schulte schulte.e...@gmail.com writes: [...] As an example, I've worked up an very simple ob-awk.el file from ob-template.el, it is attached along with an example org-mode file which demonstrates its usage. Eric, this is great to see as I use awk quite often. What is involved in extending this to be able to run an awk script on input from within the org file (output of another babel block, for instance, as my typical use of awk is to re-arrange output from another program...)? Or, if you wish, can you suggest one of the ob-XXX modules that best illustrates how to do this and I can give it a try? I've made a quick change so that any variable named stdin is treated specially, in that, rather than using its value to replace strings of $stdin in the text of the awk code, the value of the stdin variable is saved into the file processed by awk. This allows awk to operate over Org-mode references. See the attached example file. If babel code block supported a pipe or an actual stdin header argument, that would be the ideal way to add this behavior, but currently nothing of that nature exists. Please let me know if this misses part of your suggestion, or more generally what else may be advisable before we add this to the core. I've now added ob-awk.el to the Org-mode core. The newest version incorporates some change inspired by recent work with Sebastien, notably :stdin is now its own header argument, rather than a special variable name. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] bug: org-sort-list, `f'
Hello, Le Wang l26w...@gmail.com writes: patch fixes sorting lists with custom getkey-func. Bug was trying to evaluate getkey-func while setting it, so it was always nil. Indeed ! I've applied a slightly modified version of your patch. Thank you for reporting this and providing the patch. Regards, -- Nicolas Goaziou
Re: [O] org babel support for tcl and awk
Eric Schulte schulte.e...@gmail.com writes: [...] I've now added ob-awk.el to the Org-mode core. The newest version incorporates some change inspired by recent work with Sebastien, notably :stdin is now its own header argument, rather than a special variable name. Best -- Eric Thanks Eric. My apologies for not trying out your interim solution but I have been bogged down by marking examination scripts... the temptation to play with org + babel had to be resisted! Anyway, from the discussion in this thread related to stdin for sh scripts, it sounds like the final solution is cleaner and more consistent! Thanks again, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.311.g5c1cc)
[O] Problem with make and autoloads
Hello list, Recently, autoloads ceased to work in my local org-mode installation. My typical update routine is to: 1. Pull the most recent changes into my local org-mode repository, located at ~/org-mode. 2. Run make clean make. My .emacs file contains the following lines: --8---cut here---start-8--- (add-to-list 'load-path ~/org-mode/lisp) (require 'org-install) --8---cut here---end---8--- Note: I have replicated the problem using an .emacs file containing *only* those lines. When I call an autoloaded function, such as org-capture, I receive the following error: Debugger entered--Lisp error: (file-error Cannot open load file lisp/org-capture) execute-extended-command(nil) call-interactively(execute-extended-command nil nil) The autoloads in org-install all have lisp/ prepended to the file name. Here is an example: --8---cut here---start-8--- (autoload 'org-capture lisp/org-capture \ --8---cut here---end---8--- This causes problems since there is no ~/org-mode/lisp/lisp/org-capture.el. In the past, the autoloads in org-install.el looked like this: --8---cut here---start-8--- (autoload 'org-capture org-capture \ --8---cut here---end---8--- Adding ~/org-mode to the load path allows emacs to find the files correctly, but this is a temporary workaround. (The manual instructs one to add the lisp directory to the org path---not the top level of the distribution directory.) Any insights into why the autoloads are being generated this way? Is anyone else experiencing the same issue? I have downloaded a new version of the distribution to ensure that no local changes to the Makefile are involved. Note: I am using a recent version of bzr emacs, but the problem also occurred when compiling org-mode with emacs 23.2. Thanks, Matt
Re: [O] org-beamer feaure request : single frame background
I see the limitation of my suggestion one now. I guess the only way is
option two then.
On Thu, May 26, 2011 at 3:08 AM, Sander Boer sanderb...@yahoo.com wrote:
I think it it possible to write a function that prepends
{\myfunction..etc and appends } to the frame environment.
For the time being a property like BEAMER_BG: myfile.jpg could be
harvested and transformed into:
{
\setbeamertemplate{background canvas}{
\includegraphics[width=\paperwidth]{./myfile.jpg}
\begin{frame}
.
\end{frame}
}
The latex code could be a bit more elaborate and the image placement
attributes need some automagic, but as a proof of concept, this will do.
I do think I need a little help with this though, as I have no clue
about org's inner workings.
But let's take it one step at a time, like how does one harvest the
BEAMER_BG: myfile.jpg property ?
This page from the manual might help you.
http://orgmode.org/manual/Using-the-property-API.html#Using-the-property-API
A combination of getting the properties with the property API and
adding your own function in the post export hook might be the easiest
solution here.
sndr
Good luck, and do post back to the list if you find a solution, I
would be interested.
--
Suvayu
Open source is the future. It sets us free.
[O] [Babel][Bug] Inconsistent output from babel function depending on how called
I'd like to call a simple babel code block to generate org-code If I define a list thusly: #+results: list1 - foo - bar Then I define a code block thusly, and execute it by C-c C-c on the source line. That yields the desired result: a sequence of headings under #+results: print_list. #+source: print_list(lst=list1) #+begin_src sh :results output org for i in $lst; do echo * $i done #+end_src #+results: print_list #+BEGIN_ORG * foo * bar #+END_ORG Now I want to reuse the code block to generate other sequences of headings. But even if I call it with the *same* list, instead of the desired headings, I get a literal, as below. #+call: print_list(lst=list1) #+results: print_list(lst=list1) : * foo : * bar I think this qualifies as a bug---surely the method of calling the code block shouldn't affect the output? Thoughts, patches, or work-arounds welcomed! Thanks, -Ethan -- Ethan Ligon, Associate Professor Agricultural Resource Economics University of California, Berkeley
Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called
Ethan Ligon li...@are.berkeley.edu writes: I'd like to call a simple babel code block to generate org-code If I define a list thusly: #+results: list1 - foo - bar Then I define a code block thusly, and execute it by C-c C-c on the source line. That yields the desired result: a sequence of headings under #+results: print_list. #+source: print_list(lst=list1) #+begin_src sh :results output org for i in $lst; do echo * $i done #+end_src #+results: print_list #+BEGIN_ORG * foo * bar #+END_ORG Now I want to reuse the code block to generate other sequences of headings. But even if I call it with the *same* list, instead of the desired headings, I get a literal, as below. #+call: print_list(lst=list1) #+results: print_list(lst=list1) : * foo : * bar I think this qualifies as a bug---surely the method of calling the code block shouldn't affect the output? No, this is expected (if possibly under-documented behavior). The :results header arguments are associated with the code block and *not* with the #+call line. To get the desired behavior, you must specify the :results header argument on the #+call: line thusly. #+call: print_list(lst=list1) :results output org Best -- Eric Thoughts, patches, or work-arounds welcomed! Thanks, -Ethan -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called
No, this is expected (if possibly under-documented behavior). The :results header arguments are associated with the code block and *not* with the #+call line. To get the desired behavior, you must specify the :results header argument on the #+call: line thusly. #+call: print_list(lst=list1) :results output org Best -- Eric Hi, I recently made the same mistake, and it took me a while to figure things out. I had assumed #+CALLs inherited all the header arguments from the code blocks they referenced. Regarding documentation, I see now that the correct behavior is at least implicitly documented in the first example at [[info:org#Header%20arguments%20in%20function%20calls]]. It might rate an explicit explanation at [[info:org#Evaluating%20code%20blocks]] as well, though. Yours, Christian
Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called
So, the :result output org ought to be associated with the *call*, not with the function. That makes good sense. But perhaps it still doesn't work quite as it ought... On Thu, May 26, 2011 at 11:46 AM, Eric Schulte schulte.e...@gmail.com wrote: Ethan Ligon li...@are.berkeley.edu writes: I'd like to call a simple babel code block to generate org-code If I define a list thusly: #+results: list1 - foo - bar Then I define a code block thusly, and execute it by C-c C-c on the source line. That yields the desired result: a sequence of headings under #+results: print_list. #+source: print_list(lst=list1) #+begin_src sh :results output org for i in $lst; do echo * $i done #+end_src #+results: print_list #+BEGIN_ORG * foo * bar #+END_ORG Now I want to reuse the code block to generate other sequences of headings. But even if I call it with the *same* list, instead of the desired headings, I get a literal, as below. #+call: print_list(lst=list1) #+results: print_list(lst=list1) : * foo : * bar I think this qualifies as a bug---surely the method of calling the code block shouldn't affect the output? No, this is expected (if possibly under-documented behavior). The :results header arguments are associated with the code block and *not* with the #+call line. To get the desired behavior, you must specify the :results header argument on the #+call: line thusly. #+call: print_list(lst=list1) :results output org If I do this, I get #+results: print_list(lst=list1) #+END_ORG #+BEGIN_ORG which is surprising first because there's no proper output, but also because the end and begin tags are reversed (!). What *does* work is to omit the output header argument. #+call: print_list(lst=list1) :results org #+results: print_list(lst=list1) #+BEGIN_ORG * foo * bar #+END_ORG So now I definitely have a good work-around, but still think there's a bug. Thanks, -Ethan -- Ethan Ligon, Associate Professor Agricultural Resource Economics University of California, Berkeley
Re: [O] [dev] footnotes improvements
Hello, I've updated some changes that should hopefully fix most issues reported in this thread. git pull -f may be required. The footnotes are completely fontified again. Again, feedback is more than welcome. Regards, -- Nicolas Goaziou
Re: [O] org-contacts: error on message startup
Hi Julien Julien Danjou jul...@danjou.info writes: On Thu, May 26 2011, Sven Bretfeld wrote: It is definitely not there in 23.1, the emacs-snapshot package which AFAIK is the orebokech version that seems not to have been updated since quite a while. I have checked the sources of minibuffer.el and it does not define completion-at-point-functions. orebokech version is dead. This is a pity since Emacs Snapshot is the most actual you can get on Ubuntu without adding foreign repos or compiling. emacs-snapshot in Ubuntu is a joke. Yes, and I was a silly victim of that joke. Today I noticed for the first time that the normal Emacs 23 packages coming with Ubuntu are actually newer than Emacs Snapshot. With the normal Emacs 23 packages (23.2) org-contacts is working! Including the completion functions (one still has manually to define tab as completion-at-point in message-modemap). Julien, thank you very much for org-contacts. I'm looking forward to its further development (as I'm just a normal user I'm sorry to be unable to contribute very much). Greetings, Sven
Re: [O] [dev] footnotes improvements
I am eagerly awaiting these. Just curious for the git experts: are there git tricks to make it so we don't have to maintain a clone but instead a local branch?
Re: [O] [dev] footnotes improvements
Hi Samuel, On Thu, May 26, 2011 at 1:56 PM, Samuel Wales samolog...@gmail.com wrote: I am eagerly awaiting these. Just curious for the git experts: are there git tricks to make it so we don't have to maintain a clone but instead a local branch? $ cd org-mode/ $ git remote add nicolas git://orgmode.org/org-mode.git $ git remote update nicolas This should do it. :) And you can check the state of the local and remote branches with git log: $ git log --oneline --graph --decorate --all Hope this helps. PS: Note that every time Nicolas rebases his branch, you have force update your copy. -- Suvayu Open source is the future. It sets us free.
Re: [O] Passing font size to exported LaTeX table
Hello,
On Wed, May 25, 2011 at 12:22 AM, Thomas S. Dye t...@tsdye.com wrote:
#+LaTeX_HEADER: \usepackage{scripttab}
* foo
What's this?
#+tblname: foo
#+CAPTION: foo
| table | here |
|---+--|
| table | here |
What's this?
I think this works OK.
Nick
Aloha Nick,
This works like a charm. Thanks!
Although this is solved now, I found a very simple solution.
e.g. for footnotesize just add the line:
#+ATTR_LaTeX: placement=[options]\footnotesize
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called
On Thu, May 26, 2011 at 12:17 PM, Christian Moe m...@christianmoe.com wrote: No, this is expected (if possibly under-documented behavior). The :results header arguments are associated with the code block and *not* with the #+call line. To get the desired behavior, you must specify the :results header argument on the #+call: line thusly. #+call: print_list(lst=list1) :results output org Best -- Eric Hi, I recently made the same mistake, and it took me a while to figure things out. I had assumed #+CALLs inherited all the header arguments from the code blocks they referenced. Regarding documentation, I see now that the correct behavior is at least implicitly documented in the first example at [[info:org#Header%20arguments%20in%20function%20calls]]. It might rate an explicit explanation at [[info:org#Evaluating%20code%20blocks]] as well, though. I'd be happy to help with the documentation, but I still don't understand the behavior. It seems as though some arguments to :results need to be supplied to the code block, but others have to be supplied to the call. In my situation, the org option to :results has to be supplied to the call, while the output option has to be supplied to the code block. What's the logic? Here's my setup: #+results: list1 - Item1 - Item2 #+results: list2 - Item3 - Item4 #+source: print_list(lst) #+begin_src sh for i in $lst; do echo * $i done #+end_src Here's a way of calling that works #+call: print_list[:results output](lst=list1) :results org #+results: print_list[:results output](lst=list1) #+BEGIN_ORG * Item1 * Item2 #+END_ORG but this way of calling doesn't #+call: print_list[:results output org](lst=list2) #+results: print_list[:results output org](lst=list2) : * Item3 : * Item4 and neither does this way #+call: print_list[:results org](lst=list2) :results output #+results: print_list[:results org](lst=list2) or this way #+call: print_list(lst=list2) :results output org #+results: print_list(lst=list2) #+END_ORG #+BEGIN_ORG Thanks for any enlightenment! -Ethan -- Ethan Ligon, Associate Professor Agricultural Resource Economics University of California, Berkeley
Re: [O] [bug, babel] export corruption bug and 3 more bugs
At Wed, 25 May 2011 09:58:03 -0700, Samuel Wales wrote: Minimal .emacs and test case for export corruption bug. Okay, I can reproduce the args out of range with Emacs 22. Turns out that `regexp-opt` behaves different when creating `org-babel-result-regexp'. (regexp-opt org-babel-data-names) encloses the regexp for babel data names in a shy grouping construct in Emacs 23 (regexp-opt org-babel-data-names) = \\(?:DATA\\|RES\\(?:NAME\\|ULTS\\)\\|TBLNAME\\) While it does not in Emacs 22 (regexp-opt org-babel-data-names) = DATA\\|RES\\(?:NAME\\|ULTS\\)\\|TBLNAME Thus the literal string results in the example file is matched by Org Babel in `org-exp-res/src-name-cleanup'. Looks like setting up `org-babel-result-regexp' should do a check for the Emacs version and explictly add the shy grouping construct if version 23 -- I'm really not familar with all the Babel parts so Cc: Erik Schulte who I assume knows Babel better than me. I'll check the other (compatibilty) problems during the weekend. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpUXy07SC2eF.pgp Description: PGP signature
