Re: [O] [patch] Problem with insert anniversary agenda function (was Re: org-bbdb-anniversaries gives error 'bad sexp')
Carsten Dominik writes: [...] > Thanks for the patch! Indeed, there was a bug here which always forced > one particular date style even though the code was supposed to do the > right thing. Thanks! > > However, instead of applying your patch, I thought that maybe I > should put my foot where my mouth is and remove these dependencies > altogether. > > So I have just introduced a few functions org-anniversary, org-cyclic > and a few more which are just like their diary-* cousins, but with a > stable (ISO) order of arguments. Ah, I like this *much* better. > `i a' in the agenda will now also use org-anniversary, not diary-anniversary. > > For users of org-diary-class, there is a new function org-class which works > the same as org-diary-class, but with stable argument ordering. > > - Carsten Carsten, many thanks for this. The org-anniversary, at the very least, seems to work perfectly. It's nice not to have to worry about date orders! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.409.g4f3a3)
Re: [O] org and microsoft exchange
Skip Collins writes: > I was thinking of trying to get org and microsoft exchange talking to > each other via soap-client.el and exchange web services (ews). > Ultimately it would be nice to have a route into the corporate world > of exchange, outlook, entourage, and blackberry where so many of us > are forced to live. > > My first goal is to link org TODOs to exchange tasks in some > simplistic way that allows two-way syncing. > > If that proves feasible, perhaps calendar items could be next. > > Does this sound useful? If anyone with elisp or web services > programming experience is interested in lending a hand, I am sure to > need some help. +1. My institution is moving to MS Live, whatever that means (I really am completely ignorant of the MS world, for better or for worse). I think this is somehow related to Exchange etc. so any type of integration with org would be greatly helpful for me! At first, all I care about is one way transfer, from the MS world to org but obviously two way syncing would be good. In my case, it's more about calendar events than tasks. My tasks are typically for my information only but meetings etc involve multiple people. I can try to help in due course. We haven't moved to the MS system yet so I cannot yet say how much I will be able to contribute. Keep me in the loop! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.409.g4f3a3)
Re: [O] org and microsoft exchange
Hi, > >> I was thinking of trying to get org and microsoft exchange talking to >> each other via soap-client.el and exchange web services (ews). >> Ultimately it would be nice to have a route into the corporate world >> of exchange, outlook, entourage, and blackberry where so many of us >> are forced to live. >> >> My first goal is to link org TODOs to exchange tasks in some >> simplistic way that allows two-way syncing. >> >> If that proves feasible, perhaps calendar items could be next. >> >> Does this sound useful? If anyone with elisp or web services >> programming experience is interested in lending a hand, I am sure to >> need some help. > > +1. > > My institution is moving to MS Live, whatever that means (I really am > completely ignorant of the MS world, for better or for worse). I think > this is somehow related to Exchange etc. so any type of integration with > org would be greatly helpful for me! At first, all I care about is one > way transfer, from the MS world to org but obviously two way syncing > would be good. > > In my case, it's more about calendar events than tasks. My tasks are > typically for my information only but meetings etc involve multiple > people. > > I can try to help in due course. We haven't moved to the MS system yet > so I cannot yet say how much I will be able to contribute. Keep me in > the loop! One open source project that implements a pretty impressive interface to exchange is http://davmail.sourceforge.net Maybe you can get hints on how to deal with the ideosycrasies of MS coding from there. Unfortunately I cannot use this, and your proposed solution, since my Exchange server is behind an RSA-Token-"secured" gateway. I'm planning to use the org-outlook protocol http://www.emacswiki.org/emacs/org-outlook.el even if this means that I need to have an Outlook-instance running. Good luck! Holger
[O] Actual value of variable in tangled source file instead of variable
Hi I am using R for package writing in R, and the org file is under svn version control. I would like to keep the version of the R package, as stated in the DESCRIPTION file, in sync with the svn revision, so I thought about using variables for that. But my approach below obviosly does not work, as in the tangled DESCRIPTION file, it says Version: 0.$VER Is it possible to have, during tangling, the actual value in the source file instead of the variable? Thanks, Rainer * The DESCRIPTION File #+begin_src sh :tangle ./asm/DESCRIPTION :shebang :padline no :var VER=(vc-working-revision (buffer-file-name)) Package: asm Type: Package Title: Alien spread management simulation model Version: 0.$VER Date: 2011-06-08 Author: Rainer M. Krug Maintainer: Rainer M Krug Description: For research License: GPL-3 LazyLoad: yes Depends: simecol, sp, maptools, spgrass6, RSQLite, Rcpp (>= 0.9.4) LinkingTo: Rcpp #+end_src -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
[O] Bug: org-reset-checkbox-state-subtree doesn't update checkbox cookies [7.5 (release_7.5.280.ga6e9)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
If I run the above command, the state of all the checkboxes is updated
correctly, but the cookies do not update, instead they retain the
previous state.
Emacs : GNU Emacs 23.1.50.1 (i486-pc-linux-gnu, GTK+ Version 2.18.0)
of 2009-09-27 on palmer, modified by Debian
Package: Org-mode version 7.5 (release_7.5.280.ga6e9)
current state:
==
(setq
org-log-done t
org-export-preprocess-before-backend-specifics-hook
'(org-inlinetask-export-handler)
org-clock-in-switch-to-state 'bh/clock-in-to-next
org-archive-default-command 'org-archive-to-archive-sibling
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-special-ctrl-a/e t
org-agenda-clockreport-parameter-plist '(:link nil :maxlevel 3 :fileskip0 t
:indent t)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-custom-commands '(("w" "Tasks waiting on something" tags "WAITING/!"
((org-use-tag-inheritance nil)
(org-agenda-todo-ignore-scheduled nil)
(org-agenda-todo-ignore-deadlines nil)
(org-agenda-todo-ignore-with-date nil)
(org-agenda-overriding-header "Waiting Tasks"))
)
("r" "Refile New Notes and Tasks" tags
"LEVEL=2+REFILE"
((org-agenda-todo-ignore-with-date nil)
(org-agenda-todo-ignore-deadlines nil)
(org-agenda-todo-ignore-scheduled nil)
(org-agenda-overriding-header "Tasks to
Refile"))
)
("i" "Invoicing" tags "invoicing-DONE/CANCELLED"
((org-agenda-overriding-header "Invoicing")))
("N" "Notes" tags "NOTE"
((org-agenda-overriding-header "Notes")))
("n" "Next" tags-todo "-WAITING-CANCELLED/!NEXT"
((org-agenda-overriding-header "Next Tasks")))
("p" "Projects" tags "project"
((org-agenda-overriding-header "Projects")))
("f" "Focus areas" tags "FOCUS"
((org-use-tag-inheritance nil)
(org-agenda-overriding-header "Focus areas"))
)
("s" "Someday / maybe" tags "SOMEDAY"
((org-use-tag-inheritance nil)
(org-agenda-overriding-header "Someday /
Maybe"))
)
("v" . "Vendor task lists")
("vb" "BT tasks" tags-todo
"BT-project/-DONE-CANCELLED"
nil)
("vo" "Orange tasks" tags-todo
"Orange-project/-DONE-CANCELLED" nil)
("g" . "Agendas")
("gp" "Paul Jolley" tags-todo
"@PaulJolley/-DONE-CANCELLED")
("A" "Tasks to be Archived" tags
"LEVEL=2-REFILE/DONE|CANCELLED"
((org-agenda-overriding-header "Tasks to
Archive")))
)
org-agenda-files '("~/Dropbox/gtd/checklists/weeklyreview.org"
"~/Dropbox/gtd/projects/Orange mobile transition 2011.org"
"~/Dropbox/gtd/projects/Work management system.org"
"~/Dropbox/gtd/admin.org" "~/Dropbox/gtd/agendas.org"
"~/Dropbox/gtd/projects/intelligent comms.org"
"~/Dropbox/gtd/finance.org" "~/Dropbox/gtd/fixed.org"
"~/Dropbox/gtd/mobile.org" "~/Dropbox/gtd/Conferencing.org"
"~/Dropbox/gtd/personal.org" "~/Dropbox/gtd/refile.org"
"~/Dropbox/gtd/notes.org" "~/Dropbox/gtd/gtd.org"
"~/Dropbox/gtd/dates.org" "~/Dropbox/gtd/invoicing.org")
org-agenda-include-diary t
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
org-agenda-tags-column 130
org-agenda-window-setup 'current-window
org-hide-leading-stars t
org-clock-into-drawer "CLOCK"
org-gnus-prefer-web-links t
org-metaup-hook '(org-babel-load-in-session-maybe)
org-agenda-skip-timestamp-if-done t
org-after-todo-state-change-hook '(org-clock-out-if-current)
org
[O] Org-mode is not able to manage complex calendar events (was: org and microsoft exchange)
* Eric S Fraga wrote: > > In my case, it's more about calendar events than tasks. My tasks are > typically for my information only but meetings etc involve multiple > people. IMHO: Org-mode does *not* seem to be made for managing calendar events that go beyond simple one-time-occurrence events. but you *have* to support at least the same featureset of Outlook Calendar in order to think of a (two-way-) sync mechanism to Org-mode. Yes, there is this sexp-workaround[1] for more complex things but quite frankly: this is not an option for the ordinary user like me (not having that much ELISP knowledge). And even with sexp, you can not map recurring events with exceptions, irregular recurring events, and so forth. For me as a relatively newbee (related to Emacs and Org-mode) it is clear that I can not move my current calendar environment to Org-mode. Unfortunately. So far, I do have my old calendar setup (in JPilot/PalmOS) and additionally my task-only-related calendar in Org-mode. But I'd love to see an advanced and easy to use calendar environment in Org-mode! I love Pimlical[2] and its DateBk6 for PalmOS in terms of: easy to use, very flexible, able to map all kinds of complex requirements, ... 1. http://www.gnu.org/software/emacs/manual/html_node/emacs/Sexp-Diary-Entries.html 2. http://www.pimlicosoftware.com/ -- Karl Voit
Re: [O] org and microsoft exchange
On Mon, Jun 20, 2011 at 7:53 AM, Holger Wenzel wrote: > Unfortunately I cannot use this, and your proposed solution, since my > Exchange server is behind an RSA-Token-"secured" gateway. > > I'm planning to use the org-outlook protocol Both outlook and org will require dealing with secured gateways.
Re: [O] Unwanted percent-encoding capturing data from Firefox
On 06/20/2011 12:04 AM, David Maus wrote: At Sun, 19 Jun 2011 11:43:49 -0500, Bill Jacobson wrote: For some months now, I've been successfully capturing Firefox data as explained here: http://orgmode.org/worg/org-contrib/org-protocol.html But the results below demonstrate a problem. The 2nd and 3rd represent what was captured into Emacs, the quoted line in each case being what was highlighted in Firefox. Emacs version is: GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-05-03 Manually copied: [[http://www.tbray.org/ongoing/When/201x/2011/05/31/Browsers][ongoing by Tim Bray · Me and My Browsers]] "I like that Chrome’s fast, and I really like that it’s robust" Org-mode version 7.4: [[http://www.tbray.org/ongoing/When/201x/2011/05/31/Browsers][ongoing by Tim Bray · Me and My Browsers]] "I like that Chrome’s fast, and I re-ally like that it’s ro-bust" Org-mode version 7.4 (release_7.5.409.g4f3a3) == latest [[http%3A%2F%2Fwww.tbray.org%2Fongoing%2FWhen%2F201x%2F2011%2F05%2F31%2FBrowsers][ongoing by Tim Bray %C2%B7 Me and My Browsers]] "I like that Chromeâ%80%99s fast%2C and I re%C2%ADally like that itâ%80%99s ro%C2%ADbust" I'm looking into this issue, but this caught my eyes: Org-mode version 7.4 (release_7.5.409.g4f3a3) == latest This looks like a mixed up Org mode install, doesn't it? It would explain the problem you face. The functions for escaping %-encoded characters has changed significantly and if you run org-protocol.el from 7.5 together with org.el from 7.4 you would get exactly what you got. Could you check if you have a mixed Org install? Best, -- David David, I didn't know to see the 7.4 bit as a possible red flag. In /usr/local/share/emacs, I have installed Emacs 24.0.50, including the bundled org-mode 7.4 release. Into ~/elisp/org-mode I am nightly git pulling and making the latest 7.5 version I have been toggling between 7.4 and 7.5 latest—cleanly, I thought—by uncommenting or commenting the line (add-to-list 'load-path "~/elisp/org-mode/lisp/") Is this enough to tell you what I've mixed up? Thanks, Bill
[O] Subtasks are blocked in todo-items of ordered projects. Bug?
Hi all, I've run into an annoyance wrt the :ORDERED: property and the blocking of tasks due to it. Here is the minimal usecase: --- * TODO Project like header, containing subtasks :PROPERTIES: :ORDERED: t :END: ** TODO This item is the first to be done in the project This one is not blocked, as I expect. ** TODO Next task with subtasks This is blocked by the sibling above, which is what I expect *** TODO Subtask of a blocked sibling. This seems to be blocked and I can't understand why. Marking it DONE would not mark the parent done (neither explicit nor implicit). Why is it blocked then? Bug? *** TODO Second item in the blocked This is also blocked, which could be right, because the parent project has an ordered property and the sibling above is not yet complete. --- Should the first task in a subproject of a project having the ':ORDERED:' property set to true be blocked from marking 'DONE'? If so, why? The above minimal case is easy, but it's far from trivial to see why tasks in projects are blocked if the project is longer and has more outline levels. My expectation of the ordered property would be that it only acted one-level deep, regarded from a 'block-or-not' standpoint. Thoughts? marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org smime.p7s Description: S/MIME cryptographic signature
Re: [O] Org-mode is not able to manage complex calendar events
Karl Voit writes: > * Eric S Fraga wrote: >> >> In my case, it's more about calendar events than tasks. My tasks are >> typically for my information only but meetings etc involve multiple >> people. > > IMHO: Org-mode does *not* seem to be made for managing calendar > events that go beyond simple one-time-occurrence events. I would argue that this is not at all the case, especially if you consider that org uses a tree hierarchy and tags so that one can group separate entries in a variety of ways, you can clone with time shift whole trees, etc. Most calendar tools require you to specify all the conditions for a particular "event" in one go whereas with org you can have a number of different entries for the same "event"... etc. Also, with sexp, you can manage practically anything you might like although, of course, it does require learning a certain amount of elisp. Recurring events with exceptions are not a problem, for instance. In any case, as always with computer tools, what works for you is what matters! For me, org is just plainly much more suitable for my mode of working; every other calendar system I have tried has constrained me much more. But that's *me*. > but you > *have* to support at least the same featureset of Outlook Calendar > in order to think of a (two-way-) sync mechanism to Org-mode. I guess this depends on what types of events you are likely to have in the outlook calendar. In my case, only a small feature set is likely necessary (mostly repeating lectures and one off meetings) so a sync should be possible. I don't think anybody is proposing a full-blown totally automatic sync mechanism between org and Outlook (or whatever) that covers the union of the two products' feature sets... insanity lies in that direction ;-) But I'll worry about this later this year when forced to use MS... -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.410.gadf1)
Re: [O] org and microsoft exchange
On 20/06/11 5:53 AM, "Holger Wenzel" wrote: > >I'm planning to use the org-outlook protocol > >http://www.emacswiki.org/emacs/org-outlook.el > >even if this means that I need to have an Outlook-instance running. When I was still on a windows box, I built a little Windows Scripting Host REPL, for the express purpose of communicating with outlook. I've since moved to Mac, so I have not worked on it since, however, the code is available here: https://github.com/jonnay/wsh-repl You could load up an instance of the wsh-repl, and send it commands directly (it's a standard comint buffer). Hopefully it provides some help for you guys. The information contained in this message is confidential. It is intended to be read only by the individual or entity named above or their designee. If the reader of this message is not the intended recipient, you are hereby notified that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message.
Re: [O] org and microsoft exchange
On 2011-06-20 07:52 UT, Eric S Fraga wrote: ESF> Skip Collins writes: >> I was thinking of trying to get org and microsoft exchange talking to >> each other via soap-client.el and exchange web services >> (ews).Ultimately it would be nice to have a route into the corporate >> world of exchange, outlook, entourage, and blackberry where so many >> of us are forced to live. >> >> My first goal is to link org TODOs to exchange tasks in some >> simplistic way that allows two-way syncing. >> >> If that proves feasible, perhaps calendar items could be next. >> >> Does this sound useful?If anyone with elisp or web services >> programming experience is interested in lending a hand, I am sure to >> need some help. ESF> +1. ESF> My institution is moving to MS Live, whatever that means (I really ESF> am completely ignorant of the MS world, for better or for worse).I ESF> think this is somehow related to Exchange etc.so any type of ESF> integration with org would be greatly helpful for me!At first, all ESF> I care about is one way transfer, from the MS world to org but ESF> obviously two way syncing would be good. ESF> In my case, it's more about calendar events than tasks.My tasks are ESF> typically for my information only but meetings etc involve multiple ESF> people. ESF> I can try to help in due course.We haven't moved to the MS system ESF> yet so I cannot yet say how much I will be able to contribute.Keep ESF> me in the loop! How much of this problem is really MS-specific? I think it would be a huge door-opener for providing better general interoperability to have a clear idea of what types of events and tasks have to be dealt with. Then we can abstract from the org-representation of data and write plugins for different export formats. Ie have a general representation of a recurring event, have one representation for a task (with all the properties it can have) etc. Building from there, we can look at the different features supported by other formats and just dump the supported properties into the corresponding format or use other libraries as interface with, for example, an exchange server. Maybe we should start implementing iCalendar as described in http://tools.ietf.org/html/rfc5545 and export our various org tags to well-defined lisp objects. This would also benefit all the projects trying to bring org to other platforms, which are now all rolling their own exporters. -- Philipp Haselwarter
Re: [O] org and microsoft exchange
Philipp Haselwarter wrote: > On 2011-06-20 07:52 UT, Eric S Fraga wrote: > > ESF> Skip Collins writes: > > >> I was thinking of trying to get org and microsoft exchange talking to > >> each other via soap-client.el and exchange web services > >> (ews).Ultimately it would be nice to have a route into the corporate > >> world of exchange, outlook, entourage, and blackberry where so many > >> of us are forced to live. > >> > >> My first goal is to link org TODOs to exchange tasks in some > >> simplistic way that allows two-way syncing. > >> > >> If that proves feasible, perhaps calendar items could be next. > >> > >> Does this sound useful?If anyone with elisp or web services > >> programming experience is interested in lending a hand, I am sure to > >> need some help. > > ESF> +1. > > ESF> My institution is moving to MS Live, whatever that means (I really > ESF> am completely ignorant of the MS world, for better or for worse).I > ESF> think this is somehow related to Exchange etc.so any type of > ESF> integration with org would be greatly helpful for me!At first, all > ESF> I care about is one way transfer, from the MS world to org but > ESF> obviously two way syncing would be good. > > ESF> In my case, it's more about calendar events than tasks.My tasks are > ESF> typically for my information only but meetings etc involve multiple > ESF> people. > > ESF> I can try to help in due course.We haven't moved to the MS system > ESF> yet so I cannot yet say how much I will be able to contribute.Keep > ESF> me in the loop! > > How much of this problem is really MS-specific? I think it would be a > huge door-opener for providing better general interoperability to have a > clear idea of what types of events and tasks have to be dealt with. Then > we can abstract from the org-representation of data and write plugins > for different export formats. > Ie have a general representation of a recurring event, have one > representation for a task (with all the properties it can have) etc. > Building from there, we can look at the different features supported by > other formats and just dump the supported properties into the > corresponding format or use other libraries as interface with, for > example, an exchange server. > > Maybe we should start implementing iCalendar as described in > http://tools.ietf.org/html/rfc5545 and export our various org tags to > well-defined lisp objects. > > This would also benefit all the projects trying to bring org to other > platforms, which are now all rolling their own exporters. > We've discussed iCalendar before on the list - see e.g. the extensive thread at http://thread.gmane.org/gmane.emacs.orgmode/36517 My own thoughts on the above are at http://thread.gmane.org/gmane.emacs.orgmode/36517/focus=42752 and I have made a little progress along the lines described, but it's nowhere near ready for prime time. Nick
[O] exporting emphasised text (bold, italics etc.) in ORGTBL
When I'm using orgtbl in the midst of a LaTeX document, is there a way to
tell it to export *bold* as \textbf{bold}, /italics/ as \textit{italics}
etc.?
--
-
Benjamin Slade
Dept. of Linguistics
University of Illinois at Urbana-Champaign
[ http://www.jnanam.net/slade/ ]
Stæfcræft & Vyākaraṇa (lingblog) - http://staefcraeft.blogspot.com
The Babbage Files (techblog) - http://babbagefiles.blogspot.com
-
*प*रो ऽक्ष॑का*मा* हि *दे*वाः
'The gods love the obscure.' (Śatapathabrāmaṇa 6.1.1.2)
Re: [O] Bug: org-reset-checkbox-state-subtree doesn't update checkbox cookies [7.5 (release_7.5.280.ga6e9)]
Hello, Paul Mead writes: > If I run the above command, the state of all the checkboxes is updated > correctly, but the cookies do not update, instead they retain the > previous state. I cannot reproduce the problem. Could you try upgrading to git head, and, if the bug persists, post a sample file to reproduce the problem ? Regards, -- Nicolas Goaziou
Re: [O] Org-mode is not able to manage complex calendar events
* Eric S Fraga wrote: > Karl Voit writes: > >> IMHO: Org-mode does *not* seem to be made for managing calendar >> events that go beyond simple one-time-occurrence events. > > I would argue that this is not at all the case, especially if you > consider that org uses a tree hierarchy and tags so that one can group > separate entries in a variety of ways, This is fore sure a big advantage of Org-mode! > you can clone with time shift whole trees, etc. Oh, I have to look up that clone thing. This is new to me. Do you happen to have an URL for this feature by instance? > Most calendar tools require you to specify all the > conditions for a particular "event" in one go whereas with org you can > have a number of different entries for the same "event"... etc. Full ack. > Also, with sexp, you can manage practically anything you might like > although, of course, it does require learning a certain amount of > elisp. Recurring events with exceptions are not a problem, for > instance. I'd consider myself tech-savvy. But without having learned (E)LISP (yet), I can not use sexp-entries without reading a manual each time I want to use it. This is nothing I'd consider for normal users or daily use. It's not that end-user friendly (when you consider end-users as users without ELISP knowledge). For ELISP hackers this might work! But I am not sure how much percentage of Emacs/Org-mode users actually learned ELISP. And learning ELISP just to be able to write down a recurring event seems «strange» to me. > In any case, as always with computer tools, what works for you is what > matters! Full Ack. > For me, org is just plainly much more suitable for my mode of > working; every other calendar system I have tried has constrained me > much more. But that's *me*. This holds for most of the calendar systems out there, I totally agree. (This is why I still carry around my old PalmOS-PDA together with my highly sophisticated Android smartphone...) >> but you *have* to support at least the same featureset of Outlook >> Calendar in order to think of a (two-way-) sync mechanism to >> Org-mode. > > I guess this depends on what types of events you are likely to > have in the outlook calendar. In my case, only a small feature > set is likely necessary (mostly repeating lectures and one off > meetings) so a sync should be possible. I don't think anybody is > proposing a full-blown totally automatic sync mechanism between > org and Outlook (or whatever) that covers the union of the two > products' feature sets... insanity lies in that direction ;-) Sorry, I might have exaggerated a bit. But since I was implementing a one-way-sync mechanism between two different calendar systems I got a pretty good feeling of how different you can define the very same thing. Recurring events with exceptions is quite common but very hard to sync between different systems! And I am sure that this is not the only example of «being common and hard to do». > But I'll worry about this later this year when forced to use MS... Oh, sorry to hear about that :-( For ELISP-hackers out there: is this hard to do? A method which can be called «generate a series of Org-mode time stamps starting with $THIS_TIMESTAMP_CONTAINING_REPEATS up to $THIS date». I could think of generating such a series of <2011-06-22 Wed> <2011-06-29 Wed> ... just to be able to see all occurrences of an event and delete one specific event in between if necessary. This would ease exceptions for «ordinary» users like me. -- Karl Voit
Re: [O] Bug: org-reset-checkbox-state-subtree doesn't update checkbox cookies [7.5 (release_7.5.280.ga6e9)]
Nicolas Goaziou writes: > Hello, > > Paul Mead writes: > >> If I run the above command, the state of all the checkboxes is updated >> correctly, but the cookies do not update, instead they retain the >> previous state. > > I cannot reproduce the problem. Could you try upgrading to git head, > and, if the bug persists, post a sample file to reproduce the problem ? > > Regards, Right, just updated, so my org version is reported as Org-mode version 7.5 (release_7.5.419.g9a527) The problem persists with the following subtree: * The Weekly Review :PROPERTIES: :VISIBILITY: children :END: *** Loose Papers [6/6] - Gather all scraps of paper, business cards, receipts, and miscellaneous paper. Put into your in-basket to process. - [ ] Empty out backpack. Put relevant items into intray. - [ ] Remove loose stuff from desk - [ ] Empty wallet and moleskine pocket of receipts and paper - [ ] Empty inbox folder - [ ] Process everything in inbox - [ ] Empty email inbox creating NAs as required *** Process Your Notes [3/3] - Review any journal/notes types of entries, meeting notes, and miscellaneous notes scribbled on notebook paper. Decide and enter action items, projects, waiting-fors, etc., as appropriate. - [ ] Review moleskine notes - [ ] Review A4 pad - [ ] Review service review minutes *** Empty Your Head [1/1] - Put in writing (in appropriate categories) any new projects, action items, waiting-fors, someday/maybes, etc., not yet captured. - [ ] Empty your head *** Review Action Lists [1/1] - [ ] Mark off completed actions. - Review for reminders of further action steps to record. *** Review Waiting-For List [1/1] - Record appropriate actions for any needed follow-up. Check off received ones. - [ ] Review TODO items in Waiting State C-c a w *** Review Project (and Larger Outcome) Lists [3/3] - Evaluate status of projects, goals and outcomes, one by one, ensuring at least one current action item on each. Browse through work-in-progress support material to trigger new actions, completions, waiting-fors, etc. - [ ] Check stuck projects (C-c a #) - [ ] Review Project List (C-c a p) - [ ] Review contents of capture.org file (C-c i) *** Review Previous Calendar Data [1/1] - [ ] Review past calendar in detail for remaining action items, reference data, etc., and transfer into the active system. *** Review Upcoming Calendar [1/1] - [ ] Review upcoming calendar events-long and short term. Capture actions triggered. *** Review Any Relevant Checklists [1/1] - Use as a trigger for any new actions. - Review Someday/Maybe List - Review for any projects that may now have become active, and transfer to projects list. Delete items no longer of interest. - [ ] Review my [[file:~/Dropbox/gtd/someday.org][Someday/Maybe]] list *** Be Creative and Courageous [1/1] - Any new, wonderful, harebrained, creative, thought-provoking, risk-taking ideas to add into your system??? - [ ] Capture Todo items (C-c r t) or Someday (C-c r s) Regards Paul
Re: [O] Org-mode is not able to manage complex calendar events
Karl Voit writes: > * Eric S Fraga wrote: >> Karl Voit writes: >> > >>> IMHO: Org-mode does *not* seem to be made for managing calendar >>> events that go beyond simple one-time-occurrence events. >> >> I would argue that this is not at all the case, especially if you >> consider that org uses a tree hierarchy and tags so that one can group >> separate entries in a variety of ways, > > This is fore sure a big advantage of Org-mode! > >> you can clone with time shift whole trees, etc. > > Oh, I have to look up that clone thing. This is new to me. Do you > happen to have an URL for this feature by instance? ,[ org-clone-subtree-with-time-shift ] | org-clone-subtree-with-time-shift is an interactive compiled Lisp | function in `org.el'. | | It is bound to C-c C-x c,. | | (org-clone-subtree-with-time-shift N &optional SHIFT) | | Clone the task (subtree) at point N times. | The clones will be inserted as siblings. | | In interactive use, the user will be prompted for the number of | clones to be produced, and for a time SHIFT, which may be a | repeater as used in time stamps, for example `+3d'. | | When a valid repeater is given and the entry contains any time | stamps, the clones will become a sequence in time, with time | stamps in the subtree shifted for each clone produced. If SHIFT | is nil or the empty string, time stamps will be left alone. The | ID property of the original subtree is removed. | | If the original subtree did contain time stamps with a repeater, | the following will happen: | - the repeater will be removed in each clone | - an additional clone will be produced, with the current, unshifted | date(s) in the entry. | - the original entry will be placed *after* all the clones, with | repeater intact. | - the start days in the repeater in the original entry will be shifted | to past the last clone. | I this way you can spell out a number of instances of a repeating task, | and still retain the repeater to cover future instances of the task. ` >> Also, with sexp, you can manage practically anything you might like >> although, of course, it does require learning a certain amount of >> elisp. Recurring events with exceptions are not a problem, for >> instance. > > I'd consider myself tech-savvy. But without having learned (E)LISP > (yet), I can not use sexp-entries without reading a manual each time > I want to use it. This is nothing I'd consider for normal users or > daily use. It's not that end-user friendly (when you consider > end-users as users without ELISP knowledge). Sure; elisp is non-trivial. Point taken! >> I guess this depends on what types of events you are likely to >> have in the outlook calendar. In my case, only a small feature >> set is likely necessary (mostly repeating lectures and one off >> meetings) so a sync should be possible. I don't think anybody is >> proposing a full-blown totally automatic sync mechanism between >> org and Outlook (or whatever) that covers the union of the two >> products' feature sets... insanity lies in that direction ;-) > > Sorry, I might have exaggerated a bit. > > But since I was implementing a one-way-sync mechanism between two > different calendar systems I got a pretty good feeling of how > different you can define the very same thing. Recurring events with > exceptions is quite common but very hard to sync between different > systems! And I am sure that this is not the only example of «being > common and hard to do». Sure but I think you will find that most of "being command and hard to do" tasks are easily handled by org; at least, that's my experience. The difficulty may be finding out how do it as the number of possible actions in org is quite large. If there's any complaint one might have about org, is that it can be used for so many different tasks (calendar, task management, document preparation, etc.) that it can be overwhelming. Think of one of those very large swiss army knives where you can spend minutes just trying to find the right "blade" ;-). But I'm not complaining! :-> In any case, the org manual, the org web site and Worg, not to mention this mailing list, provide a wealth of information and use cases. > For ELISP-hackers out there: is this hard to do? A method which > can be called «generate a series of Org-mode time stamps starting > with $THIS_TIMESTAMP_CONTAINING_REPEATS up to $THIS date». > > I could think of generating such a series of <2011-06-22 Wed> > <2011-06-29 Wed> ... just to be able to see all occurrences of an > event and delete one specific event in between if necessary. This > would ease exceptions for «ordinary» users like me. See above; I use org-clone-subtree-with-time-shift for setting up, for instance, the lectures I have to give in a teaching term. I set up the initial lectures for each relevant day in the week and then clone the subtrees, removing any exceptions (reading/study weeks, say) afterwards. HTH. -- : Eric S Fraga (GnuPG: 0xC89193D8FFF
Re: [O] Bug: org-reset-checkbox-state-subtree doesn't update checkbox cookies [7.5 (release_7.5.280.ga6e9)]
I'm not sure if org-reset-checkbox-state-subtree is supposed to update the cookies, although that would seem logical. However, C-u C-c # will incorrectly accumulate the checkbox entries from previous sections when updating the file, which is clearly a bug: *** Loose Papers [0/6]… *** Process Your Notes [0/9]… *** Empty Your Head [0/10]… *** Review Action Lists [0/11]… *** Review Waiting-For List [0/12]… *** Review Project (and Larger Outcome) Lists [0/15]… *** Review Previous Calendar Data [0/16]… *** Review Upcoming Calendar [0/17]… *** Review Any Relevant Checklists [0/18]… *** Be Creative and Courageous [0/19]… C-c # on an individual section entry does the right thing. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Org-mode is not able to manage complex calendar events
Karl Voit writes: >> you can clone with time shift whole trees, etc. > > Oh, I have to look up that clone thing. This is new to me. Do you > happen to have an URL for this feature by instance? C-h i d m "org " i "clone " ,[ (info "(org)Structure editing") ] | `C-c C-x c' (`org-clone-subtree-with-time-shift') | Clone a subtree by making a number of sibling copies of it. You | will be prompted for the number of copies to make, and you can | also specify if any timestamps in the entry should be shifted. | This can be useful, for example, to create a number of tasks | related to a series of lectures to prepare. For more details, see | the docstring of the command `org-clone-subtree-with-time-shift'. ` Memnon
Re: [O] New release?
Achim Gratz writes: > Org 7.5 has got quite a few wrinkles ironed out during the past few > months and the current HEAD looks very clean save for two compiler > warnings in org-indent.el... and that part of the code looks like it > could use the same solution that org-agenda.el employs around line 1766. I've just set up a new Win7 system and chose to install NTemacs24 in anticipation of its upcoming release. There, aside from one complaint about an obsolete function that has been there for ages (and probably needs to stay there unless one wishes to jettison compatibility with Emacs22), I get a bunch of other warnings about global dynamic variables having no prefix. This seems to be an Emacs24 specific warning as I don't see any of that on Emacs23. Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Unwanted percent-encoding capturing data from Firefox
At Mon, 20 Jun 2011 07:17:30 -0500, Bill Jacobson wrote: > > > > I'm looking into this issue, but this caught my eyes: > > > >> Org-mode version 7.4 (release_7.5.409.g4f3a3) == latest > > > > > > This looks like a mixed up Org mode install, doesn't it? > > > > It would explain the problem you face. The functions for escaping > > %-encoded characters has changed significantly and if you run > > org-protocol.el from 7.5 together with org.el from 7.4 you would get > > exactly what you got. > > > > Could you check if you have a mixed Org install? > > > > Best, > >-- David > David, > > I didn't know to see the 7.4 bit as a possible red flag. > > In /usr/local/share/emacs, I have installed Emacs 24.0.50, including the > bundled org-mode 7.4 release. > > Into ~/elisp/org-mode I am nightly git pulling and making the latest 7.5 > version > > I have been toggling between 7.4 and 7.5 latest—cleanly, I thought—by > uncommenting or commenting the line > (add-to-list 'load-path "~/elisp/org-mode/lisp/") > > Is this enough to tell you what I've mixed up? No, AFAIK and according to http://orgmode.org/manual/Installation.html#Installation you'd need a (require 'org-install) When using the web version. This file defines the autoloads for Org, e.g. sets up the correct place where Emacs will find the correct Elips files. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgp6ErDfh9wDj.pgp Description: PGP signature
[O] [Bug] Doc string for org-clock-into-drawer truncated?
In org-clock.el, the following definition is found: (defcustom org-clock-into-drawer org-log-into-drawer "Should clocking info be wrapped into a drawer? When t, clocking info will always be inserted into a :LOGBOOK: drawer. If necessary, the drawer will be created. When nil, the drawer will not be created, but used when present. When an integer and the number of clocking entries in an item reaches or exceeds this number, a drawer will be created. When a string, it names the drawer to be used. The default for this variable is the value of `org-log-into-drawer', which see." … I can't make much sense of the last sentence which looks truncated. As an aside, while the value for org-log-into-drawer can be changed for a subtree by setting a property, this setting is not honored for clocking in the same subtree, which will still use the value of org-log-into-drawer in global or local scope or the LOGBOOK drawer, if present. In org-clock.el: (if org-clock-into-drawer (let ((logbook (if (stringp org-clock-into-drawer) (concat ":" org-clock-into-drawer ":") ":LOGBOOK:"))) But no defun to check a property like that used for logging in org.el: (defun org-log-into-drawer () "Return the value of `org-log-into-drawer', but let properties overrule. If the current entry has or inherits a LOG_INTO_DRAWER property, it will be used instead of the default value." (let ((p (org-entry-get nil "LOG_INTO_DRAWER" 'inherit))) (cond ((or (not p) (equal p "nil")) org-log-into-drawer) ((equal p "t") "LOGBOOK") (t p For symmetry it seems that one should be able to specify a property CLOCK_INTO_DRAWER specifically for clocking or fall back onto LOG_INTO DRAWER, just like the customization variables allow one to do. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] Unwanted percent-encoding capturing data from Firefox
At Mon, 20 Jun 2011 07:17:30 -0500, Bill Jacobson wrote: > > > > I'm looking into this issue, but this caught my eyes: > > > >> Org-mode version 7.4 (release_7.5.409.g4f3a3) == latest > > > > > > This looks like a mixed up Org mode install, doesn't it? > > > > It would explain the problem you face. The functions for escaping > > %-encoded characters has changed significantly and if you run > > org-protocol.el from 7.5 together with org.el from 7.4 you would get > > exactly what you got. > > > > Could you check if you have a mixed Org install? > > > > Best, > >-- David > David, > > I didn't know to see the 7.4 bit as a possible red flag. > > In /usr/local/share/emacs, I have installed Emacs 24.0.50, including the > bundled org-mode 7.4 release. > > Into ~/elisp/org-mode I am nightly git pulling and making the latest 7.5 > version > > I have been toggling between 7.4 and 7.5 latest—cleanly, I thought—by > uncommenting or commenting the line > (add-to-list 'load-path "~/elisp/org-mode/lisp/") > > Is this enough to tell you what I've mixed up? No, AFAIK and according to http://orgmode.org/manual/Installation.html#Installation you'd need a (require 'org-install) When using the web version. This file defines the autoloads for Org, e.g. sets up the correct place where Emacs will find the correct Elips files. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de
Re: [O] org-babel -- Improper syntax error in session mode?
I've changed the python session evaluation so that it explicitly sends a RET to the inferior Python process after every line of input. The attached patch makes this change. I can confirm that this fixes the problem in your example (when an empty line is placed between the block and the subsequent print statement), however, could you please test it on a variety of other python blocks to confirm it doesn't seem to break existing behavior (I'm not a python user). If this looks safe then I'll apply it to the main repo. Thanks! -- Eric >From 1edad6a87bb5491061efaf597fa38b9190387232 Mon Sep 17 00:00:00 2001 From: Eric Schulte Date: Mon, 20 Jun 2011 12:18:09 -0700 Subject: [PATCH] ob-python: Send RET after every line w/session evaluation * lisp/ob-python.el (org-babel-python-evaluate-session): Send comint-send-input after every line when interacting with an interactive python process. --- lisp/ob-python.el |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/ob-python.el b/lisp/ob-python.el index f3f4a03..6cb2c44 100644 --- a/lisp/ob-python.el +++ b/lisp/ob-python.el @@ -267,9 +267,11 @@ last statement in BODY, as elisp." (org-babel-comint-with-output (session org-babel-python-eoe-indicator t body) (let ((comint-process-echoes nil)) - (input-body body) - (insert org-babel-python-eoe-indicator) - (comint-send-input))) 2) "\n")) + (mapc + (lambda (line) + (insert line) (comint-send-input nil t)) + (append (split-string body "[\n\r]") (list org-babel-python-eoe-indicator) + 2) "\n")) (value (let ((tmp-file (org-babel-temp-file "python-"))) (org-babel-comint-with-output -- 1.7.4.1 Nick Dokos writes: > Herbert Sitz wrote: > >> Eric Schulte gmail.com> writes: >> > I can confirm that I see the same behavior. Also, if I manually type >> > the body of the code block into the session I get the same error output >> > from Python, so I don't believe this is due to a problem with Babel. >> > >> >> It appears the problem is that the python session is interactive and is >> built to >> emit output after each Python "block" (e.g., the 'for' block), before another >> "block" of Python is entered. If this is the way it's designed then it >> seems to >> me that it's Babel's obligation to feed the Python blocks to the Python >> session >> as required and then assemble the output pieces as appropriate. Or am I >> missing >> something? -- Herb >> > > Having babel recognize python blocks in order to feed them to the python > interpreter as complete blocks seems a bit too much to me. Of course, > what I think matters little: it's what Eric thinks that matters here. > > Having said that, however, I think there *is* a problem: > > If you just start the python interpreter and start typing into it: > > x = 1 > for i in range(1,5): > x = x + i > print x > print "Did it work?" > > the problem becomes obvious: the interpreter is still in "indented mode" > and complains about the last print, because it is not "properly" > indented. OTOH, if you exit "indented mode" by pressing another RET > before the final print, the interpreter is happy. This is a kludge used > by the interactive interpreter to accommodate python's reliance on > indentation to delimit block structure. > > That however does not work with babel: even if I leave empty lines > between the print x and the last print, the error persists. Apparently, > babel does not send the empty lines to the interpreter. If there is a > bug in babel, it seems to me this is it. > > Nick > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: org-reset-checkbox-state-subtree doesn't update checkbox cookies [7.5 (release_7.5.280.ga6e9)]
Hello, Achim Gratz writes: > I'm not sure if org-reset-checkbox-state-subtree is supposed to update > the cookies, although that would seem logical. > > However, C-u C-c # will incorrectly accumulate the checkbox entries from > previous sections when updating the file, which is clearly a bug: > > *** Loose Papers [0/6]… > *** Process Your Notes [0/9]… > *** Empty Your Head [0/10]… > *** Review Action Lists [0/11]… > *** Review Waiting-For List [0/12]… > *** Review Project (and Larger Outcome) Lists [0/15]… > *** Review Previous Calendar Data [0/16]… > *** Review Upcoming Calendar [0/17]… > *** Review Any Relevant Checklists [0/18]… > *** Be Creative and Courageous [0/19]… > > C-c # on an individual section entry does the right thing. Indeed, I noticed that when working on Paul's report. Issues should be fixed now. Regards, -- Nicolas Goaziou
Re: [O] org-babel -- Improper syntax error in session mode?
Eric Schulte gmail.com> writes: > I've changed the python session evaluation so that it explicitly sends a > RET to the inferior Python process after every line of input. The > attached patch makes this change. > I can confirm that this fixes the > problem in your example (when an empty line is placed between the block > and the subsequent print statement) Eric -- I did confirm that the patch works with this block: #+begin_src python :results output :session mypy x = 1 for i in range(1,5): x = x + i print x print "Did it work?" #+end_src But it doesn't work with the block below, which _is_ valid Python code. I'm not sure whether you're aware that it isn't working with the code below (and were thinking that the code below is _not_ valid python), or whether you were going to require the user to input blank lines at appropriate spots: -- #+begin_src python :results output :session mypy x = 1 for i in range(1,5): x = x + i print x print "Did it work?" #+end_src --- The above block is valid Python, it's just because of the quirk of the interactive python shell that it has to have a blank line inserted before the [print "Did it work?"] line. The locations where the blank lines would need to be inserted in code are wherever the line indent goes from >0 back to 0. A user could be required to insert these, of course, but since it's valid python to leave them out it seems like something org-babel should do behind the scenes. The '0 indent' for purposes of python execution is the smallest indent in the org-babel source. So even though all source code lines are indented in above org block, the line 'x=1' has zero indent for python eval purposes. The relevance of this is just to show that extra lines for shell/babel evaluation are necessary only when code indent goes back to zero, not when indent merely becomes smaller. So the code below works fine, even though indent shrinks after 'print y' and 'print z' statements:: -- #+begin_src python :results output :session mypy x = 1 y = 1 z = 1 for i in range(1,5): x = x + i print x for y in range(10,15): print y for z in range(20,25): print z print "Did it work?" #+end_src Like the simpler example, though, it doesn't work with with the blank line omitted, which it should. I hope I'm not confusing things. The patch does help, but doesn't address the extra-line insertion issue. -- Herb
Re: [O] org-babel -- Improper syntax error in session mode?
Herbert Sitz writes: > Eric Schulte gmail.com> writes: >> I've changed the python session evaluation so that it explicitly sends a >> RET to the inferior Python process after every line of input. The >> attached patch makes this change. > >> I can confirm that this fixes the >> problem in your example (when an empty line is placed between the block >> and the subsequent print statement) > > Eric -- > > I did confirm that the patch works with this block: > > #+begin_src python :results output :session mypy > x = 1 > for i in range(1,5): > x = x + i > print x > > print "Did it work?" > #+end_src > > > But it doesn't work with the block below, which _is_ valid Python code. As far as I can tell the problem with the block below (missing the space) is due to problems with the Python interpreter. [...] > -- > #+begin_src python :results output :session mypy > x = 1 > for i in range(1,5): > x = x + i > print x > print "Did it work?" > #+end_src > --- [...] > > I hope I'm not confusing things. No worries, however, I maintain that it is beyond the scope of Babel's Python interaction to address examples such as the one given above which do not work when typed into the Python verbatim session by the user. > The patch does help, but doesn't address the extra-line insertion > issue. > Fair enough. Does it work for other "normal" Python interactive code blocks? Have you noticed any places where the previous version worked but the new version doesn't? If it seems safe then I would like to apply it. Best -- Eric > > -- Herb > > > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] org-babel -- Improper syntax error in session mode?
Discalimer: I neither use python or babel. > Eric Schulte gmail.com> writes: >> I can confirm that I see the same behavior. Also, if I manually type >> the body of the code block into the session I get the same error output >> from Python, so I don't believe this is due to a problem with Babel. >> > > It appears the problem is that the python session is interactive and > is built to emit output after each Python "block" (e.g., the 'for' > block), before another "block" of Python is entered. > If this is the way it's designed ISTM you are speculating on design based on a very simple example and just this "specific implementation". > then it seems to me that it's Babel's obligation to feed the Python > blocks to the Python session as required and then assemble the output > pieces as appropriate. Or am I missing something? -- Herb There is a difference between feeding an interactive shell by hand and feeding interactive shell via a program (The latter one is very fast). The behaviour pertaining to buffering and flusing of output buffers would not be apparent unless large volumes of output text is spewed. The assumption that is being made in this thread is that: "Python interpreter blocks until *all* output are *appears at the* console before moving on to the next block." While it is reasonable to assume that Python interpreter *flushes the output buffers" it seems a bit too far-fetched to me to assume that python interpreter can *guarantee" the appearance of the spewed block before proceeding to the next block. Unless python spec clearly and *positively* confirms the behaviour you are assuming in *all* compliant-implementations, it is generally a good idea to be conservative and not rely on observed behaviour too much. Just my 2 cents. ps: Ignore if I have poorly understood the items discussed in this thread. Jambunathan K.. --
Re: [O] org-babel -- Improper syntax error in session mode?
On Mon, Jun 20, 2011 at 2:15 PM, Eric Schulte wrote: > > As far as I can tell the problem with the block below (missing the > space) is due to problems with the Python interpreter. It's not due to any problem with the interpreter itself, it's due to a purposeful design decision about the way the interactive shell should work. It makes good sense to require that extra line in interactive mode, given Python's reliance on carriage-returns and indents as part of its syntax, along with decision that the interactive output should be provided at the end of every "level 1" block. The blank line is the only way to end a "level 1 block without starting a second level 1 block. >> >> I hope I'm not confusing things. > > No worries, however, I maintain that it is beyond the scope of Babel's > Python interaction to address examples such as the one given above which > do not work when typed into the Python verbatim session by the user. > >> The patch does help, but doesn't address the extra-line insertion >> issue. > > Fair enough. > Maybe adding the extra lines is beyond Babel's scope, strictly speaking. I can think of some good reasons for doing it though: (1a) Babel is not an interactive shell. (1b) It's not obvious to the Babel user that sessions are being processed using Python's interactive shell. Even if that is known (I know it's somewhere in the docs), it's not clear to a user why Babel would require a user to insert the extra lines (and, it turns out, _avoid_ blank lines in other cases), which make sense in interactive environment but not within Babel's non-interactive environment. Even if this particular idiosyncrasy is documented somewhere it's going to cause confusion for users who skim the docs and just expect regular Python code to work without problems. (If I'm first to report the issue maybe there aren't many Org users trying to use :session mode with Python, though.) (2) Isn't the blank-line issue an easy fix? I think it requires just these two simple changes to source block before submitting to python shell: (a) Regex search replace to add a blank line before any "unindented" line that is preceded by an indented line (actually it may work fine to just put blank line before _any_ "unindented" textline in the source-block); and (b) deletion of all blank lines in the source-block that are followed by "indented" text on next line. > Does it work for other "normal" Python interactive code blocks? Have > you noticed any places where the previous version worked but the new > version doesn't? If it seems safe then I would like to apply it. I think the start with a stray blank line before what should be the actual output. Otherwise It does seem to be working well with the few more complicated things I've created to throw at it. I'm not really a big Python user, was just doing some testing in my vim-Org-clone with Python when I noticed the problem. If you end up not addressing the line-insertion issue I may put it on my todo-list for my first real adventure in learning elisp. Regards, Herb
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
Marcel van der Boom writes: > Hi all, > > I've run into an annoyance wrt the :ORDERED: property and the blocking > of tasks due to it. > > Here is the minimal usecase: > > --- > * TODO Project like header, containing subtasks > :PROPERTIES: > :ORDERED: t > :END: > ** TODO This item is the first to be done in the project >This one is not blocked, as I expect. ok > ** TODO Next task with subtasks >This is blocked by the sibling above, which is what I expect ok > *** TODO Subtask of a blocked sibling. > This seems to be blocked and I can't understand why. Marking it DONE > would not mark the parent > done (neither explicit nor implicit). Why is it blocked then? Bug? This is blocked until you mark the first level 2 TASK as DONE. The entire subtree is blocked by the previous incomplete task. > *** TODO Second item in the blocked > This is also blocked, which could be right, because the parent > project has an ordered property and the sibling above is not yet > complete. > --- > > Should the first task in a subproject of a project > having the ':ORDERED:' property set to true be blocked from marking > 'DONE'? If so, why? I think the answer is yes it should be blocked because the entire tree is blocked - the previous task needs to be DONE first. When the subtree is unblocked you can then complete the first task in the subtree. -Bernt > > The above minimal case is easy, but it's far from trivial to see why > tasks in projects are blocked if the project is longer and has more > outline levels. > > My expectation of the ordered property would be that it only acted > one-level deep, regarded from a 'block-or-not' standpoint. > > Thoughts? -- Bernt
Re: [O] org-babel -- Improper syntax error in session mode?
Herbert Sitz wrote: > ... (and, it turns out, _avoid_ blank lines in other cases) What are those cases? Nick
Re: [O] org-babel -- Improper syntax error in session mode?
Herbert Sitz wrote: > - > > but this doesn't > - > #+begin_src python :results output :session mypy > x = 1 > y = 1 > z = 1 > for i in range(1,2): > x = x + i > print x > > for y in range(10,11): > print y > > for z in range(5,6): > print z > while y > 0: > print y > y=y-1 > > print "Did it work?" > #+end_src > -- > It works fine if you make the empty lines "indented empty" lines: add enough space so the newline is at the proper indentation point. Nick
Re: [O] org-babel -- Improper syntax error in session mode?
Perhaps I should explain my personal view of what Babel "sessions" are, I'm not saying this is *the* view, just my own. Babel sessions explicitly are thin wrappers around the interactive mode of the language in question (whatever that may be). That is why Babel happily doesn't implement sessions for all languages, the contract simply is that if a language supports interactive evaluation, Babel will try to allow access to that functionality. If the contract was rather simply "Babel provides session based evaluation", then we'd be on the hook for implementing session evaluation where it doesn't already exist and may not make sense (e.g., C, ditaa), and normalizing everywhere else as you're suggesting here. Which would in turn requires us to spell out Babel-specific semantics of session based evaluation -- something we have thus-far avoided. Some positive points *for* the "thin wrapper" approach include; 1. It is the simplest to implement - easier to implement support for new language - easier to maintain -- especially if interactive tools change - easier to reason about -- thinking about bug fixing here - works with alternate back-ends e.g., ipython 2. It is the least surprising. I'd maintain that for users familiar with using Python sessions this behavior is the easiest to quickly understand and use. As opposed to if we did something fancy (even if it was an improvement) it would be another environment for language users to have to familiarize themselves with -- they'd have both normal session rules and babel session rules I guess that's it, I'm happy to be convinced otherwise, or simply be outvoted. If you want to look at the code I'm happy to help in any way I can, my previous patch would probably be a good place to start. Just be careful, if you get too comfortable with Emacs Lisp you might find it hard to go back to working with VM's extension language. :) a few more scattered comments below... Herbert Sitz writes: [...] > > Maybe adding the extra lines is beyond Babel's scope, strictly speaking. I > can > think of some good reasons for doing it though: > > (1a) Babel is not an interactive shell. > Exactly, it is a window to a language's interactive run-time as defined by the language's tools. > > (1b) It's not obvious to the Babel user that sessions are being processed > using > Python's interactive shell. I'd disagree, to my mind this is the simplest explanation of session evaluation. > Even if that is known (I know it's somewhere in the docs), Perhaps the documentation should be tweaked to make this point more clear. > it's not clear to a user why Babel would require a user to insert the > extra lines (and, it turns out, _avoid_ blank lines in other cases), > which make sense in interactive environment but not within Babel's > non-interactive environment. Even if this particular idiosyncrasy is > documented somewhere it's going to cause confusion for users who skim > the docs and just expect regular Python code to work without problems. But any *other* behavior would be surprising to users who are familiar with using Python's interactive shell, and think of code blocks as simply a place to store transcripts of interactive sessions they may want to dump back into the session at some point in the future. > > (If I'm first to report the issue maybe there aren't many Org users > trying to use :session mode with Python, though.) > or (if they are regular Python users) they didn't find this behavior to be surprising. > > (2) Isn't the blank-line issue an easy fix? I think it requires just these > two > simple changes to source block before submitting to python shell: (a) Regex > search replace to add a blank line before any "unindented" line that is > preceded > by an indented line (actually it may work fine to just put blank line before > _any_ "unindented" textline in the source-block); and (b) deletion of all > blank > lines in the source-block that are followed by "indented" text on next line. > I agree, it shouldn't be an overly difficult fix, but I'm worried about precedent. This gives me a distinct "foot in the door" feeling, and it breaks the /thin wrapper/ contract I spelled out above. > > >> Does it work for other "normal" Python interactive code blocks? Have >> you noticed any places where the previous version worked but the new >> version doesn't? If it seems safe then I would like to apply it. > > I think the start with a stray blank line before what should be the > actual output. Otherwise It does seem to be working well with the few more > complicated things I've created to throw at it. > Great, thanks. I appreciate you testing this out. I've just applied the patch since, regardless of the outcome of this thread I think we're all agreed that the patch is better than the current behavior. > > I'm not really a big Python user, was just doing some testing in my > vim-Org-clone with Python when I noticed the problem
Re: [O] org-babel -- Improper syntax error in session mode?
Eric Schulte gmail.com> writes:
>
> Babel sessions explicitly are thin wrappers around the interactive mode
> of the language in question (whatever that may be). That is why Babel
> happily doesn't implement sessions for all languages, the contract
> simply is that if a language supports interactive evaluation, Babel will
> try to allow access to that functionality.
>
That the Babel session is only a "thin" wrapper is not clear at all from the
docs. The docs do mention 'interactive session'--and even that the output may
be slightly different from the non-session mode. The docs don't mention
anything about the user needing to do extra preparation to avoid syntax errors
in evaluation of already valid code. If I take an existing Org block of
non-session code and stick a :session on I don't expect to get syntax errors.
If that's the expected behavior then it needs to be emphasized more in the
docs, otherwise most users will think something is broken in Org.
> If the contract was rather simply "Babel provides session based
> evaluation", then we'd be on the hook for implementing session
> evaluation where it doesn't already exist and may not make sense (e.g.,
> C, ditaa), and normalizing everywhere else as you're suggesting here.
> Which would in turn requires us to spell out Babel-specific semantics of
> session based evaluation -- something we have thus-far avoided.
Again, the docs reference 'Session based evaluation' in big bold letters and
don't indicate the thinness of the wrapper.
>
> Some positive points *for* the "thin wrapper" approach include;
>
> 1. It is the simplest to implement
>- easier to implement support for new language
>- easier to maintain -- especially if interactive tools change
>- easier to reason about -- thinking about bug fixing here
>- works with alternate back-ends e.g., ipython
>
I think I have a solution for Python that gives full "session-based evaluation"
and which is better than the current "thin wrapper" for all four concerns above
(See bottom of my message for an example.) This same approach, I think, would
work for Ruby, but I would need to do a little digging to find exact method.
Let me know if you want me to do that digging.
> 2. It is the least surprising. I'd maintain that for users familiar
>with using Python sessions this behavior is the easiest to quickly
>understand and use. As opposed to if we did something fancy (even if
>it was an improvement) it would be another environment for language
>users to have to familiarize themselves with -- they'd have both
>normal session rules and babel session rules
As a sometimes Python user it had me totally confused. I don't think of
"session-based" as having any essential tie to "interactive shell" at all. Why
would I worry about state being maintained between statements in an org block?
State is already maintained between statements in non-session Org blocks. The
only difference with session-based blocks is the starting state may not be
"fresh".
When I look at Org and think of "session-based" blocks, I see a potential big
benefit in having multiple source-blocks throughout my document share the same
session. That way I don't need to use Org's (clever and useful but) somewhat
clunky and inflexible method of passing data explicitly. In statistics-based
docs, for example, I can imagine that the sheer amount of data would make using
Org's explicit variable-passing method unfeasible. Using
session-based-evaluation is at the same time both simpler and more heavy-duty.
I never thought the use of session-based code blocks as something like a
scratchpad was much more than toy. If you're typing in code that's not intended
to be an integral part of an Org doc then you could just as well jump to the
shell and enter it there.
Here's an example of how to run a block of Python code of any length in the
interactive session and save its output in a file. Note that this is _not_
interactive, even though the command runs in the interactive shell's session:
Start with this block of code:
-
#+begin_src python :results output :session mypy
x = 1
y = 1
z = 1
for i in range(1,2):
x = x + i
print x
for y in range(10,11):
print y
# comment here
for z in range(5,6):
print z
while y > 0:
print y
y=y-1
print "Did it work?"
#+end_src
Strip out the block of empty space at the left side and save in a file in
current directory (say, 'pyfile.py') with a couple commands prepended and
appended:
-
# beginning of file
# prepend code to redirect stdout to file
import sys
saveout = sys.stdout
fsock = open('pyfile-output.log','w')
sys.stdout = fsock
# code block here, with beginning space block removed
x = 1
y = 1
z = 1
for i in range(1,2):
x = x + i
print x
