lesser-than as open paren
Hi,
when taking notes in plain org-mode, run into trouble for instance with
this scala-snippet:
def scalaFiles =
for {
file <- filesHere
if file.getName.endsWith(".scala")
} yield file
With cursor on lesser-than sign, get a type-mismatch.
The culprit resides in org.el:
(modify-syntax-entry ?< "(>")
(modify-syntax-entry ?> ")<")
Maybe use this modification only when a special case requires it?
Thanks,
Andreas
Re: bug#51167: 29.0.50; org-indent-line broken
On 13.10.21 14:59, Max Nikulin wrote: On 13/10/2021 01:35, Kévin Le Gouguec wrote: Andreas Röhler writes: With following stuff in org-mode buffer: * bla asd M-x org-indent-line RET on second line has no effect. Andreas, do the following settings make behavior consistent with you expectations? (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1))) (setq org-adapt-indentation t) Thanks. That works for me. Still thinking a command "indent" should indent.
bug#51167: 29.0.50; org-indent-line broken
On 13.10.21 09:34, Kévin Le Gouguec wrote: Andreas Röhler writes: Sounds like a chain of confusion. A command called "indent-line" definitely should indent. org-indent-line indents just like every indentation function in every other major mode: if the syntactic convention calls for it, it indents or de-indents the current line; otherwise it leaves the line untouched. Or are you saying you would like org-indent-line to also indent "* bla", because « a command called "indent-line definitely should indent »? Seems the original coulprit is that unhappy switch of RET and C-j, in order to make Emacs "modern". "Modern" did not factor in; the goal was to have RET and C-j behave consistently in all major modes. That does not deliver an argument to change the meaning of RET. BTW the costs of such changes are terribly underestimated in Emacs. Maybe make RET RET again? After much discussion on emacs-orgmode, it has been found that a lot of users expect neither (1) their prose to be indented, nor (2) RET to indent. Since electric-indent-mode is enabled globally in Emacs, Which IMO was another mistake. Preferring a clean editor, which does fancy things only if enabled. RET indents according to the major mode's indentation rules. Thus it was decided to change the default value of org-adapt-indentation, to reflect the expectations of the Org users who took the time to chime in on the mailing list to describe their workflow and expectations. If you think the default value should be reverted back to t, I suggest you make your case on emacs-orgmode.
bug#51167: 29.0.50; org-indent-line broken
On 12.10.21 20:35, Kévin Le Gouguec wrote: Andreas Röhler writes: With following stuff in org-mode buffer: * bla asd M-x org-indent-line RET on second line has no effect. Org 9.5 changed the default value of org-adapt-indentation from t to nil, as that seemed to be what a lot of users expect[1], so org-indent-line should not indent the second line in Emacs 28 onward unless configured otherwise: - setting org-adapt-indentation back to t will make Org indent by inserting whitespace; - alternatively, enabling org-indent-mode will make Org "soft-indent" with text properties. [1] Org 9.4 made RET and C-j obey electric-indent-mode like they do in most other major modes. Since org-adapt-indentation was t by default, this led to many dismayed reports on emacs-orgmode that "RET now messes up indentation", indicating that these users did not expect their prose to be indented. Sounds like a chain of confusion. A command called "indent-line" definitely should indent. Seems the original coulprit is that unhappy switch of RET and C-j, in order to make Emacs "modern". Maybe make RET RET again?
Re: Bug: org-babel python with :results value sends function definition with a statement after a for loop to the shell incorrectly [9.3.6 (9.3.6-elpa @ /home/username/.emacs.d/elpa/org-9.3.6/)]
On 01.07.20 18:55, Philip Blagoveschensky wrote:
#+begin_src python :session bug_report
def foobar():
for i in range(5):
pass
print "hello world"
foobar()
#+end_src
Works here like this:
#+begin_src python :results output
def foobar():
for i in range(5):
pass
print("hello world")
foobar()
#+end_src
#+RESULTS:
: hello world
GNU Emacs 28.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.14.5,
cairo version 1.14.0) of 2020-06-10
ical2org.awk
Hi, thanks providing ical2org.awk. When running on Debian8 however, encountered a bunch of errors: awk: ./ical2org.awk: line 394: function strftime never defined awk: ./ical2org.awk: line 394: function gensub never defined awk: ./ical2org.awk: line 394: function gensub never defined awk: ./ical2org.awk: line 394: function mktime never defined awk: ./ical2org.awk: line 394: function gensub never defined Turns out had to install gawk. After changing the shebang accordingly it worked. Just FYI, thanks again, Andreas, GNU Emacs 28.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.14.5, cairo version 1.14.0) of 2020-04-06
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
, On 20.02.20 06:45, stardiviner wrote: Hi, python-mode.el developer here. Since python.el is built-in to Emacs, I think that things should continue to work for python-mode.el users, even if we entirely switch over to only using python.el. Thanks supporting python-mode.el. Both python-modes should not conflict - except for the key-setting, which is taken by the last one loaded: py-mode-map didn't work for some reasons, so both provide now python-mode-map. The only thing I'm not sure about, is whether the equivalent of "python-shell-send-region" in python-mode.el will work with shells started by python.el. If not, this could probably be addressed with a patch to python-mode.el. It should work. Will check it. Please feel free to send a bug-report resp. feature request to https://gitlab.com/python-mode-devs/python-mode/issues in case of python-mode.el related stuff. You could test this by explicitly setting `org-babel-python-mode' to `python' (it is probably set to `python-mode' on your system, which is the default when python-mode.el is detected). I'll add a TODO for myself to explicitly mark python-mode-related variables as deprecated. I'm also planning a major update to the Worg documentation of ob-python when 9.4 comes out, and will mention the deprecation there as well. Thanks for your work! Jack - -- [ stardiviner ] BTW there are some reasons, why python-mode.el still exists: no known indentation bugs, finer navigation commands etc. Maybe have a look at open python.el bugs and check them against python-mode.el Best, Andreas
[O] bug: copyright-sign not printed
#+BEGIN_SRC python :results output print(u'\\xA9') #+END_SRC #+RESULTS: : \xA9 AFAUI cause in in calling org-babel--shell-command-on-region, line 108 of ob-eval.el (process-file shell-file-name input-file where python is run through a bash. While in a Emacs python-shell print(u'\xA9') works nicely. Thanks, Andreas
[O] bug#25466: 25.1.91; hs-show-all broken
On 17.01.2017 20:29, Glenn Morris wrote: Andreas Röhler wrote: With org-mode, hs-minor-mode: hs-show-all has no effect, but"Showing all blocks ... done" is messaged. BTW M-x show-all RET works as expected. I don't think hideshow has ever done anything useful in Org mode, which is Outline-based. Perhaps you are asking for a new feature of some kind. Thanks, that seems the case. ;) Close?
Re: [O] fill paragraph: break after sentence.
On 06.09.2016 10:23, Uwe Brauer wrote: Hello I would like to modify the auto-fill function such that after every sentence a new line starts like this In order to prove our nonlinear instability result, we want to use the linear growing mode in Proposition to construct small initial data for the nonlinear problem. Since we are involved in the higher-order regularity context, we cannot simply set the initial data for the nonlinear problem to be a small constant times the linear growing modes. I know about functions doing that for auctex, but does anybody know about a similar functionality for orgmode? Uwe Brauer In use here is ar-forward-sentence-atpt as part of thing-at-point-utils toolkit https://github.com/andreas-roehler/werkstatt/tree/master/thing-at-point-utils
Re: [O] bug#22597: [25.0.90.1] org-table-import docu
On 08.02.2016 21:51, Rasmus wrote: Hi Andreas, Thanks for your report. Andreas Röhler <andreas.roeh...@easy-emacs.de> writes: saying: The file is assumed to be tab-separated While internally org-table-convert-region is used receiving optional argument SEPARATOR: \(4) Use the comma as a field separator \(16) Use a TAB as field separator ;;; Thus docu should mention the comma as possible separator. Isn't it covered by the following line? regexp When a regular expression, use it to match the separator Which version you are checking against? Here it org-table-import docu continues: ;;; Such files can be produced by most spreadsheet and database applications. If no tabs (at least one per line) are found, lines will be split on whitespace into fields. ;;; The initial sentence is just wrong, as TAB is only one thing tried - there are a lot more. See docu of org-table-convert-region for details.
[O] Filling headers refused
Hi, when using org-mode taking notes --separated by stars-- M-q refuses to take action, as it doesn't fill headers. Any solution? Thanks, Andreas
Re: [O] babel python example not reproducible
On 19.06.2014 15:40, Eric Schulte wrote: Andreas Röhler andreas.roeh...@easy-emacs.de writes: On 18.06.2014 15:59, Eric Schulte wrote: Shiyuan gshy2...@gmail.com writes: Hi all, I found a solution to fix the echo problem of the emacs python shell: http://stackoverflow.com/questions/8060609/python-interpreter-in-emacs-repeats-lines That is, in the Interior Python buffer, do M-: (setq comint-process-echoes t) ;; or nil Now, if I enter command directly in the interior python buffer, the command is not echoed and this is what I want. However, When I evaluate the python src code block in org-mode(by `C-c C-c`), the problem persists. I notice every time I evaluate the block, I see 'org_babel_python_eoe' in the interior python buffer. I stumbled on a very strange emacs behavior. When I fiddled around, at some point, I produced the correct answer as the manual. I thought I got the right setup, but when I saved everything and restarted emacs, problem persists. Will it be a sign of anything wrong? What's even stranger is that: the evaluation for the first time gives different results from the evaluation for the second time, on exactly the same src_block: This is what I got when I evaluation the code block for the first time: - #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: #+begin_example x=100 print hello hello 2 2 print bye bye #+end_example --- --- The following is what I got when I evaluate the same block again: #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: : x=100 : print hello : hello : 2 : 2 : print bye : bye : : Notice that the prompt symbol is in the result for the first evaluation but not in the second evaluation. This issue has been raised before, it is a quirk of how the python session starts up. I think we've done what we can to handle this on the Org-mode side, I'd ask for a fix on the python.el maintainers. The prompts appear as respond from Python-process when setup-code is sent at the beginning. org-babel already knows how to fetch only the results from last prompt. Probably separating a first run-python/py-shell from execute-process would do it. I don't follow the above with sufficient clarity to implement your suggestion. Could you provide a patch to the `org-babel-python-initiate-session-by-key' function? Hi Eric, was asked off-list not to send patches... Sorry, Andreas
Re: [O] babel python example not reproducible
On 18.06.2014 15:59, Eric Schulte wrote: Shiyuan gshy2...@gmail.com writes: Hi all, I found a solution to fix the echo problem of the emacs python shell: http://stackoverflow.com/questions/8060609/python-interpreter-in-emacs-repeats-lines That is, in the Interior Python buffer, do M-: (setq comint-process-echoes t) ;; or nil Now, if I enter command directly in the interior python buffer, the command is not echoed and this is what I want. However, When I evaluate the python src code block in org-mode(by `C-c C-c`), the problem persists. I notice every time I evaluate the block, I see 'org_babel_python_eoe' in the interior python buffer. I stumbled on a very strange emacs behavior. When I fiddled around, at some point, I produced the correct answer as the manual. I thought I got the right setup, but when I saved everything and restarted emacs, problem persists. Will it be a sign of anything wrong? What's even stranger is that: the evaluation for the first time gives different results from the evaluation for the second time, on exactly the same src_block: This is what I got when I evaluation the code block for the first time: - #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: #+begin_example x=100 print hello hello 2 2 print bye bye #+end_example --- --- The following is what I got when I evaluate the same block again: #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: : x=100 : print hello : hello : 2 : 2 : print bye : bye : : Notice that the prompt symbol is in the result for the first evaluation but not in the second evaluation. This issue has been raised before, it is a quirk of how the python session starts up. I think we've done what we can to handle this on the Org-mode side, I'd ask for a fix on the python.el maintainers. The prompts appear as respond from Python-process when setup-code is sent at the beginning. org-babel already knows how to fetch only the results from last prompt. Probably separating a first run-python/py-shell from execute-process would do it. Best, Andreas
Re: [O] babel python example not reproducible
On 17.06.2014 08:21, Shiyuan wrote: Hi all, I found a solution to fix the echo problem of the emacs python shell: http://stackoverflow.com/questions/8060609/python-interpreter-in-emacs-repeats-lines That is, in the Interior Python buffer, do M-: (setq comint-process-echoes t) ;; or nil Now, if I enter command directly in the interior python buffer, the command is not echoed and this is what I want. However, When I evaluate the python src code block in org-mode(by `C-c C-c`), the problem persists. I notice every time I evaluate the block, I see 'org_babel_python_eoe' in the interior python buffer. I stumbled on a very strange emacs behavior. When I fiddled around, at some point, I produced the correct answer as the manual. I thought I got the right setup, but when I saved everything and restarted emacs, problem persists. Will it be a sign of anything wrong? What's even stranger is that: the evaluation for the first time gives different results from the evaluation for the second time, on exactly the same src_block: This is what I got when I evaluation the code block for the first time: - #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: #+begin_example x=100 print hello hello 2 2 print bye bye #+end_example --- --- The following is what I got when I evaluate the same block again: #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: : x=100 : print hello : hello : 2 : 2 : print bye : bye : : Notice that the prompt symbol is in the result for the first evaluation but not in the second evaluation. Also the result is not embedded in the #+being_example/#+end_example for the second evaluation. I want to hunt down the problem. Any hints/helps is greatly appreciated. Shiyuan Hi Guys, please permit a comment after some times - it's just not to create heroes :) IMHO the complexity orb-babel took by creating its own slots for symbols like function names, variables etc. is not to handle reliably across the languages. A net and simple way out would be just to employ commands delivered by existing Emacs modes on org-source sections. Inserting the results might be provided by a hook. Cheers, Andreas
Re: [O] Babel python question: use of ipython and %cpaste
Am 03.12.2013 07:08, schrieb Arun Persaud: Hi being able to use python as a source block is great, but I often stumble over the fact that when using sessions you have to treat empty lines in a special way (i.e. as the end of an indentation block). I was wondering if it would be easy to create an ipython mode, something like #+BEGIN_SRC ipython ... where the content for a session is copied over to an ipython buffer using the ipython magic %cpaste. This way empty lines should be treated correctly. Using the magic command, as shown in Rasmus' answer, should work. If not, as for python-mode.el, please file a bug-report at https://bugs.launchpad.net/python-mode
[O] [RFC] defcustom sorting-type
In docstring of `org-sort-entries' it's told The command prompts for the sorting type unless it has been given to the function through the SORTING-TYPE argument, which needs to be a character, \(?n ?N ?a ?A ?t ?T ?s ?S ?d ?D ?p ?P ?o ?O ?r ?R ?f ?F). Suggest to extend it somehow like that way ... through the SORTING-TYPE argument, resp. customized `sorting-type',... Which means `sorting-type' would need a defcustom. Thus the user isn't prompted every time any more. Thanks, Andreas
[O] broken names
Hi all, as I have to deal with different Emacs versions, notice several name-changes, which break my code. Are you sure `org-forward-same-level' needed be renamed `org-forward-heading-same-level' for example? Please stay as conservative as possible WRT to this, please consider providing an alias in these cases, just to moan a little bit :), Andreas
[O] [BUG] mention org-after-sorting-entries-or-items-hook
`org-sort-entries' calls a useful hook `org-after-sorting-entries-or-items-hook', which isn't mentioned in docstring. BTW using this to restore empty lines swallowed by sort. Thanks all, Andreas
[O] BUG: Decimal numbers using commata not recognised
Given the table below cash 20,000 short term debt 89,000 cash 20,000 short term debt 89,000 cash 20,000 short term debt 89,000 cash 20,000 short term debt 89,000 cash 20,000 short term debt 89,000 cash 20,000 short term debt 89,000 M-x org-table-convert-region - | cash 20 | 000 short term debt 89 | 000 | | cash 20 | 000 short term debt 89 | 000 | | cash 20 | 000 short term debt 89 | 000 | | cash 20 | 000 short term debt 89 | 000 | | cash 20 | 000 short term debt 89 | 000 | | cash 20 | 000 short term debt 89 | 000 | Decimal numbers using commata not recognised by org-table-convert-region Thanks, Andreas
Re: [O] BUG: Decimal numbers using commata not recognised
Am 09.09.2013 10:22, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Decimal numbers using commata not recognised by org-table-convert-region Did you try to customize `org-table-number-regexp'? Hi Bastiens, okay, for me that customization would be fine probably - even if a respectable regexp is waiting :) The question showed up today at Emacs help, OP asked for a quick way to make up a sheet. So, if org-table would be smart enough to detect the common dot-or-comma issue here, maybe that's a plus. Thanks all, Andreas
Re: [O] org-cut-subtree, bug?
Issue doesn't show up with Emacs built from trunk GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.18) of 2013-06-07 Thanks, Andreas
[O] org-cut-subtree, bug?
Hi, I'm misusing org-mode for a review of (slightly transformed) diffs as below. When done, want to delete the current section. Unfortunatly a call of M-x `org-cut-subtree' not just deletes the current section, but also deletes the header-start of section beneath. A bug? Better ways to do this? TIA, Andreas ;; * mlib_ImageAffineTransform_Fp.3mlib.vorher 2013-06-05 21:13:34.285757559 +0200 +++ mlib_ImageAffineTransform_Fp.3mlib.nachher 2013-06-05 21:13:40.824756887 +0200 - mtx Transformation matrix. mtx[0] holds a; mtx[1] holds b; mtx[2] - holds tx; mtx[3] holds c; mtx[4] holds d; mtx[5] holds ty. + mtx Transformation matrix. mtx[0] holds a; mtx[1] holds b; + mtx[2] holds tx; mtx[3] holds c; mtx[4] holds d; mtx[5] holds + ty. filterType of resampling filter. It can be one of the following: * mlib_ImageAffineTransform.3mlib.vorher2013-06-05 21:36:17.119617652 +0200 +++ mlib_ImageAffineTransform.3mlib.nachher 2013-06-05 21:36:19.487617409 +0200 @@ -52,8 +52,9 @@ src Pointer to source image. - mtx Transformation matrix. mtx[0] holds a; mtx[1] holds b; mtx[2] - holds tx; mtx[3] holds c; mtx[4] holds d; mtx[5] holds ty. + mtx Transformation matrix. mtx[0] holds a; mtx[1] holds b; + mtx[2] holds tx; mtx[3] holds c; mtx[4] holds d; mtx[5] holds + ty. filterType of resampling filter. It can be one of the following:
Re: [O] org-cut-subtree, bug?
Am 06.06.2013 10:11, schrieb Carsten Dominik: On 6 jun. 2013, at 09:58, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi, I'm misusing org-mode for a review of (slightly transformed) diffs as below. When done, want to delete the current section. Unfortunatly a call of M-x `org-cut-subtree' not just deletes the current section, but also deletes the header-start of section beneath. Hi Andreas, I am not sure I understand the problem. What do you mean by header-start of section? - Carsten The star, `*', introducing the header below. Which get's killed. Thanks, Andreas
Re: [O] org-cut-subtree, bug?
Am 06.06.2013 10:44, schrieb Carsten Dominik: On 6 jun. 2013, at 10:30, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 06.06.2013 10:11, schrieb Carsten Dominik: On 6 jun. 2013, at 09:58, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi, I'm misusing org-mode for a review of (slightly transformed) diffs as below. When done, want to delete the current section. Unfortunatly a call of M-x `org-cut-subtree' not just deletes the current section, but also deletes the header-start of section beneath. Hi Andreas, I am not sure I understand the problem. What do you mean by header-start of section? - Carsten The star, `*', introducing the header below. Which get's killed. I am not able to reproduce this. - Carsten Thanks, Andreas Okay, registered a kbd-macro which restores the star. Fine for me. Thanks again, Andreas
Re: [O] org-cut-subtree, bug?
Am 06.06.2013 10:56, schrieb Carsten Dominik: The star, `*', introducing the header below. Which get's killed. I am not able to reproduce this. - Carsten Thanks, Andreas Okay, registered a kbd-macro which restores the star. Fine for me. I would still be interested if anyone else sees this problem. - Carsten Thanks again, Andreas Provided stars making a header --by replacing the diffs header--, but did not indent the following section. Might be related to this. Andreas
Re: [O] How to prevent tabs from turning into spaces in source-code export?
Am 30.05.2013 15:22, schrieb Nicolas Goaziou:
Hello,
James Harkins jamshar...@gmail.com writes:
I have (where TAB is a tab character):
#+BEGIN_SRC {}
// SuperCollider code here
(
r = p.chan.play(Pspawner { |sp|
TABvar num, subdiv,
...
});
)
#+END_SRC
The exported .tex file contains:
\begin{lstlisting}
// SuperCollider code here
(
r = p.chan.play(Pspawner { |sp|
spcspcspcspcspcspcspcspcvar num, subdiv,
...
});
)
\end{lstlisting}
I do not want this conversion to happen. If it doesn't happen, then I
can use listings' tabsize property to control the tab width.
Try to preserve indentation:
#+begin_src {} -i
...
#+end_src
Regards,
Hi Nicolas,
as indentation might be provided by TAB and whitespace chars likewise, what
about following setting of `indent-tabs-mode'?
Best,
Andreas
Re: [O] Org-mode v8 broke my workflow
Am 18.05.2013 00:52, schrieb Marcin Borkowski: Hi list, can't resist;): http://xkcd.com/1172/ I have this at the end of my .emacs: (setq inhibit-splash-screen t) (org-agenda-list) (delete-window) The point is that I want agenda to appear as the only thing when I start Emacs. However, sometimes I start it e.g. when delivering a presentation; I don't want all the people to look at my overdue todo items;), so I used to press q while Emacs was starting (which takes quite a while on my netbook). This used to bury the agenda so that *scratch* was visible. Now, instead of *scratch*, one of my agenda org files appears. What do I do to restore the previous behavior? (Really, that setup worked for me;).) Best, You could move (org-agenda-list) at the beginning of your init, so it's not displayed as last. However, it might be displayed while loading for a short time though. If you want make sure it's never shown, don't see another way than deleting it from init and call it via M-x, resp. from menu. Andreas
Re: [O] Org-mode v8 broke my workflow
Am 18.05.2013 13:54, schrieb Marcin Borkowski: Dnia 2013-05-18, o godz. 08:07:07 Andreas Röhler andreas.roeh...@easy-emacs.de napisał(a): Am 18.05.2013 00:52, schrieb Marcin Borkowski: Hi list, can't resist;): http://xkcd.com/1172/ I have this at the end of my .emacs: (setq inhibit-splash-screen t) (org-agenda-list) (delete-window) The point is that I want agenda to appear as the only thing when I start Emacs. However, sometimes I start it e.g. when delivering a presentation; I don't want all the people to look at my overdue todo items;), so I used to press q while Emacs was starting (which takes quite a while on my netbook). This used to bury the agenda so that *scratch* was visible. Now, instead of *scratch*, one of my agenda org files appears. What do I do to restore the previous behavior? (Really, that setup worked for me;).) Best, You could move (org-agenda-list) at the beginning of your init, so it's not displayed as last. However, it might be displayed while loading for a short time though. If you want make sure it's never shown, don't see another way than deleting it from init and call it via M-x, resp. from menu. I guess you misread my post; Probably the problem seems to be about the order of buffers - I' like all the .org buffers to be /buried/. Okay. As it seems to matter at start, what about not open it? In cases, you might want open some files only ocassionaly, you could put a command into your init. (defun load-my-stuff-please () (interactive) (load /PATH-TO-STUFF/STUFF-1) (load /PATH-TO-STUFF/STUFF-2) ... (load /PATH-TO-STUFF/STUFF-n)) After evaluation resp. restart may you call it as command. Also, if want to load it all the time, add to your init after this definition (load-my-stuff-please) thankful (you know, there's a scientist in me - see this one: http://xkcd.com/242/). Nice. As your workflow proves, assume you also being a great sportsmen. :) Cheers, Andreas Best,
Re: [O] How to set C-o back to open-line?
Am 17.05.2013 04:28, schrieb Christopher Allan Webber: Suvayu Ali writes: Hello Christopher, On Thu, May 16, 2013 at 05:38:11PM -0500, Christopher Allan Webber wrote: I really hate org-open-line... I can see why people might want it, but it's messed up my workflow. I'd like to set C-o back. However, I have no idea what org-defkey is doing, but I expected this to work: (define-key org-mode-map (kbd C-o) 'open-line) it isn't working! How to get the standard-ol-open-line behavior back? Does using org-defkey instead make it work? org-defkey doesn't seem to work. That said, I'm curious what is so different about org-open-line? The docstring says the following: It is bound to C-o, insertline. (org-open-line N) Insert a new row in tables, call `open-line' elsewhere. So unless you are in a table, it should be the same as normal. Is that broken? Anyway, I never use open-line myself, but I was curious after I saw several people mention it on unrelated threads on a few lists. Cheers, Right, exactly. The way I use org-diet often involves me splitting apart and rejoining tables and the whole adding a new line in between is part of expected behavior for me. The new system is driving me crazy! Installing this instead should fix it: (defun org-open-line (n) Insert a new row in tables, call `open-line' elsewhere. With \C-u NUMBER `open-line' is called the common way also in table context (interactive *P) (cond (n (open-line (prefix-numeric-value n))) ((org-at-table-p) (org-table-insert-row)) (t (open-line (prefix-numeric-value n) Cheers, Andreas
Re: [O] Babel blocks not indented
[ ... ] I change my mode to whatever my src is in when I want indenting to work properly, then change it back when I want to see it as an org file again. Dave Probably it would pay to have a minor mode for that, running with idle-timer and switching the mode according to SRC context. Andreas
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 08.05.2013 22:50, schrieb Roland Donat: Yes, you're right Andreas. It fails to show the accented characters if you try to print the entire tuple. It fails too if you evaluate a[0][0] in your interpreter. You should see : a[0][0] '\xc3\xa9' But print a[0][0] gives the expected answer 'é' So, based on your successful experience consisting in returning a[0][0] in the orgmode source block, we can assume that org-babel use the python print function to display results in org buffer, aren't we? Another strange behaviour, when you evaluate the src_block test given in example, you get : | \303\251 | a| | a| \303\240 | Whereas I was expecting to get the same code than in the python interpreter, that is : | \xc3\xa9 | a | | a| '\xc3\xa0' | In addition, when I try to save my buffer, Emacs doesn't recognize the encoding of characters \303\251 and \303\240 and asks me to choose an encoding. Then, I enter utf-8 and nothing happens BUT when I quit and reopen my file : the characters are printed correctly Too strange for me Cheers, Roland. so what about that: a = ( ( é, a ), ( a, à ) ) for i, j in a: print i, j BTW previous post was sent prematurely.. Andreas Yep, using a couple of for loops will work but the result won't return as a table which is a requirement for me. To precise the context a littre more, I have basically 2 source blocks : 1) the famous python block which must return a table 2) a R block used to post-process the previous table Well, thanks for your help. I think I spent too much time on this so I'm thinking about changing my approach. For example, put the result of the first step into a file and then process the file in step 2. Best regards, Roland. Just playing a little bit with your example, what about this: #+begin_src python :results output :preamble # -*- coding: utf-8 -*- a = ( ( é, a ), ( a, à ) ) for i, j in a: print(|%s | %s| % (i, j)) #+end_src
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 09.05.2013 16:33, schrieb Roland Donat: Andreas Röhler andreas.roehler at easy-emacs.de writes: Am 08.05.2013 22:50, schrieb Roland Donat: Yes, you're right Andreas. It fails to show the accented characters if you try to print the entire tuple. It fails too if you evaluate a[0][0] in your interpreter. You should see : a[0][0] '\xc3\xa9' But print a[0][0] gives the expected answer 'é' So, based on your successful experience consisting in returning a[0] [0] in the orgmode source block, we can assume that org-babel use the python print function to display results in org buffer, aren't we? Another strange behaviour, when you evaluate the src_block test given in example, you get : | \303\251 | a| | a| \303\240 | Whereas I was expecting to get the same code than in the python interpreter, that is : | \xc3\xa9 | a | | a| '\xc3\xa0' | In addition, when I try to save my buffer, Emacs doesn't recognize the encoding of characters \303\251 and \303\240 and asks me to choose an encoding. Then, I enter utf-8 and nothing happens BUT when I quit and reopen my file : the characters are printed correctly Too strange for me Cheers, Roland. so what about that: a = ( ( é, a ), ( a, à ) ) for i, j in a: print i, j BTW previous post was sent prematurely.. Andreas Yep, using a couple of for loops will work but the result won't return as a table which is a requirement for me. To precise the context a littre more, I have basically 2 source blocks : 1) the famous python block which must return a table 2) a R block used to post-process the previous table Well, thanks for your help. I think I spent too much time on this so I'm thinking about changing my approach. For example, put the result of the first step into a file and then process the file in step 2. Best regards, Roland. Just playing a little bit with your example, what about this: #+begin_src python :results output :preamble # -*- coding: utf-8 -*- a = ( ( é, a ), ( a, à ) ) for i, j in a: print(|%s | %s| % (i, j)) #+end_src Yes Andreas! It works just fine for the python block. But when the python result arrives as input of my R post processing code, [ ... ] The bug so far affected the display only, not the data. Feeding R with the result returned from your original form should work. Best, Andreas
Re: [O] org-babel, python, encoding and table
Am 07.05.2013 22:05, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de writes: So it's up to choose the Python default interpreter. Unfortunatly (org-babel-do-load-languages 'org-babel-load-languages '((python3 . t))) seems not working. The language is still python (more or less). What you need to do is customize org-babel-python-command. Thanks. This reveals a bug in ob-python then. Will open a separate thread. Andreas
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
org-babel-python-mode was python3
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
Am 08.05.2013 09:12, schrieb Andreas Röhler: org-babel-python-mode was python3 e, org-babel-python-command
Re: [O] org-babel, python, encoding and table
Am 07.05.2013 18:41, schrieb Eric Schulte: #+NAME: test2 #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a a = ( ( é, a ), ( a, à ) ) b = é #+end_src #+RESULTS: test2 | \303\251 | a| | a| \303\240 | Maybe this isn't an execution problem, but is rather a buffer encoding problem. I executed your example above in a small buffer (attached). I then saved this buffer and was forced to specify an encoding, I selected utf8. If I cat the resulting file from disk, the accented characters appear correctly. Confirming this. BTW also return a[0][0] displays correct so far. Cheers, Andreas
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
Am 08.05.2013 14:40, schrieb Eric Schulte: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 08.05.2013 09:12, schrieb Andreas Röhler: org-babel-python-mode was python3 e, org-babel-python-command I can't reproduce this problem. After evaluating the following (setq org-babel-python-command python3) The utf-8 example works perfectly for me (and apparently for the other poster in the previous thread as well). Cheers, hmm, indeed, shows up nicely now. Please close, cheers, Andreas
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 08.05.2013 15:20, schrieb Roland Donat: hmm, indeed, shows up nicely now. Please close, cheers, Andreas That's right, it works with python3 but that is not the case with python2... Cheers, Roland. python2 fails here already with a common shell, independently from Emacs. OTOH that works with python2: #+NAME: test #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a[0][0] a = ( ( é, a ), ( a, à ) ) #+end_src #+RESULTS: test : é Maybe there is a work-around from a[0][0] ?
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 08.05.2013 16:02, schrieb Roland Donat: Andreas Röhler andreas.roehler at easy-emacs.de writes: Am 08.05.2013 15:20, schrieb Roland Donat: hmm, indeed, shows up nicely now. Please close, cheers, Andreas That's right, it works with python3 but that is not the case with python2... Cheers, Roland. python2 fails here already with a common shell, independently from Emacs. OTOH that works with python2: #+NAME: test #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a[0][0] a = ( ( é, a ), ( a, à ) ) #+end_src #+RESULTS: test : é Maybe there is a work-around from a[0][0] ? Yes, you're right Andreas. It fails to show the accented characters if you try to print the entire tuple. It fails too if you evaluate a[0][0] in your interpreter. You should see : a[0][0] '\xc3\xa9' But print a[0][0] gives the expected answer 'é' So, based on your successful experience consisting in returning a[0][0] in the orgmode source block, we can assume that org-babel use the python print function to display results in org buffer, aren't we? Another strange behaviour, when you evaluate the src_block test given in example, you get : | \303\251 | a| | a| \303\240 | Whereas I was expecting to get the same code than in the python interpreter, that is : | \xc3\xa9 | a | | a| '\xc3\xa0' | In addition, when I try to save my buffer, Emacs doesn't recognize the encoding of characters \303\251 and \303\240 and asks me to choose an encoding. Then, I enter utf-8 and nothing happens BUT when I quit and reopen my file : the characters are printed correctly Seems utf-8 understands \303\251, which seems the same number as \xc3\xa9, i.e. the numeric character returned is ok. Failings
Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef at MY-PATH/)]
Am 08.05.2013 16:02, schrieb Roland Donat: Andreas Röhler andreas.roehler at easy-emacs.de writes: Am 08.05.2013 15:20, schrieb Roland Donat: hmm, indeed, shows up nicely now. Please close, cheers, Andreas That's right, it works with python3 but that is not the case with python2... Cheers, Roland. python2 fails here already with a common shell, independently from Emacs. OTOH that works with python2: #+NAME: test #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a[0][0] a = ( ( é, a ), ( a, à ) ) #+end_src #+RESULTS: test : é Maybe there is a work-around from a[0][0] ? Yes, you're right Andreas. It fails to show the accented characters if you try to print the entire tuple. It fails too if you evaluate a[0][0] in your interpreter. You should see : a[0][0] '\xc3\xa9' But print a[0][0] gives the expected answer 'é' So, based on your successful experience consisting in returning a[0][0] in the orgmode source block, we can assume that org-babel use the python print function to display results in org buffer, aren't we? Another strange behaviour, when you evaluate the src_block test given in example, you get : | \303\251 | a| | a| \303\240 | Whereas I was expecting to get the same code than in the python interpreter, that is : | \xc3\xa9 | a | | a| '\xc3\xa0' | In addition, when I try to save my buffer, Emacs doesn't recognize the encoding of characters \303\251 and \303\240 and asks me to choose an encoding. Then, I enter utf-8 and nothing happens BUT when I quit and reopen my file : the characters are printed correctly Too strange for me Cheers, Roland. so what about that: a = ( ( é, a ), ( a, à ) ) for i, j in a: print i, j BTW previous post was sent prematurely.. Andreas
Re: [O] How to initiate source edits
Hi Alexander,
Am 07.05.2013 10:22, schrieb Alexander Baier:
Hi Andreas,
Andreas Röhler andreas.roeh...@easy-emacs.de writes:
Am 03.05.2013 10:34, schrieb Myles English:
Hi Andreas,
Andreas Röhler writes:
Hi,
have in some source file, let's assume Python, the following:
foo = {
bar: (
baz,
qux,
),
}
What is the best way to put this into an
#+BEGIN_SRC python
foo = {
bar: (
baz,
qux,
),
}
#+END_SRC
A literal answer would be:
echo #+BEGIN_SRC python\n newfile.org
cat somefile.py newfile.org
echo \n#+END_SRC\n newfile.org
Myles
ahh, that's great too :)
BTW think it should exist a way to transform a region accordingly. Will open a
separate thread maybe.
Andreas
You might want to take a look at Yasnippet, which in fact can transform
a region into a source code block, as you describe it. Have a look at
the User Guide[1] for writing snippets.
Regards,
Alex
___
[1]
http://capitaomorte.github.io/yasnippet/snippet-development.html#yas-wrap-around-region
Thanks pointing at that great tool.
In the precise case the command looked for was mentioned at the separate thread:
org-babel-demarcate-block
Best,
Andreas
Re: [O] org-babel-demarcate-block added to menu
Am 07.05.2013 12:41, schrieb Bastien: Hi Andreas, thanks for the suggestion -- I'll let other decide on it. An important point: since you do not want to assign your copyright to the FSF for Emacs/Org, I think it's better not to send patches but just to make suggestions for changes, especially for trivial changes like this one. I hope you agree :) Sure. OTOH trivial changes are accepted without assignment - at least this is the official FSF-policy. Andreas
Re: [O] org-babel, python, encoding and table
Am 07.05.2013 18:41, schrieb Eric Schulte: #+NAME: test2 #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a a = ( ( é, a ), ( a, à ) ) b = é #+end_src #+RESULTS: test2 | \303\251 | a| | a| \303\240 | Maybe this isn't an execution problem, but is rather a buffer encoding problem. I executed your example above in a small buffer (attached). I then saved this buffer and was forced to specify an encoding, I selected utf8. If I cat the resulting file from disk, the accented characters appear correctly. So maybe the problem is simply Emacs not displaying utf8 characters correctly. Hope this helps, Here error occurs depending if a or b is specified for return, really strange. Andreas
Re: [O] org-babel, python, encoding and table
Am 07.05.2013 20:18, schrieb Eric Schulte: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 07.05.2013 18:41, schrieb Eric Schulte: #+NAME: test2 #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a a = ( ( é, a ), ( a, à ) ) b = é #+end_src #+RESULTS: test2 | \303\251 | a| | a| \303\240 | Maybe this isn't an execution problem, but is rather a buffer encoding problem. I executed your example above in a small buffer (attached). I then saved this buffer and was forced to specify an encoding, I selected utf8. If I cat the resulting file from disk, the accented characters appear correctly. So maybe the problem is simply Emacs not displaying utf8 characters correctly. Hope this helps, Here error occurs depending if a or b is specified for return, really strange. I think this may be a problem with the Python code. The snippet above expands to the following python. which, when executed returns the following raw string (which is then interpreted by Org-mode). Maybe Python simply needs to be convinced to print in utf-8 format? Andreas Get the wrong results with a Ipython0.12, but correct with Python3.2.3 and Python3.3 - all called from Emacs24.3 attachment: python.png
Re: [O] org-babel, python, encoding and table
Am 07.05.2013 21:20, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 07.05.2013 20:18, schrieb Eric Schulte: Andreas Röhler andreas.roeh...@easy-emacs.de writes: ... Maybe Python simply needs to be convinced to print in utf-8 format? Get the wrong results with a Ipython0.12, but correct with Python3.2.3 and Python3.3 - all called from Emacs24.3 unicode handling is one of the big changes between Python 2.x and Python 3.x. It's good to know that Python 3.x seems to make it trivial to handle unicode correctly (although there might still be dragons there). Here are some links: http://docs.python.org/2/howto/unicode.html http://docs.python.org/3/howto/unicode.html that might shed some light. So it's up to choose the Python default interpreter. Unfortunatly (org-babel-do-load-languages 'org-babel-load-languages '((python3 . t))) seems not working. while type python3 python3 ist /usr/bin/python3
[O] [feature request] choosing the interpreter
Hi Erik, taking the interpreter issue showed up at other python thread, here a suggestion: let's go rid of static lists like (org-babel-do-load-languages 'org-babel-load-languages '( (sh . t) (python . t))) unless maybe as fallback. But from SRC, read the interpreter there. When this is implemented, let's enable there specifying a whole path. That might help testing code in different environments - as py-shell provides already. Best regards, Andreas
Re: [O] org-babel, python, encoding and table
[ ... ] But, what is hurting my poor little neurone is the fact that I don't understand why I get the correct result when the evaluation returns a single value and a wrong answer with a table. that's not the case. One from returns a, the other b, which are bound differently. The tuple fails with Python2 that way. I think I have to understand how org-babel builds a table from a Python list of lists but I have to confess that I'm afraid of reading Lisp programs, though Emacs is my best friend ;)... Well, I'll keep on investigating on that subject Thanks again for your help! Roland.
Re: [O] How to initiate source edits
Am 03.05.2013 10:07, schrieb Achim Gratz:
Andreas Röhler andreas.roehler at easy-emacs.de writes:
What is the best way to put this into an
#+BEGIN_SRC python
foo = {
bar: (
baz,
qux,
),
}
#+END_SRC
s TAB python C-c ' C-x i src.python C-c '
Regards,
Achim.
Thanks a lot!
Re: [O] How to initiate source edits
Am 03.05.2013 10:34, schrieb Myles English:
Hi Andreas,
Andreas Röhler writes:
Hi,
have in some source file, let's assume Python, the following:
foo = {
bar: (
baz,
qux,
),
}
What is the best way to put this into an
#+BEGIN_SRC python
foo = {
bar: (
baz,
qux,
),
}
#+END_SRC
A literal answer would be:
echo #+BEGIN_SRC python\n newfile.org
cat somefile.py newfile.org
echo \n#+END_SRC\n newfile.org
Myles
ahh, that's great too :)
BTW think it should exist a way to transform a region accordingly. Will open a
separate thread maybe.
Andreas
[O] initiate source edits and region
Hi all, want to wrap org-mode src markup around code in existing region. Having a look at the way sTAB works internally, it seems hard to make use of it. The region is affected already by inserting sTAB. That part probably would profit being moved closer to the way, edit commands are called commonly. Maybe someone already wrote such region-sensitive insert/init? Best regards, Andreas
Re: [O] initiate source edits and region
Am 03.05.2013 13:11, schrieb Sebastien Vauban: Andreas, Andreas Röhler wrote: want to wrap org-mode src markup around code in existing region. Maybe someone already wrote such region-sensitive insert/init? Yes, Eric: C-c C-v C-d Best regards, Seb That's it, thanks!
[O] org-babel-demarcate-block added to menu
Cheers, Andreas commit 3684737f97fc78eeca8f6d284985e39a88a5393e Author: Andreas Roehler andreas.roeh...@online.de Date: Fri May 3 17:22:33 2013 +0200 menu provide `org-babel-demarcate-block' org-mode menu should enable access to edit commands This change opens a slot, so other commands may follow TINYCHANGE diff --git a/lisp/org.el b/lisp/org.el index ae0110f..e759994 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -20719,7 +20719,11 @@ See the individual commands for more information. [Convert to odd/even levels org-convert-to-oddeven-levels t]) (Editing [Emphasis... org-emphasize t] - [Edit Source Example org-edit-special t] + (Edit Code Sources + [Wrap/split code in region or at point. org-babel-demarcate-block t] + [Edit current chunk org-edit-special t] + ) + -- [Footnote new/jump org-footnote-action t] [Footnote extra (org-footnote-action t) :active t :keys C-u C-c C-x f])
[O] How to initiate source edits
Hi,
have in some source file, let's assume Python, the following:
foo = {
bar: (
baz,
qux,
),
}
What is the best way to put this into an
#+BEGIN_SRC python
foo = {
bar: (
baz,
qux,
),
}
#+END_SRC
Thanks,
Andreas
Re: [O] how to best make characters invisible in a org-derived mode
Am 27.04.2013 05:29, schrieb Christian Wittern: Hi orgers, In a mode derived from org-mode, I would like to hide some characters with a special function to make the display cleaner. There are two cases: - special characters that should be always invisible - strings matched by a regex that should be invisible I would be glad for any pointers or ideas on how to implement this, either by piggy-packing on org-mode code or by using generic Emacs features. All the best, Christian Hi, maybe have a look how ar-hide-bracketed-in-line-atpt for example is implemented. https://launchpad.net/s-x-emacs-werkstatt/ https://launchpad.net/s-x-emacs-werkstatt/trunk/1.3/+download/S-X-Emacs-Werkstatt-1.3.tar.gz This provides a framework for tasks like this. HTH, Andreas
Re: [O] how to best make characters invisible in a org-derived mode
Am 02.05.2013 00:58, schrieb Christian Wittern: Hi Andreas, Hi John Thank both of you for trying to get me on track. On 2013-05-01 16:43, Andreas Röhler wrote: maybe have a look how ar-hide-bracketed-in-line-atpt for example is implemented. I can't actually find this function, but I get the general point from the files in Emacs Werkstatt. What tripped me up originally that simply setting a region to 'invisible worked in fundamental mode, but not in org-mode. I found the solution after I finally understood what (info (elisp) Invisible Text) was trying to tell me: - first set the desired region(s) to an arbitrary symbol, like my-symbol: (overlay-put (make-overlay beginning end) 'invisible 'my-symbol) - next add this symbol to 'invisibility' spec : (add-to-invisibility-spec 'my-symbol) After straighting this out I am now a happy camper, enjoying my uncluttered display. All the best, Christian ar-hide-bracketed-in-line-atpt seems vanished indeed, something got broken. Thanks pointing at. Andreas
Re: [O] New maintainer
Hi Bastien, Am 22.04.2013 00:39, schrieb Bastien: Hi Andreas, thanks for the kind words. The decision to step down after 8.0 was taken a long time ago, before the recent problems on the list. I had to find someone willing to step in before I could announce this. Okay, a good news in circumstances. I agree maintainer is not necessary a single person: my main purpose was to build a team, so that future maintainer(s) would feel okay to act as you suggest, for strategic decisions rather than everyday ground-level stuff. This position is easy to describe but difficult to hold, Precisely. because it depends so much on the community. This *is* the real challenge I see now: that each of us endorses some kind of responsability, some co-maintainership feeling, and act as constructively as possible---be it for org-mode, worg, the website or whatever. I already can feel some go in this direction and that's great :) Indeed. Nonetheless, WRT the amount of traffic IMHO having someone to range things a little bit before Carsten must tell will be a great advantage. Thanks all proving that great stuff, Andreas
Re: [O] New maintainer
Am 18.04.2013 18:53, schrieb Bastien: Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) Hi Bastien, have been afk for some days, please let me close up to all thanks seen here. What's have been quite impressive already was the pure amount of mailings, you delt with day by day. Having seen you working that hard also raises some concern for now: that daily galeere must be costly: whoever undertakes it, will pay a price. It's your honor having payed it for all of us. So far can't consider this stepping down anything else as a loss for org-mode. While ignoring circumstances of your resign, it's no secret, some unpleasant events happended last weeks, made your task more burdensome as necessary. I'm not speaking of possible errors - everyone who works will make errors. Who works outstanding might make outstanding errors. Purely abstractly spoken(!) OTHO the very best mind a team has --i.e. Carsten--, should not take the most burdensome tasks. IMHO Carsten should be spared for strategic decisions, define and decide the path of further development. In case you didn't lose your interest and just that recent unpleasant experiences caused your resign, what about staying maintainer backed by all this confidence revealed beside of some new experience? Also maintainer must not mean being strictly a single person, even if languages grammar doesn't foresee otherwise. Regarding recent difficulties, probably it's wise, if Carsten has a closer look, decides in cases from time to time. IIUC Emacs itself was driven in a similar way last years more or less outspoken - consider this part of it's success story. Best regards, Andreas
Re: [O] Org-mode as a metalanguage: calling SQL functions
Am 05.04.2013 18:31, schrieb Eric Schulte: [ ... ] Yea, this could be a simple note, e.g., the method by which variables are applied to code blocks are language-specific and determined by the semantics of the programming language of the code block, see Hi, still can't see the purpose of this feature. OTOH expect an eternal trouble when re-implementing. Even the notion what a variable is at all may differ a lot in languages. If you define a syntax whose results are uncertain, only work from time to time, to a limited extend, it's better to rely on native source code. Best, Andreas
Re: [O] BUG docu org-babel-default-header-args
Am 05.04.2013 19:14, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: http://orgmode.org/manual/System_002dwide-header-arguments.html#System_002dwide-header-arguments Org Mode Info System-wide header arguments System-wide values of header arguments can be specified by customizing the `org-babel-default-header-args' variable: ; Seems not the case as in ob-core.el (defvar org-babel-default-header-args ; Not sure what you mean -- do you mean that saying customizing in the manual is not appropriate because `org-babel-default-header-args' is a variable (defvar) and not an option (defcustom)? Thanks for further clarification! Hi Bastien, customization needs a defcustom, not a defvar (defvar org-babel-default-header-args '((:session . none) (:results . replace) (:exports . code) (:cache . no) (:noweb . no) (:hlines . no) (:tangle . no) (:padnewline . yes)) Default arguments to use when evaluating a source block.) This var user can't customize, as Info tells falsely. Cheers, Andreas
Re: [O] BUG typo in languages.html
Am 05.04.2013 19:21, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: http://orgmode.org/worg/org-contrib/babel/languages.html LanguageIdentifier Documentation Requirements C c ob-doc-Cnone ; mentiones lesser c as Identifier, seems it should be upper C Not sure -- why? BTW couldn't see http://orgmode.org/worg/org-contrib/babel/languages.html in Worg git-repo It's there: org-contrib/babel/languages.org HTH, wrong there also. Evaluating (org-babel-do-load-languages 'org-babel-load-languages '( (c . t))) == Debugger entered--Lisp error: (file-error Cannot open load file ob-c) require(ob-c) #[(pair) A\303@!\211\203 But (org-babel-do-load-languages 'org-babel-load-languages '( (C . t))) == ((C . t))
Re: [O] I have terminated my assignment
Am 03.04.2013 00:25, schrieb John Hendy: On Tue, Apr 2, 2013 at 5:16 PM, Christian Moe m...@christianmoe.com wrote: Jambunathan, If you're leaving the Org-mode community, I'd prefer to remember you with gratitude for leaving us the excellent ODT exporter. Please stop diminishing your legacy with this quasi-legal wrangling. As a user, I have greatly appreciated both your code contributions and your patient help on the mailing list in the past. I think your recent way of registering your displeasure with the Org maintainer is beneath you. Also unhelpful, pointless, damaging to the community, and, in the worst-case scenario, a damn waste of good work. Yours, Christian Jambunathan K writes: I have terminated my copyright assignment to Emacs (or atleast notified the copyright desk). With respect to Org staying up to date on these developments, it probably *is* a good idea to know how Emacs/FSF responds. Should the rights be granted back to Jambunathan, Org should behave accordingly. Hi John, as for the GPLed code, no one may revert it's GPLed status once published. That's great with GPL, made it a success story. Can't see anything to grant back so far from Org's side. Best, Andreas As it currently reads however, it made me think of something along the lines of, I have terminated my marriage to my wife (or at least left a message with her secretary to let her know). The two are hardly the same. Until this is formalized, papers signed and rights granted (regardless of 20/20 hindsight and warnings to other potential signers) still stand as binding. John
Re: [O] Org-mode as a metalanguage: calling SQL functions
Am 02.04.2013 23:54, schrieb Eric Schulte: Gary Oberbrunner ga...@oberbrunner.com writes: Aha -- you have to use the :var syntax on the begin_src line, not the params-in-parens syntax on the name line. Your version works: #+name: example-block #+begin_src sh :var input= echo input is $input #+end_src but this doesn't: #+name: example-block(input=) #+begin_src sh echo input is $input #+end_src The doc seems to say it should work the same, in http://orgmode.org/manual/var.html (see Alternate Argument Syntax). At this point I'm not sure if the documentation or the code should be amended. I've personally never liked the args-in-block-name syntax, but I don't recall if we formally decided to abandon it, or if it has simply been broken in a recent commit. Hi Eric, AFAIU exist considerable backsides when allowing this args-in-block-name. As languages differ, you must write some translations for every lang somehow, i.e, re-invent it's handling. Also can't see a meta-languags than, it would mean address other languages from an Org dialect. A major backside already visible it breaking the legibility of native languages code. Org constructs are not easier to read than native lang, it's more difficult with that lined-up args lists. Andreas
Re: [O] python sessions
Am 27.03.2013 07:19, schrieb Andreas Röhler: Am 26.03.2013 22:41, schrieb Gary Oberbrunner: I did some further testing. With my patch, my real org-mode python file is now actually working. There were a few gotchas I didn't understand about session mode and python and matplotlib: 1. In session mode, you are essentially running an interactive python. (This is made explicit by my patch, which passes -i). 2. In interactive mode, blank lines are special: they indicate the end of an indented block. So you have to write your org-mode python a little differently when using session mode. 3. matplotlib uses an interactive backend when started from an interactive python (sensibl y). So you have to set the backend explicitly when using session mode, or it hangs forever with no indication what's wrong. 4. ob-python does not handle python errors at all in session mode: it ignores them silently. This makes it really hard to debug the python code. I'd like to document #s 1-3; where should that go? I'd like to work on a patch for #4; it seems like the only thing is to search in the session buffer for likely error strings. Is there any better method anyone can think of? AFAIU the error string is missing, because it's sent the wrong path-to-interpreter, i.e. using shell-command. Shell returns 0 or 1, not the Python errors. Also the interactive spec is related. Usually Python shell as started from py-shell or run-python include this already. When send from a python-mode, also the empty lines you mentioned and related stuff is treated. Andreas That turned out not being the case. I'm quoting: This is incorrect. In session mode, there is one long-running python interpreter session. Emacs passes it code snippets, and it spits out stdout and stderr (all mixed up: output from your program, the lines themselves which get echoed, prompts, and error messages if any). There is never any return value since the python interpreter doesn't exit. The only way to handle errors in interactive mode AFAICS is to use approximate regexes to look for errors, un-handled exceptions and so on. Cheers
Re: [O] Fwd: run python from org, draft
Hi Gary, Am 29.03.2013 13:11, schrieb Gary Oberbrunner: Does this assume org-babel-python-mode is set to 'python-mode? The default is 'python, I believe. I don't think you should unconditionally call py-send-string-return-output like that. Also, why would you avoid calling org-babel-python-evaluate? Where in your patch would it account for the setting of session, result-type or result-params? with current GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.14) of 2013-03-05 Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ MY_PATH/emacs-24.3/lisp/org/) python from org-source seems completely broken. For example: #+BEGIN_SRC python 1+2 #+END_SRC #+RESULTS: : None While the patched ob-python.el at least gives a result. As attached png shows, a py-shell buffer is visible, which should not. And some more back-sides. So far following your arguments. Just wanted to look for the spot where to fix it. Maybe not the right one yet, just a study. So let's go on until a convenient solution is found, Andreas On Thu, Mar 28, 2013 at 5:55 PM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi, as running python from org-source has been reported broken, herewith a patch, which allows basic usage. Requires python-mode.el-6.1 https://launchpad.net/python-**mode/trunk/6.1.1/+download/** python-mode.el-6.1.1.tar.gzhttps://launchpad.net/python-mode/trunk/6.1.1/+download/python-mode.el-6.1.1.tar.gz Just a draft, not thought as implementation, Andreas attachment: ob-python-patched.png
Re: [O] Fwd: run python from org, draft
Am 29.03.2013 16:09, schrieb Eric Schulte: with current GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.14) of 2013-03-05 Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ MY_PATH/emacs-24.3/lisp/org/) python from org-source seems completely broken. For example: #+BEGIN_SRC python 1+2 #+END_SRC #+RESULTS: : None Weird. With all the testing we did last week, I'm surprised that this is the case with me as well. I'm also getting no results with Org 8.0-pre and Emacs 24.3.1. Because of quirks of the python language, or rather the quirks of org-babel? ;) when executing outside of a session, it is necessary to explicitly specify a return. For example. #+begin_src python return 1+2 #+end_src #+RESULTS: : 3 or #+begin_src python :return x x = 1+2 #+end_src #+RESULTS: : 3 This is clearly stated in the Python documentation on Worg. http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html Thanks, IMO org-babel should be able to run source code as is. If an org-mode specific modification is required at such a trivial form, what to expect wrt complex environments? BTW this fails also: #+begin_src python print Hello, world! #+end_src python #+RESULTS: : None Can't see a consistent behavior so far. Why not follow the path given, which avoids the artistics? Andreas
Re: [O] Fwd: run python from org, draft
Am 29.03.2013 17:20, schrieb Eric Schulte: A valid opinion, in fact I think I defended that point of view myself, Hi Eric, so, if I'm saying: let's make things considerably easier, working right from the spot, why not try that? What I need still is a specification, what :session and the other header arguments shall do. Presently they do quite different things. Also can't read a bulk of mails to figure out some guessing. Please write a specification and with the help of the other guys let's have some tiny and effective ob-python. Let's see of we need more lines than ob-emacs-lisp.el :) Cheers
Re: [O] Fwd: run python from org, draft
Am 29.03.2013 17:47, schrieb Eric Schulte: As we've proven a couple of times now, Python session are broken with the newest version of Emacs (since the upstream change to an entirely new python.el implementation). I've just pushed up a fix to ob-python.el so that sessions should now work with the latest version of Emacs. I hope this clears up some of the miss-understandings surrounding ob-python. Here is a quick example usage. Hi Eric, you are heading into the wrong direction, while babel as such certainly is of great interest. Recent ob-python.el commit tells about fixing the buffer name, change the default python buffer name How ob-python.el knows about a python buffer name at all? Python buffer names are at the choice of users, for example via defcustom... And so on. ob-python.el needs a re-thinking from the bottom, otherwise it remains buggy, only working from case to case. Andreas
Re: [O] Fwd: run python from org, draft
Am 29.03.2013 17:47, schrieb Eric Schulte: As we've proven a couple of times now, Python session are broken with the newest version of Emacs (since the upstream change to an entirely new python.el implementation). I've just pushed up a fix to ob-python.el so that sessions should now work with the latest version of Emacs. I hope this clears up some of the miss-understandings surrounding ob-python. Here is a quick example usage. Nonewithstanding, really a pleasure seeing it finally working so far. Thanks! Andreas
Re: [O] Fwd: run python from org, draft
Am 29.03.2013 20:59, schrieb Gary Oberbrunner: On Fri, Mar 29, 2013 at 11:09 AM, Eric Schulte schulte.e...@gmail.comwrote: Because of quirks of the python language, when executing outside of a session, it is necessary to explicitly specify a return. ... This is clearly stated in the Python documentation on Worg. http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html ... which I just wrote! Glad it's already useful! :-) Ah, thanks a lot! Really helpful. Apropos for subtypes: raw: value is inserted directly may you give some example there, how to write them? I think in any case you will need my recent patch if you want to use session mode. IIUC it's addressed resp. implemented already w/ 993e3ee6215764f122b62cc9c949299b50e1eb22 org-babel-python-with-earmufs However, ob-python should not fix python-modes but read them... use them... Anyway, glad to see it's moving, Andreas If testing is holding up application of my patch, I can test it on Linux and Mac.
Re: [O] Fwd: Fwd: run python from org, draft
Am 29.03.2013 21:10, schrieb Gary Oberbrunner: On Fri, Mar 29, 2013 at 11:29 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: IMO org-babel should be able to run source code as is. If an org-mode specific modification is required at such a trivial form, what to expect wrt complex environments? BTW this fails also: #+begin_src python print Hello, world! #+end_src python #+RESULTS: : None As the worg doc says, if you want to capture stdout rather than a value, you need :results output. The default is :results value (which in session mode is the last expression executed, and in non-session mode is whatever you return().) I agree it is a little odd, but given how python works it's not clear to me how to improve it. Hi Gary, if someone wants the value of the last expression returned, it's much simpler to write Python/native language, than cryptic, lately documented org-mode flags. That's a kind of re-inventing a programming-language, also redundant. Specifically, in non-session mode, the python interpreter is run as a separate process and fed the input (with some stuff around it). There is no way for python to get the last value in non-interactive mode, No? Any program may output any of it's values. so instead ob-python wraps your code in a function, then calls it, and writes the return value of that function to the temp file. Conversely in session mode, each block is talking to the same interactive python interpreter, just what you get if you type 'python' at the shell. So using return() there doesn't make any sense, and wouldn't work. The use of return doesn't depend from interactive mode. It's related to a function. Seen from org-user, IMO any back-ends interactive mode or not is not of interest. :session mimics and/or probably uses it, but it would also possible to implement it as a file, loading previous values from a storage. I don't see any way to make them both behave the same way. Probably most useful at this list is to define which feature/behavior is most convenient. Why people use this mode, what they want to do. Cheers, Andreas
[O] run python from org, draft
Hi, as running python from org-source has been reported broken, herewith a patch, which allows basic usage. Requires python-mode.el-6.1 https://launchpad.net/python-mode/trunk/6.1.1/+download/python-mode.el-6.1.1.tar.gz Just a draft, not thought as implementation, Andreas diff --git a/lisp/ob-python.el b/lisp/ob-python.el index 7bc9a1f..2734bff 100644 --- a/lisp/ob-python.el +++ b/lisp/ob-python.el @@ -86,8 +86,11 @@ This function is called by `org-babel-execute-src-block'. (org-babel-expand-body:generic (concat body (if return-val (format \nreturn %s return-val) )) params (org-babel-variable-assignments:python params))) - (result (org-babel-python-evaluate - session full-body result-type result-params preamble))) + (result + (py-send-string-return-output full-body) + ;; (org-babel-python-evaluate + ;; session full-body result-type result-params preamble) + )) (org-babel-reassemble-table result (org-babel-pick-name (cdr (assoc :colname-names params))
Re: [O] python sessions
Am 26.03.2013 22:41, schrieb Gary Oberbrunner: I did some further testing. With my patch, my real org-mode python file is now actually working. There were a few gotchas I didn't understand about session mode and python and matplotlib: 1. In session mode, you are essentially running an interactive python. (This is made explicit by my patch, which passes -i). 2. In interactive mode, blank lines are special: they indicate the end of an indented block. So you have to write your org-mode python a little differently when using session mode. 3. matplotlib uses an interactive backend when started from an interactive python (sensibly). So you have to set the backend explicitly when using session mode, or it hangs forever with no indication what's wrong. 4. ob-python does not handle python errors at all in session mode: it ignores them silently. This makes it really hard to debug the python code. I'd like to document #s 1-3; where should that go? I'd like to work on a patch for #4; it seems like the only thing is to search in the session buffer for likely error strings. Is there any better method anyone can think of? AFAIU the error string is missing, because it's sent the wrong path-to-interpreter, i.e. using shell-command. Shell returns 0 or 1, not the Python errors. Also the interactive spec is related. Usually Python shell as started from py-shell or run-python include this already. When send from a python-mode, also the empty lines you mentioned and related stuff is treated. Andreas
[O] BUG typo in languages.html
http://orgmode.org/worg/org-contrib/babel/languages.html LanguageIdentifier Documentation Requirements C c ob-doc-Cnone ; mentiones lesser c as Identifier, seems it should be upper C BTW couldn't see http://orgmode.org/worg/org-contrib/babel/languages.html in Worg git-repo Andreas
Re: [O] :session question
Am 26.03.2013 13:37, schrieb Eric Schulte: Question from here: I use mainly R and have there set file wide #+PROPERTY: session R-session But I also have bash code, which would be evaluated in the R session, unless I use #+begin_src sh :session sh-session ... #+end_src But I do not need a session for the bash code blocks - so would :session none disable session for this source block? This would be great! Yes maybe just :session no rather than :session none Booleans written as strings reads terribly for me :( Cheers, Andreas
Re: [O] :session question
Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. As it reads, it clutters even the global languages name space? Best, Andreas
[O] BUG docu org-babel-default-header-args
http://orgmode.org/manual/System_002dwide-header-arguments.html#System_002dwide-header-arguments Org Mode Info System-wide header arguments System-wide values of header arguments can be specified by customizing the `org-babel-default-header-args' variable: ; Seems not the case as in ob-core.el (defvar org-babel-default-header-args ;
Re: [O] :session question
Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? Best, Andreas
Re: [O] :session question
Am 27.03.2013 12:48, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? i.e. doesn't look like a session, resp. not a named session #+begin_src R x - 1 x #+end_src Once a named session org-R is started all non-sessioned source goes there? Looks like a broken namespace.
Re: [O] :session question
Am 27.03.2013 13:22, schrieb Rainer M Krug: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/13 13:18, Andreas Röhler wrote: Am 27.03.2013 12:48, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 [ ... ] Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? i.e. doesn't look like a session, resp. not a named session #+begin_src R x - 1 x #+end_src Once a named session org-R is started all non-sessioned source goes there? Looks like a broken namespace. Isn't it the same with all header arguments? when they are set file wide, they are used for the source block unless specified otherwise. Rainer Hmm, may you point me to the file-wide setting? Form at stake (setq org-babel-default-header-args:R '((:session . org-R))) seems to put all remaining R-evaluations into a named session org-R Don't see any restriction onto a file resp. buffer. Maybe that's thought implicit? Thanks, Andreas
Re: [O] :session question
Am 27.03.2013 13:43, schrieb Eric Schulte: org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? No one has said or implied that. Looks for me as this code from your example runs in session mode without explicit :session argument given: #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 [ ... ]
[O] smart loading languages
Hi, instead requiring explicit (org-babel-do-load-languages 'org-babel-load-languages '( (LANGUAGE-1 . t) (LANGUAGE-2 . t) ... (LANGUAGE-N . t) )) in Emacs init, AFAIU that might be done first time when a source block is evaluated. Andreas
Re: [O] :session question
[ ... ] But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Mi 27. Mär 21:18:49 CET 2013 #+end_org Would say rather: global defaults are not predictable from users perspective, as global :seesion settings may have an effect or not. See in Common Lisp for example, which is always in session-mode IIUC
Re: [O] python sessions
Am 25.03.2013 22:37, schrieb Eric Schulte: running into this, func def seems missing: Debugger entered--Lisp error: (void-function org-babel-result-cond) My guess is that you have a mixed install. You are mostly running the Org-mode which ships with Emacs (in which `org-babel-result-cond' is not defined), but you are running the version of ob-python.el from the master branch (which expects `org-babel-result-cond' to be defined). This is an increasingly common problem. Maybe the following can help. http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development Hmm, don't see there anything to change wrt to the issue. Have in my init (defun ar-load-feature-org-mode () (interactive) (add-to-list 'load-path MY_PATH/feature-org-mode) (add-to-list 'load-path MY_PATH/feature-org-mode/lisp) (find-file MY_PATH/feature-org-mode/lisp/ob-python.el) (load MY_PATH/feature-org-mode/lisp/org-compat.el nil t) (load MY_PATH/feature-org-mode/lisp/ob-comint.el nil t) (load MY_PATH/feature-org-mode/lisp/ob-emacs-lisp.el nil t) (load MY_PATH/feature-org-mode/lisp/org.el nil t) (load MY_PATH/feature-org-mode/lisp/ob-eval.el nil t) (load MY_PATH/feature-org-mode/lisp/ob.el nil t) (load MY_PATH/feature-org-mode/lisp/ob-python.el) ;; (load MY_PATH/feature-org-mode/testing/org-test-ob-consts.el nil t) ;; (load MY_PATH/feature-org-mode/testing/org-test.el nil t) (load-this-directory MY_PATH/feature-org-mode/lisp) (org-babel-do-load-languages 'org-babel-load-languages '( (sh . t) (python . t Maybe should unload existing org-mode first. Checking for existing features yields: org-agenda org-bbdborg-bibtex org-compat org-docview org-entitiesorg-exp org-exp-blocks org-faces org-footnoteorg-gnusorg-html org-infoorg-infojs org-irc org-jsinfo org-listorg-loaddefsorg-macsorg-mew org-mhe org-pcomplete org-rmail org-src org-version org-vm org-w3m org-wl Thanks, Andreas
Re: [O] :session question
Am 26.03.2013 00:58, schrieb Michael Gauland: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. I don't think so, but perhaps I'm just used to the way it works now. I use a mix of session and non-session blocks. When I use plantuml, dot, or asymptote to generate images, I don't use sessions (I'm not sure these languages even support sessions). Which is a strong argument for the present explicit way. Otherwise it would be hard to detect if results are kept or not. Thanks, Andreas I almost always use sessions for R, because I want to use the same data in different blocks. I also generally use sessions for Racket (scheme), even when I don't to share data across blocks, so I don't need to wait for the interpreter to start up for each block. Kind Regards, Mike Gauland
Re: [O] :session question
Thanks! Am 26.03.2013 01:46, schrieb Eric Schulte: Michael Gauland mikely...@no8wireless.co.nz writes: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. Header argument defaults are easy to accomplish on a per user or per file basis, just customize the `org-babel-default-header-args' variable. ,[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in `ob.el'. | Its value is ((:noweb . yes) | (:session . none) | (:results . replace) | (:exports . code) | (:cache . no) | (:hlines . no) | (:tangle . no) | (:padnewline . yes)) | | | Documentation: | Default arguments to use when evaluating a source block. | | [back] `
[O] org-babel header documentation
Hi all, while digging through the org-babel stuff, which is quite exiting, have some difficulties to grasp the functionality of different header arguments. Info 14.8 Header arguments is useful so far. Still miss an explanation the way Setting X to Y will cause Maybe missing the right spot still? Thanks, Andreas
Re: [O] org-babel header documentation
Am 26.03.2013 16:35, schrieb Eric Schulte: John Hendy jw.he...@gmail.com writes: On Tue, Mar 26, 2013 at 10:00 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi all, while digging through the org-babel stuff, which is quite exiting, have some difficulties to grasp the functionality of different header arguments. Info 14.8 Header arguments is useful so far. Still miss an explanation the way Setting X to Y will cause Maybe missing the right spot still? I tend to agree. I typically just follow the matching tutorial for whatever language I'm using and stick to it... but I don't always understand (like why I need =:results output graphics= in R vs. just output). Perhaps you could inquire about a particular header setting, someone could respond, and you could add the info to Worg somewhere (something like a layman's guide to header arguments)? The evolution of the code block functionality over the years has been driven almost exclusively by this mailing list. The best way to find the reasoning behind any particular baroque combination of header arguments is to search through the archives of this list. Sadly we don't do a good enough job of ensuring that the content generated here makes its way to Worg. I'm certainly guilty of this myself, but there are only so many hours in the day. Hi Eric, thanks a lot BTW for all you've done. What about to have a list editable for all interested w/ comments to all header args in alphabetical order? Might participate and write it down the way it's understood. You and others may correct it on the fly. Maybe someone starts a headers.org in Worg? Andreas
Re: [O] python sessions
Am 25.03.2013 03:59, schrieb John Hendy: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). John Thanks, Nick The python-mode(s) question should not be at stake, as in context it matters only for the choice, which command should start the Python shell - run-python or py-shell. All ob-python needs is a known buffer, commonly *Python*, connected to a python-process. This seems done by both modes, so don't expect the bug here. Andreas
[O] :session question
Hi all, org-babel uses the header argument :session keeping the environment for consecutive evaluations. That feels the opposite of all on-the-fly evaluations commonly done by a (language)-shell. Commonly a shell keeps is values until a new one is created. Would find it more natural if :session is the default, while a command refresh makes a new one. Also instead of :session a header argument :dedicated would provide a new process every time. As we have a bug around, maybe it's a good moment to consider that, Andreas
[O] no info files created w/ current git-repo
Hi, building from current git-repo make all builds some .pdf and .html docu, but not info directory doc contains: dir Makefile orgguide.texi org-version.inc doclicense.texi org org.html pdflayout.sty Documentation_Standards.org orgcard.tex org.pdftexinfo.tex library-of-babel.org orgguide.pdf org.texi Any help? Thanks, Andreas
Re: [O] no info files created w/ current git-repo
Am 25.03.2013 14:42, schrieb John Hendy: On Mon, Mar 25, 2013 at 6:53 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi, building from current git-repo make all builds some .pdf and .html docu, but not info directory doc contains: dir Makefile orgguide.texi org-version.inc doclicense.texi org org.html pdflayout.sty Documentation_Standards.org orgcard.tex org.pdftexinfo.tex library-of-babel.org orgguide.pdf org.texi Any help? Thanks, Is it the related as this? - http://permalink.gmane.org/gmane.emacs.orgmode/69071 John Andreas IIRC that was 2 commits before and no docu were built at all. Now this remains. Thanks looking at, Andreas
[O] void-variable org-list-allow-alphabetical
Hi,
when trying to load git-devel-repo after make all get the error.
Traceback attached
If defvarred before defcustom, that error is gone.
Andreas
Debugger entered--Lisp error: (void-variable org-list-allow-alphabetical)
byte-code(\306\307\310\307\311\307\312\313\307\314\307\315\307\316\307\317\307\320 \n \fF!\307
\321=\203$ \322\202/
\323=\203. \324\202/ \325\2055 \326 \327 \330 \330\331\260*\332\260\207 [org-outline-regexp org-scheduled-string org-deadline-string org-closed-string org-clock-string org-plain-list-ordered-item-terminator ^\\(?: \\| \\[\\(?:[0-9]+\\|fn:[-_[:word:]]+\\)\\] %%( [ ]*\\(?: $ \\(?:|\\|\\+-[-+]\\) [#:] -\\{5,\\}[ ]*$ begin{\\([A-Za-z0-9]+\\*?\\)} regexp-opt 41 ) 46 \\. [.)] \\|[A-Za-z] \\(?:[-+*]\\|\\(?:[0-9]+ \\) \\(?:[ ]\\|$\\) \\)\\) org-list-allow-alphabetical alpha term] 26)
(defconst org-element-paragraph-separate (byte-code \306\307\310\307\311\307\312\313\307\314\307\315\307\316\307\317\307\320 \n \fF!\307
\321=\203$ \322\202/
\323=\203. \324\202/ \325\2055 \326 \327 \330 \330\331\260*\332\260\207 [org-outline-regexp org-scheduled-string org-deadline-string org-closed-string org-clock-string org-plain-list-ordered-item-terminator ^\\(?: \\| \\[\\(?:[0-9]+\\|fn:[-_[:word:]]+\\)\\] %%( [ ]*\\(?: $ \\(?:|\\|\\+-[-+]\\) [#:] -\\{5,\\}[ ]*$ begin{\\([A-Za-z0-9]+\\*?\\)} regexp-opt 41 ) 46 \\. [.)] \\|[A-Za-z] \\(?:[-+*]\\|\\(?:[0-9]+ \\) \\(?:[ ]\\|$\\) \\)\\) org-list-allow-alphabetical alpha term] 26) (MY-PATH/org-element.elc . 533))
load(MY-PATH/org-element.elc nil nil t)
load-file(MY-PATH/org-element.elc)
(if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file))
(let ((file (car files))) (if (file-exists-p (concat file c)) (progn (if (file-newer-than-file-p file (concat file c)) (setq files (remove (concat file c) files)) (setq files (cdr files)) (setq file (concat file c) (if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file)))
(while files (let ((file (car files))) (if (file-exists-p (concat file c)) (progn (if (file-newer-than-file-p file (concat file c)) (setq files (remove (concat file c) files)) (setq files (cdr files)) (setq file (concat file c) (if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file))) (setq files (cdr files)))
(let ((files (directory-files (expand-file-name (substitute-in-file-name dir)) t \\.elc?$))) (while files (let ((file (car files))) (if (file-exists-p (concat file c)) (progn (if (file-newer-than-file-p file (concat file c)) (setq files (remove ... files)) (setq files (cdr files)) (setq file (concat file c) (if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file))) (setq files (cdr files
Re: [O] python sessions
Am 25.03.2013 17:43, schrieb Eric Schulte: John Hendy jw.he...@gmail.com writes: On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: Yes, because my example only works in external (non session) execution with the current buggy code, where as your example works with session execution in the old working code. x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. Aha! Thanks for sleuthing this out. So the problem lies in changes to the python.el distributed with Emacs. I don't suppose we can ask whoever made these changes to python.el to fix the breakage they've caused in Org-mode? Thanks, Please give me some time still to investigate. Still doubt it's python.el But if yes, probably will be able to tell more. Best, Andreas
Re: [O] python sessions
Am 24.03.2013 19:41, schrieb Nick Dokos:
running into this, func def seems missing:
Debugger entered--Lisp error: (void-function org-babel-result-cond)
(org-babel-result-cond result-params results
(org-babel-python-table-or-string results))
(if (string= (substring org-babel-python-eoe-indicator 1 -1) results) nil
(org-babel-result-cond result-params results (org-babel-python-table-or-string
results)))
(unless (string= (substring org-babel-python-eoe-indicator 1 -1) results)
(org-babel-result-cond result-params results (org-babel-python-table-or-string
results)))
(lambda (results) (unless (string= (substring org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results
(org-babel-python-table-or-string results(Traceback (most recent call last):\n File \stdin\, line 1, in module\nNameError: name 'foo' is not defined\nbye)
(let* ((send-wait (lambda nil (comint-send-input nil t) (sleep-for 0 5))) (dump-last-value (lambda (tmp-file pp) (mapc (lambda (statement) (insert statement) (funcall
send-wait)) (if pp (list import pprint (format open('%s', 'w').write(pprint.pformat(_)) ...)) (list (format open('%s', 'w').write(str(_)) ...)) (input-body
(lambda (body) (mapc (lambda (line) (insert line) (funcall send-wait)) (split-string body [ \n])) (funcall send-wait ((lambda (results) (unless (string= (substring
org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results (org-babel-python-table-or-string results (case result-type (output
(mapconcat (function org-babel-trim) (butlast (org-babel-comint-with-output (session org-babel-python-eoe-indicator t body) (funcall input-body body) (funcall send-wait)
(funcall send-wait) (insert org-babel-python-eoe-indicator) (funcall send-wait)) 2) \n)) (value (let ((tmp-file (org-babel-temp-file python-)))
(org-babel-comint-with-output (session org-babel-python-eoe-indicator nil body) (let (...) (funcall input-body body) (funcall dump-last-value tmp-file ...) (funcall
send-wait) (funcall send-wait) (insert org-babel-python-eoe-indicator) (funcall send-wait))) (org-babel-eval-read-file tmp-file))
org-babel-python-evaluate-session(#buffer *Python* print(foo(100)) \nprint \bye\ output
(output replace))
(if session (org-babel-python-evaluate-session session body result-type
result-params) (org-babel-python-evaluate-external-process body result-type
result-params preamble))
org-babel-python-evaluate(#buffer *Python* print(foo(100)) \nprint \bye\ output
(output replace) nil)
(let* ((session (org-babel-python-initiate-session (cdr (assoc :session params (result-params (cdr (assoc :result-params params))) (result-type (cdr (assoc
:result-type params))) (return-val (when (and (eq result-type (quote value)) (not session)) (cdr (assoc :return params (preamble (cdr (assoc :preamble params)))
(full-body (org-babel-expand-body:generic (concat body (if return-val (format \nreturn %s return-val) )) params (org-babel-variable-assignments:python params))) (result
(org-babel-python-evaluate session full-body result-type result-params preamble))) (org-babel-reassemble-table result (org-babel-pick-name (cdr (assoc :colname-names
params)) (cdr (assoc :colnames params))) (org-babel-pick-name (cdr (assoc :rowname-names params)) (cdr (assoc :rownames params)
org-babel-execute:python(print(foo(100)) \nprint \bye\ ((:comments . #1=) (:shebang . #1#) (:cache . no) (:padline . #1#) (:noweb . no) (:tangle . no)
(:exports . results) (:results . replace output) (:hlines . no) (:padnewline . yes) (:session) (:result-type . output) (:result-params output replace)
(:rowname-names) (:colname-names)))
org-babel-execute-src-block(nil (python print(foo(100)) \nprint \bye\ ((:comments . #1=) (:shebang . #1#) (:cache . no) (:padline . #1#) (:noweb . no)
(:tangle . no) (:exports . results) (:results . replace output) (:hlines . no) (:padnewline . yes) (:session) (:result-type . output) (:result-params output
replace) (:rowname-names) (:colname-names)) nil 0))
org-babel-execute-src-block-maybe()
org-babel-execute-maybe()
org-babel-execute-safely-maybe()
run-hook-with-args-until-success(org-babel-execute-safely-maybe)
org-ctrl-c-ctrl-c(nil)
call-interactively(org-ctrl-c-ctrl-c nil nil)
Re: [O] python sessions
Am 23.03.2013 23:07, schrieb Eric Schulte: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 21.03.2013 08:43, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Nonetheless, still thinking let-var session in org-babel-execute:python needs the fix. I've not been following this thread, can you send a patch with the fix and the reason for it? Thanks in advance! Hi Bastien, unfortunately my org-environment isn't ready yet for developing. Might take some time, but I'm on it. I also haven't been following this thread. Forgetting a patch for the moment, is it possible to conclusively state that there is or isn't a bug in the current ob-python handling and naming of sessions? If there is, is there a recipe for reproducing this bug? Thanks, Hi, Ista proved it works for him. ca+vqilhuwvgogszto9981nxxbyhnkmcb-rdhbdy8nehypzu...@mail.gmail.com Maybe we all other have incomplete resp. not updated installations? Best regards, Andreas
Re: [O] python sessions
Am 24.03.2013 15:47, schrieb John Hendy: On Sun, Mar 24, 2013 at 2:47 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 23.03.2013 23:07, schrieb Eric Schulte: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 21.03.2013 08:43, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Nonetheless, still thinking let-var session in org-babel-execute:python needs the fix. I've not been following this thread, can you send a patch with the fix and the reason for it? Thanks in advance! Hi Bastien, unfortunately my org-environment isn't ready yet for developing. Might take some time, but I'm on it. I also haven't been following this thread. Forgetting a patch for the moment, is it possible to conclusively state that there is or isn't a bug in the current ob-python handling and naming of sessions? If there is, is there a recipe for reproducing this bug? Thanks, Hi, Ista proved it works for him. ca+vqilhuwvgogszto9981nxxbyhnkmcb-rdhbdy8nehypzu...@mail.gmail.com This opens up a compose window in gmail for me. mmh, picked the field thought as message-ID seems not to work that way. I think this is the thread you might have wanted to point to: - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68267.html rather this http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68273.html Cheers
Re: [O] tests with travis-ci
Am 21.03.2013 21:41, schrieb Bastien: [ ... ] Yes. The limitation of the pre-push hook comes from the fact that various developers may have various testing environments, no one should be prevented from pushing by the fact that tests do not pass for someone else. [ ... ] Hi, just to ask about some more aspects: - Typos often will break it from the beginning, so complete tests must not run all every time. Will some testing at all is needed to detect the typos... - org-mode has already a directory testing. It was not obvious for me how to make use of it. Exists some docu wrt available tests? - usually you know about the range of changes. Limited tests checking certain features seem useful Best, Andreas
Re: [O] tests with travis-ci
Am 22.03.2013 13:55, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de wrote: [ ... ] Not worth bothering about IMO: just run the whole test suite. Nick Hi Nick, thanks a lot for your explanation and patience. Still digging in... :) Andreas
Re: [O] python sessions
Am 21.03.2013 02:56, schrieb Gary Oberbrunner: Hi Gary, great if you can make it work for you. Nonetheless, still thinking let-var session in org-babel-execute:python needs the fix. Best, Andreas
