Patch by Christian Moe, who writes:
> It looks like support for formatting custom link types in LaTeX export
> is broken?
>
> I was trying to implement a custom link type with its own formatting
> function for HTML and LaTeX export, following the steps in
> org-bbdb.el.
>
> I've found that org-bbdb-export does not italicize bbdb links in
> LaTeX, nor does my own org-cite-export turn my custom =cite:= links
> into LaTeX =\cite{}= citations. Everything works fine in HTML export,
> but in LaTeX all custom link types get formatted as =\texttt{descr}=.
>
> I see that org-export-as-html and org-export-as-docbook look up
> org-link-protocols to get the function for formatting the link, but it
> seems that org-export-as-latex doesn't.
>
>
Karl Eichwalder writes:
> Consider the following two files:
>
> * 2009
> #+TBLNAME: 2009
> :PROPERTIES:
> :ID: ea32e5b5-31ba-468e-8e31-3e0d09696bb0
> :END:
> |-----+-------|
> | mm | km |
> |-----+-------|
> | all | 946.8 |
> |-----+-------|
>
> * 2010
> #+TBLNAME: 2010
> :PROPERTIES:
> :ID: e0df84c4-8abc-458f-a1ee-eb53eb71b4f0
> :END:
> |-----+-------+-------+-------|
> | mm | km | B km | G km |
> |-----+-------+-------+-------|
> | all | 249.4 | 429.2 | 678.6 |
> |-----+-------+-------+-------|
>
> * all
> :PROPERTIES:
> :ID: 44751a7f-73a4-4c07-b3c2-e3edb9042acd
> :END:
> #+TBLNAME: all
> |------+--------|
> | yyyy | km |
> |------+--------|
> | 2009 | |
> | 2010 | 678.6 |
> |------+--------|
> | all | 1625.4 |
> |------+--------|
> #+TBLFM: @2$2=remote(ea32e5b5-31ba-468e-8e31-3e0d09696bb0,$LR2);%.1f::@3$2=remote(2010,$LR4);%.1f::$LR2=vsum(@2$2..@-1);%.1f
>
> Then, in the 2010 file, eval the formula of the "all" table by pressing
> C-c C-c.
> ==>
>
> It takes the km value from the 2009 file, but also puts the cursor
> (point) into the 2009 file in front of the ID:
>
> * 2009
> #+TBLNAME: 2009
> :PROPERTIES:
> :ID: -!-ea32e5b5-31ba-468e-8e31-3e0d09696bb0
> :END:
> |-----+-------|
> | mm | km |
> |-----+-------|
> | all | 946.8 |
> |-----+-------|
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> I'd prefer if the point would stay in the 2010 file.
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.
Sebastien Rose writes:
> there was much discussion about a terminator and I ran into a problem,
> that made me think we need one. But then I found we had one --- it's
> just not used on HTML export.
>
>
> Below is a little file I wrote. Thanks to the `- __' items, it results
> in the XHTML closely to what I wanted it to.
> But only as long as I use those _undocumented_ `- __' items. Once you
> remove them, you'll see, that the `#+html: </div...' stuff ends up
> inside the last list item and the XHTML will not validate.
>
>
> As I looked at it, I found the most natural solution would be, to
> terminate the list by regarding the indentation of `#+WHATEVER' and
> `#+BEGIN_WHATEVER' if inside lists [fn:1].
>
>
>
> The patch below (diffed against `remove-compatibility-code') makes
> XHTML-export honor the indentation of `#+SPECIALS'.
>
>
>
> Here's the Org-file I wrote (remove and add the `- __' list items to see
> the effect):
>
> #+OPTIONS: toc:nil
> #+STYLE: <style type="text/css">
> #+STYLE: body,p,div,td{font-size:13px;font-family:sans-serif;}
> #+STYLE: div { text-align:left; }
> #+STYLE: #content {width:550px;
> #+STYLE: margin-left:auto;margin-right:auto;text-align:center; }
> #+STYLE: #postamble { width:550px;clear:both;border-top:1px solid black;
> #+STYLE: margin-left:auto;margin-right:auto;text-align:center; }
> #+STYLE: </style>
>
> * List of design patterns
>
> #+HTML: <div style="width:48%;float:left;">
> *Behavioural Patterns*
> - [[file:BatchCommand][BatchCommand]]
> - [[file:ChainOfResponsibility.org][Chain Of Responsibility]]
> - [[file:Command.org][Command]], UndoableCommand and BatchCommand
> - [[file:Interpreter.org][Interpreter]]
> - [[file:Iterator.org][Iterator]]
> - [[file:Mediator.org][Mediator]]
> - [[file:Memento.org][Memento]]
> - [[file:NullObject][NullObject]]
> - [[file:Observer.org][Observer]]
> - [[file:State.org][State]]
> - [[file:Strategy.org][Strategy]]
> - [[file:TemplateMethod.org][Template Method]]
> - [[file:Visitor.org][Visitor]]
> *Creational Patterns*
> - [[file:AbstractFactory.org][Abstract Factory]]
> - [[file:Builder.org][Builder]]
> - [[file:Factory.org][Factory]]
> - [[file:FactoryMethod.org][Factory Method]]
> - [[file:Prototype.org][Prototype]]
> - [[file:Singleton.org][Singleton]]
> - __
> #+html: </div>
> #+html: <div style="width:48%;float:right;">
> *Structural Patterns*
> - [[file:Adapter.org][Adapter]]
> - [[file:Composite.org][Composite]]
> - [[file::Bridge.org][Bridge]]
> - [[file:Decorator.org][Decorator]]
> - [[file:Facade.org][Facade]]
> - [[file:Flyweight.org][Flyweight]]
> - [[file:Proxy.org][Proxy]]
> *Unsorted*
> - [[file:BusinessDelegate.org][Business Delegate]]
> - [[file:DataAccessObject.org][Data Access Object]]
> - [[file:DataTransferObject.org][Data Transfer Object]]
> - [[file:DependencyInjection.org][Dependency Injection]]
> - [[file:FluentInterface.org][Fluent Interface]]
> - [[file:InversionOfControl.org][Inversion Of Control]]
> - [[file:ModelViewControler.org][Model View Controler]]
> - [[file:ModelViewPresenter.org][Model View Presenter]]
> - [[file:Plugin.org][Plugin]]
> - __
> #+HTML: </div>
Jan Bcker writes:
> If you have a headline with an elisp code block containing the following
> line:
>
> " :ID:"
>
> the HTML code will be garbled at the beginning of the headline.
>
> I have attached a minimal test case and the resulting HTML file. The
> #+OPTIONS: line is not needed, but is included to make the HTML file
> less cluttered.
>
> There has to be whitespace between the " and :ID: and the string must be
> ended on the same line. For example, these lines trigger the bug:
>
> " :ID:"
> " :ID:"
> " :ID: garble-my-html"
>
> while these do not:
>
> ":ID:"
> ":ID: garble-my-html"
> " :ID:
>
The definition of "makes sense is here:
- either the user is logging repeats (org-log-repeat)
- or the entry contains clock data, in which case the LAST_REPEAT is
needed to display clocking time properly.
Request by Dan Griswold, with some support from Bernt Hansen
Patch by Peter Jones, following a bug report by Xiao-Jong Jin, who wrote:
> If you have the follow org file
>
> * test crypt :crypt:
> ** subheading 1
> text 1
> ** subheading 2
> text 2
>
> with setup as
>
> (require 'org-crypt)
> (setq org-tags-exclude-from-inheritance '("crypt"))
> (setq org-crypt-key "CBC0714E") ; my key
>
> On calling org-encrypt-entry on the first head line, only
> subheading 1 get encrypted, subheading 2 remains plain text.
> But, if you add an empty line or some text under the first
> heading, both subheading 1 and 2 are encrypted.
By David Maus.
The gist of the extended capabilities:
- Remove filter conditions for messages in a filter folder
If customization variable `org-wl-link-remove-filter' is non-nil,
filter conditions are stripped of the folder name.
- Create web links for messages in a Shimbun folder
If customization variable `org-wl-shimbun-prefer-web-links' is
non-nil, calling `org-store-link' on a Shimbun message creates a
web link to the messages source, indicated in the Xref: header
field.
- Create web links for messages in a nntp folder
If customization variable `org-wl-nntp-prefer-web-links' is
non-nil, calling `org-store-link' on a nntp message creates a web
link either to gmane.org if the group can be read trough gmane or
to googlegroups otherwise. In both cases the message-id is used as
reference.
- Open links in namazu search folder
If `org-wl-open' is called with one prefix, WL opens a namazu
search folder for message's message-id using
`org-wl-namazu-default-index' as search index. If this variable is
nil or `org-wl-open' is called with two prefixes Org asks for the
search index to use.
Regards,
-- David
Conflicts:
lisp/ChangeLog
The target state can now be fixed locally with the REPEAT_TO_STATE
property, or globally with the variable `org-todo-repeat-to-state'.
This was a request by John Wiegley.
Carsten Dominik
David Maus
Dan Davison
Bastien Guerry
Jan Böcker