Re: [O] Bug: conflict with python-mode [7.8.11]
Am 25.12.2012 04:14, schrieb Bastien: I can finally reproduce the bug. It comes from python-model.el which set this: (defvar outline-heading-end-regexp nil) Andreas, this breaks outline in Org - can you have a look? Thanks, This was fixed in trunk some days ago. Get it via bzr branch lp:python-mode BTW bug should not show up, if org-mode gets loaded before python-mode.el Cheers, Andreas
Re: [O] Bug: conflict with python-mode [7.8.11]
Hi Andreas, Andreas Röhler writes: > This was fixed in trunk some days ago. Get it via > > bzr branch lp:python-mode Thanks. I let Till confirm the fix. > BTW bug should not show up, if org-mode gets loaded before > python-mode.el Maybe, but normal use of Org don't require to require org-mode explicitly in the user init file, as .org files load org-mode automatically. -- Bastien
Re: [O] org-plus-contrib-20121224 error
Hi Alan, Alan L Tyree writes: > Using the above package in emacs 24.2.1 on Debian Wheezy/Sid, I get an > error when trying to call up the agenda with C-C a. The error is > > Invalid function: org-no-popups. Did you restart Emacs? Can you send a backtrace? -- Bastien
Re: [O] Footnote disable & sorting
Hi Alan, Alan L Tyree writes: > I'm using the elpa version of org-plus-contrib-20121224. After I learned > how to apply patches (hangs head in shame!!), it solved all the problems > that I had - sorting, renumbering, exporting all worked very well. > > Are you thinking of making this a general option? Yes, sure! Just need to have more time ahead to fix the tests and to double-check the code. -- Bastien
Re: [O] [PATCH] Introduce a new variable for x11idle
Hi Yasushi, Yasushi SHOJI writes: > I've signed the paper and it's on its way to FSF. it will take a few > more days to reach the office, though. great -- thanks! I've added you to the list of contributors waiting for the FSF confirmation. If you don't get any feedback within the next three weeks, let me know, I can try to accelerate things. Best, -- Bastien
[O] [PATCH] Caching latex preview images
Hi, Org mode lost the ability to reuse already generated latex preview images in commit 27101a3e0ee7. Now it just regenerates all of them every time. I don't see a reason for removing this feature (am I missing something?), so here is a little patch reintroducing that feature. I'm also mailing the author of that commit. Abdó Roig-Maranges. >From cd284a858a653c28e42b09fa07f172172ceba510 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Abd=C3=B3=20Roig-Maranges?= Date: Tue, 23 Oct 2012 18:44:24 +0200 Subject: [PATCH] org.el: Don't re-generate latex previews if already present * org.el (org-format-latex): Do not re-generate a latex preview if the image already exists. This feature was lost in commit 27101a3e0ee7 --- lisp/org.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ee4c70e..3ba1ab8 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -17636,8 +17636,9 @@ Some of the options can be changed using the variable (unless checkdir ; make sure the directory exists (setq checkdir t) (or (file-directory-p todir) (make-directory todir t))) - (org-create-formula-image - txt movefile optnew forbuffer processing-type) + (unless (file-exists-p movefile) + (org-create-formula-image + txt movefile optnew forbuffer processing-type)) (if overlays (progn (mapc (lambda (o) -- 1.8.0.2
[O] calculate frequencies in a table with calc
Dear helpers, on the web I found a formula to get frequencies which I modified to my needs, but it does not yet work well. An example: |-| | [1, 2, 3, 4, 5] | | [6, 7, 8] | | [9, 10, 11, 12, 12] | | 12, 12 | |-| | 15 | | 2 | #+TBLFM: @5$1=vcount(@I..@II)::@6$1=vcount(map(,@I..@II)) With the first formula (@5$1) everything inside and outside the brackets is counted, but with the second (@6$1), where I am asking for the frequency of 12, only what is outside the brackets is considered. How could I also include what is inside the brackets, so I get 4? Thank you very much in advance! Martin
Re: [O] Python code for producing Org tables
Bastien writes: > Would you like something like > | 3.1 | > | 3.1415 | > be aligned/modified as > | 3.1000 | > | 3.1415 | > ? More precisely as: > | 3.1| > | 3.1415 | which is aligning on dots, even if it looks like left-justifying. There is a problem in that I have tables using a decimal period, and others using a decimal comma, and the Python code only handles periods. Instead of diving into complex locales things, which would not do anyway, I would merely recognize both as a reasonable compromise. > Don't worry, once you'll dive into `org-table-align' chances are that > you will feel like "working" instead of "toying" :) Grrr! :-) > Bonnes fêtes ! Itou, itou! François (who is soon going, to play the office this morning).
Re: [O] Python code for producing Org tables
Dov Grobgeld writes: > Nice! I've needed that often. But please add licensing information > to the code to make clear in what contexts it may be used. You mean, for the Python bits I sent to the list? For such a short amount of code, do whatever you feel like it. If you really want an explicit license, then consider either the GPLv2, or whatever Org Lisp code is using. I'll merely let you add it on your side, rather than polluting the list with a re-invoice. :-) François (who is not a fussy guy).
Re: [O] Rudel - Real-Time collaborative editing of Org-Mode files
Bastien writes: > I don't have experience with Rudel but I'm also interested in hearing > from others -- maybe at some point we can organize some co-writing > session where we try to update Worg pages. I tried Rudel, a good while ago, and did not find it satisfying enough to be usable, besides an emulation of the old "talk" functionality. After your message, I quickly revisited its Web site. While it got more interesting on the side of supporting various standards and methods, and without trying it this time, I got the feeling its UI did not really improve, or at least, is still way too far from Org. Or maybe it's just that I lack enthusiasm and vision? > http://prose.io/about.html > https://github.com/prose Saving these pointers, might be worth further checking? > [...] let *anyone* write Org doc collaboratively and seemlessly. > Com'on, let's start something great :) It would be great indeed! Where I work, Org has no chance of spreading to the remainder of the development team, exactly because it is not real-time collaborative. So we use other (flashy but weaker) means instead. François
Re: [O] Bug: inline tasks behave strange with respect to visibility cycling within plain lists [7.9.2 (release_7.9.2-646-g664217 @ /home/grfz/src/org-mode/lisp/)]
Hi Bastien, org developers, * Bastien [24. Dec. 2012]: > I think you are misusing inline tasks, the stars should start > at the beginning of the line. thank you for spending some of your holiday on this. The blanks at the beginning of the inline task were an artefact of selecting/pasting, killing/yanking. Sorry for this. I did the whole thing again but with more care: This is with recent Emacs-snapshot: GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2012-12-24 on dex, modified by Debian and recent org-mode (via `make up1'): Org-mode version 7.9.2 (release_7.9.2-881-g99c873 @ /home/grfz/src/org-mode/lisp/) The test suite says: "Ran 320 tests, 320 results as expected (2012-12-25 13:07:27+0100) 7 expected failures" I did the following test with `emacs-snapshot -Q -nw -l ~/.emacs.d/_minimal.org-init.el /tmp/testinlinetask.org' with `~/.emacs.d/_minimal.org-init.el' being: >>> (add-to-list 'load-path "~/src/org-mode/lisp") <<< and /tmp/testinlinetask.org being: >>> * first heading 1) master list - first plain list item - second plain list item - third plain list item - first sub list item - second sub list item * TODO inline task - third sub list item - fourth sub list item - fourth plain list item 2) another master list - two one - two two * second heading 1) master list two one - plain list - plain list 2) masterlist two two * third heading <<< I often want to use inline tasks within plain lists. The following org file shows a bug and a problem with inline tasks in plain lists with respect to visibility cycling >>> * first heading 1) master list - first plain list item - second plain list item - third plain list item - first sub list item - second sub list item * TODO inline task - third sub list item - fourth sub list item - fourth plain list item 2) another master list - two one - two two * second heading 1) master list two one - plain list - plain list 2) masterlist two two * third heading <<< In Overview it looks like this >>> * first heading... * second heading... * third heading <<< With point on the first star and org-cycle-include-plain-lists set to `As children of outline heading' org-cycle reveals an error: `byte-code: Invalid search bound (wrong side of point)'. This is a bug. The display looks now like this: >>> * first heading 1) master list... * TODO inline task... * second heading... * third heading <<< Since this resulted in an error I now begin in overview again, this time with `org-cycle-include-plain-lists' set to `t': OVERVIEW: >>> * first heading... * second heading... * third heading <<< With cursor on first star do org-cycle one time: >>> * first heading 1) master list - first plain list item - second plain list item - third plain list item - first sub list item - second sub list item * TODO inline task... * second heading... * third heading <<< Here I do not see the second half of the first `master list' nor the second master list. This is hinted at with the ellipses after the inline task but I understand inline task as not "disturbing" cycling. Therefore I would expect to see only the children of the first heading: >>> * first heading 1) master list 2) another master list * second heading * third heading <<< Now move point to `1' and do org-cycle again: >>> * first heading 1) master list... * TODO inline task... * second heading... * third heading <<< In the echo area it org-mode says: "FOLDED": Now the list `1)' is folded but without the inline task. I would expect to not see the inline task. Now with point still on `1' do org-cycle again: >>> * first heading 1) master list - first plain list item - second plain list item - third plain list item... * TODO inline task... * second heading... * third heading <<< In the echo area it org-mode says: "CHILDREN": here I would expect to see the fourth plain list item but it is still hidden under the inline task. Now with point still on `1' do org-cycle again: >>
Re: [O] [PATCH] Introduce a new variable for x11idle
Hi Bastien, At Sun, 23 Dec 2012 21:03:57 +0100, Bastien wrote: > > Since the patch is substantial, we need you sign the FSF copyright > assignment in order to apply it. If that's okay with you, please > fill the form here and follow the instructions here: > > http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt Thank you for the info. I've signed the paper and it's on its way to FSF. it will take a few more days to reach the office, though. Thanks, -- yashi
Re: [O] elp-instrument-package does not return anything
Hi Samuel, Samuel Wales wrote: > One way to ensure that the symbols exist might be to run the function > first without instrumenting, then instrument? That'd solve the problem if all such functions do have autoloads. That should be the case for Org, but not necessarily for all other packages. But explicitly requiring the packages is as easy -- my problem was not knowing we absolutely had to do it! > Can't help you with the optimizing, but I strongly support your > efforts. Speeding up agenda would be a boon. Thanks! Best regards, Seb -- Sebastien Vauban
Re: [O] elp-instrument-package does not return anything
Hi Bastien, Bastien wrote: > "Sebastien Vauban" wrote: > >> Generating the agenda for 43 files, and more or less 75 entries to display, >> takes between 17 and 20 seconds, in this case 19 seconds: >> >> org-agenda-list 1 >> 19.15619.156 >> org-agenda-prepare1 >> 11.14111.141 >> org-agenda-prepare-buffers1 >> 11.07811.078 >> org-get-agenda-file-buffer344 >> 11.06400 0.0321627906 > ^^ > > This is the most significant entry for me: it tells that Emacs on your > machine takes quite a lot of time to access files. May be due to your > harddrive and your computer... Though, I can ensure you that, 2 weeks ago, I did run Windows' defrag multiple times -- and it did change the colors shown in its analysis phase. For the rest, not sure to notice any speedup, however. I mean: sure, I did not notice any real difference. But better it's done, anyway. >> org-agenda-get-day-entries301 >> 7.517999 0.0249767441 >> org-agenda-get-scheduled 301 >> 4.518000 0.0150099667 >> org-mode 43 >> 3.771000 0.0876976744 >> org-entry-get 2601 >> 2.033999 0.0007820069 >> org-back-to-heading 6 >> 1.967999 0.0001770421 >> org-get-property-block2601 >> 1.908999 0.0007339484 >> outline-back-to-heading 6 >> 1.77 0.0001601295 >> org-set-startup-visibility43 >> 1.391 0.0323488372 >> org-agenda-get-deadlines 301 >> 1.36 0.0045182724 >> org-get-todo-state3782 >> 1.33 0.0003543098 >> org-agenda-files 46 >> 0.805000 0.017500 >> org-cycle-internal-global 43 >> 0.781000 0.0181627906 >> org-cycle 43 >> 0.781000 0.0181627906 >> org-install-agenda-files-menu 43 >> 0.774000 0.018000 >> org-agenda-skip 4636 >> 0.717000 0.0001546591 >> org-agenda-get-sexps 301 >> 0.702000 0.0023322259 >> outline-next-heading 7764 >> 0.678000 8.73...e-005 >> org-overview 43 >> 0.672000 0.0156279069 >> outline-map-region43 >> 0.609000 0.0141627906 >> org-load-modules-maybe86 >> 0.594 0.0069069767 >> org-time-string-to-absolute 3759 >> 0.517000 0.0001375365 >> org-parse-time-string 4088 >> 0.5 0.0001223091 >> org-set-regexps-and-options 43 >> 0.497000 0.0115581395 >> org-cycle-hide-drawers86 >> 0.405000 0.0047093023 >> org-find-base-buffer-visiting 344 >> 0.404000 0.0011744186 >> org-agenda-get-timestamps 301 >> 0.359000 0.0011926910 >> org-agenda-get-blocks 301 >> 0.347000 0.0011528239 >> org-diary-sexp-entry 714 >> 0.328000 0.0004593837 >> org-flag-drawer 1396 >> 0.297000 0.0002127507 >> org-before-first-heading-p2602 >> 0.282000 0.0001083781 >> org-outline-level 4313 >> 0.265 6.14...e-005 >> org-cycle-show-empty-lines86 >> 0.205000 0.0023837209 >> org-agenda-finalize-entries 4 >> 0.203 0.05075 >> org-macro-initialize-templates43 >> 0.173000 0.0040232558 >> org-get-tags-at 84 >> 0.171000 0.0020357142 >> org-up-heading-safe 225 >> 0.14 0.000622 >> o
Re: [O] Bug: conflict with python-mode [7.8.11]
Hi guys, First of all, thank you so much for your quick answers during the holidays, I really didn't expect any answer until next year :) So, Andreas was right, I got the newest version of python-mode and the problem is gone. BTW, the bug also show up if org-mode gets loaded before or after python-mode, it doesn't matter. It was the first thing I tried. Thanks, great work Till On 12/25/2012 11:28 AM, Bastien wrote: > Hi Andreas, > > Andreas Röhler writes: > >> This was fixed in trunk some days ago. Get it via >> >> bzr branch lp:python-mode > Thanks. I let Till confirm the fix. > >> BTW bug should not show up, if org-mode gets loaded before >> python-mode.el > Maybe, but normal use of Org don't require to require org-mode > explicitly in the user init file, as .org files load org-mode > automatically. > signature.asc Description: OpenPGP digital signature
Re: [O] org-plus-contrib-20121224 error
Bastien writes: > Hi Alan, > > Alan L Tyree writes: > >> Using the above package in emacs 24.2.1 on Debian Wheezy/Sid, I get an >> error when trying to call up the agenda with C-C a. The error is >> >> Invalid function: org-no-popups. > > Did you restart Emacs? Yes. And it is on two separate machines with slightly different configuations. > > Can you send a backtrace? I can if you give me a pointer as to how to do it. -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] Footnote disable & sorting
Bastien writes: > Hi Alan, > > Alan L Tyree writes: > >> I'm using the elpa version of org-plus-contrib-20121224. After I learned >> how to apply patches (hangs head in shame!!), it solved all the problems >> that I had - sorting, renumbering, exporting all worked very well. >> >> Are you thinking of making this a general option? > > Yes, sure! Just need to have more time ahead to fix the tests and to > double-check the code. This is fantastic, Bastien. It really makes org even more attractive as an authoring environment, at least for me. Great software! Cheers, Alan -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] org-plus-contrib-20121224 error [Solved]
Bastien writes: > Hi Alan, > > Alan L Tyree writes: > >> Using the above package in emacs 24.2.1 on Debian Wheezy/Sid, I get an >> error when trying to call up the agenda with C-C a. The error is >> >> Invalid function: org-no-popups. > > Did you restart Emacs? > > Can you send a backtrace? I deleted and then reinstalled the package and everything is OK. But I have no idea what went wrong since agenda was working and then stopped with the installation of the new package. Sorry for the noise. -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] elp-instrument-package does not return anything
On 12/25/12, Sebastien Vauban wrote: > That'd solve the problem if all such functions do have autoloads. That > should > be the case for Org, but not necessarily for all other packages. In which case you get an error, thus ensuring. :) Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] Agenda highlighting bug
On 12/24/2012 09:48 AM, Bastien wrote: Hi Simon, Simon Thum writes: I recently added an org file which is an import from our community service, the so-called "Müllabfuhr", which I put in "müllabfuhr.org". The agenda fails to highlight these entries however. It's not terrible, actually it's JUST PERFECT because this is such a minor thing but it sucks to miss it. Could you provide a minimal config and example to reproduce this bug? Special character should not prevent the inclusion of tasks in the agenda, and I never noticed anything like this before... I can't reproduce it currently, maybe it was just that most agenda entries are scheduled/dealined and the highlighting was actually normal. The more difficult problem for me was that the agenda file in my case contains a list of files which is synchronised over systems. Wherever I add this file (win32 vs. linux) the other system fails to load the agenda then. I dropped back to non-special surrogates but it feels like 90s. Can I set the agenda file's encoding or is there something else which comes to mind? I'd also like to use this opportunity to ask about more graceful agenda handling of changed files. When someone (not emacs) touches agenda files, the agenda code fails horribly. That is even if the file is readonly or has the "#+READONLY" header (which seems menaingful only to org-mobile). It would be preferable to just reload in this case. ATM, I am queried about something related to reloading and the agenda cancels no matter what I say. Cheers, Simon
Re: [O] org-plus-contrib-20121224 error
Alan L Tyree wrote: > > Bastien writes: > > > Hi Alan, > > > > Alan L Tyree writes: > > > >> Using the above package in emacs 24.2.1 on Debian Wheezy/Sid, I get an > >> error when trying to call up the agenda with C-C a. The error is > >> > >> Invalid function: org-no-popups. > > > > Did you restart Emacs? > Yes. And it is on two separate machines with slightly different configuations. > > > > Can you send a backtrace? > I can if you give me a pointer as to how to do it. > See section 1.4, "Feedback", in the org manual. Nick
Re: [O] Rudel - Real-Time collaborative editing of Org-Mode files
François Pinard writes: > Bastien writes: >> [...] let *anyone* write Org doc collaboratively and seemlessly. >> Com'on, let's start something great :) > It would be great indeed! On the road this morning, I gave some thought on this problem, which does not seem trivial at all, to me at least. Unless taken under the appropriate angle — which I do not know yet! — I think I see that many design choices could trap developers in a maze of sad consequences. Nevertheless, it might be an interesting problem. Maybe it would be worth seeking a few avenues on this mailing list, trying to find a workable solution? Would there be an interest for such a discussion? François
Re: [O] org-plus-contrib-20121224 error
On 26/12/12 06:56, Nick Dokos wrote: Alan L Tyree wrote: Bastien writes: Hi Alan, Alan L Tyree writes: Using the above package in emacs 24.2.1 on Debian Wheezy/Sid, I get an error when trying to call up the agenda with C-C a. The error is Invalid function: org-no-popups. Did you restart Emacs? Yes. And it is on two separate machines with slightly different configuations. Can you send a backtrace? I can if you give me a pointer as to how to do it. See section 1.4, "Feedback", in the org manual. Thanks Nick. You guys are very patient with guys like me. Cheers, Alan Nick -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
[O] Bug: source block editing on headings fail on 2nd source block [7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)]
The following issues use my org-mode source http://doc.norang.ca/org-mode.org org-mode.org line 117 column > 0 #+begin_src sh cd ~/git git clone git://orgmode.org/org-mode.git #+end_src C-c ' works on the first line but not on the one below which is identical. #+begin_src sh cd ~/git git clone git://orgmode.org/org-mode.git #+end_src C-c ' gives #+begin_example Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) org-edit-src-code() org-edit-special() call-interactively(org-edit-special nil nil) #+end_example Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)
Re: [O] Opendocument export causes error
Dear Jambunathan and others, Apologies for resending this message, but my email from yesterday seemingly did not arrive. To summarise at first, the results in my 2nd IELM session (at the end of the message below) differed clearly from those in your kindly provided template -- in several cases symbol-file returned nil instead a path, and for (symbol-file 'org-macs 'require) it returns a different path that in your template. Does that perhaps point towards the problem? Here is the full story. Please remember that I cannot not use the OpenDocument export, because -- as far as I understood -- (the correct version of) "org-compat.el" and "org-odt.el" are not loaded. This is perhaps caused by the fact that the Emacs I am using (the latest stable release of Aquamacs, version 2.4) is based on the rather old GNU Emacs 23.3.50.1. Aquamacs is widely used on the Mac platform, so likely I am not the only one with these problems. I temporarily fixed my problem by loading the respective libraries manually in my ~/.emacs file as below, but as others may also have this problem this is probably not the best and certainly not a clean solution. ;; TMP hack to get OpenDocument export working again (load-library "org-compat.el") (load-library "org-odt.el") Anyway, I finally ran the tests you suggested (thanks a lot for detailing these!). > 1. Load Emacs like this. Adjust the `-L's. Note also the -Q. > > emacs --debug-init -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp -Q Aquamacs started. Clearly, Aquamacs was not fully loaded (e.g., standard Mac short-cuts where not yet defined). Anyway, it output the following message in *Messages* Aquamacs is based on GNU Emacs, a part of the GNU/Linux system. It is Free Software: you can improve and redistribute it under the GNU General Public License, version 3 or later. Copyright (C) 2011 Free Software Foundation, Inc. (C) 2011 D. Reitter. No Warranty. ns-handle-drag-file: Symbol's value as variable is void: one-buffer-one-frame-mode To double check, I confirmed the Emacs version. GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-10-25 on braeburn.aquamacs.org Copyright (C) 2011 Free Software Foundation, Inc. > 2. M-x load-library RET org-odt RET Loading org-odt... Loading /Users/torsten/emacs/org-mode/lisp/org-loaddefs.el (source)...done Debug (org-odt): Searching for OpenDocument schema files... Debug (org-odt): Trying /usr/share/emacs/etc/org/schema/... [2 times] Debug (org-odt): No OpenDocument schema files installed Debug (org-odt): Searching for OpenDocument styles files... Debug (org-odt): Trying /usr/share/emacs/etc/org/styles/... [2 times] Debug (org-odt): Trying /Users/torsten/emacs/org-mode/etc/styles/... Debug (org-odt): Using styles under /Users/torsten/emacs/org-mode/etc/styles/ Loading org-odt...done > 3. M-x ielm RET > | ELISP> (symbol-file 'org-compat 'require) "/Users/torsten/emacs/org-mode/lisp/org.elc" > | ELISP> (symbol-file 'org 'require) "/Users/torsten/emacs/org-mode/lisp/org-exp.elc" > | ELISP> (symbol-file 'org-exp 'require) "/Users/torsten/emacs/org-mode/lisp/org-lparse.elc" > | ELISP> (symbol-file 'org-lparse 'require) "/Users/torsten/emacs/org-mode/lisp/org-odt.elc" > | ELISP> (symbol-file 'org-odt 'require) nil I restarted Aquamacs and repeated all above except for the previous ielm session (just in case, as I do not know whether symbol-file has any side effects). > | ELISP> (symbol-file 'org-compat 'require) "/Users/torsten/emacs/org-mode/lisp/org.elc" > | ELISP> (symbol-file 'org 'require) "/Users/torsten/emacs/org-mode/lisp/org-exp.elc" > | ELISP> (symbol-file 'org-element 'require) nil > | ELISP> (symbol-file 'org-export 'require) nil > | ELISP> (symbol-file 'org-e-odt 'require) nil > | ELISP> (symbol-file 'org-macs 'require) "/Users/torsten/emacs/org-mode/lisp/org-exp.elc" Again, thanks a lot for your help! Best wishes, Torsten On 4 Dec 2012, at 05:33, Jambunathan K wrote: >> I will go through your detailed list of suggestions a bit >> later. Thanks a lot again for your help! > > I hope you do revert with your observations on broken setup. > > In my experience, most users don't :-). > > There is some confusion around the area of macros and autoloads. > Something is amiss. Only non-programmers seem to run in to this and it > has been very difficult to understand what is happening on their setup, > without their co-operation. > > Here is another suggestion. A bit easy one though. This will be > archived and will serve as a written hint to debug macro/autoload > issues. > > When the err happens, > > 1. Load Emacs like this. Adjust the `-L's. Note also the -Q. > > emacs --debug-init -L ~/src/org-mode/lisp -L > ~/src/org-mode/contrib/lisp -Q > > 2. M-x load-library RET org-odt RET > > 3. M-x ielm RET > > Here is a sample session both for org-odt and org-e-odt. Sample > illustrates the sequence of events that led org-compat.el
[O] Bug: Commas not removed from source blocks [7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)]
I have org source blocks in my document http://doc.norang.ca/org-mode.org which have embedded commas on line 1 from previous uses of org-edit-special. Now editing the blocks does not remove all of the commas previously introduced. I use org-indent mode with source blocks starting in column 0 org-mode.org lines 327 #+begin_src org :exports src ,* Health and Recreation ,PROPERTIES: ,CATEGORY: Health ,END: , ... ,* House Maintenance ,PROPERTIES: ,CATEGORY: House ,END: #+end_src org-mode.org lines 1880 #+begin_src org :exports src ,Original Estimate ,#+BEGIN: columnview :hlines 1 :id local ,| Task| Estimated Effort | CLOCKSUM | ,|-+--+--| ,| ** TODO Project to estimate | 5:40 | | ,| *** TODO Step 1 | 0:10 | | ,| *** TODO Step 2 | 0:10 | | ,| *** TODO Step 3 | 5:10 | | ,| TODO Step 3.1 | 2:00 | | ,| TODO Step 3.2 | 3:00 | | ,| TODO Step 3.3 | 0:10 | | ,| *** TODO Step 4 | 0:10 | | ,#+END: #+end_src C-c ' shows org-mode source block with commas only removed from headings. The property lines still contain the commas. I believe the commas were originally inserted by a previous version of org-mode during org-edit-special. Usecase: I do not want these property lines from the org source block to apply to the enclosing heading. Also occurs on line 709 #+begin_src org :exports src ,* TODO New Capture Task , LOGBOOK: , END: , [2010-05-08 Sat 13:53] #+end_src Also occurs on line 759 #+begin_src org :exports src ,* TODO , [2010-08-05 Thu 21:06] , [[file:~/git/org-mode-doc/org-mode.org::*Capture%20Tasks%20is%20all%20about%20being%20FAST][Capture Tasks is all about being FAST]] #+end_src Also occurs on line 1261 #+begin_src org :exports src ,#+FILETAGS: PERSONAL ,... ,* Tasks ,** Organization ,PROPERTIES: ,CLOCK_MODELINE_TOTAL: today ,ID: eb155a82-92b2-4f25-a3c6-0304591af2f9 ,END: ,... #+end_src Also occurs on line 2260 #+begin_src org :exports src ,* NEXT Weekly Review [0/6] , SCHEDULED: <2009-05-18 Mon ++1w> , LOGBOOK:... , PROPERTIES:... , What to review: , - [ ] Check follow-up folder , - [ ] Review weekly agenda =F12 a w //= , - [ ] Check clocking data for past week =v c= , - [ ] Review clock report for past week =R= ,- Check where we spent time (too much or too little) and rectify this week , - [ ] Look at entire agenda for today =F12 SPC= , - [ ] Review projects =F12 SPC //= and =V= repeatedly to view each project , - start work ,- daily agenda first - knock off items ,- then work on NEXT tasks #+end_src and line 2766 #+begin_src org :exports src ,#+begin_src ditaa :file some_filename.png :cmdline -r -s 0.8 , ,#+end_src #+end_src line 3793 #+begin_src org :exports src ,#+FILETAGS: PERSONAL ,* Appointments ,PROPERTIES: ,CATEGORY: Appt ,ARCHIVE: %s_archive::* Appointments ,END: ,** Holidays ,PROPERTIES: ,Category: Holiday ,END: ,%%(org-calendar-holiday) ,** Some other Appointment , ... #+end_src line 4029 #+begin_src org :exports src ,* TODO Invoicing and Archive Tasks [0/7] , DEADLINE: <2009-07-01 Wed +1m -0d> ,PROPERTIES: ,RESET_CHECK_BOXES: t ,END: , - [ ] Do task 1 , - [ ] Do task 2 , ... , - [ ] Do task 7 #+end_src line 4100 #+begin_src org :exports src ,* TODO New Repeating Task , SCHEDULED: <2009-06-16 Tue +1w> ,PROPERTIES: ,NOBLOCKING: t ,END: ,... ,** TODO Subtask #+end_src line 4116 #+begin_src org :exports src ,* TODO Some Task ,PROPERTY: ,ORDERED: t ,END: ,** TODO Step 1 ,** TODO Step 2 ,** TODO Step 3 #+end_src 4306 #+begin_src org :exports src ,* Attachments:ATTACH: ,PROPERTIES: ,Attachments: x.sql ,ID: f1d38e9a-ff70-4cc4-ab50-e8b58b2aaa7b ,END: #+end_src 4356 #+begin_src org :exports src ,* TODO Pay Wages , DEADLINE: <2009-07-01 Wed +1m -0d> #+end_src 4490 #+begin_src org :exports src ,* NEXT Document my use of org-mode ,LOGBOOK:... ,PROPERTIES: ,CLOCK_MODELINE_TOTAL: today ,Effort: 1:00 ,END: #+end_src 4549 #+begin_src org :exports src ,* TODO Update Org Mode Doc , SCHEDULED: <2009-11-21 Sat .+7d/30d> , [2009-11-14 Sat 11:45] ,PROPERTIES: ,STYLE: habit ,END: #+end_src 4622 #+begin_src org :exports src ,* Habits ,PROPERTIES: ,LOGGING: DONE(!) ,ARCHIVE: %s_archive::* Habits ,END: #+end_src 4949 #+begin_src org :exports src ,* TODO Sample Meeting , - Attendees ,- [ ] Joe ,- [X] Larry ,- [X] Mary ,- [X] Fred , - Joe is on vacation this week , - Status Updates ,+ Larry , - did this , - and that , - TODO: Needs to follow up on this ,+ Mary , - got a promotion for her recent efforts ,+ Fred , - completed all his tasks 2 days
[O] Bug: org-edit-special adds commas to source blocks repeatedly [7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)]
The following source blocks refer to my document http://doc.norang.ca/org-mode.org line 564 original : #name : #+begin_...#+end_ : # -- : #+begin_$1 $2 : $0 : #+end_$1 C-c ' twice : #name : #+begin_...#+end_ : # -- : ,#+begin_$1 $2 : $0 : ,#+end_$1 again C-c ' four times : #name : #+begin_...#+end_ : # -- : ,,#+begin_$1 $2 : $0 : ,,#+end_$1 commas are added to the #+begin and #+end lines Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)
[O] Bug: Can't edit example blocks [7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)]
The following source blocks refer to http://doc.norang.ca/org-mode.org
org-mode.org line 1553
#+begin_example
Default Task
[d] norang Organization <-- Task B
The task interrupted by starting the last one
[i] norang Organization <-- Task B
Current Clocking Task
[c] org NEXT Document my use of org-mode <-- Task A
Recent Tasks
[1] org NEXT Document my use of org-mode <-- Task A
[2] norang Organization <-- Task B
...
[Z] org DONE Fix default section links<-- 35 clock task
entries ago
#+end_example
C-c ' in the example block gives
#+begin_example
Debugger entered--Lisp error: (error "No special environment to edit here")
signal(error ("No special environment to edit here"))
user-error("No special environment to edit here")
org-edit-special()
call-interactively(org-edit-special nil nil)
#+end_example
This used to work in previous org versions
Usecase: I find it convenient to edit in a separate buffer, select
everything with C-x h, cut it and replace it than working on
the data in the example block. When example blocks are
indented in list entries org-edit-special automatically
indents the contents inside the indented #+begin_example
... #+end_example lines already properly indented for the
list.
Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
of 2010-12-11 on raven, modified by Debian
Package: Org-mode version 7.9.2 (release_7.9.2-781-g5de94e @
/home/bernt/git/org-mode/lisp/)
[O] Bug: Editing org src blocks doesn't work first time [7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)]
This may already be fixed by Bastien's commit enabling editing of org source blocks when org-fontify-natively is not set. I can't check that now but in case it isn't here is a bug report of the behaviour I saw before Christmas. I noticed some weird behaviour with source block editing. When source blocks are not fontified the block is greyed out as expected. Editing the block with C-c ' does NOT work except on column 0 of the begin_src line. Setting org-src-fontify-natively to t allows editing and fontifies the block natively after saving it. Following blocks are still greyed out and not editable except in column 0 of e begin_src line (using C-c ') After the block is fontified natively editing works as expected for the block. Regards, Bernt PS. Sorry if these bug reports are lacking in details... I am away for the holidays and composing these on my iPad. Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.9.2 (release_7.9.2-781-g5de94e @ /home/bernt/git/org-mode/lisp/)
Re: [O] Fix to property inheritance
While I'm figuring out how to create the patch and email it in the right format (I don't think I can with gmail), I've tried to make my bitbucket.orgrepository as public as possible. Perhaps give it another shot in the meantime. https://bitbucket.org/mrvwman/wishon-org-mode.git ~>Bill On Mon, Dec 24, 2012 at 7:28 PM, Bastien wrote: > Hi Bill, > > Bill Wishon writes: > > > My public git repository info is: git clone g...@bitbucket.org:mrvwman > > /wishon-org-mode.git > > branch name: fix-property-inheritance > > I could not clone this repository, apparently I don't have enough > rights. Can you send a patch? > > Thanks, > > -- > Bastien >
[O] [PATCH 1/2] Fix Property Inheritance
* org.el (org-update-property-plist): Added logic to replace the existing property value if the new value is nil or if the old value is nil. This is to support the usage of nil as a reset in a chain of PROP+ statements. Eg: :prop+: foo -> :prop+: nil -> :prop+: bar would result in a property value of bar. (org-re-property): Added an optional parameter to allow for this re to match PROP+ style properties with a new match to determine if it did have a + or not. (org-entry-get): Refactored the logic combining property values into a separate function org-combine-property-entries in order to re-use it in org-entry-get-with-inheritance-helper. (org-combine-property-entries): Refactored code from org-entry-get plus new logic to use nil as a resetting value in a chain of PROP+ declarations. See function documentation for more info. (org-entry-get-with-inheritance-helper): A recursion helper function for org-entry-get-with-inheritance. It walks up the org structure until it gets to the top, they combines properties using org-combine-property-entries as it comes back down. (org-entry-get-with-inheritance): Calls org-entry-get-with-inheritance helper and returns the property resulting property value. * property-inheritance.org: added a test for property inheritance through levels of headings in addition to the test to inherit from file wide properties. Also added a test to reset the heirarchy value by setting a property's value to nil. The problem here was that org-entry-get wasn't working when properties of the form PROP+ were used in multiple sub headings. It only worked to add to file level properties. Plus I added a way to reset the value in along the way by using :PROP+: nil. --- lisp/org.el | 118 + testing/examples/property-inheritance.org | 39 +- 2 files changed, 109 insertions(+), 48 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 3f4c319..4684988 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4511,13 +4511,15 @@ this variable to if the option is found. An optional forth element PUSH means to push this value onto the list in the variable.") (defun org-update-property-plist (key val props) - "Update PROPS with KEY and VAL." + "Update PROPS with KEY and VAL. +If val is \"nil\" replace the value with nil. +If the existing value of a property is \"nil\" then replace it with val." (let* ((appending (string= "+" (substring key (- (length key) 1 (key (if appending (substring key 0 (- (length key) 1)) key)) (remainder (org-remove-if (lambda (p) (string= (car p) key)) props)) (previous (cdr (assoc key props -(if appending - (cons (cons key (if previous (concat previous " " val) val)) remainder) +(if (and appending (not (or (string= val "") (string= val "nil" ; no sense in appending an empty string, and if the value is "nil" then replace what was there. + (cons (cons key (if (and previous (not (string= previous "nil"))) (concat previous " " val) val)) remainder) (cons (cons key val) remainder (defconst org-block-regexp @@ -14393,10 +14395,13 @@ Being in this list makes sure that they are offered for completion.") org-property-end-re "\\)\n?") "Matches an entire clock drawer.") -(defsubst org-re-property (property) +(defsubst org-re-property (property &optional include-additions) "Return a regexp matching a PROPERTY line. -Match group 1 will be set to the value." - (concat "^[ \t]*:" (regexp-quote property) ":[ \t]*\\(\\S-.*\\)")) +Match group 1 will be set to the value. +include-additions will allow the regex to match the :PROPERTY_NAME+: form +which adds values to defined in parent headings. If set Match group 1 will be +the + and the value will be match group 2." + (concat "^[ \t]*:" (regexp-quote property) (if include-additions "\\(\\+?\\)" "") ":[ \t]*\\(\\S-.*\\)")) (defsubst org-re-property-keyword (property) "Return a regexp matching a PROPERTY line, possibly with no @@ -14647,26 +14652,7 @@ when a \"nil\" value can supersede a non-nil value higher up the hierarchy." ;; We need a special property. Use `org-entry-properties' to ;; retrieve it, but specify the wanted property (cdr (assoc property (org-entry-properties nil 'special property))) - (let* ((range (org-get-property-block)) - (props (list (or (assoc property org-file-properties) - (assoc property org-global-properties) - (assoc property org-global-properties-fixed - (ap (lambda (key) -(when (re-search-forward - (org-re-property key) (cdr range) t) - (setq props -(org-update-property-plist - key - (if (match-end 1) - (org-
[O] [PATCH 2/2] Updates to test cases
* property-inheritance.org: Updated test cases to include expected outcomes. Adjusted the numeric values to be in order. Removed irrelevant addition tests. --- testing/examples/property-inheritance.org | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/testing/examples/property-inheritance.org b/testing/examples/property-inheritance.org index 477e25f..f2c68e2 100644 --- a/testing/examples/property-inheritance.org +++ b/testing/examples/property-inheritance.org @@ -35,17 +35,19 @@ #+end_src * hierarchy test :PROPERTIES: -:var+: boo=2 +:var+: boo=2.5 :END: ** appending to a parent property :PROPERTIES: :var+: baz=3 :END: +The result should be 8.5 #+begin_src emacs-lisp (+ foo bar boo baz) #+end_src +The result should be "foo=1 bar=2 boo=2.5 baz=3" #+begin_src emacs-lisp (org-entry-get (point) "var" t) #+end_src @@ -53,21 +55,15 @@ :PROPERTIES: :var+: nil :END: -#+begin_src emacs-lisp - (+ foo bar baz) -#+end_src - +The result should be "nil" #+begin_src emacs-lisp (org-entry-get (point) "var" t t) #+end_src *** setting a new property value :PROPERTIES: -:var+: bat=5 +:var+: bat=4 :END: -#+begin_src emacs-lisp - (+ foo bar baz) -#+end_src - +The result should be "bat=4" #+begin_src emacs-lisp (org-entry-get (point) "var" t) #+end_src -- 1.7.10.2 (Apple Git-33)
[O] Bug: Table export to [tc]sv doesn't convert \vert [7.8.11]
Converting \vert and \vert{} when exporting an Org table to csv or tsv does not
properly convert them to the vertical bar. Instead, they are retained literally.
Emacs : GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu) of 2012-11-20 on Nathan-GNU
Package: Org-mode version 7.8.11
