Re: [O] babel python example not reproducible
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. On Wed, Jun 11, 2014 at 12:48 AM, Doyley, Marvin mdoy...@ur.rochester.edu wrote: Works for me, see example below #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: : : hello : 2 : bye #+BEGIN_SRC python :results output :session foo print hello good bye print Printing value from previous session, x #+END_SRC #+RESULTS: : : hello good bye : Printing value from previous session 100 The only difference is that I like to give my session a name and for what it is worth I am using ipython (don't think this will make a difference). You can do this including the following statement in your .emacs file (setq python-shell-interpreter ipython) (setq python-shell-interpreter-args --pylab) Hope this help. Cheers, M
Re: [O] how to use :options-alist in org-export-define-derived-backend ?
Bastien b...@gnu.org writes: Okay, but what is the benefit of not using a default title? It removes a hack. But there are other reasons at http://permalink.gmane.org/gmane.emacs.orgmode/86442 (e.g., a default title hardly makes sense anyway). Regards, -- Nicolas Goaziou
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
Re: [O] proposal to have ignoreheading tags/properties
Hello, Eric Schulte schulte.e...@gmail.com 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-and-promoting-children (data info) + Remove
Re: [O] Link to Top Most Heading
Esben Stien b...@esben-stien.name 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] org-weather for openweathermap.org
Chris Raschl c...@kautsig.org 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] 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
Ian Barton li...@wilkesley.net 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] Tangling with variables in R
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Rainer, Hi Andreas, Rainer M Krug rai...@krugs.de 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 put some thoughts into this and see how it could be done easily and with limited rewuirements to supplementary files. Apologies for a long post, but I would like to know which direction of the tangling /
Re: [O] proposal to have ignoreheading tags/properties
Nicolas Goaziou mail at 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] babel python example not reproducible
Shiyuan gshy2...@gmail.com 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] org-weather for openweathermap.org
On 2014-06-16 10:04, Rüdiger Sonderfeld ruedi...@c-plusplus.de 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] Capturing outgoing gnus e-mail
Esben Stien b...@esben-stien.name writes: Eric Abrahamsen e...@ericabrahamsen.net 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] proposal to have ignoreheading tags/properties
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Schulte schulte.e...@gmail.com 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 against implementing the functionality. We can implement it without increasing complexity, so the demand is hardly a justification for this added complexity.
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] 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
[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] Insert #+BEAMER_HEADER_EXTRA before \begin{document}?
Sebastien Vauban sva-n...@mygooglest.com 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] 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] 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/
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] customizable C, C++, D, Java, Groovy compilers
Applied, Thanks! Thierry Banel tbanelweb...@free.fr 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 tbanelweb...@free.fr 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] org-weather for openweathermap.org
On 16/06/14 11:45, Thorsten Jolitz wrote: Ian Barton li...@wilkesley.net 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] Errors after upgrading emacs to 24.3.1 and org to 7.9.4
Chris Henderson henders254 at gmail.com writes: On Fri, Mar 22, 2013 at 3:38 AM, Eric S Fraga e.fraga at ucl.ac.uk wrote: Chris Henderson henders254 at 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] 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 e...@ericabrahamsen.net wrote: Fletcher Charest fletcher.char...@gmail.com 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] 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=%smode=jsonunits=metriccnt=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] org-weather for openweathermap.org
Thanks, I will change the api cheers, M --
Re: [O] babel python example not reproducible
Hi Eric, Thanks for showing me the smart way of doing this. cheers, M --
Re: [O] inclusion of #+RESULTS in a source block
Federico Beffa beffa at 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 analytic-sol() #+END_SRC To use in more than one src-block use the `:cache yes' header for `analytic-sol' HTH, Chuck
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
[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] 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
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
Aloha Thierry, How about a user-customizable variable with a default value of 2147483647? All the best, Tom Thierry Banel tbanelweb...@free.fr 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
[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] 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
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 tbanelweb...@free.fr 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
Bastien b...@gnu.org 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 STARTEDfrom 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 STARTEDfrom 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
