Re: [O] Touching :noexport: regions

[François Pinard]

Bastien <address@hidden> writes:

> Hi François,

Bonjour chez vous! :-)

> François Pinard <address@hidden> 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