From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: **: Re: Re: Org-mode Code Blocks Manuscript: Request For Comments Date: Thu, 09 Dec 2010 07:46:00 -0700 Message-ID: <87hbenypg7.fsf@gmail.com> References: <87lj487z50.fsf@gmail.com> <12760.1291360577@gamaville.dokosmarshall.org> <80k4jl2ny3.fsf@missioncriticalit.com> <87bp4w0zmx.fsf@gmail.com> <8039q7dqs4.fsf@missioncriticalit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=35885 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQhl2-0007A7-Uk for emacs-orgmode@gnu.org; Thu, 09 Dec 2010 09:46:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQhl1-00007p-1n for emacs-orgmode@gnu.org; Thu, 09 Dec 2010 09:46:08 -0500 Received: from mail-qw0-f41.google.com ([209.85.216.41]:53403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQhl0-00007k-Pd for emacs-orgmode@gnu.org; Thu, 09 Dec 2010 09:46:06 -0500 Received: by qwa26 with SMTP id 26so2685943qwa.0 for ; Thu, 09 Dec 2010 06:46:06 -0800 (PST) In-Reply-To: <8039q7dqs4.fsf@missioncriticalit.com> (=?utf-8?Q?=22S=C3=A9b?= =?utf-8?Q?astien?= Vauban"'s message of "Thu, 09 Dec 2010 14:22:51 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?utf-8?Q?S=C3=A9bastien?= Vauban Cc: emacs-orgmode@gnu.org Hi Seb, S=C3=A9bastien Vauban writes: > Hi Eric, > > "Eric Schulte" wrote: >> Thanks for the proof reading. I have answers for some of your questions >> below. > > Sure! > >>> Page 9 -- You say that "tags and properties of a node are inherited by = its >>> sub-nodes". I agree for tags, not for properties (at least, by default). >> >> With respect to code blocks properties are inherited by subnodes, at >> least all properties which can be used as header arguments are >> inherited. > > OK. You're talking now of the properties *of code blocks*. The, your para= graph > is a bit misleading, as you're also talking of tags -- which do not apply= to > code blocks... > > Having made the above distinction, I now understand your paragraph. > Alright I'll take another look at this paragraph and see if I can untangle the verbiage. > >>> BTW, what happens if there is a name clash with other code blocks (in t= he same >>> document, or in the LOB)? Though, this is not for your paper... >> >> While no behavior is guaranteed in this case (meaning don't do it :)) I >> believe that whichever code block is found first will be used, in >> practice this would probably mean that local code blocks will override >> lob code blocks, but I make no guarantees > > Some ideas: > > - report the conflict in a very visible way (at execution and export time= s) > > - having the ability to look for potential clashes (some > =3Dlist-code-block-shadows=3D) > > - (why not?) being able to add the filename of the code block we want to = use, > to resolve the conflict (if we don't want to change the names...) > actually this should already be implemented, you can specify another file by constructing your reference as file-name:resource-name, e.g. with the following saved to ~/Desktop/location.org #+source: year #+begin_src emacs-lisp 2010 #+end_src #+source: city #+begin_src emacs-lisp "Santa Fe" #+end_src the following code block should resolve its references correctly from *any* buffer #+headers: :var city=3D~/Desktop/location.org:city #+headers: :var year=3D~/Desktop/location.org:year #+begin_src emacs-lisp (message "I'm in %s in the year %d" city year) #+end_src although apparently there is still some work to be done on this code as for me it leaves the referenced file open. This is code that apparently hasn't been used or documented so I'm sure there will be some kinks to work out > >>> Side comment -- Wouldn't you use a standard way of handling the acronym= s in >>> LaTeX, so that they're expanded when required, and listed at the end of= the >>> document? Example of such acro: ESS. >> >> I don't understand what you mean by "standard acronyms" can you give a >> specific location and how you would suggest it be changed? > > #+TITLE: Inserting proper acronyms in LaTeX > #+DATE: 2010-12-09 > #+LANGUAGE: en_US > > #+LaTeX_HEADER: \usepackage[printonlyused]{acronym}% (not in medium TeX L= ive installation) > > * Prologue > > \ac{ESS} is a great add-on to Emacs. > > * Epilogue > > Emacs is made public by the \ac{FSF}. The second time the acronym \ac{FSF= } is > used, it should not be expanded in the PDF... > > All of that being taken care automagically by LaTeX itself, and the =3Dac= ronym=3D > package. Plus you gain hyperlinks from every usage of acronym to its > definition table... > > * Acronyms > > \begin{acronym}[LONGEST] > \acro{EEPROM} {Electrically Erasable Programmable \acs{ROM}} > \acro{ESS} {Emacs Speaks Statistics} > \acro{FSF} {Free Software Foundation} > \acro{GNU} {GNU is Not Unix} > \end{acronym} > > ** Note :noexp= ort: > > Unused acronyms won't be outputted in the final PDF... Out of the 4 defin= ed > acronyms, only the 2 used will be listed at the end of the document... th= anks > to the option =3Dprintonlyused=3D. > > * Conclusion > > Does this answer your question? > Yes, thanks for the explanation, this is the first I've heard of this package but it certainly does seem useful. > > For me, this is one of the only missing piece that should be made more > standard into Org. > > The real problem is: how do we have something clean for the HTML export, = even > if ultra-minimal (like having no LaTeX symbols outputted in the middle of= the > text, having always/never acronym expansion, printing all acronyms > independently of the fact they're used or not). > Maybe this would be possible to implement using custom links? Cheers -- Eric > > Best regards, > Seb