Re: [O] Should comments break paragraphs?

[Suvayu Ali]

On Tue, Jul 16, 2013 at 07:51:38PM +0200, Nicolas Goaziou wrote:
> Eric Schulte  writes:
> 
> >> Even if you move it to ox.el, this is not an acceptable solution. Think
> >> about the following example
> >>
> >>  - item 1
> >>
> >># with a comment
> >>
> >>  - item 2
> >>
> >> If you simply delete matching lines, you break the list.
> >>
> >
> > Yes, I would argue that this list should be broken, because with or
> > without the comment the items are separated by two blank lines.
> 
> On the other hand, visually, this list looks perfectly correct.

Actually I can think of at least one use case where you would want that
to be a list.  Say when drafting, you have a list of things you are
discussing, but you have yet to fill in the details and the comment has
some notes/reminder for tomorrow.  In this case, adding missing content
should not change the structure of your document, i.e. join two lists
into one.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Should comments break paragraphs?

[Nicolas Goaziou]

Hello,

Bastien  writes:

> I think everyone agrees that comments are an important part of Org.

Then I, for one, am not in the "everyone" part. FWIW, I think comments
are a minor part of Org and that we're just bikeshedding.

> Nicolas, apart from the current code, what theoretically prevents Org
> from considering them as *empty* lines (not blank lines)?

This question is too vague.

What is the difference between an empty line and the way they are
treated actually? More importantly, where, precisely, comments should be
allowed to appear in an Org buffer?

IOW, you need to define exactly what a comment should be in Org, first,
if the current definition doesn't suit you (or someone else willing to
change it). Then, we'll know where the pitfalls are.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer

[Øyvind Stegard]

Daimrod  writes:

[...]

> Thanks for the bug report!
>
> Don't you think that checking if one of the buffer would be enough and
> faster?
> With something like (every #'get-file-buffer org-contacts-files)

Hi,

I thought about that, yes. But what about when an org-contacts buffer is
killed and subsequently re-opened (like using `find-alternate-file' with
same file name). Then the buffer will exist for the file, but it will be
a new instance, and the markers in org-contacts-db will still be dead.
That's why I decided to just check the markers instead.


Regards,

Øyvind
-- 
< Øyvind Stegard
 < http://stegard.net/

Re: [O] Should comments break paragraphs?

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

>> I think everyone agrees that comments are an important part of Org.
>
> Then I, for one, am not in the "everyone" part. FWIW, I think comments
> are a minor part of Org and that we're just bikeshedding.

Perhaps "part" is not the right word here.

The way to know whether comments are important or not is to poll
users.  My guess is that many of them use comments (I do a lot).
That's what I call "important".

And I don't think we not bikeshedding: several users explain why
they think the current behavior does not match what they expect.
If the conversation goes on, it's just that the answer is not
what they expect either.

>> Nicolas, apart from the current code, what theoretically prevents Org
>> from considering them as *empty* lines (not blank lines)?
>
> This question is too vague.
>
> What is the difference between an empty line and the way they are
> treated actually?

(I used the "empty vs. blank" line terminology from the thread.)

By considered an empty line, I mean this:

This is
# a comment
within a paragraph.

If "# a comment" is considered to be an empty line (i.e. a no-line),
then the above is treated as one single paragraph.  If it is treated
as a blank line, the above is treated as three paragraphs: a first
paragraph, a commented paragraph, another paragraph.

> More importantly, where, precisely, comments should be
> allowed to appear in an Org buffer?

I think "no-line" comments they should be allowed anywhere expect in
src code blocks, where the comment syntax is different.

For example this list:

- an item
# a comment
- another item

would be treated as

- an item
- another item

etc.

> IOW, you need to define exactly what a comment should be in Org, first,
> if the current definition doesn't suit you (or someone else willing to
> change it). Then, we'll know where the pitfalls are.

I think we have two options: either define comments in Org syntax,
either treat them as normal lines and delete them before parsing a
buffer for export purposes.

A simple (setq org-export-ignore-comments t) would put the user in
the second situation, where comments are deleted before parsing and
exporting, and treated as standard citizens when manipulating or
buffers.  (Eric's patch goes into that direction.)

Then (setq org-export-ignore-comments nil) would put us in the first
situation, which is the current one, where comments are defines as
elements within Org syntax, with some constraints when parsing or
exporting them (such as separating a paragraph.)

What do you think?

-- 
 Bastien

Re: [O] Should comments break paragraphs?

[Nicolas Goaziou]

Bastien  writes:

> By considered an empty line, I mean this:
>
> This is
> # a comment
> within a paragraph.
>
> If "# a comment" is considered to be an empty line (i.e. a no-line),
> then the above is treated as one single paragraph.  If it is treated
> as a blank line, the above is treated as three paragraphs: a first
> paragraph, a commented paragraph, another paragraph.

Why is it an issue on the Org side? So far, it only seems to be an
annoyance when exporting to HTML (and maybe ODT).

>> More importantly, where, precisely, comments should be
>> allowed to appear in an Org buffer?
>
> I think "no-line" comments they should be allowed anywhere expect in
> src code blocks, where the comment syntax is different.
>
> For example this list:
>
> - an item
> # a comment
> - another item
>
> would be treated as
>
> - an item
> - another item
>
> etc.

Then it requires serious coding in many parts of Org, as I already
explained in this thread.

> I think we have two options: either define comments in Org syntax,
> either treat them as normal lines and delete them before parsing a
> buffer for export purposes.

I already explained why the second "option" wasn't one. Look again at
your example:

  1. an item
  # a normal line breaking the list
  1. an item in another list

but, upon exporting, both items will belong to the same list. This is
just nonsensical.

> A simple (setq org-export-ignore-comments t) would put the user in
> the second situation, where comments are deleted before parsing and
> exporting, and treated as standard citizens when manipulating or
> buffers.  (Eric's patch goes into that direction.)

And the direction is wrong... Parsing shouldn't modify the buffer being
parsed, ever. But you can use a hook for that purpose.

> Then (setq org-export-ignore-comments nil) would put us in the first
> situation, which is the current one, where comments are defines as
> elements within Org syntax, with some constraints when parsing or
> exporting them (such as separating a paragraph.)
>
> What do you think?

I still think the same. Comments belong to Org syntax (if they don't,
you can't even fill them correctly, for example). If you redefine them,
there's no easy workaround. You have to change every part of Org that
assumes there will be no comment in its way (lists, agenda, babel,
parser and probably more I can't think of).

If it's an HTML/ODT export issue, it's far easier to patch the export
back-ends instead. 10 lines of code in each one, maybe.


Regards,

-- 
Nicolas Goaziou

[O] Org-protocol does not work with org-capture

[Sineau Gh]

Hi all,
I'm sineau and I'm new member of the mailing list and newbie in org-mode. I
have a problem with org-protocol which I searched in the mailing list and
also stackoverflow with no luck.
I'm trying to setup org-protocol and here's my config:

(server-start)
(require 'org-protocol)

(setq org-protocol-default-template-key "l")
 (global-set-key "\C-cc" 'org-capture)

Now org-capture returns this error:

 Symbol's function definition is void: org-contextualize-keys
 Greedy org-protocol handler. Killing client.

I didn't know path-load to org-protocol.el so I left it empty in emacs
config. I use emacs 24.2 on ubuntu 13.04 (downloaded from ubuntu default
repo) and get org-mode package via emacs packages.

[O] ASCII art in org src mode triggers font lock glitch

[Jisang Yoo]

Short description:

Invoking C-c ' (org-edit-special) on an org src block containing an
ascii diagram causes table recognition and font lock glitch if the
diagram has a rectangle in it.




Long description:

Invoke C-c ' on any of the following three src blocks

#+BEGIN_SRC artist
  +-+
  | |
  |  box1   |
  | |
  +-+
#+END_SRC

#+BEGIN_EXAMPLE
  +-+
  | |
  |  box2   |
  | |
  +-+
#+END_EXAMPLE

#+BEGIN_ASCII
  +-+
  | |
  |  box3   |
  | |
  +-+
#+END_ASCII

and org src mode will trigger table recognition (message "Recognizing
tables...done" in echo area) and leave some font lock glitch such as
blue background inside the rectangle. Another glitch is that if the
user uses variable-pitch for text outside source blocks and
fixed-pitch for text inside them, the org-src-mode buffer will be in
variable-pitch font after table recognition is triggered.

This bug sometimes disappear on second invoke of org-edit-special of
the same block.




Workarounds for now:

1. Prefixing the diagram (with dots in this case):

#+BEGIN_EXAMPLE
  . +-+
  . | |
  . |   box   |
  . | |
  . +-+
#+END_EXAMPLE

2. Using a colon block which does not have the benefit of being foldable:

: +-+
: | |
: |   box   |
: | |
: +-+

3. Not using + in rectangle corners:

#+BEGIN_EXAMPLE
   -
  | |
  |   box   |
  | |
   -
#+END_EXAMPLE

Re: [O] How to trigger the clockcheck in an agenda view.

[Rainer Stengele]

Am 12.07.2013 10:06, schrieb Rainer Stengele:
> Hi,
> 
> I want to start an aganda view over a week and immediately check the 
> consistency of clock entries:
> 
> 
> See manual for agenda dispacther:
> 
> v c
> Show overlapping clock entries, clocking gaps, and other clocking 
> problems in the current agenda range. You can then visit clocking lines and 
> fix them manually. See the
> variable org-agenda-clock-consistency-checks for information on how to 
> customize the definition of what constituted a clocking problem. To return to 
> normal agenda display, press l
> to exit Logbook mode.
> 
> 
> I can't seem to find a way to trigger the clockcheck in the agenda view 
> options.
> 
> At the moment I have::
> 
> ..
>   ("Aw"
>"agenda + no todos - this week - log-mode - ARCHIVE included - clock 
> report"
>agenda ""
>(
> (org-agenda-sorting-strategy '(time-up priority-down))
> (org-agenda-span 'week)
> (org-agenda-start-with-log-mode t)
> (org-agenda-archives-mode t)
> (org-agenda-start-with-clockreport-mode t)
> ))
> ..
> 
> Do I miss the variable to be set?
> 
> Thanks,
> Rainer
> 
> 
> 
Anybody?

Re: [O] Should comments break paragraphs?

[Eric Schulte]

Nicolas Goaziou  writes:

> Eric Schulte  writes:
>
>> So are you proposing to remove comments from Org-mode entirely? 
>
> Certainly not.
>

Great, then I think we're much closer together on this than I originally
thought.

>
> I'm on the "good enough" side and I simply suggest to live with it.
> Also, if you badly need inline comments, there's the empty "comment"
> macro:
>
>   #+MACRO: comment 
>
>   Some text {{{comment(This is my comment)}}} and some more.
>

I'm not suggesting adding inline comments, only that comment lines be
treated as "" instead of "\n".

>
>> But if we treat comments as semantically empty, then maybe they should
>> be ignored by the parser?
>
> Yes, we can ignore them at the parser level. But what about the rest of
> Org? There are many places that do not rely on the parser and do not
> ignore comments (lists being an example, agenda being another one, and
> I'm pretty sure comments at some locations can break Babel too).
>
> Something could be done, but again, it would certainly not be
> a one-liner in org-element.el or ox.el.
>

I'm happy to work to fix places where babel is breaking comments.

>
>>> Even if you move it to ox.el, this is not an acceptable solution. Think
>>> about the following example
>>>
>>>  - item 1
>>>
>>># with a comment
>>>
>>>  - item 2
>>>
>>> If you simply delete matching lines, you break the list.
>>>
>>
>> Yes, I would argue that this list should be broken, because with or
>> without the comment the items are separated by two blank lines.
>
> On the other hand, visually, this list looks perfectly correct.
>
>> In my opinion comments as semantically empty lines is a simple rule
>> for both users and parsers to understand.
>
> Comments are already almost semantically empty lines. That's why:
>
>   Text
>   # Comment
>   Other Text
>
> generates two paragraphs in Org (and in every back-end excepted `latex',
> but that's a different problem). They basically act as a paragraph
> separator, much like blank lines.
>
> Also, note that if they really are empty lines, they cannot be inlined
> within paragraphs either.
>

Sorry I was unclear, see above, by "semantically empty" I meant
replacing comment lines with "" instead of the current behavior (except
in the latex exporter) which replaces them with "\n".

Cheers,

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Should comments break paragraphs?

[Bastien]

Nicolas Goaziou  writes:

>   1. an item
>   # a normal line breaking the list
>   1. an item in another list
>
> but, upon exporting, both items will belong to the same list. This is
> just nonsensical.

Users who want comments to be equivalent to empty lines will not write
the above.  If they do, it's their responsability.

>> A simple (setq org-export-ignore-comments t) would put the user in
>> the second situation, where comments are deleted before parsing and
>> exporting, and treated as standard citizens when manipulating or
>> buffers.  (Eric's patch goes into that direction.)
>
> And the direction is wrong... Parsing shouldn't modify the buffer being
> parsed, ever. But you can use a hook for that purpose.

I didn't suggest that parsing should modify the before: I said "where
comments are deleted before parsing and exporting".

There should be an easy solution for that.

>> Then (setq org-export-ignore-comments nil) would put us in the first
>> situation, which is the current one, where comments are defines as
>> elements within Org syntax, with some constraints when parsing or
>> exporting them (such as separating a paragraph.)
>>
>> What do you think?
>
> I still think the same. Comments belong to Org syntax (if they don't,
> you can't even fill them correctly, for example). If you redefine them,
> there's no easy workaround.

I didn't suggest to redefine comments.

> You have to change every part of Org that
> assumes there will be no comment in its way (lists, agenda, babel,
> parser and probably more I can't think of).
>
> If it's an HTML/ODT export issue, it's far easier to patch the export
> back-ends instead. 10 lines of code in each one, maybe.

This is a general pre-export issue, it does not depend on the
exporters themselves.

So again, what prevents us to make it easy for users to treat comments
as no-line before parsing and exporting?

-- 
 Bastien

Re: [O] ASCII art in org src mode triggers font lock glitch

[Bastien]

Hi Jisang,

what version of Emacs and Org-mode are you using?

Thanks!

-- 
 Bastien

Re: [O] Should comments break paragraphs?

[Rainer M Krug]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>>   1. an item
>>   # a normal line breaking the list
>>   1. an item in another list
>>
>> but, upon exporting, both items will belong to the same list. This is
>> just nonsensical.
>
> Users who want comments to be equivalent to empty lines will not write
> the above.  If they do, it's their responsability.
>
>>> A simple (setq org-export-ignore-comments t) would put the user in
>>> the second situation, where comments are deleted before parsing and
>>> exporting, and treated as standard citizens when manipulating or
>>> buffers.  (Eric's patch goes into that direction.)
>>
>> And the direction is wrong... Parsing shouldn't modify the buffer being
>> parsed, ever. But you can use a hook for that purpose.
>
> I didn't suggest that parsing should modify the before: I said "where
> comments are deleted before parsing and exporting".
>
> There should be an easy solution for that.
>
>>> Then (setq org-export-ignore-comments nil) would put us in the first
>>> situation, which is the current one, where comments are defines as
>>> elements within Org syntax, with some constraints when parsing or
>>> exporting them (such as separating a paragraph.)
>>>
>>> What do you think?
>>
>> I still think the same. Comments belong to Org syntax (if they don't,
>> you can't even fill them correctly, for example). If you redefine them,
>> there's no easy workaround.
>
> I didn't suggest to redefine comments.
>
>> You have to change every part of Org that
>> assumes there will be no comment in its way (lists, agenda, babel,
>> parser and probably more I can't think of).
>>
>> If it's an HTML/ODT export issue, it's far easier to patch the export
>> back-ends instead. 10 lines of code in each one, maybe.
>
> This is a general pre-export issue, it does not depend on the
> exporters themselves.
>
> So again, what prevents us to make it easy for users to treat comments
> as no-line before parsing and exporting?

OK - I can't comment on the inner workings of org and the exporters (so
this might not make any sense at all), but I think that
comments have their place in exports as well:

LaTeX: has comments
odt format: has notes

So at least in these two formats, it would make sense to provide the
exports to the exporter, so that they can then be converted to
comments. But in general, I agree that they should be treated as being
non existent, rather then as "\n", unless the exporter deals with them
on it's own.

Cheers,

Rainer

-- 
Rainer M. Krug

email: RMKruggmailcom

Re: [O] Should comments break paragraphs?

[Eric Schulte]

>
> This is a general pre-export issue, it does not depend on the
> exporters themselves.
>
> So again, what prevents us to make it easy for users to treat comments
> as no-line before parsing and exporting?

Unless I'm mistaken, I think this is exactly what my previous patch does
(reproduced here for ease of reference).

>From ce4c30ebe56d4cd66810bca48824d8841e7b130d Mon Sep 17 00:00:00 2001
From: Eric Schulte 
Date: Tue, 16 Jul 2013 09:44:59 -0600
Subject: [PATCH] support inline comments w/o breaking paragraphs

* lisp/org-element.el (org-element-parse-buffer): Strip inline comments
  as a pre-processing step before exporting.
---
 lisp/org-element.el | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 8d64657..d69d9ba 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4092,13 +4092,19 @@ or objects within the parse tree.
 
 This function assumes that current major mode is `org-mode'."
   (save-excursion
-(goto-char (point-min))
-(org-skip-whitespace)
-(org-element--parse-elements
- (point-at-bol) (point-max)
- ;; Start in `first-section' mode so text before the first
- ;; headline belongs to a section.
- 'first-section nil granularity visible-only (list 'org-data nil
+(let ((save (buffer-string)))
+  (unwind-protect
+	  (progn
+	(goto-char (point-min))
+	(delete-matching-lines "^ *# .[^\n]*\n")
+	(org-skip-whitespace)
+	(org-element--parse-elements
+	 (point-at-bol) (point-max)
+	 ;; Start in `first-section' mode so text before the first
+	 ;; headline belongs to a section.
+	 'first-section nil granularity visible-only (list 'org-data nil)))
+	(delete-region (point-min) (point-max))
+	(insert save)
 
 (defun org-element-parse-secondary-string (string restriction &optional parent)
   "Recursively parse objects in STRING and return structure.
-- 
1.8.3.2


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Should comments break paragraphs?

[Nicolas Goaziou]

Eric Schulte  writes:

> Sorry I was unclear, see above, by "semantically empty" I meant
> replacing comment lines with "" instead of the current behavior (except
> in the latex exporter) which replaces them with "\n".

They are _not_ replaced by "\n". They are replaced by "". But the parser
sees two paragraphs, and so does the exporter (even if they are not
separated by a blank line).


Regards,

-- 
Nicolas Goaziou

Re: [O] Should comments break paragraphs?

[Rasmus]

Rainer M Krug  writes:


> OK - I can't comment on the inner workings of org and the exporters (so
> this might not make any sense at all), but I think that
> comments have their place in exports as well:
>
> LaTeX: has comments

Do you mean '%'?  If so it's not part of the output and I do not agree
that LaTeX has notes.  There exists several packages enabling some
type of notes, or exporting pdf notes.  The right approach (IMO) to
add e.g. pdf notes is inlinetasks and altering
org-latex-format-inlinetask-function.  It would be interesting to add
support for pdfcomment.sty, I think.

> odt format: has notes

I assume you mean the comments that in recent version of Libreoffice
show up on the side of the documents.  Again, I don't agree that they
are comments in the sense that '^#.*' is a comment.  Again, I think
the correct approach for adding such notes is inlinetasks.

As for how to handle comments: I don't care.  For me comments are a
temporary state before moving to a separate "* trash :noexport:" or
ARCHIVE heading.

–Rasmus

-- 
The Kids call him Billy the Saint

Re: [O] Should comments break paragraphs?

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  writes:
>> And the direction is wrong... Parsing shouldn't modify the buffer being
>> parsed, ever. But you can use a hook for that purpose.
>
> I didn't suggest that parsing should modify the before: I said "where
> comments are deleted before parsing and exporting".
>
> There should be an easy solution for that.

Yes, a hook, as I suggested:

  (defun my-comment-removal (backend)
(delete-matching-lines "^[ \t]*#\\( \\|$\\)"))
  (add-hook 'org-export-before-parsing-hook 'my-comment-removal)

I maintain it is dangerous to make it a default (or even make it easier
than that) because it will cause a discrepancy between the real buffer
contents and what is really parsed. It can create strange things,
really.

> I didn't suggest to redefine comments.

Of course you did. You said comments should be available anywhere but in
source blocks, didn't you? It isn't possible without redefining them in
Org.

>> You have to change every part of Org that
>> assumes there will be no comment in its way (lists, agenda, babel,
>> parser and probably more I can't think of).
>>
>> If it's an HTML/ODT export issue, it's far easier to patch the export
>> back-ends instead. 10 lines of code in each one, maybe.
>
> This is a general pre-export issue, it does not depend on the
> exporters themselves.

What you want here is to give comments a special meaning just before
export, even though they don't have it otherwise. As an example, you can
remove the comment here just before export:

  text
  # comment
  text

but `org-element-at-point' will still see two paragraphs and a comment
between them nonetheless.

But, IIUC, the problem the OP wants to solve is different: he wants the
example above to be treated as a paragraph, not as two of them. In fact
this is more about paragraphs than comments (i.e. paragraphs definition
in targeted back-ends is different than Org's).

> So again, what prevents us to make it easy for users to treat comments
> as no-line before parsing and exporting?

It is already easy, see hook above. Nothing prevents you from making it
easier. But this is wrong.


Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG] List argument to a shell code block

[Eric Schulte]

Daniel Gerber  writes:

> Hello,
>
> It seems that passing a list to a shell code-block is broken:
>
> #+CALL: echo-sh(arg-list)
>
> #+RESULTS: echo-sh(arg-list)
> |  97 |
> |  98 |
> |  99 |
> | 120 |
> | 121 |
> | 122 |
>
> #+NAME: arg-list
> - abc
> - xyz
>
> #+NAME: echo-sh
> #+BEGIN_SRC sh :var arg=arg-list
> for a in $arg; do
>  echo "$a"
> done
> #+END_SRC
>
>
> Shouldn't it work the same as a table argument?
>
> #+CALL: echo-sh(arg-table)
>
> #+RESULTS: echo-sh(arg-table)
> | ABC |
> | XYZ |
>
> #+TBLNAME: arg-table
> | ABC |
> | XYZ |
>
>
> This is on Org-mode version 8.0.3 (8.0.3-32-g0c789f-elpa).
>
>

Hi Daniel,

Thanks for reporting this, I've just pushed up a fix.

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Should comments break paragraphs?

[Bastien]

Eric Schulte  writes:

> Unless I'm mistaken, I think this is exactly what my previous patch does
> (reproduced here for ease of reference).

Yes, this is it.

I also reproduce Nicolas snippet elsewhere in the thread, which might
be useful for other:

  (defun my-comment-removal (backend)
(delete-matching-lines "^[ \t]*#\\( \\|$\\)"))
  (add-hook 'org-export-before-parsing-hook 'my-comment-removal)


I won't discuss this further, because I feel like the discussion
was over before it even started.

-- 
 Bastien

Re: [O] [Patch] ob-ditaa.el for Cygwin

[Eric Schulte]

Achim Gratz  writes:

> Yujie Wen writes:
>> Could someone please take a look and, if it is satisfactory, please
>> help to apply it?
>
> You're missing a Changelog and emacs-p might better be called cygwin-p.
>
> More to the point: I don't think Org should care about such system
> idiosyncrasies at all.  Instead you might use a wrapper script for
> Cygwin that converts the arguments and then calls the native Windows
> java executable.
>
>> I am used to Orgmode under Cygwin and sometimes uses ditaa for drawing
>> diagrams. But without this patch, I have to switch to Windows native
>> Emacs for calling ditaa.
>
> If there's anything to do on the Org side then removing the still
> hardcoded call of "java".
>

I've just pushed up a configuration variable to allow customization of
the previously hard coded "java".  Set `org-babel-ditaa-java-cmd' to
change this.

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

[O] How to turn off visibility-state messages from 'org-cycle?

[Thorsten Jolitz]

Hi List, 

when calling Org-mode functionality form an external program, some
functions seem to make use of 'org-cycle', what results in a lot of
"OVERVIEW" messages arriving at stdout/stderr

,-
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| OVERVIEW
| 
`-


that are not really helpful and a bit of a hassle.

,-
| (org-cycle &optional ARG)
|  
|
| - When this function is called with a prefix argument, rotate the entire
|   buffer through 3 states (global cycling)
|   1. OVERVIEW: Show only top-level headlines.
|   2. CONTENTS: Show all headlines of all levels, but no body text.
|   3. SHOW ALL: Show everything.
`-

Is there a way to turn these message off? I found things like
'org-no-popups or 'org-no-warnings but nothing like
"org-no-visibility-state-messages" or so. Its not really a big problem,
rather an inconvenience, but maybe its easy to solve when knowing where
to look.

-- 
cheers,
Thorsten

Re: [O] Should comments break paragraphs?

[Eric S Fraga]

Rasmus  writes:

[...]

> show up on the side of the documents.  Again, I don't agree that they
> are comments in the sense that '^#.*' is a comment.  Again, I think
> the correct approach for adding such notes is inlinetasks.

+1

Comments are internal to the org file and should not be
exported.  Inlinetasks work very well for "notes" for exporting.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed

[O] Hiding cells in org table

[J. David Boyd]

I've scanned through the manuals, and see no way to do this, but.

Is there anyway to block out the contents of a result field in a table, until
I export it into an html file?

I'm keeping track of my hours worked, with the dollar amounts paid calculated,
and I don't want anyone wandering by my desk to be able to see how much I am
being paid.

Then I want the amount to show in the .html file that I export to have signed
off on.

Thanks,

Dave

Re: [O] Should comments break paragraphs?

[Eric S Fraga]

Nicolas Goaziou  writes:

[...]

>   (defun my-comment-removal (backend)
> (delete-matching-lines "^[ \t]*#\\( \\|$\\)"))
>   (add-hook 'org-export-before-parsing-hook 'my-comment-removal)

Nicolas,

quick question as I am trying to understand the various hooks and
filters that make up the (not so new anymore ;-) exporter.

This little snippet works just fine for comment lines.  However, I tried
changing the regexp to one that matches an :ignoreheading: tag on a
headline.  This works when I do a LaTeX export but not an HTML one.  Why
would the behaviour be different in each case?

I have tried using org-export-before-processing-hook as well but I get
the same behaviour.

I am s confused!

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed

Re: [O] Should comments break paragraphs?

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> This little snippet works just fine for comment lines.  However, I tried
> changing the regexp to one that matches an :ignoreheading: tag on a
> headline.  This works when I do a LaTeX export but not an HTML one.  Why
> would the behaviour be different in each case?

It shouldn't. Would you mind sending your hook?


Regards,

-- 
Nicolas Goaziou

Re: [O] Should comments break paragraphs?

[Eric S Fraga]

Nicolas Goaziou  writes:

> Hello,
>
> Eric S Fraga  writes:
>
>> This little snippet works just fine for comment lines.  However, I tried
>> changing the regexp to one that matches an :ignoreheading: tag on a
>> headline.  This works when I do a LaTeX export but not an HTML one.  Why
>> would the behaviour be different in each case?
>
> It shouldn't. Would you mind sending your hook?

Actually, it works so sorry about the noise.  I just tried emacs -Q and
realised that one of my other customisations was getting in the way.

For the record, this is what I have which (almost) does what I want:

#+begin_src emacs-lisp
  (defun esf/remove-lines-with-ignore-heading-tag (backend)
(message "Deleting lines with ignore heading tag")
(delete-matching-lines "^\\*+.*[ 
\t]+[a-ZA-Z0-9:]*:ignoreheading:[a-ZA-Z0-9:]*$"))
  (add-hook 'org-export-before-processing-hook 
'esf/remove-lines-with-ignore-heading-tag)
#+end_src

I say almost because I actually want to replace matching lines by "\n"
and not simply delete them (sort of going against the whole
thread... ;-).  But I'll figure this bit out -- good emacs lisp practice
for me!

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed

Re: [O] Export to LaTeX and Beamer

[Suvayu Ali]

On Wed, Jul 17, 2013 at 10:47:12PM +0200, Julien Cubizolles wrote:
> Hi Ali (am I right in assuming that's your first name ?)
> 
> Suvayu Ali  writes:
> 
> > Here is an older version of the function:
> >
> >  (defun my-org-export-remove-tagged-headlines (tag)
> >(save-excursion
> >  (goto-char (point-min))
> >  (while (re-search-forward (concat ":" tag ":") nil t)
> >(delete-region (point-at-bol) (point-at-eol)
> >
> > Here I'm parsing the buffer in a pre-process hook.  In a filter, you
> > have to parse a string instead.  But the logic should be the same.
> 
> I'll try and adapt to make it work. I'll let you know how it goes.

Actually Rasmus shared his filter earlier today on the Emacs list.  Try
this:

(defun my-ignore-headline (contents backend info)
  "Ignore headlines with tag `ignoreheading'."
  (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
  (string-match "\\`.*ignoreheading.*\n"
(downcase headline)))
(replace-match "" nil nil headline)))

(add-to-list 'org-export-filter-headline-functions 'my-ignore-headline)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

[O] patch for latex->tikz

[Andreas Leha]

Hi all,

attached is a small patch that makes it possible to 'evaluate' latex
source blocks to tikz files.
When the :file header argument has a value ending in '.tikz' the content
of the body of the source block will be copied into the resulting tikz
file.
This makes handling of tikz figures with captions easier.

Here is a use-case:
--8<---cut here---start->8---
#+latex_header: \usepackage{tikz}

* Test

#+name: picturecontents
#+begin_src latex :noweb yes :exports none
 \node[red!50!black] (a) {A};
 \node (b) [right of=a] {B};
 \draw[->] (a) -- (b);
#+end_src

#+name: flowdiagram
#+header: :exports results
#+header: :imagemagick (if (and (boundp 'backend) (eq (org-export-backend-name 
backend) (intern "latex"))) "no" "yes")
#+header: :fit (if (and (boundp 'backend) (eq (org-export-backend-name backend) 
(intern "latex"))) "no" "yes")
#+header: :results raw :file (if (and (boundp 'backend) (eq 
(org-export-backend-name backend) (intern "latex"))) "flowdiagram.tikz" 
"flowdiagram.png")
#+header: :headers "\\usepackage{tikz}"
#+header: :noweb yes
#+begin_src latex
   \begin{tikzpicture}
 <>
   \end{tikzpicture}
#+end_src

#+caption: Testing figure caption for figure going to multiple destinations
#+results: flowdiagram
[[file:flowdiagram.png]]
--8<---cut here---end--->8---

This example works well besides some weird scaling/placement issue.


Regards,
Andreas


>From 1d9c381c309a3a72b5d9feb3db28cdaed920c16d Mon Sep 17 00:00:00 2001
From: Andreas Leha 
Date: Wed, 17 Jul 2013 16:45:32 +0200
Subject: [PATCH] add *.tikz files as possible result files for latex blocks

* lisp/ob-latex.el (org-babel-execute:latex) add a tizk option
  that copies the body of the block into a tikz file
---
 lisp/ob-latex.el |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index f916eb0..f9216e1 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -95,7 +95,11 @@ This function is called by `org-babel-execute-src-block'."
  ((and (string-match "\\.png$" out-file) (not imagemagick))
   (org-create-formula-image
body out-file org-format-latex-options in-buffer))
- ((or (string-match "\\.pdf$" out-file) imagemagick)
+ ((string-match "\\.tikz$" out-file)
+	  (when (file-exists-p out-file) (delete-file out-file))
+	  (with-temp-file out-file
+	(insert body)))
+	 ((or (string-match "\\.pdf$" out-file) imagemagick)
 	  (with-temp-file tex-file
 	(require 'ox-latex)
 	(insert
-- 
1.7.10.4

Re: [O] patch for latex->tikz

[Eric Schulte]

Andreas Leha  writes:

> Hi all,
>
> attached is a small patch that makes it possible to 'evaluate' latex
> source blocks to tikz files.

Applied, thanks.

> 
> When the :file header argument has a value ending in '.tikz' the
> content of the body of the source block will be copied into the
> resulting tikz file.  This makes handling of tikz figures with
> captions easier.
>
> Here is a use-case:
[...]
> This example works well besides some weird scaling/placement issue.
>

The best way I've found to deal with scaling/placement of raw or inline
tikz is to use the subcaption and adjustbox packages as in the following
example.

% latex
\begin{figure}
  \centering
  \begin{minipage}[b]{0.32\linewidth}
\adjustbox{width=1.0\linewidth}{
  \begin{tikzpicture}
% ...
  \end{tikzpicture}
}
\subcaption{\small part 1}
  \end{minipage}
  \begin{minipage}[b]{0.32\linewidth}
\adjustbox{width=1.0\linewidth}{
  \begin{tikzpicture}
% ...
  \end{tikzpicture}
}
\subcaption{\small part 2}
  \end{minipage}
  \begin{minipage}[b]{0.32\linewidth}
\adjustbox{width=1.0\linewidth}{
  \begin{tikzpicture}
% ...
  \end{tikzpicture}
}
\subcaption{\small part 3}
  \end{minipage}
  \caption{Example with three sub-parts}
  \label{fig:example}
\end{figure}

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Should comments break paragraphs?

[Andreas Leha]

Eric Schulte  writes:


[...]

>
> I'm happy to work to fix places where babel is breaking comments.
>

I guess this would be one of these cases:

--8<---cut here---start->8---
* Test

#+name: flowdiagram
#+header: :exports results
# #+header: :results raw
#+begin_src latex
  Hello World
#+end_src

#+results: flowdiagram
Hello World
--8<---cut here---end--->8---


[...]

Regards,
Andreas

Re: [O] import R data frame into org-mode table

[Andreas Leha]

Rob Stewart  writes:

> I have an R script that generates a data frame, that I export to a CSV
> file. The data looks something like this:
>
> "","Variant","Xaxis","N","mean","sd","se"
> "1","line1",10,5,111.11,9.33,3.11
> "1","line1",20,5,112.11,9.13,3.14
> "1","line1",30,5,113.11,9.43,3.10
> "1","line2",10,5,101.11,8.33,2.11
> "1","line2",20,5,100.11,8.13,2.12
> "1","line2",30,5,108.11,8.03,2.10
>
> I have an ongoing org-mode document in which I'd like to report this
> data. I'd like to add a table that looks something like this:
>
> | Variant | X Axis | Y Axis | N | Mean | Standard Deviation |
> Standard Error |
> 
> ||
>
> The data will change frequently over the coming months. I'd like
> org-mode to auto-magically read a CSV file, to construct my org-table
> on-the-fly. I'd hoping to avoid copying and pasting results each time.
>
> Is there some org-mode or emacs+ESS magic I can use to populate my
> empty table, with source data from my CSV file?
>
> --
> Rob

Definitely there is:

--8<---cut here---start->8---
#+begin_src R :results table :colnames yes
  read.csv('test.csv')
#+end_src

#+results:
| X | Variant | Xaxis | N |   mean |   sd |   se |
|---+-+---+---++--+--|
| 1 | line1   |10 | 5 | 111.11 | 9.33 | 3.11 |
| 1 | line1   |20 | 5 | 112.11 | 9.13 | 3.14 |
| 1 | line1   |30 | 5 | 113.11 | 9.43 |  3.1 |
| 1 | line2   |10 | 5 | 101.11 | 8.33 | 2.11 |
| 1 | line2   |20 | 5 | 100.11 | 8.13 | 2.12 |
| 1 | line2   |30 | 5 | 108.11 | 8.03 |  2.1 |

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

Regards,
Andreas

[O] Switch for exported file types when evaluating code blocks

[Brett Viren]

Hi,

I'm hitting on an old theme in a new way here.  

I want graphics files which are exported by evaluated code blocks to be
generated in a format best suited to their intended use.  For HTML I
want either PNG or SVG.  For LaTeX/PDF I almost always want PDF.  For
inline viewing in emacs I want either PNG or SVG.

To that end I went a'googling and found this idea:

  http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3

It doesn't work with my copies[1] of emacs and org-mode but I was able
to adapt it.  I suck at elisp so this is probably more an accomplishment
to me than it appears to most of you!

In any case, here is a short org document based on the one I found above
in worg which shows what I ended up with:


* COMMENT setup
#+begin_src emacs-lisp :results silent
  (defmacro by-backend (&rest body)
`(case (if (boundp 'backend) backend nil) ,@body))
#+end_src

* A graph
#+header: :file (by-backend (html "graph.png") (latex "graph.pdf") (t 
"graph.svg"))
#+header: :export results
#+begin_src dot
digraph Name {
tail -> head;
}
#+end_src


I think the real learning experience for me was that I could put lisp
directly in a header like this!  Now, I just gotta learn elisp
better

Also, I'd certainly be interested to hear of any better ways to
accomplish this.

Thanks,
-Brett.


[1] The versions I'm using are

 - Org-mode version 8.0.3 (8.0.3-elpa @ 
/home/bviren/.emacs.d/elpa/org-20130514/)

 - GNU Emacs 24.1.1 (i486-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-07-20 on 
murphy, modified by Debian


pgpOglEO1Y7O6.pgp
Description: PGP signature

Re: [O] Should comments break paragraphs?

[Eric Schulte]

Andreas Leha  writes:

> Eric Schulte  writes:
>
>
> [...]
>
>>
>> I'm happy to work to fix places where babel is breaking comments.
>>

I should add the conditional *if* we're going to improve comment support
globally (e.g., in the parser as well).  Else I am emphatically *not* up
for a host of new parsing edge cases. :)

Best,

>>
>
> I guess this would be one of these cases:
>
> --8<---cut here---start->8---
> * Test
>
> #+name: flowdiagram
> #+header: :exports results
> # #+header: :results raw
> #+begin_src latex
>   Hello World
> #+end_src
>
> #+results: flowdiagram
> Hello World
> --8<---cut here---end--->8---
>
>
> [...]
>
> Regards,
> Andreas
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] patch for latex->tikz

[Andreas Leha]

Hi Eric,

Eric Schulte  writes:

> Andreas Leha  writes:
>
>> Hi all,
>>
>> attached is a small patch that makes it possible to 'evaluate' latex
>> source blocks to tikz files.
>
> Applied, thanks.
>
>> 
>> When the :file header argument has a value ending in '.tikz' the
>> content of the body of the source block will be copied into the
>> resulting tikz file.  This makes handling of tikz figures with
>> captions easier.
>>
>> Here is a use-case:
> [...]
>> This example works well besides some weird scaling/placement issue.
>>
>
> The best way I've found to deal with scaling/placement of raw or inline
> tikz is to use the subcaption and adjustbox packages as in the following
> example.
>
> % latex
> \begin{figure}
>   \centering
>   \begin{minipage}[b]{0.32\linewidth}
> \adjustbox{width=1.0\linewidth}{
>   \begin{tikzpicture}
> % ...
>   \end{tikzpicture}
> }
> \subcaption{\small part 1}
>   \end{minipage}
>   \begin{minipage}[b]{0.32\linewidth}
> \adjustbox{width=1.0\linewidth}{
>   \begin{tikzpicture}
> % ...
>   \end{tikzpicture}
> }
> \subcaption{\small part 2}
>   \end{minipage}
>   \begin{minipage}[b]{0.32\linewidth}
> \adjustbox{width=1.0\linewidth}{
>   \begin{tikzpicture}
> % ...
>   \end{tikzpicture}
> }
> \subcaption{\small part 3}
>   \end{minipage}
>   \caption{Example with three sub-parts}
>   \label{fig:example}
> \end{figure}

thanks for the pointer.  I was not aware of the adjustbox package
before.  Definitely interesting.



Playing with it I found the flaw in my patch.  The inclusion of
[[foo.tikz]] is wrapped in \begin{tikzpicture} ... \end{tikzpicture}
already during LaTeX export.

So, exporting my example to latex gives a nested tikzpicture.  There is
nothing wrong with that, but the outer tikzpicture has these scaling
options, hence the wrong placement/scaling.

The code block that is going to tikz should, thus, *not* contain
the \begin{tikzpicture} and \end{tikzpicture} directives.

That might not render my patch completely useless, but limits its
use at least.

I was hoping for one and the same latex code block to be evaluated to
tikz/pdf/svg/imagemagick giving (more ore less) the same resulting image
in each.
In the moment that is not the case.

To clarify this:
--8<---cut here---start->8---
# can be evaluated to tikz (to export to latex)
#+begin_src latex
<>
#+end_src

# can be evaluated to pdf/svg/imagemagick
#+begin_src latex
  \begin{tikzpicture}
<>
  \end{tikzpicture}
#+end_src
--8<---cut here---end--->8---


Regards,
Andreas

Re: [O] Should comments break paragraphs?

[Andreas Leha]

Eric Schulte  writes:

> Andreas Leha  writes:
>
>> Eric Schulte  writes:
>>
>>
>> [...]
>>
>>>
>>> I'm happy to work to fix places where babel is breaking comments.
>>>
>
> I should add the conditional *if* we're going to improve comment support
> globally (e.g., in the parser as well).  Else I am emphatically *not* up
> for a host of new parsing edge cases. :)
>

That is how I read your offer.  Just to give an example that I stumbled
upon while experimenting with latex->tikz evaluation.

[...]

Regards,
Andreas

Re: [O] import R data frame into org-mode table

[Thomas S. Dye]

Rob Stewart  writes:

> I have an R script that generates a data frame, that I export to a CSV
> file. The data looks something like this:
>
> "","Variant","Xaxis","N","mean","sd","se"
> "1","line1",10,5,111.11,9.33,3.11
> "1","line1",20,5,112.11,9.13,3.14
> "1","line1",30,5,113.11,9.43,3.10
> "1","line2",10,5,101.11,8.33,2.11
> "1","line2",20,5,100.11,8.13,2.12
> "1","line2",30,5,108.11,8.03,2.10
>
> I have an ongoing org-mode document in which I'd like to report this
> data. I'd like to add a table that looks something like this:
>
> | Variant | X Axis | Y Axis | N | Mean | Standard Deviation |
> Standard Error |
> 
> ||
>
> The data will change frequently over the coming months. I'd like
> org-mode to auto-magically read a CSV file, to construct my org-table
> on-the-fly. I'd hoping to avoid copying and pasting results each time.
>
> Is there some org-mode or emacs+ESS magic I can use to populate my
> empty table, with source data from my CSV file?
>
> --
> Rob

Hi Rob,

Andreas' post answers your specific question.

In your situation, I typically don't run through a csv file, but just
write the R script so the data frame is returned to the Org mode buffer
as the result of the source code block.

As for the translation of column heads, see the ascii package for R,
which has a print() routine that recognizes Org mode as a type of
output, and which has facilities for formatting column names.

Here is an example from some work in progress that uses a session:

#+property: exports results
#+property: colnames yes
#+property: session *adzes*

#+name: lda-mid-z
#+header: :results output org
#+begin_src R 
  y <- edxrf[edxrf$lab=='UH-Hilo',]
  fit <- lda(as.factor(site) ~  rb_ppm + sr_ppm + y_ppm + zr_ppm + nb_ppm,
 data=y, na.action="na.omit", CV=TRUE)
  adzes <- y$site=='unknown'
  cap <- "Assignment of unknowns to sources"
  z <- 
ascii(cbind(BPBM=y$bpbm[adzes],round(fit$posterior[adzes,],2)),header=T,include.colnames=T,caption=cap)
  print(z,type="org")
  rm(y,fit,adzes,cap,z)
#+end_src

#+RESULTS: lda-mid-z
#+BEGIN_ORG
#+CAPTION: Assignment of unknowns to sources
| BPBM  | Haleakala | Kilauea | Mauna Kea | Nu`u | Pololu | 
Waiahole | unknown |
|---+---+-+---+--++--+-|
| 1985.134.01 adze  | 0 | 0.1 | 0 | 0| 0  | 
0.64 | 0.27|
| 50-HA-1349-G-5 adze   | 0 | 0.85| 0 | 0| 0  | 
0| 0.14|
| 50-HA-900-P24-1 microadze | 0 | 0   | 1 | 0| 0  | 
0| 0   |

...

hth,
Tom


-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Ido org-refile results in misfiling

[Samuel Wales]

I'd like to bump this bug as I have a minimal test case for it now.

Save the whole thing to one file, and the subtree labeled "test case"
to another file.

*** bad refile example 1 :refile:
* save test case to a file, and make it accessible to ido refiling
with flex matching
* don't save these instructions to the file because they will interfere :)
* refile this entry to the entry labeled 3 by typing 3
* now try to refile this entry to the entry labeled 2 by typing 2
* notice how the default provided is 3.  this is the bug.
it is of course ok that the default is 3 /before/ you
type 2.  that is not a bug.

the bug is that the default is 3 /after/ you type 2.
* test case
*** i want this 2:refile:
* i get this 3   :refile:

The bug is explained in more detail below.

Thanks.

Samuel

On 5/31/12, Samuel Wales  wrote:
> Ido and org-refile are a superb combination that enhances
> Org significantly.  It is a killer feature IMO.
>
> However, in my usage there is a substantial risk of
> misfiling:
>
>   1) If I start from a fresh Emacs, "myorg" is sufficient to
>  select "computer/emacs/org/myorg/".  This is good.
>
>   2) If I refile something to
>  "computer/emacs/org/myorg/strategy and examples/various
>  todo kw and maybe some tags/", "various" is enough to
>  select it.  Note that this is below "myorg".  Also good.
>
>   3) (Just as an aside, if I then refile something else to
>  the same entry, I don't even need to enter "various".
>  It is the default.  A nice feature.)
>
>   4) Now suppose I want to refile something to "myorg".  I
>  enter "myorg" but I get "various".
>
> Detail on this subtle issue is below:
>
> ===
>
> My expectation is that if "myorg" selects "myorg" once, it
> should always do so no matter what my refile history is.
> This expectation is violated.
>
> It violates a sort of referential transparency.  The same
> narrowing inputs should produce the same narrowed outputs
> (in my expectation at least).
>
> I suspect that the reason for the unexpected behavior is related (in
> some way) to
> the defaulting in 3, which is useful.  However, the false defaulting in 4
> is
> NOT useful in any obvious way.
>
> ===
>
> Proposed solution:
>
> I think that as soon as the user starts selecting something,
> the default should be discarded.
>
> ===
>
> With my expectation, it is never necessary to check the
> offered olpaths except as a confirmation.
>
> With the current behavior, checking is always necessary
> because in edge cases, there will be a guaranteed misfile.
>
> Here is why: the only reason that default showed up at all
> is that the narrowing input /happened/ to match both
> headlines.  Otherwise the default would have been discarded.
> So it is an edge case that allowed the offer to misfile.  In
> other cases, the correct default would be provided.  If I
> wanted "various", RET would be sufficient.
>
> User checking is significantly more error-prone because one
> olpath is a substring of the other.
>
> Likewise, the requirement to navigate in the list is
> burdensome as 4 is never useful as far as I can tell.
>
> ===
>
> Is there any way to fix this?  I tried looking at ido
> customizations and got lost.
>
> If you can't reproduce witn your ido settings, I'll try to
> provide an MCE at some point.  Might take a while though.
>
> Thanks.
>
> Samuel
>
> --
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
>


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

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

Denmark: free Karina Hansen NOW.

Re: [O] Switch for exported file types when evaluating code blocks

[Cook, Malcolm]

>I want graphics files which are exported by evaluated code blocks to be
 >generated in a format best suited to their intended use.  For HTML I
 >want either PNG or SVG.  For LaTeX/PDF I almost always want PDF.  For
 >inline viewing in emacs I want either PNG or SVG.
 >
 >To that end I went a'googling and found this idea:
 >
 >  
 > http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3
 >
 >It doesn't work with my copies[1] of emacs and org-mode but I was able
 >to adapt it.  I suck at elisp so this is probably more an accomplishment
 >to me than it appears to most of you!
 >
 >In any case, here is a short org document based on the one I found above
 >in worg which shows what I ended up with:
 >
 >
 >* COMMENT setup
 >#+begin_src emacs-lisp :results silent
 >  (defmacro by-backend (&rest body)
 >`(case (if (boundp 'backend) backend nil) ,@body))
 >#+end_src
 >
 >* A graph
 >#+header: :file (by-backend (html "graph.png") (latex "graph.pdf") (t 
 >"graph.svg"))
 >#+header: :export results
 >#+begin_src dot
 >digraph Name {
 >tail -> head;
 >}
 >#+end_src
[Cook, Malcolm] 

Brett,

Thanks for posting your findings.  They almost help me.

I am looking for a solution to a similar problem.

I tend to work with org-export-babel-evaluate set to nil.  Thus, my code blocks 
are not evaled in the context of an export.  Thus at eval time there is no way 
of knowing what the eventual backend is going to be.

I think I need an approach that auto converts svg to png on-demand/on-the-fly 
during export.

Has anyone come across a variation on this that works as I am suggesting?

Thanks!

Re: [O] Use babel to import table data from OpenDocument spreadsheets?

[James Harkins]

At Wed, 10 Jul 2013 09:20:25 +0530,
Jambunathan K wrote:
> James Harkins  writes:
> 
> > I found a utility, unoconv[1], which I can persuade to produce a
> > tab-separated export of the first worksheet of an ODS document.
> 
> FYI, unoconv is an option provided by `org-odt-convert-processes'.

Thanks.

Okay... I finally had some time to come back to this task.

While I do appreciate all the suggestions so far, unfortunately I have to admit 
that I'm still stuck. What I'd like to do now is run down what I know about it 
so far and put questions in the middle of that.

1. I have a LibreOffice ODS file, where the table to obtain will be in the 
first worksheet.

1a. I can use unoconv to get a tab-separated text table out of it, in a file on 
disk.

1b. I will need to invoke this synchronously in an emacs-lisp block. 
(shell-command ...) I guess, right?


2. I want the tab-separated text to be converted into an org-table, so that 
HTML export will turn it into an HTML table. This is where it becomes 
completely baffling to the novice.

2a. There's a function, org-table-import, which looks like it will do the job. 
It inserts the table contents at the point. I just can't find any examples 
online of the correct way to do this. I assume I will have to run an emacs-lisp 
source block. I had been thinking I could use ":exports results" with a #+call, 
supposing that I could write out the table text as a stream and those results 
would be put in place of the #+call in the export. But of course that doesn't 
make sense if org-table-import is significant for its side effect (modifying 
the buffer) rather than its result.

2b. So (I guess) I would have to use emacs-lisp to move the point to a specific 
location in the file before calling org-table-import (obviously not by 
character index, since I can't assume previous text will not change).

QUESTION: What is the best way to do that?

^^ This is the point where I'm stuck. I really have no idea. Say I put in an 
org comment "# raw data here" -- how do I get the point to go to the line after 
that? How do I delete the entire old table before importing the new one? 
Working example, perhaps?


Anyway, I'll be happy to write this up as a worg page after I get it working, 
as it seems to me this would be a fairly common need but the information is not 
easy to find.

Thanks,
hjh

Re: [O] Hiding cells in org table

[John Rakestraw]

Hi, David --

On 17.07.2013 14:02, da...@adboyd.com wrote:

I've scanned through the manuals, and see no way to do this, but.

Is there anyway to block out the contents of a result field in a 
table, until

I export it into an html file?

I'm keeping track of my hours worked, with the dollar amounts paid 
calculated,
and I don't want anyone wandering by my desk to be able to see how 
much I am

being paid.

Then I want the amount to show in the .html file that I export to 
have signed

off on.


I can't tell you how to hide the contents of a field, but this might 
serve your purpose, assuming that you're paid a regular hourly wage. How 
about setting a constant (see http://orgmode.org/org.html#References and 
search for "Named References")? You can do this in a property in the 
table. Have a column formula that multiplies the number of hours worked 
times the constant.


For day-to-day purposes, you'd define the constant as "0" or "1". When 
it's time to export and print your html file, change the constant to 
your actual hourly rate and recalculate.


--
John Rakestraw

Re: [O] Switch for exported file types when evaluating code blocks

[Suvayu Ali]

Hello again Malcolm,

On Thu, Jul 18, 2013 at 12:45:36AM +, Cook, Malcolm wrote:
> 
> I tend to work with org-export-babel-evaluate set to nil.  Thus, my code 
> blocks are not evaled in the context of an export.  Thus at eval time there 
> is no way of knowing what the eventual backend is going to be.
> 
> I think I need an approach that auto converts svg to png on-demand/on-the-fly 
> during export.

In that case just use another source block with shell source.  In that
block you can call inkscape to do the conversion.  For an example, see
here:


Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

[O] how to handle svg files when exporting orgmode to html and pdf?

[malcolm cook]

Hi, 

I am creating .svg files with R source blocks and ESS in org. 

I am happily viewing them in-line in my emacs buffer. 

I am happily exporting as html and viewing them in-line in the resulting web 
page, including a table of images. 

I do not have an approach for including them into PDF when I export-tex-pdf. 

I'm thinking there might be an approach to converting them on-the-fly to png 
(or something) during the export->tex->pdf. 

A similar problem was addressed with custom macros here: 
http://thread.gmane.org/gmane.emacs.orgmode/56532/focus=58322 

But it does not work with  R source blocks that produce .svg files. 

Any suggestions for me?  Is this a lost cause?  Am I asking for too many 
assumptions to be made by such an auto-conversion process that it is doomed 
to fail anyway? 

Thanks for your thoughts and help! 

Malcolm 

Re: [O] Switch for exported file types when evaluating code blocks

[Nick Dokos]

Suvayu Ali  writes:

> Hello again Malcolm,
>
> On Thu, Jul 18, 2013 at 12:45:36AM +, Cook, Malcolm wrote:
>> 
>> I tend to work with org-export-babel-evaluate set to nil.  Thus, my
>> code blocks are not evaled in the context of an export.  Thus at
>> eval time there is no way of knowing what the eventual backend is
>> going to be.
>> 
>> I think I need an approach that auto converts svg to png 
>> on-demand/on-the-fly during export.
>
> In that case just use another source block with shell source.  In that
> block you can call inkscape to do the conversion.  For an example, see
> here:
> 
>

OT for the OP (say that three times fast!) but maybe of some use to somebody:

For SVG, there is a latex package that is an evolutionary offshoot of
the above link. It does the inkscape dance so you don't have to:

   http://www.tex.ac.uk/ctan/graphics/svg/

-- 
Nick