From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Fran=C3=A7ois_Pinard?= Subject: Re: Touching :noexport: regions Date: Sat, 05 May 2012 12:04:39 -0400 Message-ID: <86zk9mzka0.fsf@mercure.progiciels-bpi.ca> References: <86fwbf1twv.fsf@mercure.progiciels-bpi.ca> <87r4uysljc.fsf@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQhTQ-0004q2-1m for emacs-orgmode@gnu.org; Sat, 05 May 2012 12:04:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SQhTO-0004Ky-2g for emacs-orgmode@gnu.org; Sat, 05 May 2012 12:04:43 -0400 Received: from 206-248-137-202.dsl.teksavvy.com ([206.248.137.202]:54856 helo=mercure.progiciels-bpi.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQhTN-0004Ic-Sg for emacs-orgmode@gnu.org; Sat, 05 May 2012 12:04:41 -0400 In-Reply-To: <87r4uysljc.fsf@altern.org> (Bastien's message of "Sat, 05 May 2012 08:29:34 +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: emacs-orgmode@gnu.org Bastien writes: > Hi Fran=C3=A7ois, Bonjour chez vous! :-) > Fran=C3=A7ois Pinard writes: >> There is some machinery on my side involved into publication, which I >> would rather avoid if not necessary. > Please don't hesitate to share it you think other people could find it > useful. Probably not generic enough. I intend, yet with low priority, to create a page explaining my overall Org setup and tools, would it be as a reference for myself... > We could have a #+PUBLISH: option allowing to tell whether a file > should be published or not. If we had this, we could then check > whether a section without the :noexport: tag has been modified... and > dynamically set the buffer publication option based on this. I see. When publication occurs, #+PUBLISH could be reset, and publication stay inhibited until #+PUBLISH is set again. Modifying an exportable section could set #+PUBLISH automatically. It might mean quite an overhead just to check while editing, it might not be an affordable avenue. > But this is rather a complicated way, and the gain is merely about > speed. In my case, this goes a bit further. How to explain... OK, visit: http://pinard.progiciels-bpi.ca/recent-notes.html This page is created by a program which, starting from the existing HTML, has enough knowledge of my work habits to infer the real source file behind it, usually a reST file or an Org file. Then, it picks up the modification time stamp of the source file. The index is complemented by XSLT-like code (in fact: Python using lxml and XPath) which grabs explicit Org dates from within the published HTML pages. If I modify text in a :noexport: section, the time stamp of the Org file is modified, and so, the generated HTML page jumps near the top in the index. As there is no user-visible change corresponding at that time stamp, they may uselessly visit the page, a mere annoyance to them. One idea, but not an easy one for me as it would require a lot of work, would be to generate change bars, with the reference date settable by users (or worse, through tons of cookies). It is /theoretically/ possible as all my Org files are kept under Git. But I feel this would be gross, absolute overkill, as what I publish is never important enough for users to really trigger such toys. Fran=C3=A7ois