Nicolas Goaziou <> writes:

> Hello,
> Thibault Marin <> writes:
>> I would like to generate a sitemap for a published website and use
>> it to extract
>> the last few entries in a specific folder to put on the main page.
>> The site structure looks like:
>> .
>> ├──
>> ├── posts
>> │   ├──
>> │   ├──
>> │   └──
>> ├── misc
>> │   ├──
>> │   └──
>> └──
>> In, I would have:
>> #+begin_src org
>> #+INCLUDE:*posts :lines "-10" :only-contents t
>> #+end_src
>> to include links to the 10 most recent pages in =posts= (I use
>> :sitemap-sort-files anti-chronologically in the project setup).  If I am not
>> missing anything, this requires the file to have a
>> =posts= heading,
>> but the `org-publish-org-sitemap' function only produces a list of pages.
>> If there is no better way to get this to work, I would like to propose a 
>> patch
>> to `org-publish-org-sitemap' to produce headings in the sitemap file
>> when a new
>> parameter is passed and non-nil.  The attached patch is my first
>> attempt at it,
>> it works for my tests.
>> I would be interested to hear people's opinion on this:
>> - Is there a better way to achieve what I want?
>> - Is the proposed patch acceptable?  Any comments would be appreciated.
> This reminds me of a patch Rasmus (Cc'ed) is working on (thread starting
> at: <>).

This is still WIP.  I guess we were discussing the "hows" in that thread
as well.

> I'd like to propose here a slightly different, hopefully simpler
> approach so as to get flexibility without entering keyword hell.
> The first thing to note is that :sitemap-function is, IMO, unusable,
> because it puts too much work on the hands of the user. Indeed, they
> have to generate the title of the sitemap page, get the list of files in
> the project, walk that list, handle sorting according to style...

It’s not quite that complicated in my patch/WIP.  You specify an ordering
function.  E.g. the plain list is:

     (defun org-publish-org-sitemap-as-list (files project-plist)
       "Insert FILES as simple list separated by newlines.
     PROJECT-PLIST holds the project information."
        (lambda (file) (org-publish-format-file-entry
                   file project-plist))
        files "\n"))

If you don’t have the full flexibility of a function I guess someone will
always run into trouble eventually...

> I suggest to let :sitemap-function operate on the lists of files
> included in the sitemap (i.e., the list of files in the project),
> already ordered, and formatted according to
> `org-publish-sitemap-file-entry-format'.

Isn’t that’s what my patch does?  The file sorting function call the
formater, providing these arguments.  We could move the formatting back in
the "main" sitemap publishing function, to hide it from users, if that’s

         `((?t . ,(and (not (directory-name-p file)) (org-publish-find-title 
file t)))
           (?s . ,(and (not (directory-name-p file)) (org-publish-find-subtitle 
file t)))
           (?f . ,filename)
           (?F . ,(directory-file-name
                    (if (directory-name-p filename)
                         dirname (org-publish--dir-parent dirname))
                      (file-relative-name filename dirname))))
           (?l . ,link)
           (?h . ,(concat (make-string depth ?*)))
           (?i . ,(concat (make-string (* 2 depth) ? ) "-"))
           (?d . ,(and (not (directory-name-p file))
                        (or (plist-get project-plist :sitemap-date-format)
                        (org-publish-find-date file))))

> The list would be provided in the same format as the return value from
> `org-list-to-lisp', so that, e.g., `org-list-to-subtree' can be directly
> called on it.

> Also, I suggest to make `org-publish-sitemap-file-entry-format'
> a function instead of a string, so as to get more power, i.e., to not
> limit ourselves to the list of placeholders allowed in the format
> string. In particular, we could provide a public function
> org-publish-get-keyword (file keyword &optional backend), much like what
> Rasmus does in his patchset, but with a back-end so as to get the value
> of any export keyword. Also, this would make
> `org-publish-sitemap-dir-entry-format' unnecessary.

I like that, but AFAIK the backend is not known at the time the sitemap is
generated.  And it might not be deducible from the publishing function.

> Eventually, we could run a hook at the end of `org-publish-org-sitemap',
> which would now always be called, in order to give the opportunity to
> modify the sitemap as a whole (e.g., the title).
> In a nutshell, ISTM that it would solve both your request and the
> difficulties encountered by Rasmus in changes.

Time is the main difficulty :)


Vote for proprietary math!

Reply via email to