all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org, roklein@roklein.de
Subject: Re: [ox-publish, patch] More flexible sitemaps
Date: Wed, 20 Jul 2016 09:56:34 +0200	[thread overview]
Message-ID: <87shv47nf1.fsf@saiph.selenimh> (raw)
In-Reply-To: <87furlkefs.fsf@gmx.us> (rasmus@gmx.us's message of "Thu, 07 Jul 2016 11:03:35 +0200")

Hello,

Rasmus <rasmus@gmx.us> writes:

> Sorry about the slow reply.  Sometimes there's not enough time.

So true.

> I obviously agree with your criticism.  It’s not obvious how to do this
> properly.
>
> If we provide a backend we’d have to move the index preparation to
> beginning of each export process as :publishing-function can be a list.
> Also, I’m not sure how we’d know about the backend.  Before the exporting
> starts, we at most know the names of the functions right?  If one of the
> publishing functions is anonymous we don’t even have that.
>
> Perhaps the best way is to move keywords back to ox, though I’d rather opt
> for something else.

You're right, "ox-publish" is mostly back-end agnostic so the
information is not readily available.

However, we're creating an Org file here. We don't need to have parsed
values for keywords. So, what about simply looking for, e.g., #+SUBTITLE
value in the document and use it instead as a template replacement? IOW,
what about eschewing so-called "environment" altogether?

>>> +	 ;; Call function to build sitemap based on files and the project-plist.
>>> +	 (let* ((style (or (plist-get project-plist :sitemap-style) 'tree))
>>> +		(fun (intern (format "org-publish-org-sitemap-as-%s" style))))
>>
>> Side note : I think this is a bit too smart. It prevents, e.g., from
>> grepping for a function name. Maybe 
>>
>>   (if (eq style 'something) #'... #'....)
>>
>> would be better.
>
> The point is that it should be easy to supply your own functions.  All
> sorts of requirements for the index/sitemap could come up, and it is
> important to not limit to the tree-style and the flat-style.

But that's outside the scope of the patch currently considered. My point
is that we should avoid forging function names as a UI.

> I might want to provide an index ordered by keywords, say.
>
> Perhaps styles should be stores in an alist with elements like
>
>         (STYLE STYLE-FUNCTION) ?

Some functions may handle multiple styles, as `org-publish-org-sitemap'
does. Besides, any user-provided sitemap function is likely to handle
its own style without relying on :sitemap-style property.

Therefore, providing :sitemap-function and :sitemap-style is enough,
there's no need to merge them together.

WDYT?


Regards,

-- 
Nicolas Goaziou

      reply	other threads:[~2016-07-20  7:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 15:39 [ox-publish, patch] More flexible sitemaps Rasmus
2016-05-22 22:58 ` Nicolas Goaziou
2016-05-27 16:41   ` Rasmus
2016-06-01 15:34     ` Nicolas Goaziou
2016-07-05 11:08       ` Robert Klein
2016-07-06 11:17         ` Rasmus
2016-07-07  9:03       ` Rasmus
2016-07-20  7:56         ` Nicolas Goaziou [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87shv47nf1.fsf@saiph.selenimh \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=rasmus@gmx.us \
    --cc=roklein@roklein.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.