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."
> (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 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
> 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
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).