Re: [O] Orgmode 8.0.2: Possible bug in `org-insert-heading` when invoked at end of a heading with a property
All, Finally found the cause of the issue I had reported a few weeks back: Anupam Looks like M-RET (`org-insert-heading`), and it's equivalent Anupam M-S-RET (`org-insert-todo-heading`) are behaving a little Anupam erratically when invoked from the _end_ of a heading that Anupam has a property drawer. [...] Anupam behavior when M-RET is invoked from the _end_ of the line Anupam is: Anupam *** A Heading with a Drawer Anupam :PROPERTIES: Anupam :CATEGORY: TEST Anupam :END: Anupam *** - The second item's outline Anupam ^^^ Note that the second item's outline got indented, Anupam and has leading spaces (indented?) Basically, the issue is that there is a bad interplay with the `electric-indent-mode`, which is causing the additional indentation to be added during the invocation of `org-insert-heading`. Apologies for the noise, and hopefully this helps someone. It might be useful to add this minor mode in the list of conflicts in the manual also. Regards, -- Anupam
[O] Orgmode 8.0.2: Possible bug in `org-insert-heading` when invoked at end of a heading with a property
Hello fellow Orgmode users, Have installed orgmode 8.0.2 last night, and loving it so far. Facing one issue (or change in behavior) though. This is on Emacs 24.3. Looks like M-RET (`org-insert-heading`), and it's equivalent M-S-RET (`org-insert-todo-heading`) are behaving a little erratically when invoked from the _end_ of a heading that has a property drawer. An example will perhaps help: With a heading _without_ any property drawer, such as: *** A Heading ^ ^ Beginning End If I invoke M-S-RET at the beginning or end of the heading, then I get the expected behavior, where I get a new item created as: *** - This is created if invoked from the _beginning_ of the line *** A Heading- The original heading *** - And this is created if invoked from the _end_ of the line However, if there is a _drawer_ on the heading, then the behavior when M-RET is invoked from the _end_ of the line is: *** A Heading with a Drawer :PROPERTIES: :CATEGORY: TEST :END: *** - The second item's outline ^^^ Note that the second item's outline got indented, and has leading spaces (indented?) This is inconsistent with the behavior in earlier versions of Orgmode. Not sure if this is a bug (since there seems to be new functionality such as C-u C-u M-RET to add a new item at end of the parent's subtree in version 8.0). Thanks, -- Anupam
[O] Re: [Orgmode] [babel] Possible bug: (mis)handling tuples for :return value in Python [7.4 (release_7.4.153.ga0b8)]
Hi Scott, This issue has come up a couple of times recently. I just pushed up a fix. Please let me know if you run into any further issues. Thanks -- Eric Eric, It works now. Thanks! Cheers, Scott ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [babel] Possible bug: (mis)handling tuples for :return value in Python [7.4 (release_7.4.153.ga0b8)]
Scott May bscott...@yahoo.com writes: I do not think that =org-babel-read= is correctly handling Python tuples that are returned from source blocks. If I execute the following source block: #+begin_src python :results value return (1,2) #+end_src I get the following error message: : Symbol's function definition is void: 1\, The Python output for this source block is =(1,2)=, which =org-babel-read= interprets as lisp and tries to eval. I can work around the problem using either a Python list: #+begin_src python :results value return [1,2] #+end_src or by using =:results output= #+begin_src python :results output :session (1,2) #+end_src Regards, Scott Hi Scott, This issue has come up a couple of times recently. I just pushed up a fix. Please let me know if you run into any further issues. Thanks -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [babel] Possible bug: (mis)handling tuples for :return value in Python [7.4 (release_7.4.153.ga0b8)]
I do not think that =org-babel-read= is correctly handling Python tuples that are returned from source blocks. If I execute the following source block: #+begin_src python :results value return (1,2) #+end_src I get the following error message: : Symbol's function definition is void: 1\, The Python output for this source block is =(1,2)=, which =org-babel-read= interprets as lisp and tries to eval. I can work around the problem using either a Python list: #+begin_src python :results value return [1,2] #+end_src or by using =:results output= #+begin_src python :results output :session (1,2) #+end_src Regards, Scott Emacs : GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.21.6) of 2010-09-01 on rhenium, modified by Debian Package: Org-mode version 7.4 (release_7.4.529.gb23d) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [bug?] Possible bug with shifted cursor keys
Hi, I just noticed that S-left and S-right do not select anywhere in the buffer in org-mode, even when org-support-shift-select is set to 'always. Can anyone confirm this behavior? I am running this morning's org-mode git pull version 7.4 (release_7.4.174.g163cd.dirty) on today's Emacs nightly GNU Emacs 24.0.50.1 (i686-apple-darwin10.0.0, NS apple-appkit-949.54) of 2011-01-14 on ring Thanks, -Anthony ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Accepted] [Orgmode] Bug: possible bug in latex export [7.01trans (release_6.36.735.g15ca.dirty)]
Patch 175 (http://patchwork.newartisans.com/patch/175/) is now Accepted.
Maintainer comment: No comment
This relates to the following submission:
http://mid.gmane.org/%3C22496.1280243082%40maps%3E
Here is the original message containing the patch:
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Orgmode] Bug: possible bug in latex export [7.01trans
(release_6.36.735.g15ca.dirty)]
Date: Tue, 27 Jul 2010 20:04:42 -
From: Stephen Eglen s.j.eg...@damtp.cam.ac.uk
X-Patchwork-Id: 175
Message-Id: 22496.1280243...@maps
To: David Maus dm...@ictsoc.de
Cc: emacs-orgmode@gnu.org, Stephen Eglen s.j.eg...@damtp.cam.ac.uk
FYI: This is a know limitation of the LaTeX exporter[1] and the
current state of this issue (dealing with skipped levels) is that
patches for the problem are welcome. I agree that even if
skipped-level-headlines are not allowed, they shouldn't be silently
droped neither.
Best,
-- David
[1] http://thread.gmane.org/gmane.emacs.orgmode/26413
I think I have a patch for this, see below. I've tested it briefly to
see that it works with both oddeven and odd level headings, but I would
appreciate other people taking a closer look/checking that it doesn't
break other things. I think I found the problem, in that if you have a
structure like
* A
*** B
(i.e. a level one and a level 3)
after it has found the level 1 content, it expects to find a level 2
subtree, whereas in fact there could be a level 2+ tree. See the
comment in the code for the change I made.
Stephen
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 24dd8c1..8530723 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -937,13 +937,28 @@ Return a list reflecting the document structure.
(defun org-export-latex-parse-subcontent (level odd)
Extract the subcontent of a section at LEVEL.
If ODD Is non-nil, assume subcontent only contains odd sections.
- (if (not (org-re-search-forward-unprotected
- (concat ^\\(\\(?:\\*\\)\\{
- (number-to-string (+ (if odd 4 2) level))
- \\}\\) \\(.*\\)$)
- nil t))
- nil ; subcontent is nil
-(org-export-latex-parse-global (+ (if odd 2 1) level) odd)))
+
+ (let (nstars new-level)
+;; In the search, we should not assume there will be exactly
+;; LEVEL+1 stars in the next heading, as there may be more than
+;; that number of stars. hence the regexp should be \\*{N,}
+;; rather than just \\*{N} (i.e. no upper bound, but N is minimum
+;; number of stars to expect.)
+;; We then have to check how many stars were found, rather than
+;; assuming there were exactly N.
+(when (org-re-search-forward-unprotected
+(concat ^\\(\\(?:\\*\\)\\{
+(number-to-string (+ (if odd 4 2) level))
+,\\}\\) \\(.*\\)$)
+nil t)
+ (setq nstars (1- (- (match-end 1) (match-beginning 1
+ (setq new-level (if odd
+ (/ (+ 3 nstars) 2);; not entirely sure why +3!
+ nstars)))
+(if nstars
+ (org-export-latex-parse-global new-level odd)
+ nil) ; subcontent is nil
+ ))
;;; Rendering functions:
(defun org-export-latex-global (content)
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Bug: possible bug in latex export [7.01trans (release_6.36.735.g15ca.dirty)]
Thanks David, and apologies for not checking the archives. I'll put bugfixing it my todo list! Stephen ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Bug: possible bug in latex export [7.01trans (release_6.36.735.g15ca.dirty)]
Stephen Eglen wrote: Neither the heading or text of section 'B' appears due to the incorrect level of B (three stars rather than two). If I correct the level for B, the heading and text appears. I found this today when working on a document. It is my fault for getting the level of heading B wrong, but is it possible to keep the text in the pdf, or put a heading like '2.0.1 B'? FYI: This is a know limitation of the LaTeX exporter[1] and the current state of this issue (dealing with skipped levels) is that patches for the problem are welcome. I agree that even if skipped-level-headlines are not allowed, they shouldn't be silently droped neither. Best, -- David [1] http://thread.gmane.org/gmane.emacs.orgmode/26413 -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpCHylmbOkDl.pgp Description: PGP signature ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible Bug in org-refile [6.36trans (release_6.36.654.g2cd3)]
No bug here. If I SAVE the buffer to a file, everything works great. I had something wrong with the value of org-refile-targets in my full set up that triggered all this. I think I can make it right. Carry on... Scot ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug in ordered tasks
On Jun 25, 2010, at 8:55 PM, Bernt Hansen wrote: Carsten Dominik carsten.domi...@gmail.com writes: On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote: Question: what is the proper way to get a NIL into a property? Are we to use () instead of nil? Or are property values always interpreted as strings? Apologies in advance if this is a stupid question! Not a stupid question at all. There is no way, currently. Property values are string - the only way to make org-entry-get return nil is to not have the property defined at all. I've wanted a similar thing in the past for the LOGGING property where the parent task has special logging set via the LOGGING property but I want to undo that for some of the child tasks so they use the default logging setup. Having a way to undefine a property would be good in general I think. This does now work, the property value nil will now be interpreted as explicit undefine of a property. - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Solved] [Orgmode] [Patch] possible Bug: non-interactive publishing (emacs 22.1)
Quoting Sebastian Rose sebastian_r...@gmx.de: Sorry for the reply to my own mail. But as Carsten is on vacation, I thought it might make sense to add the `[Patch]' to the subject. This patch fixes batch-mode publishing. Tested in emacs24 like this: sh$ emacs -q -batch --eval='(org-publish PROJECT_NAME t)' Hi Sebastian, thanks, the patch works great (emacs 22)!!! That was fast. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [Patch] possible Bug: non-interactive publishing (emacs 22.1)
Sorry for the reply to my own mail. But as Carsten is on vacation, I thought it might make sense to add the `[Patch]' to the subject. This patch fixes batch-mode publishing. Tested in emacs24 like this: sh$ emacs -q -batch --eval='(org-publish PROJECT_NAME t)' diff --git a/lisp/org-publish.el b/lisp/org-publish.el index fc18a9a..3f24863 100644 --- a/lisp/org-publish.el +++ b/lisp/org-publish.el @@ -756,7 +756,12 @@ Default for SITEMAP-FILENAME is 'sitemap.org'. (save-window-excursion (let* ((org-publish-use-timestamps-flag (if force nil org-publish-use-timestamps-flag))) - (org-publish-projects (list project) + (org-publish-projects + (if (stringp project) + ;; If this function is called in batch mode, + ;; project is still a string here. + (list (assoc project org-publish-project-alist)) + (list project)) ;;;###autoload (defun org-publish-all (optional force) Regards Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [babel] possible bug in org-babel-execute-buffer?
Hello, I am using Emacs 23.1, orgmode pulled from git just an hour ago, but I noticed the following issue on a version pulled about a week ago, too. I don't know if it ever worked as I expect. These development versions have C-c C-v as the babel prefix keys, so if you are using a stable version, the following may be different. Also, all my examples use R. I'm trying to use C-c C-v C-b to call org-babel-execute-buffer, which is documented as: Call `org-babel-execute-src-block' on every source block in the current buffer. However, what happens when this is called seems to depend on which trees are visible in the buffer when it's called! Paste the following orgmode file into an org buffer, and make sure all trees are fully collapsed, i.e., you just see the headlines Big Block 1 and Big Block 2, and try C-c C-v C-b. After it's done executing, notice that only the *last* source blocks of each tree were run. Now collapse everything again, and call org-babel-execute-buffer again. The same thing happens, except now there are *two* results present for those last code blocks. Now start all over again with the below code, so no results are present. Expand all subtrees so everything is visible. Do C-c C-v C-b, and all results are inserted as expected. Run the blocks a second time with everything open, and every block still only has 1 results section, as expected. This is how I would expect/hope the function to work regardless of the hide/show states of the trees. So I think there are two possibly related problems when trees aren't fully expanded: 1) Only the last source code block per hidden tree is getting run 2) That last block will insert results multiple times if org-babel-execute-buffer is called multiple times Thanks! Erik === orgmode code follows below == * Big Block 1 ** my first bit of code! #+begin_src R from the first nested code block in Big Block 1 #+end_src ** and some more code! #+begin_src R from the middle nested code block in Big Block 1 #+end_src ** and final code! #+begin_src R from the final nested code block in Big Block 1 #+end_src * Big Block 2 #+begin_src R from the only code block in Big Block 2 #+end_src ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [babel] possible bug in org-babel-execute-buffer?
Hi Erik, Thanks for the report, this should now be fixed in the latest git HEAD, please let me know if the problem persists. Best -- Eric Erik Iverson er...@ccbr.umn.edu writes: Hello, I am using Emacs 23.1, orgmode pulled from git just an hour ago, but I noticed the following issue on a version pulled about a week ago, too. I don't know if it ever worked as I expect. These development versions have C-c C-v as the babel prefix keys, so if you are using a stable version, the following may be different. Also, all my examples use R. I'm trying to use C-c C-v C-b to call org-babel-execute-buffer, which is documented as: Call `org-babel-execute-src-block' on every source block in the current buffer. However, what happens when this is called seems to depend on which trees are visible in the buffer when it's called! Paste the following orgmode file into an org buffer, and make sure all trees are fully collapsed, i.e., you just see the headlines Big Block 1 and Big Block 2, and try C-c C-v C-b. After it's done executing, notice that only the *last* source blocks of each tree were run. Now collapse everything again, and call org-babel-execute-buffer again. The same thing happens, except now there are *two* results present for those last code blocks. Now start all over again with the below code, so no results are present. Expand all subtrees so everything is visible. Do C-c C-v C-b, and all results are inserted as expected. Run the blocks a second time with everything open, and every block still only has 1 results section, as expected. This is how I would expect/hope the function to work regardless of the hide/show states of the trees. So I think there are two possibly related problems when trees aren't fully expanded: 1) Only the last source code block per hidden tree is getting run 2) That last block will insert results multiple times if org-babel-execute-buffer is called multiple times Thanks! Erik === orgmode code follows below == * Big Block 1 ** my first bit of code! #+begin_src R from the first nested code block in Big Block 1 #+end_src ** and some more code! #+begin_src R from the middle nested code block in Big Block 1 #+end_src ** and final code! #+begin_src R from the final nested code block in Big Block 1 #+end_src * Big Block 2 #+begin_src R from the only code block in Big Block 2 #+end_src ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [babel] possible bug in org-babel-execute-buffer?
Eric Schulte wrote: Hi Erik, Thanks for the report, this should now be fixed in the latest git HEAD, please let me know if the problem persists. Best -- Eric Looks good on the test file I had included in my initial report, thank you very much. When I get back to work tomorrow, I will try it on the actual file that was giving me trouble. Thank you, Eric. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug in TODO ALL agenda fast tag filter generation?
The problem is that org-todo-keywords-1 is set for each agenda file parsed, and that list is appended onto the org-todo-keywords-for-agenda without any de-duplication. The patch below fixes the problem, but possibly not in the best way. regards, Tim. diff --git a/lisp/org.el b/lisp/org.el index d80bb91..6a663b3 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14960,6 +14960,8 @@ When a buffer is unmodified, it is just killed. When modified, it is saved (add-text-properties (match-beginning 0) (org-end-of-subtree t) pc))) (set-buffer-modified-p bmp) +(setq org-todo-keywords-for-agenda + (org-uniquify org-todo-keywords-for-agenda)) (setq org-todo-keyword-alist-for-agenda (org-uniquify org-todo-keyword-alist-for-agenda) org-tag-alist-for-agenda (org-uniquify org-tag-alist-for-agenda On 7 April 2010 11:47, Tim O'Callaghan tim.ocallag...@gmail.com wrote: Any idea why this is happening? I'm seeing it with the agenda t (global todo all) --- Global list of TODO items of type: ALL Available with `N r': (0)ALL (1)TODO (2)NEXT (3)WAITING (4)APPT (5)DONE (6)DEFERRED (7)CANCELLED (8)PROJECT (9)SOMEDAY (10)PROJDONE (11)PROJCANC (12)TODO (13)NEXT (14)WAITING (15)APPT (16)DONE (17)DEFERRED (18)CANCELLED (19)PROJECT (20)SOMEDAY (21)PROJDONE (22)PROJCANC (23)TODO (24)NEXT (25)WAITING (26)APPT (27)DONE (28)DEFERRED (29)CANCELLED (30)PROJECT (31)SOMEDAY (32)PROJDONE (33)PROJCANC (34)TODO (35)NEXT (36)WAITING (37)APPT (38)DONE (39)DEFERRED (40)CANCELLED (41)PROJECT (42)SOMEDAY (43)PROJDONE (44)PROJCANC (45)TODO (46)NEXT (47)WAITING (48)APPT (49)DONE (50)DEFERRED (51)CANCELLED (52)PROJECT (53)SOMEDAY (54)PROJDONE (55)PROJCANC (56)TODO (57)NEXT (58)WAITING (59)APPT (60)DONE (61)DEFERRED (62)CANCELLED (63)PROJECT (64)SOMEDAY (65)PROJDONE (66)PROJCANC (67)TODO (68)NEXT (69)WAITING (70)APPT (71)DONE (72)DEFERRED (73)CANCELLED (74)PROJECT (75)SOMEDAY (76)PROJDONE (77)PROJCANC (78)TODO (79)NEXT (80)WAITING (81)APPT (82)DONE (83)DEFERRED (84)CANCELLED (85)PROJECT (86)SOMEDAY (87)PROJDONE (88)PROJCANC (89)TODO (90)NEXT (91)WAITING (92)APPT (93)DONE (94)DEFERRED (95)CANCELLED (96)PROJECT (97)SOMEDAY (98)PROJDONE (99)PROJCANC --- My todo-keywords config is this: (setq org-todo-keywords (quote ((sequence TODO(1!) NEXT(2!/!) WAITING(3@/!) APPT(4@/!) | DONE(0!/@!) DEFERRED(d...@!/!) CANCELLED(c...@!/!)) (type PROJECT(P!/@!) SOMEDAY(S!/@!) | PROJDONE PROJCANC) )) org-todo-keyword-faces (quote ( (TODO :foreground orangered :weight bold) (NEXT :foreground gold :weight bold) (DONE :foreground forest green :weight bold) (WAITING :foreground orange :weight bold) (CANCELLED :foreground indianred :weight bold) ;; project level todo indicators (SOMEDAY :foreground orchid :weight bold) (PROJECT :foreground grey :weight bold) (PROJDONE :foreground forest green :weight bold) (PROJCANC :foreground indianred :weight bold) ))) Using git emacs 23 org git source (both as of this morning) Tim. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Possible bug in TODO ALL agenda fast tag filter generation?
Applied, thanks. - Carsten On Apr 7, 2010, at 12:20 PM, Tim O'Callaghan wrote: The problem is that org-todo-keywords-1 is set for each agenda file parsed, and that list is appended onto the org-todo-keywords-for-agenda without any de-duplication. The patch below fixes the problem, but possibly not in the best way. regards, Tim. diff --git a/lisp/org.el b/lisp/org.el index d80bb91..6a663b3 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14960,6 +14960,8 @@ When a buffer is unmodified, it is just killed. When modified, it is saved (add-text-properties (match-beginning 0) (org-end-of-subtree t) pc))) (set-buffer-modified-p bmp) +(setq org-todo-keywords-for-agenda + (org-uniquify org-todo-keywords-for-agenda)) (setq org-todo-keyword-alist-for-agenda (org-uniquify org-todo-keyword-alist-for-agenda) org-tag-alist-for-agenda (org-uniquify org-tag-alist-for- agenda On 7 April 2010 11:47, Tim O'Callaghan tim.ocallag...@gmail.com wrote: Any idea why this is happening? I'm seeing it with the agenda t (global todo all) --- Global list of TODO items of type: ALL Available with `N r': (0)ALL (1)TODO (2)NEXT (3)WAITING (4)APPT (5)DONE (6)DEFERRED (7)CANCELLED (8)PROJECT (9)SOMEDAY (10)PROJDONE (11)PROJCANC (12)TODO (13)NEXT (14)WAITING (15)APPT (16)DONE (17)DEFERRED (18)CANCELLED (19)PROJECT (20)SOMEDAY (21)PROJDONE (22)PROJCANC (23)TODO (24)NEXT (25)WAITING (26)APPT (27)DONE (28)DEFERRED (29)CANCELLED (30)PROJECT (31)SOMEDAY (32)PROJDONE (33)PROJCANC (34)TODO (35)NEXT (36)WAITING (37)APPT (38)DONE (39)DEFERRED (40)CANCELLED (41)PROJECT (42)SOMEDAY (43)PROJDONE (44)PROJCANC (45)TODO (46)NEXT (47)WAITING (48)APPT (49)DONE (50)DEFERRED (51)CANCELLED (52)PROJECT (53)SOMEDAY (54)PROJDONE (55)PROJCANC (56)TODO (57)NEXT (58)WAITING (59)APPT (60)DONE (61)DEFERRED (62)CANCELLED (63)PROJECT (64)SOMEDAY (65)PROJDONE (66)PROJCANC (67)TODO (68)NEXT (69)WAITING (70)APPT (71)DONE (72)DEFERRED (73)CANCELLED (74)PROJECT (75)SOMEDAY (76)PROJDONE (77)PROJCANC (78)TODO (79)NEXT (80)WAITING (81)APPT (82)DONE (83)DEFERRED (84)CANCELLED (85)PROJECT (86)SOMEDAY (87)PROJDONE (88)PROJCANC (89)TODO (90)NEXT (91)WAITING (92)APPT (93)DONE (94)DEFERRED (95)CANCELLED (96)PROJECT (97)SOMEDAY (98)PROJDONE (99)PROJCANC --- My todo-keywords config is this: (setq org-todo-keywords (quote ((sequence TODO(1!) NEXT(2!/!) WAITING(3@/!) APPT(4@/!) | DONE(0!/@!) DEFERRED(d...@!/!) CANCELLED(c...@!/!)) (type PROJECT(P!/@!) SOMEDAY(S!/@!) | PROJDONE PROJCANC) )) org-todo-keyword-faces (quote ( (TODO :foreground orangered :weight bold) (NEXT :foreground gold :weight bold) (DONE :foreground forest green :weight bold) (WAITING :foreground orange :weight bold) (CANCELLED :foreground indianred :weight bold) ;; project level todo indicators (SOMEDAY :foreground orchid :weight bold) (PROJECT :foreground grey :weight bold) (PROJDONE :foreground forest green :weight bold) (PROJCANC :foreground indianred :weight bold) ))) Using git emacs 23 org git source (both as of this morning) Tim. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
Not sure whether I'm talking about the same phenomenon, but I have started almost routinely adding a tag at the end of every headline inserted by my remember templates. Without the tag, it'seems it's hard to move past the end of the line cleanly to edit the contents. With a tag, using the custom \C-a/e behavior alluded to above, its a cinch. I am annoyed by this. It seems wrong, and I assumed there is a workaround somewhere, if I looked hard enough. Again, maybe this is another problem. Alan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
Hi Alan, On Mar 28, 2010, at 1:45 PM, Alan E. Davis wrote: Not sure whether I'm talking about the same phenomenon, but I have started almost routinely adding a tag at the end of every headline inserted by my remember templates. Without the tag, it'seems it's hard to move past the end of the line cleanly to edit the contents. With a tag, using the custom \C-a/e behavior alluded to above, its a cinch. I don't think I can reproduce this. Can you please make your explanation more detailed, with an example, with your setting for org-special-control-a/e, and with a step by step guide on how to hit any problems? Thanks - Carsten I am annoyed by this. It seems wrong, and I assumed there is a workaround somewhere, if I looked hard enough. Again, maybe this is another problem. Alan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
Hello, Carsten: I have to admit you are right, at least to the extent I cannot now reproduce this behavior. I also have to admit that I haven't been aware of that behavior for a while. I will attempt to reproduce it for a day or two, and see if I can send you a working example. With apologies, Alan On Sun, Mar 28, 2010 at 9:58 PM, Carsten Dominik carsten.domi...@gmail.com wrote: Hi Alan, On Mar 28, 2010, at 1:45 PM, Alan E. Davis wrote: Not sure whether I'm talking about the same phenomenon, but I have started almost routinely adding a tag at the end of every headline inserted by my remember templates. Without the tag, it'seems it's hard to move past the end of the line cleanly to edit the contents. With a tag, using the custom \C-a/e behavior alluded to above, its a cinch. I don't think I can reproduce this. Can you please make your explanation more detailed, with an example, with your setting for org-special-control-a/e, and with a step by step guide on how to hit any problems? Thanks - Carsten I am annoyed by this. It seems wrong, and I assumed there is a workaround somewhere, if I looked hard enough. Again, maybe this is another problem. Alan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
Anthony Lander anthonylan...@yahoo.com writes: I was thinking about this a bit more. Is it possible to meet in the middle and restrict the cursor so that it can't go past the last character in the headline, like this: *** Some entry|... I suggest this because if you do type after the elipsis, the text goes right on the end of the folded entry, which I believe is undesirable as well; It means that part of the entry is invisible, and part is visible. Limiting the cursor would solve both problems. Is this even feasible? I have not been following closely this thread, but I believe customizing org-special-ctrl-a/e might bring you a long way towards the behaviour you want. I suggest you give it a try. ,[ (info (org)Headlines) ] | Documentation: | Non-nil means `C-a' and `C-e' behave specially in headlines and items. | | When t, `C-a' will bring back the cursor to the beginning of the | headline text, i.e. after the stars and after a possible TODO keyword. | In an item, this will be the position after the bullet. | When the cursor is already at that position, another `C-a' will bring | it to the beginning of the line. | | `C-e' will jump to the end of the headline, ignoring the presence of tags | in the headline. A second `C-e' will then jump to the true end of the | line, after any tags. This also means that, when this variable is | non-nil, `C-e' also will never jump beyond the end of the heading of a | folded section, i.e. not after the ellipses. ` hth memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Thanks for this, memmon. On Sat, Mar 27, 2010 at 1:02 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: Anthony Lander anthonylan...@yahoo.com writes: I was thinking about this a bit more. Is it possible to meet in the middle and restrict the cursor so that it can't go past the last character in the headline, like this: *** Some entry|... I suggest this because if you do type after the elipsis, the text goes right on the end of the folded entry, which I believe is undesirable as well; It means that part of the entry is invisible, and part is visible. Limiting the cursor would solve both problems. Is this even feasible? I have not been following closely this thread, but I believe customizing org-special-ctrl-a/e might bring you a long way towards the behaviour you want. I suggest you give it a try. ,[ (info (org)Headlines) ] | Documentation: | Non-nil means `C-a' and `C-e' behave specially in headlines and items. | | When t, `C-a' will bring back the cursor to the beginning of the | headline text, i.e. after the stars and after a possible TODO keyword. | In an item, this will be the position after the bullet. | When the cursor is already at that position, another `C-a' will bring | it to the beginning of the line. | | `C-e' will jump to the end of the headline, ignoring the presence of tags | in the headline. A second `C-e' will then jump to the true end of the | line, after any tags. This also means that, when this variable is | non-nil, `C-e' also will never jump beyond the end of the heading of a | folded section, i.e. not after the ellipses. ` hth memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
Very cool and good point about unfolding. I've basically been doing the same things. Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's so many helpful things I might never find that way! On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
John Hendy jw.he...@gmail.com writes: Very cool and good point about unfolding. I've basically been doing the same things. Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's so many helpful things I might never find that way! On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
John Hendy jw.he...@gmail.com writes: Very cool and good point about unfolding. I've basically been doing the same things. Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's so many helpful things I might never find that way! On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon Sorry about the premature post - send key malfunction :) One other thing I've done for dealing with folded text is use my binding for F9-v which toggles visibility mode on and off. This unfolds _everything_ and makes it possible to see what you are changing (usually because I accidentally edited something in a folded region and want to see exactly what I'm undoing to fix it) (global-set-key (kbd f9 v) 'visible-mode) HTH, Bernt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
Carsten Dominik carsten.domi...@gmail.com writes: On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote: If the cursor is after the elipsis on a folded entry like this: Some entry...| pressing TAB doesn't expand the entry, or in fact, do anything useful at all. Is it possible to get it to expand the entry, or am I missing something? Cursor after the dots means the cursor is no longer in the headline, in fact it is no longer in the entry at all. But neither is it in the following entry, surely? I agree with the original reporter that this goes against expectations. Pressing TAB *anywhere* on the same line of a collapsed item should expand it as normal, no? Can this be fixed? -- \ “Working out the social politics of who you can trust and why | `\ is, quite literally, what a very large part of our brain has | _o__) evolved to do.” —Douglas Adams | Ben Finney ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible Bug in Time stamp Editing
I have a remember template that inserts an inactive time stamp. If I edit the inactive time stamp in the remember buffer using C . it changes to an active timestamp. Shouldn't editing preserve the active/inactive status? C-c . creates active timestamps. You want C-c ! for inactive timestamp editing. Thanks. I'll add a section to the manual saying that if you want to edit an existing time stamp, you need to use the same key combination used to create it, or it will change from active to inactive, or vice versa. Now I think about it makes sense, as it also allows a quick way to toggle the active/inactive status of time stamps. Ian. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Possible Bug in Time stamp Editing
On Sep 12, 2009, at 7:48 PM, Ian Barton wrote: I have a remember template that inserts an inactive time stamp. If I edit the inactive time stamp in the remember buffer using C . it changes to an active timestamp. Shouldn't editing preserve the active/inactive status? C-c . creates active timestamps. You want C-c ! for inactive timestamp editing. Thanks. I'll add a section to the manual saying that if you want to edit an existing time stamp, you need to use the same key combination used to create it, or it will change from active to inactive, or vice versa. Now I think about it makes sense, as it also allows a quick way to toggle the active/inactive status of time stamps. Yes. Another way to do that is S-up with the cursor on the bracket/angle. - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
On Fri, Apr 24, 2009 at 02:12:11PM -0400, Bernt Hansen wrote: Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 09:24:10AM -0400, Bernt Hansen wrote: Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 08:45:17AM -0400, Bernt Hansen wrote: I think we need more information to help. Could you show us what your value of org-stuck-projects is? Sure. '(org-stuck-projects (quote (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) [State]: EDITED, shown value does not take effect until you set or save it.))) I think that's a little messed up. Can you post what C-h v org-stuck-projects displays (or cut and paste the value out of your custom file? The [State]: EDITED, ... stuff shouldn't be part of the value. That's cut straight from my .emacs. The first few lines of C-h v tell me: org-stuck-projects is a variable defined in `org-agenda.el'. Its value is (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) \n [State]: EDITED, shown value does not take effect until you set or save it.) Okay. That string is used for regexp matching and probably should not be there. True! But there it is... - If this regexp - \n [State]: ...it. matches anywhere in the subtree then the project is not stuck. That's probably not what you want even if matching that exactly string is unlikely. If you click on the _customize_ link you'll see what each value is used for. You probably just want an empty string there. Yes, I got that. I've adjusted the string manually. Carsten mentioned that inherited tags are not considers for stuck project matching during the search and you should probably try his suggestion to see if it works better for your scenario. I haven't had a chance to play around with this yet. As I said in my original mail, though, it's probably more correct to use PROPERTIES to mark something as information. org-stuck-projects seems to be able to read PROPERTIES, so I'll fiddle around with that and see how I go. Thanks for your help, -- Cameron Horsburgh Blog: http://spiritcry.wordpress.com/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 03:54:29PM +0200, Carsten Dominik wrote: The tags in org-stuck-projects must be present explicitly in the subtree, because the subtree is searched with a regula expression that does not know about inheritance. I thought this might be the case. May I suggest a note be made to the documentation of org-stuck-projects? Carsten did that yesterday fin commit f4f1d5c (Stuck projects: Improve docstring of org-stuck-projects) -Bernt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
Cameron Horsburgh ca...@netcall.com.au writes: Today I stumbled across an instance where tag inheritance doesn't seem to work as I expected it to. I'm using GNU Emacs 23.0.92.1 (i486-pc-linux-gnu, GTK+ Version 2.14.7) of 2009-04-12 on elegiac, modified by Debian, and Org-mode version 6.26trans. Let's say I have an org file that records all the information for a particular part of my life. Different parts of the file record meetings, track projects and record notes and other information. Here's what it might look like: * Meetings ** Lunch with John :Restaurant: 2009-04-27 Mon 12:30 ** Meeting with Fred :Office: 2009-04-27 Mon 13:00 * Projects ** Find Higgs Boson:Laboratory: DEADLINE: 2009-04-27 Mon ** Achieve World domination :Office:Laboratory: SCHEDULED: 2009-04-28 Tue ** Cook dinner :Kitchen: * Notes :Info: ** Mary's phone numbers - 1234-5678 - 0412-345-678 ** Jenny's web page - [[http://www.somewebpage.com][Jenny's web page]] I have customised org-stuck-projects[fn:1] to ignore entries tagged with the tag `Info'. org-use-tag-inheritance is set to `t'. If I hit C-a # to list stuck projects I would only expect to see the entry about cooking dinner listed. The `Notes' headline should be ignored, as should the notes about Mary's phone number and Jenny's web page, because they inherit the `Info' tag. In practice, the `Notes' headline is ignored as expected. However, the children are listed as stuck projects. After all this I have realised it's probably more appropriate to use properties rather than tags to do this sort of thing. Still, the behaviour puzzles me a bit, so I thought it was worth asking about. Is this behaviour incorrect? Or am I expecting the wrong thing? * Footnotes [fn:1] I had some trouble customising this variable in the usual way, because the explanation at the end of the customize buffer somehow got included in the sexp recorded in my .emacs. I deleted that line, reset the customize buffer and started again, but with exactly the same result. Hi Cameron, I think we need more information to help. Could you show us what your value of org-stuck-projects is? -Bernt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
On Fri, Apr 24, 2009 at 08:45:17AM -0400, Bernt Hansen wrote: Cameron Horsburgh ca...@netcall.com.au writes: [fn:1] I had some trouble customising this variable in the usual way, because the explanation at the end of the customize buffer somehow got included in the sexp recorded in my .emacs. I deleted that line, reset the customize buffer and started again, but with exactly the same result. Hi Cameron, I think we need more information to help. Could you show us what your value of org-stuck-projects is? Sure. '(org-stuck-projects (quote (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) [State]: EDITED, shown value does not take effect until you set or save it.))) This is the latest version of it. An earlier attempt also listed the explanation of the way stuck projects are identified. -- Cameron Horsburgh Blog: http://spiritcry.wordpress.com/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 08:45:17AM -0400, Bernt Hansen wrote: I think we need more information to help. Could you show us what your value of org-stuck-projects is? Sure. '(org-stuck-projects (quote (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) [State]: EDITED, shown value does not take effect until you set or save it.))) I think that's a little messed up. Can you post what C-h v org-stuck-projects displays (or cut and paste the value out of your custom file? The [State]: EDITED, ... stuff shouldn't be part of the value. -Bernt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
On Fri, Apr 24, 2009 at 09:24:10AM -0400, Bernt Hansen wrote: Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 08:45:17AM -0400, Bernt Hansen wrote: I think we need more information to help. Could you show us what your value of org-stuck-projects is? Sure. '(org-stuck-projects (quote (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) [State]: EDITED, shown value does not take effect until you set or save it.))) I think that's a little messed up. Can you post what C-h v org-stuck-projects displays (or cut and paste the value out of your custom file? The [State]: EDITED, ... stuff shouldn't be part of the value. That's cut straight from my .emacs. The first few lines of C-h v tell me: org-stuck-projects is a variable defined in `org-agenda.el'. Its value is (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) \n [State]: EDITED, shown value does not take effect until you set or save it.) -Bernt -- Cameron Horsburgh Blog: http://spiritcry.wordpress.com/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug with tag inheritance
Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 09:24:10AM -0400, Bernt Hansen wrote: Cameron Horsburgh ca...@netcall.com.au writes: On Fri, Apr 24, 2009 at 08:45:17AM -0400, Bernt Hansen wrote: I think we need more information to help. Could you show us what your value of org-stuck-projects is? Sure. '(org-stuck-projects (quote (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) [State]: EDITED, shown value does not take effect until you set or save it.))) I think that's a little messed up. Can you post what C-h v org-stuck-projects displays (or cut and paste the value out of your custom file? The [State]: EDITED, ... stuff shouldn't be part of the value. That's cut straight from my .emacs. The first few lines of C-h v tell me: org-stuck-projects is a variable defined in `org-agenda.el'. Its value is (+LEVEL=2/-DONE (TODO NEXT NEXTACTION) (Info) \n [State]: EDITED, shown value does not take effect until you set or save it.) Okay. That string is used for regexp matching and probably should not be there. - If this regexp - \n [State]: ...it. matches anywhere in the subtree then the project is not stuck. That's probably not what you want even if matching that exactly string is unlikely. If you click on the _customize_ link you'll see what each value is used for. You probably just want an empty string there. Carsten mentioned that inherited tags are not considers for stuck project matching during the search and you should probably try his suggestion to see if it works better for your scenario. -Bernt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug in publish
Fixed, thanks. - Carsten On Jan 6, 2009, at 4:28 AM, Richard Riley wrote: Hi Carsten See here: http://richardriley.net/default/projects/xmonad/index.html note the contents pane with foreground: wheat . The publish has treated an included src file as org file and assumed the source lines were org levels. regards r. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: update Re: [Orgmode] A possible bug?
On Nov 4, 2008, at 8:12 PM, [EMAIL PROTECTED] wrote: old task does not change. New task after update will disappear in the day view if i mark it done. Is there any way, i can make the done one show up at agenda view (with my done label.)? sorry to bother you again. Hi Jack, please lets do these discussions on emacs-orgmode@gnu.org, so that if the same question comes up again, people will be able to find any previously given answers. And please take a little more time to write your emails, so that they are clear and self-contained. In this case the answer is no. I implemented, per your request, a special exception to updating the agenda view when marking a repeating task DONE. So if you do switch the task *FROM THE AGENDA VIEW*, then in the agenda view this task will be listed as done. Any update of the agenda by pressing g or C-c a a will loose this entry because it is now a TODO entry for the next instance of the repeater. - Carsten [EMAIL PROTECTED] wrote: Hello Dominik, I just update org to org-mode- a80b84425b6127d0a4b8b28df645c102e5aadcc5.tar.gz, but nothing change mark repeat task as done for today, still show todo at agenda view, and no strikethrough for it (which i set for done task) PS, I am using windows xp. Thanks. Have a good day. Jack Carsten Dominik wrote: Hi Jack, thanks for noticing this, fixed now. - Carsten On Nov 3, 2008, at 4:12 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: For a every day repeat task, I mark it done for today. But in the agenda view, it still show up as todo for today, which would be better if it shows done keyword for today. Jack ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org mailto:Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] A possible bug?
Hi Jack, thanks for noticing this, fixed now. - Carsten On Nov 3, 2008, at 4:12 AM, [EMAIL PROTECTED] wrote: For a every day repeat task, I mark it done for today. But in the agenda view, it still show up as todo for today, which would be better if it shows done keyword for today. Jack ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] A possible bug?
For a every day repeat task, I mark it done for today. But in the agenda view, it still show up as todo for today, which would be better if it shows done keyword for today. Jack ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible Bug in Table Calculations?
Carsten Dominik [EMAIL PROTECTED] writes: Currently, Org uses cals with only 5 significant digits, this is the cause for this accuracy. You can change this per equation by including something like n8 or f8 into the mode string, like @5$1=vsum(@[EMAIL PROTECTED]);n8%.2f Ah, I totally glossed over the n8 format. Thanks. Maybe I should actually do this by default. Yes, I wil, do so. Better questions about too wide fields than inaccurate calculations. I agree, and thanks! -- Peter Jones, pmade inc. http://pmade.com ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug in version 5.08
McKelvie [EMAIL PROTECTED] writes: version 5.04 allows my to file quick notes away using remember. On upgrading to 5.08, when I try typing in my template hot key I get the error, Wrong type argument: stringp, nil. It works fine in 5.04. Sounds like a problem I was having which came down to org-remember-apply-template expecting remember's global `annotation' variable to be non-nil. I temporarily (and unartfully) fixed it with , | (defadvice org-remember-apply-template | (around ajk/fix-org-remember-apply-template activate compile) | (with-no-warnings | (if annotation | ad-do-it | (let ((annotation )) | ad-do-it ` -- Andrew J. Korty, Deputy Information Security Officer Office of the Vice President for Information Technology and CIO Indiana University ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Possible bug in Org-mode version 4.74
On May 21, 2007, at 6:51, Ruslan Kosolapov wrote: CD I have released version 4.74 of Org-mode at CD http://www.astro.uva.nl/~dominik/Tools/org/ 1. I got org-mode from http://staff.science.uva.nl/~dominik/Tools/org/org-4.74.tar.gz 2. I configure agenda export as follows: (setq org-agenda-exporter-settings '((htmlize-output-type 'inline-css))) (setq org-agenda-custom-commands '((w todo WAITING nil (agenda-waiting.html)) (n todo NEXT nil (agenda-next.html)) (f todo FREEZED nil (agenda-freezed.html)) (d Agenda + NEXT ((agenda) (todo NEXT)) (agenda+next.html)) there is `nil' missing between the list of commands and the list of files. nil stands for the list of options, you have it right in all other cases. (c agenda nil (agenda-current.html)) (I Ilnar tasks ((tags ilnar)) nil (ilnar-tasks.html)) (R rk tasks ((tags rk)) nil (rk-tasks.html)) )) 3. Now when I press C-c a e, error appears (full errmessage in attach): Debugger entered--Lisp error: (void-variable nosettings) (org-write-agenda agenda-waiting.html nosettings) Indeed a bug, will be fixed in 4.75. Additional info: 1. When I use C-x C-w in agenda buffer, I get another error (full errmessage in second attach): Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil) insert(nil 10 !-- Created by htmlize-1.30 in inline-css mode. --\n html\n head\n title *Org Agenda* /title\n ) This is another bug, thank you. You can prevent if for the time being by loading htmlize before using the org stuff. Will be fixed in 4.75 as well. Thanks a lot for the detailed report, quite complete! One more thing: I strongly advise to use absolute file names in org-agenda-custom-commands. - Carsten ___ Emacs-orgmode mailing list Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
