unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
style syntax. There still needs to be work done on the regexps for
recognising #+srcname lines possibly with/without parenthesised
arguments. This change makes org-babel-block-name return nil rather
than fail when it doesn't find a src block head (e.g. in a #+lob
line), which seems sensible.
The sbe test table is failing half-way down at `simple ruby
arrays'. For some reason it is making a mini table ("| |") to the
right hand, and point keeps jumping out of the table. My ability to
debug sbe-related stuff is hampered by me not understanding the
code (I need to learn about macros).
This is a rough, first-pass implementation using some code from
org-babel-ref.el. If we do go with this idea, I think we can find a
better implementation, hopefully using the same code for parsing
`function calls' (parameterised source block calls), whether they are
made directly at a source block, or as a reference in another function
call, or as a LoB call.
Bernt Hansen writes:
> I have a monthly repeated task (Archive tasks) that has lots of
> old clock time on it currently but has never been marked DONE
> since the creation of the property LAST_REPEAT_TIME. If this
> task is clocking when Emacs exits and you restart emacs and
> answer Yes to continue the clock - the modeline has the total
> time for the parent task (151:04 instead of the total time for
> this task (5:04). If I clock the task in again the modeline is
> correct.
This skips over blank lines preceeding the next task when archiving a task or
subtree. This allows us to use a keyboard macro to remember the archive key
sequence incantation and skips to the next heading so we don't accidentally
archive the wrong task.
This fixes an issue with blank line handling. Tasks which have blank lines
following them do not include the blank lines -- they are part of the following
task. This moves the point forward to the next visible headline so that if we
repeat the archive operation it affects the following task and not the previous
one by mistake.
This reverts commit d8001facab.
Going back to original plan of simply passing (cmd body params) to the org-babel-execute:LANG functions.
The benefit of this is that languages will have access to the full params list. A downside is that code parsing the
params list and referencing variables is currently duplicated across the languages, so perhaps we can aim to reduce
that code duplication at some point.
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.
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
Rainer Stengele writes:
> using org-mode for quite some time now I always look at
> operations (key sequences) I repeat a lot of times.
>
> A lot of times I start a list with an item and immediately
> indent the next item as subitem.
>
> From
>
> - item 1
> - subitem 11
>
> I go to
>
> - item 1
> - subitem 11
>
> via "M-right". Then I always want to change the style of the
> subitem list to "*". I do this via "S-right-right".
>
> I wonder how others work. I would like to automatically have
> changed the subitem list type to "*" as soon as I indent via
> "Alt-right". Next indentation should go back to "-". etc.
>
> Maybe we could introduce a variable that sets the order of
> standard list item types, in my case: "- * - * - * - *" as
> in
>
>
> - item 1
> * subitem 11
> - subitem 111
> * subitem 111
> ...
>
> very special I know but I try to reduce the keypressings as
> much as possible. Any other suggestions?
This commits adds the variable
`org-list-demote-modify-bullet' for this purpose.
Moved reference resolution out of language-specific files; changed
things so that we parse the header args list in org-babel.el, and
changed the argument list of the org-babel-execute:LANG functions
accordingly. In addition to hopefully resulting in easier maintenance,
this results in more streamlined org-babel-execute:LANG functions, and
hence less work to do when adding interpreters.
results-processing changes and state they are currently in. Here's the
comment:
You can see below the various fragments of results-processing
code that were present in the language-specific files. Out of
those fragments, I've moved the
org-babel-python-table-or-results and
org-babel-import-elisp-from-file functionality into the
org-babel-*-evaluate functions. I think those should only be
used in the :results value case, as in the 'output case we are
not concerned with creating elisp versions of results.
The rest of the functionality below, concerned with vectorising
or scalarising results is commented out, has not yet been
replaced, and may need to be reinstated in this function
This reverts commit a13cbf64b6.
I'm in favour of this change, but it seems that we need a more sophisticated way of combining plists before we can
change the default header args in this way. Otherwise, we get two entries for :results (one from the defaults and one
from the header args), whereas what we want is a single entry for :results with space-separated values.
When :results is 'value, the org-babel-LANG-evaluate functions are
responsible for returning an elisp representation of the *value* of
the block. This stage is maintained in the language-specific code
because different languages have different ways of doing it: python
and ruby use org-babel-LANG-table-or-string, whereas R and shell write
to file and then use org-babel-import-elisp-from-file. It could
however be put in the org-babel-execute:LANG function.
Bug fix: I was missing out org-babel-table-or-string with external
process evaluation (non-session).
Also, I have renamed org-babel-ruby-table-or-results to org-babel-ruby-table-or-string.
(the previous commit's message should have read org-babel-python-table-or-results...)
