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
Org-publish: correctly find files in projects which didn't define a base-extension.
Previously, (org-publish-get-project-from-filename "~/org/file.org") would return nil because the constructed regular expression "^/home/dc/org/.+\\.\\(\\)$" required a dot at the end.
#+BEGIN_QUOTE
#+END_QUOTE
* lisp/org-publish.el (org-publish-write-cache-file):
Write a serialized version of the cache hash.
(org-publish-initialize-cache): Reset the cache hash before creating a
new one.Serialize publishing project cache with `puthash' expressions.
Carsten Dominik <carsten.dominik@gmail.com> writes:
> Hi Sebastian,
>
> sorry for being slow. Could you do me a favor and send me the cache patch one
> more time - if possible updated to the current master.
>
> I am just not sure I have the right patch in my hands.
Hi Carsten,
no problem. The patch is attached.
Here is a list of my ChangeLog entries, redated to today:
2010-05-13 Sebastian Rose <sebastian_rose@gmx.de>
* org-publish.el (org-publish-cache): Use one big hashmap for
each project defined in `org-publish-project-alist'. The
hashmap will hold pairs of our timestamp-filenames and
timestamps, as well as pairs of source-paths and associated
plists for arbitrary values. Currently only the files title is
stored there.
The caching feature writes the information gathered during
publishing to disk and re-loads it from there the next time we
publish the same project. All those informations will hence
survive a restart of emacs.
One cache file per publishing project is used. The contents of
that file is the elisp that fills the new variable
`org-publish-cache'. The cache file is named according to the
project with `.cache' added and lives in
`org-timestamp-directory'.
* org-publish.el (initialize-files-alist): This function and
the variable `org-publish-files-alist' are not used anymore in
favour of the reloadable cache and the functions for handling
it. Removed therefor.
* org-publish.el (org-publish-validate-link) was not used
anywhere. Removed.
* org-publish.el (org-publish-get-base-files): Added the
variable `sitemap-requested' to avoid sorting where possible.
See also end of `org-publish-get-base-files-1'.
* org-publish.el (org-publish-get-files): This function is
not called anymore. Removed.
* org-publish.el (org-publish-get-project-from-filename) does
not depend on a list of files anymore. Instead of laoding all
files of all, we walk `org-publish-project-alist' until we
find a project, where the properties :base-directory, :recursive,
:base-extension, :include and :exclude match.
* org-publish.el (org-publish-file) takes an additional
parameter to avoid superfloues loading and writing of the
cache file when used to publish a part of a project.