From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: Re: [PATCH] Remove unecesssary invocations of org-mode in ox-publish Date: Wed, 30 Jul 2014 14:33:34 -0500 Message-ID: <87bns663qp.fsf@fastmail.fm> References: <87mwbsn40z.fsf@fastmail.fm> <871tt4fggm.fsf@bzg.ath.cx> <87zjfsnsyf.fsf@fastmail.fm> <87fvhk9p0m.fsf@bzg.ath.cx> <87k36wnp7x.fsf@fastmail.fm> <877g2wyoyo.fsf@fastmail.fm> <87egx2ss5l.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCZdF-00049V-Oi for emacs-orgmode@gnu.org; Wed, 30 Jul 2014 15:33:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCZdA-0002T3-B9 for emacs-orgmode@gnu.org; Wed, 30 Jul 2014 15:33:49 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:47188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCZdA-0002Sp-3i for emacs-orgmode@gnu.org; Wed, 30 Jul 2014 15:33:44 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by gateway1.nyi.internal (Postfix) with ESMTP id 2C1BA24C9B for ; Wed, 30 Jul 2014 15:33:34 -0400 (EDT) In-Reply-To: <87egx2ss5l.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Wed, 30 Jul 2014 18:55:18 +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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org Mode Cc: Bastien Nicolas Goaziou writes: > Hello, > > Matt Lundin writes: > >> Clearly, this is still very inadequate, but it is an improvement. I >> would love to use the built in site-map functions, but they are simply >> to slow for any larger projects. >> >> Could we do something like this to speed it up? >> >> (with-temp-buffer >> (insert-file-contents file) >> (goto-char (point-min)) >> (when (re-search-forward "^#\\+TITLE:" nil t) >> (org-element-at-point))) > > No, you also need to parse #+SETUPFILE: keywords. You could also get > false positive within a verbatim block: > > #+begin_example > #+title: something > #+end_example > However, it is possible to write a specialized function to extract > only #+TITLE. > > Another option is to cache results. See `org-publish-cache-set' and > `org-publish-cache-get'. Thanks for the helpful information. I think the cache would be a nice way to go, especially if it were combined a timestamp check. E.g., only files that have been updated since the last publishing should be queried for titles; otherwise, use the cached file. I notice that org-publish-find-title does cache the title, but AFAICT this is never used, since org-publish-format-file-entry calls org-publish-find-title with the reset argument. Perhaps we could add a variable to make this optional in org-publish-format-file-entry. E.g., --8<---------------cut here---------------start------------->8--- (defun org-publish-format-file-entry (fmt file project-plist) (format-spec fmt `((?t . ,(org-publish-find-title file org-publish-find-title-use-cache)) [...] --8<---------------cut here---------------end--------------->8--- A similar option could be added to the date function date function. Would it be O.K. if I went ahead and implemented this? Thanks, Matt