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
On Wed, Sep 8, 2010 at 2:12 AM, Daniel Clemente <n142857@gmail.com> wrote:
>
> Commit bd1b57f92a broke the exporting
> of [[file:a.org]] links, which now appear as [[http:a.html]]. Try
> C-c C-e H on any .org with such links, even in emacs -Q.
>
> The problem is, I think, that „type“ is actually "http", not "file"
> as the code tries.
>
* lisp/org-html.el (org-html-cvt-org-as-html): Do not convert protocol
from 'file' to 'http'.
TINYCHANGE
* org.el (org-skip-over-state-notes): do not compute bottom point at
each item.
* org-mouse.el (org-mouse-for-each-item): use `org-apply-on-list'
instead of moving to each item.
* org.el (org-priority): Save match data before call to
`read-char-exclusive'.
Otherwise interactively calling `org-priority' with org-indent-mode
enabled fails to set a new priority cookie.
Bug reported by Joseph Buchignani.
* org.el (org-store-log-note): Indent new notes to the right column.
Also take `org-list-two-spaces-after-bullet-regexp' into
consideration when creating the note.
* org-gnus.el (org-gnus-nnimap-query-article-no-from-file): New
customization variable.
(org-gnus-nnimap-cached-article-number): New function.
(org-gnus-follow-link): Try to fetch cached article number of
message-id.
Some IMAP servers (e.g. Courier) are slow when searching for a message
by its message id header field. Because article numbers in IMAP
mailboxes are persistent UIDs, we can try to look up the UID of a IMAP
message in Gnus' cache for the mailbox in question and skip the slow
search on the server.
The problem with slow server was reported by Sébastien Vauban and the
patch is based on the work of Tassilo Horn.
Eric Schulte
David Maus
Bastien Guerry
Nicolas Goaziou
Carsten Dominik
Sebastian Rose
Harri Kiiskinen
Dan Davison
Jambunathan K
Matt Lundin
Rémi Vanicat
Achim Gratz
Noorul Islam
aaa bbb