From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Pank Roulund Subject: Re: Use headings in sitemap Date: Wed, 12 Oct 2016 11:12:52 +0200 Message-ID: <87bmyqq6az.fsf@gmx.us> References: <87fuojl53s.fsf@dell-desktop.WORKGROUP> <87y41uq1yo.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buFav-0003ts-JJ for emacs-orgmode@gnu.org; Wed, 12 Oct 2016 05:13:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buFaq-0001DN-Jh for emacs-orgmode@gnu.org; Wed, 12 Oct 2016 05:13:00 -0400 Received: from mout.gmx.net ([212.227.15.19]:50546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buFaq-0001D8-A2 for emacs-orgmode@gnu.org; Wed, 12 Oct 2016 05:12:56 -0400 In-Reply-To: <87y41uq1yo.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Tue, 11 Oct 2016 18:34:23 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: thibault.marin@gmx.com Cc: emacs-orgmode@gnu.org 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: >> . >> =E2=94=9C=E2=94=80=E2=94=80 index.org >> =E2=94=9C=E2=94=80=E2=94=80 posts >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 A.org >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 B.org >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 C.org >> =E2=94=9C=E2=94=80=E2=94=80 misc >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 page.org >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 other-page.org >> =E2=94=94=E2=94=80=E2=94=80 sitemap.org >> >> In index.org, I would have: >> >> #+begin_src org >> #+INCLUDE: sitemap.org::*posts :lines "-10" :only-contents t >> #+end_src >> >> to include links to the 10 most recent pages in =3Dposts=3D (I use >> :sitemap-sort-files anti-chronologically in the project setup). If I am= not >> missing anything, this requires the sitemap.org file to have a >> =3Dposts=3D 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=E2=80=99s not quite that complicated in my patch/WIP. You specify an or= dering 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=E2=80=99t have the full flexibility of a function I guess someon= e 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=E2=80=99t that=E2=80=99s 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=E2= =80=99s better. (format-spec fmt `((?t . ,(and (not (directory-name-p file)) (org-publish-find-title file = t))) (?s . ,(and (not (directory-name-p file)) (org-publish-find-subtitle fi= le t))) (?f . ,filename) (?F . ,(directory-file-name (if (directory-name-p filename) (file-relative-name 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)) (format-time-string (or (plist-get project-plist :sitemap-date-format) org-publish-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 :) Rasmus --=20 Vote for proprietary math!