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.
* lisp/org-agenda.el (org-agenda-filter-preset): Document the limitation
for the filter preset - it can only be used for an entire agenda view,
not in an individual block in a block agenda.
* doc/org.texi (Agenda commands): Document the limitation
for the filter preset - it can only be used for an entire agenda view,
not in an individual block in a block agenda.
* lisp/org-exp.el (org-export-format-source-code-or-example): escape
underscores in code block names on latex listings export
* lisp/org-latex.el (org-export-latex-listings-w-names): make export
of code block names to latex optional
* lisp/org-capture.el (org-capture-target-buffer): Throw an error
if we have no target file.
(org-capture-select-template): Use a default template if the user has
not specified any.