Daniel Clemente writesL
> Hi, I found an HTML export bug with org-mode 6.34c-140-g44c8 and
> older. I used:
>
> --------------------------------------------------------
> * only one section
> #+BEGIN_EXAMPLE:
>
> We need:
> ,* pears
> ,* lettuce
> ,* watermelons
>
> Very important!
> #+END_EXAMPLE:
> --------------------------------------------------------
>
> And the outputed table of contents had this code:
>
> --------------------------------------------------------
> <div id="text-table-of-contents">
> <ul>
> <li><a href="#sec-1">1 only one section </a></li>
> <li><a href="#sec-2">2 pears</a></li>
> <li><a href="#sec-3">3 lettuce</a></li>
> <li><a href="#sec-4">4 watermelons</a></li>
> </ul>
> </div>
> --------------------------------------------------------
>
> This is wrong because the asterisks inside the example don't
> represent headers. There should be only one header.
Lukasz Stelman writes:
I've create some presentation on programming (some more to do) and to my
surprise I've discovered that if org-mode escapes one "&" properly it
doesn't do its job in case of "&&" (and a single "^" too). I get "\&&"
in latex file which of course is wrong.
This change fixes a bug in the remote execution branch, involving the
way that org-babel-tramp-handle-call-process-region is used
to (conditionally) handle calls to call-process-region. When
org-babel-execute-src-block called itself recursively (e.g. when
resolving a reference to another src block), a circular binding of
symbols and values resulted.
When using ':results value' in certain situations, results are written
to file by the foreign language process and subsequently read from
file by emacs into an elisp table structure. If the foreign language
process is running remotely, then the results are written
remotely. These changes ensure that in that case, an appropriate
remote file name is constructed to read the remote data.
These changes solve two problems: both are discussed in the following thread
http://lists.gnu.org/archive/html/tramp-devel/2010-02/msg00025.html
of which a summary follows.
Firstly, shell-command-on-region does not work with tramp in the same
way that shell-command does. I.e. whereas
(let ((default-directory "/user@remote-host:"))
(shell-command "hostname" t))
gives the remote hostname,
(let ((default-directory "/user@remote-host:"))
(shell-command-on-region (point) (mark) "hostname" t))
does not.
The reason is that shell-command-on-region calls call-process-region,
which does not use a tramp handler for remote files. However, such a
file handler does exist (unused) in the tramp sources:
tramp-handle-call-process-region. There is a slight problem in that
there is a bug in that function definition in current tramp (which has
persisted because the function is not normally used).
Therefore, we define an org-babel version of
tramp-handle-call-process-region which fixes the bug, and we bind
call-process-region to org-babel-tramp-handle-call-process-region for
the duration of org-babel-execute-src-block.
This introduces a new header argument :dir. For the duration of source
block execution, default-directory is set to the value of this header
argument. Consequences include:
- external interpreter processes run in that directory
- new session processes run in that directory (but existing ones are unaffected)
- relative paths for file output are relative to that directory
The name of a directory on a remote machine may be specified with
tramp syntax (/user@host:path), in which case the interpreter
executable will be sought in tramp-remote-path, and if found will
execute on the remote machine in the specified remote directory.
Use shell-command-on-region, bringing R into line with ruby, python,
clojure, shell. In addition to consistency (and perhaps efficiency),
this will also be preferable in the case of a remote R process because
it means that transfer of the input to the remote process is dealt
with automatically by tramp.
This support was totally broken. It works now again. Unfortunately
it is not possible to edit the table directly in the org-mode buffer
anymore - to edit such a table, you have to use C-c '
This patch implements reading American dates, like
2/5/3 --> 2003-02-05
2/5 --> ????-02-05
Is also fixes a bug that would force the current year when reading a
date like 2/5 (American) or 2-5 (ISO), and in this way would prevent
`org-read-date-prefer-future' to do its job. This bug was reported by
Lukasz Stelmach.
Before this change we have
#+begin_src ruby :results value :session
["1", "3"]
#+end_src
#+results:
: 1", "3
After, we have
#+begin_src ruby :results value :session
["1", "3"]
#+end_src
#+results:
| 1 | 3 |
Carsten Dominik
Łukasz Stelmach
Dan Davison
Eric Schulte