* org.el (org-structure-template-alist): Use uppercase for
keywords.
* org-publish.el (org-publish-index-generate-theindex): Use
uppercase for the #+INCLUDE keyword.
* org-publish.el (org-publish-index-generate-theindex): Use
theindex.inc for storing index entries, and theindex.org for
including theindex.inc.
Commit f0d7ac removed the theindex.inc and directly included
index entries in theindex.org. This is not as flexible as using
theindex.org as a page you want to manually edit, which can then
include theindex.inc with proper content.
Thanks to Stefan Vollmar for insisting about this issue.
Bastien <bzg@altern.org> writes:
Hi Bastien,
> The patch looks good but I'd like to understand it better.
> Can you send an example configuration working with your patch?
In org-publish-project-alist, i have HTML publishing projects which
should be published to different target directories depending on e.g.
where emacs is running (which i determine in my init files using the MAC
address of the default GW, the name the machine, ...).
Here is an example: At home, i publish to a local directory
(:publishing-directory "~/tmp/publish-test") but at work i would like to
publish directly to a webserver (:publishing-directory
"/plinkx:doxydoc:~/public_html/publish-test" - this is on w32, using
tramps PuTTY/plink). To avoid having to change the definition of the
publishing project when i change locations i would like to construct the
actual value of :publishing-directory by calling a function:
("publishing-dir-test"
:base-directory "~/Documents/Work/RS"
:recursive t
:base-extension "org"
:exclude-tags ("intern")
:publishing-directory '(expand-file-name "publish-test" kt:org-default-publishing-dir)
:publishing-function org-publish-org-to-html)
Depending on the location i'm in, 'kt:org-default-publishing-dir' would
be set to either "~/tmp" or "/plinkx:doxydoc:~/public_html". Without the
patch, the example above does not work as the value of
:publishing-directory does not get evaluated.
> Also, please try to send git patch using these conventions:
> http://orgmode.org/worg/org-contribute.html#sec-5
>
> Thanks a lot!
Thanks for the hint. I've attached a revised version of the patch which
includes a changelog/commit msg - i hope that works for you.
Publish: allow dynamic construction of the publish destination.
* org-publish.el (org-publish-file): Added 'eval'ing the value of the
:publishing-directory property before using it as destination of the
publishing project. This allows to construct the publish destination
directory dynamically at run-time using the return value of a
function.
TINYCHANGE
Also remove blank lines before the ";;; org*el ends here" declarations.
Having a "Version" header forced us to update every file when releasing a
new version of Org; it also forced us to update every file when merging Org
with Emacs trunk, thus cluttering the diffs between the previously merged
version and the new one with useless information.
Glenn Morris suggested this in emacs-devel:
http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00322.html
Deleting .orgx files is an error -- thanks to Carsten for pointing
at this. Instead, we "hide" them by using dotted files: .file.orgx.
Also, use theindex.org directly instead of including theindex.inc in
theindex.org. This prevents a bug about republication of theindex.org
being skipped because the file has not been updated.
* org-publish.el (org-publish-index-generate-theindex): rename
from `org-publish-index-generate-theindex.inc'. Use the file
theindex.org directly instead of including theindex.inc.
(org-publish-projects): Don't delete .orgx files.
(org-publish-aux-preprocess): Use .file.orgx.
Also add the org- prefix to some variable.
* org-publish.el (org-publish-find-title): bugfix: kill
buffers unless they were already visited.
(org-sitemap-sort-files, org-sitemap-sort-folders)
(org-sitemap-ignore-case, org-sitemap-requested)
(org-sitemap-date-format, org-sitemap-file-entry-format): use
a correct prefix.
(org-publish-projects): Make sure to delete .orgx files.
(org-publish-index-generate-theindex.inc): Small docstring
fix.
* install/git/org-mode/lisp/org-publish.el
(org-publish-cache-file-needs-publishing): Takes care of more
recently included files, returning `t' in case the file including
them needs to be republished.
* org-publish.el (org-publish-cache-ctime-of-src): Properly handle
relative symlinks.
At Thu, 07 Apr 2011 01:11:00 -0400,
Nick Dokos wrote:
>
> org-publish-cache-ctime-of-src tries (but does not always succeed) to
> deal with symlinks: file-symlink-p returns the target as a string, but
> if the target is relative to the symlink, that's not going to fly.
> e.g. if c is a symlink like this
>
> /a/b/c->../d/f
>
> then (file-symlink-p "/a/b/c") -> "../d/f"
> but if the current directory is any place other than /a/b, the target
> will not be found, the file attributes are going to be nil and
> the function will blow up.
* lisp/org-publish.el (org-publish-project-alist): Document new
:sitemap-sans-extension property.
(org-publish-org-sitemap): Use new sitemap-sans-extension setting.
The following patch adds an option to remove extensions of files linked
from the auto generated sitemap. This is useful if you want to follow
this: http://www.w3.org/Provider/Style/URI
* org-special-blocks.el
(org-special-blocks-make-special-cookies): Use
`org-export-current-backend'.
* org-publish.el (org-publish-aux-preprocess): Use
`org-export-current-backend'.
* org-inlinetask.el (org-inlinetask-export-handler): Use
`org-export-current-backend'.
* org-exp.el (org-export-current-backend): New variable.
(org-export-preprocess-string)
(org-export-format-drawer-function)
(org-export-remove-or-extract-drawers)
(org-export-format-drawer)
(org-export-convert-protected-spaces)
(org-export-select-backend-specific-text)
(org-export-mark-list-end, org-export-mark-list-properties)
(org-export-attach-captions-and-attributes)
(org-export-replace-src-segments-and-examples)
(org-export-format-source-code-or-example)
(org-export-number-lines): Use the new global variable instead
of a local variable.
* org-exp-blocks.el (org-export-blocks-format-ditaa)
(org-export-blocks-format-dot)
(org-export-blocks-format-comment): Use
`org-export-current-backend'.
* org-publish.el (org-publish-cache-ctime-of-src): improve
docstring.
(org-publish-find-title): New option to explicitly reset the
title in the cache.
(org-publish-format-file-entry): Use this new option.
Thanks to Jonathan Bisson for reporting this.
Hi,
Here's a patch that make the sitemap entry formating coherent with the
new html-pre/postamble one.
While here I was trying to add some documentation about this feature in
org.texi but I end up copy/pasting or paraphrasing the docstring of
correspondant customs. Is it acceptable for the documentation or plain
useless?
>From 766b0db7d0189d2edb0d8799c3424d62f9ac4e47 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel.giraud@univ-nantes.fr>
Date: Fri, 11 Feb 2011 15:32:58 +0100
Subject: [PATCH] org-publish.el: sitemap formating coherent with new preamble
Adopt downcase for format directive to be coherent with the new
pre/postamble formating.
Use `format-spec' function instead of `org-replace-escapes'.
* org-html.el (org-export-html-auto-preamble)
(org-export-html-auto-postamble): Remove.
(org-export-html-preamble, org-export-html-postamble): Turn
into custom variables. Update the docstrings.
(org-export-html-preamble-format)
(org-export-html-postamble-format): New custom variables.
(org-export-as-html): Use org-export-html-postamble-format and
org-export-html-preamble-format.
(org-export-html-title-format): delete.
* org-exp.el (org-export-plist-vars): Remove
:auto-preamble and :auto-postamble. Rename :preamble and
:postamble to :html-preamble and :html-postamble.
* org-publish.el (org-publish-project-alist): Remove
:auto-preamble and :auto-postamble. Rename :preamble and
:postamble to :html-preamble and :html-postamble.
* org.texi (Publishing options): replace :preamble and
:auto-preamble by :html-preamble (same for postamble.)
* org-publish.el (org-publish-sitemap-date-format)
(org-publish-sitemap-file-entry-format): new custom variables.
(org-publish-projects): use these variables to format the
sitemap entries.
This patch adds sort options to the sitemap. In addition to
alphabetical order, one can choose chronological or anti-chronological
ordering of sitemap entries. To retrieve file date, it tries to parse
the "#+date" keyword and if not present defaults to file modification
time.
* lisp/org-publish.el (org-publish-get-base-files): Add sitemap file.
I noticed some wonkiness in getting my sitemap created on my webserver
when pushing my website, and the problem seems to lie in
org-publish-get-base-files only returning existing files, and not
picking up on the soon to be generated sitemap. My patch always adds
the sitemap file to the list of returned files if a sitemap is
requested, regardless of if it exists or not.
* lisp/org-publish.el (org-publish-org-to-ascii):
(org-publish-org-to-latin1):
(org-publish-org-to-utf8): New functions.
* doc/org.texi (Publishing action): Document the new publishing functions.
Thanks to Matthias Danzl for showing how to do this.
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