[O] src blocks: code is /always/ exported

[Martin Gürtler]

Dear list,

I am exporting the following org mode file:
8<
* doc
#+BEGIN_SRC shell :exports none
ls |wc
#+END_SRC

#+RESULTS:
: 20  20 199
8<

I'd expect org mode to honour the :exports none header argument and
create a document that contains only the result.

However, the exported document contains  both, code and results.

This seems to be independent of the type of SRC and independent of the
export type (I tried dot and shell for odt, latex and beamer exports).

How can I get rid of the src code in the exported document?

Thanks for help,

Martin


Emacs  : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.4)
 of 2016-12-01, modified by Debian
Package: Org mode version 9.0.3 (9.0.3-elpaplus @ /home/guertler/.emacs.d/elpa/org-plus-contrib-20161224/)

 

Re: [O] [PATCH] Tag visibility fixup after setting them

[Nicolas Goaziou]

Hello,

Alexey Lebedeff  writes:

> I'm attaching updated patch.

Applied. Thank you.

> But I'm not sure it's a good idea to add another 6 lines of code to
> the function which is already big enough.

The function is not massive either, and half the inserted lines are
comments anyway.

Besides, I tweaked the change so that it fits in a single loc (excluding
comments).

Regards,

-- 
Nicolas Goaziou

[O] mark as done on a previous date?

[Stig Brautaset]

I'm trying to use org-habit to track my habits and sometimes I don't
get around to mark stuff as done on the day I do them. I've found two
different functions for marking stuff as done in the past, but I can't
get either of them to work.

Here are the two different approaches I found. The first was at
https://www.emacswiki.org/emacs/OrgMode#toc22 and is the most general:

#+BEGIN_SRC emacs-lisp
  (defun org-todo-at-date (date)
(interactive (list (org-time-string-to-time (org-read-date
(cl-flet ((org-current-effective-time ( r) date)
  (org-today ( r) (time-to-days date)))
  (org-todo)))
#+END_SRC

The second is from
https://joelmccracken.github.io/entries/emacs-hack-set-todo-done-yesterday/
and looks like this:

#+BEGIN_SRC emacs-lisp
  (defun org-todo-toggle-yesterday ()
(interactive)
(let ((time-in-question (decode-time))) 
  (decf (nth 3 time-in-question))
  (setq time-in-question (apply 'encode-time time-in-question))
  (flet ((current-time () time-in-question))
(org-todo
#+END_SRC

Unfortunately, I haven't been able to get either to work. I've tested
with Org 9, and with =emacs -Q= (which gives me Org 8.2) but can't get
it to work in either. Perhaps the tricks employed do not work in Emacs
25?

FWIW:

: GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 
(Build 13F1911)) of 2016-09-21
: Org mode version 9.0.3 (9.0.3-elpaplus @ 
/Users/stig/.emacs.d/elpa/org-plus-contrib-20161224/)

Stig

Re: [O] [PATCH] Tag visibility fixup after setting them

[Alexey Lebedeff]

Hi Nicolas,

I'm attaching updated patch. But I'm not sure it's a good idea to add
another 6 lines of code to the function which is already big enough.

Best,
Alexey


On Thu, Dec 29, 2016 at 3:39 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Alexey Lebedeff  writes:
>
> > This fixes bug where you sometimes can't immediately see tags that were
> > just set. And to reveal them you need to go through global visibility
> > cycle.
>
> Thank you for the patch, and the test.
>
> > +(defun org-insert-visible-text ( args)
> > +  "Inserts arguments at point and makes them visible in outline.
> > +
> > +When text is being inserted on the invisible region boundary, it
> > +can be inadvertently sucked into invisibility."
> > +  (let* ((before-point (point)))
> > +(apply #'insert args)
> > +(outline-flag-region before-point (point) nil)))
>
> I don't think, for the time being, it deserves a dedicated function.
> I suggest to integrate it in `org-set-tags' instead.
>
> Could you send an updated patch ?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>


0001-Reveal-tags-after-setting-them.patch
Description: Binary data

Re: [O] Referring to an Org Babel variable in the invocation arguments to another Org Babel code block

[Nicolas Goaziou]

Hello,

Zack Piper  writes:

> When I use your example, and adjust it slightly:
>
> #+NAME: block-1
> #+BEGIN_SRC shell :var x="X"
>
> echo ">>>" $x "<<<" #+END_SRC
>
> #+BEGIN_SRC shell :var c="test" y=block-1(c)
> echo $y
> #+END_SRC
>
> #+RESULTS:
> : >>> $c <<<

ITYM

  y=block-1("c")

Regards,

-- 
Nicolas Goaziou

[O] Bug: org-publish-get-project-from-filename raises (wrong-type-argument sequencep any)

[Arun Isaac]

On list elements of `org-publish-project-alist' with :base-extension any
`org-publish-get-project-from-filename' fails with error
(wrong-type-argument sequencep any). This is due to the `concat' call in
`org-publish-get-project-from-filename' where it attempts to construct a
regex by concatenating several strings together. When extension `x' is
any (a symbol), this step fails.

Regards,
Arun Isaac.


signature.asc
Description: PGP signature

Re: [O] src blocks: code is /always/ exported

[Lars E. Pettersson]

On 12/29/16 19:45, Martin Gürtler wrote:

I do not really need src block evaluation during export. I only need to
evaluate (manually) when I changed the graphics src, what I am doing
anyway to check the changed image.

But how would I control the (not-)inclusion of the src code during
export in that case?


I am using the following:

(add-to-list 'org-babel-default-header-args '(:eval . "never-export"))
(add-to-list 'org-babel-default-inline-header-args '(:eval . 
"never-export"))


Lars
--
Lars E. Pettersson 
http://www.sm6rpz.se/

Re: [O] src blocks: code is /always/ exported

[Charles C. Berry]

On Thu, 29 Dec 2016, Martin Gürtler wrote:


Am Donnerstag, 29. Dezember 2016, 09:07:40 CET schrieb Charles C. Berry:

On Thu, 29 Dec 2016, "Martin Gürtler" wrote:

Dear list,
I am exporting the following org mode file:


[deleted]



But how would I control the (not-)inclusion of the src code during
export in that case?


As I wrote:

#+begin_quote

You might also note the advice in the docstring:

"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

#+end_quote


If that was not clear, review

(info "(org) Exporting code blocks")

particularly the paragraph that starts "Turning off evaluation..."


Chuck

Re: [O] src blocks: code is /always/ exported

[Charles C. Berry]

On Thu, 29 Dec 2016, "Martin Gürtler" wrote:


Dear list,
I am exporting the following org mode file:
8<
* doc
#+BEGIN_SRC shell :exports none
ls |wc
#+END_SRC
#+RESULTS:
: 20  20 199
8<
I'd expect org mode to honour the :exports none header argument and
create a document that contains only the result.
However, the exported document contains  both, code and results.
This seems to be independent of the type of SRC and independent of the
export type (I tried dot and shell for odt, latex and beamer exports).
How can I get rid of the src code in the exported document?


What does C-h v org-export-use-babel RET say?

If the result is not `t' that is the problem, and somewhere in your setup 
you have set that variable (or its predecessor org-export-babel-evaluate) 
to nil or something other than `t'.


If this is the problem, set org-export-use-babel to `t'. You might 
also note the advice in the docstring:


"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

HTH,

Chuck

Re: [O] src blocks: code is /always/ exported

[Martin Gürtler]

Am Donnerstag, 29. Dezember 2016, 09:07:40 CET schrieb Charles C. Berry:
> On Thu, 29 Dec 2016, "Martin Gürtler" wrote:
> > Dear list,
> > I am exporting the following org mode file:
> > 8<
> > * doc
> > #+BEGIN_SRC shell :exports none
> > ls |wc
> > #+END_SRC
> > 
> > #+RESULTS:
> > : 20  20 199
> > 
> > 8< I'd expect org mode to honour the
> > :exports none header argument and create a document that contains
> > only the result.  However, the exported document contains both, code
> > and results.  This seems to be independent of the type of SRC and
> > independent of the export type (I tried dot and shell for odt, latex
> > and beamer exports).  How can I get rid of the src code in the
> > exported document?
> 
> What does C-h v org-export-use-babel RET say?
> 
> If the result is not `t' that is the problem, and somewhere in your setup
> you have set that variable (or its predecessor org-export-babel-evaluate)
> to nil or something other than `t'.

That was indeed the culprit. I had switched it off to speed up export. After
setting that to t again it works (of course). Drawbacks are, that I need to
confirm the evaluation in each export (I am a bit hesitant to generally
accepting src block evaluation), and evaluation takes time.

I do not really need src block evaluation during export. I only need to
evaluate (manually) when I changed the graphics src, what I am doing
anyway to check the changed image.

But how would I control the (not-)inclusion of the src code during
export in that case?

Thanks,

Martin




signature.asc
Description: This is a digitally signed message part.

[O] Getting "Chapter" before a heading number

[Peter Davis]

I'm preparing a proposed table of contents for a book, and I'd like the HTML 
output to appear like:

Chapter 1 Blah
  1.1 blah
  1.2 blah blah
  1.3 blah blah blah

Chapter 2 Blah Blah
  2.1 blah
  2.2 blah blah

etc.

Is there a way to get HTML output to do this? I'd like the "*" at the start of 
a line to denote a new chapter, and nested headings
to go inside. I haven't been able to find anything like this.

Thanks very much, and Happy New Year to all!

-pd

Re: [O] speeding up Babel Gnuplot

[Nicolas Goaziou]

Hello,

Thierry Banel  writes:

> Babel Gnuplot is quite slow on large tables.
> Example: 45 seconds for a 1500 rows table.
>
> Why? Because orgtbl-to-generic is too slow (or too generic). Its
> behavior seems to be quadratic O(size^2). Should we bypass it?

I don't think so.

> Should we try to optimize it?

I did some optimizations in master branch. I go below 1 sec for the 1500
rows table.

> Here is a fix to speed up the rendering to a mere fraction of a second.
>
> #+BEGIN_SRC elisp
> (defun org-babel-gnuplot-table-to-data (table data-file params)
>   "Export TABLE to DATA-FILE in a format readable by gnuplot."
>   (let ((org-babel-gnuplot-timestamp-fmt
>  (or (plist-get params :timefmt) "%Y-%m-%d-%H:%M:%S")))
> (with-temp-file data-file
>   (mapc (lambda (line)
>   (mapc (lambda (cell)
>   (insert (org-babel-gnuplot-quote-tsv-field cell))
>   (insert "\t"))
> line)
>   (insert "\n"))
> table)))
>   data-file)
> #+END_SRC

The comparison is not fair, because the function doesn't handle all the
cases `orgtbl-to-generic' handles.

Regards,

-- 
Nicolas Goaziou

Re: [O] Getting "Chapter" before a heading number

[Richard Lawrence]

Hi Peter,

Peter Davis  writes:

> I'm preparing a proposed table of contents for a book, and I'd like the HTML 
> output to appear like:
>
> Chapter 1 Blah
>   1.1 blah
>   1.2 blah blah
>   1.3 blah blah blah
>
> Chapter 2 Blah Blah
>   2.1 blah
>   2.2 blah blah
>
> etc.
>
> Is there a way to get HTML output to do this? I'd like the "*" at the start 
> of a line to denote a new chapter, and nested headings
> to go inside. I haven't been able to find anything like this.
>

This might not be exactly what you want, but it's pretty trivial to do
this with CSS.  In your stylesheet, you want something like (untested):

span.section-number-2:before { content: "Chapter" }

Basically, this tells the browser to put the word "Chapter" before the
number of a first-level headline (which, in a default setup, is exported
as a span tag with class section-number-2).

If you'd rather that "Chapter" appears in the actual HTML, you probably
want to use a filter on headlines during export.

Hope that helps!
 
Best,
Richard

Re: [O] speeding up Babel Gnuplot

[Thierry Banel]

Le 29/12/2016 21:04, Nicolas Goaziou a écrit :
> I did some optimizations in master branch. I go below 1 sec for the 1500
> rows table.
Confirmed! Your latest commit givesa huge boost.

>> Here is a fix to speed up the rendering to a mere fraction of a second.
>>
>> #+BEGIN_SRC elisp
>> (defun org-babel-gnuplot-table-to-data (table data-file params)
>>   "Export TABLE to DATA-FILE in a format readable by gnuplot."
>>   (let ((org-babel-gnuplot-timestamp-fmt
>>  (or (plist-get params :timefmt) "%Y-%m-%d-%H:%M:%S")))
>> (with-temp-file data-file
>>   (mapc (lambda (line)
>>   (mapc (lambda (cell)
>>   (insert (org-babel-gnuplot-quote-tsv-field cell))
>>   (insert "\t"))
>> line)
>>   (insert "\n"))
>> table)))
>>   data-file)
>> #+END_SRC
> The comparison is not fair, because the function doesn't handle all the
> cases `orgtbl-to-generic' handles.
>
Of course it was not fair.
It was just a quick-and-dirty-not-to-be-commited patch to discuss the issue.
And of course improving orgtbl-to-generic benefits to many usages,
besidesBabel Gnuplot.
Thanks for taking care and doing so so quickly.

Thierry

Re: [O] Bug: org-publish-get-project-from-filename raises (wrong-type-argument sequencep any)

[Nicolas Goaziou]

Hello,

Arun Isaac  writes:

> On list elements of `org-publish-project-alist' with :base-extension any
> `org-publish-get-project-from-filename' fails with error
> (wrong-type-argument sequencep any). This is due to the `concat' call in
> `org-publish-get-project-from-filename' where it attempts to construct a
> regex by concatenating several strings together. When extension `x' is
> any (a symbol), this step fails.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-publish-get-project-from-filename raises (wrong-type-argument sequencep any)

[Arun Isaac]

Nicolas Goaziou writes:

> Hello,
>
> Arun Isaac  writes:
>
>> On list elements of `org-publish-project-alist' with :base-extension any
>> `org-publish-get-project-from-filename' fails with error
>> (wrong-type-argument sequencep any). This is due to the `concat' call in
>> `org-publish-get-project-from-filename' where it attempts to construct a
>> regex by concatenating several strings together. When extension `x' is
>> any (a symbol), this step fails.
>
> Fixed. Thank you.

Perhaps, `org-publish-get-project-from-filename' can be rewritten
without `catch' and `throw' using `cl-some' or `seq-some'. This is not a
bug. But, it might help improve readability of the logic.

Thanks,
Arun Isaac.


signature.asc
Description: PGP signature