Touching :noexport: regions

Touching :noexport: regions

[François Pinard]

Hi, people.  I doubt there is an easy solution, but here I go nevertheless.

Many of my Org notes are published to the Web, which have :noexport:
headers.  It is very convenient that Org allows me to keep all parts
together, whether parts are published or not, in a single Org file.

There is some machinery on my side involved into publication, which I
would rather avoid if not necessary.  My little problem is that Org
checks the file time stamp, and Emacs does not distinguish, of course,
if I modify a part which is within a :noexport: region.

The only idea I got (but I did not really torture me into this yet!) is
to maintain a kind of a cache of files before edit, and write a
specialized file comparator that would re-establish previous time stamps
when nothing publishable has been changed.  Any clever idea, someone? :-)

François

Re: Touching :noexport: regions

[Bastien]

Hi François,

François Pinard <pinard@iro.umontreal.ca> writes:

> There is some machinery on my side involved into publication, which I
> would rather avoid if not necessary.  My little problem is that Org
> checks the file time stamp, and Emacs does not distinguish, of course,
> if I modify a part which is within a :noexport: region.

Please don't hesitate to share it you think other people could find it
useful. 

> The only idea I got (but I did not really torture me into this yet!) is
> to maintain a kind of a cache of files before edit, and write a
> specialized file comparator that would re-establish previous time stamps
> when nothing publishable has been changed.  Any clever idea, someone?
> :-)

Currently the only way to exclude an *entire* file from the publication
process is to play with the :exclude parameter in `org-publish-project-alist'.

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.

But this is rather a complicated way, and the gain is merely about
speed.

If someone comes up with something more clever, let's see.

Or if someone would find a new #+PUBLISH option useful outside of this
use-case, let's also see.

Thanks,

-- 
 Bastien

Re: Touching :noexport: regions

[François Pinard]

Bastien <bzg@gnu.org> writes:

> Hi François,

Bonjour chez vous! :-)

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

Re: Touching :noexport: regions

[François Pinard]

François Pinard <pinard@iro.umontreal.ca> writes:

> Our dear Bastien writes:

>> 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.  But
>> this is rather a complicated way, and the gain is merely about speed.

> 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.

Here is how I decided to proceed for now, in case anyone is amused by my
little problems.  I just created a file *org-stamps* having three
columns for each publishable Org file: a time stamp, a md5sum over all
publishable parts, and the Org file name.

The very first time, or for any new Org file, the time stamp is the file
modification time.  For each Org file, the tool generating the index
pages recomputes the md5sum over all publishable parts and compares with
the md5sum from *org-stamps*; if they match, the *org-stamps* time stamp
is used instead of the actual file time stamp.  If they do not match,
the current file time stamp and md5sum are going to obliterate the
values saved in *org-stamps* once all Org files will have been
processed.

Simple enough for now, I guess.

François

Re: Touching :noexport: regions

[Bastien]

Hi François,

François Pinard <pinard@iro.umontreal.ca> writes:

> But I feel this would be gross, absolute overkill

I do feel the same -- especially because, again, the issue at stake is
the time it takes to publish the files to HTML.  One idea would be to
gather as much :noexport: subtrees into a small set of files so that 
the publication process does not take too much extra time.

-- 
 Bastien