* lisp/org-indent.el (org-indent-remove-properties):
(org-indent-add-properties): Make sure changing these properties does
not trigger modification hooks
* lisp/org.el (org-link-search-must-match-exact-headline): New option.
(org-link-search-inhibit-query): New variable.
(org-link-search): Search for exact headline match in Org files
* doc/org.texi (Internal links): Document the changes in internal links.
Internal links used to do a fuzzy text search for the link text. This
patch changes the behavior for Org files. Here a link [[My Target]]
now searches for an exact headline match, i.e. for a headline that
does look like "* My Target", optionally with TODO keyword, priority
cookie and tags.
The new option `org-link-search-must-match-exact-headline' is
`query-to-create' by default. This means that a failed link search
will offer to create the headline as a top-level headline at the end
of the buffer. This corresponds to a wiki-like behavior where missing
targets are automatically created. If you do not like this behavior,
change the option to t.
* ob.el (org-babel-execute-src-block-maybe): remove check for
`org-babel-no-eval-on-ctrl-c-ctrl-c'; this is done in the new
function `org-babel-execute-safely-maybe'
(org-babel-execute-maybe): new function to execute src blocks
or lob/call lines.
(org-babel-execute-safely-maybe): new function to execute src blocks
or lob/call lines via C-c C-c
(org-ctrl-c-ctrl-c-hook): remove
`org-babel-execute-src-block-maybe' and add
`org-babel-execute-safely-maybe'.
* ob-lob.el (org-ctrl-c-ctrl-c-hook): remove
`org-babel-lob-execute-maybe'
* ob-keys.el (org-babel-key-bindings): New function
`org-babel-execute-maybe' is bound to C-c C-v e and C-c C-v
C-e
This parameter default to 140 and controls the resolution of images
created from LaTeX fragments for HTML output. There is no :resolution
parameter: the resolution of images produced for a buffer is computed
from the font height.)
This was suggested by Uriel (amscopub-mail@yahoo.com).
2010-08-03 Dan Davison <davison@stats.ox.ac.uk>
* ob-octave.el (org-babel-octave-wrapper-method): use dlmwrite
to write delimited text instead of save -ascii
(org-babel-octave-import-elisp-from-file): specify that data
written to file is tab-delimited
2010-08-03 Dan Davison <davison@stats.ox.ac.uk>
* ob-R.el (org-babel-R-evaluate): Specify that tabular data is
tab-delimited
Prior to this we had
#+begin_src R
c("some words", "with spaces")
#+end_src
#+results:
| some | words |
| with | spaces |
2010-08-03 Dan Davison <davison@stats.ox.ac.uk>
* ob-python.el (org-babel-python-table-or-string): Fix
recognition of lists and tuples
Prior to this we had
#+begin_src python
return [1, 2]
#+end_src
#+results:
: [1, 2]
Hi,
I'm starting to work with ob-octave and found several problems:
The first, for which I have a fix (see patch below) is that octave's
output was passed on as a string instead of being interpreted as a table:
[diff removed]
Now this works:
8<------------------------------------------------------------
#+source: test_output
#+begin_src octave :results value vector
[[1 2 3];[4 5 6]]
#+end_src
#+results: test_output
| 1.00000000e+00 | 2.00000000e+00 | 3.00000000e+00 |
| 4.00000000e+00 | 5.00000000e+00 | 6.00000000e+00 |
8<------------------------------------------------------------
(before the patch you'd get a single table element with something like
"1 2 3\n 4 5 6\n" inside).
The second problem is that if I use octave table output as input to
another block, it gets interpreted as a string instead of a vector:
8<------------------------------------------------------------
#+results: test_output
| 1.25000000e+00 |
#+source: check_input
#+begin_src octave :var input=test_output() :results output
ischar( input )
size( input )
#+end_src
#+results: check_input
: input = 1.25000000e+00
: ans = 1
: ans =
: 1 14
8<------------------------------------------------------------
This has to do with the EXP notation. The 'e+00' suffix makes the
whole table into a string. The problem is with "%S" in the formatting
inside org-babel-octave-var-to-octave.
The following patch seems to fix it (and makes it possible to work with
complex numbers inside the tables)::
[diff removed]
A third problem is with org-babel-octave-var-to-octave.
For example:
: (org-babel-octave-var-to-octave '( ( 1 2 3 ) ( 4 5 6 ) ))
: -> "[[1, 2, 3], [4, 5, 6]]"
This is not a 2x3 matrix, but a 1x6 vector:
: octave-3.2.3:1> [[1,2,3],[4,5,6]]
: ans =
: 1 2 3 4 5 6
a semicolon ';' or '\n' is needed between rows instead of a comma.
To sum up:
- 2 patches for prepare-session and importing the results back as
org-tables (I don't know if these patches break anything).
- 1 problem with matrix notation in org-babel-octave-var-to-octave.
I'll try to provide a patch for this today.
2010-08-01 Juan Pechiar <Pechiar@computer.org>
* ob-octave.el (org-babel-octave-evaluate-external-process):
use `org-babel-octave-import-elisp-from-file' instead of
`org-babel-eval-read-file'.
(org-babel-octave-var-to-octave): separate matrix rows with
';', and use '%s' as format specifier instead of '%S'
From: Alexandre Passos <alexandre.tp@gmail.com>
> I was editing an org document on a server earlier today, remotely
> using tramp, and continuously exporting it to html. When I added
> LaTeX, it exported once and then not anymore, failing because it
> couldn't create a directory anymore. So I found out that patching
> org-export-latex to pass a "t" parameter to org-make-directory fixes
> this, and it continues to work perfectly. This is the modified version
> of that function, if anyone else is interested in this constrained
> case. The only change I made was right under the "make sure directory
> exists" comment.
Hello,
>>>>> Neil Hepburn writes:
> The latest version (7.01g) seems to have a bug when exporting to PDF
> (and LaTeX) with tables with labels. The export does not label the
> table in the LaTeX file although it is labeled in the .org file.
Curiously, it looks like \label code was removed at some time.
This quick fix should put labels back.
Regards,
-- Nicolas
>From 64855c52b20766db9898ce82316fac11d51de72d Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Wed, 28 Jul 2010 20:54:40 +0200
Subject: [PATCH] Add labels to tables.
* org-latex.el (org-export-latex-tables): add label if any
* org-latex.el (org-export-latex-convert-table.el-table): fix little
mistake when inserting label
Hello,
Like what is already done with drawers, point should not move when
cycling visibility of headings and list items.
The call to `org-back-to-heading' this patch removes seems redundant
anyways.
Regards,
-- Nicolas
>From 17cd55557d747366c90fad47b44edeac2daf920b Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Sun, 25 Jul 2010 23:14:08 +0200
Subject: [PATCH] Cursor stays at same column when cycling visibility.
* org.el (org-cycle-internal-local): Removed an unnecessary call to
`org-back-to-heading' that was preventing point to stay at its
column when cycling visibility.
The attached patch suppresses a compiler warning in org-gnus.el
* lisp/org-gnus.el:
Suppress compiler warning by declaring outside function
nnimap-retrieve-headers-from-file.
On Sat, Jul 31, 2010 at 12:54 PM, Simon Guest <simon.guest@tesujimath.org>wrote:
> Hi,
>
> I'm making my first real Org mode Beamer presentation, using org-mode
> 7.01g, and trying to set the ignore_heading for a multi-column slide.
>
> In column mode, when I hit 'e' in the Env column, Emacs says:
> Wrong type argument: commandp, org-beamer-set-environment-tag
> (and org-beamer-set-environment-tag does not appear to be defined
> anywhere).
>
> It's triggered from this code in org-colview.el
> ((equal key "BEAMER_env")
> (setq eval '(org-with-point-at pom
> (call-interactively 'org-beamer-set-environment-tag))))
>
> Any idea what's wrong?
>
>
This function was renamed to org-beamer-select-environment and I think it
was not changed here.
The attached patch should solve the problem.
* lisp/org-colview.el
Use org-beamer-select-environment instead
of org-beamer-set-environment-tag
Thanks and Regards
Noorul
Nick Dokos <nicholas.dokos@hp.com> wrote:
> John Hendy <jw.hendy@gmail.com> wrote:
>
> > Just to be sure I created an blank org file with only this:
> >
> > * test
> >
> > #+CAPTION: test table
> > #+ATTR_LaTeX: placement=[H]
> > | 1 | 2 | 3 | 4 |
> > |------+------+------+------|
> > | test | test | test | test |
> > | test | test | test | test |
> >
> > It gets exported to this:
> >
> > \begin{table}[htb]
> > \caption{test table}
> > \begin{center}
> > \begin{tabular}{llll}
> >
> > Did something change between 6.35 and 7.01 or in the LaTeX table options?
> >
>
> I think that placement works fine for figures, but not for tables. In
> fact, I cannot find the code that's supposed to do this for tables: I
> suspect that it never existed. So unless I'm mistaken, it seems that
> tables never got the placement treatment that figures did.
>
Try the following patch (might be wrong in detail, and its scope might
be too limited, but I hope it's not too far off: at least it seems to
work on your simple table.) It may also be white-space damaged, so some
reformatting may be needed after applying it.
Nick
>From 4c8cdde9f3d80edc882efe83562a934fd9a6a8c8 Mon Sep 17 00:00:00 2001
From: Nick Dokos <nicholas.dokos@hp.com>
Date: Fri, 23 Jul 2010 17:54:06 -0400
Subject: [PATCH] Process latex placement attribute for tables.
Figures got placement attributes previously, but tables never did.
David Maus <dmaus@ictsoc.de> writes:
Hi David,
>>I'm trying to add a workaround to org-gnus.el which should save the
>>slowness of querying the IMAP server by looking up the article number
>>in the group's .overview file. But since I don't have nnimap groups,
>>we have to play some question & answer game. ;-)
>
>>Please apply this patch and set
>>`org-gnus-nnimap-query-article-no-from-file' to t.
>
> The patch does not work: It calls `nnimap-retrieve-headers-from-file'
> without the required arguments (group server)
Argh, stupid me! Here's a corrected patch.
--8<---------------cut here---------------start------------->8---
--8<---------------cut here---------------end--------------->8---
> and the headers are not fetched because
> `nnimap-retrieve-headers-from-file' looks for a NOV cache file, not
> .overview.
Aren't overview file and NOV file synonyms?
Hm, anyway. In the Gnus docs I've found this paragraph:
,----[ (info "(gnus)IMAP") ]
| `nnimap-nov-is-evil'
| Never generate or use a local NOV database. Defaults to the value
| of `gnus-agent'.
|
| Using a NOV database usually makes header fetching much faster,
| but it uses the `UID SEARCH UID' command, which is very slow on
| some servers (notably some versions of Courier). Since the Gnus
| Agent caches the information in the NOV database without using the
| slow command, this variable defaults to true if the Agent is in
| use, and false otherwise.
`----
So maybe we're trying to replace one slow command with another slow
command. Especially, the fact that Courier is explicitly mentioned is a
bit frustrating. Well, let's try it out and see if it helps a bit.
> Alas: I couldn't figure out how to enable NOV cache for my nnimap
> group. Setting `nnimap-nov-is-evil' to nil didn't help.
This variable defaults to the value of `gnus-agent', so I assume the
agent has to be enabled (which is default), and most probably the IMAP
server has to be agentized as well. That can be done in the server
buffer (`^' in *Group*), and then:
,----[ (info "(gnus)Server Agent Commands") ]
| `J a'
| Add the current server to the list of servers covered by the Gnus
| Agent (`gnus-agent-add-server').
`----
Bye,
Tassilo
* lisp/org.el (org-insert-time-stamp): Fix org-insert-time-stamp so
that the value of org-last-inserted-timestamp includes time range.
Previously, org-last-inserted-timestamp included only the
beginning of a time range (e.g., 10:00 instead of 10:00-12:00).
This caused parsing problems elsewhere, such as when rescheduling
items with repeating timestamps and a time range (the repeater
was removed during rescheduling).
* org-wl.el (org-wl-store-link-message): Provide link property
for message-id without angle brackets.
The message-id header field can be used to maintain the connection
between an Org entry and an internet message. The angle brackets have
a special meaning when performing a TAGS/PROPS/TODO query (Cf. Org
mode manual 10.3.3). To be able to use the message-id as an entry
property we have to remove the angle brackets to be able to perform a
search for the entry associated with a particular message.
Thanks to Ethan Ligon for pointing this out
* contrib/lisp/org-mime.el (org-mime-org-buffer-htmlize): fixed major
error -- was exporting entire as text/plain mime part, now when
region is active, only that region is exported
* lisp/ob-tangle.el (org-babel-find-file-noselect-refresh): finds a
file ensuing that the latest changes on disk are represented
(org-babel-with-temp-filebuffer): now only kills the buffer of the
tangled file, and doesn't kill said buffer if the file is already
being visited
* lisp/org-capture.el (org-capture-finalize): Fix clock in of interrupted
task during capture finalize
Calling org-capture-get inside the org-with-point-at macro does not
work when the current clocking task and the capture target buffer are
the same. In this case the captured task would continue clocking
instead of switching back to the previously clocking task.
Carsten Dominik
Dan Davison
Bastien Guerry
Eric Schulte
Juan Pechiar
Nicolas Goaziou
Noorul Islam
Nick Dokos
Tassilo Horn
Matt Lundin
David Maus
John Wiegley
Bernt Hansen