Daniel Hochheimer writes:
> It seems there is a bug in the handling of simple dependencies.
> I think an example tree is the best solution, to show you the bug:
>
> * Projects
> #+CATEGORY: Projects
> *** TODO foo bar project
> :PROPERTIES:
> :ORDERED: t
> :END:
> ***** TODO foo subproject :FooSubproject:
> ******* TODO Task 1
> ***** TODO bar subproject :BarSubproject:
> ******* TODO Task 1
>
> This is in my .emacs file:
> (setq org-enforce-todo-dependencies t)
> (setq org-agenda-dim-blocked-tasks 'invisible)
> (setq org-odd-levels-only t)
>
> the expected global todo agenda view imho is:
>
> Projects: Task 1 :FooSubproject:
>
> but actual it is unfortunately:
>
> Projects: Task 1 :FooSubproject:
> Projects: Task 1 :BarSubproject:
>
>
> Imho "Task 1" from "bar subproject" should not be visible,
> because "bar subproject " is blocked because of the
> ORDERED property (therefore it's childs should be blocked, too)
>
>
> Is it easy / possible to fix this bug? My whole GTD system is
> heavily based on such project / subproject-Constructs. But with
> this bug my global todo agenda view is unfortunately "polluted"
> a little bit with tasks from projects that shouldn't be active.
After some back and forth, Daniel convinced me, and this is now done
correctly.
With the setting
(setq org-refile-use-outline-path 'file)
the file names ended up twice, like
"xxx.org/level 1/level 2 (xxx.org)"
Now the second occurrence is omitted.
Rustom Mody writes:
> The last two lines of my org file are
>
> *** Vishnu Sahasranam
> *** Ram Navami
>
> without a newline at the end
>
> Trying to reorder these two lines I do a M-S-down on second last
> line I get
>
> *** Ram Navami*** Vishnu Sahasranam
This module implements inline tasks in Org-mode. Inline tasks are
tasks that have all the properties of normal outline nodes, including
the ability to store meta data like scheduling dates, TODO state, tags
and properties. However, these nodes are treated specially by the
visibility cycling and export commands.
RefTeX can now be used to create a citation in Org-mode buffers.
Setup the buffer with #+BIBLIOGRAPHY: bibbase style
and create citations with `C-c C-x ['.
Chris Leyon writes:
> For some semi-short time, org-ido-switchb has been broken, complaining
> about wrong type arguments. The attached one-line patch corrects
> this.
Patch by Chris fixes this problem.
Harri Kiiskinen writes:
> It seems that org-use-tag-inheritance set to regexp, the use of
> #+FILETAGS: and org-todo-list do not work together. It seems, that a
> regexp in org-use-tag-inheritance matching a tag set in #+FILETAGS
> causes this error:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> string-match("^ +" nil)
> [...]
> when org-use-tag-inheritance is set to regexp "te"
> with this file:
>
> --------
> #+STARTUP:
> #+FILETAGS: tea
> * TODO testing :test:
> ** TODO too :data:
> -----
>
> When the regexp is "tes", so that the FILETAG does not match,
> org-todo-list produces a correct list.
This is indeed a bug. The all to `org-get-tags-at' does change the
match data if there is a match for the inheritance regexp. This
problem is now avoided by first extracting (match-string 1), and then
getting the tags.
Studying this bug also exposed another one, namely that file tags are
not marked as inherited tags. This is now fixed, immediately when
the #+FILETAGS line is parsed.
Items are listed in the agenda sometimes in bright colors, to draw
attention to important tasks or deadlines. When such an item is
switched to DONE, the state change is reflected by the new TODO
keyword, but the line itself might still be bright. Org de-emphasizes
the line by changing the face of the line. It used to change it to
the face `org-done', but now we use a new, independent face
`org-agenda-done'.
When a tags/property match does match an entry and its sublevels, the
sublevels used to be indented by dots, to indicate that the matches
likely result from tag inheritance. This is now no longer the
default, but you can get it back with
(setq org-tags-match-list-sublevels 'indented)
This commit implements an important change: When, during a
stuck-project search, a project tree is identified as not stuck, so
far the search would continue after the end of the project tree. From
now on, the search continues in the subtree, so that stuck subprojects
can still be identified.
When a note is taken, the new drawer is created before the note is
taken. Now the drawer is removed again if the note gets aborted and
if the drawer is empty.
Anupam Sengupta writes:
> I routinely use time ranges (and occasionally time-stamp ranges)
> in my org files to document the scheduled block of time for a
> meeting or activity. As an example, I will mark meetings as:
>
> * A Meeting
> <2009-03-12 Thu 10:00-11:00>
>
> As often happens with meetings, rescheduling needs to be done and
> I use S-<up> or S-<down> on the time-stamp to make the
> modifications. While this works fine, it usually leads to a
> duplication when the *time* part of the time-stamp needs to be
> changed.
>
> For the same example above, if the time-block has now changed to
> 11:00-12:00, then I need to do S-<up> on both the "10:00" and the
> "11:00" string. I.e,
>
>
> * A Meeting
> <2009-03-12 Thu 11:00-11:00>
> ^
> +---------------- After the first S-<up>
>
> * A Meeting
> <2009-03-12 Thu 11:00-12:00>
> ^
> +---------------- After the second S-<up>
>
> Can we have a feature (with a toggle option perhaps) which would
> *move* the block (i.e., both time entries) by the same amount
> when either one is moved in the same direction. I.e., the
> proposal is to have:
>
> * A Meeting
> <2009-03-12 Thu 11:00-12:00>
> ^ ^
> | |
> | +---------- Automatically shifted
> +---------------- After the S-<up>
This is in fact how changing time works in many applications, and
it does make sense here as well. The commits implements this
change.
It also implements a way to change the start time of an entry from
the agenda. The date is normally changed with S-right/left.
Now, if you add a C-u prefix, the hour will be changed. If you
immediately press S-right/left again, hours will continue to be
changed.
A double prefix will do the same for minutes.
Wanrong Lin writes:
> Suppose I have an org file with following lines:
>
> * Test1
> Test2
>
> Now if I put the cursor at the beginning of the "Test2" line and
> press "M-S-RET" (Alt-Shift-Return on my machine), I got this:
>
> * Test1
> * Test2TODO
>
> The "TODO" keyword was inserted at the end instead of the
> beginning of the task text. This seems a bug to me.
Yes, this is a bug that occurs in the special case when the
heading stars are inserted in front of an existing line. The
commit adds code to make sure the correct position is used.
Carsten Dominik
Bastien Guerry