Re: [O] Seeking advice for conditional code

[Sebastien Vauban]

Hi François,

François Pinard wrote:
> "Sebastien Vauban" writes:
>> Please tell if that's more or less the direction you want to take...
>
> Direction already taken, and completed a few minutes ago! :-).  But I'll
> happily revert to something else it if there is a better way to proceed.
> The addition of pseudo-Org directives does not really please me, I would
> prefer plain Org if possible.  If you are curious, see comments at start
> of https://github.com/pinard/poporg/blob/master/extradoc.py.  In my
> application, I even define context from the Makefile, which is an
> unexpected advantage.

I'll have a look, but not now... ;-(

>> I want to be sure to understand: do you need
>> - conditional tangled code, or
>> - conditional "full" document (containing conditional code and conditional
>>   doc)?
>> When you say "conditional", do you mean to to be able to decide to include it
>> or not, or even more (such as including one version or the other)?
>
> Exactly! :-) It's not tangling.  Rather, merely extract the
> documentation out of comments found in (program) source code.  The
> comments (once removed the hash marks) are in Org format.  I'm seeking
> for conditional documentation.

For curiosity, why aren't you considering tangling?

>> What's sure if that you can have conditions based on tags, and things in the
>> following spirit::
>> * Show the params                                                        
>> :dev:
>> Params are "dynamically" assigned. Here the results with the "dev" tag:
>> #+begin_src sh :rownames no :var data=(concat (car (org-get-tags-at
>> (point))) "-params") :exports both
>> echo $data
>> #+end_src
>
> I should have thought at exploring the usage of Org tags.  :export: and
> :noexport: are already very useful, but the idea did not come to me that I
> could extend this to other tags.  I probably do not use tags enough!
>
> In any case, the example above is quite interesting, and could be useful
> to solve other problems.  I'll keep it around.
>
>> #+tblname: params
>> | Variable           | dev | stg | prd |
>> |--------------------+-----+-----+-----|
>> | webServerName      | a   | g   | m   |
>> | loginWebServerName | b   | h   | n   |
>> | pwWebServerName    | c   | i   | o   |
>> | appBaseDir         | d   | j   | p   |
>> | dbName             | e   | k   | q   |
>> | dbBackupFile       | f   | l   | r   |
>
> I missed the point of this table however, I presume the "dev" column is
> to be linked in some way to the ":dev:" tag, but I do not see why/how.

The above is almost working real sample -- not had time to really finish it.

The column is a list of parameters (for different environments, such as
"development" machine, "staging" and "production"): paths, user names,
passwords, database names, etc.

By using the tags, you can tangle or display inline code customized to the tag
of their subtree. Have 3 subtrees to list all 3 codes, or have just one, and
change the tag accordingly to what you need to do (generate).

Such a document can be used as a "deployment guideline", for example.

> Thanks for caring, Sebastien!  I feel all warm inside :-).

Silly you ;-)

Best regards,
  Seb

-- 
Sebastien Vauban