* org-src.el (org-src-strip-leading-and-trailing-blank-lines):
New variable allowing prevention of automatic stripping of
leading and trailing blank lines when exiting edit buffer.
(org-edit-src-exit): Respect value of
`org-src-strip-leading-and-trailing-blank-lines'
(org-src-native-tab-command-maybe): Bind
`org-src-strip-leading-and-trailing-blank-lines' to nil during
this function.
Thanks to Richard Riley for the initial idea and implementation
* lisp/ob.el (org-babel-demarcate-block): interactive demarcation of
code blocks
* lisp/ob-keys.el (org-babel-key-bindings): key bindings for block
demarcation
* doc/orgcard.tex: documentation in the ref card
* org.el (org-link-types): Add 'message:' link type to default link
types.
Jules Bean wrote:
>The link-type "message" is one of the ones org handles by default, it
>is an explicit case in org-open-at-point, much like http and it is
>handled by the following code:
>((member type '("message"))
> (browse-url (concat type ":" path)))
>However it is not included in the default value of org-link-types:
>(defvar org-link-types '("http" "https" "ftp" "mailto" "file" "news"
> "shell" "elisp" "doi"))
>...and therefore it doesn't work when clicked/followed.
>Manually adding it to org-link-types makes it work correctly. For me,
>anyway.
* org-list.el (org-cycle-list-bullet): follow order of bullets
indicated in doc-string.
* org-list.el (org-list-bottom-point-with-indent): list is ended when
a line is less indented that the last item, not the less indented item.
* lisp/ob-exp.el (org-babel-exp-src-blocks): now switching back to the
original file before resolving code block parameters to ensure
headline and buffer wide parameters are taken into consideration
when only a narrowed portion of the file is exported
When republishing all from scratch with babel code evaluation turned on,
Changes_old.org could not be exported because #+STARTUP: indent returns
an error when run in Emacs 23.1.
Aidan Gauland <aidalgol@no8wireless.co.nz> writes:
> Sebastian Rose <sebastian_rose <at> gmx.de> writes:
>> did you revert the previous patch? The second patch was against master
>> again.
>
> I ran git reset --hard then applied the second patch.
>
>> I changed to a subdirectory of my :base-directory (here $BASE):
>>
>> $ cd ${BASE}/subdirectory
>> $ cp ~/images/first.jpg . # a simple image
>> $ ln -s ~/images/second.jpg # a link to an image
>> $ ln -s ~/images/screenshots/ # a link to a directory
>>
>> When exporting, I get this tree in :publishing-directory ($PUB):
>>
>> $PUB/
>> |-- subdirectory/
>> | |-- first.jpg
>> | |-- second.jpg
>> | `-- screenshots/
>> | |-- some.png
>> | `-- other.png
>>
>> which is what you expected, is that right?
>
> Yes, that's what I expected. What I'm getting is a little different.
>
> $PUB/
> `-- subdirectory/
> |-- screenshots/
> | `-- subdirectory/
> | `-- screenshots/
> | |-- other.png
> | `-- some.png
> `-- subdirectory/
> |-- first.jpg
> |-- second.jpg
>
> This is how the project is defined...
> (setq
> org-publish-project-alist
> '(("static"
> :base-directory "~/org-bug/"
> :publishing-directory "~/org-bug-pub/"
> :publishing-function org-publish-attachment
> :recursive t
> :base-extension "css\\|gz\\|bz\\|lzma\\|jpg\\|gif\\|png")))
>
> And published with this sexp.
> (org-publish "static")
>
> Perhaps the discrepancy between our setups is git commit (not sure if
> I'm using the right terms there)? git log shows
> 878d94b472 at the top of its output.
>
> Thanks for your help!
> --Aidan
Ahrrgh :)
I just pulled, because I couldn't find that commit.
That commit already includes the (obviously wrong) first patch...
Here's the patch that reverts the first attempt and applies the new
one. Hope this works :)
Sebastian
* lisp/org-publish.el (org-publish-attachment): Put the attachment
into the right directory.
Aidan Gauland <aidalgol@no8wireless.co.nz> writes:
> On Thu, Sep 16, 2010 at 12:40:34AM +0200, Sebastian Rose wrote:
>> Aidan Gauland <aidalgol@no8wireless.co.nz> writes:
>> > Sebastian Rose <sebastian_rose <at> gmx.de> writes:
>> >> It would be a bug.
>> >>
>> >> But I cannot reproduce it (current Org mode from git, emacs24).
>> >
>> > I just figured out why: I store all my images in ~/images/ and just
>> > have symbolic links to them in my Org website directory.
>> >
>> > Can you reproduce it now that you have this piece of information?
>>
>>
>> Ah, OK. That might be because of some call to
>>
>> (file-truename file...)
>>
>> or similar. `file-truename' removes symbolic links in filenames.
>>
>> Functions like this are called to make sure, the file is published only
>> if needed (i.e. the file has changed since last export).
>>
>> I'm not sure currently if it's clever to remove such calls (see
>> lisp/org-publish.el and search `file-truename').
>
> What if `file-truename' was used only to get the path of the actual
> file to copy, but the (relative) path of the link is used as the
> destination?
>
> --Aidan
Hi Aidan,
`org-publish-attachment' is wrong or called with wrong arguments.
This patch fixes it.
As always, there might be a better way to fix it,
but this way the function `org-publish-attachment' will work regardless
of parameters. Someone will always call this function with the wrong
`PUB-DIR' parameter...
Aidan, would like to apply the patch and verify it works for you?
Best wishes,
Sebastian
[My apologies, but I'm afraid my first attempt at this patch mistook a
necessary second check for redundancy. Here is an improved version.]
* lisp/org-agenda.el (org-prepare-agenda): If the agenda is called
from within the agenda via an elisp link, such as
[[elisp:(org-agenda-list)]], org-prepare-agenda erases the buffer of
the file containing the link, since that buffer is current during
org-prepare agenda (due to a with-current-buffer in
org-agenda-open-link). An additional test now ensures that the
agenda buffer is in fact current when the buffer is erased and local
variables for the agenda are set.
Example:
{{{property(id)}}}
Will insert the ID property of current subtree if the Org buffer is
exported.
* lisp/org-exp.el (org-infile-export-plist): Define property macro
TINYCHANGE
Define a new variable org-icalendar-use-UTC-date-time that when
non-nil make icalendar exporter to use UTC date-time for better
compatibility with some other software (as GCALDaemon).
* lisp/org-icalendar.el (org-icalendar-use-UTC-date-time): New option.
(org-ical-ts-to-string): Use UTC time when requested.
Hi,
The attached patch makes it clear when a language mode has thrown an
error. This can clear up confusion whether an error is originating from
Org-mode or form the language-mode in question.
Should this be committed?
Best -- Eric