Re: [O] latex newcommand in org

2016-05-20 Thread Doyley, Marvin M.
Eric’s suggestion works like a charm with the following modification
#+latex_header:\newenvironment{response}{\color{red}}{\ignorespacesafterend}

Thanks I really appreciate the help.

Cheers,
M

On May 20, 2016, at 5:00 PM, Leslie Watter 
> wrote:

You can use also macros in combination with latex \newcommand:

Following there's a sample with html:

#+MACRO: color @@html:$2@@
# macro sample: {{{color(red, aceitação)}}}


Note: untested with latex newcommand1


Cheers,

LEslie



On Fri, May 20, 2016 at 4:50 PM, Marcin Borkowski 
> wrote:

On 2016-05-20, at 20:45, Eric S Fraga 
> wrote:

> On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
>> Hi there,
>>
>> In my group, we typically response to reviewers comments (in latex) by first 
>> defining the  following command in the header
>>
>> \newcommand{\response}[1]{\textcolor{red}{#1}}
>> then marking up the text as follows
>>
>> \response{red text}
>>
>> I try to do the same in org,  i.e., putting
>>  #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
>> then \response{BLAH BLAH} in the text. The only snag is that on export I get 
>> \response\{BLAH BLAH\}
>
> Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
> all the org formatting.  Longer solution is to use environments, such as
>
> #+begin_response
> blah blah blah
> #+end_response
>
> and define a "response" LaTeX environment, along these lines:
>
> #+latex_header: 
> \makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
>
> (untested)

Notice also that commands and environments in LaTeX are not
interchangeable; there are things only commands can do and things only
environments can do.  (Well, not really - technically, I guess,
environments are strictly more powerful than commands, though I'm not
100% sure - but some things are quite difficult to do with environments
and trivial with commands.)

See also
http://tex.stackexchange.com/questions/102141/what-are-the-consideration-when-choosing-either-newcommand-or-newenvironment

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University




--
Leslie H. Watter



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

2016-05-20 Thread Ken Mankoff

On 2016-05-20 at 14:46, Nick Dokos  wrote:

> Are you getting an evaluation on export? I don't get that with o-e-b-e
> set to nil.

No I was not, but things were still exporting, which was confusing. I agree, 
seems like a bug.

> ... the fact that I get both code and results even if I specify
> ":exports results" looks like a bug to me.

Yes.

  -k.



Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]

2016-05-20 Thread Ken Mankoff
Hi Chuck,

On 2016-05-20 at 13:48, Charles C. Berry  wrote:
>> On Fri, 20 May 2016, Ken Mankoff wrote:
>>
>> I'm still trying to find a way where:
>>  + code results do export
>>  + code does not export
>>  + code does not evaluate at export
>>  + code can still be evaluated by me
>>
>
> So, you want `:exports results :eval never-export' and forget about
> `:cache yes'.
>
> And leave `org-export-babel-evaluate' at `t'.
>
> Also, see
>  (info "(org) eval")
>

Yes, this setup now appears to work. Thank you! I can get back to work...

I think this option to :eval might also be useful for John Hendy who was 
manually toggling eval from no to yes.

  -k.



Re: [O] Bug: orgtbl-self-insert-command does not overwrite whitespace [8.3.4 (8.3.4-50-g83e373-elpa @ /home/alex/.emacs.d/elpa/org-20160509/)]

2016-05-20 Thread Alex
Alex G  writes:

>> > Backspace works as expected, however.
>> I'm afraid that as of org-20160516 on ELPA, backspace also does not
>> overwrite whitespace.
>
> Oh, it seems like backspace works fine in text modes like
> fundamental-mode and message-mode, but not prog-derived modes. I'd say
> that's another bug.
>
> A git bisect says that this commit by Bastien Guerry is the culprit:
> f0a64ab3b5c46c8c7b1c838de2ed20511357e43d
>
> Does anyone know why it also affects orgtbl-self-insert-command?

I believe I have figured out the issue for both problems:

a) orgtbl-self-insert-command wasn't updated along with
org-self-insert-command in the commit
73a5c27cc1751721344886e7518f20ff382265b5. Changing it accordingly fixes
the issue.


b) Backspace doesn't work in prog-derived modes as orgtbl-mode seems to
just remap delete-backward-char to orgtbl, but in prog modes backspace
is bound to backward-delete-char-untabify.

Perhaps something extra should be done about backspace in orgtbl-mode
instead of just a simple remapping?




Re: [O] error: org-meta-return release_8.3.4.zip

2016-05-20 Thread Nicolas Goaziou
Hello,

Mambo Levis  writes:

>  On Thursday, May 19, 2016 12:45 PM, Mambo Levis  
> wrote:
>  
>  Hi,
> 1.) By testing org-mode release_8.3.4.zip from ( 
> http://orgmode.org/cgit.cgi/org-mode.git/) without compile it in emacs 
> 25.1.50.1 an error is shown
> when typing M-RET to add a new heading/item (see attached backtrace).

It means that Emacs is confused and doesn't load the latest Org.

> Questions: - How can isolate the new org version from the default
> installed?- How can I solve this issue?

Did you follow installation instructions
(http://orgmode.org/manual/Installation.html#Installation)?

Regards,

-- 
Nicolas Goaziou



Re: [O] error: org-meta-return release_8.3.4.zip

2016-05-20 Thread Nick Dokos
Mambo Levis  writes:

> On Thursday, May 19, 2016 12:45 PM, Mambo Levis  wrote:
>
> Hi,
>
> Yesterday I reported an issue (see bellow). How can I see its status? I open 
> an account in lists.gnu.org
> Mailing Lists but I couldn't find
> how to search for a reported issue.
>

Did you send it to the bug-gnu-emacs mailing list or to the org-mode
mailing list? If the latter, you cannot check its status: org-mode does
not have a bug tracking system as such. You need to wait for a
maintainer or other interested party to respond (please, wait at least a
week before pinging the list again: it might take a while for
somebody to get around to it, but after a week or so, it's a fair
supposition that it fell through the cracks).

For the specific problems you are reporting below, it looks to me
as if you are missing some initialization. I would add

(require 'org-loaddefs)

to init-org-minimal.el and try again.

For the "mixed installation" problem, please search the list: there
have been tens or hundreds of these problems reported. The best way
to avoid it is to follow the instructions in

(info "(org) Installation")

exactly and use a tried-and-true method rather than going your own way.

HTH, but please realize it's all untested conjecture.

--
Nick


> Thanks,
>
> Levis
>
> On Wednesday, May 18, 2016 9:18 PM, Mambo Levis  wrote:
>
> Hi,
>
> 1.) By testing org-mode release_8.3.4.zip from ( 
> http://orgmode.org/cgit.cgi/org-mode.git/) without
> compile it in emacs 25.1.50.1 an error is shown
> when typing M-RET to add a new heading/item (see attached backtrace).
>
> I am using the minimal configuration suggested in the manual.
>
> -
> ;; init.el
> --
> (use-package org-mode
>   :load-path "~/.emacs.d/user/site-lisp/org-mode"
>   :init
>   (load-file "~/.emacs.d/user/lisp/init-org-minimal.el")
>   )
> --
> 
> ;;; init-org-minimal.el --- org-mode minimal configuration 
> 
> ;;; Minimal setup to load latest 'org-mode'
> ;; activate debugging
> (setq debug-on-error t
>   debug-on-signal nil
>   debug-on-quit nil)
> ;; add latest org-mode to load path
> (add-to-list 'load-path "~/.emacs.d/user/site-lisp/org-mode/lisp")
> (add-to-list 'load-path "~/.emacs.d/user/site-lisp/org-mode/contrib/lisp" t)
> ;;(org-capture)
>
> (provide 'init-org-minimal)
> ;;; init-org-minimal.el ends here
> ---
>
> 2) If I use the option reload Org uncompiled there is no problem when using 
> M-RET but the following
> message appears:
> Successfully reloaded Org
> Org-mode version 8.2.10 (release_8.2.10 @ mixed installation! 
> c:/emacs/emacs-25.1.50/share/emacs/25.1.50
> /lisp/org/ and c:/home/.emacs.d/user/site-lisp/org-mode/lisp/)
>
> 3) Now I force emacs to search the new org-mode version by adding a org__ to 
> the original installation.
> The following message appears:
> File error: Cannot open load file, No such file or directory, org-table
>
> Questions: 
> - How can isolate the new org version from the default installed?
> - How can I solve this issue? 
>
> I appreciate your help,
> regards,
>
> Levis
>




Re: [O] Starting source code export at non-zero (-n value)

2016-05-20 Thread Nicolas Goaziou
Hello,

Brian Carlson  writes:

> Hello other org mode aficionados! (I apologize for the errant email I 
> send a minute ago. )
>
> I have created a (possible) patch to the export (ox.el and other 
> ox-XXX.el) files that allow for "source code" and "example" blocks to 
> have line numbers starting at an arbitrary number. Before the 
> (wonderful) ox redesign I used to have advice around some functions. I 
> hadn't needed this functionality for a while, but now that I did I 
> thought I would share.
>
>
> The code is written with the following design:
>
> -n   is the same as -n 1 : The functionality is unchanged
> +n   is the same as +n 1 :  The functionality is unchanged
>
> -n X   will "reset" and start new code block starting at line X
> +n X   will "add" X to the last line of the block before.

Thank you for the patch. It looks like an useful addition to Org. Some
comments follow.

> From 6b4db0a978cc3492f0d0ac7e29008de6846fbe4a Mon Sep 17 00:00:00 2001
> From: Brian Carlson 
> Date: Mon, 16 May 2016 10:58:01 -0400
> Subject: [PATCH] ox: provide [+-]n  functionality

Here you need to specify all the functions being modified. You may want
to look at other commit messages in the repository.

> @@ -1488,9 +1488,9 @@ contextual information."
>   (custom-env (and lang
>(cadr (assq (intern lang)
>org-groff-custom-lang-environments
> - (num-start (case (org-element-property :number-lines src-block)
> + (num-start (case (car (org-element-property :number-lines 
> src-block))
>(continued (org-export-get-loc src-block info))
> -  (new 0)))
> +  (new (or (cdr (org-element-property :number-lines 
> src-block)) 0

This pattern appears often in your patch, and, of course in the code
base. I suggest to factorize it out.  Indeed, we could take advantage of
the new behaviour of `org-export-get-loc' that your patch introduces.

IIUC, the new `org-export-get-loc' returns the number for the first line
of the current block, not the number of the last line in the previous
block, like it used to do. It can then includes the construct above:

  (pcase (org-element-property :number-lines src-block)
;; No need to compute line numbers before this one.
(`(new . ,n) (or n 2))
(`(continued . ,_)
 ;; Count all lines above, up to the first block that has "new" line
 ;; numbering.
 (let ((loc 0))
   (org-element-map (plist-get info :parse-tree)
   ...

Of course, tests would have to be changed or updated accordingly.

> - ((string-match "-n\\>" switches) 'new)
> - ((string-match "+n\\>" switches) 'continued)))
> + ((string-match "-n *\\([0-9]+\\)" switches) (cons 'new 
> (- (string-to-number (match-string 1 switches)) 1 )))

There is a spurious white space after the last 1.

> + ((string-match "+n *\\([0-9]+\\)" switches) (cons 
> 'continued (- (string-to-number (match-string 1 switches)) 1 )))

Ditto.

> + ((string-match "-n" switches) (cons 'new 0))
> + ((string-match "+n" switches) (cons 'continued 0))
> + ))

These parens should be moved at the end of the previous line.

>(preserve-indent
> (and switches (string-match "-i\\>" switches)))
>;; Should labels be retained in (or stripped from) example
> @@ -2393,7 +2396,7 @@ Assume point is at the beginning of the block."
>   (looking-at
>(concat "^[ \t]*#\\+BEGIN_SRC"
>"\\(?: +\\(\\S-+\\)\\)?"
> -  "\\(\\(?: +\\(?:-l 
> \".*?\"\\|[-+][A-Za-z]\\)\\)+\\)?"
> +  "\\(\\(?: +\\(?:-l \".+\"\\|[+-]n 
> *[[:digit:]]+\\|[+-][[:alpha:]]\\)\\)+\\)?"

I don't think "[-+][[:alpha:]]" is correct here and neither was [-+][A-Za-z].  
We
only want to match valid switches: k, r and i. Besides, there is no +k,
+r or +i. Thus, it should be "-[iIkKrR]".

>"\\(.*\\)[ \t]*$"))
>   (org-match-string-no-properties 1)))
>;; Get switches.
> @@ -2403,8 +2406,11 @@ Assume point is at the beginning of the block."
>;; Switches analysis
>(number-lines
> (cond ((not switches) nil)
> - ((string-match "-n\\>" switches) 'new)
> - ((string-match "+n\\>" switches) 'continued)))
> + ((string-match "-n *\\([0-9]+\\)" switches) (cons 'new 
> (- (string-to-number (match-string 1 switches)) 1 )))
> + ((string-match "+n *\\([0-9]+\\)" switches) (cons 
> 'continued (- (string-to-number (match-string 1 switches)) 1 )))
> + ((string-match "-n" switches) (cons 'new 0))
> +  

Re: [O] latex newcommand in org

2016-05-20 Thread Leslie Watter
You can use also macros in combination with latex \newcommand:

Following there's a sample with html:

#+MACRO: color @@html:$2@@
# macro sample: {{{color(red, aceitação)}}}


Note: untested with latex newcommand1


Cheers,

LEslie



On Fri, May 20, 2016 at 4:50 PM, Marcin Borkowski  wrote:

>
> On 2016-05-20, at 20:45, Eric S Fraga  wrote:
>
> > On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
> >> Hi there,
> >>
> >> In my group, we typically response to reviewers comments (in latex) by
> first defining the  following command in the header
> >>
> >> \newcommand{\response}[1]{\textcolor{red}{#1}}
> >> then marking up the text as follows
> >>
> >> \response{red text}
> >>
> >> I try to do the same in org,  i.e., putting
> >>  #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
> >> then \response{BLAH BLAH} in the text. The only snag is that on export
> I get \response\{BLAH BLAH\}
> >
> > Easiest solution is @@latex:\response{blah blah}@@ but that will lose
> you
> > all the org formatting.  Longer solution is to use environments, such as
> >
> > #+begin_response
> > blah blah blah
> > #+end_response
> >
> > and define a "response" LaTeX environment, along these lines:
> >
> > #+latex_header:
> \makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
> >
> > (untested)
>
> Notice also that commands and environments in LaTeX are not
> interchangeable; there are things only commands can do and things only
> environments can do.  (Well, not really - technically, I guess,
> environments are strictly more powerful than commands, though I'm not
> 100% sure - but some things are quite difficult to do with environments
> and trivial with commands.)
>
> See also
>
> http://tex.stackexchange.com/questions/102141/what-are-the-consideration-when-choosing-either-newcommand-or-newenvironment
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Faculty of Mathematics and Computer Science
> Adam Mickiewicz University
>
>


-- 
Leslie H. Watter


Re: [O] Bug: orgtbl-self-insert-command does not overwrite whitespace [8.3.4 (8.3.4-50-g83e373-elpa @ /home/alex/.emacs.d/elpa/org-20160509/)]

2016-05-20 Thread Nicolas Goaziou
Hello,

Alex  writes:

> As per the title, orgtbl-mode doesn't overwrite whitespace in tables
> like it does normally in org-mode.

Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] latex newcommand in org

2016-05-20 Thread Doyley, Marvin M.
Thanks,

I will give Eric’s suggestion a go.

Cheers,
M


On May 20, 2016, at 3:50 PM, Marcin Borkowski 
> wrote:


On 2016-05-20, at 20:45, Eric S Fraga 
> wrote:

On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
Hi there,

In my group, we typically response to reviewers comments (in latex) by first 
defining the  following command in the header

\newcommand{\response}[1]{\textcolor{red}{#1}}
then marking up the text as follows

\response{red text}

I try to do the same in org,  i.e., putting
#+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
then \response{BLAH BLAH} in the text. The only snag is that on export I get 
\response\{BLAH BLAH\}

Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
all the org formatting.  Longer solution is to use environments, such as

#+begin_response
blah blah blah
#+end_response

and define a "response" LaTeX environment, along these lines:

#+latex_header: 
\makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother

(untested)

Notice also that commands and environments in LaTeX are not
interchangeable; there are things only commands can do and things only
environments can do.  (Well, not really - technically, I guess,
environments are strictly more powerful than commands, though I'm not
100% sure - but some things are quite difficult to do with environments
and trivial with commands.)

See also
https://urldefense.proofpoint.com/v2/url?u=http-3A__tex.stackexchange.com_questions_102141_what-2Dare-2Dthe-2Dconsideration-2Dwhen-2Dchoosing-2Deither-2Dnewcommand-2Dor-2Dnewenvironment=CwIBAg=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU=T41F_5QsIVBGYhPPUkgYHUp9iPHgs2rOCjs7rfKaTMU=BXygbrudx0ZbLjXB7_QSNrR5Nwf_kj7fU2GbMseZG9Q=u6a29DcYPvJ-0G5l--k-db1OPj9GPF2DO89fbOOfje0=

Best,

--
Marcin Borkowski
https://urldefense.proofpoint.com/v2/url?u=http-3A__octd.wmi.amu.edu.pl_en_Marcin-5FBorkowski=CwIBAg=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU=T41F_5QsIVBGYhPPUkgYHUp9iPHgs2rOCjs7rfKaTMU=BXygbrudx0ZbLjXB7_QSNrR5Nwf_kj7fU2GbMseZG9Q=msRYXf0n_C3V5ncax1tSsNPVzKQ8OOotiw7ibezCLxU=
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Re: [O] org-mode html export background/foreground inconsistency

2016-05-20 Thread lad
On Fri, May 20, 2016, at 01:14 PM, Nick Dokos wrote:
> lad  writes:
> 
> > I attempted to follow this blog to enable a background html export on
> > org file save: 
> >
> >   http://stephanus-volke.de/posts/2015/Dez/22/org-mode-live-preview-en/
> >
> > I tried adding the following to the top of the org file:
> >
> >   # -*- after-save-hook: org-html-export-to-html;
> >   org-export-in-background: t; -*-
> >
> > by the way I also tried:
> >
> >   -*- after-save-hook: org-html-export-to-html;
> >   org-export-in-background: t; -*-
> >  
> > I even tried the following which I thought would work since I'm setting
> > the optional ASYNC variable to true:
> >
> >   #-*- after-save-hook: (org-html-export-to-html t);
> >   org-export-in-background: t; -*-
> >
> > For each test I tried I quit emacs and reopened to org file fresh. I was
> > prompted to accept some security settings and chose "y" so the variable
> > org-export-in-background is set correctly. The funny thing is when I go
> > through (C-c C-e h o) the export goes to the background, otherwise when
> > I save the file it happens in the foreground (which freezes emacs for
> > some time). :(
> >
> > Running:
> >   
> >   Org-mode version 8.3.4 (8.3.4-50-g83e373-elpa)
> >   GNU Emacs 25.1.50.1
> >
> > I'm not sure if this is correct behavior? Thank you in advance for any
> > insight or suggestions you may have.
> >
> 
> I tried it and it works for me, so I suspect that
> org-export-in-background is just not implemented in the stable release
> (based on the maint branch of the git repo - the elpa releases come from
> that branch), but *is* implemented in master (which is what I use).
> 
> If that is correct, your options are to wait until version 9.0 is
> released, or to use the master branch of the git repo, with the
> possible bugs/instabilities that that might entail.
> 
> --
> Nick
> 
> 
> 

Hey Nick, 

That did the trick.  Thanks for the hint, much appreciated! I don't mind
living on the edge. ;)

- lad



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

2016-05-20 Thread Charles C. Berry

On Fri, 20 May 2016, Nick Dokos wrote:


Ken Mankoff  writes:


[deleted discussion of  `org-export-babel-evaluate' settings]



With ":exports results" and o-e-b-e set to nil, I get no evaluation on
export, but I get both code and results in the output.


There may have been a misunderstanding, but when I mentioned this in
the bug report, I was told this is a "feature".

http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231



Not sure what exactly Chuck meant is a feature, but IIUC, the fact
that I get both code and results even if I specify ":exports results"
looks like a bug to me.



I meant this, as of commit ec615b1..., `org-export-babel-evaluate' set to
`nil' keeps the exporter from running this line

  (org-export-execute-babel-code)

during exports. So, 'no Babel code is run' in the sense that the above
line does not execute.

src-blocks and inline-src-blocks are neither run nor removed, and no
#+results: or {{{results()}}} are added, removed, or
modified. Babel handles all that. The exporter merely formats those
things once Babel is done.

So the bug, if any, is in the docstring in failing to mention that
everything that babel does is switched off.

Since the behavior that the OP wanted can be had by setting babel
header args, I don't see this as a bug even though the behavior
changed in a way that surprised him.

Chuck



Re: [O] Org insert different hour than current time

2016-05-20 Thread Nick Dokos
Mambo Levis  writes:

> Hi,
>
> 1. When I insert date and time format (C-u C-c .) the hour display in emacs 
> calendar is the same as my
> system hour. Nonetheless,
> org-mode insert a different hour (it adds automatically 3 hours)
>

FWIW, everything is working fine here.

But I don't understand what "the hour display in emacs calendar" means,
or what your "system hour" is. Can you specify *exactly* what you do?

> 2. I make tests with different time zones and the same problem appeared.
>
> 3. When the time zone is UTC, there is no problem because org insert the 
> system hour.
>

How do you set the timezone?

--
Nick




Re: [O] Bug: org links do not work in some latex files [8.3.4 (8.3.4-34-gacfd41-elpaplus @ /home/oub/.emacs.d/elpa/org-plus-contrib-20160411/)]

2016-05-20 Thread Nicolas Goaziou
Hello,

Uwe Brauer  writes:

> Please look at the following example
>
> \documentclass[addpoints,12pt]{exam}
> \begin{document}
> % 
> [[file:~/ALLES/tex/vorlesungen/HGBioQuim/Examen+geogebra/Examen2/README.org::*Overview][Overview]]
> \begin{questions}  
> % 
> [[file:~/ALLES/tex/vorlesungen/HGBioQuim/Examen+geogebra/Examen2/README.org::*Overview][Overview]]
>
> \end{questions}
>
> `org-open-at-point' opens the first link, but not the one in the
> environment questions.

`org-open-at-point' in an Org function, which is meant to be called in
an Org buffer. IIUC, you are calling it from a LaTeX buffer.

`org-open-at-point-global' provides sloppy Org link (and time-stamp)
following in any buffer. You should use it in this case.

Note that however `org-open-at-point-global' was bugged, so I just fixed
it in master. Thank you for the report.


Regards,

-- 
Nicolas Goaziou



Re: [O] org-mode html export background/foreground inconsistency

2016-05-20 Thread Nick Dokos
lad  writes:

> I attempted to follow this blog to enable a background html export on
> org file save: 
>
>   http://stephanus-volke.de/posts/2015/Dez/22/org-mode-live-preview-en/
>
> I tried adding the following to the top of the org file:
>
>   # -*- after-save-hook: org-html-export-to-html;
>   org-export-in-background: t; -*-
>
> by the way I also tried:
>
>   -*- after-save-hook: org-html-export-to-html;
>   org-export-in-background: t; -*-
>  
> I even tried the following which I thought would work since I'm setting
> the optional ASYNC variable to true:
>
>   #-*- after-save-hook: (org-html-export-to-html t);
>   org-export-in-background: t; -*-
>
> For each test I tried I quit emacs and reopened to org file fresh. I was
> prompted to accept some security settings and chose "y" so the variable
> org-export-in-background is set correctly. The funny thing is when I go
> through (C-c C-e h o) the export goes to the background, otherwise when
> I save the file it happens in the foreground (which freezes emacs for
> some time). :(
>
> Running:
>   
>   Org-mode version 8.3.4 (8.3.4-50-g83e373-elpa)
>   GNU Emacs 25.1.50.1
>
> I'm not sure if this is correct behavior? Thank you in advance for any
> insight or suggestions you may have.
>

I tried it and it works for me, so I suspect that
org-export-in-background is just not implemented in the stable release
(based on the maint branch of the git repo - the elpa releases come from
that branch), but *is* implemented in master (which is what I use).

If that is correct, your options are to wait until version 9.0 is
released, or to use the master branch of the git repo, with the
possible bugs/instabilities that that might entail.

--
Nick





Re: [O] latex newcommand in org

2016-05-20 Thread Marcin Borkowski

On 2016-05-20, at 20:45, Eric S Fraga  wrote:

> On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
>> Hi there,
>>
>> In my group, we typically response to reviewers comments (in latex) by first 
>> defining the  following command in the header
>>
>> \newcommand{\response}[1]{\textcolor{red}{#1}}
>> then marking up the text as follows
>>
>> \response{red text}
>>
>> I try to do the same in org,  i.e., putting
>>  #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
>> then \response{BLAH BLAH} in the text. The only snag is that on export I get 
>> \response\{BLAH BLAH\}
>
> Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
> all the org formatting.  Longer solution is to use environments, such as
>
> #+begin_response
> blah blah blah
> #+end_response
>
> and define a "response" LaTeX environment, along these lines:
>
> #+latex_header: 
> \makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
>
> (untested)

Notice also that commands and environments in LaTeX are not
interchangeable; there are things only commands can do and things only
environments can do.  (Well, not really - technically, I guess,
environments are strictly more powerful than commands, though I'm not
100% sure - but some things are quite difficult to do with environments
and trivial with commands.)

See also
http://tex.stackexchange.com/questions/102141/what-are-the-consideration-when-choosing-either-newcommand-or-newenvironment

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Re: [O] sparse tree search still hides matching drawers (bug?)

2016-05-20 Thread Samuel Wales
thank you!

On 5/20/16, Nicolas Goaziou  wrote:
> I added `org-occur-case-fold-search' variable in master.  Setting it to
> `smart' should mimic isearch when calling org-occur.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.



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

2016-05-20 Thread Nick Dokos
Ken Mankoff  writes:

> On 2016-05-20 at 13:11, Eric S Fraga  wrote:
>> On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote:
>> So, if I understand correctly, you have org-export-babel-evaluate set
>> to nil?
>
> yes.
>

Are you getting an evaluation on export? I don't get that with o-e-b-e
set to nil.

>> If I set that, I no longer get asked whether I want anything evaluated
>> but the (existing) results do get exported. I just tried it to
>> confirm.
>
> Yes results get exported, but so does code. Both, always, even if ":exports 
> none" or ":exports results".
>

With ":exports results" and o-e-b-e set to nil, I get no evaluation on
export, but I get both code and results in the output.

> There may have been a misunderstanding, but when I mentioned this in
> the bug report, I was told this is a "feature".
>
> http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231
>

Not sure what exactly Chuck meant is a feature, but IIUC, the fact
that I get both code and results even if I specify ":exports results"
looks like a bug to me.

I'm on more-or-less latest master:
Org-mode version 8.3.4 (release_8.3.4-824-ga02fe8 @
/home/nick/elisp/org-mode/lisp/)

--
Nick





Re: [O] Division of Org documentation: Org manual and Worg

2016-05-20 Thread Rasmus

Daniele Pizzolli  writes:

> Done, just pushed the change succesfully!  I will look forward to
> integrate more docs about org-mode and python.

Grazie mille!

Caio

-- 
C is for Cookie




Re: [O] latex newcommand in org

2016-05-20 Thread Eric S Fraga
On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
> Hi there,
>
> In my group, we typically response to reviewers comments (in latex) by first 
> defining the  following command in the header
>
> \newcommand{\response}[1]{\textcolor{red}{#1}}
> then marking up the text as follows
>
> \response{red text}
>
> I try to do the same in org,  i.e., putting
>  #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
> then \response{BLAH BLAH} in the text. The only snag is that on export I get 
> \response\{BLAH BLAH\}

Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
all the org formatting.  Longer solution is to use environments, such as

#+begin_response
blah blah blah
#+end_response

and define a "response" LaTeX environment, along these lines:

#+latex_header: 
\makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother

(untested)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5



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

2016-05-20 Thread Eric S Fraga
On Friday, 20 May 2016 at 16:45, Ken Mankoff wrote:
> Eric: You're running something newer (by date) than the commit which
> changed the behavior, which was:
>
> ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28)
>
> But with all the branches in git, I don't know if you have that commit
> or not. Anyway, I'm not sure why it works for you. It doesn't appear
> to work for John and I the way it used to. Do you have a global "eval:
> no" set somewhere?

I do have that commit incorporated in the version I am running from what
I see in the git log.

When I export, org asks whether to evaluate the code block and I respond
with no.  The existing results block is therefore exported but not
changed.  If I say yes, a new results block is generated and exported
(and I can tell because it is different to what was there before).

I have org-export-babel-evaluate set to t but also
org-confirm-babel-evaluate to t.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5



[O] latex newcommand in org

2016-05-20 Thread Doyley, Marvin M.
Hi there,

In my group, we typically response to reviewers comments (in latex) by first 
defining the  following command in the header

\newcommand{\response}[1]{\textcolor{red}{#1}}
then marking up the text as follows

\response{red text}

I try to do the same in org,  i.e., putting
 #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
then \response{BLAH BLAH} in the text. The only snag is that on export I get 
\response\{BLAH BLAH\}

Any suggestion how to fix this

cheers,
M













Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]

2016-05-20 Thread Charles C. Berry

On Fri, 20 May 2016, Ken Mankoff wrote:



On 2016-05-20 at 13:29, Charles C. Berry  wrote:

On Fri, 20 May 2016, Ken Mankoff wrote:


#+BEGIN_SRC octave :exports results :cache nil
"hello, world"
#+END_SRC
#+RESULTS:
: hello, world

Yes, the above appears to work.


Really? I do not see the hash in your results block.


Correct. I've never used cache, and ":cache t" doesn't work, it has to 
be ":cache yes". I'll try to set this up and see if it works better w/ 
caching. That may be the trick as you suggested in the other thread, and 
perhaps most of the issues here are my improper use of cache (which 
wasn't required before).




But I see that you said:



I'm still trying to find a way where:
 + code results do export
 + code does not export
 + code does not evaluate at export
 + code can still be evaluated by me



So, you want `:exports results :eval never-export' and forget about
`:cache yes'.

And leave `org-export-babel-evaluate' at `t'.

Also, see
(info "(org) eval")

Chuck




Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]

2016-05-20 Thread Ken Mankoff

On 2016-05-20 at 13:29, Charles C. Berry  wrote:
> On Fri, 20 May 2016, Ken Mankoff wrote:
>>>
>>> #+BEGIN_SRC octave :exports results :cache nil
>>> "hello, world"
>>> #+END_SRC
>>> #+RESULTS:
>>> : hello, world
>>>
>>> Yes, the above appears to work.
>
> Really? I do not see the hash in your results block.

Correct. I've never used cache, and ":cache t" doesn't work, it has to be 
":cache yes". I'll try to set this up and see if it works better w/ caching. 
That may be the trick as you suggested in the other thread, and perhaps most of 
the issues here are my improper use of cache (which wasn't required before).

  -k.




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

2016-05-20 Thread Ken Mankoff

Nicolas Goaziou added to To: field, because he committed the change.

Question: Why does "org-export-babel-evaluate" change what is exported? 
Shouldn't it just change what is evaluated at export time? That is what the doc 
string implies. A recent commit changed this behavior.

  -k.

On 2016-05-20 at 13:23, John Hendy  wrote:
> Variables org-export-babel-evaluate and org-confirm-babel-evaluate
> abbreviated above.
>
> I find two things bizarre:
> - these options (well, just o-e-b-e it seems) would change what's exported?



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

2016-05-20 Thread Ken Mankoff

On 2016-05-20 at 13:11, Eric S Fraga  wrote:
> On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote:
> So, if I understand correctly, you have org-export-babel-evaluate set
> to nil?

yes.

> If I set that, I no longer get asked whether I want anything evaluated
> but the (existing) results do get exported. I just tried it to
> confirm.

Yes results get exported, but so does code. Both, always, even if ":exports 
none" or ":exports results".

There may have been a misunderstanding, but when I mentioned this in the bug 
report, I was told this is a "feature".

http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231

  -k.



Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]

2016-05-20 Thread Charles C. Berry

On Fri, 20 May 2016, Ken Mankoff wrote:



On 2016-05-20 at 07:12, Ken Mankoff  wrote:

On 2016-05-19 at 23:33, Charles C. Berry  wrote:

On Thu, 19 May 2016, Ken Mankoff wrote:


(setq org-export-babel-evaluate t)

#+BEGIN_SRC octave :exports results :cache nil
"hello, world"
#+END_SRC
#+RESULTS:
: hello, world

Yes, the above appears to work.


Really? I do not see the hash in your results block.



But it doesn't work with sessions. Can you advise what settings to have how I 
can have the following code in an Org document:

#+BEGIN_SRC python :results output :exports results :session foo :cache nil
print("hello, world")
#+END_SRC
#+RESULTS:
: hello, world

And easily export that document without evaluating the code?


`:cache yes'

Of course, you must eval at least once with `:cache yes' to set the hash.

Chuck

p.s. I like to use stuff like

: import time
: print(time.strftime("%H:%M:%S"))

in src blocks to do :cache experiments



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

2016-05-20 Thread John Hendy
On Fri, May 20, 2016 at 11:45 AM, Ken Mankoff  wrote:
>
> Eric: You're running something newer (by date) than the commit which changed 
> the behavior, which was:
>
> ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28)
>
> But with all the branches in git, I don't know if you have that commit or 
> not. Anyway, I'm not sure why it works for you. It doesn't appear to work for 
> John and I the way it used to. Do you have a global "eval: no" set somewhere?
>
> On 2016-05-20 at 12:14, John Hendy  wrote:
>> On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff  wrote:
>>> As of an Org git commit a few weeks ago, Org exporting (and therefore
>>> Org) has become basically unusable for me. I used to be able to
>>> export code block results without evaluating the block during the
>>> export. I can no longer do this.
>>>
>>
>> Well, you're exporting them at least *once*, right? If not, where are
>> the results coming from?
>
> Yes, but only once. Or sometimes I generate the figure elsewhere (via 
> org-edit-special) and then manually put [[file:fig.pdf]] below the #+RESULTS:.
>
>> I do the same as I'm tweaking plots. Every code block I create has
>> :eval yes initially and once I'm satisfied with the results I just
>> change to :eval no and the generated results (for me, typically a
>> #+results line containing a link to a pdf plot generated by my code
>> block) are still included.
>>
>> Does this help at all? Sorry if I'm not understanding
>
> You understand, and this sort-of helps. I have never used :eval before. 
> Things just didn't evaluate by default, and I like it like that.
>
> ":eval no" fixes the problem at export, but then I can't evaluate the code 
> myself manually when not exporting.

Not in the buffer so as to replace results, but you *can* go into
interactive mode (if python has one) with =C-c '=. I use this
constantly, which allows me to ignore whatever :eval is set to, and
just putz around in the new code block buffer to my heart's content.
I'm approx. 100% R usage, so this still gives me access to the R
pop-up device to view plots or an R buffer to see results. You're
right though, there's no way to update the results block without
toggling :eval, manually running, and then resetting :eval back to no.

John

>
>> Mine is set to t. Interestingly, when I export the above after
>> deleting the results bit, no new results are generated. When I C-c
>> C-c, they are replaced. When I add :eval no, it does't appear to run
>> the code.
>
> Yes same here. This new behavior really sucks.
>
> I'm still trying to find a way where:
>   + code results do export
>   + code does not export
>   + code does not evaluate at export
>   + code can still be evaluated by me
>
> This was the behavior prior to
>
> ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28)
>
> But not since.
>
>   -k.



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

2016-05-20 Thread John Hendy
On Fri, May 20, 2016 at 12:11 PM, Eric S Fraga  wrote:
> On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote:
>
> [...]
>
>> Thanks for clarifying your workflow. That seems to work for a small
>> example. But what would you do if you had a manuscript with 100 code
>> blocks in it? And in general you're exporting it a lot without
>> changing anything in code, just editing the non-code text. But
>> occasionally you want to modify a code block (and its results) too?
>
> So, if I understand correctly, you have org-export-babel-evaluate set to
> nil?  If I set that, I no longer get asked whether I want anything
> evaluated but the (existing) results do get exported.  I just tried it
> to confirm.

Using this block,

#+begin_src R :exports results
print("hello")
#+end_src

I get the following (with *no* pre-existing #+results block manually
created with C-c C-c):

| *o-e-b-e* | *o-c-b-e* | *buffer*  | *doc*|
|---+---+---+--|
| nil   | t | nothing   | =print("hello")= |
| t | t | nothing   | =hello=  |
| t | nil   | nothing   | =hello=  |
| nil   | nil   | nothing   | =print("hello")= |
|---+---+---+--|

Variables org-export-babel-evaluate and org-confirm-babel-evaluate
abbreviated above.

I find two things bizarre:
- these options (well, just o-e-b-e it seems) would change what's exported?
- why without C-c C-c which initiates the #+results block, exporting
which causes babel to execute code doesn't insert the results block.
Is this intended or for a reason?

I've not really looked into these variables and just use :eval yes/no
to toggle things. I find it easy enough to create all my blocks with
:eval no, and do a quick change to =yes= as I'm iteratively exporting.
Finally, I can do a replace-string to catch any missed :eval yes's
before a final export.

>
>> In the above scenario, I used to edit the code, and =C-c C-c= it
>> manually to get the updates into the results. When I exported the
>> document (C-e l l), it would export in ~1 second (even a >100 page
>> document) and not prompt me about executing code blocks.
>
> Yes, I do this as well in such a case.
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5



Re: [O] Division of Org documentation: Org manual and Worg

2016-05-20 Thread Daniele Pizzolli
On Wed, May 18 2016, Rasmus  wrote:

> Hi Daniele,
>
>> So... here is the patch for worg about python and utf-8!  I skipped
>> the part related to the tables, since I do not have a clean
>> workaround.
>
> Thanks for contributing to Worg!
>
> For Worg you just need to have your ssh key added.  Then you can push
> changes yourself.
>
> http://orgmode.org/worg/worg-about.html
>
> You can email your public ssh key to e.g. Bastien (bzg at gnu dot org).

Hello Rasmus,

Done, just pushed the change succesfully!  I will look forward to
integrate more docs about org-mode and python.

Of course feedback are welcome!

Best,
Daniele



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

2016-05-20 Thread Eric S Fraga
On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote:

[...]

> Thanks for clarifying your workflow. That seems to work for a small
> example. But what would you do if you had a manuscript with 100 code
> blocks in it? And in general you're exporting it a lot without
> changing anything in code, just editing the non-code text. But
> occasionally you want to modify a code block (and its results) too?

So, if I understand correctly, you have org-export-babel-evaluate set to
nil?  If I set that, I no longer get asked whether I want anything
evaluated but the (existing) results do get exported.  I just tried it
to confirm.

> In the above scenario, I used to edit the code, and =C-c C-c= it
> manually to get the updates into the results. When I exported the
> document (C-e l l), it would export in ~1 second (even a >100 page
> document) and not prompt me about executing code blocks.

Yes, I do this as well in such a case.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5



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

2016-05-20 Thread Ken Mankoff
Hi Eric,

On 2016-05-20 at 12:59, Eric S Fraga  wrote:
> When I export, org asks whether to evaluate the code block and I
> respond with no. The existing results block is therefore exported but
> not changed. If I say yes, a new results block is generated and
> exported (and I can tell because it is different to what was there
> before).
>
> I have org-export-babel-evaluate set to t but also
> org-confirm-babel-evaluate to t.

Thanks for clarifying your workflow. That seems to work for a small example. 
But what would you do if you had a manuscript with 100 code blocks in it? And 
in general you're exporting it a lot without changing anything in code, just 
editing the non-code text. But occasionally you want to modify a code block 
(and its results) too?

In the above scenario, I used to edit the code, and =C-c C-c= it manually to 
get the updates into the results. When I exported the document (C-e l l), it 
would export in ~1 second (even a >100 page document) and not prompt me about 
executing code blocks.

  -k



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

2016-05-20 Thread Ken Mankoff

Eric: You're running something newer (by date) than the commit which changed 
the behavior, which was:

ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28)

But with all the branches in git, I don't know if you have that commit or not. 
Anyway, I'm not sure why it works for you. It doesn't appear to work for John 
and I the way it used to. Do you have a global "eval: no" set somewhere?

On 2016-05-20 at 12:14, John Hendy  wrote:
> On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff  wrote:
>> As of an Org git commit a few weeks ago, Org exporting (and therefore
>> Org) has become basically unusable for me. I used to be able to
>> export code block results without evaluating the block during the
>> export. I can no longer do this.
>>
>
> Well, you're exporting them at least *once*, right? If not, where are
> the results coming from?

Yes, but only once. Or sometimes I generate the figure elsewhere (via 
org-edit-special) and then manually put [[file:fig.pdf]] below the #+RESULTS:.

> I do the same as I'm tweaking plots. Every code block I create has
> :eval yes initially and once I'm satisfied with the results I just
> change to :eval no and the generated results (for me, typically a
> #+results line containing a link to a pdf plot generated by my code
> block) are still included.
>
> Does this help at all? Sorry if I'm not understanding

You understand, and this sort-of helps. I have never used :eval before. Things 
just didn't evaluate by default, and I like it like that.

":eval no" fixes the problem at export, but then I can't evaluate the code 
myself manually when not exporting.

> Mine is set to t. Interestingly, when I export the above after
> deleting the results bit, no new results are generated. When I C-c
> C-c, they are replaced. When I add :eval no, it does't appear to run
> the code.

Yes same here. This new behavior really sucks.

I'm still trying to find a way where:
  + code results do export
  + code does not export
  + code does not evaluate at export
  + code can still be evaluated by me

This was the behavior prior to

ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28)

But not since.

  -k.



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

2016-05-20 Thread Eric S Fraga
On Friday, 20 May 2016 at 15:57, Ken Mankoff wrote:
> Hi List,
>
> I'm repeating a question here from a recent bug report because I have
> a feeling official-looking bug reports might get read less than normal
> questions. Sorry for the re-post.
>
> As of an Org git commit a few weeks ago, Org exporting (and therefore
> Org) has become basically unusable for me. I used to be able to export
> code block results without evaluating the block during the export. I
> can no longer do this.

I can export your example without evaluating the babel block and the
results appear in the exported output.  My org is relatively recent but
may be of a similar vintage to yours (see my signature).

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5



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

2016-05-20 Thread John Hendy
On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff  wrote:
> Hi List,
>
> I'm repeating a question here from a recent bug report because I have a 
> feeling official-looking bug reports might get read less than normal 
> questions. Sorry for the re-post.
>
> As of an Org git commit a few weeks ago, Org exporting (and therefore Org) 
> has become basically unusable for me. I used to be able to export code block 
> results without evaluating the block during the export. I can no longer do 
> this.
>
> The following headers used to support the above behavior:
>
> #+BEGIN_SRC python :exports results :results output
> #+BEGIN_SRC python :exports results :results file
>   (and possibly with ":session foo" also)

Well, you're exporting them at least *once*, right? If not, where are
the results coming from?

Perhaps my use case is similar. I often write up an org doc with a
pretty heavy setup heading containing my main data reading in,
manipulation, statistics, etc. Maybe up to 100k total rows in a data
frame in R. Once I run that block the first time I'm working on the
document I just put =:eval no= in the src block options.

I do the same as I'm tweaking plots. Every code block I create has
:eval yes initially and once I'm satisfied with the results I just
change to :eval no and the generated results (for me, typically a
#+results line containing a link to a pdf plot generated by my code
block) are still included.

Does this help at all? Sorry if I'm not understanding

>
> Is anyone running the current git head? And if so, can you export a document 
> that consists of the following, or something similar to the following (i.e. 
> do you use ":cache t" or ":cache nil")?
>
> #+BEGIN_SRC python :results output :exports results :session foo
> print("hello, world")
> #+END_SRC
> #+RESULTS:
> : hello, world
>
> If you can export this without running the code, what settings are you using? 
> In particular, what is the value of =org-export-babel-evaluate=?

Mine is set to t. Interestingly, when I export the above after
deleting the results bit, no new results are generated. When I C-c
C-c, they are replaced. When I add :eval no, it does't appear to run
the code.


Hope that helps,
John

>
> Thanks,
>
>   -k.
>



[O] History list for %^{...} in capture

2016-05-20 Thread Phil Hudson
Arising from a discussion here a couple of weeks ago, I'm thinking about
how best to add a history list to org-capture's current
%^{prompt|default|choice2|...|choiceN} escape syntax. Here's my thinking
so far.

%^{prompt|'histList}
%^{prompt|default|'histList}
%^{prompt|default|choiceToPrepend|...|'histList|choiceToAppend|...}

Note the quote distinguishing the variable name.

Effectively the third example means: merge choices "default" and
"choiceTo*" into 'histList, prepending or appending each choice (if it
is not already an element of `histList') according to whether it occurs
before or after 'histList. Usually we would not expect prepending and
appending, just the prompt, default and history list as in the second
example. However, this form might be useful for pre-populating an
otherwise empty list.

I've identified the place in the code where the changes would need to be
coded, but I thought I should get your ideas before I dive in.
Effectively something similar is being done behind the scenes already
and then discarded; I would just be bringing it into the light of day
and making it persistent across calls.

WDYT? Good idea? Too complex? Too "busy"? Useful? Not useful?

-- 
Phil Hudson   http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63



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

2016-05-20 Thread Ken Mankoff
Hi List,

I'm repeating a question here from a recent bug report because I have a feeling 
official-looking bug reports might get read less than normal questions. Sorry 
for the re-post.

As of an Org git commit a few weeks ago, Org exporting (and therefore Org) has 
become basically unusable for me. I used to be able to export code block 
results without evaluating the block during the export. I can no longer do this.

The following headers used to support the above behavior:

#+BEGIN_SRC python :exports results :results output 
#+BEGIN_SRC python :exports results :results file
  (and possibly with ":session foo" also)

Is anyone running the current git head? And if so, can you export a document 
that consists of the following, or something similar to the following (i.e. do 
you use ":cache t" or ":cache nil")?

#+BEGIN_SRC python :results output :exports results :session foo
print("hello, world")
#+END_SRC
#+RESULTS:
: hello, world

If you can export this without running the code, what settings are you using? 
In particular, what is the value of =org-export-babel-evaluate=?

Thanks,

  -k.



[O] Org insert different hour than current time

2016-05-20 Thread Mambo Levis
Hi,
1. When I insert date and time format (C-u C-c .) the hour display in emacs 
calendar is the same as my system hour. Nonetheless,org-mode insert a different 
hour (it adds automatically 3 hours)
2. I make tests with different time zones and the same problem appeared.
3. When the time zone is UTC, there is no problem because org insert the system 
hour.
How can I solve this issue?
Regards,
Levis

[O] Litteral :var passing buggy for shell execution in org-babel when in :session

2016-05-20 Thread Olivier Berger
Hi.

I'm trying to apply the approach of litteral devops described in
http://www.howardism.org/Technical/Emacs/literate-devops.html and
noticed the following issue.

I'm trying to use execute shell blocks of the following form ("remote" 
execution of
commands inside a Vagrant VM via tramp through ssh, using a shell mode session) 
:

 #+BEGIN_SRC sh :dir /symfonyvm:/vagrant :var SYNCEDDIR="/vagrant" :results 
drawer :session centosvm
 ls $SYNCEDDIR
 #+END_SRC

This works well when not using a session, but when using the session,
the variable evaluation gets stuck, and when interrupted, I can see the
following inside the "centosvm" shell buffer :

 /scp:symfonyvm: #$ SYNCEDDIR=$(cat <<'BABEL_TABLE'

The substitution doesn't seem to happen well over tramp in that case,
somehow.

Typing C-c C-d in the shell session allows me to recover.

I suspect an issue related to tramp + session, incompatible with the
variable initialisation mechanism.

Any clue ?

My setup should be org-mode version : 8.3.4 and normally, ob-sh.el
supposedly stock emacs in Debian testing context...

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)




Re: [O] sparse tree search still hides matching drawers (bug?)

2016-05-20 Thread Nicolas Goaziou
Hello,

Samuel Wales  writes:

> that would only either allow case folding or no case folding.  in
> isearch, if you search for lowercase, it folds.  if you search for
> uppercase CATEGORY, it doesn't.

I added `org-occur-case-fold-search' variable in master.  Setting it to
`smart' should mimic isearch when calling org-occur.

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]

2016-05-20 Thread Ken Mankoff

On 2016-05-20 at 07:12, Ken Mankoff  wrote:
> On 2016-05-19 at 23:33, Charles C. Berry  wrote:
>> On Thu, 19 May 2016, Ken Mankoff wrote:
>
> (setq org-export-babel-evaluate t)
>
> #+BEGIN_SRC octave :exports results :cache nil
> "hello, world"
> #+END_SRC
> #+RESULTS:
> : hello, world
>
> Yes, the above appears to work.

But it doesn't work with sessions. Can you advise what settings to have how I 
can have the following code in an Org document:

#+BEGIN_SRC python :results output :exports results :session foo :cache nil
print("hello, world")
#+END_SRC
#+RESULTS:
: hello, world

And easily export that document without evaluating the code?

Thanks,

  -k.



Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]

2016-05-20 Thread Ken Mankoff

On 2016-05-19 at 23:33, Charles C. Berry  wrote:
> On Thu, 19 May 2016, Ken Mankoff wrote:
>
>> I've noticed that code and results are all getting exported in the
>> latest Org mode git head. This is new behavior. I haven't traced it
>> to what commit caused this change, but the stock 8.2.10 install does
>> not have this bug.
>>
>> The offending setting is:
>>
>> (setq org-export-babel-evaluate nil)
>
> I think this is a *feature* not a bug.
>
> It turns off all of babel on export. So the code will still be there
> and any results that were already in the buffer will also be there.

The documentation is: "Switch controlling code evaluation during export.
When set to nil no code will be evaluated as part of the export
process."

which is different than "all code and results will be exported". Evaluation and 
export are two different things.

> You can use `org-babel-remove-result-one-or-many' with a prefix if you 
> want results to be stripped (prior to export, say).
>
> You can use :cache to prevent re-evaluation of code blocks and set
> org-export-babel-evaluate to t. Then the `:exports results' blocks
> will not have their code run nor exported.


(setq org-export-babel-evaluate t)

#+BEGIN_SRC octave :exports results :cache nil
"hello, world"
#+END_SRC
#+RESULTS:
: hello, world

Yes, the above appears to work.

Thanks,

   -k.



Re: [O] org-tag-alist - fullscreen problem when adding tags

2016-05-20 Thread Peter Sterner
2016-05-19 10:27 GMT+02:00 Nicolas Goaziou :

>
> FWIW, I cannot reproduce it. You may want to debug
> `org-fast-tag-selection' to understand what happens in your case.
>
> Are you using dedicated windows or some such ?


No. I will try and debug. Thank you for your assistance.