Hi Seb,
I'm not quite sure why the commands are not echoed and someone else
can probably explain this.
But for what it's worth, using a header argument ":results output"
shows the command plus their output in the *R* buffer.
Cheers,
Andreas
I'm using archlinux which is a rolling distribution so have this version
of emacs on my machine. I did not experience this bug with org-mode until
after installing eww which was not part of emacs 24.550.1 installed on
archlinux. I ran into it opening an org-mode table, but if I open a bash
sh
The eww branch put no code on my machine the second time I ran it. I made
the mistake of not configuring bzr oritinally and bzr put everything into
a ~/trunk subdirectory. After configuring bzr by making a repository for
it according to the article on archwiki for bzr, the bzr command appeared
Do org-odt-styles-dir and org-odt-schema-dir now point to the correct
directory?
If not, did you try putting
(setq org-odt-data-dir "/usr/share/emacs/24.3/etc/org")
in your .emacs and restarting?
Those variables are set on startup based on the contents of
org-odt-data-dir, and not immediatel
On 2014-08-28 18:03, Subhan Michael Tindall wrote:
> Try
> (setq org-clock-history-length )
> In your .emacs
Thank you very much, that's great! I had no idea, because …
* the documentation of org-clock-goto and org-clock-in (which display
the history given universal-argument) didn't refer to t
that is odd. this means org-ref is not finding the key you clicked
on. could you send me a small example that reproduces your problem (an
org-file and the bib file)?
"Julian M. Burgos" writes:
> Hi John,
>
> No, they still do not work even after I click on the bibliography link
> and get my .bi
Hi all,
I am using org-mode in a class, and some students wondered if it was
possible for there to be a progress bar of some kind while a code block
is running. Right now Emacs just appears to lock up and there is no
indication anything is happening, especially the first time we run a
python block.
My latest clocktables have started to stumble on the formatting of subheadings;
some of the leading "*" of the items seem to be making it into the table as
"\emsp". What's the problem?
Example:
#+BEGIN: clocktable :maxlevel 4 :scope subtree
#+CAPTION: Clock summary at [2014-08-30 Sat 10:58]
|
Hello,
I would like to assign a relative column formular for the 6 column (name
= BIPr).
The formular should start in the *second field* of column 3 (value = 12)
and multiply it with *first value of column* 4 (value = 2.8) etc. like this:
12 * 2.8
4 * 0.7
...
|---+--+---+---+--
Hi,
I had the same problem, and I could solve it by removing an org installation in
.emacs.d/elpa.
(My regular org installation is a git sandbox).
Regards,
Dieter
On 30. August 2014 17:00:39 MESZ, torys.ander...@gmail.com wrote:
>My latest clocktables have started to stumble on the formatting of
Hi Org users,
I wrote a Babel block to generate the #+INCLUDE statements
for all Org files of a directory.
Nothing spectacular: not recursive through directories,
only .org files ... but I wanted to share it, just in case
someone finds it helpful. Source code and usage example
are available h
May you please discuss your use case that motivated this code?
Grant Rettke | ACM, ASA, FSF
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it
Hmm... I use the elpa as my main install, and maintain orgmode through those
updates. Any other solutions, or idea why that fixed it?
- Tory
Date: Sat, 30 Aug 2014 17:36:24 +0200
From: Dieter Sch?n
To: orgmode list
Subject: Re: [O] Latest clocktable mis-formats headings
Message-ID:
Content-T
My elpa orgmode is running Org-mode version 8.2.7c, btw. Do others have this
(possibly elpa-specific) problem?
> Date: Sat, 30 Aug 2014 17:36:24 +0200
> From: Dieter Sch?n
> To: orgmode list
> Subject: Re: [O] Latest clocktable mis-formats headings
> Message-ID:
> Content-Type: text/plain; ch
Hello list,
I want to ask for help regarding elisp and org-elements. I like to
access the properties of all my headlines and I created the following
function (tree is the parsed tree) that collects them into an a-list:
#+begin_src emacs-lisp
(defun collect-props (tree)
(car (org-element-ma
Hello all,
I'm playing with the functions in org-elements.el and the following
effect seems strange to me:
I have a few propery drawers with empty propertys, like
#+BEGIN_EXAMPLE
:PROPERTIES:
:date: [2014-08-29 Fr]
:chf: 21.76
:eur:
:END:
#+END_EXAMPLE
If I do org-elements-parse-buffe
Hi Seb,
2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen:
[...]
> Does it have something to do with `ess-eval-visibly' not being respected
> (whose default is `t')?
Indeed, babel’s R support let-binds this variable to nil when evaluating
value-type results in a session.
--
Aaron Ecay
Hi Nicolas,
2014ko abuztuak 28an, Nicolas Goaziou-ek idatzi zuen:
[...]
>
> Nevertheless, I think we should take a radical different approach, as
> discussed recently with Bastien, which is to enforce property drawers to
> start on the line right after the headline and maybe the planning info,
Hi Seb,
2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen:
> I think it's related to an Emacs bug (#16440) which I reported on the
> Org mailing list in February.
I don’t completely understand what is going on in that bug report. My
proposal is to convert org-copy-face to defface. I can’t t
forgot to mention org version:
Org-mode version 8.3beta (release_8.3beta-296-g851b77 @
/home/eike/.emacs.d/src/org-mode/lisp/)
Kind regards,
Eike
Eike writes:
> Hello all,
>
> I'm playing with the functions in org-elements.el and the following
> effect seems strange to me:
>
> I have a few prop
Hello again
it seems that I messed up my testing variables… I always had just one
headline and thus the list of lists had always one element that I then
extracted with `car'. So `car' must be removed:
#+begin_src emacs-lisp
(defun collect-props (tree)
(org-element-map tree 'headline
I did that. But got the same message.
Should I have anything except:
> ls
OrgOdtContentTemplate.xml OrgOdtStyles.xml README
in that directory?
Thank you.
Eike writes:
Hello,
> I want to ask for help regarding elisp and org-elements. I like to
> access the properties of all my headlines and I created the following
> function (tree is the parsed tree) that collects them into an a-list:
>
> #+begin_src emacs-lisp
> (defun collect-props (tree)
>
Eike writes:
> Hello all,
>
> I'm playing with the functions in org-elements.el and the following
> effect seems strange to me:
>
> I have a few propery drawers with empty propertys, like
>
> #+BEGIN_EXAMPLE
> :PROPERTIES:
> :date: [2014-08-29 Fr]
> :chf: 21.76
> :eur:
> :END:
> #+END_EX
I found the problem and have changed it as per below. The \emsp is being
interpreted literally. I just changed mine back to underscores.
>From org-clock.el:
(defun org-clocktable-indent-string (level)
(if (= level 1) ""
(let ((str " "))
(dotimes (k (1- level) str)
;; (setq str
Hello,
Grant Rettke writes:
> May you please discuss your use case that motivated this code?
typical usage scenarios could be:
1) write a book of many chapters, one main.org file
and many second-level .org files, one file per chapter,
and you don't want to manually write all the #
Thanks a lot for the examples, they are very helpful! I first thought to
parse the org buffer and then work with the resulting tree. But your
examples now makes me think to work directly on the buffer. Well, I will
play with a few different ways now…
Regards
Eike
Thorsten Jolitz writes:
> Eike
Hello,
Let's say I have this:
*** TODO Org tidy-up
SCHEDULED: <2014-08-22 Fri .+1d/2d>
:LOGBOOK:...
:PROPERTIES:...
Now, in my relatively default configuration "Org tidy-up" is the same
face as everything that appears after it.
Is there any way to make the SCHEDULED, LOGBOOK, and PROPERTIES bit
Andrea Rossetti writes:
> my_reference_manual.org
> abs.org
> ...
> printf.org
> strcpy.org
sorry for the typo, I meant:
my_c_manual.org
abs.org
...
printf.org
strcpy.org
Eike writes:
> Thanks a lot for the examples, they are very helpful! I first thought to
> parse the org buffer and then work with the resulting tree.
Thats the obvious thing to do in this case, and you can do everything
you want this way, but there are some alternatives too.
> But your exampl
How are *you* realizing traceability from your org documents to their
tangled and weaved destination?
I was thinking of using UUIDs or git hashes for commits, and wanted to
know what others have done.
Grant Rettke | ACM, ASA, FSF
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom
John, for some weird reason everything seems to be working now. Thanks
for your help... I will let you know if I break it again.
John Kitchin writes:
> that is odd. this means org-ref is not finding the key you clicked
> on. could you send me a small example that reproduces your problem (an
> or
I would have expected
[[latex:textsc][some text]]
to become
\textsc{some text}
Instead, it becomes
\texttt{some text}
My hackish fix is to modify a variable,
(setq org-latex-link-with-unknown-path-format "\\textsc{%s}")
Is there a better way?
Brady
Org-mode version 8.2.
Eike writes:
> Hello list,
>
> I want to ask for help regarding elisp and org-elements. I like to
> access the properties of all my headlines and I created the following
> function (tree is the parsed tree) that collects them into an a-list:
You could also take a look at org-collector, in contri
Nick, your code worked! My example image was small and I could change
the size by altering the width variable. The same image in a regular org
file is huge.
That means something is wrong with my org-mode install? I have not
changed or done anything to org-mode that came with the compiled emacs
35 matches
Mail list logo
