Re: [O] Continuing a numbered list
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 want to use numbered lists in org mode, and often there are multiple paragraphs that belong under one list item. I want to be able to use org mode tables instead of latex tabular, and these tables sometimes appear in the middle of a bunch of paragraphs under a single list item. I know how to get multiple paragraphs in one numbered list item. But how can I stick a table in the middle of my multiple-paragraph list item without terminating the list? Such as: 1. blah blah\\ yatta yatta | m | n | foo | |---+---+-| | x | y | z | and this text should be part of item 1. That is the real problem - a paragraph AFTER the table which should belong to item 1. 2. This is the next item. I could use a cookie here to force start at 2, I know. TIA. Best, Jake.
Re: [O] Continuing a numbered list
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 | and this text should be part of item 1. That is the real problem - a paragraph AFTER the table which should belong to item 1. 2. This is the next item. I could use a cookie here to force start at 2, I know. === - thomas On 30.04.2015 04:59, DJ wrote: 1. blah blah\\ yatta yatta | m | n | foo | |---+---+-| | x | y | z | and this text should be part of item 1. That is the real problem - a paragraph AFTER the table which should belong to item 1. 2. This is the next item. I could use a cookie here to force start at 2, I know.
Re: [O] Using macros in properties
> 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
Re: [O] Can't save file with latest version of org
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/gmane.emacs.orgmode/97349 -- Kyle
[O] Can't save file with latest version of org
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
Re: [O] navigate between source code blocks
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 best Helm implementation for navigating to headings. I've just added named blocks to this list as well. Screenshot: http://oremacs.com/download/worf-goto.png. The command to call is "M-x" `worf-goto' or "g" while in `worf-mode'. Oleh
Re: [O] navigate between source code blocks
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 named source code blocks. You can also go to the next source code block via org-babel-next-src-block etc. Just to hop around. There is also a command for marking blocks. Worf I think is a bit on the vi side of things. Helm is more generic. I usually do things like append 'src' to the title of a heading and then do a helm-heading search to find my source code. Leo Ufimtsev | Intern Software Engineer @ Eclipse Team - Original Message - From: "Zhihao Ding" To: "Oleh Krehel" Cc: emacs-orgmode@gnu.org Sent: Wednesday, April 29, 2015 4:20:06 AM Subject: Re: [O] navigate between source code blocks Thanks very much Oleh. Best, Zhihao > On 28 Apr 2015, at 08:22, Oleh Krehel wrote: > > Hi Zhihao, > >> I’ve got a simple question: how to speed up jumping >> between code blocks? > > You might be interested in https://github.com/abo-abo/worf. > It allows you to traverse anything that starts with "*" or "#+" with > just "hjkl" keys. > See the docs here: http://oremacs.com/worf/README.html. > > regards, > Oleh
[O] now it get's ridiculous: bug is still there (was: Re: wrong test, fix works, sorry (was: Re: bisected))
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 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-mode version 8.3beta (release_8.3beta-1097-gea5759 @ > > /home/grfz/src/org-mode/lisp/) > > > > and emacs invoked with -Q I cannot save a modified file with ^x ^s > > but when I leave emacs: this is still the case with commit ea575950d957fcecc74ed6f53c29bb6b77e9fe26 my mistake was: > > receipt: > > emacs -Q -nw /tmp/tempfile > > > > change buffer, do ^x ^s. not to load the freshly build org-mode. With this invocation: emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ --debug-init --eval "(require 'org)" /tmp/testfile change the buffer, try to save it, see: "user-error: Not in a sub-editing buffer" This ist the case with: - GNU Emacs 25.0.50.6 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of - Emacs24 as of Debian Jessie it's the caese with org-mode commits up to: - 14f5b132184ac9c0492d8cc94345413b85ef3f55 - ea575950d957fcecc74ed6f53c29bb6b77e9fe26 it's not the case with org- mode commits up to: - 86dcd907719c97530a266686694a7dc7bd25449a - 14f5b132184ac9c0492d8cc94345413b85ef3f55 and patch from Nicolas email Message-ID: <87oam56dow@yahoo.fr> appplied. But then I get "defvar: Symbol's value as variable is void: org-src-mode" at startup. This time I got it right, I hope. Bye, Gregor
Re: [O] org-babel R ascii results: unable to export table
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 R ascii(summary(lm(hp ~ wt, data = mtcars))) #+END_SRC ### End Example First execute the code blocks with 'M-x org-babel-execute-buffer' then export. For more control I would refer to the manual section at http://orgmode.org/manual/Working-With-Source-Code.html#Working-With-Source-Code Best, Ista On Thu, Apr 30, 2015 at 7:32 AM, Marco Barbàra wrote: > 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-contrib/babel/examples/ascii.org > which I downloaded trying to understand how to export R output produced > with the R 'ascii' package. > > Running this example, after adding ":exports results" to > "ascii-example3" block, _on the first attempt_, the output was exported > as an odt table (i was happy, this is my desired outcome). But > afterwards, any subsequent attempts to export the same block resulted in > a "verbatim" block, which is the same problem I was trying to solve. > > I tried to export as a latex buffer too, and even there i got a verbatim > environment. > > I don't think it is bug, it is probably that I still don't understand > org-babel well. > > Sorry not to provide any other sample code, but I wouldn't know where > to begin. > > Any advice would be very appreciated. > > Thank you very much > > Marco Barbara > > >
Re: [O] [Bug?] Smart quotes and latex environments
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-point on
it). You could do
#+begin_myenvironment
"Foo"
#+end_myenvironment
—Rasmus
--
Hvor meget poesi tror De kommer ud af et glas isvand?
[O] [Bug?] Smart quotes and latex environments
Hello,
--
#+OPTIONS: ':t
\begin{myenvironment}
"Foo"
\end{myenvironment}
--
Exports "Foo" rather than ``foo''. Is this expected?
I tried this instead:
--
#+Latex:\begin{myenvironment}
"Foo"
#+Latex:\end{myenvironment}
--
which exports to:
--
\begin{myenvironment}
``Foo''
\#+Latex:\end{myenvironment}
--
This seems like a bug.
Mixing the two:
--
#+Latex:\begin{myenvironment}
"Foo"
\end{myenvironment}
--
gives the desired result:
--
\begin{myenvironment}
``Foo''
\end{myenvironment}
--
but this seems like a hack.
Regards,
Jake
Re: [O] Marking/highlighting text temporarily
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 extrapolated from the > notion of org-inlinetasks.el. Since we have one we should try to minimize > the distance whilst still keeping syntax as simple as possible, > e.g. [comment:] or [TODO-TAG:] (I don't know what the "@" operator meant > in your previous example). > >> 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 VC does not do this well for written text. Most VC were designed for code, and are line oriented. In written text, you can have an entire paragraph on a single line, and most VC do not show changes by sentence, for example. There are some ways to get different kinds of diffs, but none of them work well in my opinion. Students "get" track changes, and for collaborative editing of text, it is pretty great. > > [comment: txt :annotation annot :author a :date d :other-properties p] > > is not "accessible" for non-Emacs users of the Org format. > >> 1. Annotations attached to arbitrary text in the buffer. The buffer text >>should be visible, the annotation data invisible (basically the way >>links work right now). > > This is a fortification/overlay issue. And I disagree strongly on having > invisible parts. > >> 2. Plain annotation: just a chunk of free-form paragraph text that is >>attached to the buffer text. > > What do you concretely have in mind here? Can't this be done with an > inlinetask at the beginning of the file? Or a noexport heading? inlinetasks do not have the same semantic meaning as comments and annotations. They can serve a purpose similar to this, I agree. but, it doesn't make sense to me to consider having an annotation type for inline comments, and a separate type for this plain annotation. How would you differentiate a real task from a plain annotation? > >> 3. Replacement text: an alternate version of the buffer text; this could >>be the basis of track changes stuff. > > Is this not the job of VC? No. VC has a role in it, but current tools do not do this well enough to be solutions. > >> 4. Timestamps > > This seems like the job of e.g. vc-annotate.el, no? > >> 7. "Author" metadata would probably be unnecessary with full access to >>the export channels, but it might still be desirable. > > What John was talking about was for collaboration. When you export John's > notes on your machine how can it know it's from John if not set > explicitly? In any case, I think it could be too verbose. Sidenote: In > collaborated papers I simply use prefix "R:" and "K:" in inlinetasks. > >> That's all I can think of, just trying to get the ball rolling. I don't >> have any opinions about actual syntax, though something with curly >> braces might be nice. > > Nothing with curly braces is nice :) > > I think I have something much less ambitious in mind, as I'm perfectly > happy with only spanning a subset of org-inlinetasks.el. Disregarding > date and generalizing replacement text to "annotation", which could be set > to "replace" with a keyword, you could perhaps have something like one of > these: > > > [comment/Property:annotation; text] > [comment/TODO-TAG@author: annotation; text] > [comment/Property: annotation] > > [TODO-TAG/Property@Author: annotation; text] > [comment/Property: annotation] > > - Of course the / and @ operators are optional. > - I'm not sure what "Property" would be. > - Author could also be @work as in your previous example. > - Perhaps calculating TODO-TAGS on a document basis is a can of worms. > - I would be happier with having text before annotation, but that makes it > weird when you have no text attached (for inline tasks not associated to > a piece of text). > > —Rasmus -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] bisected
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 for one welcome our new git overlord :-) > > ! > > >
[O] wrong test, fix works, sorry (was: Re: bisected)
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-mode version 8.3beta (release_8.3beta-1097-gea5759 @ > /home/grfz/src/org-mode/lisp/) > > and emacs invoked with -Q I cannot save a modified file with ^x ^s > but when I leave emacs: > > receipt: > emacs -Q -nw /tmp/tempfile > > change buffer, do ^x ^s. I redid my test and now it works... Probably I forgot the -Q. Sorry for the noise, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [O] bisected
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
Re: [O] bisected
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 htmlize. There is a mode hook, and keybindings for `org-edit-src-exit' and `org-edit-src-save'" - (when org-edit-src-persistent-message -(org-set-local - 'header-line-format - (substitute-command-keys - (if org-src--allow-write-back - "Edit, then exit with \\[org-edit-src-exit] or abort with \ + (when org-src-mode +(when org-edit-src-persistent-message + (org-set-local + 'header-line-format + (substitute-command-keys +(if org-src--allow-write-back +"Edit, then exit with \\[org-edit-src-exit] or abort with \ \\[org-edit-src-abort]" - "Exit with \\[org-edit-src-exit] or abort with \ + "Exit with \\[org-edit-src-exit] or abort with \ \\[org-edit-src-abort]" - ;; Possibly activate various auto-save features (for the edit buffer - ;; or the source buffer). - (when org-edit-src-turn-on-auto-save -(setq buffer-auto-save-file-name - (concat (make-temp-name "org-src-") - (format-time-string "-%Y-%d-%m") - ".txt"))) - (unless (or org-src--auto-save-timer (zerop org-edit-src-auto-save-idle-delay)) -(setq org-src--auto-save-timer - (run-with-idle-timer - org-edit-src-auto-save-idle-delay t - (lambda () -(let (edit-flag) - (dolist (b (buffer-list)) -(when (org-src-edit-buffer-p) - (unless edit-flag (setq edit-flag t)) - (when (buffer-modified-p) (org-edit-src-save - (unless edit-flag -(cancel-timer org-src--auto-save-timer) -(setq org-src--auto-save-timer nil +;; Possibly activate various auto-save features (for the edit buffer +;; or the source buffer). +(when org-edit-src-turn-on-auto-save + (setq buffer-auto-save-file-name +(concat (make-temp-name "org-src-") +(format-time-string "-%Y-%d-%m") +".txt"))) +(unless (or org-src--auto-save-timer (zerop org-edit-src-auto-save-idle-delay)) + (setq org-src--auto-save-timer +(run-with-idle-timer + org-edit-src-auto-save-idle-delay t + (lambda () + (let (edit-flag) + (dolist (b (buffer-list)) + (when (org-src-edit-buffer-p) + (unless edit-flag (setq edit-flag t)) + (when (buffer-modified-p) (org-edit-src-save + (unless edit-flag + (cancel-timer org-src--auto-save-timer) + (setq org-src--auto-save-timer nil) (defun org-src-mode-configure-edit-buffer () (when (org-bound-and-true-p org-src--from-org-mode) -- Nicolas.
[O] org-babel R ascii results: unable to export table
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-contrib/babel/examples/ascii.org which I downloaded trying to understand how to export R output produced with the R 'ascii' package. Running this example, after adding ":exports results" to "ascii-example3" block, _on the first attempt_, the output was exported as an odt table (i was happy, this is my desired outcome). But afterwards, any subsequent attempts to export the same block resulted in a "verbatim" block, which is the same problem I was trying to solve. I tried to export as a latex buffer too, and even there i got a verbatim environment. I don't think it is bug, it is probably that I still don't understand org-babel well. Sorry not to provide any other sample code, but I wouldn't know where to begin. Any advice would be very appreciated. Thank you very much Marco Barbara
Re: [O] Marking/highlighting text temporarily
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 100% with you on this. One of the most important aspects of org is that it is all text and existing and powerful revision control systems can be used with any org file. Let's not go down the "everything including the kitchen sink" approach as we'll do everything badly and nothing well (i.e. end up with an MS Word look-a-like...). Let's keep things simple. Anyway, that's my opinion. Obviously, nobody is going to force me to use org-annotate for tracking changes but my concern is feature creep leading to a mess... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] #+LINK abbrevs possible in #+INCLUDEs ?
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
> open a document or use C-c C-c on a keyword.
I see. So is this a correct characterization:
SETUPFILΕ behaves as if all the "#+" lines of the pointed file were in
the current file.
INCLUDE behaves as if all the lines of the pointed file were in the
current file during export.
Hence if a file only has "#+" lines, as in:
--8<---cut here---start->8---
#+author: Programmation Fonctionnelle
#+date: Année 2014-2015
#+options: toc:nil d:RESULTS
#+property: header-args:ocaml :tangle yes
#+LaTeX_CLASS_OPTIONS: [a4paper]
#+latex_header: \usepackage{color}
#+latex_header: \usepackage{minted}
--8<---cut here---end--->8---
then I only need to SETUPFILE it (but I cannot just INCLUDE it because
of the tangle property that needs to be set when the file is opened).
Thanks,
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
signature.asc
Description: PGP signature
Re: [O] bisected
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-back) > > Is it related to your initial problem ? I don't know. It appeared while git bisecting. > 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-mode version 8.3beta (release_8.3beta-1097-gea5759 @ /home/grfz/src/org-mode/lisp/) and emacs invoked with -Q I cannot save a modified file with ^x ^s but when I leave emacs: receipt: emacs -Q -nw /tmp/tempfile change buffer, do ^x ^s. Thanks for looking into this, Gregor
Re: [O] "not in sub-editing buffer"
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.
Re: [O] bisected
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 in : Commit ea575950d957fcecc74ed6f53c29bb6b77e9fe26 modified lisp/org-src.el @@ -543,7 +543,7 @@ (define-minor-mode org-src-mode (org-set-local 'header-line-format (substitute-command-keys - (if write-back + (if org-src--allow-write-back "Edit, then exit with \\[org-edit-src-exit] or abort with \ \\[org-edit-src-abort]" "Exit with \\[org-edit-src-exit] or abort with \ -- Nico
Re: [O] Marking/highlighting text temporarily
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 org-inlinetasks.el. Since we have one we should try to minimize the distance whilst still keeping syntax as simple as possible, e.g. [comment:] or [TODO-TAG:] (I don't know what the "@" operator meant in your previous example). > 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 [comment: txt :annotation annot :author a :date d :other-properties p] is not "accessible" for non-Emacs users of the Org format. > 1. Annotations attached to arbitrary text in the buffer. The buffer text >should be visible, the annotation data invisible (basically the way >links work right now). This is a fortification/overlay issue. And I disagree strongly on having invisible parts. > 2. Plain annotation: just a chunk of free-form paragraph text that is >attached to the buffer text. What do you concretely have in mind here? Can't this be done with an inlinetask at the beginning of the file? Or a noexport heading? > 3. Replacement text: an alternate version of the buffer text; this could >be the basis of track changes stuff. Is this not the job of VC? > 4. Timestamps This seems like the job of e.g. vc-annotate.el, no? > 7. "Author" metadata would probably be unnecessary with full access to >the export channels, but it might still be desirable. What John was talking about was for collaboration. When you export John's notes on your machine how can it know it's from John if not set explicitly? In any case, I think it could be too verbose. Sidenote: In collaborated papers I simply use prefix "R:" and "K:" in inlinetasks. > That's all I can think of, just trying to get the ball rolling. I don't > have any opinions about actual syntax, though something with curly > braces might be nice. Nothing with curly braces is nice :) I think I have something much less ambitious in mind, as I'm perfectly happy with only spanning a subset of org-inlinetasks.el. Disregarding date and generalizing replacement text to "annotation", which could be set to "replace" with a keyword, you could perhaps have something like one of these: [comment/Property:annotation; text] [comment/TODO-TAG@author: annotation; text] [comment/Property: annotation] [TODO-TAG/Property@Author: annotation; text] [comment/Property: annotation] - Of course the / and @ operators are optional. - I'm not sure what "Property" would be. - Author could also be @work as in your previous example. - Perhaps calculating TODO-TAGS on a document basis is a can of worms. - I would be happier with having text before annotation, but that makes it weird when you have no text attached (for inline tasks not associated to a piece of text). —Rasmus -- A clever person solves a problem. A wise person avoids it
Re: [O] bisected
There was a hidden clue the commit could be problematic... Gregor Zattler writes: > First bad commit is: > bad0409c3b86e09c4559e97d5f394356c6ccbe7f ^^^ !
[O] bisected (was: )Re: "not in sub-editing buffer"
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 save without/before loading org. First bad commit is: bad0409c3b86e09c4559e97d5f394356c6ccbe7f This results in a startup error: Debugger entered--Lisp error: (void-variable write-back) With 86dcd907719c97530a266686694a7dc7bd25449a there is no error. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [O] Numbering only *some* subheadings?
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 explicitly override this choice with something like the following: * Course Outline :PROPERTIES: :UNNUMBERED: t :END: ** Introduction :PROPERTIES: :UNNUMBERED: nil :END: some long multi paragraph text. ** Origins of the French Revolution :PROPERTIES: :UNNUMBERED: nil :END: more text. Readings. Or introduce an explicit NUMBERED property (probably easier in code). However, the numbering will likely be complicated as they are no longer sub-numbered according to parent (i.e. the correct numbering is not 0.1, 0.2, 0.3 but 1, 2, 3). Do you think this is generally useful or is this a one-off document? —Rasmus -- To err is human. To screw up 10⁶ times per second, you need a computer
[O] "not in sub-editing buffer"
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
Re: [O] Numbering only *some* subheadings?
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 heading numbering for the top heading level (add
more CSS if you have more heading levels). It won't fix the TOC, though;
with numbered headline export, the numbers are hardcoded in the TOC.
You could export without heading numbering, and add numbering to both
headlines and TOC items with CSS, but it's more involved. Again, for
your simple example you could do something like this.
#+OPTIONS: num:nil
#+HTML_HEAD: h3::before {counter-increment: subheadnum;
#+HTML_HEAD:content: counter(subheadnum) ". "}
#+HTML_HEAD:h2 {counter-reset: subheadnum}
#+HTML_HEAD:#text-table-of-contents ul ul {list-style-type:
decimal}
Yours,
Christian
Matt Price writes:
> I would like to number only a single subset of subheadings in an html
> export, so that, e.g.,
>
> * Introduction
> lorem ipsum
> * Coiurse Requirements
> lorem ipsum
> * Course Outline
> ** Introduction
> some long multi paragraph text.
> ** Origins of the French Revolution
> more text. Readings.
> ** Liberty, Equality, Fraternity?
> ... etc
>
> becomes:
>
> Introduction
>
> Course Requirements
>
> Course Outline
>
> 1. Introduction
> bla bla bla
> 2. Origins of hte French Revolution
> bla bla bla.
> Readings: bla bla bla
> 3. Liberty, Eaquality, Fraternity
>
> ... etc
>
> Is this possible? Anyone have a suggestion?
>
> Thanks as always,
> Matt
