Baoqui Cui writes:
> "robut@iinet.net.au" <robut@iinet.net.au> writes:
>
> I very much like the idea of native inline image display in Org-mode but can't
> seem to make it work.
>
> Given a 6.36 snapshot or 6.36 release and these org file contents
>
> * Test image
> Test image
> [[Screenshot.png]]
>
>
> I hoped org would display that image after C-c C-x C-v. Rather Org-mode returns
> "No images to display inline".
>
> I've tried different ways of linking that image, different image formats,
> relative vs complete paths, and my regular .emacs vs a near empty one and
> always the same result. If I toggle iimage-mode the image displays fine per se
> but does not affect how Org-mode works.
>
> Seems clear I am missing something simple. What?
>
> I like the idea of inline image display too, but hit the similar
> problems. After reading the code in org.el, I found that the inline
> image file link has to start with either "file:" or "./".
>
> For example, the following two links are OK:
>
> [[file:~/images/myImage.png]]
> [[./figures/org-mode-unicorn.svg]]
>
> but the following two are not:
>
> [[Screenshot.png]]
> [[~/images/myImage.png]]
>
> Here is a small patch that seems to work well for me, but I'd like
> Carsten to check whether it may break anything
Patch by David Maus:
> 1. Store and open link to Wanderlust folders.
>
> 2. Store link to Wanderlust message while visiting the message
> buffer.
>
> Up to now it was only possible to store a link to a message when
> point was in the message summary.
Patch by David Maus, who writes:
> Org enters an infinite loop when `org-replace-escapes' is called with
> a table containing a replace string that contains the escape sequence
> it should be replaced with.
>
> Example:
> ,----
> | (org-replace-escapes "%m" '(("%m" . "87zl0qq1f3.wl%maus.david@gmail.com")))
> `----
>
> I stumpled upon when I tried to store a link to a internet message
> whose message id contained the sequence "%m" (perfectly valid for a
> message id) while using "%m" as message description.
>
> Attached patch fixes this by
>
> 1. detecting such 'self reference' and replacing the offending
> sequence in the replace string by a string with a text property
> that contains the original sequence
>
> 2. replacing occurences of substrings with this text property by the
> original sequence.
Patch by Stephen Peters.
Stephen writes:
> When creating a table, I was noticing that the
> <colgroup><col>... provides useful alignment information based on
> whether or not the column has numbers in it. I think, however, that
> there is a mistake in this routine. Take, for example, the following
> table:
>
> | Id | Task | Developer | Estimate | Spent | Remaining | Comp.% | Updated |
> |-----+--------------+-----------+----------+-------+-----------+--------+-----------------|
> | 1 | Task One | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 2 | Task Two | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 3 | Task Three | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 4 | Task Four | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 5 | Task Five | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 5.1 | Another Task | XML team | 0 | 1 | 0 | 0 | SLP, 2010-04-27 |
> | 6 | Task Six | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 6.1 | More Tasks | DB team | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
> | 7 | Task Seven | SLP | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
>
> When the colgroup list is created for this table, it reads:
>
> <colgroup><col align="right" /><col align="left" /><col align="left" /><col align="right" /><col align="right" /><col align="left" /><col align="left" /><col align="left" />
> </colgroup>
>
> Note that the first columns are correct, but the last few are not. It
> should read right, left, left, right, right, right, right, left.
>
> I believe that this is due to the (< i nline) comparison within
> org-format-org-table-html, which is nonsensical because it's trying to
> compare a column number with a number of rows. I've attached a patch
> for the problem.
Willian Henney writes:
> The following is using today's git trunk of org-mode with emacs
> 23.1.94.1 (aquamacs 2.0preview5)
>
> Consider the following table
>
> | -8 |
> | |
> | |
> | |
> #+TBLFM: $1=@-1 - 1::@1$1=-8
>
> Evaluate formulas once (C-u C-c *):
>
> | -8 |
> | -9 |
> |----|
> | -1 |
>
> Evaluate formulas again (C-u C-c *):
>
> | -8 |
> | -9 |
> |----|
> |----|
>
> What I expected:
>
> | -8 |
> | -9 |
> | -10 |
> | -11 |
>
> The problem always seems to start at -10. When I turn on table
> debugging, it first calculates the -10 value correctly, but then fails
> to recognise the -10 cell as a number when calculating the next row,
> using 0 instead, which results in -1. This is because during the
> intermediate formatting of the cell the minus sign in -10 abuts the
> column separator: "|-10 |", and the "|-" part is then interpreted as
> the beginning of an hline.
Adam Elliott writes:
> I have attached a git patch against master that implements a new
> parameter to clock tables, "tags". This parameter is a tags-query as a
> string and is used to filter the headlines which are consulted when
> building the clock table.
>
> In my search of the archives to see if this feature already existed, I
> found a reference here:
> http://article.gmane.org/gmane.emacs.orgmode/17304
> suggesting it was difficult. The patch is not so large, though, so
> perhaps I am missing something.
>
> My rationale in implementing this feature was to keep track of the
> occasional task item that is not billable, yet still makes sense to
> include in the overall project structure. Of course I could just avoid
> clocking the task item, or manually delete clock lines before generating
> a report, but this feature reduces the chance for error; no doubt there
> are other workflows enabled with this feature as well. I don't make
> significant use of tags myself, but I know many do.
>
> In order to maintain a sensible report, headlines that don't match the
> tag filter may be included if they have descendants that do. Any time
> clocked directly on non-matching headlines, however, is excluded.
>
> Specifying even a simple filter noticeably slows down clock table
> generation for non-toy reports, particularly for clock table reports
> with :step. If there is no filter, though, there is no degradation in
> performance.
>
> Tag filter syntax is the standard one, as described at:
> http://orgmode.org/manual/Matching-tags-and-properties.html
> Only tags are considered at the moment, although I suspect querying
> against all properties would be possible (if even slower).
>
> Examples:
>
> * development
> CLOCK: => 1:00
> *** task 1
> CLOCK: => 1:00
> *** task 2 :must:
> ***** task 2a
> CLOCK: => 1:00
> ***** task 2b :mustnot:
> CLOCK: => 1:00
>
> Note I am using an unconventional but legal(ish) clock format for
> brevity. Clock tables are also pruned to only relevant lines.
>
> [1] #+BEGIN: clocktable
> | | *Total time* | *4:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 4:00 | | |
> | 2 | task 1 | | 1:00 | |
> | 2 | task 2 | | 2:00 | |
> | 3 | task 2a | | | 1:00 |
> | 3 | task 2b | | | 1:00 |
>
> [2] #+BEGIN: clocktable :tags "must"
> | | *Total time* | *2:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 2:00 | | |
> | 2 | task 2 | | 2:00 | |
> | 3 | task 2a | | | 1:00 |
> | 3 | task 2b | | | 1:00 |
>
> [3] #+BEGIN: clocktable :tags "-mustnot"
> | | *Total time* | *3:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 3:00 | | |
> | 2 | task 1 | | 1:00 | |
> | 2 | task 2 | | 1:00 | |
> | 3 | task 2a | | | 1:00 |
>
> [4] #+BEGIN: clocktable :tags "must-mustnot"
> | | *Total time* | *1:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 1:00 | | |
> | 2 | task 2 | | 1:00 | |
> | 3 | task 2a | | | 1:00 |
>
> [5] #+BEGIN: clocktable :tags "must+mustnot"
> | | *Total time* | *1:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 1:00 | | |
> | 2 | task 2 | | 1:00 | |
> | 3 | task 2b | | | 1:00 |
>
> As you can see, in examples 2, 4, and 5, the time clocked on
> "development" itself is being removed. Example 2 illustrates the effect
> of tag inheritance.
>
> Adam
org-edit-src-code gains extra optional arguments `code' and
`edit-buffer-name'. If `code' is supplied, then this code forms the
contents of the edit buffer, which is made read-only. In this case,
the mechanisms for writing back to the org buffer on save are
disabled.
Optional argument `edit-buffer-name' allows a name for the edit buffer
to be supplied.
This behavior is now parallel to the treatment of outline nodes.
This commit also introduces another change. When an outline node or a
plain list item is folded by outline and contains hidden children,
M-left/right will refuse to act on this item. You must either open
the tree, or use the subtree commands M-S-left and M-S-right.
Based on a patch by Matti De Craene, but significantly modified after
a discussion involving Bernt Hansen and others.
Carsten Dominik
Dan Davison