Thanks, everyone. I thought I /had/ tried that. Feeling silly...thanks
for the help.
- DJ -
On 15-04-29 10:59 PM, DJ wrote:
Can't figure this out from the org mode manual.
I want to use org mode for doing math assignments. This will be a lot
easier than using latex directly, I think. But, I
OMG (facepalm). I *thought* I had already tried that, since it's the
obvious thing to do.
Thanks for your help.
On 15-04-30 02:32 AM, thomas wrote:
indenting the table should do the trick:
===
1. blah blah
yatta yatta
| m | n | foo |
|---+---+-|
| x | y | z |
> From: m...@nicolasgoaziou.fr
>
> Actually, this is now possible in development version. Truth is no match
> against Time.
>
Indeed! Thank you so much for letting me know (I just saw your reply). In fact
I'm using the dev version and it seems to be working well. Thank you.
-Joon
Hello,
Richard Stanton wrote:
> I just ran git pull to update to the latest version of org-mode. Now, when I
> try to save an org file, I get the error message:
>
> user-error: Not in a sub-editing buffer
I think this issue is already being discussed in another thread:
http://thread.gmane.org/g
I just ran git pull to update to the latest version of org-mode. Now, when I
try to save an org file, I get the error message:
user-error: Not in a sub-editing buffer
Leo Ufimtsev writes:
> Worf I think is a bit on the vi side of things. Helm is more generic.
Worf is as much on the vi side of things, as `org-use-speed-commands'
are. Almost not at all. It just takes vi-style "hjkl" arrows, because
Emacs-style "bnpf" arrows aren't convenient.
And it's got the
There are some build in things also,
E.g you can name source code blocks:
#+name: EDE Config
#+begin_src emacs-lisp
(require 'ede)
(global-ede-mode)
(load-file (concat user-emacs-directory "my/cedet-projects.el"))
#+end_src
And then with Helm + org-babel-goto-named-src-block you can search your
Hi Nicolas, org-mode users and -developers,
I was too much in a hurry...
This bug still exists as of now:
* Gregor Zattler [30. Apr. 2015]:
> * Gregor Zattler [30. Apr. 2015]:
> > * Nicolas Richard [30. Apr. 2015]:
> > > I think this specific bug was fixed in :
> > > Commit ea575950d957fcecc
Hi Marco,
Here is a fairly minimal example to get you started:
Begin Example
#+PROPERTY: header-args:R :session *R* :results output drawer :exports both
#+BEGIN_SRC R
library(ascii)
options(asciiType="org")
#+END_SRC
#+BEGIN_SRC R
ascii(mtcars[1:5, 1:5])
#+END_SRC
#+BEGIN_SRC
Jacob Gerlach writes:
> --
> #+OPTIONS: ':t
> \begin{myenvironment}
> "Foo"
> \end{myenvironment}
> --
> Exports "Foo" rather than ``foo''. Is this expected?
Yes, 'cause it's a latex-environment (try running org-element-at-p
Hello,
--
#+OPTIONS: ':t
\begin{myenvironment}
"Foo"
\end{myenvironment}
--
Exports "Foo" rather than ``foo''. Is this expected?
I tried this instead:
--
#+Latex:\begin{myenvironment}
"Foo"
Rasmus writes:
> Hi,
>
> Eric Abrahamsen writes:
>
>> We're just talking about annotations-plus-metadata here, right? Not
>> actual in-text TODOs?
>
> I don't know.
>
>> From what I can tell, rasmus seems to be proposing an in-text TODO,
>
> I mainly extrapolated from your example. Further, I e
Am Thu, 30 Apr 2015 11:59:32 +0200
schrieb Bastien :
> There was a hidden clue the commit could be problematic...
>
> Gregor Zattler writes:
>
> > First bad commit is:
> > bad0409c3b86e09c4559e97d5f394356c6ccbe7f
> ^^^
That must be a first look at the singularity.
"The git" knows it all.
I
Hi Nicolas,,
* Gregor Zattler [30. Apr. 2015]:
> * Nicolas Richard [30. Apr. 2015]:
> > I think this specific bug was fixed in :
> > Commit ea575950d957fcecc74ed6f53c29bb6b77e9fe26
>
> Sorry, no:
> with:
> GNU Emacs 25.0.50.6 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of
> 2015-04-27 on boo Org-m
Hi Nicolas,
* Nicolas Richard [30. Apr. 2015]:
> Gregor Zattler writes:
> > Sorry, no:
>
> From Bastien's comment, I wonder : does the following patch helps ?
Yes, but see my other email: The fix in
ea575950d957fcecc74ed6f53c29bb6b77e9fe26 works.
Thanks, grgeor
Gregor Zattler writes:
> Sorry, no:
>From Bastien's comment, I wonder : does the following patch helps ?
--- /dev/fd/63 2015-04-30 13:44:20.900676564 +0200
+++ /tmp/org-src.el 2015-04-30 13:43:50.924673810 +0200
@@ -539,35 +539,36 @@
- When formatting a source code snippet for export with
Dear org-mode community,
First, I want to apologize for subscribing mainly because I need help.
I recently started using org-mode as a tool for reproducible research
(trying to do R-based literate programming).
What I'm trying to is explained in this example file:
http://orgmode.org/worg/org-co
On Thursday, 30 Apr 2015 at 11:58, Rasmus wrote:
[...]
>> I've definitely wanted some sort of a track changes equivalent in Org,
>> but we'd want to be careful about this.
>
> Isn't this the job of VC? I'm not sure how we can concisely represent all
> the needed metadata? Something like
I'm 10
On 2015-04-29 17:05, Nicolas Goaziou writes:
> Hello,
>
> Alan Schmitt writes:
>
>> Does this mean that #+INCLUDE is now a superset of #+SETUPFILE (I've had
>> some cases where I needed to do both)?
>
> No, it isn't.
>
> INCLUDE are expanded only during export. SETUPFILE are read whenever you
>
Hi Nicolas,
* Nicolas Richard [30. Apr. 2015]:
> Gregor Zattler writes:
> > First bad commit is:
> > bad0409c3b86e09c4559e97d5f394356c6ccbe7f
>
> Nice hash for a "bad" commit :)
I didn't realise :-)
> > This results in a startup error:
> > Debugger entered--Lisp error: (void-variable write-
Hi Detlef,
Detlef Steuer writes:
> Whatever file I open, I can´t save it with C-c C-s and get the message
> "not in sub-editing buffer"
Noticed this too. You need to deactivate org-src-mode manually.
For whatever reason, org-src-mode gets wrongly activated at startup.
Gregor Zattler writes:
> First bad commit is:
> bad0409c3b86e09c4559e97d5f394356c6ccbe7f
Nice hash for a "bad" commit :)
> This results in a startup error:
> Debugger entered--Lisp error: (void-variable write-back)
Is it related to your initial problem ?
I think this specific bug was fixed
Hi,
Eric Abrahamsen writes:
> We're just talking about annotations-plus-metadata here, right? Not
> actual in-text TODOs?
I don't know.
> From what I can tell, rasmus seems to be proposing an in-text TODO,
I mainly extrapolated from your example. Further, I extrapolated from the
notion of or
There was a hidden clue the commit could be problematic...
Gregor Zattler writes:
> First bad commit is:
> bad0409c3b86e09c4559e97d5f394356c6ccbe7f
^^^
!
Hi Daniel, Detlef,
* Detlef Steuer [30. Apr. 2015]:
> Hi!
>
> On of yesterday's commits introduces an error:
>
> Whatever file I open, I can´t save it with C-c C-s and get the message
> "not in sub-editing buffer"
>
> I verified org is the culprit using emacs -Q and only loading org.
>
> I can
Hi Matt,
Matt Price writes:
> Is this possible? Anyone have a suggestion?
It is not possible in Org since one of the basic assumptions of the
UNNUMBERED property is that it is inherited from parent(s). I think this
is the right design choice in most cases. Perhaps it should be possible
to exp
Hi!
On of yesterday's commits introduces an error:
Whatever file I open, I can´t save it with C-c C-s and get the message
"not in sub-editing buffer"
I verified org is the culprit using emacs -Q and only loading org.
I can save without/before loading org.
Regards
Detlef
You can do the opposite and number only the topmost headings, e.g. with
#+OPTIONS: num:1
but I don't think Org has a way to number only sub-headings. In HTML
export, you can get there with CSS hacks. For the exact example you
gave,
#+HTML_HEAD: .section-number-2 {display: none;}
should hide h
28 matches
Mail list logo
