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, 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.
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.
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
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.
By default, title, author, date and email lines appear in dark blue
with the initial keywords greyed out. The title is in a larger font
than the others. This is implemented by the following new faces:
org-document-title
org-document-info
org-document-info-keyword
In addition, the variable org-hidden-keywords can be used to make the
corresponding keywords disappear.
Magnus Henoch writes:
> This patch has been sitting in my tree for a while... It's a fix to
> org-map-dblocks, to make it use save-excursion instead of remembering
> position values. I need this since I have a dblock function that
> asynchronously updates dblocks from HTTP responses, and some dblocks
> ended up getting updated twice or thrice.
[...]
> My dblock-write function calls url-retrieve, to asynchronously retrieve an
> HTML page. The callback function I pass to url-retrieve will then fill
> in the information I need into the dynamic block.
>
> So in the following case:
>
> * Find start of dblock 1, store as pos
> * Make HTTP request for dblock 1
> * Go back to pos
> * Find end of dblock 1
> * Find start of dblock 2, store as pos
> * Make HTTP request for dblock 2
> * Asynchronous event: HTTP response for dblock 1 arrives, insert lots of
> data in dblock 1
> * Go back to pos
> * Find end of dblock 2
>
> the last step will actually find the end of dblock 1, if the amount of
> data inserted in dblock 1 is great enough that pos suddenly points
> inside it. (Then it will of course find dblock 2 again, request its HTML
> page again, and thus insert the data twice.)
>
> An equivalent fix would be to make pos a marker instead.
Ryan Thompson writes:
> I have found a bug. When the point is at the end of an empty headline
> and you press M-RET (or C-RET) to make a new headline, it deletes all
> the whitespace at the end of the empty headline first, which causes
> the headline to break. I'm not sure if the correct behavior is to
> leave an empty headline, or maybe just do nothing and leave the point
> at the end of the empty headline without creating a new one, but the
> correct thing is definitely *not* to break the headline.
Patch by Jan Böker.
Jan writes:
> What is this?
> =============
>
> This patch changes the way extension regexps in `org-file-apps' are
> handled. Instead of against the file name, the regexps are now matched
> against the whole link, and you can use grouping to extract link
> parameters which you can then use in a command string to be executed.
>
> For example, to allow linking to PDF files using the syntax
> file:/doc.pdf::<page number>, you can add the following entry to
> org-file-apps:
>
> Extension: \.pdf::\([0-9]+\)\'
> Command: evince "%s" -p %1
>
> In a command string to be executed, the parameters can be referenced
> using %1, %2, etc. Lisp forms can access them using (string-match n link).
>
>
> Where to get it?
> ================
> Either apply the patch by hand or
>
> git pull git://github.com/jboecker/org-mode.git org-file-apps-parameters
>
>
> What's next? / Feedback
> =======================
>
> - Find the bugs. Since this messes with links, a central concept of Org,
> I probably have missed some edge cases; so please test this and
> report if it works for you.
>
> I also appreciate any feedback on code quality or the design decisions
> made. I am learning elisp along the way, so you may be able to write
> some changes in a more idiomatic and/or elegant way.
>
> - Add a mechanism for org-mode modules to add default values to
> org-file-apps, similar to the variables org-file-apps-defaults-*.
> This could be used by modules to define their own extensions to the
> syntax of file: links.
>
> - Modify org-docview.el to use this and deprecate the docview: link syntax.
>
>
> What does it (intentionally) break?
> ===================================
>
> This patch introduces a backwards-incompatible change. If LINE or SEARCH
> is given, the file is no longer guaranteed to open in emacs: if IN-EMACS
> is nil and an entry in org-file-apps matches, that takes precedence.
>
> A grep of the lisp/ and contrib/ directories showed that no code in the
> org-mode distribution was relying on this behaviour; whereever LINE or
> SEARCH is given, IN-EMACS is also set to t.
>
> I decided against adding an additional parameter because that would be
> redundant; the original link as seen by org-open-at-point can be
> reconstructed from PATH, LINE and SEARCH.
>
> I am not that sure if this is the right way to do this, but it seems to
> break as little as possible while hopefully avoiding to add too much
> complexity.
