B S will cause tasks to be rescheduled a random number of days into the
future, with 7 as the default. This is useful if you've got a ton of
tasks scheduled for today, you realize you'll never deal with them all,
and you just want them to be distributed across the next N days.
* org-agenda.el (org-agenda-custom-commands-local-options):
Allow org-agenda-span to be a symbol.
(org-agenda-ndays): Make obsolete.
(org-agenda-span): New variable superseding org-agenda-ndays.
(org-agenda-menu): Use org-agenda-current-span.
(org-agenda-current-span): New local variable storing current
span.
(org-agenda-list): Take a span instead of ndays as argument.
This function is now responsible for computing the ndays based
on span.
(org-agenda-ndays-to-span): Return span only if number of days
really matches.
(org-agenda-span-to-ndays): New function.
(org-agenda-manipulate-query): Use org-agenda-compute-starting-span.
(org-agenda-goto-today): Use org-agenda-compute-starting-span.
(org-agenda-later): Do not give compute a new span, use the
current one.
(org-agenda-day-view, org-agenda-week-view)
(org-agenda-month-view, org-agenda-year-view): Stop touching
org-agenda-ndays.
(org-agenda-change-time-span): Only compute starting-span.
(org-agenda-compute-starting-span): New function derived from
the old org-agenda-compute-time-span.
(org-agenda-set-mode-name): Compute mode based on
org-agenda-current-span.
(org-agenda-span-name): New function.
* org-mouse.el: Replace Replace org-agenda-ndays by
org-agenda-current-span.
* org.texi, orgguide.texi: Replace org-agenda-ndays by
org-agenda-span. Add a paragraph about org-agenda-span and say that
org-agenda-ndays is now deprecated.
This patch is pretty huge, so I'll give a bit of context about it.
I'm weird, but I used org-agenda-ndays set to 14. Unfortunately, this
settings was interpreted as a month view. Pressing 'f' key to see later,
would show me the next month, which was not at all what I wanted.
On the same idea, day view or week view would change my org-agenda-ndays
settings, which I think is not a good idea. Changing user setting is *bad*.
:-)
So I rewrote the things this way:
- Rename org-agenda-span to org-agenda-current-span
Which has the same meaning has before, except it can be numeric.
- Rename org-agenda-ndays to org-agenda-span
I think the name is better choosen. You can set it to a symbol instead of
only a numeric value. That means you can set it to 'month and it will show
you the number of days of the current month in your agenda. Better than
30. But you can still set it to 30, or 31, or whatever you want.
- Do not change org-agenda-span. Never.
- Use org-agenda-current-span for navigation.
That means if you press 'f', it will shows you really the next
org-agenda-current-span ndays, and not something based on "I think you
want a weekly view".
* lisp/org-agenda.el: (org-format-agenda-item) The value of
org-category is not converted to a string unless it is defined.
This fixes commit 3061c7083d, which
resulted in org-format-agenda-item always returning the symbol-name for
org-category even if it was not defined. I.e., in some instances,
org-format-agenda-item returned the string "nil", thus bypassing the
buffer-file-name method of deriving the category.
* lisp/ob-python.el (org-babel-execute:python): Pass the new "prefix"
header argument through to external evaluation.
(org-babel-python-evaluate): Pass the new "prefix" header argument
through to external evaluation.
(org-babel-python-evaluate-external-process): When specified prepend
"prefix" to the file used in external evaluation.
* lisp/ob-sql.el (org-babel-expand-body:sql): Expand the body of a sql
code block.
(org-babel-execute:sql): Use sql specific body expansion function.
(org-babel-sql-expand-vars): Insert variables into a sql code block.
* lisp/ob-sqlite.el (org-babel-execute:sqlite): Remove unused variable
declaration.
* lisp/org-clock.el (org-day-of-week): New function.
(org-quarter-to-date): New function.
(org-clock-special-range): Implement quarters.
Patch by Erwin Vrolijk
* org-agenda.el (org-format-agenda-item): Convert category to a string
if it is a symbol. This fixes the following call to
org-agenda-get-category-icon which fails if category is not a string.
Signed-off-by: Julien Danjou <julien@danjou.info>
* lisp/ob-clojure.el: Updated requirements documentation to mention
the minimum version of Clojure.
(org-babel-expand-body:clojure): Fully qualified function name.
* lisp/org-latex.el (org-export-latex-lists): do not add an
unnecessary newline character after a list.
* lisp/org-list.el (org-list-bottom-point-with-indent): ensure bottom
point is just after a non blank line.
* lisp/ob-python.el (org-babel-execute:python): Use a :return header
argument for external evaluation in which the code block body need
be wrapped in a function
Thanks to Darlan Cavalcante for proposing this feature.
* lisp/ob-clojure.el (org-babel-execute:clojure): Remade using slime
for all code evaluation.
(org-babel-expand-body:clojure): Remade in the image of
`org-babel-expand-body:emacs-lisp'.
* lisp/org-beamer.el (org-beamer-sectioning): Allow overlay arguments for
the column as well.
* doc/org.texi (Beamer class export): Document that also overlay arguments
can be passed to the column environment.
Eric Fraga writes:
> I am trying to create a beamer slide which has two columns. The second
> column should only appear after a while (the 6th uncovering operation).
> In latex, I would do:
>
> : \begin{column}<6->{0.4\textwidth}
>
> say. In org, I would expect to be able to get this latex code generated
> by the following:
>
> --8<---------------cut here---------------start------------->8---
> ***** column heading :BMCOL:B_block:
> :PROPERTIES:
> :BEAMER_col: 0.4
> :BEAMER_envargs: c<6->
> :BEAMER_extra:
> :BEAMER_env: block
> :END:
> --8<---------------cut here---------------end--------------->8---
>
> according to the info documentation (Beamer class export).
>
> However, this does not work: the "c<6->" is placed verbatim in
> the \begin{block} that comes after the \begin{column}. Furthermore, if
> I ask for the heading to be ignored (instead of defining a block), the
> envargs are lost completely!
