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 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 writes: > >> On 2011-05-25, Bernt Hansen 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 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] Completing with anything
26/05/11 04:23, Stefan Monnier >>> Another is to do it more selectively, flag some of >>> completion-at-point-functions as "not-exclusive", meaning that if >>> completion fails with those we should keep trying with subsequent >>> functions. E.g. the nick completion in rcirc could be flagged as >>> non-exclusive since it applies everywhere, which in turn would let >>> your dabbrev-expand kick in when nick-completion fails. > >> This seems to be the most flexible, while still keeping all the >> completions in the same UI. I'd make the non-exclusive behaviour the >> default though: let the functions that want to "take over" the >> completion state it explicitely. > > I actually much prefer the it the other way around. > Most completion-at-point-functions should be pretty specific, checking > the context to decide whether they should be used at point, so they can > be exclusive. > Can you try the patch below to see if it gives you back the old behavior > in ERC? > > > Stefan > > > === modified file 'lisp/erc/erc-pcomplete.el' > --- lisp/erc/erc-pcomplete.el 2011-04-29 15:23:59 + > +++ lisp/erc/erc-pcomplete.el 2011-05-26 02:12:19 + > @@ -73,7 +73,10 @@ >"ERC completion data from pcomplete. > for use on `completion-at-point-function'." >(when (> (point) (erc-beg-of-input-line)) > -(pcomplete-completions-at-point))) > +(or (let ((pcomplete-default-completion-function #'ignore)) > + (pcomplete-completions-at-point)) > +(nconc (pcomplete-completions-at-point) > + '(:exclusivity 'non-exclusive) There's a double quoting here that messes up the test (took me a while to figure out why 'non-exclusive was not equal to non-exclusive ...). Also, the (let ((pcomplete-default-completion-function #'ignore)) (pcomplete-completions-at-point)) check always return non-nil, so I removed it for testing purposes (not sure what your intent was here). With these two modifications, it runs fine (that is, using the old calling convention and just using (setq-default completion-at-point-functions '(my-dabbrev-expand))) > > (defun erc-pcomplete () >"Complete the nick before point." > > === modified file 'lisp/minibuffer.el' > --- lisp/minibuffer.el2011-05-24 02:45:50 + > +++ lisp/minibuffer.el2011-05-26 02:16:05 + > @@ -1436,9 +1436,13 @@ > `:predicate' a predicate that completion candidates need to > satisfy.") > > (defvar completion--capf-misbehave-funs nil > - "List of functions found on `completion-at-point-functions' that > misbehave.") > + "List of functions found on `completion-at-point-functions' that misbehave. > +These are functions that neither return completion data nor a completion > +function but instead perform completion right away.") > (defvar completion--capf-safe-funs nil > - "List of well-behaved functions found on `completion-at-point-functions'.") > + "List of well-behaved functions found on `completion-at-point-functions'. > +These are functions which return proper completion data rather than > +a completion function or god knows what else.") > > (defun completion--capf-wrapper (fun which) >;; FIXME: The safe/misbehave handling assumes that a given function will > @@ -1451,9 +1455,23 @@ > (optimist (not (member fun completion--capf-misbehave-funs >(let ((res (funcall fun))) > (cond > - ((consp res) > + ((and (consp res) (not (functionp res))) >(unless (member fun completion--capf-safe-funs) > -(push fun completion--capf-safe-funs))) > +(push fun completion--capf-safe-funs)) > + (and (eq 'non-exclusive (plist-get (nthcdr 3 res) :exclusivity)) > + ;; FIXME: Here we'd need to decide whether there are > + ;; valid completions against the current text. But this > depends > + ;; on the actual completion UI (e.g. with the default > completion > + ;; it depends on completion-style) ;-( > + ;; We approximate this result by checking whether prefix > + ;; completion might work, which means that non-prefix > completion > + ;; will not work (or not right) for completion functions that > + ;; are non-exclusive. > + (null (try-completion (buffer-substring-no-properties > + (car res) (point)) > + (nth 2 res) > + (plist-get (nthcdr 3 res) :predicate))) > + (setq res nil))) > ((not (or (listp res) (functionp res))) >(unless (member fun completion--capf-misbehave-funs) > (message
Re: [O] org-contacts: error on message startup
Hi Michael Michael Markert 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 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 | | | | ** 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 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 STDOUT>STDIN,
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 |\
<> |\
<>
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 writes: > Eric S Fraga writes: > >> Eric Schulte 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 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 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 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 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 wrote: > Ethan Ligon 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 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 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 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=[]\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 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
Re: [O] Passing font size to exported LaTeX table
suvayu ali writes:
> Hello,
>
> On Wed, May 25, 2011 at 12:22 AM, Thomas S. Dye 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=[]\footnotesize
Aloha Suvayu,
And this works, too. Thanks!
Can I ask where you found this simple solution?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
