emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "François Pinard" <pinard@iro.umontreal.ca>
To: emacs-orgmode@gnu.org
Subject: Re: Touching :noexport: regions
Date: Sat, 05 May 2012 12:04:39 -0400	[thread overview]
Message-ID: <86zk9mzka0.fsf@mercure.progiciels-bpi.ca> (raw)
In-Reply-To: <87r4uysljc.fsf@altern.org> (Bastien's message of "Sat, 05 May 2012 08:29:34 +0200")

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:


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.


  reply	other threads:[~2012-05-05 16:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 22:08 Touching :noexport: regions François Pinard
2012-05-05  6:29 ` Bastien
2012-05-05 16:04   ` François Pinard [this message]
2012-05-06  1:44     ` François Pinard
2012-05-08 12:35     ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86zk9mzka0.fsf@mercure.progiciels-bpi.ca \
    --to=pinard@iro.umontreal.ca \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).