From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Seeking advice for conditional code Date: Thu, 31 Jan 2013 23:56:28 +0100 Message-ID: <86d2wl3qsj.fsf@somewhere.org> References: <86lib96zzl.fsf@iro.umontreal.ca> <86halx3w0f.fsf@somewhere.org> <868v796m3u.fsf@iro.umontreal.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Fran=C3=A7ois, Fran=C3=A7ois 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...=C2=A0;-( >> I want to be sure to understand: do you need >> - conditional tangled code, or >> - conditional "full" document (containing conditional code and condition= al >> doc)? >> When you say "conditional", do you mean to to be able to decide to inclu= de 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=3D(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=C2=A0;-) Best regards, Seb --=20 Sebastien Vauban