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.
Running a command that would use the tag scanner could suffer a large
slow-down when many entries match, because the tag list with
inheritance forces each matching entry to walk the hierarchy.
Now, it is possible to avoid this penalty by using the variable
`org-scanner-tags', or by binding the `org-trust-scanner-tags' to t
around calls to `org-get-tags-at' and `org-entry-properties' when
retrieving tags and properties for the current entry in the
scanner/mapper.
An agenda item carries a full list of tags. The list must normally be
made, but not during a tags scan. So now the tags scan does pass on
its list instead, which should make things faster.
Jeff Mickey writes:
> Hey all,
>
> To reproduce:
>
> * TODO Make Bicycle :project:workshop:
> ** TODO Buy stuff
> ** TODO Build stuff
> ** TODO Test stuff
>
> (setq org-use-tag-inheritance t)
> (setq org-tags-exclude-from-inheritance '("project"))
>
> <C-a m> to type in a match string to search, I type in "project"
>
> I expected to see:
> TODO Make Bicycle
>
> I saw:
> TODO Make Bicycle
> .TODO Buy stuff
> .TODO Build stuff
> .TODO Test stuff
>
> I assume this isn't what is supposed to happen. I'm currently at work
> so I can't investigate and provide a diff, but it seems like there
> needs to be a check in org.el:10144:org-get-tags-at to remove tags
> that are explicitly excluded from inheritance.
This commit fixes the bug.
Carsten Dominik
Bastien Guerry