Re: [O] suppress leading ":" in org-babel output
Hello,
Many thanks updating org-mode resolved the issue
Best regards,
Jeremie
> FWIW, I just get the last line:
>
> #+NAME:mean_purchase_per_shopping_trip
>
> #+BEGIN_SRC R :var x=6 :results output :session *R*
> a <-sprintf("%.2f",12.234324)
> cat(a,sep="\n")
> #+END_SRC
>
> #+RESULTS:
> : 12.23
>
> This is with
>
>GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of
> 2019-05-01
>Org mode version 9.2.3 (release_9.2.3-367-gd79e80 @
> /home/nick/elisp/org-mode/lisp/)
>R version 3.5.3 (2019-03-11) -- "Great Truth"
>
> on Fedora 29.
Re: [O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.
On 25 Apr 2019, Nicolas Goaziou wrote:
>Hello,
>
>Karl Fogel writes:
>
>> My proposal is for each raw prefix arg (each `C-u' prefix) to expand
>> the narrowing level outward/upward by one. So in the above situation:
>
>I suggest to use a numeric argument for that. M-1 for one level, M-2 for
>two levels, maybe M-0 equivalent to current behaviour. C-u can be
>a shortcut for M-1.
Thanks to you and Alan Tyree for your encouraging replies.
In a followup message, you added:
> Further to my previous message: there is already provision for a
> numerical prefix in org-tree-to-indirect-buffer. I suppose that it
> and org-narrow-to-subtree should behave the same.
Ahhh, okay, hmmm -- I didn't know about `org-tree-to-indirect-buffer'. This
makes the situation somewhat more complex. Let me explain:
First, I agree it should be a numeric argument, and we can treat "C-u"
specially, making each C-u be equivalent to one increment. E.g., "C-u" is
"M-1", as you said, and "C-u C-u" is "M-2", etc. This may be a slightly
unusual behavior in Emacs, but given the low numbers we're talking about here,
and the high convenience of just being able to repeat C-u a certain number of
times to indicate that number of levels, I think it's well worth it.
However, my orginal thought was that the number would be relative *from* the
level point is currently at. In other words, if you're in the 5th nested
subtree down ("* " is the most recent heading prefix), then `M-1
org-narrow-to-subtree' would narrow to the next level up -- the 4th-level
nesting.
Unfortunately, this is the opposite of how `org-tree-to-indirect-buffer'
interprets prefixes:
"With a numerical prefix ARG, go up to this level and then take that tree.
If ARG is negative, go up that many levels."
In other words, in `org-tree-to-indirect-buffer', the number is counted down
from the absolute reference point of the top level (although you can use a
negative number to get the behavior I was proposing for
`org-narrow-to-subtree').
I'd like to be consistent with existing commands. But still, most of the time
a user would (I conjecture) want to choose their narrowing level *relative* to
the level of where point currently is. That's certainly what I always want:
I'm at a certain nesting level, and either I want to narrow to that level, or
to the one right above it, or to the one above that, etc. I'm always thinking
in terms relative to where I am now, not relative to the far-away top level.
In fact, I'm not necessarily even aware of the absolute nesting count of where
I am now -- and I don't need to know either, for the purposes of narrowing.
So here's my updated proposal:
Purely numeric prefix arguments behave as in `org-tree-to-indirect-buffer', but
each C-u behaves as an increment in the other direction (i.e., the way negative
numbers behave for `org-tree-to-indirect-buffer'). Numeric arguments would
thus be consistent with `org-tree-to-indirect-buffer', but there would still be
a way, using repeated "C-u"s, to quickly and conveniently indicate a nesting
level relative to where one currently is.
Thoughts?
Best regards,
-Karl
>> If you offer too many `C-u's, such that the narrowing would be wider
>> than the current surrounding first-level subtree, then there are two
>> possible ways we could handle it:
>>
>> 1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.
>>
>> 2) Throw an error.
>>
>> I prefer (1), because it would be the more useful behavior, even
>> though (2) would be easier to implement (since `org-back-to-heading'
>> already throws the error). However, I'd welcome others' feedback on
>> that question, or on any other aspect of this proposal.
>
>1 sounds good.
>
>I think it is a good idea.
>
>Thank you.
>
>Regards,
[O] strange output when executing matlab using babel, strange ,
Hi
I am running Ubuntu 16.06, matlab 2018b and I am using the python
kernel to use matlab from within org mode
Thanks to John Kitchin, I have the following setting
* Lisp setting
#+BEGIN_SRC emacs-lisp
(setq org-confirm-babel-evaluate nil) ;don't prompt me to confirm everytime I
want to evaluate a block
;;; display/update images in the buffer after I evaluate
(add-hook 'org-babel-after-execute-hook 'org-display-inline-images 'append)
(add-to-list 'org-src-lang-modes '("matlab" . matlab))
(setq python-shell-interpreter "python3")
;; set default headers for convenience
(setq org-babel-default-header-args:matlab
'((:results . "output replace")
(:session . "matlab")
(:kernel . "matlab")
(:exports . "code")
(:cache . "no")
(:noweb . "no")
(:hlines . "no")
(:tangle . "no")))
(defalias 'org-babel-execute:matlab 'org-babel-execute:ipython)
(defalias 'org-babel-prep-session:matlab 'org-babel-prep-session:ipython)
(defalias 'org-babel-matlab-initiate-session
'org-babel-ipython-initiate-session)
#+END_SRC
* The problem
When I run
#+begin_src matlab :results output latex :exports results :eval never-export
disp('*Step 3:*')
disp('*Step 3:* Calculate this')
#+end_src
On obtain
#+RESULTS:
#+begin_export latex
,*Step 3:*
,*Step 3:* Calculate this
#+end_export
Instead of
#+begin_export latex
*Step 3:*
*Step 3:* Calculate this
#+end_export
Does anybody have an idea what is wrong there?
Uwe Brauer
Re: [O] strange output when executing matlab using babel, strange ,
I believe you are seeing org's escaping at play. It puts a comma in front
of the leading *. It must think that it is a heading in org-syntax, and so
it escapes it to avoid some issues.
I think here it is a bug since that is not a heading. can you use some
other leading character? I don't think the * have any significance in latex.
John
---
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
On Fri, May 31, 2019 at 9:11 AM Uwe Brauer wrote:
>
>
> Hi
>
> I am running Ubuntu 16.06, matlab 2018b and I am using the python
> kernel to use matlab from within org mode
>
>
> Thanks to John Kitchin, I have the following setting
>
> * Lisp setting
> #+BEGIN_SRC emacs-lisp
> (setq org-confirm-babel-evaluate nil) ;don't prompt me to confirm
> everytime I want to evaluate a block
>
> ;;; display/update images in the buffer after I evaluate
> (add-hook 'org-babel-after-execute-hook 'org-display-inline-images 'append)
>
>
> (add-to-list 'org-src-lang-modes '("matlab" . matlab))
> (setq python-shell-interpreter "python3")
>
> ;; set default headers for convenience
> (setq org-babel-default-header-args:matlab
> '((:results . "output replace")
> (:session . "matlab")
> (:kernel . "matlab")
> (:exports . "code")
> (:cache . "no")
> (:noweb . "no")
> (:hlines . "no")
> (:tangle . "no")))
>
> (defalias 'org-babel-execute:matlab 'org-babel-execute:ipython)
> (defalias 'org-babel-prep-session:matlab 'org-babel-prep-session:ipython)
> (defalias 'org-babel-matlab-initiate-session
> 'org-babel-ipython-initiate-session)
> #+END_SRC
>
>
> * The problem
>
> When I run
>
> #+begin_src matlab :results output latex :exports results :eval
> never-export
> disp('*Step 3:*')
> disp('*Step 3:* Calculate this')
> #+end_src
>
>
> On obtain
> #+RESULTS:
> #+begin_export latex
> ,*Step 3:*
> ,*Step 3:* Calculate this
> #+end_export
>
>
> Instead of
>
> #+begin_export latex
> *Step 3:*
> *Step 3:* Calculate this
> #+end_export
>
>
> Does anybody have an idea what is wrong there?
>
> Uwe Brauer
>
>
>
Re: [O] strange output when executing matlab using babel, strange ,
>>> "JK" == John Kitchin writes:
> I believe you are seeing org's escaping at play. It puts a comma in front
> of the leading *. It must think that it is a heading in org-syntax, and so
> it escapes it to avoid some issues.
> I think here it is a bug since that is not a heading. can you use some
> other leading character? I don't think the * have any significance in latex.
The point is after executing the matlab code, I export the org file to
latex and then the * * gets translated to \textbf{} which is what I
want.
I could use / / instead obtaining italics or emp, but I want bold
I could write \textbf but I want to write as little latex commands as
possible (that is the work of the converter) instead I wan to use org
mode syntaxis for the font highlighting.
smime.p7s
Description: S/MIME cryptographic signature
Re: [O] strange output when executing matlab using babel, strange ,
Uwe Brauer writes:
> Hi
>
> I am running Ubuntu 16.06, matlab 2018b and I am using the python
> kernel to use matlab from within org mode
>
>
>
> * The problem
>
> When I run
>
> #+begin_src matlab :results output latex :exports results :eval never-export
> disp('*Step 3:*')
> disp('*Step 3:* Calculate this')
> #+end_src
>
> On obtain
> #+RESULTS:
>
> #+begin_export latex
> ,*Step 3:*
> ,*Step 3:* Calculate this
> #+end_export
>
> Instead of
>
> #+begin_export latex
> *Step 3:*
> *Step 3:* Calculate this
> #+end_export
>
> Does anybody have an idea what is wrong there?
>
I don't think anything is wrong: org quotes lines that look like
headlines in the babel output by prepending the comma.
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: [O] strange output when executing matlab using babel, strange ,
> Uwe Brauer writes: > I don't think anything is wrong: org quotes lines that look like > headlines in the babel output by prepending the comma. But it shouldn't I want the output to be surrounded by * * because then it is exported to latex as \textbf smime.p7s Description: S/MIME cryptographic signature
Re: [O] strange output when executing matlab using babel, strange ,
you are putting it in :results output latex though, so it won't be changed on export. The contents of that block will be used verbatim I think in the latex export. Maybe you can change latex to raw instead. Then the org syntax will get converted to \textbf. Otherwise, I think you have to put the latex markup in the output. I still think it is a bug though, *step3:* does not act like a headline, and isn't valid headline syntax even at the beginning of a line. I don't think it should be getting escaped here. John --- 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 On Fri, May 31, 2019 at 10:59 AM Uwe Brauer wrote: > >> Uwe Brauer writes: > > >> I don't think anything is wrong: org quotes lines that look like >> headlines in the babel output by prepending the comma. > > But it shouldn't I want the output to be surrounded by * * because then > it is exported to latex as \textbf >
Re: [O] [PATCH] Add :target option for the TOC keyword
Hello, Sacha Chua writes: > - catch the signal raised by org-export-resolve-fuzzy-link and then check for > the > special case of "local" > - always handle :target "local" as a local TOC > - or just leave the behaviour as it is. What would you recommend? The latter is fine. I applied you patch. Thank you. Regards, -- Nicolas Goaziou
Re: [O] suppress leading ":" in org-babel outputariBLE
AFAICS, the latest update (99aa984) did NOT fix the issue.
There are complications in this story that I explain here.
If I start a fresh *R* session by eval'ing the src block, I get
#+RESULTS:
:
: 12.23
and the *R* buffer ends with
--8<---cut here---start->8---
> x <- 6L
a <-sprintf("%.2f",12.234324)
cat(a,sep="\n")
'org_babel_R_eoe'
> >
12.23
>
[1] "org_babel_R_eoe"
>
--8<---cut here---end--->8---
If I then open a buffer in ESS[R] mode and run ess-eval-line-visibly-and-step
(e.g. by typing C-c C-n)
and then eval the src block again, I get
#+RESULTS:
: 12.23
and the *R* buffer ends with
--8<---cut here---start->8---
> x <- 6L
a <-sprintf("%.2f",12.234324)
cat(a,sep="\n")
'org_babel_R_eoe'
> > 12.23
> [1] "org_babel_R_eoe"
>
--8<---cut here---end--->8---
Presumably, a comint or ess variable has changed to effect these differences.
I am unable to discern what variable that is.
I suspect that the changed behavior Jeremie sees now was do to something
similar and that a fresh start will result in the extraneous line in the
results.
:-(
Chuck
> On May 31, 2019, at 12:05 AM, Jeremie Juste wrote:
>
> Hello,
>
> Many thanks updating org-mode resolved the issue
>
> Best regards,
> Jeremie
>> FWIW, I just get the last line:
>>
>> #+NAME:mean_purchase_per_shopping_trip
>>
>> #+BEGIN_SRC R :var x=6 :results output :session *R*
>> a <-sprintf("%.2f",12.234324)
>> cat(a,sep="\n")
>> #+END_SRC
>>
>> #+RESULTS:
>> : 12.23
>>
>> This is with
>>
>> GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of
>> 2019-05-01
>> Org mode version 9.2.3 (release_9.2.3-367-gd79e80 @
>> /home/nick/elisp/org-mode/lisp/)
>> R version 3.5.3 (2019-03-11) -- "Great Truth"
>>
>> on Fedora 29.
>
>
Re: [O] strange output when executing matlab using babel, strange ,
>>> "JK" == John Kitchin writes: > you are putting it in :results output latex though, so it won't be changed > on export. The contents of that block will be used verbatim I think in the > latex export. Maybe you can change latex to raw instead. Then the org > syntax will get converted to \textbf. Right! Raw is the solution #+begin_src matlab :results output raw :exports results :eval never-export #+end_src Does precisely what I want, thanks a lot > Otherwise, I think you have to put the latex markup in the output. > I still think it is a bug though, *step3:* does not act like a headline, > and isn't valid headline syntax even at the beginning of a line. I don't > think it should be getting escaped here. That is what I think, it is a bug, Nick does not agree. > John > --- > 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 > On Fri, May 31, 2019 at 10:59 AM Uwe Brauer wrote: >> >> > Uwe Brauer writes: >> >> >> > I don't think anything is wrong: org quotes lines that look like >> > headlines in the babel output by prepending the comma. >> >> But it shouldn't I want the output to be surrounded by * * because then >> it is exported to latex as \textbf >> smime.p7s Description: S/MIME cryptographic signature
