Chris Randle writes:
> I've just noticed that creating a sparse tree with `C-c / r' is
> not displaying matches in my org file. It hasn't always been this
> way, I *think* things were working OK around 6.29, but it's hard
> to be sure.
>
> I've managed to pare my org file down to a few lines that
> demonstrate the problem
>
> ===============================
>
> * Customers
> ** Customer A
> *** Billing
> **** Support during September :ARCHIVE:
> ** Customer B
> 07964-xxxxxx
>
> *** Problem with Laptop
> ** Customer C
> *** Current Details
>
> *** Test of 07968 showing up
> ** Customer D
> 01673-xxxxxx
> 07968-xxxxxx
>
> *** Laptop slowdown fix
> spoolsv.exe at 99%
>
> ===================================
>
> Setting a sparse tree by regexp 0796[48] returns "3 match(es) for
> regexp 0796[48]", but the tree doesn't expand at the hit
> locations. If I manually expand the tree at the locations of the
> hits, the results are highlighted. It makes no difference if the
> hits are in a headline or in notes beneath a headline.
>
> Remove the ARCHIVE tag from the "Support during September"
> headline with `C-c C-x a' and redo the sparse tree. Everything
> now appears expanded as I'd expect.
Hmm, maybe the outline behavior of hide-subtree has changed???
Anyway, we now just use our own function for this.
Adam Spiers writes:
> The code for handling %^{PROP}p in org-remember templates seems to
> have a bug:
>
> ((equal char "p")
> (edebug)
> (let*
> ((prop (org-substring-no-properties prompt))
> (pall (concat prop "_ALL"))
> (allowed
> (with-current-buffer
> (get-buffer (file-name-nondirectory file))
>
> Here get-buffer can return nil, in which case `org-remember' fails
> with the error:
>
> Wrong type argument: stringp, nil
>
> It seems to be assuming that the non-directory part of the filename
> corresponds to the buffer name, but this is not guaranteed. Perhaps I
> noticed it because I am using uniquify.el ?
Doug Hellmann writes:
> Some calendar systems (Google, Zimbra) handle subscriptions to
> multiple calendars (or to an account) by grouping them under a single
> caldav directory in the calendar tree. org-mac-iCal assumes there is
> only one ics file created per caldav directory, so while it *creates*
> all of the needed merged ics files, it only copies one of them to
> ~/Library/Calendar before importing the contents into the diary.
RET will only do this if the cursor is on the link and
`org-return-follows-link' is set. `C-c C-o' will work anywhere in the
line.
Requested by Chris Leyon.
A "functional-style" source block is one in which the name is followed
immediately by a parenthesised argument. An example is the following
"function", which generates n uniform random numbers:
\#+srcname: rand(n)
\#+begin_src R
runif(n)
\#+end_src
With these changes, such source blocks are passed over to the export
machinery in the following form:
\#+begin_src org-babel-lob
<function-def-keyword> rand(n):
\#+end_src
\#+begin_src R <switches>
<indent>runif(n)
\#+end_src
where <function-def-keyword> is the value of
org-babel-function-def-export-keyword, which defaults to "function",
<switches> are the src block switches that belonged to the original
block, and <indent> is the whitespace indent of the function body, the
width of which is determined by org-babel-function-def-export-indent.
org-babel-lob is a simple major mode responsible for fontification of
the blocks corresponding to the function definition line (as opposed
to the function body).
This adds a new terminal (sixth) element to the list returned from
org-babel-get-src-block-info. It is used when exporting the code of
"functional style" code blocks, i.e. those in which the name of the
block is followed by a parenthesised argument list (or an empty pair
of parentheses).
- org-babel-get-src-block-info returns the name of the block as a new
fifth element.
- org-babel-get-src-block-info incorporates the parenthesised variable
references into the header arg list, with precendence given to
explicit :var references, as before.
- remove function org-babel-get-src-block-name
- remove function org-babel-get-src-block-function-args
org-babel-get-src-block-function-args now returns a list
(lang body params-alist switches srcname)
where, unless a non-nil value for the optional argument is passed,
params-alist contains any :var entries acquired from the parenthesised
argument list following the srcname.
The switches are flags like -n and must *precede* the first colon
after the language (i.e. precede the first header argument). So the
general src block syntax is
\#+begin_src lang <switches> :header1 val1 :header2 val2 ...
...
org-babel-get-src-block-info now returns a list
(lang body params-alist switches)
With these changes, if org-src-preserve-indentation is non-nil, or if
the block has a -i switch, then the behaviour of org-exp-blocks is
altered as follows:
1. Indentation is not removed before passing the block contents to the
block-transforming plugin.
2. The result returned by the plugin is not re-indented.
The following keys now do archiving
C-c C-x C-a archive using the command specified in
`org-archive-default-command'
This variable is by default set to `org-archive-subtree', which means
arching to the archive file.
The three specific archiving commands are available through
C-c C-x C-s archive to archive file
C-c C-x a toggle the archive tag
C-c C-x A move to archive sibling
These bindings work the same in an Org file, and in the agenda.
In addition:
- In the agenda you can also use `a' to call the default archiving
command, but you need to confirm the command with `y' so that this
cannot easily happen by accident.
- For backward compatibility, `C-c $' in an org-mode file, and `$' in
the agenda buffer continue to archive to archive file.
Dan Davison writes:
> If a file contains "-1" followed by a newline and nothing else,
> org-table-import on that file fails. The first commit with this
> property is a commit (below) to do with CVS tables made a few
> days ago. I have given up trying to work out a good solution to
> this :) In case it is useful, the failure occurs when
> org-table-align is called at the end of
> org-table-convert-region. I think it is long-standing behaviour
> that hitting tab inside of
>
> |-1|
>
> doesn't make a table containing "-1", so presumably there is
> something different about the context in which org-table-align is
> now being called.
