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
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
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 goin
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 amoun
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'.
Than
>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'googl
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 re
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,
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
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 t
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 ne
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 ei
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,
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
#+begi
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
> resul
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 c
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-c
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
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?
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
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 de
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.
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)
(dele
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 a
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 :va
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
| OVER
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 expor
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 agre
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 t
>
> 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
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
Hi Jisang,
what version of Emacs and Org-mode are you using?
Thanks!
--
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,
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.
>
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 th
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
+-+
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-pr
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 th
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 t
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 sub
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
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 del
42 matches
Mail list logo
