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.
> Feature Request: that the pdf saved automatically from agenda be
> immediately displayed
> The saving of a pdf is a really nice feature. I had hacked
> org-agenda, I think, to automatically do this. However, it would
> be nicer if immediate display were optional. I don't know
> whether \C-u makes sense as a prefix to saving a file with \C-x
> \C-w. Perhaps not.
Why not, C-c C-x C-w is a fine idea for this. It should now work.
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.
Custom commands can now bind `org-agenda-filter-preset'. This filter
will then be present in the agenda view and persist through refresh
and further filtering. Only a new agenda command will remove the
filter again.
The variable org-priority-faces can now be used to set special faces
for different priority cookies.
Also, in the agenda, the default is now to fontify only the priority
cookie, not the entire task. See the variable
`org-agenda-fontify-priorities'.
Before this patch, org-agenda-quit would delete the agenda window if
the frame had more than one window. This patch changes that behavior
slightly so that if org-agenda-window-setup is 'current-window, the
agenda window won't be deleted.
A new hook is introduced, `org-agenda-before-write-hook'.
A function that ca be added to this hook is
`org-agenda-add-entry-text'. When this is done, each of the entries
shown in the agenda is amended with text that in the original buffer
is part of the entry text below the headline. Drawers are not copied,
and also the line with scheduling and deadline information is not
used. Finally, the number of ines to be added is imited by
`org-agenda-add-entry-text-maxlines'.
If the headline contains a time-of-day in one format or another, it
will be used to sort the entry into the time sequence of items for a
day. Some people have time stamps in the headline that refer to the
creation time or so, and then this produces an unwanted side effect.
If this is the case for your, use the new option
`org-agenda-search-headline-for-time' to turn off searching the
headline for a time.
John Rakestraw writes:
> I noticed today that, at least in my set-up, setting these variables
> this way:
>
> (setq org-agenda-dim-blocked-tasks 'invisible)
> (setq org-enforce-todo-checkbox-dependencies t)
>
> means that a TODO task with checkboxes doesn't get included in the
> agenda. However, the sub-tasks in the checkbox list don't get included,
> either. So the TODO task with checkboxes doesn't show up in the agenda.
>
> It makes sense given the way the variables work. However, I wonder if
> it makes more sense for a task with checklisted sub-tasks to be
> included in the agenda so that the tasks and sub-tasks don't get lost.
> Or, to put the point slightly differently, I think that a TODO that's
> blocked because it has dependent TODOs might be treated differently in
> agenda listings than a TODO that's blocked because it has dependent
> checklist items.
>
> Not a big deal to me because I don't typically use checkboxes for TODO
> items. But I thought I'd raise it for consideration.
I agree with this view and the commit implements exactly this.
The variables `org-agenda-todo-ignore-deadlines' and
`org-agenda-todo-ignore-with-date, and
`org-agenda-tags-todo-honor-ignore-options' are now all mentioned in
the docs.
The commands org-agenda-show can now be used to show varying degrees of
context when called with a prefix argument. `0 SPC', `1 SPC', ... `4
SPC'.
The new command `org-agenda-cycle-show' shows different amounts of
context when called several times in succession.
Christopher Suckling reports that todo state sorting doe not work in
block agenda. The reason for this that the variable
`org-todo-keywords-for-agenda' which is supposed to be a lost of all
keywords of all buffers contributing to the agenda, is not correct
during the construction of a block agenda.
Therefore, this commit instructs the todo state comparison function to
refer back to the original buffer for a list of todo keywords.
When org-depend.el is loaded, running the blocker hook will already
toggle a tag. However, when dimming the agenda, we do not want that.
Reported by Dan Griswold.
