The category can contain a bracket link. This commit makes sure that
the prefix in the agenda looks OK if there is a link, and that the
link is accessible with `C-c C-o 0'.
Peter Westlake writes:
> This is quite obscure, and an odd corner case, but here it is.
>
> If you have an item which is:
>
> - a TODO
> - scheduled
> - ordered
> - blocked by a child TODO
>
> then it leaves an empty line in the agenda.
>
> Here's a test case:
> ,----
> | * Press t r on this line in the agenda
> | SCHEDULED: <2009-09-02 Wed>
> | :PROPERTIES:
> | :ORDERED: t
> | :END:
> | *** TODO Report invisible scheduled items
> `----
>
> C-a a a will show an agenda with "Scheduled: Press t r ...".
> Press "t" on that line to add a TODO.
> Press "r" to redisplay, and see the line go blank.
>
> Peter.
Henry Atting writes:
> If org agenda is displayed in an other frame then windows aren*t
> restored when quitting, I have to kill the frame manually. I
> really would like it to behave like e.g. gnus-other-frame which
> automatically kills his frame on quitting.
The new keys are b and f. This used to be on the cursor keys, but
they do now again do cursor motion.
This is a significant change in the UI, I hope this will not cause too
many problems.
Fix bulk refiling in the agenda due to commit
9ec5529 (Fix jumping to last refile location in agenda, 2009-08-20)
This restores the original behaviour.
This bug was caused by commit
8c177dc832, and reported by Matt
Lundin. The problem was that this commit tried to remove the text
propertes of the MATCH part of an agenda command. However, in block
commands, the MATCH part is not a string.
New variable `org-agenda-skip-scheduled-if-deadline-is-shown' to avoid
that a entry shows up in the agenda for today for both a scheduling
and a deadline entry. See the docstring of the variables for more
details.
Bernt Hansen writes:
> Every so often I run into a situation where bulk refiling
> doesn't work anymore.
>
> I currently have 15 items in my refile.org file that I want
> to refile to other locations. I marked a few of them and
> bulk refiled them just fine. Then I marked a few more and B
> r fails with "Cannot find entry for marker #<marker at
> 297156 in norang.org>"
>
> I think this happens when I mark multiple tasks in the same
> subtree (i.e. the parent and a sibling) and refile both to
> the same location. After that it gets confused.
>
> If I have a task like this in refile.org
>
> #+FILETAGS: REFILE
> * Test
> ** Test 2
>
> and run a tags match on REFILE I see both tasks. Mark both
> with m in the agenda and B r to some other location. It
> refiles the first (and this moves the sibling too) and then
> it's broken after that.
>
> I get the following backtrace
>
> Debugger entered--Lisp error: (error "Cannot find entry for
> marker #<marker at 297156 in norang.org>")
Indeed the happens because, when a parent gets refiled or
achieved, any entries corresponding to its children are
removed from the agenda.
We address this issue by
- sorting the markers, to make sure parents will be handled
before children
- No longer throwing an error when a bulk action entry no
longer is present in the agenda - most likely it was taken
care of together with its parent.
This commit defines three new functions in org-timer.el:
- org-timer-set-timer, bound to `C-c C-x ;' in Org buffers
and to `;' in Org agenda buffers. This function sets a
timer for the headline the cursor is currently it. Up to
three timers can be set.
- org-timer-show-remaining-time: this shows the remaining
time for the last set timer.
- org-timer-reset-timers: this reset all timers.
This functionality was requested by Samuel Wales and emulates
that of tea-time.el -- see the emacswiki doc about tea-time.el:
http://www.emacswiki.org/emacs/tea-time
Agenda bulk commands on marked entries now can also set the scheduling
date or a deadline. Normally, all entries will be set to the
specified date. However, when writing the change as "++5d" or "++2w",
then each time stamp will independently be shifted by that amount.
This commit implements refiling directly from the agenda.
It also implements a mechanism for selecting a number of entries in
the agenda and then executing a command on all of them. Possible
actions include archive, refile, todo state setting, and more.
When the agenda buffer for an agenda series is created, this was so
far done without the options of the custom agenda command in place.
This meant that some options would not take effect, because the only
place where that did would have an effect was during creation of that
buffer.
This commit makes sure that the global options of an agenda series are
in fact in place when the buffer is created.
Nicolas Goaziou writes:
> As I was saying in anoter post, it looks like there's something
> weird happening when using C-k in agenda view:
>
> 1. Create two new remember entries (i.e. test and test2) with the
> same tag (I used @office)
> 2. Narrow down the agenda view to only see the @office entries.
> 3. Kill the last but one entry (it should be "test") : both of
> "test" and "test2" disappear frow the view. Actually, "test2" is
> not properly killed, but it is scary nonetheless.
>
> It only happens with two last entries.
>
> Is anyone able to reproduce this ?
Peter Frings writes:
> Good day, org-ers
>
> I have seen a *small* problem in the Agenda's log mode.
>
> Org-mode version 6.26d
> GNU Emacs 22.3.1 (i386-apple-darwin9.5.0, Carbon Version 1.6.0) of 2008-11-01
>
>
> I have this in time-sheets.org:
>
>
> * Project AI
> ** Enhancement PT <2009-04-30 Thu 10:00-11:00 +1w>
> CLOCK: [2009-05-14 Thu 09:55]--[2009-05-14 Thu 10:45] => 0:50
>
>
> But, the Agenda shows this:
>
> Day-agenda (W20):
> Thursday 14 May 2009
> 9:00...... ----------------
> planning: 9:12- 9:55 Clocked: (0:43) BUSY Notifications
> time-sheet: 10:00-11:00 Clocked: (0:50) Enhancement PT
> time-sheet: 10:00-11:00 Enhancement PT
> 10:00...... ----------------
> 11:00...... ----------------
>
He is right. Progress lines should never take their
time from the headline, always only from the triggering line.
Benjamin Andresen writes:
> I was curious as to why a value such log-mode wasn't customizable
> to be run on start-up as follow-mode and clock-report-mode are.
>
> If Carsten thinks this is a good idea, I've attached a patch that
> may shave of 5 seconds of him adding it. It applies cleanly to
> current git HEAD.
This commit applies Beanjamin's patch
Tassilo Horn writes:
> I have this entry in an org-file.
>
> --8<---------------cut here---------------start------------->8---
> ** bung Grundlagen der Softwaretechnik (B 016) :teaching:
> <2009-04-22 Wed 08:30-10:00 +1w>
> <2009-04-29 Wed 10:15-11:45> (Fr Hannes bernehmen)
> --8<---------------cut here---------------end--------------->8---
>
> I expect it to be displayed every wednesday after 2009-04-22
> for 08:30-10:00 and on 2009-04-29 it should be displayed
> twice: one at the usual time and one for 10:15-11:45.
>
> But the agenda shows only the regular entry (08:30-10:00)
> and omitts the exception. If I reorder the timestamps, so
> that the exception comes first, only the exception will be
> shown on 2009-04-29. Every other wednesday shows the
> regular repeater date.
>
> What do I have to do to make that entry showing up twice on
> 29th April?
This commit adds a new option
`org-agenda-skip-additional-timestamps-same-entry'. When set
to t, an entry that has multiple active time stamps will get
multiple lines in the agenda.
If the trigger for a log mode entry in the agenda has notes, for
example a note associated with a state change or with a clock entry,
the first line of the notes will now be added to the logbook entry.
You can turn this off the with new variable
`org-agenda-log-mode-add-notes'.
During secondary agenda filtering, pressing "?" now will install a
filter that selects entries which do not have an effort defined.
This new model was necessary because we needed to stop interpreting
entries with no effort defines as 0 effort. This was inconsistent,
because for normal agenda sorting, the treatment of these entries
depends on the variable `org-sort-agenda-noeffort-is-high'. Now this
variable is also respected during filtering.
The new variable `org-agenda-cmp-user-defined' can contain a function
to test how two entries should be compared during sorting.
user-defined-up and user-defined-down can then be part of any sorting
strategy.
The new variable `org-agenda-search-headline-for-time' also turned off
time searching for diary items as an unwanted side-effect. This
commit makes sure that diary entries are always parsed for a time.
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'.
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.
