emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Use headings in sitemap


From: Nicolas Goaziou
Subject: Re: [O] Use headings in sitemap
Date: Sun, 30 Oct 2016 18:38:30 +0100

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Rasmus Pank Roulund <address@hidden> writes:
>
>> Nicolas Goaziou <address@hidden> writes:
>
>> 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."
>>        (mapconcat
>>         (lambda (file) (org-publish-format-file-entry
>>                    org-publish-sitemap-file-entry-format
>>                    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 think one mistake here is to conflate style and formatting. By doing
> so, defining a new style implies that one has to handle sorting,
> directories (or lack thereof)... and also Org syntax.
>
> I suggest to keep style as a mean to control how the file names are
> provided, and separate it from the formatting process, handled
> by :sitemap-function and :sitemap-format-entry or some such.
>
> We might, however, by this definition, merge sorting and style together
> (e.g., tree-date-ascending list-name-descending).
>
>>> 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?
>
> More or less, but my proposal is slightly different. E.g., I suggest
> a different data type for the arguments.
>
> OTOH, your patch does other things orthogonal to my proposal (e.g.
> preamble and postambles for sitemaps...).
>
>> 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.
>
> You might have misread my proposal. 
>
> I'm suggesting to leave it up to the user. Whenever they define a new
> sitemap function and need to implement a formatting function, they can
> provide the name of the back-end they want to use. This information is
> known to the user.
>
> Conversely, we do not provide any ready-to-use keyword (so, no format
> string with placeholders) because, as you write, we cannot predict the
> back-end with certainty. Instead, we merely implement a generic getter
> function (which you mostly implemented in your patch set).

I pushed an implementation of that idea in wip-sitemap branch, if anyone
wants to test it.

For example, setting :sitemap-function property to

           (lambda (title list)
             (concat "#+TITLE: " title "\n\n"
                     (org-list-to-subtree list)))

mostly achieves what the OP wants. Also, setting :sitemap-format-entry
to

           (lambda (entry root style)
             (if (directory-name-p entry)
                 (file-name-nondirectory (directory-file-name entry))
               (format
                "[[file:%s][%s]]%s"
                (file-relative-name entry root)
                (org-publish-find-title entry)
                (let ((subtitle
                       (org-element-interpret-data
                        (org-publish-find-property entry :subtitle 'latex))))
                  (if (equal subtitle "") "" (format " (%s)" subtitle))))))

will add a subtitle to the entry, when available, upon publishing to
LaTeX.

Feedback weclome.


Regards,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]