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
