Re: [O] how to get images support in Emacs on Windows?

[Ista Zahn]

You could use http://vgoulet.act.ulaval.ca/en/emacs/windows/ which comes
bundled with image support (and other stuff that you may or may not want).
On Feb 19, 2015 6:20 PM, Herbert Sitz hes...@gmail.com wrote:

 I'm trying to use inline images on Windows and (I think?) I've gotten to
 the
 point where I understand that this is not available with the standard GNU
 Emacs installation on Windows.  My understanding is that I need an
 image.dll that I can put in the bin directory.  I think that comes as
 part
 of EmacsW32 install, but that install seems to be packaged as a single
 executable, not sure how to get image.dll without running a full install of
 EmacsW32, which I don't think I want.

 So, am I correct in understanding that all I need is that 'image.dll' to
 get
 inline image support on Windows (I'm running v24.4 of Emacs).  If not, what
 more do I need to do?  And how can I get (or make) a copy of that .dll?

 Thanks,

 Herbert

Re: [O] about htmlize.el

[Ista Zahn]

It looks like that was created just by calling 'htmlize-buffer' three
times with different visibility cycling. Does that work for you?

Best,
Ista

On Thu, Mar 12, 2015 at 12:25 PM, XIE Yuheng xyh...@gmail.com wrote:


 what I wish is org mode like web page
 see ::
   
 http://the-little-language-designer.github.io/org-html/cicada-nymph/overview.html

 On 03/12/2015 04:20 PM, Eric S Fraga wrote:
 On Wednesday, 11 Mar 2015 at 02:01, XIE Yuheng wrote:
 Hi friends ^-^,
 it is me again.
 can you guys hack htmlize.el for me,
 to make it an org-html with better support to view exported
 org-mode file online ?
 (only viewing, no editing)

 See info: (org) HTML export

Re: [O] render - as rarr on html export?

[Ista Zahn]

Not an answer to your question, but alternative: the company-math[1]
package makes it really easy to insert unicode.

Best,
Ista

[1] https://github.com/vspinu/company-math

On Mon, Mar 23, 2015 at 12:23 PM, Matt Price mopto...@gmail.com wrote:
 I feel like I've seen the answer to this somewhere but I can't find it -- is
 it possible for me to get - and = to render as rightarrows (→, ⇒)?

 \rightarrow will work, but doesn't give me the visual cue I want when
 working in org. And entering unicode directly in org is pretty distracting
 for me, as the gnome unicode shortcuts seem to turn themselves on and off
 whenever I upgrade.

 thanks!
 m

Re: [O] Latex export or Latex tangle? Best practice?

[Ista Zahn]

I would use LaTeX code blocks when I need to write something in LaTeX
that isn't easy to write in org mode, not to distinguish what is a
note and what is part of the draft. For that I recommend comments,
e.g.,


### Start example ###

* Section 1
** COMMENT Some rough draft notes to myself
 yadda yadda more badda
** Some stuff that should be exported
This is the actual important stuff that should be exported
*** More stuff that should be exported
yadda yada
*** COMMENT More notes and stuff don't export
*** Export this one too
bla bla

### End example ###

When you export the commented sections will be excluded.

Best,
Ista
On Mon, Apr 27, 2015 at 2:12 PM, Lawrence Bottorff borg...@gmail.com wrote:
 In a previous post I was getting at the issue of whether I should just do
 regular export or use latex code blocks for what I wanted in a final
 document. What I want is the ability to create a big, rambling, annotated
 org file -- with keeper stuff inside the latex babel blocks -- then tangle
 the .org file, thereby leaving all the annotations and lead-up notes behind.
 I'm sure I'm not alone in wanting notes to evolve into a finished
 product and orgmode would seem to offer a good path. So, I don't want to
 have to hand-edit out my so-called annotations. Is keeping the good stuff in
 latex babel blocks a best practice?

 LB

Re: [O] org-babel R ascii results: unable to export table

[Ista Zahn]

Hi Marco,

Here is a fairly minimal example to get you started:

 Begin Example 

#+PROPERTY: header-args:R :session *R* :results output drawer :exports both

#+BEGIN_SRC R
  library(ascii)
  options(asciiType=org)
#+END_SRC

#+BEGIN_SRC R
  ascii(mtcars[1:5, 1:5])
#+END_SRC

#+BEGIN_SRC R
  ascii(summary(lm(hp ~ wt, data = mtcars)))
#+END_SRC


### End Example

First execute the code blocks with 'M-x org-babel-execute-buffer' then
export. For more control I would refer to the manual section at
http://orgmode.org/manual/Working-With-Source-Code.html#Working-With-Source-Code

Best,
Ista

On Thu, Apr 30, 2015 at 7:32 AM, Marco Barbàra jab...@gmail.com wrote:
 Dear org-mode community,

 First, I want to apologize for subscribing mainly because I need help.

 I recently started using org-mode as a tool for reproducible research
 (trying to do R-based literate programming).

 What I'm trying to is explained in this example file:
 http://orgmode.org/worg/org-contrib/babel/examples/ascii.org
 which I downloaded trying to understand how to export R output produced
 with the R 'ascii' package.

 Running this example, after adding :exports results to
 ascii-example3 block, _on the first attempt_, the output was exported
 as an odt table (i was happy, this is my desired outcome). But
 afterwards, any subsequent attempts to export the same block resulted in
 a verbatim block, which is the same problem I was trying to solve.

 I tried to export as a latex buffer too, and even there i got a verbatim
 environment.

 I don't think it is bug, it is probably that I still don't understand
 org-babel well.

 Sorry not to provide any other sample code, but I wouldn't know where
 to begin.

 Any advice would be very appreciated.

 Thank you very much

 Marco Barbara

Re: [O] Fortran missing in List of supported code block languages?

[Ista Zahn]

On Thu, May 14, 2015 at 8:37 AM,  alain.coch...@unistra.fr wrote:
 John Kitchin writes:

   Fortran is supported in the sense that you can edit a block in
   Fortran mode. But you cannot execute a Fortran block directly
   afaik. You have to tangle it, compile it and then run the
   executable.

That is not true, you can in fact execute fortran blocks directly.
ob-fortran.el has been part of org since 2011. IMO it is a
documentation bug that it is not listed as a supported language.

Best,
Ista


 Thanks for the precision.  I guess it would not hurt to mention this
 kind of details in the doc, to some extent at least.

   For example like this:
  
   
 http://kitchingroup.cheme.cmu.edu/blog/2014/02/04/Literate-programming-example-with-Fortran-and-org-mode/

 Very helpful.  Seems to me that having such examples (at least the
 simple one) in the doc would be extremely helpful to beginners.

Re: [O] Help with alternative ipython session workflow

[Ista Zahn]

The settings described at
http://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg00793.html
seem to work for me. (I replaced --pylab=osx with --pylab since
I'm on Linux.)

Best
Ista

On Sat, Apr 11, 2015 at 7:09 PM, Giacomo M jackja...@gmail.com wrote:
 I have never been able to make org sessions getting along properly with
 ipython, so at the moment I'm using a sort of handmade hybrid between org
 and an ipython notebook, doing the following:
 1. Enter the first source block in a .org file
 2. Start an ipython instance with C-c C-c
 3. Keep the org/src buffer and *Python* buffer side by side
 4. Copy paragraph of code around cursor (keeping cursor in position) (I
 usually split sections of code I want to run individually with spaces)
 5. Select *Python* buffer
 6. Go to last position
 7. Type %paste
 8. Go back to other buffer (src/org)

 I probably sound like a caveman doing this over and over, but this is the
 most stable setup I could find. Plus I keep experimenting w/ code, and this
 gives me a very interactive environment. Macros helped me to automatize
 steps 4-8, but still it's not very flexible, e.g. I need the side-by-side
 buffers, with ipython already running.

 I was wondering whether anybody has any suggestions to improve this (and
 make me save some minutes of life every day), or any good reference to make
 ipython work smoothly with org src blocks

 Thanks,

 Giacomo

Re: [O] Problem with org-mode and minted

[Ista Zahn]

I think you just need to customize org-latex-minted-langs so that it
maps C to c, e.g.,

(add-to-list 'org-latex-minted-langs '(C c))

Best,
Ista

On Wed, Apr 8, 2015 at 8:11 AM, azubi az...@acm.org wrote:
 Hi all

 I've recently discovered babel (of org-mode) and I try to learn it.
 I've discovered a little problem that I cannot solve.

 Consider the following (almost) minimal example:

 
 * First example with language c

 #+BEGIN_SRC c :EXPORT results
 printf (First example \n);
 #+END_SRC

 * Second example with language C

 #+BEGIN_SRC C :EXPORT results
 printf (second example \n);
 #+END_SRC

 #+RESULTS:
 : second example
 

 The first example cannot be evaluated by a C-c C-c (?? due to the small c
 ??). The second example is evaluated without any problem.

 I've configured org-mode to use minted to colorize the source code when it
 is exported to latex.

 For the file above, the function org-export-latex-to-pdf gives the
 expected result for the first example but nothing for the second one (?? due
 to the big C ??). Minted understand c as a language but not C. The
 latex code produced by the command is (without the very long standard
 preamble):

 
 \begin{document}

 \maketitle
 \tableofcontents

 \section{First example with language c}
 \label{sec-1}

 \begin{minted}[]{c}
 printf (First example \n);
 \end{minted}
 \section{Second example with language C}
 \label{sec-2}

 \begin{minted}[]{C}
 printf (second example \n);
 \end{minted}
 % Emacs 24.3.1 (Org mode 8.2.4)
 \end{document}
 ===

 What have I done wrong ?

 Thank you in advance for your help.

Re: [O] latest org from Elpa error: Invalid function: org-babel-header-args-safe-fn

[Ista Zahn]

Unfortunately I now can't reproduce the problem, so I can't check if
my suggestion to byte compile ob-R.el works or not. When I did observe
the issue you describe that seemed to fix it, and at least one other
person confirmed that it worked for them as well.

Since it doesn't work for you I suggest removing org-plus-contrib (or
org), starting emacs with 'emacs -Q' and running something like

(require 'package)
(add-to-list 'package-archives
 '(org . http://orgmode.org/elpa/;) t)
(package-initialize)
(package-install 'org-plus-contrib)
;; or (package-install 'org)

Best,
Ista

On Sat, Aug 8, 2015 at 12:07 AM, Xebar Saram zelt...@gmail.com wrote:
 Hi Ista

 i did do a byte compiling but that didnt help. i got this message when i did
 byte compile

 Compiling no file at Sat Aug  8 07:06:30 2015
 Leaving directory `/home/zeltak/.emacs.d/elpa/ace-isearch-20150807.1803'
 Compiling file /home/zeltak/.emacs.d/elpa/org-20150805/ob-R.el at Sat Aug  8
 07:06:55 2015
 Entering directory `/home/zeltak/.emacs.d/elpa/org-20150805/'
 ob-R.el:72:11:Warning: reference to free variable
 `org-babel-safe-header-args'

 In end of data:
 ob-R.el:470:1:Warning: the following functions are not known to be defined:
 org-babel-header-args-safe-fn, org-babel-graphical-output-file

 best

 Z


 On Fri, Aug 7, 2015 at 10:01 PM, Ista Zahn istaz...@gmail.com wrote:

 We discussed this already in another thread[0]. The upshot was run
 M-x byte-compile-file on ob-R.el.

 Best,
 Ista
 [0] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg98762.html

 On Fri, Aug 7, 2015 at 12:47 PM, Xebar Saram zelt...@gmail.com wrote:
 
  Thx for the response Bastien
 
  i removed (require 'org-install) from my init.el file (correct?) and
  restarted emacs but get the same error
 
  Invalid function: org-babel-header-args-safe-fn
 
  i also tried now to downgrade to previous version from 3/8/15 and the
  error
  is gone so its 100% reproducible with the 5/8/15 elpa version
 
  thx again
 
  Z
 
 
 
  On Fri, Aug 7, 2015 at 6:33 PM, Bastien b...@gnu.org wrote:
 
  Hi Xebar,
 
  try removing (require 'org-install), it is not needed since long.
 
  --
   Bastien
 
 

Re: [O] user-error: No language for src block: (unnamed) when running `org-icalendar-combine-agenda-files`

[Ista Zahn]

On Fri, Aug 21, 2015 at 7:50 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
 Hello,

 JI, Xiang h...@xiangji.me writes:

 Well actually I think the error shows because of another block below
 the emacs-lisp blocks. In this header I just wrote #+BEGIN_SRC without
 any language name. Is it actually wrong and maybe I should have
 written #+BEGIN_EXAMPLE instead?

 Correct.

 Though I’d still say it probably shouldn’t have failed the export?…

 Babel blocks are executed prior to any export process, no matter what
 you want to include in the output.

Unless you've restored sanity by setting org-export-babel-evaluate to
nil. Personally I think this is not a good default. Source block
evaluation and export are distinct actions, and I don't see why they
should be linked by default.

Best,
Ista

Re: [O] user-error: No language for src block: (unnamed) when running `org-icalendar-combine-agenda-files`

[Ista Zahn]

On Fri, Aug 21, 2015 at 10:43 AM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
 Hi,

 Ista Zahn istaz...@gmail.com writes:
 On Fri, Aug 21, 2015 at 10:20 AM, Nicolas Goaziou
 m...@nicolasgoaziou.fr wrote:
 Ista Zahn istaz...@gmail.com writes:

 Unless you've restored sanity by setting org-export-babel-evaluate to
 nil. Personally I think this is not a good default. Source block
 evaluation and export are distinct actions, and I don't see why they
 should be linked by default.

 Wild guess:

 Principle of least surprise: setting it to nil means results from Babel
 code are not refreshed before export, without user realizing about it.
 I think most users would like them to be up-to-date before export. It
 seems sane to me.

 The problem is that if the code blocks are non-trivial it slows down
 the export. Changing one line of documentation and exporting
 re-evaluates all the code blocks, which for me often takes several
 minutes. The defaults work for trivial examples, but not my real-world
 use. Since it's easy to make it work how I want it to via
 org-export-babel-evaluate I don't mean to complain too much. I posted
 mostly to make sure the OP knows about org-export-babel-evaluate, in
 case disabling code block evaluation on export makes sense for them.


 I know that problem...

 Decoupling code block evaluation and export has the problem of
 decoupling code block evaluation and export ;-), though.  If you export
 your document without evaluating first, how can you be sure that the
 resulting document is based on the latest version of the code contained
 in the code blocks?

By calling org-babel-execute-buffer before exporting ;-)

The advantage of doing it this way is that you don't have to do that
if you haven't changed a code block.

  So, from my point of view the default is the safe
 option and, thus, fine.

I agree that it is safer. In my case its safer like a 10 MPH speed
limit. Safe yes, but too slow!



 Regards,
 Andreas

Re: [O] user-error: No language for src block: (unnamed) when running `org-icalendar-combine-agenda-files`

[Ista Zahn]

On Fri, Aug 21, 2015 at 10:20 AM, Nicolas Goaziou
m...@nicolasgoaziou.fr wrote:
 Ista Zahn istaz...@gmail.com writes:

 Unless you've restored sanity by setting org-export-babel-evaluate to
 nil. Personally I think this is not a good default. Source block
 evaluation and export are distinct actions, and I don't see why they
 should be linked by default.

 Wild guess:

 Principle of least surprise: setting it to nil means results from Babel
 code are not refreshed before export, without user realizing about it.
 I think most users would like them to be up-to-date before export. It
 seems sane to me.

The problem is that if the code blocks are non-trivial it slows down
the export. Changing one line of documentation and exporting
re-evaluates all the code blocks, which for me often takes several
minutes. The defaults work for trivial examples, but not my real-world
use. Since it's easy to make it work how I want it to via
org-export-babel-evaluate I don't mean to complain too much. I posted
mostly to make sure the OP knows about org-export-babel-evaluate, in
case disabling code block evaluation on export makes sense for them.


 In any case, I don't see the harm here. OP uses invalid syntax and is
 warned about that. I think it's a decent way to proceed.

Yes, I agree about that.

Best,
Ista


 Regards,

Re: [O] user-error: No language for src block: (unnamed) when running `org-icalendar-combine-agenda-files`

[Ista Zahn]

On Fri, Aug 21, 2015 at 11:04 AM, Nicolas Goaziou
m...@nicolasgoaziou.fr wrote:
 Ista Zahn istaz...@gmail.com writes:

 I agree that it is safer. In my case its safer like a 10 MPH speed
 limit. Safe yes, but too slow!

 Doesn't Babel :cache property help here?

It does actually, to my surprise. I have not been using :cache because
the documentation says

Note that the :cache header argument will not attempt to cache
results when the :session header argument is used

and since I almost always use :session I didn't expect this to work.
To my surprise it does (at least with R source blocks, I haven't
tested yet with others). Can I now rely on this to work even with
:session?

Best,
Ista


 Regards,

Re: [O] Stable releases

[Ista Zahn]

On Tue, Aug 11, 2015 at 1:18 PM, Scott Randby sran...@gmail.com wrote:
 While I've used Org's development version in the past, I stopped doing that
 due to my failure to learn how to use git (no time) and other issues. Now, I
 only use the stable releases. But the latest 8.3 release doesn't seem so
 stable to me, so I'd like some clarification about what the Org maintainers
 mean by a stable release. Perhaps this is too vague, so let me explain a
 bit.

[snip]


 I guess what I want to know, and maybe there is no answer, is how long
 should I wait before upgrading to a stable release?

One strategy is keeping an eye on the mailing list and waiting for bug
reports to die down before upgrading.

Org is by far the most
 important piece of software I use (I hate it when I can't use Org), and bugs
 (which I know can't be avoided) make it hard, even impossible, for me to get
 my real work done. If there is a way for me to minimize encountering bugs, I
 will appreciate a description of that way.

 Scott Randby

Re: [O] latest org from Elpa error: Invalid function: org-babel-header-args-safe-fn

[Ista Zahn]

We discussed this already in another thread[0]. The upshot was run
M-x byte-compile-file on ob-R.el.

Best,
Ista
[0] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg98762.html

On Fri, Aug 7, 2015 at 12:47 PM, Xebar Saram zelt...@gmail.com wrote:

 Thx for the response Bastien

 i removed (require 'org-install) from my init.el file (correct?) and
 restarted emacs but get the same error

 Invalid function: org-babel-header-args-safe-fn

 i also tried now to downgrade to previous version from 3/8/15 and the error
 is gone so its 100% reproducible with the 5/8/15 elpa version

 thx again

 Z



 On Fri, Aug 7, 2015 at 6:33 PM, Bastien b...@gnu.org wrote:

 Hi Xebar,

 try removing (require 'org-install), it is not needed since long.

 --
  Bastien

Re: [O] sudo uninstall org? Can it be done?

[Ista Zahn]

I had this problem too, but only on one of my machines. In my case it was
triggered by (require 'ob-R). Running byte-compile-file on ob-R.el
fixed it for me. I don't know what that means, but maybe it will give
someone a clue as to how to track this down.

best,
Ista
On Aug 5, 2015 6:23 PM, Bastien Guerry b...@gnu.org wrote:

 Sharon Kimble boudic...@skimble.plus.com writes:

  ╭
  │org-babel-safe-header-args , and I think it said something about the
  | function being void. |
  ╰

 A similar error is also reported here:
 https://www.reddit.com/r/emacs/comments/3fuq11/org_83_released/

 Anyone knows how to reproduce and fix this?

 --
  Bastien

Re: [O] Some projects

[Ista Zahn]

On Tue, Oct 27, 2015 at 9:42 AM, Rasmus  wrote:
> Hi,
>
> Rainer M Krug  writes:
>
>> I don't know which OS you are using, but just checking on
>> [[https://github.com/jgm/pandoc/releases/1.15.1]] and
>> [[https://github.com/jgm/pandoc/releases/tag/1.15.1.1]]:
>>
>> Windows: 19.7 MB
>> Mac: 27.9 MB
>> Deb: 20.2 MB
>>
>> The 1600MB must be including LaTeX?
>
> Nope, but something like 100 haskell libraries and ghc.  I guess it’s not
> build in a static way?
>
> It’s much smaller on Debian, approx. 25Mb.  (I should switch to Fedora
> full-time).
>
>> In General, I like the idea of using the Pandoc approach, as Pandoc
>> provides a very useful framework for all kinds of conversions (and I
>> don't like java...)
>
> Your first argument refers to a side effect (to us), and it is irrelevant
> IMO.

I disagree. pandoc supports conversion to and from org-mode. Making
pandoc a requirement will enable other useful features (e.g., "Import
documents from...", alternative pandoc-based exporters etc. IMO pandoc
is easy on Windows and OSX. It is easy on some Linux distros but not
all. I use Arch LInux, where getting pandoc requires some work, but I
think that is an issue that the Linux distros need to work out. In
short, pandoc is extremely useful for org-mode users, and not only for
citations. I think pandoc is the way to go.

  Java run easily everywhere, easily, and if you use mathml for some
> of your documents, you’re likely already using a jar file with Org.
>
> That being said, it suggest that Pandoc /can/ be packed in a sensible way,
> which is good.
>
> Rasmus
>
> --
> A page of history is worth a volume of logic
>

Re: [O] Some projects

[Ista Zahn]

On Oct 27, 2015 11:09 AM, "Rasmus Pank Roulund" <ras...@pank.eu> wrote:
>
> Hi,
>
> Ista Zahn <istaz...@gmail.com> writes:
>
> > I disagree. pandoc supports conversion to and from org-mode.
>
> I fail to see how this is relevant for the discussion at hand.
>
> > Making pandoc a requirement will enable other useful features (e.g.,
> > "Import documents from...", alternative pandoc-based exporters etc.
>
> AFAIK, nobody is working on this.

Not yet :-)
>
> > IMO pandoc is easy on Windows and OSX. It is easy on some Linux distros
> > but not all.
>
> > I use Arch LInux, where getting pandoc requires some work, but I think
> > that is an issue that the Linux distros need to work out.
>
> No it doesn't: pacman -S pandoc.

Good to know, thanks! That must be fairly recent.
>
> The relevant question here is whether we can accept to rely on pandoc for
> CSL support.  Any other feature is irrelevant.

That seems like a narrow way to look at it. Of course I agree that the
topic of discussion is citations, but I don't see why the bigger picture of
what the various options provide should be ignored.

I'll be happy to see improved citation support in org regardless of the
implementation details. But I do think pandoc deserves a serious look, and
I don't think the non-citation related possibilities it opens up are
irrelevant.

>
> At 25MB, a static, precompiled pandoc is probably fine, but for users of
> some OSs, such as Archlinux or even worse some OS where pandoc is not
> generally available as a precompiled package, it’s a really, really big
> dependency.  I may still be the best option, though.
>
> Rasmus
>
> --
> And when I’m finished thinking, I have to die a lot

Re: [O] preparing a R course in org for slides..can i link back to org document?

[Ista Zahn]

On Mon, Oct 19, 2015 at 7:29 AM, Eric S Fraga  wrote:
> On Monday, 19 Oct 2015 at 11:05, Xebar Saram wrote:
>> Also if people are using other alternative to org-reveal that can do that i
>> also wouldnt mind to try it out (a long as its as simple as org-revel :-))
>
> You might want to try org-treeslide [1].

I believe the canonical repository is https://github.com/takaxp/org-tree-slide

 List of alternatives can be
> found on Worg [2].
>
> I'm suggesting org-treeslide because it runs within Emacs so you have
> the full power of Emacs at hand.  It should be easy to use babel in the
> presentation although I've never tried.  I'm a beamer person (with
> org-reveal as a useful quick'n'dirty backup).
>
> HTH,
> eric
>
> Footnotes:
> [1]  https://github.com/avdi/org-tree-slide
>
> [2]  http://orgmode.org/worg/org-tutorials/non-beamer-presentations.html
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 24.5.1, Org release_8.3beta-1229-ge900eb
>

Re: [O] [PATCH] org-babel-execute-src-block-region

[Ista Zahn]

I recommend using polymode[1] as a more general solution to the need to
interact with code blocks without pulling up a separate edit buffer. It
seamlessly switches major modes when point is inside a code block.

Best,
Ista

[1] https://github.com/vspinu/polymode
On Nov 11, 2015 12:11 AM, "Xebar Saram"  wrote:

> Hi
>
> I actually find it annoying in ESS to keep pressing C-c ' each time i want
> to eval a single line of code in a code block. if this could work for R
> code this would be fantastic for me
>
> thx
>
> Z
>
> On Tue, Nov 10, 2015 at 8:19 PM, Carlos Henrique Machado S Esteves <
> ch.machado.este...@gmail.com> wrote:
>
>> Hello Chuck,
>>
>> Thank you for the feedback.
>>
>> > You might want to check that point and mark are both inside the src
>> block. Otherwise, the results are unpredictable.
>> You are right, I've updated the patch.
>>
>> > ess-mode, python-mode, sh-mode and octave-mode already provide this
>> capability (and a lot more) for R, python, shell scripts, octave/matlab and
>> some other languages from the edit buffer.
>> I understand that. My idea is to avoid the need to C-c ' back and forth.
>> Actually that's a problem I have with org-babel; I usually find myself
>> coding inside the src block and losing many of the major mode
>> functionalities; switching to the edit buffer often seem too much of a
>> hassle. Any tips about how to get more major-mode functionalities inside
>> the src-block? Or should I develop the muscle memory to switch back and
>> forth to the edit buffer all the time?
>>
>> > `org-babel-demarcate-block' gives the user the ability to break up src
>> blocks into smaller pieces so they can be run independently.
>> Thanks for pointing that; I didn't know about `org-babel-demarcate-block'.
>>
>> Best,
>>
>> Carlos
>>
>> 2015-11-02 13:19 GMT-05:00 Charles C. Berry :
>>
>>> On Sun, 1 Nov 2015, Carlos Henrique Machado S Esteves wrote:
>>>
>>> Hello, I find it useful to be able to execute only a region of a source
 code block, so I've implemented a new function for that. I've tested it
 with MATLAB and Python, but it should work for any mode, since it calls
 org-babel-execute-src-block.


>>> You might want to check that point and mark are both inside the src
>>> block. Otherwise, the results are unpredictable.
>>>
>>> Also note that:
>>>
>>> ess-mode, python-mode, sh-mode and octave-mode already provide this
>>> capability (and a lot more) for R, python, shell scripts, octave/matlab and
>>> some other languages from the edit buffer.
>>>
>>> `org-babel-demarcate-block' gives the user the ability to break up src
>>> blocks into smaller pieces so they can be run independently.
>>>
>>> Best,
>>>
>>> Chuck
>>>
>>>
>>
>

Re: [O] How to make ~evil-leader~ work for for ~org-src-mode~?

[Ista Zahn]

Hi Ben,

It doesn't work because evil-leader/set-key-for-mode sets keys for
major modes and org-src-mode is a minor mode. Unfortunately I don't
know the answer to your implied question "how do I make it work?", but
that is why it doesn't work.

Best,
Ista

On Tue, Oct 20, 2015 at 10:22 AM, Ben  wrote:
> Dear all,
>
> I want to set some evil-leader keys for org-src-mode with the following
> code:
>
> (evil-leader/set-key-for-mode 'org-src-mode
> "k" 'org-edit-src-abort
> "s" 'org-edit-src-save
> "'" 'org-edit-src-exit)
>
> But it doesn't work. Why is that?
>
> Thanks,
> Ben

Re: [O] Modification dates in Worg (was: babel header arguments tutorial?)

[Ista Zahn]

I've created a worg mirror on github at
https://github.com/izahn/worg-mirror/, so you can see the modification
dates via git-blame. For example,
https://github.com/izahn/worg-mirror/blame/master/org-contrib/babel/languages.org
shows modification of the babel languages page.

Best,
Ista

On Sun, Sep 27, 2015 at 4:22 AM, Michael Strey  wrote:
> On Sa, 2015-09-26 at 23:39, Charles C. Berry wrote:
>
> [...]
>
>> The source is several years old and filed under the FIXME worg
>> directory.
>
> Both things are not visible on the page.  In general there seems to be a
> lot of outdated stuff on Worg.  It would be helpful to have at least the
> date of last modification on the pages.
>
> --
> Michael Strey
> http://www.strey.biz * https://twitter.com/michaelstrey
>
>

Re: [O] Modification dates in Worg

[Ista Zahn]

Hi Machael,

Well, you're welcome to add modification dates to the worg files. IMO
this won't help much, since some sections of the same file may be up
to date while other sections may be out of date. Something like
git-blame is needed I think in order to get a sense of how up-to-date
a particular section might be.

Best,
Ista

On Tue, Sep 29, 2015 at 4:06 AM, Michael Strey <mst...@strey.biz> wrote:
> On Mo, 2015-09-28 at 17:04, Ista Zahn wrote:
>> I've created a worg mirror on github at
>> https://github.com/izahn/worg-mirror/, so you can see the modification
>> dates via git-blame.
>
> Thank you.  That will help me and maybe some other people who follow this
> thread.  Unfortunately it does not solve the general problem.  Most
> people access Worg via HTML.
>
> --
> Michael Strey
> http://www.strey.biz * https://twitter.com/michaelstrey
>
>

Re: [O] babel for sml?

[Ista Zahn]

I don't understand. You see ob-sml, but you ask if there is no
support? From the looks of it, ob-sml provides babel language support
for Standard ML, no?

Best,
Ista

On Wed, Sep 23, 2015 at 9:21 AM, Lawrence Bottorff  wrote:
> Is there no babel language support for Standard ML? I see a ob-sml at elpa.
> . .
>
> LB

Re: [O] babel for sml?

[Ista Zahn]

I've added a link from
http://orgmode.org/worg/org-contrib/babel/languages.html to the ob-sml
github project.

Best,
Ista

On Wed, Sep 23, 2015 at 11:49 AM, Lawrence Bottorff <borg...@gmail.com> wrote:
> The babel language page does in fact list SML, but no specific ob- package
> is mentioned -- as if support is "built-in." And ob-sml -- at least in my
> elpa listing -- says only
>
>  Requires: sml-mode-6.4
>  Summary: org-babel functions for template evaluation
>
> I was confused by the summary. I did install it and it works, BTW.
>
> On Wed, Sep 23, 2015 at 2:10 PM, Ista Zahn <istaz...@gmail.com> wrote:
>>
>> I don't understand. You see ob-sml, but you ask if there is no
>> support? From the looks of it, ob-sml provides babel language support
>> for Standard ML, no?
>>
>> Best,
>> Ista
>>
>> On Wed, Sep 23, 2015 at 9:21 AM, Lawrence Bottorff <borg...@gmail.com>
>> wrote:
>> > Is there no babel language support for Standard ML? I see a ob-sml at
>> > elpa.
>> > . .
>> >
>> > LB
>
>

Re: [O] [PATCH] ox-latex: Add scrartcl LaTeX class

[Ista Zahn]

On Wed, Sep 23, 2015 at 2:16 PM, Eric S Fraga  wrote:
> On Wednesday, 23 Sep 2015 at 18:59, Sebastian Boehm wrote:
>> Hi Nicolas,
>>
>> On 21 September 2015 at 21:46, Nicolas Goaziou  
>> wrote:
>>> But can't users needing a non-default class customize their
>>> own `org-latex-classes? Or is there an entitling reason to offer it out
>>> of the box?
>>
>> you are of course right; users can always customise their own setup.
>> However, when sharing Org files with other people this kind of tight
>> coupling between the Org file and the user's Emacs configuration can
>> become quite problematic.
>
> Yes, this is a real problem.
>
> One solution, but not an ideal one, is to use file local variables to
> define org-latex-classes (and any other variables) as appropriate for
> the document.  It's not ideal because unfortunately most of org's
> variables (as well as many of emacs's own) are "global" and hence affect
> the functionality of org visiting other buffers.  I find myself having
> separate emacs instances for some org files for this reason.

Doesn't "setq-local" solve this problem?

>
> I had thought that maybe using #+bind: would solve this problem but the
> export engine looks for the LaTeX class before binding takes effect.
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-270-g256fef
>

Re: [O] Super indent when editing R blocks and using a # comment

[Ista Zahn]

I'm pretty sure that's standard ess indentation. I don't think it has
anything to do with org mode.

Best,
Ista
On Jan 28, 2016 4:59 PM, "John Hendy"  wrote:

> Find attached a screenshot of the behavior I'm experiencing with this
> minimal config and =emacs -Q=.
>
> #+begin_src min-config
>
> ;; set load paths
> ;; set load dirs and global config options
> (add-to-list 'load-path "~/.elisp/org.git/lisp/")
> (add-to-list 'load-path "~/.elisp/org.git/contrib/lisp")
> (add-to-list 'load-path "~/.elisp/ess/lisp/")
>
> (require 'ess-site)
>
> ;; setup babel languages
> (org-babel-do-load-languages
>  'org-babel-load-languages
>  '((R . t)))
>
> #+end_src
>
> As shown in the shot:
> - create a .org file, insert a #+begin/end_src R block
> - edit with =C-c '=
> - start a line with a comment char (#)
> - press RET
> - it gets indented halfway across the page
>
> Inside a function, it seems to use a default of four spaces (the
> position of =return(i^2)=), so I'm not sure why a comment triggers
> such a massive indent. I end up having to delete the preceding spaces
> or be super careful about having a newline already inserted so that I
> can arrow down instead of pressing RET at the end of a comment line.
>
>
> Thanks for any insights!
> John
>

Re: [O] exporting documents w/ babel results w/o evaluating babel blocks

[Ista Zahn]

On Tue, May 24, 2016 at 6:17 AM, Andreas Kiermeier
 wrote:
> I second that.
> I like exporting everything to LaTeX without having to re-run all the code,
> which in many cases can add considerable time.

Which you can still do, I guess by

(setq org-babel-default-header-args
  (cons '(:eval . "never-export")
   (assq-delete-all :noweb org-babel-default-header-args)))

instead of the old way

(setq org-export-babel-evaluate nil)

I'm not saying this is good or right. IMO the old behavior of
org-export-babel-evaluate made sense and was useful; the new behavior
is surprising and I have a hard time seeing how it is useful. One can
argue (as Chuck has) that the new behavior is fine sense we have
another way of achieving the desired results; that may be, but I have
yet to see an explanation of why the new behavior is desirable.

It this change is not going to be reversed than the doc string for
org-export-babel-evaluate needs to be updated, and something should go
in the NEWS file warning people (like me) who have been relying on the
old behavior.

Best,
Ista

> Cheers,
> Andreas
>
> On 24 May 2016 at 11:04, Grant Rettke  wrote:
>>
>> On Sun, May 22, 2016 at 4:52 PM, Charles C. Berry 
>> wrote:
>> > TL;DR: Org babel headers give excellent control over what gets run,
>> > when it gets run, and how. Users should use them.
>>
>> Definitely!
>>
>> > Don't reset `org-export-babel-evaluate'.
>>
>> Why not?
>>
>> It can be nice to disable org-export-babel-evaluate by setting it to
>> `nil'.
>>
>> That way you separate your workflow into two distinct steps: one for
>> execution and one for weaving.
>>
>> It would be fun to "see" everyone's Org-Mode workflows; I bet there
>> are a lot of nice approaches.
>>
>

Re: [O] interesting dilemma with ob-ipython

[Ista Zahn]

On Fri, Jun 10, 2016 at 10:19 AM, John Kitchin  wrote:
> Thanks for this tip. It was a great start! I turned it into this:
>
> #+BEGIN_SRC emacs-lisp
> ;; make src blocks open in the right mode
> (add-to-list 'org-src-lang-modes '("jupyter-hy" . hy))
> (add-to-list 'org-latex-minted-langs '(jupyter-hy  "hylang"))
>
> ;; set default headers for convenience
> (setq org-babel-default-header-args:jupyter-hy
>   '((:results . "output replace")
> (:session . "hy")
> (:kernel . "hy")
> (:exports . "code")
> (:cache .   "no")
> (:noweb . "no")
> (:hlines . "no")
> (:tangle . "no")))
>
> (defalias 'org-babel-execute:jupyter-hy 'org-babel-execute:ipython)
>
> (add-to-list 'org-structure-template-alist
>  '("hy" "#+BEGIN_SRC jupyter-hy\n?\n#+END_SRC"
>"\n?\n"))
> #+END_SRC
>
> Which solves all the problems!
> 1. src-blocks open in hy-mode and export as hylang in minted.
> 2.  3. C-c C-c runs the block using the hy jupyter kernel.

I worked up some code to do this for all installed jupyter kernels.
It's kind of rough (my elisp is not so good) by I submitted it as a
pull request at https://github.com/gregsexton/ob-ipython/pull/74. I
would appreciate any feedback or suggestions for improvement.

--Ista

>
> Fantastic. Thanks!
>
>
> Anthony Cowley writes:
>
>> John Kitchin writes:
>>
>>> I was looking into ob-ipython as a replacement for regular
>>> org-babel-python because it seems to be better at sessions. Also, you
>>> can use other kernels with it!
>>>
>>> For example:
>>>
>>> #+BEGIN_SRC ipython :session hy :results output :kernel hy
>>> (print "hello world")
>>> (import time)
>>> (print (time.asctime))
>>> #+END_SRC
>>>
>>> #+RESULTS:
>>> : hello world
>>> : Thu Jun  9 17:26:56 2016
>>>
>>> Here is the dilemma:
>>> If I special edit this, it is in python-mode, not hy-mode. And similarly
>>> on export, it is highlighted as ipython, not hy-lang.
>>>
>>> Any thoughts on how to address these?
>>
>> I've had success using something like this,
>>
>> (add-to-list 'org-src-lang-modes '("ipython" . haskell))
>>
>> in a :noexport: setup section.
>>
>> Anthony
>
>
> --
> 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
>

Re: [O] v9.0 running babel blocks

[Ista Zahn]

On Nov 28, 2016 5:54 AM, "Alan Schmitt" 
wrote:
>
> Hello again,
>
> On 2016-11-28 09:01, Alan Schmitt  writes:
>
> > I'm sorry to write again about this, but the problem has come back, and
> > reinstalling org-plus-contrib did not make it go away this time.

Do you perhaps have both org and org-plus-contrib installed? If so, remove
org, then remove and reinstall org-plus-contrib.

--Ista
> >
> > I'm pretty sure this is not a problem with org itself, but some
> > interaction with other packages (I'm using Spacemacs so there are many
> > things happening under the hood). I don't know what to do to start
> > investigating. Would you have suggestions?
>
> I'm also seeing some other very strange behavior. For instance, while
> editing an org-beamer file, the function org-beamer-select-environment
> (bound to C-c C-b) is just the tagging function (bound to C-c C-q). To
> get the beamer behavior, I need to evaluate the defun of
> org-beamer-select-environment, and then all works well until the next
> time I restart emacs.
>
> I have no idea how such a thing would happen. Any suggestions?
>
> Thanks,
>
> Alan
>
> --
> OpenPGP Key ID : 040D0A3B4ED2E5C7
> Monthly Athmospheric CO₂, Mauna Loa Obs. 2016-10: 401.57, 2015-10: 398.29

Re: [O] ob-python newline & indentation behavior

[Ista Zahn]

ob-ipython[1] provides a working alternative:

#+BEGIN_SRC jupyter-python :session :results output
  foo = 0
  for _ in range(10):
  foo += 1

  foo += 1

  print(foo)
#+END_SRC

#+RESULTS:
: 20

I've long wished that more org people would show ob-ipython some love.
Letting jupyter handle things on the backend seems like it should
simplifly things considerably.

[1] https://github.com/gregsexton/ob-ipython

Best,
Ista

On Tue, Nov 21, 2017 at 3:28 AM, Jack Kamm  wrote:
> Yes, I'm starting to see now how difficult it is to properly support
> ":session :results value". I would vote to remove it from ob-python...
>
> I think the patch still improves ":session :results output" so I will
> simplify it and restrict to that case, leaving ":session :results value"
> unchanged for now.
>
> Sorry for sending this twice Kyle, forgot to reply all.
>
> On 21 Nov 2017 4:04 am, "Kyle Meyer"  wrote:
>>
>> Jack Kamm  writes:
>>
>> > In response to this:
>> >
>> >> I can't think of a good solution, though.  Stepping back a bit, I think
>> >> it's unfortunate that python blocks handle ":results value" differently
>> >> depending on whether the block is hooked up to a session or not.  For
>> >> non-sessions, you have to use return.  Using the same approach
>> >> (org-babel-python-wrapper-method) for ":session :results value", we
>> >> could then get the return value reliably, but the problem with this
>> >> approach is that any variables defined in a ":results value" block
>> >> wouldn't be defined in the session after executing the block because
>> >> the
>> >> code is wrapped in a function.
>> >
>> > How about if we used the "globals()" and "locals()" functions in Python?
>> >
>> > Something like this at the end of the wrapper block, before return:
>> >
>> > for k, v in locals().items():
>> > globals()[k] = v
>>
>> Hmm, placing that code "before return" is a problem.  Like with
>> non-session ":results value" blocks, the user would be responsible for
>> inserting the return (or even multiple return's), so we can't know where
>> to insert the above code without parsing the block :/
>>
>> > Another bug with the current approach is that it breaks if common idioms
>> > like "for _ in range(10)" are used. ("_" is used to inspect the last
>> > output
>> > of the shell, an obscure feature I hadn't known about until now).
>>
>> Right.  Also, IIRC the built-in interactive python and ipython treat
>> multiline blocks differently.  With
>>
>> if True:
>> "ipython ignores my existence"
>>
>> the built-in shell binds "_" to the string's value, but ipython doesn't.
>>
>> --
>> Kyle

Re: [O] Moving from Jekyll to Orgmode

[Ista Zahn]

On Sun, Apr 29, 2018 at 4:50 AM, ST  wrote:
> Hi Scott,
>
> thank you, and all other responders, for the shared information. The
> reason I want to leave Jekyll is because I don't want to depend on a
> tool that relies on language (Ruby)/environment that I don't know/use
> (in this respect Hugo is the same for me). I prefer something more
> simplistic, even though if I'll have to invest some time for it to work
> initially. Those 3 features I've mentioned are almost all I need, more
> or less.
>
> Could you, please, share your website publishing workflow (considering
> the 3 issues I've mentioned)?

I use Nikola (https://getnikola.com/). It has a plugin for org source files
(https://plugins.getnikola.com/v8/orgmode/). It claims to support
multilingual sites, though I have not used that feature.

--Ista

>
> Thank you!
>
> On Sat, 2018-04-28 at 18:13 -0400, Scott Randby wrote:
>> On 04/28/2018 05:40 PM, Diego Zamboni wrote:
>> >
>> > Org-mode is not really a website-publishing tool like Jekyll, although it 
>> > can be part of the chain. Org-mode at its core is a markup language, 
>> > although with considerable tooling support from org-mode and related tools 
>> > in Emacs.
>> >
>>
>> I think Org is a good website publishing tool in many ways. I've been using 
>> it for making and publishing my website since 2010. Sure, it has some 
>> limitations, but I think it can be made to work nicely for a lot of types of 
>> sites. But I do agree that the Org/Hugo combination is really good.
>>
>> Scott Randby
>>
>
>