Bastien <b...@gnu.org> writes: > Hi François,
Bonjour chez vous! :-) > François Pinard <pin...@iro.umontreal.ca> 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çois