Re: [O] Org-mode exporters licensing

[Robert Klein]

On Mon, 27 Jul 2015 20:49:05 +0200
Marcin Borkowski  wrote:

> 
> On 2015-07-27, at 20:30, Daniele Nicolodi  wrote:
> 
> > On 27/07/15 20:20, Marcin Borkowski wrote:
> >> 
> >> On 2015-07-27, at 20:02, Daniele Nicolodi 
> >> wrote:
> >> 
> >>> On 27/07/15 19:42, Marcin Borkowski wrote:
>  That I've already learned.  OTOH, one of the reasons to use PD
>  might be that I explicitly state that I object the legal system
>  I live in.  (Mind you: I'm not an anarchist, and I'm very far
>  from that.  But this system is almost unbearable.)
> >>>
> >>> This statement confirms that you do not really understand what
> >>> you are talking about: as you cannot renounce your copy rights,
> >>> you cannot place something in the public domain. If you do not
> >>> release your work with an explicit license, the default copyright
> >>> protection law applies and this means (in all jurisdictions I
> >>> know about) that you reserve all rights to yourself: none can use
> >>> your code, and probably not even look at it.
> >> 
> >> I do understand (at least I think so).  And I do understand that my
> >> declaration of putting something in PD would be technically void.
> >> I just don't care about it, if the declaration of intent is clear.
> >
> > If you do not care about the terms in which who receives your work
> > is able to use it, why all the discussion?
> >
> > I thought that you were arguing that a less strict license than the
> > GPL is better for the content of a possible tutorial and you were
> > inquiring if you could release your code derived or inspired from
> > GPL code with another license. Now you say that you do not care, or
> > better you say that you do not want to give any rights to who
> > receives your code.
> >
> > I think you are confused.
> 
> I was unclear again, sorry.
> 
> 1. As for my planned tutorial: I am reconciled with the idea that it
> might have to be GPL'd.  Though I still maintain that GPL is not an
> optimal license for such work.
> 
> 2. As for other code I might write and publish: I'm tempted to use the
> Unlicense (which is basically more or less putting it into the PD),
> even though it might (technically) be void.
> 
> > Cheers,
> > Daniele

FWIW, what Richard Lawrence posted in the other threat sounds good.  

Please feel free to use my material I posted to the list
(see
http://lists.gnu.org/archive/html/emacs-orgmode/2015-06/msg00160.html)
I mostly copied the export function in the example from org-mode, but
the rest you may use as you like.

Best regards
Robert

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[Sebastien Vauban]

Eric S Fraga  writes:
>> 3) Custom highlight markers error
>>> No idea about this.  It could be a bug anywhere.
>>> Could you maybe post a small example file?  I have no idea what you are
>>> describing unfortunately.
>> I retrieved what I did, from here
>> :
>
> I am not sure the new exporter allows you to define new highlighting
> methods.  The old one did but that was quite a while ago now.

That's true we liked `@' for `alert'...

> You can always use macros instead?

Or the `font-lock-add-keywords' mechanism?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Babel and R: Call code block and output plot

[Stefan Nobis]

Andreas Leha  writes:

> You still have to specify the format of the results of the #+CALL
> line, as in #+CALL: myplot[:exports results]() :results file

Works like a charm, thank you very much.

-- 
Until the next mail...,
Stefan.

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Marcin Borkowski  writes:

>> As Oleh Krehel pointed out in a reply to another mail of yours, if your
>> code links to org-mode code (or other GPL code) you cannot release it
>> under a different license. I'm not sure about how linking is intended in
>> Elisp sense of ('require)ing a library, but I believe it is analog to
>> executable linking in machine code programs.
>
> I understand, and I thank you for your clarification.  (Though I still
> consider it plain ridiculous.  And the fact that Oleh's own blog is
> CC-BY-NC-SA licensed, and contains many fragments of Elisp code, both
> small snippets and whole functions, thus rendering it illegal, is
> sweet;-).)

I think posting snippets on a blog falls into "Fair Use". As long as I'm
not posting something which is a full program, this is fine.  Besides,
CC-BY-NC-SA is compatible with GPL! Compatible. With GPL.

Quoting the SA (ShareAlike) part from the website:

> ShareAlike — If you remix, transform, or build upon the material, you
> must distribute your contributions under the same license as the
> original.

So if anyone dislikes GPL, add CC-...-SA to your list as well.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Eric S Fraga  writes:

> On Monday, 27 Jul 2015 at 19:04, Marcin Borkowski wrote:
>
> [...]
>
>> Nope.  As stated by someone here (Oleh, I guess), if I (require 'org),
>> or possibly even just write Elisp, and want to distribute it, it has to
>> be GPL.
>
> I do not think this is true.  I would like to see a proper reference
> where it is shown to be the case.  Oleh?

Look here:
https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License§ion=11#Libraries

Most useful quote:

> The Free Software Foundation (which holds the copyright of several
> notable GPL-licensed software products and of the license text itself)
> asserts that an executable which uses a dynamically linked library is
> indeed a derivative work. This does not however apply to separate
> programs communicating with one another.

So calling GNU find in your program via the shell call API (or whatever
else, pipes ...) of your language is totally fine.

But adding #include "find.h" to your code is not fine, according to FSF.
Same thing with Org: adding a shell call "emacs --eval org-export ..."
is fine. Adding (require 'org) to your program is not fine.

Org the text format is fully open and not copyright-able. Anyone can
choose to support it (Orgzzly, Trello etc.). Org-mode's Elisp
implementation is GPL, just like the whole of the Elisp interpreter.

You could argue about Elisp being close to Common Lisp, and indeed: if
you write in a subset of Elisp that is compatible with Common Lisp,
you're not using "the Elisp standard library", and your code can run on
whatever CL implementation and you don't have to GPL your code.

One could try make a BSD licensed Emacs, just like the Wine 
(https://www.winehq.org/) project was
made to emulate Windows: just try to adhere to the API without reusing
any of the original code.

See also GNU LGPL: 
https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License.
That license explicitly allows closed code to link to a free software
library. Since this license exists, it's natural to assume that GPL does
not allow this.

--Oleh

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[Eric S Fraga]

On Tuesday, 28 Jul 2015 at 09:24, Sebastien Vauban wrote:
> Eric S Fraga  writes:

[...]

>> You can always use macros instead?
>
> Or the `font-lock-add-keywords' mechanism?
>
> Best regards,
>   Seb

I think the OP wanted markers that would export, not just stand out in
the emacs buffer.  

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

Re: [O] John's amazing indexing posts

[Oleh Krehel]

Erik Hetzner  writes:

> I believe that you can rewrite using the recoll tool directly instead
> of recollq, using `recoll -t -b 'search string'`:
>
> (defun counsel-recoll-function (string &optional _pred &rest _unused)
>   "Grep in the current directory for STRING."
>   (if (< (length string) 3)
>   (counsel-more-chars 3)
> (counsel--async-command
>  (format "recoll -t -b '%s'" string))
> nil))
>
> If you use `recoll -A -t 'search string'` and do some post processing
> you could get snippets, too. I can’t see how to do that easily with
> counsel--async-command, though.

Thanks, Erik. I've merged your pull request. So now it's very easy to
start using recoll with Emacs - outside of Emacs the only necessary
thing is:

sudo apt-get install recoll

And inside Emacs it's:

package-install counsel

I did look into the annotation switch. The thing is that it just shows
some database aggregates instead of the actual line context, like grep
does. With 30 candidates and no line context, a pure list of files looks
simpler than a list of files and a list of out-of-sequence words that
each file contains.

--Oleh

[O] agenda events from table?

[Paolo Bientinesi]

Hello,

I am facing what seems to be a common situation, yet I can't find a way 
out. Imagine this scenario: A list of people, a number of 
fields/properties per person, and the date for a personal meeting.

For convenience, I handle this information through tables.
Example:

| Name | Address | Sex | Rank | Date   |
|--+-+-+--+|
| A| blah| M   |3 | <2015-07-30 Thu 10:00> |
| B| | F   |   10 | <2015-08-11 Tue 15:00> |
| C| blah2   | |   13 ||
| D| blah3   | M   |   15 | <2015-09-28 Mon 07:00> |
|  | | |  ||

Question:
How can I get the meetings (the Names) to show up as Agenda events?


One of the successful approaches I tried is to use properties (instead 
of table columns), and edit via column view. However, this is 
significantly slower (for me) than using straight tables; also the 
column view is nice, but not as clean as a straight table.


I tried to transpose a table into properties, but could not do that.


Any help or suggestions, please?

Thank you!
--
Prof. Paolo Bientinesi, Ph.D.

AICES, RWTH Aachen

Re: [O] Relative links and #+include:

[Rasmus]

Pavel Panchekha  writes:

> Is there any way to advise the #+include: process to resolve relative
> links correctly? Or a better way to include Org files in one another?

Relative links work.  Use something like

 #+include: ./inc/o2.org

Or

#+include: inc/o2.org

For including o2.org from the subfolder inc.

Hope it helps,
Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .

Re: [O] How to make a non-GPL Org-mode exporter?

[Eric S Fraga]

On Tuesday, 28 Jul 2015 at 10:07, Oleh Krehel wrote:

[...]

> Look here:
> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License§ion=11#Libraries
>
> Most useful quote:
>
>> The Free Software Foundation (which holds the copyright of several
>> notable GPL-licensed software products and of the license text itself)
>> asserts that an executable which uses a dynamically linked library is
>> indeed a derivative work. This does not however apply to separate
>> programs communicating with one another.

Oleh,

thanks for this link and excerpt.  I could argue that the key word in
the excerpt is "executable".  I cannot see how code written in elisp
itself would need to be GPL.  Distributing it *with* emacs would
probably require it being GPLed but the source code itself, if not based
on already GPLed code, should be fine, e.g. in the context of a
tutorial.

Anyway, I think we've beaten this to death already.  Time to get real
work done! :-)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Eric S Fraga  writes:

> Anyway, I think we've beaten this to death already.  Time to get real
> work done! :-)

That is my usual approach: label everything I write with GPL and not
think about it:)

It's just that most posts about GPL cast it in a bad light: I think it's
the best license, and I don't want people who casually read this list to
think that GPL has no supporters or that we are somehow "stuck" with it,
or it is imposed on us.

Even if I was not *required* to use this license, I would *choose* to
use it, because I like the idea.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Andreas Hilboll]

>> Look here:
>> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License§ion=11#Libraries
>>
>> Most useful quote:
>>
>>> The Free Software Foundation (which holds the copyright of several
>>> notable GPL-licensed software products and of the license text itself)
>>> asserts that an executable which uses a dynamically linked library is
>>> indeed a derivative work. This does not however apply to separate
>>> programs communicating with one another.
> 
> Oleh,
> 
> thanks for this link and excerpt.  I could argue that the key word in
> the excerpt is "executable".  I cannot see how code written in elisp
> itself would need to be GPL.

Exactly.  To quote again
https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:

   When the interpreter just interprets a language, the answer is no.
   The interpreted program, to the interpreter, is just data; a free
   software license like the GPL, based on copyright law, cannot limit
   what data you use the interpreter on. You can run it on any data
   (interpreted program), any way you like, and there are no
   requirements about licensing that data to anyone.

--
Andreas Hilboll

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Andreas Hilboll  writes:

>>> Look here:
>>> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License§ion=11#Libraries
>>>
>>> Most useful quote:
>>>
 The Free Software Foundation (which holds the copyright of several
 notable GPL-licensed software products and of the license text itself)
 asserts that an executable which uses a dynamically linked library is
 indeed a derivative work. This does not however apply to separate
 programs communicating with one another.

>> thanks for this link and excerpt.  I could argue that the key word in
>> the excerpt is "executable".  I cannot see how code written in elisp
>> itself would need to be GPL.
>
> Exactly.  To quote again
> https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:
>
>When the interpreter just interprets a language, the answer is no.
>The interpreted program, to the interpreter, is just data; a free
>software license like the GPL, based on copyright law, cannot limit
>what data you use the interpreter on. You can run it on any data
>(interpreted program), any way you like, and there are no
>requirements about licensing that data to anyone.

Just to link the paragraph exactly below the one you quoted

> However, when the interpreter is extended to provide “bindings” to
> other facilities (often, but not necessarily, libraries), the
> interpreted program is effectively linked to the facilities it uses
> through these bindings. So if these facilities are released under the
> GPL, the interpreted program that uses them must be released in a
> GPL-compatible way. The JNI or Java Native Interface is an example of
> such a binding mechanism; libraries that are accessed in this way are
> linked dynamically with the Java programs that call them. These
> libraries are also linked with the interpreter. If the interpreter is
> linked statically with these libraries, or if it is designed to link
> dynamically with these specific libraries, then it too needs to be
> released in a GPL-compatible way.

Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
which are GPL, and the interpreted program that uses them must be
released in a GPL-compatible way.

Plus Emacs supports byte compilation: someone could publish only the
exporter.elc, without providing exporter.el. That would be illegal, but
if the third party is given exporter.el released under BSD by a second
party, theoretically they could do it. Therefore, the second party
should not be allowed to change to BSD if they're linking to GPL code.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Andreas Hilboll]

On 28.07.2015 11:30, Oleh Krehel wrote:
> Andreas Hilboll  writes:
> 
 Look here:
 https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License§ion=11#Libraries

 Most useful quote:

> The Free Software Foundation (which holds the copyright of several
> notable GPL-licensed software products and of the license text itself)
> asserts that an executable which uses a dynamically linked library is
> indeed a derivative work. This does not however apply to separate
> programs communicating with one another.
> 
>>> thanks for this link and excerpt.  I could argue that the key word in
>>> the excerpt is "executable".  I cannot see how code written in elisp
>>> itself would need to be GPL.
>>
>> Exactly.  To quote again
>> https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:
>>
>>When the interpreter just interprets a language, the answer is no.
>>The interpreted program, to the interpreter, is just data; a free
>>software license like the GPL, based on copyright law, cannot limit
>>what data you use the interpreter on. You can run it on any data
>>(interpreted program), any way you like, and there are no
>>requirements about licensing that data to anyone.
> 
> Just to link the paragraph exactly below the one you quoted
> 
>> However, when the interpreter is extended to provide “bindings” to
>> other facilities (often, but not necessarily, libraries), the
>> interpreted program is effectively linked to the facilities it uses
>> through these bindings. So if these facilities are released under the
>> GPL, the interpreted program that uses them must be released in a
>> GPL-compatible way. The JNI or Java Native Interface is an example of
>> such a binding mechanism; libraries that are accessed in this way are
>> linked dynamically with the Java programs that call them. These
>> libraries are also linked with the interpreter. If the interpreter is
>> linked statically with these libraries, or if it is designed to link
>> dynamically with these specific libraries, then it too needs to be
>> released in a GPL-compatible way.
> 
> Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
> which are GPL, and the interpreted program that uses them must be
> released in a GPL-compatible way.

I would interpret this as

   "As long as I write pure elisp and don't require' and GPL'ed part of
   Emacs, I can release my code under any license I want.  If I do
   require' any part of Emacs, I have to go the GPL path."

If I'm wrong with this interpretation, please explain why.

-- Andreas.

Re: [O] How to make a non-GPL Org-mode exporter?

[Oleh Krehel]

Andreas Hilboll  writes:

>>> However, when the interpreter is extended to provide “bindings” to
>>> other facilities (often, but not necessarily, libraries), the
>>> interpreted program is effectively linked to the facilities it uses
>>> through these bindings. So if these facilities are released under the
>>> GPL, the interpreted program that uses them must be released in a
>>> GPL-compatible way. The JNI or Java Native Interface is an example of
>>> such a binding mechanism; libraries that are accessed in this way are
>>> linked dynamically with the Java programs that call them. These
>>> libraries are also linked with the interpreter. If the interpreter is
>>> linked statically with these libraries, or if it is designed to link
>>> dynamically with these specific libraries, then it too needs to be
>>> released in a GPL-compatible way.
>> 
>> Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
>> which are GPL, and the interpreted program that uses them must be
>> released in a GPL-compatible way.
>
> I would interpret this as
>
>"As long as I write pure elisp and don't require' and GPL'ed part of
>Emacs, I can release my code under any license I want.  If I do
>require' any part of Emacs, I have to go the GPL path."
>
> If I'm wrong with this interpretation, please explain why.

Your interpretation is entirely correct. However, to write almost any
useful code, you're going to need to require some parts of
Emacs. Anything that interacts with text in a buffer will need to call
`buffer-string' eventually - GPL-ed code.

Here are the famous 9 lines from the Oracle-Google Java lawsuit:

private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
 if (fromIndex > toIndex)
  throw new IllegalArgumentException("fromIndex(" + fromIndex +
   ") > toIndex(" + toIndex+")");
 if (fromIndex < 0) 
  throw new ArrayIndexOutOfBoundsException(fromIndex);
 if (toIndex > arrayLen) 
  throw new ArrayIndexOutOfBoundsException(toIndex);
}

This lawsuit is currently on some sort of appeal now. The code above is
essentially the most simple, efficient and obvious way to implement the
rangeCheck function based on the API signature. And still they sued.

On the other hand, the implementation of `buffer-string' isn't at all
trivial:

DEFUN ("buffer-string", Fbuffer_string, Sbuffer_string, 0, 0, 0,
   doc: /* Return the contents of the current buffer as a string.
If narrowing is in effect, this function returns only the visible part
of the buffer.  */)
  (void)
{
  return make_buffer_string_both (BEGV, BEGV_BYTE, ZV, ZV_BYTE, 1);
}

Lisp_Object
make_buffer_string_both (ptrdiff_t start, ptrdiff_t start_byte,
 ptrdiff_t end, ptrdiff_t end_byte, bool props)
{
  Lisp_Object result, tem, tem1;

  if (start < GPT && GPT < end)
move_gap_both (start, start_byte);

  if (! NILP (BVAR (current_buffer, enable_multibyte_characters)))
result = make_uninit_multibyte_string (end - start, end_byte - 
start_byte);
  else
result = make_uninit_string (end - start);
  memcpy (SDATA (result), BYTE_POS_ADDR (start_byte), end_byte - 
start_byte);

  /* If desired, update and copy the text properties.  */
  if (props)
{
  update_buffer_properties (start, end);

  tem = Fnext_property_change (make_number (start), Qnil, make_number 
(end));
  tem1 = Ftext_properties_at (make_number (start), Qnil);

  if (XINT (tem) != end || !NILP (tem1))
copy_intervals_to_string (result, current_buffer, start,
  end - start);
}

  return result;
}

It's possible to write some complex number-crunching functions without
relying on the Elisp library. That's the only use-case that I see of
using Emacs like an interpreter and not relying on the "bindings" to the
code that it provides.

--Oleh

Re: [O] How to make a non-GPL Org-mode exporter?

[Eric S Fraga]

On Tuesday, 28 Jul 2015 at 11:00, Oleh Krehel wrote:
> Eric S Fraga  writes:
>
>> Anyway, I think we've beaten this to death already.  Time to get real
>> work done! :-)
>
> That is my usual approach: label everything I write with GPL and not
> think about it:)
>
> It's just that most posts about GPL cast it in a bad light: I think it's
> the best license, and I don't want people who casually read this list to
> think that GPL has no supporters or that we are somehow "stuck" with it,
> or it is imposed on us.
>
> Even if I was not *required* to use this license, I would *choose* to
> use it, because I like the idea.
>
> --Oleh

Well said.  I'm with you on this completely!

Having said this, some of what I write cannot be GPLed due to
restrictions imposed on me by my employer but at least all research
publications we generate now have to be open access so we're moving in
the right direction.

And speaking of research publications, time to get back to the one I'm
working on now, using org of course ;-) including ox-latex, ob-octave,
ob-shell, and ob-gnuplot!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[Xiha]

Thanks Sebastien and Eric,


On Tuesday, 28 Jul 2015 at 09:24, Sebastien Vauban wrote:
> Eric S Fraga  ucl.ac.uk> writes:

[...]

>> You can always use macros instead?


Maybe, if I knew how. I haven't used macros before. I read this 
 and tried


   #+MACRO: hi ·$1·
   Let's {{{hi(test)}}} this.

but unsurprisingly that gives the same export error, and moreover within 
Org does not show the 'highlight' formatting I associated with ·, but 
rather the macro formatting.


Or did you mean to simply use the fact that any macro gets 'highlighted' 
within Org -- so I should use something like #+MACRO: hi $1 ?



> Or the `font-lock-add-keywords' mechanism?


In what way? What I read here 
 
seems more about highlighting particular words, not /any/ words between 
particular markers...?



I think the OP wanted markers that would export, not just stand out in
the emacs buffer.


Most importantly, I would like to custom-highlight text /within/ Org, to 
make my writing easier. The highlighting nor the markers have to be in 
the exported document. But if they are there, that is icing on the cake.


I figure - perhaps wrongly! - that it should be easiest to have custom 
marking like ·this· be highlighted within Org, yet be exported 
literally, without highlighting (i.e. '·' is treated just like any old 
character by the exporter)?


cheers

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[Eric S Fraga]

You need to differentiate between two aspects: highlighting of text
within a org buffer and what happens to text when exported.  In the new
exporter, I don't think you can implement anything that covers both use
cases.

I am not entirely sure what it is you want.  If you want just one of
these, for the former, font-lock-add-keywords is probably what you want
to pursue.  For the latter, you probably want to use a macro with
@@latex:...@@ and/or @@html:...@@ code embedded in the macro to export
the text the way you want it, as in

#+macro: coloured @@latex:{\color{red} $1}@@

This is some {{{coloured(text)}}} when exported.

HTH,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[Nick Dokos]

Xiha  writes:

> Thanks Sebastien and Eric,
>
> On Tuesday, 28 Jul 2015 at 09:24, Sebastien Vauban wrote:
> > Eric S Fraga  ucl.ac.uk> writes:
> 
> [...]
> 
> >> You can always use macros instead?
>
> Maybe, if I knew how. I haven't used macros before. I read this and tried
>
> #+MACRO: hi ·$1·  
> 
> Let’s {{{hi(test)}}} this.
>
> but unsurprisingly that gives the same export error, and moreover within Org 
> does not show the 'highlight' formatting I associated with ·, but rather the 
> macro formatting.
>
> Or did you mean to simply use the fact that any macro gets 'highlighted' 
> within Org -- so I should use something like #+MACRO: hi $1 ?
>
> > Or the `font-lock-add-keywords' mechanism?
>
> In what way? What I read here seems more about highlighting particular words, 
> not any words between particular markers...?
>
> I think the OP wanted markers that would export, not just stand out in
> the emacs buffer.  
>
> Most importantly, I would like to custom-highlight text within Org, to
> make my writing easier. The highlighting nor the markers have to be in
> the exported document. But if they are there, that is icing on the
> cake.
>
> I figure - perhaps wrongly! - that it should be easiest to have custom
> marking like ·this· be highlighted within Org, yet be exported
> literally, without highlighting (i.e. '·' is treated just like any old
> character by the exporter)?
>

Emphasis is detected in the parser, so it is indeed difficult to add new
emphasis for export. 

Since you don't care about the added emphasis in the exported document
(only in the org buffer), using latest org from git works OK, except
that the marker characters are copied verbatim to the output, so you'll
have some cleanup to do.

I also tried 8.2.9 and got an error, but the error is different from
what you get (backtrace attached).

Nick

Debugger entered--Lisp error: (void-variable org-quote-string)
  (format "^%s\\( \\|$\\)" org-quote-string)
  (string-match (format "^%s\\( \\|$\\)" org-quote-string) raw-value)
  (let ((case-fold-search nil)) (string-match (format "^%s\\( \\|$\\)" 
org-quote-string) raw-value))
  (let* ((components (org-heading-components)) (level (nth 1 components)) (todo 
(nth 2 components)) (todo-type (and todo (if (member todo org-done-keywords) 
(quote done) (quote todo (tags (let ((raw-tags (nth 5 components))) (and 
raw-tags (org-split-string raw-tags ":" (raw-value (or (nth 4 components) 
"")) (quotedp (let ((case-fold-search nil)) (string-match (format "^%s\\( 
\\|$\\)" org-quote-string) raw-value))) (commentedp (let ((case-fold-search 
nil)) (string-match (format "^%s\\( \\|$\\)" org-comment-string) raw-value))) 
(archivedp (member org-archive-tag tags)) (footnote-section-p (and 
org-footnote-section (string= org-footnote-section raw-value))) (standard-props 
(let (plist) (mapc (function (lambda (p) (setq plist ...))) 
(org-entry-properties nil (quote standard))) plist)) (time-props 
(save-excursion (if (progn (forward-line) (looking-at 
org-planning-or-clock-line-re)) (progn (let (... plist) (while ... ... ... ...) 
plist) (begin (point)) (end (min (save-excursion (org-end-of-subtree t t)) 
limit)) (pos-after-head (progn (forward-line) (point))) (contents-begin 
(save-excursion (skip-chars-forward " 
\n" end) (and (/= (point) end) (line-beginning-position (hidden 
(org-invisible-p2)) (contents-end (and contents-begin (progn (goto-char end) 
(skip-chars-backward " 
\n") (forward-line) (point) (if (or quotedp commentedp) (progn (let 
((case-fold-search nil)) (setq raw-value (replace-regexp-in-string (concat 
(regexp-opt ...) "\\(?: \\|$\\)") "" raw-value) (if archivedp (progn (setq 
tags (delete org-archive-tag tags (let ((headline (list (quote headline) 
(nconc (list :raw-value raw-value :begin begin :end end :pre-blank (if ... 0 
...) :hiddenp hidden :contents-begin contents-begin :contents-end contents-end 
:level level :priority (nth 3 components) :tags tags :todo-keyword todo 
:todo-type todo-type :post-blank (count-lines ... end) :footnote-section-p 
footnote-section-p :archivedp archivedp :commentedp commentedp :quotedp 
quotedp) time-props standard-props (let ((alt-title (org-element-property 
:ALT_TITLE headline))) (if alt-title (progn (org-element-put-property headline 
:alt-title (if raw-secondary-p alt-title (org-element-parse-secondary-string 
alt-title ... headline)) (org-element-put-property headline :title (if 
raw-secondary-p raw-value (org-element-parse-secondary-string raw-value 
(org-element-restriction (quote headline)) headline)
  (save-excursion (let* ((components (org-heading-components)) (level (nth 1 
components)) (todo (nth 2 components)) (todo-type (and todo (if (member todo 
org-done-keywords) (quote done) (quote todo (tags (let ((raw-tags (nth 5 
components))) (and raw-tags

Re: [O] [bug] undo bunching in agenda

[Rasmus]

Samuel Wales  writes:

> on repeated task i change state twice in agenda.  i ret to go to the
> task.  i do undo only once, but both changes get undone.

Indeed on repeated tasks the second undo seems to be weird and produces
bad output:

* TODO test
  :PROPERTIES:
  :LAST_REPEAT: [2015-07-28 mar 14:40]
  :END:
]
 <2015-08-04 mar +1w>>

I guess your expected behavior would be to go back to the previous state
(i.e. change the last repeated property and the time stamp).

We could to that by always modifying the the headline, properties and the
date tag in a temporary buffer and *then* inserting in after all
"internal" modifications.  Probably other ways exist as well.  This would
presumably provide a nice workflow in this case.

I'm not very familiar with the agenda codebase and I don't have time to
allocate towards fixing this right now.

Rasmus

-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts

Re: [O] Cannot fold drawer

[Rasmus]

Hi,

azubi  writes:

> I've recently discovered the drawers for org-mode. When I use
> "standard" drawers names (like LOGBOOK or PROPERTIES) I can fold them
> using the TAB key. If I create drawers with other names (like URLS or
> NOTES), these folders cannot be folded. I've created these specific
> folder using the function "org-insert-drawer" and therefore I suppose
> that I do not have some syntax problem, but I see that these
> "non-standard" drawer names are not "colorized" (sorry I don't know
> how to explain this clearly).

It seems to be fixed in the git version (8.3).

> The version of org-mode I use is:
>
> Org-mode version 8.2.4 (8.2.4-dist @
> /home/azubi/.emacs.d/elpa/org-20150720/)

Note: your version is quite out of date.  You should at least have 8.2.10.

Thanks,
Rasmus

-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone

Re: [O] How to make a non-GPL Org-mode exporter?

[Paul Rudin]

Oleh Krehel  writes:

> Marcin Borkowski  writes:
>
>> Hi all,
>>
>> after a short discussion in a recent thread, I have a serious technical
>> question.
>>
>> Assume that (for some reason) I want to write an Org-mode exporter which
>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>> writing a tutorial on them, and I consider publishing a *tutorial* with
>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>> other people can or even should reuse the code in the tutorial, right?
>> And I see no reason to impose GPL on them.))
>>
>> How do I do that?  Is that even possible?  Also, is it possible to get
>> an actual answer to this question without spending money on lawyers?
>
> Like I said in an earlier message just a few minutes ago, you can do it,
> but you can't use org.el or Elisp at all, unless you implement your own
> Elisp engine that you call.

AIUI, in the UK at least this isn't correct. There is no infringement of
copyright by writing and distributing your own elisp (or any other
language) code.

Whether or not somebody else chooses to use a particular elisp
implementation to run that code is up to them. But you don't have any
liability simply by using the language.

Re: [O] agenda events from table?

[Subhan Michael Tindall]

On Tue, Jul 28, 2015, 1:25 AM Paolo Bientinesi 
wrote:

Hello,

I am facing what seems to be a common situation, yet I can't find a way
out. Imagine this scenario: A list of people, a number of
fields/properties per person, and the date for a personal meeting.
For convenience, I handle this information through tables.
Example:

| Name | Address | Sex | Rank | Date   |
|--+-+-+--+|
| A| blah| M   |3 | <2015-07-30 Thu 10:00> |
| B| | F   |   10 | <2015-08-11 Tue 15:00> |
| C| blah2   | |   13 ||
| D| blah3   | M   |   15 | <2015-09-28 Mon 07:00> |
|  | | |  ||

Question:
How can I get the meetings (the Names) to show up as Agenda events?

One of the successful approaches I tried is to use properties (instead
of table columns), and edit via column view. However, this is
significantly slower (for me) than using straight tables; also the
column view is nice, but not as clean as a straight table.

I tried to transpose a table into properties, but could not do that.

Any help or suggestions, please?

Thank you!
--
Prof. Paolo Bientinesi, Ph.D.

AICES, RWTH Aachen


Agendas only pick up headlines,  which don't exist inside tables.  Your
attempt using properties is about as close as you can get.

Maybe you can build a custom table exporter and convert it to headlines,
then build your agenda from that?

Re: [O] [Feature Request] Let publishing-function decide :output-file and whether publishing is needed

[Rasmus]

Hi Ruben,

Thanks for your patch.

Ruben Maher  writes:

> I've been working on a derived exporter to publish a static blog, and
> I've run into some issues.  Say that `:publishing-directory' is
> "~/public_html" and I have `:base-directory' with an Org file foo.org.
>
> foo.org has option keywords like this:
>
> #+title: foo.org
> #+date: <2015-07-25 Sat 17:21:41>

OK.  That's nice.

> I have achieved this using the attached diff, which tells
> `org-export-output-file-name' to respect the property `:output-file' in
> the communications channel.

OK.  I did not test your patch, but can you please test and indicate
whether the following features work as expected with your patch:

 - automatic sitemap.
 - linking org files (foo.org links to bar.org).
 - async export (since you change org-export-output-file-name)

Some quick thoughts.  Perhaps it would be better to allow either a
user-supplied function that takes an org parse tree or an org file
location and returns an output name.  Alternatively, maybe you could
provide a way to format file names in :publish-direction via a
format-string (e.g. keywords, date etc).

> From 13c92b87b728da134a73ef173be8957453ef90a6 Mon Sep 17 00:00:00 2001
> From: Ruben Maher 
> Date: Sat, 25 Jul 2015 16:54:28 +0930
> Subject: [PATCH] org-export-output-file-name: respect :output-file
>
> There is a property :output-file defined in the communications channel
> but it is ignored by `org-export-output-file-name'.
>
> * lisp/ox.el (org-export-output-file-name): Add optional argument
>   EXT-PLIST, and try to get `base-name' from its property `:output-file'
>   if SUBTREEP is nil or there was no EXPORT_FILE_NAME at point.

Nicolas would have to say whether this is OK.  I don't know the details
here well enough.

Rasmus

-- 
May the Force be with you

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[Xiha]

Thanks guys. Getting closer - but please don't overestimate my backgound 
knowledge :)


On 07/28/2015 02:05 PM, Eric S Fraga wrote:

You need to differentiate between two aspects: highlighting of text
within a org buffer and what happens to text when exported.

Yes. Principally, I want the former.

As to the latter: (1) my custom highlighting shouldn't break exporting. 
(2) /If/ highlighting can appear in the exported document, that's a 
bonus. But clearly it's not trivial to do; so never mind.



In the new exporter, I don't think you can implement anything that covers
both use cases.

I am not entirely sure what it is you want.  If you want just one of
these, for the former, font-lock-add-keywords is probably what you want
to pursue.
Right, so grabbing code from the manual about font lock mode 
, 
how do I adapt it? I tried putting this in my .emacs file


;; Highlight text between ·interpuncts·
(add-hook 'org-mode-hook
  (lambda ()
   (font-lock-add-keywords nil
'(("·\w·" 1
   font-lock-warning-face t)

but that doesn't work. Probably that regexp is all wrong?

Also, I don't want it to use font-lock-warning-face particularly. (How) 
can I define a new face for this purpose?


Nick Dokos wrote:

Emphasis is detected in the parser, so it is indeed difficult to add new
emphasis for export.

Since you don't care about the added emphasis in the exported document
(only in the org buffer), using latest org from git works OK,
So do I understand correctly that this is a completely different route 
than the font-lock-add-keywords one above? I.e. using this latest git 
version, I can define the highlight marker as I did and described 
earlier, and there's no need for a new face, because it uses the 
'highlight' defined in the theme I'm using. Correct?


I cloned the git files, but I'm wary of the next steps. If I just make 
and make install, will it not half-overwrite my current stable Org, and 
become a big mess? Sorry, this stuff is new to me and not really obvious.


Also: I tried reinstalling Org via the menu, Options >> Manage Emacs 
Packages in hopes that it would install the git version while taking 
care of avoiding a mess. It now lists 20150727 as the version, so that's 
recent, but is that the 'bleeding edge' version or the stable version at 
that date? It didn't solve the problem, at any rate.



except
that the marker characters are copied verbatim to the output, so you'll
have some cleanup to do.
That's okay. It's not a problem for draft versions of the document; and 
by the time the final document is ready, all this temporary highlighting 
should be gone!



I also tried 8.2.9 and got an error, but the error is different from
what you get (backtrace attached).

I am using 8.2.10 not 8.2.9 so that may explain the difference.

cheers

Re: [O] Questions about exporting: subtitle, level formating, custom highlight markers error

[John Kitchin]

You may find this post on highlighting text helpful:
http://kitchingroup.cheme.cmu.edu/blog/2015/07/28/A-highlight-annotation-mode-for-Emacs-using-font-lock/

I think it also lays the foundation for thinking about how to get it to
export, although you would need to do this as a preprocessing step
before the org export to replace highlighted regions by the appropriate markup.

It also sounds like you could use the highlight-regexp function for what
you want.

Something like this might do what you want (use the face you prefer).

(defface my-face3
  `((t (:inherit org-link :foreground "red")))
  "My face")


(highlight-regexp "·[^·]*·" 'my-face3)

(unhighlight-regexp "·[^·]*·")



Xiha writes:

·test·

> Thanks guys. Getting closer - but please don't overestimate my backgound
> knowledge :)
>
> On 07/28/2015 02:05 PM, Eric S Fraga wrote:
>> You need to differentiate between two aspects: highlighting of text
>> within a org buffer and what happens to text when exported.
> Yes. Principally, I want the former.
>
> As to the latter: (1) my custom highlighting shouldn't break exporting.
> (2) /If/ highlighting can appear in the exported document, that's a
> bonus. But clearly it's not trivial to do; so never mind.
>
>> In the new exporter, I don't think you can implement anything that covers
>> both use cases.
>>
>> I am not entirely sure what it is you want.  If you want just one of
>> these, for the former, font-lock-add-keywords is probably what you want
>> to pursue.
> Right, so grabbing code from the manual about font lock mode
> ,
> how do I adapt it? I tried putting this in my .emacs file
>
> ;; Highlight text between ·interpuncts·
> (add-hook 'org-mode-hook
>(lambda ()
> (font-lock-add-keywords nil
>  '(("·\w·" 1
> font-lock-warning-face t)
>
> but that doesn't work. Probably that regexp is all wrong?
>
> Also, I don't want it to use font-lock-warning-face particularly. (How)
> can I define a new face for this purpose?
>
> Nick Dokos wrote:
>> Emphasis is detected in the parser, so it is indeed difficult to add new
>> emphasis for export.
>>
>> Since you don't care about the added emphasis in the exported document
>> (only in the org buffer), using latest org from git works OK,
> So do I understand correctly that this is a completely different route
> than the font-lock-add-keywords one above? I.e. using this latest git
> version, I can define the highlight marker as I did and described
> earlier, and there's no need for a new face, because it uses the
> 'highlight' defined in the theme I'm using. Correct?
>
> I cloned the git files, but I'm wary of the next steps. If I just make
> and make install, will it not half-overwrite my current stable Org, and
> become a big mess? Sorry, this stuff is new to me and not really obvious.
>
> Also: I tried reinstalling Org via the menu, Options >> Manage Emacs
> Packages in hopes that it would install the git version while taking
> care of avoiding a mess. It now lists 20150727 as the version, so that's
> recent, but is that the 'bleeding edge' version or the stable version at
> that date? It didn't solve the problem, at any rate.
>
>> except
>> that the marker characters are copied verbatim to the output, so you'll
>> have some cleanup to do.
> That's okay. It's not a problem for draft versions of the document; and
> by the time the final document is ready, all this temporary highlighting
> should be gone!
>
>> I also tried 8.2.9 and got an error, but the error is different from
>> what you get (backtrace attached).
> I am using 8.2.10 not 8.2.9 so that may explain the difference.
>
> cheers

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[O] Is it possible to remove org-completing-read and org-completing-read-no-i?

[Oleh Krehel]

Hi all,

I'd like to remove them in favor of using `org-icompleting-read'
everywhere (or better yet, `completing-read').

`org-completing-read-no-i' doesn't do much, is called twice and can be
replaced with a let binding wrapper.

`org-completing-read' could be updated this way:

(defmacro with-org-minibuffer-keys (&rest body)
  "Minibuffer read with SPACE being a normal character."
  `(let ((enable-recursive-minibuffers t)
 (minibuffer-local-completion-map
  (copy-keymap minibuffer-local-completion-map)))
 (org-defkey minibuffer-local-completion-map " " 'self-insert-command)
 (org-defkey minibuffer-local-completion-map "?" 'self-insert-command)
 (org-defkey minibuffer-local-completion-map (kbd "C-c !") 
'org-time-stamp-inactive)
 ,@body))

(with-org-minibuffer-keys
(org-icompleting-read args))

This change will simplify the code nicely.  One example that bothers me
is `org-tags-completion-function': it's essentially a hacky closure that
relies on several dynamic variables being set:
`org-last-tags-completion-table' and
`org-add-colon-after-tag-completion' are implicit arguments to this
function.

With the proposed change, each use of `org-tags-completion-function'
will be in conjunction with `org-icompleting-read'. That means a new
function can be written:

(defun org-read-tags (tag-list &optional colon)
  (let ((org-last-tags-completion-table tag-list)
(org-add-colon-after-tag-completion colon))
(org-icompleting-read
 "Tag: " 'org-tags-completion-function
 ;; ...
 )))

I think it's a better interface, since the coupling is now made
explicit, instead of having to remember to set
`org-last-tags-completion-table' and
`org-add-colon-after-tag-completion' each time
`org-tags-completion-function' is to be used.

An even better thing to do would be to use "lexical-binding: t", remove
`org-tags-completion-function' and have it be a real closure inside
`org-read-tags'. Is there any wish or effort to move Org to
lexical-binding? Adding it would allow us to get rid of those dynamic
variables and `org-tags-completion-function' altogether and have the
lambda enclose on tag-list and colon instead.

regards,
Oleh

Re: [O] Is it possible to remove org-completing-read and org-completing-read-no-i?

[Rasmus]

Hi,

Oleh Krehel  writes:

> I'd like to remove them in favor of using `org-icompleting-read'
> everywhere (or better yet, `completing-read').

I think we had a discussion following another thread on this topic
(probably a thread you started), and I believe switching to
`completing-read' is on the table after 8.3 has been released...

> An even better thing to do would be to use "lexical-binding: t".

Of course.  AFAIK lexical binding is not supported by Emacs 24.3.  Thus,
it can only happen after 8.3 has been released.

Rasmus

-- 
Dung makes an excellent fertilizer

Re: [O] Cannot fold drawer

[Achim Gratz]

azubi writes:
> The version of org-mode I use is:
>
> Org-mode version 8.2.4 (8.2.4-dist @
> /home/azubi/.emacs.d/elpa/org-20150720/)
>
> Can you please explain me what I've done wrong ?

That looks like a mixed installation to me.  Somewhere you seem to have
installed an Org version 8.2.4 from a distribution tarball that is now
shadowing an Org from ELPA dated 2015-07-20.  You need to remove the
standalone Org installation from load-path and call package-initialze
before any Org customization you may have in your startup script.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [O] "Capture"-like browser plugin?

[Peter Davis]

Daniele Pizzolli  writes:

> On Thu, Jul 23 2015, Peter Davis wrote:
>
>> Frequently when I'm doing a Web search and find pages I like, I want
>> to save a link to the page, along with the title and perhaps a few
>> notes. Something like org-mode's capture would be great, but I'd like
>> to initiate it from a browser. I imaging hitting a plugin button on
>> the the browser's toolbar to open emacs via emacsclient, and
>> essentially do a capture with the link and whatever text I care to
>> enter.
>
>>
>> Has anyone seen or heard of or written something like this?
>
> Hello,
> if you use firefox, see:
>
> https://addons.mozilla.org/it/firefox/addon/org-mode-capture/
>

Thank you, Daniele. I'm afraid I haven't been able to get this to work on a 
Mac. I have the Firefox add-in installed, and emacs
configured, but when I click the icon, nothing (seems to) happen(s).

Thanks,
-pd

[O] capture htmlwidgets for export - a pattern in search of a new :results type???

[Cook, Malcolm]

I have been playing with exporting htmlwidgets [1] generated in R code-blocks.

[1] http://www.htmlwidgets.org/  and

Here is a worked example that exports to html

#+BEGIN_SRC R :session *R* :exports both :results html 
library(htmlwidgets)
library(d3heatmap)
widget<-d3heatmap(mtcars, scale="column", colors="Blues")
saveWidget(widget,'d3heatmap_widget.html')
print('')
#+END_SRC
#+RESULTS:
#+BEGIN_HTML

#+END_HTML

After doing a few of these, a pattern emerges:  using ':results html' in the 
code bock header, and the last 2 lines of:
saveWidget(...)
print('

Re: [O] "Capture"-like browser plugin?

[Alan Schmitt]

On 2015-07-28 11:58, Peter Davis  writes:

>> if you use firefox, see:
>>
>> https://addons.mozilla.org/it/firefox/addon/org-mode-capture/
>>
>
> Thank you, Daniele. I'm afraid I haven't been able to get this to work on
> a Mac. I have the Firefox add-in installed, and emacs
> configured, but when I click the icon, nothing (seems to) happen(s).

Did you configure a capture template for it?

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Last week athmospheric CO₂ average (Updated July 26, 2015, Mauna Loa Obs.):
401.25 ppm


signature.asc
Description: PGP signature

Re: [O] capture htmlwidgets for export - a pattern in search of a new :results type???

[Charles C. Berry]

On Tue, 28 Jul 2015, Cook, Malcolm wrote:


I have been playing with exporting htmlwidgets [1] generated in R code-blocks.



[snip: proposal for new :results format to accomodate repetitive codes]




Perhaps there is  a better or more useful abstraction.

Or a better workaround than simply following the pattern when needed (which is 
not too hard anyway).

Any ideas along these lines?


See

(info "(org) Noweb reference syntax")

for one way to handle repetitive codes.

Alternately, header args :var, :post, :prologue and/or :epilogue could be 
used to crystallize your code.


One other alternative is to write an R function that creates the extra 
markup.


HTH,

Chuck

Re: [O] "Capture"-like browser plugin?

[Bob Newell]

Aloha kakou,

I've had this work on Firefox (with Linux) when everything is properly
set up, but it won't and probably never will work on Chrome. Even on
Firefox it isn't really ideal. But as long as you have clipboard access
configured in your Emacs, it really isn't such a great slowdown to do
cutting and pasting--- with any browser, on any system.

Yes, ideally we would have a web-clipper (similar to Evernote).

-- 
Bob Newell
Honolulu, Hawai`i
* Sent via Ma Gnus 0.12-Emacs 24.3-Linux Mint 17 *

Re: [O] "Capture"-like browser plugin?

[Ken Mankoff]

The chrome version of this works on chrome. See announcement on this list about 
two weeks ago...

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback 
keyboard. 

> On Jul 28, 2015, at 18:10, Bob Newell  wrote:
> 
> Aloha kakou,
> 
> I've had this work on Firefox (with Linux) when everything is properly
> set up, but it won't and probably never will work on Chrome. Even on
> Firefox it isn't really ideal. But as long as you have clipboard access
> configured in your Emacs, it really isn't such a great slowdown to do
> cutting and pasting--- with any browser, on any system.
> 
> Yes, ideally we would have a web-clipper (similar to Evernote).
> 
> -- 
> Bob Newell
> Honolulu, Hawai`i
> * Sent via Ma Gnus 0.12-Emacs 24.3-Linux Mint 17 *
> 

Re: [O] capture htmlwidgets for export - a pattern in search of a new :results type???

[Cook, Malcolm]

> On Tue, 28 Jul 2015, Cook, Malcolm wrote:
> 
> > I have been playing with exporting htmlwidgets [1] generated in R code-
> blocks.
> >
> 
> [snip: proposal for new :results format to accomodate repetitive codes]
> 
> 
> >
> > Perhaps there is  a better or more useful abstraction.
> >
> > Or a better workaround than simply following the pattern when needed
> (which is not too hard anyway).
> >
> > Any ideas along these lines?
> 
> See
> 
>   (info "(org) Noweb reference syntax")
> 
> for one way to handle repetitive codes.
> 
> Alternately, header args :var, :post, :prologue and/or :epilogue could be used
> to crystallize your code.

Excellent!  Glad to be directed to these.  The combination of all of them gets 
me over the fence:

#+name: iframe
#+begin_src sh :var it="" :var height="700px" :var width="700px" :results 
output :exports none
   printf "" $it $height $width
#+end_src

#+header: :prologue {file="d3heatmap_widget.html"; saveWidget({
#+header: :epilogue },file) ;file}
#+BEGIN_SRC R :session *R* :results html :exports both :post 
iframe(it=*this*,height="800px" width="800px")
library(htmlwidgets)
library(d3heatmap)
d3heatmap(mtcars, scale="column", colors="Greens")
#+END_SRC

#+RESULTS:
#+BEGIN_HTML

#+END_HTML


I don't really care for all the verbosity of the header, but the effect is 
perfect.  The code block does not contain ANY extra org-mode export-specific 
cruft.

TH,

Malcolm

> 
> One other alternative is to write an R function that creates the extra markup.
> 
> HTH,
> 
> Chuck