Hello, 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). Regards, -- Nicolas Goaziou
