Re: [O] babel python example not reproducible
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 On Mon, Jun 16, 2014 at 9:12 AM, Doyley, Marvin wrote: > Hi Eric, > > Thanks for showing me the smart way of doing this. > > cheers, > M > -- > > > >
Re: [O] Switching to DONE does not clock-out
Bastien writes: >> If I am asking this, it is because earlier today, it did not work >> exactly like I would I have expected: it clocked-out the task *but* it >> did not update the time count. > > What do you mean by "update the time count"? > Can you show the CLOCK: lines and what you expected instead. ** DONE test of clock SCHEDULED: <2014-06-17 Tue> - State "DONE" from "STARTED"[2014-06-17 Tue 06:58] - State "STARTED"from "TODO" [2014-06-17 Tue 06:56] :LOGBOOK: CLOCK: [2014-06-17 Tue 06:56] :END: :PROPERTIES: :ID: AE6B33B5-F7DD-4A14-B5DC-B623023B4F3F :CREATED: [2014-06-17 Tue 06:55] :END: I would have expected something like: ** DONE test of clock SCHEDULED: <2014-06-17 Tue> - State "DONE" from "STARTED"[2014-06-17 Tue 06:58] - State "STARTED"from "TODO" [2014-06-17 Tue 06:56] :LOGBOOK: CLOCK: [2014-06-17 Tue 06:56] -- [2014-06-17 Tue 06:58] => 0:02 :END: :PROPERTIES: :ID: AE6B33B5-F7DD-4A14-B5DC-B623023B4F3F :CREATED: [2014-06-17 Tue 06:55] :END: Instead. Regards -- XMA
Re: [O] babel C, C++, D enhancement
t...@tsdye.com (Thomas S. Dye) writes: > Aloha Thierry, > > How about a user-customizable variable with a default value of > 2147483647? > > All the best, > Tom > > Thierry Banel writes: > >> Hi Achim. >> >> You are right, INT_MAX is the C++ constant to compare to. >> It is defined in limits.h >> >> I'm not sure I want to locate limits.h (where is it ? are there several >> versions ?), >> and parse it, all from within Emacs-lisp... >> And this will have to be done for all languages (Python, Perl, Java, and >> so on), >> not just C++. >> >> Or we could assume that INT_MAX is always 2147483647. >> (Which of course is not true). >> >> Not so easy... >> You don't need to parse limits.h: for POSIX systems, one can use `getconf INT_MAX' from the shell. `getconf -a' will list all the names. Nick
Re: [O] Switching to DONE does not clock-out
Hi, nore...@maillard.im writes: > When updating the task state from TODO to DONE, is it supposed to > clock-out With the default value for `org-clock-out-when-done', yes. > *and* update the time spent since latest clock-in ? Not sure what it means: clocking out when switching from TODO to DONE will clock out the task. > If I am asking this, it is because earlier today, it did not work > exactly like I would I have expected: it clocked-out the task *but* it > did not update the time count. What do you mean by "update the time count"? Can you show the CLOCK: lines and what you expected instead. Thanks, -- Bastien
[O] Switching to DONE does not clock-out
Hello, Just a quick question. When updating the task state from TODO to DONE, is it supposed to clock-out *and* update the time spent since latest clock-in ? If I am asking this, it is because earlier today, it did not work exactly like I would I have expected: it clocked-out the task *but* it did not update the time count. Is it normal ? Thank you -- XMA
Re: [O] babel C, C++, D enhancement
Aloha Thierry,
How about a user-customizable variable with a default value of
2147483647?
All the best,
Tom
Thierry Banel writes:
> Hi Achim.
>
> You are right, INT_MAX is the C++ constant to compare to.
> It is defined in limits.h
>
> I'm not sure I want to locate limits.h (where is it ? are there several
> versions ?),
> and parse it, all from within Emacs-lisp...
> And this will have to be done for all languages (Python, Perl, Java, and
> so on),
> not just C++.
>
> Or we could assume that INT_MAX is always 2147483647.
> (Which of course is not true).
>
> Not so easy...
>
> Regards
> Thierry
>
> Le 16/06/2014 20:28, Achim Gratz a écrit :
>> Thierry Banel writes:
>>> So Babel C++ may cause problem for large integers.
>>> I am not sure how we can fix this in any case.
>> You'd need to know INT_MAX and give an error for larger values or use an
>> integral type that is large enough to handle Emacs' integer (which would
>> most likely be necessary for any Emacs that uses wide integer).
>>
>>> In the meantime, we can force large values to be declared as doubles by
>>> adding dot zero
>>> like this:
>>>
>>> #+BEGIN_SRC C++ :var large=9876543210 .0
>>> printf ("%g", large);
>>> #+END_SRC
>> That will lose precision, so it may not be the right thing either.
>>
>>
>> Regards,
>> Achim.
>
>
>
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] babel C, C++, D enhancement
Hi Achim.
You are right, INT_MAX is the C++ constant to compare to.
It is defined in limits.h
I'm not sure I want to locate limits.h (where is it ? are there several
versions ?),
and parse it, all from within Emacs-lisp...
And this will have to be done for all languages (Python, Perl, Java, and
so on),
not just C++.
Or we could assume that INT_MAX is always 2147483647.
(Which of course is not true).
Not so easy...
Regards
Thierry
Le 16/06/2014 20:28, Achim Gratz a écrit :
> Thierry Banel writes:
>> So Babel C++ may cause problem for large integers.
>> I am not sure how we can fix this in any case.
> You'd need to know INT_MAX and give an error for larger values or use an
> integral type that is large enough to handle Emacs' integer (which would
> most likely be necessary for any Emacs that uses wide integer).
>
>> In the meantime, we can force large values to be declared as doubles by
>> adding dot zero
>> like this:
>>
>> #+BEGIN_SRC C++ :var large=9876543210 .0
>> printf ("%g", large);
>> #+END_SRC
> That will lose precision, so it may not be the right thing either.
>
>
> Regards,
> Achim.
Re: [O] babel C, C++, D enhancement
Thierry Banel writes:
> So Babel C++ may cause problem for large integers.
> I am not sure how we can fix this in any case.
You'd need to know INT_MAX and give an error for larger values or use an
integral type that is large enough to handle Emacs' integer (which would
most likely be necessary for any Emacs that uses wide integer).
> In the meantime, we can force large values to be declared as doubles by
> adding dot zero
> like this:
>
> #+BEGIN_SRC C++ :var large=9876543210 .0
> printf ("%g", large);
> #+END_SRC
That will lose precision, so it may not be the right thing either.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] Checkboxes with org-list-allow-alphabetical
Using Org-mode version 8.2.6 (release_8.2.6-1) git master 25fc4d: Alphabetic ordered lists do not seem to work with checkboxes: : (setq org-list-allow-alphabetical t) Type a checkbox, but org doesn't seem to parse it: : * heading : : 1. [ ] numeric heading :a. [ ] alphabetic subheading (typed but not checkbox faced or C-c usable) Use keychord to create next item with checkbox, but also not parsed: : * heading : : 1. [ ] numeric heading :a. alphabetic subheading(point here, press M-S-RET) :b. [ ] (creates this, not checkbox faced or C-c usable) Is this expected behavior? Do I need to enable additional options? Thanks, Jeff
Re: [O] Errors after upgrading emacs to 24.3.1 and org to 7.9.4
On Monday, 16 Jun 2014 at 15:43, Francisco Fernández wrote: [...] > I'm new on this. And I have the same problem > > Where do you exactly change "modeline" to "mode-line" Wherever you have a reference to "modeline" in your initialisation files. If you cannot find that reference, try starting emacs with --debug-init which should tell you where it fails. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.2, Org release_8.2.6-1155-g9c57eec
Re: [O] inclusion of #+RESULTS in a source block
Federico Beffa ieee.org> writes: > > > > Suppose you want to use a program such as Sympy or Maxima to find > the analytic solution of a complicated equation. After this you > want to make use of that solution for numerical evaluation of > various cases. See http://orgmode.org/manual/Noweb-reference-syntax.html#Noweb-reference-syntax You want something like #+BEGIN_SRC python :noweb yes <> #+END_SRC To use in more than one src-block use the `:cache yes' header for `analytic-sol' HTH, Chuck
Re: [O] babel python example not reproducible
Hi Eric, Thanks for showing me the smart way of doing this. cheers, M --
Re: [O] org-weather for openweathermap.org
Thanks, I will change the api cheers, M --
Re: [O] org-weather for openweathermap.org
mdoy...@ur.rochester.edu (Doyley, Marvin) writes: > I love this app, but there is only one snag. Changing the temperature units > from Celsius to Fahrenheit doesn't work. I get the same results regards > of the units in specified in the org-weather-unit variable [I don't have an org-weather-unit variable, so I presume you mean org-weather-temperature-unit.] Yes, one needs to change the API URL as well to get different units: , | (defvar org-weather-api-url "http://api.openweathermap.org/data/2.5/forecast/daily?q=%s&mode=json&units=metric&cnt=7";) ` AFAICT, they provide "metric", "imperial" and "internal" (don't know what the last one means). org-weather.el itself does not do any units conversions. Nick
Re: [O] Linked tasks
Hi Eric, Thank you, I will have a closer look at org-depend, although it seems to me that it's more 'depend' in the sense of 'this task has to be done for this other task to be doable'. But I only had a glimpse on the code. Regards, FC On Sat, Jun 14, 2014 at 10:19 AM, Eric Abrahamsen wrote: > Fletcher Charest writes: > > > Dear all, > > > > I was wondering if there was a way to link the status of two tasks in > > an agenda file (or even across multiple agenda files). Sometimes, a > > single task (in my case, updating my CV) might be a useful step in > > two different projects. If the tasks is marked DONE in one project > > (in one subtree), I would like the other one to be marked DONE as > > well. Is it possible or even implemented? > > > > Cheers, > > > > FC > > There's an org-depend package in the contrib directory that's supposed > to do this, but I haven't looked at it before... Vanilla Org only does > dependencies within the same subtree. > > E > > >
Re: [O] Errors after upgrading emacs to 24.3.1 and org to 7.9.4
Chris Henderson gmail.com> writes: > > On Fri, Mar 22, 2013 at 3:38 AM, Eric S Fraga ucl.ac.uk> wrote: > > Chris Henderson gmail.com> writes: > > > >> I have upgraded emacs from version 24 to 24.3.1 via homebrew on os x > >> mountain lion and every time I start emacs I get error: > >> > >> error: Invalid face, modeline > > > > modeline changed to mode-line a while back although probably sometime > > between 24 and 24.3.1 (I track emacs-snapshot). It could be that you > > have a custom face set that depends on modeline? > > Thanks, I have changed "modeline" to "mode-line" and it's now working fine. > > Hi, I'm new on this. And I have the same problem Where do you exactly change "modeline" to "mode-line"
Re: [O] org-weather for openweathermap.org
On 16/06/14 11:45, Thorsten Jolitz wrote: Ian Barton writes: On 15/06/14 12:54, Thorsten Jolitz wrote: Not sure though if this data (except the moon phase) is as universally and easily available as the data you display Sunset and rise would be interesting too of course. You can get sunrise and sunset by doing something like in an Agenda file: * Weather. Lat N 51 57.931 Long W 03 33.191 #+CATEGORY: Day/Year &%%(diary-day-of-year) #+CATEGORY: Weather %%(diary-sunrise) %%(diary-sunset) Thanks, had to use this to make it work: #+CATEGORY: Citiy %%(diary-sunrise-sunset) City: 6:32.. Sunrise (CEST), sunset 11:16pm (CEST) But somehow lat/long are right, but time is 2h off ... I'm GMT+2 (CEST) here. Where is the time adjusted for diary entries? The Emacs manual has the information: https://www.gnu.org/software/emacs/manual/html_node/emacs/Daylight-Saving.html#Daylight-Saving Also information on Lunar phases: https://www.gnu.org/software/emacs/manual/html_node/emacs/Lunar-Phases.html#Lunar-Phases Ian.
Re: [O] customizable C, C++, D, Java, Groovy compilers
Applied, Thanks!
Thierry Banel writes:
> Hi all
>
> Here is a patch to make compilers customizable
> (by typing M-x customize-group org-babel).
> It applies to C, C++, D, Java, Groovy.
> This is consistent with customizations for R, Python, Ditaa and others
> languages.
>
> Have fun
> Thierry
>
>
>
> From 933f50c3fbebefec14b5df8ebff0cebaf3e45922 Mon Sep 17 00:00:00 2001
> From: Thierry Banel
> Date: Sun, 15 Jun 2014 14:53:34 +0200
> Subject: [PATCH] Make C, C++, D, Java, Groovy compilers customizable
>
> * ob-C.el (org-babel-C-compiler):
> (org-babel-C++-compiler):
> (org-babel-D-compiler): changed defvar to defcustom
> * ob-java.el (org-babel-java-command):
> (org-babel-java-compiler): changed defvar to defcustom
> * ob-groovy.el (org-babel-groovy-command):
> changed defvar to defcustom
> ---
> lisp/ob-C.el | 36 ++--
> lisp/ob-groovy.el | 10 --
> lisp/ob-java.el | 22 +-
> 3 files changed, 51 insertions(+), 17 deletions(-)
>
> diff --git a/lisp/ob-C.el b/lisp/ob-C.el
> index 505b290..2e146d4 100644
> --- a/lisp/ob-C.el
> +++ b/lisp/ob-C.el
> @@ -46,16 +46,32 @@
>
> (defvar org-babel-default-header-args:C '())
>
> -(defvar org-babel-C-compiler "gcc"
> - "Command used to compile a C source code file into an
> -executable.")
> -
> -(defvar org-babel-C++-compiler "g++"
> - "Command used to compile a C++ source code file into an
> -executable.")
> -
> -(defvar org-babel-D-compiler "rdmd"
> - "Command used to compile and execute a D source code file.")
> +(defcustom org-babel-C-compiler "gcc"
> + "Command used to compile a C source code file into an executable.
> +May be either a command in the path, like gcc
> +or an absolute path name, like /usr/local/bin/gcc
> +parameter may be used, like gcc -v"
> + :group 'org-babel
> + :version "24.3"
> + :type 'string)
> +
> +(defcustom org-babel-C++-compiler "g++"
> + "Command used to compile a C++ source code file into an executable.
> +May be either a command in the path, like g++
> +or an absolute path name, like /usr/local/bin/g++
> +parameter may be used, like g++ -v"
> + :group 'org-babel
> + :version "24.3"
> + :type 'string)
> +
> +(defcustom org-babel-D-compiler "rdmd"
> + "Command used to compile and execute a D source code file.
> +May be either a command in the path, like rdmd
> +or an absolute path name, like /usr/local/bin/rdmd
> +parameter may be used, like rdmd --chatty"
> + :group 'org-babel
> + :version "24.3"
> + :type 'string)
>
> (defvar org-babel-c-variant nil
>"Internal variable used to hold which type of C (e.g. C or C++ or D)
> diff --git a/lisp/ob-groovy.el b/lisp/ob-groovy.el
> index 9bb17e6..0068df9 100644
> --- a/lisp/ob-groovy.el
> +++ b/lisp/ob-groovy.el
> @@ -36,8 +36,14 @@
> (defvar org-babel-tangle-lang-exts) ;; Autoloaded
> (add-to-list 'org-babel-tangle-lang-exts '("groovy" . "groovy"))
> (defvar org-babel-default-header-args:groovy '())
> -(defvar org-babel-groovy-command "groovy"
> - "Name of the command to use for executing Groovy code.")
> +(defcustom org-babel-groovy-command "groovy"
> + "Name of the command to use for executing Groovy code.
> +May be either a command in the path, like groovy
> +or an absolute path name, like /usr/local/bin/groovy
> +parameters may be used, like groovy -v"
> + :group 'org-babel
> + :version "24.3"
> + :type 'string)
>
> (defun org-babel-execute:groovy (body params)
>"Execute a block of Groovy code with org-babel. This function is
> diff --git a/lisp/ob-java.el b/lisp/ob-java.el
> index 22f8785..8c64171 100644
> --- a/lisp/ob-java.el
> +++ b/lisp/ob-java.el
> @@ -32,11 +32,23 @@
> (defvar org-babel-tangle-lang-exts)
> (add-to-list 'org-babel-tangle-lang-exts '("java" . "java"))
>
> -(defvar org-babel-java-command "java"
> - "Name of the java command.")
> -
> -(defvar org-babel-java-compiler "javac"
> - "Name of the java compiler.")
> +(defcustom org-babel-java-command "java"
> + "Name of the java command.
> +May be either a command in the path, like java
> +or an absolute path name, like /usr/local/bin/java
> +parameters may be used, like java -verbose"
> + :group 'org-babel
> + :version "24.3"
> + :type 'string)
> +
> +(defcustom org-babel-java-compiler "javac"
> + "Name of the java compiler.
> +May be either a command in the path, like javac
> +or an absolute path name, like /usr/local/bin/javac
> +parameters may be used, like javac -verbose"
> + :group 'org-babel
> + :version "24.3"
> + :type 'string)
>
> (defun org-babel-execute:java (body params)
>(let* ((classname (or (cdr (assoc :classname params))
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] babel python example not reproducible
mdoy...@ur.rochester.edu (Doyley, Marvin) writes: > Hi Shiyuan, > > I think the problem is that Emacs or babel is using python located in > /usr/bin or /usr/local/sbin rather than default python or ipython. The way I > got > around this is rename python in these locations to python_old and then did > a soft link to ipython (i.e., ln -s /anaconda/bin/ipython python). > > I am sure there is a smarter way of telling babel to use ipython, but > this was my work around. > See the `org-babel-python-command' variable. > > Hope this help > cheers, > M > > > > -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] org-weather for openweathermap.org
I love this app, but there is only one snag. Changing the temperature units from Celsius to Fahrenheit doesn't work. I get the same results regards of the units in specified in the org-weather-unit variable cheers, M -- Marvin Doyley Associate Professor 343 Hopeman Engineering Building University of Rochester Department of Electrical and Computer Engineering Rochester NY 14627 585-275-3774 http://www.ece.rochester.edu/projects/doyley_lab/
[O] inclusion of #+RESULTS in a source block
Suppose you want to use a program such as Sympy or Maxima to find
the analytic solution of a complicated equation. After this you want
to make use of that solution for numerical evaluation of various
cases.
Is it safe to use the analytic results (without using a session) in the
following way, or is there a better way?
#+NAME: analytic-sol
#+BEGIN_SRC python :session none :results raw
from sympy import symbols, sqrt, python, solve
x, a = symbols("x, a")
y = solve( x**2 + 2*a*x + 1, x)
return python(y)
#+END_SRC
#+NAME: numeric-sol
#+BEGIN_SRC python :session none
from sympy import Symbol, sqrt, lambdify
import numpy as np
#+RESULTS: analytic-sol
a = Symbol('a')
e = [-a - sqrt(a**2 - 1), -a + sqrt(a**2 - 1)]
f = lambdify(a, e[1], "numpy")
t = np.r_[1:4]
return f(t)
#+END_SRC
#+RESULTS:
| -1 | -0.26794919 | -0.17157288 |
Regards,
Fede
Re: [O] Insert #+BEAMER_HEADER_EXTRA before \begin{document}?
Sebastien Vauban writes: >> About the keyword, my only concern is that #+LATEX_HEADER_EXTRA has >> already a specific meaning, which is different from the one we're going >> to implement. > > Can you restate once what the difference is between #+LATEX_HEADER > and #+LATEX_HEADER_EXTRA? It never has been clear to me, yet... The manual says: , |(2) Unlike `LATEX_HEADER', contents from `LATEX_HEADER_EXTRA' | keywords will not be loaded when previewing LaTeX snippets (*note | Previewing LaTeX fragments::). | ` AFAIK, that's the only difference. Nick
[O] capture template for interval
Dear All,
with a help of this mailinglist I have setup my capture template for
appointments as follows:
(setq org-capture-templates
'(
("a" "Appointment (compulsory)" entry (file+datetree (concat
my-org-files "diary.org"))
"* %? :appt:\n%a\n%^T\n\nEntered on %U")
))
This makes appointment in the diary.org file, it puts there a link to
the actually visited file (notmuch buffer mostly) and then asks for a
date+time.
Now this appears in my agenda, but only as as a simple date. Now I'd
like to get it done in a way that I enter one date time, and another one
is 'offered' to me in 2 hours in the future from the date I have given
as first.
So basically if I do not put the second date, it will by default create
an interval long 2 hours.
any possibility how to do this?
many thanks
..d
Re: [O] babel python example not reproducible
Hi Shiyuan, I think the problem is that Emacs or babel is using python located in /usr/bin or /usr/local/sbin rather than default python or ipython. The way I got around this is rename python in these locations to python_old and then did a soft link to ipython (i.e., ln -s /anaconda/bin/ipython python). I am sure there is a smarter way of telling babel to use ipython, but this was my work around. Hope this help cheers, M
Re: [O] Insert #+BEAMER_HEADER_EXTRA before \begin{document}?
Hello Nicolas,
> Sebastien Vauban writes:
>
>> But the whole point is that is DOES NOT even WORK for a couple of
>> things, such as modifying base colors of a theme:
>>
>> #+BEAMER_HEADER: \setbeamercolor{frametitle}{bg=blue}
>>
>> won't work because of the misplacement of the BEAMER_HEADER placeholder
>> regarding to the (color) theme: the above line will be placed before the
>> choice of the theme... TOO EARLY.
>>
>> On the contrary, adding it in the above title command (already in the
>> LaTeX document, that is) is TOO LATE.
Thanks for answering to this.
> I do not see how to solve this without either adding a new keyword or
> extending `org-latex-classes' to support another location (e.g.
> "[BEAMER-THEME]"). Actually, both may be needed.
IIUC the code of ox-beamer:
--8<---cut here---start->8---
;; 1. Time-stamp.
(and (plist-get info :time-stamp-file)
(format-time-string "%% Created %Y-%m-%d %a %H:%M\n"))
;; 2. Document class and packages.
...
(concat (org-element-normalize-string
(plist-get info :latex-header))
(org-element-normalize-string
(plist-get info :latex-header-extra))
(plist-get info :beamer-header-extra)
info)))
;; 3. Insert themes.
--8<---cut here---end--->8---
all 3 following keywords:
- #+LATEX_HEADER:
- #+LATEX_HEADER_EXTRA:
- #+BEAMER_HEADER:
are going to the exact same place, right?
Then, why not saying that, for example, both #+LATEX_HEADER
and #+LATEX_HEADER_EXTRA go to the current place, and
drop #+BEAMER_HEADER at the end of the preamble?
Maybe I see: because you want to associate such a place to an official
"location" such as [BEAMER-THEME], so that it can be enabled or
disabled?
> About the keyword, my only concern is that #+LATEX_HEADER_EXTRA has
> already a specific meaning, which is different from the one we're going
> to implement.
Can you restate once what the difference is between #+LATEX_HEADER
and #+LATEX_HEADER_EXTRA? It never has been clear to me, yet...
Thanks.
> So, #+BEAMER_HEADER_EXTRA might be confusing. OTOH
> I cannot think of anything much better.
>
> WDYT?
Maybe something more semantic, then, such
as #+BEAMER_HEADER_PREAMBLE_END or #+BEAMER_HEADER_END_PREAMBLE?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] proposal to have ignoreheading tags/properties
Nicolas Goaziou writes: > Hello, > > Eric Schulte writes: > >> In my opinion the manual interleaving of "noexport" and "export" tags is >> overly cumbersome and is non-obvious. > > It is as non-obvious as the task it achieves. > >> The obscure nature of this solution is evidenced by multiple >> discussions and implementations of filter functions to handle >> situations which could be covered by this noexport/export pattern. > > I don't know what you are referring to, since this "noexport/export" > pattern isn't implemented yet. Do you have an example of such > a discussion that dismissed said pattern? > >> I think the attached patch should be applied to the core. It includes >> the following. >> >> - a single new export function which removes the headlines and contents >> (the "section" element) of headlines tagged "ignoreexport", then >> retains and promotes all sub-headlines contained therein. >> >> - a single new export tag named "ignoreexport" (ignore seems to be the >> crowd favorite, and adding "export" reduces possible conflicts with >> existing personal tags) > > Thank you for the patch. > > Again, my concern is that it introduces another tag for a task that > could be possible without it. "export", "noexport", "ignoreexport": this > all gets confusing. Furthermore, this tag should, at the bare minimum, > be configurable so it also introduces another keyword on par with > SELECT_TAGS and EXCLUDE_TAGS. > > Moreover, that task is highly specific; I'm not convinced we should have > a dedicated keyword for each of them. I'd rather have a simple solution > for selective export problems, even if, as a generic solution, it may > look clumsier. > >> From the included tests, the effect of this patch is to convert a tree >> like the following, >> >> , >> | * H1 >> | Text1 >> | ** H2 >> :ignoreexport: >> | Text2 >> | *** H3 >> | Text3 >> | H4 >> | Text4 >> | *** H5 >> | Text5 >> | H6 >> :ignoreexport: >> | Text6 >> | * H7 >> | Text7 >> | * H8 >> | Text8 >> ` > > Note that my suggestion is > > , > | * H1 > | Text1 > | ** H2 :noexport: > | Text2 > | *** H3 :export: > | Text3 > | H4 > | Text4 > | *** H5 :export: > | Text5 > | H6:noexport: > | Text6 > | * H7 :export: > | Text7 > | * H8 :export: > | Text8 > ` > > In this case, it is more verbose. But the opposite would happen if you > needed to also ignore children within the "ignoreexport" headlines. > In order to get > > * H1 > ** H4 > > compare > > > * H1 > ** H2 :ignoreexport: > *** H3 :noexport: > *** H4 > > with > > * H1 > ** H2 :noexport: > *** H3 > *** H4:export: > > This time, the brevity of :ignoreexport: is not so clear. Also, it will > not prevent the need to nest tags at some points. IOW, it is only > efficient for one very specific use case. Outside of this case, the new > tag would just be an annoyance and you would fallback > to :noexport:/:export: nesting, if implemented. And if we cannot avoid > tags nesting, I'd take 2 "nesteable" tags over 3 any day. > > Another point to consider is that :noexport:/:export has the advantage > to mark explicitly what will be included in the export process. As such, > I don't find less obvious than your proposal: in both cases, you have to > understand the rules applied behind the keywords anyway. And these rules > are well-known for "export" and "noexport" tags. > This is a specific tag for a specific but common use case. I'll defer to your judgment on the exporting code and instead share a filter function which may be added to personal configurations (I've added this to the FAQ as well [1]). Having looked more closely at my use cases (documented in the attached implementation), including the contents of ignored headlines is required for most practical applications (which may make the parse tree invalid, but which works well for every export backend I've used thus far). ignore-headline.el Description: application/emacs-lisp > >> I'm sympathetic to arguments about maintaining simplicity of the core, >> and even more so to arguments about maintaining structural validity of >> trees during export. I believe that this revised patch fully maintains >> valid tree structures, and I'd suggest that the increase in complexity >> of a single keyword is justified by the demonstrated user demand for >> this functionality. > > It mostly preserves tree structure, indeed. More comments about this > below. > > Just to be clear: I'm not
Re: [O] Capturing outgoing gnus e-mail
Esben Stien writes: > Eric Abrahamsen writes: > >> [1]: https://github.com/girzel/gnorb > > "Some way to create a TODO for an outgoing mail, saying 'this mail needs > a response, check in N days to see if we’ve got one.'" > > That's really cool and I've been looking for ages for something like that;) Give it a shot! gnorb-gnus-outgoing-do-todo, and then schedule the resulting capture heading. Hope it works for you, E
Re: [O] org-weather for openweathermap.org
On 2014-06-16 10:04, Rüdiger Sonderfeld writes: > Hi, > > On Saturday 14 June 2014 15:11:21 Chris Raschl wrote: >> recently I wanted to add a weather forecast to my org-agenda. I found >> org-google-weather, but this package is obsolete since 2012, because the >> API is not available any more. So I wrote my own version which is backed >> by the openweathermap.org API. > > I've written the `weather-metno-el' package. Which uses the weather data > from > met.no (CC licensed). It supports showing weather data in the org-agenda as > well. > > https://github.com/ruediger/weather-metno-el When it rains it pours (sorry ...) I've tried both packages and they are very nice. Thanks a lot! Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgpHtsMp5zZ7L.pgp Description: PGP signature
Re: [O] babel python example not reproducible
Shiyuan writes: > The two setting doesn't seem to have effect. > (setq python-shell-interpreter "ipython") > (setq python-shell-interpreter-args "--pylab") > > When I did `C-c C-c` on the SRC block to execute the code, emacs > created a buffer with the interior python process. When I switched to > the process, I saw it is python 2.5.3, not ipython. > > Also, it looks like the problem is with the shell interpreter. If I > enter command directly in the shell buffer, the shell buffer will echo > command itself and then the result. > print "Hello" > print "Hello" > Hello. > > Is there any setting to control this shell behavior? Can I make the > python shell not echo the command? Thanks. > When a *shell* does that to me, I do (on Linux) $ stty -echo but I'm not sure where that would fit into your setup. Nick
Re: [O] proposal to have ignoreheading tags/properties
Nicolas Goaziou nicolasgoaziou.fr> writes: > Moreover, that task is highly specific; I'm not convinced we should have > a dedicated keyword for each of them. I'd rather have a simple solution > for selective export problems, even if, as a generic solution, it may > look clumsier. Hi Nicolas, I agree that the nested use of :export: and :noexport: symmetric is a good feature to implement. I think the main point of contention that I and others may have is that even if the :ignoreexport: (or whatever you wish to call it) tag is "highly specific" w.r.t. the variety of export/noexport arrangements one can have, it is also highly useful. While implementing a specific tag for this task may not be wise to implement at this time, there should be *some* way that an org-mode user can avoid being required to manually add export tags to every child of a noexport node in order to achieve this "summary node" functionality. In order to make it possible to add a non-exported summary-node (i.e. a node which we might have marked as :ignoreexport:) at any location in the tree without needing to add N more tags for all of the children, one would need to somehow "by default" have :export: tags implicit on all nodes, unless a :noexport: tag was on a node which would override the behavior of the :export: tag. Maybe there needs to be a way to decide whether a specific tag (i.e. on a specific headline) will be applied recursively or not -- e.g. if the tag has a "*" suffix appended to it, then it is applied to all descendants recursively, but otherwise it applies only to the single headline it is on. Ultimately I see the problem of having to tag all of the children as stemming from this default behavior of tags being recursive. Having control of their "recursivitiy" would alleviate the problem. Regards, Mark
Re: [O] Tangling with variables in R
Andreas Leha writes:
> Hi Rainer,
Hi Andreas,
>
> Rainer M Krug writes:
>
>> Hi
>>
>> I just realized (again) that tangling with variables in R contains many
>> particularities.
>>
>> 1) it only works with non-tables, i.e. single values.
>>
>> When defining the following variables:
>>
>> #+NAME: YEARS
>> | | year |
>> |---+---|
>> | 1 | 1990 |
>> | 2 | 2000 |
>> #+PROPERTY: var+ YEARS=YEARS
>> #+PROPERTY: var+ PRESENT=2008
>>
>>
>> I get the following code in the tangled .R file:
>>
>> ,
>> | YEARS <-
>> read.table("/var/folders/50/wcr5bjwn75q595n6x82gxj28gn/T/babel-97151aBD/R-import-97151vpn",
>> | header=TRUE,
>> | row.names=1,
>> | sep="\t",
>> | as.is=TRUE)
>> | PRESENT <- 2008
>> `
>>
>> Variable transfer from tables does not work, as it is based on a
>> temporary file, which is not easy to distribute together with the
>> tangled.R file and requires manual work as the path will be different.
>>
>> I consider this as a bug which should be fixed.
>
> Me too, see http://thread.gmane.org/gmane.emacs.orgmode/51067
>
OK - then I will include a fix to the tangling of tables issue in one of
my first patches.
>
>>
>> 2) With regards to variables which are defined non-file wide, (i.e. in
>> properties in a subtree and variables defined per code block and
>> function call), these are set when they occur in the tangled code, but
>> they are not unset *for the next code block* or *for R code in the next
>> subtree* (I hope you know what I mean). They are therefore similar to
>> the use of a session header argument instead of non-session evaluation
>> of the code.
>>
>> This is a (conceptually) a more complex issue, and requires some initial
>> thought on how this should be dealt with and how the tangled code should
>> relate to the executed code.
>>
>> - Should the tangled .R file result in the same output as the execution in
>> the org file, i.e. an accompanying .R file to a exported pdf, so that
>> the .R file can be used to reproduce the graphs and analysis in the .pdf
>> exported from the .org? or
>>
>> - Is tangling a completely thing to execution, and the resulting R code
>> in the .R file is not expected to reproduce the results in the org file?
>>
>> - Finally, does tangling with variables makes sense?
>>
>> My opinions are
>>
>> a) *All* variables should be transferred to the .R file. This can be
>> already disabled via the :no-expand header argument. Unfortunately, this
>> is combined with noweb expansion, and it might be useful to split these
>> two, i.e. to be able to only disable variable expansion but to keep
>> noweb (I don't use noweb so far, so it is not a problem to me as it is
>> now).
>>
>> b) The variable assignments should be per code block / function call. So
>> a tangled block should look as follow:
>>
>> #+NAME: YEARS
>> | | year |
>> |---+---|
>> | 1 | 1990 |
>> | 2 | 2000 |
>> #+PROPERTY: var+ YEARS=YEARS
>> #+PROPERTY: var+ PRESENT=2008
>>
>> #+begin_src R
>> x <- 4
>> cat(x^2)
>> #+end_src
>>
>> should result in something like the following:
>>
>> ,
>> | ## # Set the variables
>> | YEARS <- TRANSFER_TABLE()
>> | PRESENT <- TRANSFER_VALUE()
>> | ## Here begins the real code
>> | x <- 4
>> | cat(x^2)
>> | ## # Unset all variables previously set
>> `
>>
>> but I prefer the following approach, as the result would be very
>> similar, only that the variables are still present afterwards which
>> would make debugging easier:
>>
>> ,
>> | ## # Unset all variables previously set
>> | ## # Set the variables
>> | YEARS <- TRANSFER_TABLE()
>> | PRESENT <- TRANSFER_VALUE()
>> | ## Here begins the real code
>> | x <- 4
>> | cat(x^2)
>> `
>>
>> This is effectively already implemented by using R environments. See [1]
>> and particularly [2] and [3] for how it is implemented. This does not
>> yet address the concern about the transfer of tables, but I will look at
>> this.
>
> These are good thoughts!
Thanks.
>
> For the general question on whether tangling should directly reflect
> weaving, there was a long (and fruitless) discussion or R-devel lately.
> See http://thread.gmane.org/gmane.comp.lang.r.devel/36031 and maybe
> http://thread.gmane.org/gmane.comp.lang.r.devel/36031/focus=36075 where
> Yihui states that it is very hard to tangle code that produces the
> same result as weaving. This might actually be easier in org than in
> Sweave/knitr, but still the org setup will have a big impact, that would
> be hard to replicate in the tangled R code.
I agree completely - but it might be worth to try to go into this
direction rather then blocking it with choosing the wrong approach
initially.
>
> Setting aside the general question:
> In my opinion, it should definitely be possible to tangle with
> variables. I think the approach of the environments to address (2) is a
> good one.
OK - I will p
Re: [O] org-weather for openweathermap.org
Ian Barton writes: > On 15/06/14 12:54, Thorsten Jolitz wrote: > > > >> >> Not sure though if this data (except the moon phase) is as universally >> and easily available as the data you display Sunset and rise would >> be interesting too of course. >> > > You can get sunrise and sunset by doing something like in an Agenda file: > > * Weather. > > Lat N 51 57.931 > Long W 03 33.191 > > #+CATEGORY: Day/Year > &%%(diary-day-of-year) > #+CATEGORY: Weather > > %%(diary-sunrise) > %%(diary-sunset) Thanks, had to use this to make it work: #+CATEGORY: Citiy %%(diary-sunrise-sunset) City: 6:32.. Sunrise (CEST), sunset 11:16pm (CEST) But somehow lat/long are right, but time is 2h off ... I'm GMT+2 (CEST) here. Where is the time adjusted for diary entries? -- cheers, Thorsten
Re: [O] org-weather for openweathermap.org
On 15/06/14 12:54, Thorsten Jolitz wrote: Not sure though if this data (except the moon phase) is as universally and easily available as the data you display Sunset and rise would be interesting too of course. You can get sunrise and sunset by doing something like in an Agenda file: * Weather. Lat N 51 57.931 Long W 03 33.191 #+CATEGORY: Day/Year &%%(diary-day-of-year) #+CATEGORY: Weather %%(diary-sunrise) %%(diary-sunset) Ian.
Re: [O] org-weather for openweathermap.org
Chris Raschl writes: Hi, I made a little table comparing Beaufort and m/s with data from Deutscher Wetterdienst, text is in German therefore, but the numbers are not fortunately, so the table might be usefull for others too (after deleting the text columns). * Windwarnskala Quelle: [[http://www.wettergefahren.de/warnungen/windwarnskala.html][Deutscher Wetterdienst]] | Beaufort | Label | m/s | Beschreibung | |--++---+--| |0 | Windstille | 0 | Rauch steigt senkrecht auf | |1 | leiser Zug | 1 | Windrichtung angezeigt durch den Zug des Rauches | |2 | leichte Brise | 2 bis 3 | Wind im Gesicht spürbar, Blätter und Windfahnen bewegen sich | |3 | schwache Brise | 4 bis | Wind bewegt dünne Zweige und strecktWimpel | | | schwacher Wind | 5 | | |4 | mäßige Brise | 6 bis | Wind bewegt Zweige und dünnere Äste,hebt Staub und loses Papier | | | mäßiger Wind | 7 | | |5 | frische Brise | 8 bis | kleine Laubbäume beginnen zu schwanken, Schaumkronen bilden sich auf See | | | frischer Wind | 10| | |6 | starker Wind | 11 bis| starke Äste schwanken, Regenschirme sind nur schwer zu halten, Telegrafenleitungen | | | pfeifen im Wind| 13| | |7 | steifer Wind | 14 bis 17 | fühlbare Hemmungen beim Gehen gegen den Wind, ganze Bäume bewegen sich | |8 | stürmischer Wind | 18 bis 20 | Zweige brechen von Bäumen, erschwert erheblich das Gehen im Freien | |9 | Sturm | 21 bis 24 | Äste brechen von Bäumen, kleinere Schäden an Häusern (Dachziegel oder Rauchhauben abgehoben) | | 10 | schwerer Sturm | 25 bis 28 | Wind bricht Bäume, großere Schäden an Häusern| | 11 | orkanartiger Sturm | 29 bis 32 | Wind entwurzelt Bäume, verbreitet Sturmschäden | | 12 | Orkan | ab 33 | schwere Verwüstungen | -- cheers, Thorsten
Re: [O] Link to Top Most Heading
Esben Stien writes:
> I'm trying to figure out how I can get a link to the top most heading
> without actually moving point up there and doing C-c C-l.
>
> Is there some function to do that?
>
> If I try using the function outline-previous-heading, how can I know
> when I've reached the top as it seems to just bang its head in the roof
> of the file when it reaches the top. It also finds stuff above the
> topmost heading, like lines beginning with "#".
>
> Any pointers as to what I can try?
I don't know if `org-goto-first-headline' is implemented, but e.g. this
function shows how to do it, since it needs to find first headline too:
(defun org-first-headline-recenter ()
"Move cursor to the first headline and recenter the headline."
(goto-char (point-min))
(when (re-search-forward (concat "^\\(" org-outline-regexp "\\)") nil t)
(set-window-start (selected-window) (point-at-bol
--
cheers,
Thorsten
Re: [O] proposal to have ignoreheading tags/properties
Hello, Eric Schulte writes: > In my opinion the manual interleaving of "noexport" and "export" tags is > overly cumbersome and is non-obvious. It is as non-obvious as the task it achieves. > The obscure nature of this solution is evidenced by multiple > discussions and implementations of filter functions to handle > situations which could be covered by this noexport/export pattern. I don't know what you are referring to, since this "noexport/export" pattern isn't implemented yet. Do you have an example of such a discussion that dismissed said pattern? > I think the attached patch should be applied to the core. It includes > the following. > > - a single new export function which removes the headlines and contents > (the "section" element) of headlines tagged "ignoreexport", then > retains and promotes all sub-headlines contained therein. > > - a single new export tag named "ignoreexport" (ignore seems to be the > crowd favorite, and adding "export" reduces possible conflicts with > existing personal tags) Thank you for the patch. Again, my concern is that it introduces another tag for a task that could be possible without it. "export", "noexport", "ignoreexport": this all gets confusing. Furthermore, this tag should, at the bare minimum, be configurable so it also introduces another keyword on par with SELECT_TAGS and EXCLUDE_TAGS. Moreover, that task is highly specific; I'm not convinced we should have a dedicated keyword for each of them. I'd rather have a simple solution for selective export problems, even if, as a generic solution, it may look clumsier. > From the included tests, the effect of this patch is to convert a tree > like the following, > > , > | * H1 > | Text1 > | ** H2 > :ignoreexport: > | Text2 > | *** H3 > | Text3 > | H4 > | Text4 > | *** H5 > | Text5 > | H6 > :ignoreexport: > | Text6 > | * H7 > | Text7 > | * H8 > | Text8 > ` Note that my suggestion is , | * H1 | Text1 | ** H2 :noexport: | Text2 | *** H3 :export: | Text3 | H4 | Text4 | *** H5 :export: | Text5 | H6:noexport: | Text6 | * H7 :export: | Text7 | * H8 :export: | Text8 ` In this case, it is more verbose. But the opposite would happen if you needed to also ignore children within the "ignoreexport" headlines. In order to get * H1 ** H4 compare * H1 ** H2 :ignoreexport: *** H3 :noexport: *** H4 with * H1 ** H2 :noexport: *** H3 *** H4:export: This time, the brevity of :ignoreexport: is not so clear. Also, it will not prevent the need to nest tags at some points. IOW, it is only efficient for one very specific use case. Outside of this case, the new tag would just be an annoyance and you would fallback to :noexport:/:export: nesting, if implemented. And if we cannot avoid tags nesting, I'd take 2 "nesteable" tags over 3 any day. Another point to consider is that :noexport:/:export has the advantage to mark explicitly what will be included in the export process. As such, I don't find less obvious than your proposal: in both cases, you have to understand the rules applied behind the keywords anyway. And these rules are well-known for "export" and "noexport" tags. > I'm sympathetic to arguments about maintaining simplicity of the core, > and even more so to arguments about maintaining structural validity of > trees during export. I believe that this revised patch fully maintains > valid tree structures, and I'd suggest that the increase in complexity > of a single keyword is justified by the demonstrated user demand for > this functionality. It mostly preserves tree structure, indeed. More comments about this below. Just to be clear: I'm not against implementing the functionality. We can implement it without increasing complexity, so the demand is hardly a justification for this added complexity. Making :export: and :noexport: tags symmetrical is a good thing anyway: why could we add :noexport: within :export: trees but not the other way? And, as I demonstrated earlier, combination of both permits more patterns than :ignoreexport:. Therefore, we should implement it in any case. As a bonus, it provides a solution for the problem at hand. If this solution happens to be inadequate, then we can discuss about better solutions, this time with more options (a user-defined hook, a macro, a command, even a new tag if we cannot escape it...). Anyway, some comments follow about your code. > +(defun org-export-ignore-headlines-retain-an
Re: [O] org-weather for openweathermap.org
Hi, On Saturday 14 June 2014 15:11:21 Chris Raschl wrote: > recently I wanted to add a weather forecast to my org-agenda. I found > org-google-weather, but this package is obsolete since 2012, because the > API is not available any more. So I wrote my own version which is backed > by the openweathermap.org API. I've written the `weather-metno-el' package. Which uses the weather data from met.no (CC licensed). It supports showing weather data in the org-agenda as well. https://github.com/ruediger/weather-metno-el Regards, Rüdiger
