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.
The variables =org-agenda-todo-ignore-with-date=,
=org-agenda-todo-ignore-with-date=, and
=org-agenda-todo-ignore-with-date= make it possible to
exclude TODO entries which have this kind of planning info
associated with them. This is most useful for people who
schedule everything, and who use the TODO list mainly to find
things that are not yet scheduled. Thomas Morgan pointed out
that also the tags-todo search may serve exactly this
purpose, and that it might be good to have a way to make
these variables also apply to the tags-todo search. I can
see than, but could not convince myself to make this the
default. A new variable must be set to make this happen:
=org-agenda-tags-todo-honor-ignore-options=.
An agenda series can have a set of global options. Matt Lundin
reported that these options to not work completely. There reason was
that, when calling `org-finalize-agenda' for a series, the dynamic
binding of those options was already off again. This commit makes
sure that these bindings are available also during this final step.
A new perl program, list-hooks.pl, now extracts the full list of hook
and function variables in Org, for inclusion into Worg's org-hooks.org.
Also, add a docstring to a few hooks that did not have one.
A prefix argument to the `org-agenda-show' command is now interpreted
to make sure the entire entry is made visible in the other window, not
only the headline.
Updating agenda lines did display tags incorrectly, because it used
the list of tags available as a property to remake the list. However,
that list contains down-cased versions of the tags, because all the
filtering in the agenda does ignore case in tags.
This patch implements a fresh scan for the tags each time a line is
updated, and in this way fixes the problem. It also reverses a
previous attempt to fix a similar problem.
Samuel Wales writes:
> It would be really nice if you could set tags to different
> faces the way you can with todo keywords.
>
> For example, you could set :urgent: to a bright color. Or
> set a face for all contexts.
This patch add a new customization variable `org-tag-faces' that can
be used to specify such faces. The rest of the patch implements these
new faces in Org-mode buffers as well as in the agenda.
This patch does a lot of things. First, it makes sure that the tags
transferred to the agenda as text properties on each line are do carry
information about there origin (in the form of an `inherited' text
property). Then it modifies the function creating agenda lines so
that inherited tags will be listed and identified as such in the
agenda.
This new feature can be turned off with a new variable,
`org-agenda-show-inherited-tags'.
If you set the variable `org-completion-use-ido' to t, and if you have
ido-mode turned on, most instanced of completion in Org-mode will use
ido-complete.
Thanks to Samuel Wales and Eric Schulte for patches to this effect.
Georg C.F. Greve asked for configurable leaders strings for agenda
display of time ranges. This patch implements these strings, in the
new option `org-agenda-timerange-leaders'.
Bernt Hanses writes:
This changes the default value for Effort during agenda filtering so
that an undefined Effort value is treated as 0 instead of nil. Tasks
with no effort defined now return zero effort when selecting tasks for
the filter.
There was effectively no way to select 'tasks with no effort defined'
using the agenda effort filter. The '<' operator is interpreted as
'<=' and the default effort selection defined in
org-agenda-filter-by-tag starts with zero ("0 0:10 ...") so this
change just treats tasks with no effort defined the same as tasks with
an effort of 0.
This allows fast selection of NEXT tasks with no effort defined.
Column view with follow-mode active in the agenda is great for quickly
filling in the agenda estimated effort values for tasks. Just display
your Next tasks, then / 0 to select tasks with no effort and enter
column mode (C-c C-x C-c) and fill in your effort values with the
quick keys (0-9) for all of the tasks that have blanks in the effort
column.
Jurgen Defume asked for a way to display only logging information in
the agenda. This patch implements such a possibility. It works by
calling `org-agenda-log-mode' (bound to `l' in the agenda) with a
double prefix arg. This sets the variable `org-agenda-show-log' to a
special value `only' which is then interpreted by the agenda-creating
functions.
Org records (depending on setup) various information about progress
achieved with projects and tasks. It can record when an item is done
(when it is "closed"), it can record time spent working on these
entries (clocking), and it can record state changes.
In the daily/weekly agenda, turning on logbook mode with the `l' key
will lists the tasks closed or clocked on a day.
This patch implements showing recorded state changes in the agenda
logbook. By default, showing state changes is not turned on. But you
can configure the new variable `org-agenda-log-mode-items' to trigger
inclusion of state changes. An alternative way is to press `C-u l' in
the agenda, to temporarily force inclusion of all possible entries
(closed, clock, state) into the agenda display.
In passing, this patch renames the function `org-agenda-get-closed' to
the now more appropriate `org-agenda-get-progress'. The old name
continues to be available as an alias, but its use is deprecated.
So far, Org used either `fit-window-to-buffer' or
`shrink-window-if-larger-than-buffer' without any further checks when
displaying one of its many help and selection buffers. This can cause
problems if the user has set up Emacs to split windows horizontally
rather than vertically, because the window being shrunken then may be
side-by-side with another window, and shrinking the height of one will
also change the other.
With this patch, shrinking a window always goes through the new
function `org-fit-window-to-buffer' which only acts if the current
window spans the whole width of the frame.
Furthermore, this function also helps with compatibility, because it
falls back to `shrink-window-if-larger-than-buffer' if
`fit-window-to-buffer' does not exist, as is the case on older version
of Emacs and XEmacs.
When marking a repeated entry DONE in the daily or weekly agenda, that
task would previously still be shown as TODO, because the repeater
immediately restores the TODO state after moving the time stamp. This
is bad feedback.
This problem was hard to fix. Because the same line may be present in
other lines in the same weekly agenda, we cannot simply update all
lines related to this entry.
What we do now is this: Before the repeater does its work in shifting
the time stamp and resetting the TODO keyword, we take a snapshot of
the headline as it looks then. And then, when we update the agenda
view, we change only the line at the cursor instead of all lines
related to this entry. We also make sure that this is only so if the
cursor is in a daily/weekly agenda, on TODAY's date.
There still remain possible inconsistencies. For example, if you have
a daily repeating task in the weekly agenda, and you move the cursor a
few days into the future and mark it DONE there, the entry will
actually be marked DONE for today, but still show up in today's task
list as TODO. refreshing the agenda will fix the display in such an
unlikely case.
Thanks to Jack ??? for noticing and reporting this issue.
C-c C-c still works with the cursor in a headline,
but I wanted a special binding as the default, mainly
in order to be able to set tags in a remember buffer.
Carsten Dominik
Peter Jones
Bernt Hansen
Bastien Guerry