Now the recommendation is to use clock persistence only for the
history, and to use John's code for resolving a clock that has been
idle (either because the user stopped working or exited Emacs).
org-habit.el: New file, which implements code to build a "habit
consistency graph".
org-agenda.el (org-agenda-get-deadlines)
(org-agenda-get-scheduled): Display consistency graphs when outputting
habits into the agenda. The graphs are always relative to the current
time.
(org-format-agenda-item): Added new parameter `habitp', which indicates
whether we are formatting a habit or not. Do not display "extra"
leading information if habitp is true.
(org-agenda-auto-exclude-function): New customization variable for
allowing the user to create an "auto exclusion" filter for doing
context-aware auto tag filtering.
(org-agenda-filter-by-tag): Changes to support the use of
`org-agenda-auto-exclude-function'. See the new manual addition,.
See the new manual section on "Resolving idle time".
(org-clock-resolve-clock): If keeping or subtracting time results in a
clock out at a time in the past, and if the resolution occurred due to
idleness or invoking `M-x org-resolve-clocks', remember that past moment
in time. On the next clock in, the user will be prompted to see if they
want to back-date their new clock to then.
(org-clock-resolve): Do not jump the user to the location of a dangling
clock if the resolution is occuring due to an idle timeout. In that
case there is typically only one dangling clock, the active one, and
there is no value gained by shuffling their windows around to show it to
them. Being prompted to resolve an idle clock should be as inobtrusive
as possible.
(org-resolve-clocks-if-idle): New function that resolves only the
currently active clock if the user has exceeded the time returned by
`org-user-idle-seconds', based on the value of `org-clock-idle-time'.
(org-clock-in): If, after resolving clocks,
(org-clock-out): Cancel the `org-clock-idle-timer' on clock out.
This file should be with the other org files, and not in the staging
area. Also, when file names in mobileorg.org are interpreted, this
should be relative to org-directory. So we also require now that the
user set this variable.
The default in search view is not that the search expression is
searched for as a substring, i.e. the different words must occur in
direct sequence. The old way is only used it the first word in
the search string is preceded by a plus or a minus.
This was, more-or-less, requested by John Wiegley.
The reorganizes parts of the manual. The Archiving stuff has been
moved into the new chapter "Capture-Refile-Archive". Also, there is a
new chapter "Markup" to contains both the markup rules (moved there
from the Export chapter) and the embedded LaTeX stuff.
PT writes:
> Currently, I'm using Google Calendar and it's quick add syntax is very
> convenient:
>
> http://www.google.com/support/calendar/bin/answer.py?hl=en&answer=36604#text
>
>
> Of course, Org has similar capabilites, but I found one thing which
> google calendar does better: if it's 4pm and I add an event for 8am
> then GCal schedules it for 8am tomorrow.
>
> Org, on the the other hand, schedules it for 8am today even if that
> time is already passed.
>
> I never add past events and I think it's quite atypical. Shouldn't be
> an option similar to org-read-date-prefer-future for times too, so
> that timestamps also prefer the future when no date given?
This is now possible, but it is not the default. You need to set
(setq org-read-date-prefer-future 'time)
The new variable org-mobile-files can now be configured to include
non-agenda files into the staging area for MobileOrg. Furthermore,
files that are located in a subdirectory of `org-directory' will also
end up in a sub-directory in the staging area.
Peter Westlake writes:
> Could I request this as a small feature enhancement, please?
> Commands like org-refile have an agenda equivalent so that
> the same keys work in the agenda, and it would be very nice
> to be able to store a link to an item that way as well.
The width and alignment in table columns can be set with a cookie like
"<10>" or "<r>" or "<r10>". In order to keep Org from exporting such
lines, the first column of a line can contain only "/". However, for
convenience, this commit implements a special case: If the entire row
contains only sch markers, the line will automatically be discarded
during export.
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.
A relative row reference like @-1 in a table may now reach across a
horizontal separator line. I hope this will not break any important
tables out there, but I think it is the right thing to do.
The original reason for not-crossing was to implement running
averages of one column in the next. This can now be done using field
formulas near the beginning and end of the column, and a column
formula for the central part.
See the variable `org-table-relative-ref-may-cross-hline' for more
details.
Using :timetamp t as an option in a clock report now allows
insertion of the timestamp for the clocked entry. Timestamps
are searched for in this order: SCHEDULING, TIMESTAMP, DEADLINE
and TIMESTAMP_IA.
Allow whitespace in code references. Allow the -r switch to remove the
references in the source code even when the lines are not numbered: the
labels can be explicit enough. Note that "-r -k" is the same than no
switch - as expected.
Thanks to Ulf Stegemann for bring this up.
This hook is called in org-clock-in earlier than the existing
org-clock-in-hook. This is useful for functions that need to
modify the Effort property, for example.
When changing the publishing setup, old timestamp files can be left
behind. Forcing publishing of all projects with `C-u C-c C-e E'
will remove all existing timestamp files.
Many different people want to set many different variables in a
buffer-local way for export. This cannot be done with file variables,
because the Org buffer is not current while the exporter is running.
Lots of variables can be set with the #+OPTIONS lines, but finding
abbreviations goes only so far.
Therefore we have now a general mechanism that can be used to bind
variables during export operations.
a line like: #+BIND: variable value
will bind the variable to value. For example,
the line
>> #+OPTIONS: toc:nil
can now equivalently be written as
>> #+BIND: org-export-with-toc nil
Customize the new variable org-footnote-auto-adjust or use the STARTUP
option fnadjust to get automatic renumbering and sorting of footnotes
after each insertion/deletion.
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.
TAB now cycles visibility in plain lists if the cursor is in a plain
list. This corresponds now to the new default value `t' of
`org-cycle-include-plain-lists'. If you want to treat plain list
items as part of the outline hierarchy during cycling of outline
headings (this is what a `t' value used to mean), set this variable to
`integrate'.
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.
Michael Brand writes:
> 2) One could like to have configurable left/right alignment, even
> combinable with column width, e. g.
>
> | <l10> | <r> |
> | 3.14 | 0x10 |
> | 3.141592=> | 0x32 0x10 |
Good idea, I would say.
Clicking on the clock in the mode line now pops up a menu with
clocking options.
A new command `C-c C-x C-e' allows to set or change the effort
estimate of the task currently being clocked. This is mainly useful
when using an alert notification when the task should be finished.
Based on a patch by Konstantin Antipin.
This commit changes which time is shown in the mode line while
clocking. Normally this will now be the total time ever clocked on
this task and its children.
However, when the task is a repeating one, only the time since the
last reset of the task will be shown. The time of the last reset is
now recorded in a LAST_REPEAT property.
You can also set the CLOCK_MODELINE_TOTAL property to the value
"current" to only show the current clocking instance. Or it may be
the value "today", to only add up the time spent today on this task.
Other possible values are "repeat", "all", or "auto".
Finally, you can set your default for this property with
`org-clock-modeline-total'.
This commit introduces two new variables:
- org-treat-insert-todo-heading-as-state-change
Default is nil. When set to t, adding a new TODO item will be done
by adding an item and the executing an "official" state change which
potentially will trigger state logging.
- org-treat-S-cursor-todo-seletion-as-state-change
Default is t. When set to nil, selecting a TODO state with
S-left/right will not trigger logging, only selecting a new state
with `C-c C-t'. I actually like this a lot and would even consider
making this the default.
Mikael Fornius writes:
> This is my suggestion of an implementation of min/mean/max computation
> in columnview summaries. If you like it feel free to use it.
>
> New operators: {min}, {max} and {mean} possibly prefixed with : for use
> with timevalues.
>
> Example from my running exercise diary:
>
> #+COLUMNS: %DISTANCE{+;%.1f} %HEARTRATE{mean;%.1f} %SPEED{:min} %CALORIES{+}
>
> Gives a colview with summaries:
>
> total distance, mean heartrate, fastest speed (min/km) and total
> calories.
>
> I have tested it on emacs-23 and it works well for me now, also with the
> interactive colview functions.
>
> But you never know really. ;-) Anyway, there should not be any emacs-23
> specific elisp code added afik.
>
> (Because I do not use xemacs I have not tested it with xemacs but the
> small changes I made should be compitable to both xemacs and emacs. I
> would appreciate if someone on this list who uses xemacs will give it a
> try for me. Thanks!)
>
> (This fix also opens up for using user defined lisp functions to
> calculate colview summaries, but I am not sure if that is something
> useful. Like this:
>
> (defun std (&rest values)
> "Compute standard deviation."
> ...)
>
> #+COLUMNS: %DATA{eval:std}
>
> If someone finds this attractive it would now be easy to implement as well.)
>
Hsiu-Khuern Tang writes:
> Hi Carsten,
>
> You recently changed org-edit-src-code to use a separate buffer
> instead of an indirect buffer. One side effect of this is that I
> can no longer edit several code examples at the same time:
> opening the second buffer will silently discard any changes made
> in the first. I would prefer this behavior: when opening the
> second edit source buffer, write any changes in the first buffer
> to the originating Org buffer (but don't save it, of course).
>
> Another approach is to use different buffer names.
The better approach is clearly to allow several buffers, now
implemented with this commit.
There is now a new export function, `org-export-as-org', which
basically creates a copy of the Org file with things like archived
trees, commented trees, and trees deselected by export tags,
stripped.
This commit adds:
{{{date(FORMAT)}}} current date/time, formatted with
`format-time-string'
{{{modification-time(FORMAT)}}} date/time of last modification of
file, formatted with `format-time-string'
{{{input-file}}} the file name of the source Org file.
The commit implements a general mechanism for providing special
(e.g. completion) support for specific link types when entering links
with `C-c C-l'. After calling `C-c C-l', you may now press RET after
inserting a link prefix, and Org will look for a function
`org-PREFIX-complete-link'. Such functions may be defined for any
link types, including link abbreviations. Currently, Org has
`org-file-complete-link' for file name completion, and
`org-bbdb-complete-link' for completion of record names from BBDB.
Jason Riedy writes:
> I'm trying to change org-export-latex-image-default-option
> to "width=.7\\linewidth" in a file local variable. It's set
> correctly as a buffer local variable, and it's having no
> effect on the export. My guess is that the buffer-local
> property is stopping it as soon as org-export-as-latex runs
> set-buffer.
>
> I can smuggle the value in by adding an entry to org-export-plist-vars
> referring to org-export-latex-image-default-option and pulling the value
> from the plist, but that feels incorrect.
It is actually the correct way to do this, and I have
implemented this change.
Samuel Wales writes:
> I frequently export to ascii without wanting a file to be created,
> especially not in a useful directory, as the files are temporary.
>
> Is there a way to export ascii to just a buffer?
There is now, `C-c C-e A'.
This commit also implements commands
- org-export-as-ascii-to-buffer
- org-replace-region-by-ascii
- org-export-region-as-ascii
which are similar to what is available for HTML and LaTeX.
`C-c C-e A' used to be the key for publishing all projects.
This functionality has now been moved to `C-c C-e E'.
The variable `org-refile-target-verify-function' can be set to a
function that will be called to verify a refile target. The function
must return t if the target is valid.
When refiling, you can now create new parent nodes on the fly. To do
this, set the variable `org-refile-allow-creating-parent-nodes' to
`confirm'. Then, at a refiling prompt, proceed with completion until
you have an existing heading, and then add "/new heading", i.e. a
slash followed by the new heading. That heading will be created as a
child of the existing heading, and the entry to be refiled will end up
under that new heading.
New wrapper span around keyword plus time stamp, with class
timestamp-wrapper.
.timestamp-wrapper {float: right;}
could be a nice entry in a CSS style file.
Mapping call a function for each matching entry. So far this has
always assumed that the entry stays in the buffer and search can
continue from there. However, when the mapper function removes the
tree, more control is needed to specify from where the search should
continue.
The action function handed to the mapping function can now set the
variable `org-map-continue-from' to the position from where mapping
should continue.
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.
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.
Installation of info files works differently in Debian. There is now
a new Makefile target `install-info-debian' to handle this, and this
fact is mentioned in the manual as well.
Carsten Dominik
John Wiegley
Bastien Guerry
Bernt Hansen