Re: [O] [RFC] [PATCH] allow bind keywords to set safe values

[Aaron Ecay]

Hi Nicolas,

2015ko azaroak 6an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> BIND keywords should be used for controlling export, rather than the
>> usual emacs method of setting file local variables
>> .
> 
> In this message, I say that file local variables may not replace BIND
> keywords (although, I still cannot remember why).
> 
> However, BIND keywords cannot replace file local variables, because some
> variables are used outside of `org-export-as'. `org-latex-compiler'
> comes to mind.

You are right, both are needed.  Maybe org-mode (the function, i.e. the
code executed when opening an org-mode file) should look for BIND keywords
and set local variables according to them.  Otherwise people might need
the same entry in BIND and the local variables block.  WDYT?

(Of course, it would be even better if we could convince ourselves that
local variables will work 100% of the time for export – then the use
case for BIND would be restricted to setupfiles.  I tried to see if I
could convince myself of this, but quickly got lost.)

> 
>> But, BIND keywords are currently disabled by default. We can’t turn
>> these on by default, as maliciously crafted documents could do nasty
>> things to a user’s emacs. The attached patch permits many interesting
>> usages of BIND keywords by allowing them to set variables by default,
>> as long as the value thus set is safe (as implemented by emacs’s
>> default file local variable code).
> 
> Sounds good.

OK.  I will push a patch to master with your suggestions.

Thanks,

-- 
Aaron Ecay

Re: [O] Conditional link export?

[Aaron Ecay]

Hi Oleh,

2015ko azaroak 7an, Oleh Krehel-ek idatzi zuen:
> 
> Aaron Ecay  writes:
> 
> Hi Aaron,
> 
> Thanks for the effort, I might use the code you suggested as a last
> resort:)
> 
> I think the issue here is extending the power of Org markup.
> 
> The task at hand is "Write a manual in Org that exports to both Texinfo
> and HTML", preferably with zero config outside of the Org file itself.
> Also preferably without any extra Elisp inside the Org file. Is Org-mode
> suitable for the task?

Extra elisp inside the org file is an important way of extending the
power of org markup.  Why don’t you want to use it?

> 
> Currently I have a few questions that I had trouble internet-searching:
> 
> 1. Does Org-mode support export-based #ifdef #endif escapes? 

Not in general.  For small pieces of text, you can use macros.
Something like:

#+macro: ifinfo (eval (if (org-export-derived-backend 
org-export-current-backend 'info) "$1" "$2"))

{{{ifinfo([[info:emacs#Pachages]],[[https://]])}}}

Note that the solution I gave you allows the links to be clickable in
the buffer, whereas a macro does not (sort of).

(Presently links in macro arguments are clickable but not
underlined/colored like links, but that’s because the buffer is parsed
differently for fontification than for export.  Eventually fontification
will use the export parser, and then I expect macro args will no longer
be able to contain clickable links.)

The restrictions on what you can put inside a macro are a bit complex (I
don’t claim to understand them fully myself), but approximately speaking
they must occur in running text (not src blocks, the value of property
drawers, #+keywords, etc) and the arguments must not contain a blank
line.

> Here's what I have currently:
> 
> You can read about ELPA in the Emacs manual, see 
> #+HTML:  href="https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;>(emacs)Packages.
> #+TEXINFO: @ref{Packages,,,emacs,}.
> 
> Note that I'm getting an unwanted newline after "see" in case of HTML
> export that I'd like to get rid of. Even if that problem is solved, it
> still looks a bit clunky.
> 
> Is there a way to make something like this work instead?
> 
> #+begin_src elisp :inline
> (cond
>   (ox-htmlp
>(ox-html-link
> "(emacs)Packages"
> 
> "https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;))
>   (ox-texinfop
>(ox-texinfo-link
> "info:emacs#Packages")))
> #+end_src
>

See, even you can’t resist putting elisp in.  :P  You could give the
your pseudocode a #+name and then call it as an inline babel call.
But that would be almost exactly the same as the macro approach (but
more complicated).

> 2. Does Org-mode support the kbd markup for denoting keyboard shortcuts?
> I'm guessing that the answer is no, which is a shame since both Texinfo
> and Github/StackExchange-flavored Markdown support it.

No.  There was recently a thread on small caps syntax:

where many of the same themes come up.

There’s not enough consensus at present to add any new markup types to
org syntax.  Macros can be made to serve many of the same functions,
though.

> 
> Currently I've customized my Org to export =foo= as code, and ~foo~ as
> foo. Could we have this or a similar markup as the built-in
> default? Since Org-mode has so much to do with Emacs, having kbd tags
> would be very convenient.  In some odd cases, ~foo~ wasn't working for
> me and I've had to use @@html:@@"@@html:@@, which looks quite
> ugly.

You could use:

#+macro: kbd @@html:@@$1@@html:@@ @@info:@kbd{@@$1@@info:}@@ 
@@latex:...@@

It’s long and ugly, but it works for however many backends you care to
add.  I left a space between the different backends for clarity; you’ll
need to remove this in your actual document though.

> 
> 3. I really like http://orgmode.org/manual/index.html. How would I go
> about producing something like that (i.e. where can I find the sources)?
> Each time I've seen HTML export, it's always a single page. How to
> export each heading to its own page and have them all linked?

AFAIK that is produced by converting a texinfo document to html using
texinfo, not by org’s html exporter.  There must be a way to have
multi-page html documents, perhaps using ox-publish.  I’m not familiar
with them though.

> 
> 4. Is Org-mode powerful enough to have all of Emacs' manuals re-written
> in it, without any change in the final Info output?

In a trivial sense yes, using a file consisting solely of:

#+begin_info

#+end_info

Someone ported the org manual to org format in a non-trivial way a
couple of years ago .
It generated a lot of discussion but was never finally adopted.  I
believe that was due more to the difficulty in integrating the build
process rather than anything wrong with the org 

Re: [O] Conditional link export?

[Oleh Krehel]

Aaron Ecay  writes:

Hi Aaron,

Thanks for the effort, I might use the code you suggested as a last
resort:)

I think the issue here is extending the power of Org markup.

The task at hand is "Write a manual in Org that exports to both Texinfo
and HTML", preferably with zero config outside of the Org file itself.
Also preferably without any extra Elisp inside the Org file. Is Org-mode
suitable for the task?

Currently I have a few questions that I had trouble internet-searching:

1. Does Org-mode support export-based #ifdef #endif escapes? Here's what
I have currently:

You can read about ELPA in the Emacs manual, see 
#+HTML: https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;>(emacs)Packages.
#+TEXINFO: @ref{Packages,,,emacs,}.

Note that I'm getting an unwanted newline after "see" in case of HTML
export that I'd like to get rid of. Even if that problem is solved, it
still looks a bit clunky.

Is there a way to make something like this work instead?

#+begin_src elisp :inline
(cond
  (ox-htmlp
   (ox-html-link
"(emacs)Packages"

"https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;))
  (ox-texinfop
   (ox-texinfo-link
"info:emacs#Packages")))
#+end_src

2. Does Org-mode support the kbd markup for denoting keyboard shortcuts?
I'm guessing that the answer is no, which is a shame since both Texinfo
and Github/StackExchange-flavored Markdown support it.

Currently I've customized my Org to export =foo= as code, and ~foo~ as
foo. Could we have this or a similar markup as the built-in
default? Since Org-mode has so much to do with Emacs, having kbd tags
would be very convenient.  In some odd cases, ~foo~ wasn't working for
me and I've had to use @@html:@@"@@html:@@, which looks quite
ugly.

3. I really like http://orgmode.org/manual/index.html. How would I go
about producing something like that (i.e. where can I find the sources)?
Each time I've seen HTML export, it's always a single page. How to
export each heading to its own page and have them all linked?

4. Is Org-mode powerful enough to have all of Emacs' manuals re-written
in it, without any change in the final Info output?

regards,
Oleh

Re: [O] Inconsistency between org-store-link-functions and org-store-link

[Aaron Ecay]

Hi Nicolas,

2015ko azaroak 6an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> The docstring of org-store-link-functions says: “Each function will be
>> called in turn until one returns a non-nil value.”  However, the code of
>> org-store-link actually calls all the functions, and if more than one
>> returns a non-nil value raises a prompt asking the user to choose (and
>> then calls that function a second time).
>> 
>> Should we change the code to match the doc, or vice versa?
> 
> The former, IMO.

OK, will do.

[...]

> 
> P.S: next release is AFAIK "8.4", not "9.0", you may want to update your
> recent changes advertising the latter. Thank you.

I’m confused.  My impression of Bastien’s decision
 is that Org 8.4 should be
compatible with emacs 23.  Master contains changes that require emacs 24
(to give one example, files that require cl-lib).  So, I thought master
was going to become Org 9.0, and the 8.4 release would be cut from
either maint or an earlier revision of master before emacs24-only
changes were introduced.

-- 
Aaron Ecay

Re: [O] Lexical binding bug in org-list.el?

[Aaron Ecay]

Hi Nicolas,

2015ko azaroak 7an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay  writes:
> 
>> The org-list code is a mess, and I think we should hold off on converting
>> it to lexical scoping until it can be refactored in a more dedicated
>> way.
> 
> It seems a bit strong considering there's only one issue so far. I don't
> think the code is a mess, but "Send and receive lists" part clearly
> needs an overhaul.
> 
>> Nonetheless I include the patch, in case it’s helpful to anyone.
> 
> Lifting `org-list--get-text', `org-list--parse-item', etc. isn't
> necessary. 

I’ll defer to your judgment, of course, especially where it comes to
fixing the immediate issue.

On a broader scope, this is just one part of org that is written in this
style (one large let that defines many functions which call each other;
the body of the let is just a call into one of these functions).  This
isn’t idiomatic elisp (at least, I’ve never seen it outside org), and it
seems suboptimal for at least two reasons:
1. The interface between the functions isn’t well-defined – they could
   exchange information via arguments and/or by modifying variables
   introduced by their containing let.
2. It’s impossible to unit test the small let-bound functions.

In view of this, do you think it would be desirable in the long term to
refactor code like this into top-level functions?

> I just forgot a `letrec' in `org-list-parse-list'.

Oh ok.  I had never seen letrec before these recent lexical binding
changes, so I wasn’t familiar with how it could fix the problems.  But
I’m glad it can.

> [...]

I originally wrote individual responses to the points in the rest of
your email, but then I realized that it’s slightly more than a year
since we had an eerily similar discussion:
.  I don’t think we
reached any conclusion then.  To avoid the same thing happening, I’m
going to try to step back and sketch the vision I have about this code
from a high-level perspective.

If it was up to me, there would be only three kinds of code touching
lists in org:
- code that manipulates org-elements objects and (where necessary)
  converts them to strings using the exporter
- a single function in ob-core that takes org-elements lists and converts
  them into a simple nested list format, for use as input to babel code
  blocks
- a single function in ob-core that is the inverse of the one above, for
  processing the output of code blocks

I think this implies:
- org-list-parse-list deprecated/removed
- org-list-to-generic deprecated/removed
- callers of these two functions updated to use org-elements/ox (with new
  helper functions introduced for this purpose if it seems necessary)

The simplicity gains from this would be:
- fewer functions in the public API of org (org-list-parse-list is replaced
  by preexisting org-elements functions, and org-list-to-generic by ox
  functions)
- hopefully less code to maintain (in terms of lines), though it remains
  to be seen how much or if at all these changes actually shrink the
  code base
- all org code manipulating lists uses a single format (org-elements).
  Babel code blocks are not org code (and often not in elisp), so they
  are the only thing that gets to use a different format
- the plist format controlling org-list-to-generic goes away

You said:

> Actually, `org-list-to-generic' in its current form isn't adequate for
> anything. Even `org-list-to-*' functions do not use it.

And

> we can re-implement `org-list-to-subtree' without using
> `org-list-to-generic'.

Which I think means we are on more or less the same page about
org-list-to-generic.  You also said:

> `org-list-parse-list' should be simplified, too, as its current return
> value is useless (e.g., nothing uses [CBON] anymore in the code base).

Here I’m more radical than you: since the current return value is useless
(I agree) and hardly used anywhere, my conclusion is to just get rid of
the function, rather than trying to invent a way in which it could be
useful.

I hope that having laid it out in this way helps to understand what I
have in mind.  I’d of course be very glad to hear what your thoughts
are, and hopefully we’ll be able to work out how to proceed.

-- 
Aaron Ecay

Re: [O] [RFC] [PATCH] allow bind keywords to set safe values

[Aaron Ecay]

Hi Thomas,

2015ko azaroak 6an, "Thomas S. Dye"-ek idatzi zuen:
> 
> Aloha Aaron,
> 
> Aaron Ecay  writes:
> 
>> Hello all,
>> 
>> BIND keywords should be used for controlling export, rather than the
>> usual emacs method of setting file local variables
>> .  But,
>> BIND keywords are currently disabled by default.  We can’t turn these on
>> by default, as maliciously crafted documents could do nasty things to a
>> user’s emacs.  The attached patch permits many interesting usages of
>> BIND keywords by allowing them to set variables by default, as long as
>> the value thus set is safe (as implemented by emacs’s default file local
>> variable code).
> 
> The prescription that BIND keywords should be used over local variables
> caught me by surprise.  Nicolas' post about a vague recollection that
> some local variables might not be picked up during export seems an odd
> motivation for the prescription.  I've used local variables to control
> export for a long time without running into this problem.
> 
> I'm not complaining, just commenting on an unusual sequence of events on
> the mailing list.  
> 
> I'm happy to migrate my local variables to BIND if that is what I should
> do.

The export process is complicated, involving at least one clone being
made of the org buffer.  If it’s async export, the clone is made in
another emacs process.

There’s a concern that some time in this process, local variable lines
could be lost.  This could happen because:
- hack-local-variables doesn’t get called when it should
- the lines themselves are deleted (because of being in a COMMENT or
  noexport subtree)
BIND keywords don’t rely on hack-local-variables, and would typically be
located in the preamble of the document.  So they should be immune to
these factors.  There’s also an issue with #+INCLUDE keywords, which
will bring in BINDs from the included file, but (AFAICS) not local
variable lines.

I tried to take a look at the export code.  I’m 99% certain that any
local variables with the org- prefix will be successfully maintained at
all relevant steps of the export process.  But the code is complex, and
I couldn’t reach 100% certainty.  It would be better (more reassuring)
if someone could reach that level of certainty.  Then we could tell
people that it doesn’t matter whether they use BIND or a local variable
(which is what I wish I could say to you now).

If you’ve used local variables and are happy with how they have worked I
think nothing bad will happen if you leave them as is.  But that’s just,
like, my opinion man.

> 
> That said, it would be great if one could use EXPORT_BIND to control
> export at the subtree export level.  I'm keeping separate HTML and LaTeX
> export projects in the same file fairly often now and it can be
> difficult (for me) to structure the whole file properly so both exports
> work as expected.

This is an excellent idea IMO.

> 
> BTW, many thanks for your recent interest in and work on Babel.  It is
> an important part of my work flow and I've been uneasy since Eric
> orphaned the project a while back.  I hope you find the work there
> rewarding enough to keep up.

I’ll do my best!  Thanks for the kind words.

-- 
Aaron Ecay

Re: [O] [PATCH][BUG] org-babel-confirm-evaluate

[Aaron Ecay]

Hi Chuck,

The patch is fundamentally correct, please push it.  A couple minor
comments:

2015ko azaroak 7an, "Charles C. Berry"-ek idatzi zuen:

[...]

> +  (`query (or
> +(and (not (org-bound-and-true-p
> +   org-babel-confirm-evaluate-answer-no))
> + (yes-or-no-p
> +  (format "Evaluate this %s code block%s on your system? "
  ^^^
Rather than inserting that space, you should make the no-name value of
name-string a single space.  Otherwise there will be two spaces if the
block does have a name.

> +  lang name-string)))
> +(and
> + (message "Evaluation of this %s code-block%s is aborted."
> +  lang name-string)
> + nil)))

I think ‘progn’ would be better than ‘and’ here, just as a matter of
style.  Same comment as above applies about the extra space.

Thanks very much for the patch, and sorry for the breakage,
Aaron

PS Git gave me some strange errors about trailing whitespace when trying
to apply your patch, until I converted it from DOS to Unix line
endings.  I’ve never seen git do that before – I think it usually copes
very well with different line ending styles.  Does anyone know what to
do in this scenario?  Manually changing the line endings of the patch
file seems hackish.

-- 
Aaron Ecay

Re: [O] Emacs+org-mode in a Docker?

[Stelian Iancu]

On 07/11/15 08:00, Grant Rettke wrote:

On Wed, Nov 4, 2015 at 7:07 PM, John Kitchin  wrote:

Thanks for all the notes! It looks like a not too trivial exercise that
might have to be a summer project for me.


For the past year, I've been curious about how to make my Emacs
environment available to me and anyone else, easily. Goal is to make
working on a Linux, Windows, or OSX GUI a one-click setup. For me,
Vagrant is the obvious solution here. Vagrant and Packer,
specifically.

The benefit of using Packer to build a Vagrant image is that the user
doesn't have to wait for the download and installation of big stuff
like TeXLive. That get's me curious if we (all Emacs/Org users) might
want to build a base-image that includes all the stuff out there.
Might make it easy for users to try out lots of different configs
without having to deal with all of the software requirements. While
that isn't a "big deal", it is just easier for them so they can focus
on doing stuff with Org.



This is a good idea, I'm personally using Vagrant for a lot of 
development related stuff.


However the users still have to download the base box image initially 
and that can be many GBs, depending on what you include in it.


Also, would you include Xorg and thus the ability to run Emacs in 
graphical mode or only a terminal-based Emacs?


S.

[O] org-export to beamer

[Jérémie Juste]

I want to export org to beamer. It worked well previously when I press
C-c C-e l O. But in recent days, when I press C-c C-e l, the options
for beamer are missing. I can only export to pdf, not beamer.

What?s the problem, and what can I do?

Thanks a lot!


Hello,

In the last version of org-mode you only need to activate beamer-mode.
M-x beamer-mode. Then you are good to go with C-c C-e l O

you can also do
M-x org-beamer-export-to-pdf and bind it to a key of your preference.



-- 
Jérémie Juste

Re: [O] [PATCH][BUG] org-babel-confirm-evaluate

[Aaron Ecay]

Hi Chuck,

2015ko azaroak 7an, "Charles C. Berry"-ek idatzi zuen:
> 
> 
> Thanks for the comments. I've revised as suggested. The patch has been 
> pushed as

Thanks.

> 
> Strange.
> 
> I produced the patch on Mac OS X 10.11.1 with the usual
> 
>   git format-patch master -o 
> 
> command line using
> 
>   git version 2.4.9 (Apple Git-60)
> 
> and sent it as an email attachment using alpine as the client.

Strange indeed.  I re-downloaded the patch file from gmail (in case my
MUA had done something perverse) and checked it with emacs and even a
hex editor – it definitely has \r\n line endings.  Mysteries of life I
suppose.  :)

-- 
Aaron Ecay

Re: [O] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Nicolas Goaziou]

"Charles C. Berry"  writes:

> On Thu, 5 Nov 2015, Nicolas Goaziou wrote:
> [...]
>> Would you want to provide a patch for that (and commit it while you're
>> at it)?
>>
>
> Done.

Thank you.

Regards,

Re: [O] problems with export and :cache

[Aaron Ecay]

Hi Achim,

2015ko azaroak 7an, Achim Gratz-ek idatzi zuen:
> Your commit 0d000f5680 implementing this (I can't find the push
> announced on the list, so I hope it's OK to piggy-back on here) breaks
> the test ob-awk/tabular-input.

Thanks for the report.  Fixed in 4773baf.

-- 
Aaron Ecay

Re: [O] Lexical binding bug in org-list.el?

[Aaron Ecay]

Hi Nicolas,

2015ko azaroak 7an, Nicolas Goaziou-ek idatzi zuen:
> 
> Aaron Ecay  writes:
> 
>> On a broader scope, this is just one part of org that is written in this
>> style (one large let that defines many functions which call each other;
>> the body of the let is just a call into one of these functions).  This
>> isn’t idiomatic elisp (at least, I’ve never seen it outside org), and it
>> seems suboptimal for at least two reasons:
>> 1. The interface between the functions isn’t well-defined – they could
>> exchange information via arguments and/or by modifying variables
>> introduced by their containing let.
> 
> They are mutually recursive functions. I don't think that is
> un-idiomatic in the Lisp world. I don't think why the reason above would
> make them sub-optimal, too.

I guess it’s a scheme-ism.  .
Grepping for it in emacs sources, I see 4 uses in vc-* libraries, 1 in
octave, and 1 in emacs-lisp mode.  cl-labels is also implemented in
terms of letrec.  Org has 16 uses so far, all of them introduced since
the lexical binding change (or in any case since the last merge with
emacs).

I’m not saying we shouldn’t use it just because it’s rare, or a
scheme-ism.  Just satisfying my own curiosity out loud.  :)

> 
>> 2. It’s impossible to unit test the small let-bound functions.
> 
> Why would you want to unit test them? They are an implementation detail.
> Only `org-list-parse-list' should be tested here.

I don’t think we should unit-test only public API functions.  Indeed, I
find it easier to write unit tests for small functions, since I don’t
have to construct a lot of extra context to exercise all the corner
cases.

> 
>> In view of this, do you think it would be desirable in the long term to
>> refactor code like this into top-level functions?
> 
> No, I don't. I see no reason to pollute name space with these very
> specific functions.

I’m not sure I get it – interned symbols are cheap, and with the new-ish
double-dash convention for private functions users/downstream developers
can be pretty sure they don’t need to worry about them.

If it’s for us as org devs, I think the benefits outweigh the drawback
of having the extra function names to sift through in code completion
popups (which is the only one I can think of).  But opinions can differ,
and maybe I haven’t considered all the potential negatives.

[...]

> My take on the problem at hand is
> 
>   - change `org-list-parse-list' to provide a simpler output and update
> Babel should to use that new output.
> 
>   - re-implement `org-list-to-subtree' using directly Elements, or even
> string massaging.

OK, these both sound do-able.

> 
>   - start a poll on the ML to guess the potential user base for radio
> lists. Depending on the results, we might either deprecate the whole
> thing, as you suggest, or implement in a more powerful and clean
> way. Note that first item implies `org-list-to-generic' should be
> updated to handle new output for `org-list-parse-list'.

Given that no one’s ever asked for better radio lists despite us
advertising the feature and its unflattering comparison with more
powerful radio tables, I doubt there will be any interest.  But it’s
worth asking.  Should one of us start a new thread to ask this question?

-- 
Aaron Ecay

Re: [O] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Charles C. Berry]

On Thu, 5 Nov 2015, Nicolas Goaziou wrote:
[...]

Would you want to provide a patch for that (and commit it while you're
at it)?



Done.

Chuck

Re: [O] Lexical binding bug in org-list.el?

[Nicolas Goaziou]

Aaron Ecay  writes:

> On a broader scope, this is just one part of org that is written in this
> style (one large let that defines many functions which call each other;
> the body of the let is just a call into one of these functions).  This
> isn’t idiomatic elisp (at least, I’ve never seen it outside org), and it
> seems suboptimal for at least two reasons:
> 1. The interface between the functions isn’t well-defined – they could
>exchange information via arguments and/or by modifying variables
>introduced by their containing let.

They are mutually recursive functions. I don't think that is
un-idiomatic in the Lisp world. I don't think why the reason above would
make them sub-optimal, too.

> 2. It’s impossible to unit test the small let-bound functions.

Why would you want to unit test them? They are an implementation detail.
Only `org-list-parse-list' should be tested here.

> In view of this, do you think it would be desirable in the long term to
> refactor code like this into top-level functions?

No, I don't. I see no reason to pollute name space with these very
specific functions.

> If it was up to me, there would be only three kinds of code touching
> lists in org:
> - code that manipulates org-elements objects and (where necessary)
>   converts them to strings using the exporter
> - a single function in ob-core that takes org-elements lists and converts
>   them into a simple nested list format, for use as input to babel code
>   blocks
> - a single function in ob-core that is the inverse of the one above, for
>   processing the output of code blocks
>
> I think this implies:
> - org-list-parse-list deprecated/removed
> - org-list-to-generic deprecated/removed
> - callers of these two functions updated to use org-elements/ox (with new
>   helper functions introduced for this purpose if it seems necessary)
>
> The simplicity gains from this would be:
> - fewer functions in the public API of org (org-list-parse-list is replaced
>   by preexisting org-elements functions, and org-list-to-generic by ox
>   functions)
> - hopefully less code to maintain (in terms of lines), though it remains
>   to be seen how much or if at all these changes actually shrink the
>   code base
> - all org code manipulating lists uses a single format (org-elements).
>   Babel code blocks are not org code (and often not in elisp), so they
>   are the only thing that gets to use a different format
> - the plist format controlling org-list-to-generic goes away

Like for radio tables, radio lists are meant to be used in foreign
buffers, i.e., buffers not in Org mode. They have almost the same
requirements as Babel code blocks, which explains why they share the
same representation. The same happens with radio tables, which provide
their own representation to Babel, through `org-table-to-lisp'. If only
for symmetry, Org List should be the provider of any list
representation.

Moreover, `org-table-to-generic' is a powerful and flexible thin wrapper
around Org Export. In particular, `org-table-to-latex' is quite
different from calling `org-latex-export-to-latex' on an Org list.
Similarly, `org-list-to-generic' could be implemented as such, and,
therefore, may not be discarded too easily.

I'm not married to radio lists, and I wouldn't mind them being removed,
but, if they are to be kept, they should at least be implemented
correctly, not left in their current dumbed down state. Unfortunately,
if I had to guess, I'd say that radio lists have no user, unlike to
radio tables (which have their own video on a popular site).

My take on the problem at hand is

  - change `org-list-parse-list' to provide a simpler output and update
Babel should to use that new output.

  - re-implement `org-list-to-subtree' using directly Elements, or even
string massaging.

  - start a poll on the ML to guess the potential user base for radio
lists. Depending on the results, we might either deprecate the whole
thing, as you suggest, or implement in a more powerful and clean
way. Note that first item implies `org-list-to-generic' should be
updated to handle new output for `org-list-parse-list'.


Regards,

Re: [O] Inconsistency between org-store-link-functions and org-store-link

[Nicolas Goaziou]

Aaron Ecay  writes:

> I’m confused.  My impression of Bastien’s decision
>  is that Org 8.4 should be
> compatible with emacs 23.  Master contains changes that require emacs 24
> (to give one example, files that require cl-lib).  So, I thought master
> was going to become Org 9.0, and the 8.4 release would be cut from
> either maint or an earlier revision of master before emacs24-only
> changes were introduced.

Fair enough. I changed references to Org 8.4 into references to Org 9.0
in master.

Regards,

Re: [O] [PATCH][BUG] org-babel-confirm-evaluate

[Charles C. Berry]

On Sat, 7 Nov 2015, Aaron Ecay wrote:


Hi Chuck,

The patch is fundamentally correct, please push it.  A couple minor
comments:



Thanks for the comments. I've revised as suggested. The patch has been 
pushed as


  commit 3f6e71e62e558f4a1c4316c9ecf0519a905e87f3
  Author: Charles Berry 
  Date:   Fri Nov 6 16:00:50 2015 -0800




PS Git gave me some strange errors about trailing whitespace when trying
to apply your patch, until I converted it from DOS to Unix line
endings.  I’ve never seen git do that before – I think it usually copes
very well with different line ending styles.  Does anyone know what to
do in this scenario?  Manually changing the line endings of the patch
file seems hackish.


Strange.

I produced the patch on Mac OS X 10.11.1 with the usual

git format-patch master -o 

command line using

git version 2.4.9 (Apple Git-60)

and sent it as an email attachment using alpine as the client.

Chuck

Re: [O] Conditional link export?

[Achim Gratz]

Aaron Ecay writes:
> Someone ported the org manual to org format in a non-trivial way a
> couple of years ago .
> It generated a lot of discussion but was never finally adopted.  I
> believe that was due more to the difficulty in integrating the build
> process rather than anything wrong with the org version of the manual
> per se.  Speed may have also been a concern, but I expect the exporter
> to have gotten much faster in the intervening years.

The build process wasn't a problem, but speed arguably still is.  I
still have the corresponding extension in my local.mk file (I also
posted them on the list for others to re-use).


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] problems with export and :cache

[Achim Gratz]

Aaron Ecay writes:
>> Another option is to extend `org-babel-get-header' to accept a list of
>> keys instead of a single key.
>
> I’d like to remove this function, actually.  I hate the org functions
> that do X most of the time, but the opposite of X when you pass them
> an optional argument (in this case the third arg ‘other’).  Almost
> all (a couple dozen in total) of the calls to o-b-get-header are in
> the context (mapcar #'cdr (org-babel-get-header params :var)).  I’d
> like to introduce a function org-babel--get-var-values to cover these
> cases, and replace the remaining 2 calls in the codebase (which both
> extract :column-names) with assq (since :column-names should appear
> maximally once, unlike :var).  The sole use of the evil 'other arg is
> refactored away by my patch.

Your commit 0d000f5680 implementing this (I can't find the push
announced on the list, so I hope it's OK to piggy-back on here) breaks
the test ob-awk/tabular-input.


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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: [O] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Charles C. Berry]

On Sat, 7 Nov 2015, Cook, Malcolm wrote:


Thanks Chuck for setting this through.


[...]


I've wondered if there is not a better way for Babel to share an 
interactive session with the user.  For instance, if we wanted to 
support a new form of results processing on addition to value and 
output Namely, "transcript", wherein the results of evaluating a 
source block would be a transcript of the season with statements 
interwoven with their respective outputs I suspect that this would 
not be easy extension of the current approach since it would require 
parsing the source into statements that get evaluated sequentially with 
visible results echoed into the transcript.


You can do stuff like this using babel and some R code.

Here is a start:

--8<---cut here---start->8---
#+NAME: my-block
#+BEGIN_SRC R :eval no
ls()
a <- 1
sqrt(a+2)
ls()
#+END_SRC


#+BEGIN_SRC R :session :noweb yes :results value raw :wrap example
capture.output(
source(textConnection("
  <>
  "),
  echo=T,print=T))
#+END_SRC

#+RESULTS:
#+BEGIN_example


ls()

[1] "a"


a <- 1



sqrt(a+2)

[1] 1.732051


ls()

[1] "a"
#+END_example


--8<---cut here---end--->8---

I suppose you would want `:exports results'.

Best,
Chuck

Re: [O] BUG: emacs orgmode ob-R.el function org-babel-R-evaluate-session over aggressively performs "; ; cleanup extra prompts left in output" and a possible workaround

[Cook, Malcolm]

Thanks Chuck for setting this through.

I've never been happy at how Babel arranged the inter process communication 
with R  including the need for cleaning up the output with scary regular 
expressions like this.

Also there are some of uses of temp files that sometime cause of bugs 
especially when running R under tramp on a remote host. I'll be sure to report 
it next time I see it.

I've wondered if there is not a better way for Babel to share an interactive 
session with the user.   For instance, if we wanted to support a new form of 
results processing on addition to value and output Namely, "transcript", 
wherein the results of evaluating a source block would be a transcript of the 
season with statements interwoven with their respective outputs I suspect 
that this would not be easy extension of the current approach since it would 
require parsing the source into statements that get evaluated sequentially with 
visible results echoed into the transcript.

But I digress.

Thanks again for running with my workaround

On Nov 7, 2015 3:31 PM, "Charles C. Berry"  wrote:
On Thu, 5 Nov 2015, Nicolas Goaziou wrote:
[...]
> Would you want to provide a patch for that (and commit it while you're
> at it)?
>

Done.

Chuck

Re: [O] problems with export and :cache

[Achim Gratz]

Aaron Ecay writes:
>> Your commit 0d000f5680 implementing this (I can't find the push
>> announced on the list, so I hope it's OK to piggy-back on here) breaks
>> the test ob-awk/tabular-input.
>
> Thanks for the report.  Fixed in 4773baf.

Fix confirmed, thank you.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[O] visual-fill-column-mode with org

[Vikas Rawal]

I would like to use visual-fill-column-mode with my org files. However, this 
has a peculiar problem that org tables also start wrapping at fill-column. Does 
anyone use visual-fill-column-mode with org and has found a way of telling it 
to ignore lines starting with a |?

Thanks,

Vikas

[O] org/android sync

[Nick Dokos]

There was a  G+ post in the orgmode community
pointing to 

   http://www.orgzly.com/

No idea whether it works or not but I figured if you
have an android phone, here's another opportunity to
bury your face in it :-)

-- 
Nick