Rasmus Pank Roulund <ras...@gmx.us> writes:

> Nicolas Goaziou <m...@nicolasgoaziou.fr> 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).


Nicolas Goaziou

Reply via email to