Re: [O] In-line code, italics, quotation marks, etc.
Hi Nick, Nick Dokos ndo...@gmail.com writes: Since this is the third time in as many weeks that somebody brings this exact problem up, this probably qualifies as a FAQ. But before going there, is there *any* reason to forbid quotes in the border? IOW, maybe it's a better idea to change the default value of org-emphasis-regexp-components instead. I would guess it is to allow writing things like: if you enter the tilde character '~' then things are fine, but don't forget the '~'. However, I use double and single quotes as code/verbatim much more often than I need to write such examples, so I'm all for changing the default. Alan
Re: [O] exporter for latex g-brief - extending \begin{document}
LanX lanx.p...@googlemail.com writes:
Hi
Im using a latex class called g-brief to create formal german letters (see
e.g. http://vimpy.org/wp/archives/47) and I'm trying to add an exporter to
org-mode.
Have you tried ox-koma-letter.el?
my problem is that I need to enclose the text within
\begin{document}
\begin{g-brief}
... here comes text
\end{g-brief}
\end{document}
#+TITLE: title
#+BEGIN_g-brief
... here comes text
#+END_g-brief
so any customization possibilities to nest the document within
begin/end{g-brief} (before I try patching the org-mode.el)
Does it help to upgrade, my org-version is 7.7
Yes.
Hope it helps,
Rasmus
--
Slowly unravels in a ball of yarn and the devil collects it
Re: [O] In-line code, italics, quotation marks, etc.
Hi Nick On Wed, Mar 5, 2014 at 4:39 AM, Nick Dokos ndo...@gmail.com wrote: Since this is the third time in as many weeks that somebody brings this exact problem up, this probably qualifies as a FAQ. But before going there, is there *any* reason to forbid quotes in the border? IOW, maybe it's a better idea to change the default value of org-emphasis-regexp-components instead. Did you see this thread?: http://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=emacs-orgmodesort=date:latequery=%2Bsubject:%22[RFC]+Emphasis+regexp%22 There I provided also the history of org-emphasis-regexp-components. Michael
Re: [O] References
On Sat, 01 Mar 2014 15:03:55 -0500 Nick Dokos ndo...@gmail.com wrote: Sharon Kimble boudic...@talktalk.net writes: On Sat, 01 Mar 2014 13:22:45 -0500 Nick Dokos ndo...@gmail.com wrote: Sharon Kimble boudic...@talktalk.net writes: I'm using [fn:1] to reference articles in an academic article, but how should I reference it back from the list of references at the end of the article please? Thanks Sharon. Not sure what you mean: in the org-mode buffer or in some exported file? In the former case, C-c C-c on the footnote marker in the text takes you to the footnote and C-c C-c on the footnote marker in the footnote takes you back. The article is in org-mode and I can open the file easily in a buffer, and everywhere that the original article has a reference to a numbered item in the 'References' section at the end of the article, I have put [fn:*] where * is the number of the reference. The [fn:*] has been manually put in, without using any keybindings or macros. What I'm now looking for is some way to link my [fn:*] to its mate in the reference list. Can it be done please? Sure: here's the general outline: --8---cut here---start-8--- * Section This takes us to a footnote[fn:1]. * References [fn:1] This is the footnote. --8---cut here---end---8--- Just label each footnote with the corresponding footnote mark and you should be OK. After all, it's all plain text. After spending some time on it, I've just exported the article to my blog using 'org2blog' and looking at the preview of the post, I see that what I know of as 'references', headed that in the original, is showing as 'Footnotes', although there is already a section [in the org doc] headed Footnotes and which is not exported. How can I get the 'Footnote' section to be the same as the org-doc, and the 'References' section to contain the references, the same as the org-doc please? Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots Debian testing, Fluxbox 1.3.5, emacs 24.3.1 Registered Linux user 561944 signature.asc Description: PGP signature
[O] Table disaligned with some pretty entities
Dear all, nothing of crucial importance for the sake of humanity, but when I realign (C-c C-c) the following table: | entry1 | \check | | entry2 | X | with pretty-entities toggled (C-c C-x \), columns are not perfectly aligned. My setup: Emacs 24.3.1 (i386-mingw-nt6.1.7601) Org-mode 8.2.5h (8.2.5h-19-g0ceb68-elpa) Thanks, Giacomo
Re: [O] Table disaligned with some pretty entities
Giacomo M jackja...@gmail.com writes: Dear all, nothing of crucial importance for the sake of humanity, but when I realign (C-c C-c) the following table: | entry1 | \check | | entry2 | X | with pretty-entities toggled (C-c C-x \), columns are not perfectly aligned. Probably you are using different fonts for check and the rest. Use M-x describe-char and look at the line starting with The component character(s) are displayed by these fonts Hope it helps, Rasmus -- Hooray!
Re: [O] In-line code, italics, quotation marks, etc.
Michael Brand michael.ch.br...@gmail.com writes: On Wed, Mar 5, 2014 at 4:39 AM, Nick Dokos ndo...@gmail.com wrote: Since this is the third time in as many weeks that somebody brings this exact problem up, this probably qualifies as a FAQ. But before going there, is there *any* reason to forbid quotes in the border? IOW, maybe it's a better idea to change the default value of org-emphasis-regexp-components instead. Did you see this thread?: http://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=emacs-orgmodesort=date:latequery=%2Bsubject:%22[RFC]+Emphasis+regexp%22 There I provided also the history of org-emphasis-regexp-components. No, I missed that: no time to read it now, but I'll take a look. Thanks! -- Nick
Re: [O] References
Sharon Kimble boudic...@talktalk.net writes: After spending some time on it, I've just exported the article to my blog using 'org2blog' and looking at the preview of the post, I see that what I know of as 'references', headed that in the original, is showing as 'Footnotes', although there is already a section [in the org doc] headed Footnotes and which is not exported. How can I get the 'Footnote' section to be the same as the org-doc, and the 'References' section to contain the references, the same as the org-doc please? Customize org-footnote-section. -- Nick
Re: [O] Table disaligned with some pretty entities
Very interesting... thank you, Rasmus! Indeed Consolas, the font I was using, doesn't have the check mark unicode character (U+2713). Switching to DejaVu Sans Mono solved the problem. Giacomo On Wed, Mar 5, 2014 at 1:01 PM, Rasmus ras...@gmx.us wrote: Giacomo M jackja...@gmail.com writes: Dear all, nothing of crucial importance for the sake of humanity, but when I realign (C-c C-c) the following table: | entry1 | \check | | entry2 | X | with pretty-entities toggled (C-c C-x \), columns are not perfectly aligned. Probably you are using different fonts for check and the rest. Use M-x describe-char and look at the line starting with The component character(s) are displayed by these fonts Hope it helps, Rasmus -- Hooray!
Re: [O] [Bug] org-open-at-point adds file+
Hello, Daimrod daim...@gmail.com writes: I think that since its recent rewrite, `org-open-at-point' adds 'file+' before the name of the application before trying to find the correct application. For example the following link: #+BEGIN_EXAMPLE [[docview:foo.pdf]] #+END_EXAMPLE won't trigger the `org-docview-open' handler This should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] org-element-context doesn't parse consistently link with spaces
Hello, Daimrod daim...@gmail.com writes: I think that there is a bug in `org-element-context' because it doesn't seem to parse link with spaces consistently. For example: #+BEGIN_EXAMPLE v [[file:test 1 2 3]] ^ #+END_EXAMPLE If the cursor is before the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test :raw-link file:test :application nil :search-option nil :begin 26 ...)) #+END_EXAMPLE if the cursor is one or after the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test%201%202%203 :raw-link file:test%201%202%203 :application nil :search-option nil :begin 1 ...)) #+END_EXAMPLE I cannot reproduce it. What Org version do you use? Did you try to disable `org-element-use-cache'? Regards, -- Nicolas Goaziou
Re: [O] References
On Wed, 05 Mar 2014 07:15:07 -0500 Nick Dokos ndo...@gmail.com wrote: Sharon Kimble boudic...@talktalk.net writes: After spending some time on it, I've just exported the article to my blog using 'org2blog' and looking at the preview of the post, I see that what I know of as 'references', headed that in the original, is showing as 'Footnotes', although there is already a section [in the org doc] headed Footnotes and which is not exported. How can I get the 'Footnote' section to be the same as the org-doc, and the 'References' section to contain the references, the same as the org-doc please? Customize org-footnote-section. Thanks, never customized anything before, but that was quite easy. :) Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots Debian testing, Fluxbox 1.3.5, emacs 24.3.1 Registered Linux user 561944 signature.asc Description: PGP signature
Re: [O] [Bug] org-open-at-point adds file+
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I think that since its recent rewrite, `org-open-at-point' adds 'file+' before the name of the application before trying to find the correct application. For example the following link: #+BEGIN_EXAMPLE [[docview:foo.pdf]] #+END_EXAMPLE won't trigger the `org-docview-open' handler This should be fixed. Thank you for reporting it. Thanks for the fast reply. Regards, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I think that there is a bug in `org-element-context' because it doesn't seem to parse link with spaces consistently. For example: #+BEGIN_EXAMPLE v [[file:test 1 2 3]] ^ #+END_EXAMPLE If the cursor is before the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test :raw-link file:test :application nil :search-option nil :begin 26 ...)) #+END_EXAMPLE if the cursor is one or after the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test%201%202%203 :raw-link file:test%201%202%203 :application nil :search-option nil :begin 1 ...)) #+END_EXAMPLE I cannot reproduce it. What Org version do you use? Did you try to disable `org-element-use-cache'? Sorry, it happens with: #+BEGIN_EXAMPLE [[file:test%201%202%203][file:test 1 2 3]] #+END_EXAMPLE I use org-mode version release_8.0.2-101-gce5988 (I follow the git upstream) and I tried it with `org-element-use-cache' set to nil. It doesn't happen with: #+BEGIN_EXAMPLE [[file:test 1 2 3]] #+END_EXAMPLE but as soon as the cursor leaves the link, org-mode rewrite the link to: #+BEGIN_EXAMPLE [[file:test%201%202%203][file:test 1 2 3]] #+END_EXAMPLE Best, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Hello, Daimrod daim...@gmail.com writes: I use org-mode version release_8.0.2-101-gce5988 (I follow the git upstream) and I tried it with `org-element-use-cache' set to nil. There was no `org-element-use-cache' in Org 8.0. Could you update Org and try again? Regards, -- Nicolas Goaziou
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I use org-mode version release_8.0.2-101-gce5988 (I follow the git upstream) and I tried it with `org-element-use-cache' set to nil. There was no `org-element-use-cache' in Org 8.0. Could you update Org and try again? I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. And you're right, it doesn't happen when `org-element-use-cache' is set to nil. However, when `org-element-use-cache' is set to t, then it looks like `org-element-context' uses the link's title instead of the link's value. e.g. #+BEGIN_EXAMPLE v-- with the cursor here, it returns (link (:type file :path foo ...)) [[file:foo][file:test 1 2 3]] ^-^ when the cursor is in this zone, it returns (link (:type file :path test ...)) ^-- when the cursor is after this point (after the first space) it returns (link (:type file :path test 1 2 3 ...)) #+END_EXAMPLE Best, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? Regards, -- Nicolas Goaziou
Re: [O] org-element-context doesn't parse consistently link with spaces
Hi Nicolas and Greg, Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. I think Greg did C-h v org-version RET, which returns 8.2.5h both from the maint and the master branch. Greg: M-x org-version RET gives all the information we need. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? Mhh... now *I* am confused. The latest release on master is Org-mode version 8.2.5h (release_8.2.5h-676-gfb8a04) How can it be 8.2.5e for you? -- Bastien
Re: [O] org-element-context doesn't parse consistently link with spaces
Hello Nicolas On 5 March 2014 09:25, Nicolas Goaziou n.goaz...@gmail.com wrote: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? Output from eshell freshly pulling right now: ,-- | ~/build/org $ git stat | git: 'stat' is not a git command. See 'git --help'. | | Did you mean one of these? | status | stage | stash | ~/build/org $ git status | On branch master | Your branch is up-to-date with 'origin/master'. | | nothing to commit, working directory clean | ~/build/org $ c:/cygwin/bin/make autoloads | /usr/bin/make -C lisp autoloads | make[1]: Entering directory '/cygdrive/c/Users/jonpe/build/org/lisp' | rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc org-install.elc | cygwin warning: | MS-DOS style path detected: c:/Users/jonpe/build/org | Preferred POSIX equivalent is: /cygdrive/c/Users/jonpe/build/org | CYGWIN environment variable option nodosfilewarning turns off this warning. | Consult the user's guide for more details about POSIX paths: | http://cygwin.com/cygwin-ug-net/using.html#using-pathnames | org-version: 8.2.5h (release_8.2.5h-678-g51718d) `-- I initially cloned Org onto this machine 1 week ago. 8.2.5h should be on master as well according to the above Regards, -- Nicolas Goaziou Regards, Jon
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? I really don't understand. I am on the master branch, the latest commit I see is yours (51718d9 Fix last commit). I'm trying with a fresh clone. Regards, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Bastien b...@gnu.org writes: Hi Nicolas and Greg, Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. I think Greg did C-h v org-version RET, which returns 8.2.5h both from the maint and the master branch. Greg: M-x org-version RET gives all the information we need. Awww that's tricky, M-x org-version doesn't have the same behavior than M-: (org-version) M-x org-version returns: Org-mode version 8.2.5h (release_8.2.5h-678-gd8c717 @ ...) -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Hello, Bastien b...@gnu.org writes: Mhh... now *I* am confused. The latest release on master is Org-mode version 8.2.5h (release_8.2.5h-676-gfb8a04) How can it be 8.2.5e for you? Good question. I have absolutely no clue. OTOH, my tree looks up-to-date, and my .git/config reports: [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = orgm...@orgmode.org:org-mode.git [branch master] remote = origin merge = refs/heads/master I don't see anything suspicious here. Also, how comes that master gets a maint tag? AFAIU, release_8.2.5h was put on 53c664c, which belongs to maint. Regards, -- Nicolas Goaziou
Re: [O] org-element-context doesn't parse consistently link with spaces
Daimrod daim...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? I really don't understand. I am on the master branch, the latest commit I see is yours (51718d9 Fix last commit). I'm trying with a fresh clone. Still the same with a fresh clone. Regards, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Good question. I have absolutely no clue. OTOH, my tree looks up-to-date, and my .git/config reports: [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = orgm...@orgmode.org:org-mode.git [branch master] remote = origin merge = refs/heads/master I don't see anything suspicious here. Well, make sure you did a ~$ make or ~$ make autoloads so that lisp/org-version.el is correct. Also, how comes that master gets a maint tag? AFAIU, release_8.2.5h was put on 53c664c, which belongs to maint. I always add the release tag on maint, that's where both minor and major releases are made from (expect that I merge master into maint before a major release.) We could have a dedicated tag for the master branch, but for any move here I'd refer to Achim. -- Bastien
Re: [O] org-element-context doesn't parse consistently link with spaces
Daimrod daim...@gmail.com writes: Awww that's tricky, M-x org-version doesn't have the same behavior than M-: (org-version) That's on purpose: (org-version) is what you want to call in a program, hence the short version, while M-x org-version RET is what you want to call interactively (hence the longer one.) -- Bastien
Re: [O] how to force org-mode to interpret number as string
Hi Stefan, Stefan Huchler stefan.huch...@mail.de writes: The Problem is that that org-mode seems to auto-format the salary column as a number. That a problem here, but I guess this is handy in many circumstances. Why don't use just turn the number into a string in your code? -- Bastien
Re: [O] org-element-context doesn't parse consistently link with spaces
Bastien b...@gnu.org writes: Well, make sure you did a ~$ make or ~$ make autoloads so that lisp/org-version.el is correct. I always do: make org-reload from Eshell. That doesn't change anything. I always add the release tag on maint, that's where both minor and major releases are made from (expect that I merge master into maint before a major release.) That is what I don't understand. You added 8.2.5h to maint, and master wasn't merged into maint since then. How can the tag propagate to master? Regards, -- Nicolas Goaziou
Re: [O] org-element-context doesn't parse consistently link with spaces
Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: Awww that's tricky, M-x org-version doesn't have the same behavior than M-: (org-version) That's on purpose: (org-version) is what you want to call in a program, hence the short version, while M-x org-version RET is what you want to call interactively (hence the longer one.) Now I understand this annoying behaviour - whenever I wrote a function for quick insertion of system-info into a mail I only got the short version but wanted the long one. So it must be #+begin_src emacs-lisp (call-interactively 'org-version) #+end_src #+results: : Org-mode version 8.2.5g (release_8.2.5g-564-ge45d13 @ /usr/share/emacs/24.3/lisp/org/lisp/) instead of #+begin_src emacs-lisp (org-version) #+end_src #+results: : 8.2.5g -- cheers, Thorsten
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: I always do: make org-reload from Eshell. That doesn't change anything. Please do ~$ git fetch --tags to update all your tags, and make again. I always add the release tag on maint, that's where both minor and major releases are made from (expect that I merge master into maint before a major release.) That is what I don't understand. You added 8.2.5h to maint, and master wasn't merged into maint since then. How can the tag propagate to master? Tags are on commits, not on branches, and commmits can belong to multiple branches. Since the tagged commit is both on the maint and the master branch, make autoloads will use the same tag to generate Org's version in both case. -- Bastien
Re: [O] org-element-context doesn't parse consistently link with spaces
Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: Awww that's tricky, M-x org-version doesn't have the same behavior than M-: (org-version) That's on purpose: (org-version) is what you want to call in a program, hence the short version, while M-x org-version RET is what you want to call interactively (hence the longer one.) I tried (org-version t) C-x C-e but it inserted nothing. Looking at the code, I'd suggest the following patch. OTOH, I find it a bad idea that some arguments are ignored in non-interactive uses, it'd be better to have a function which fully obeys its arguments, and has an interactive spec which sets the argument. If you're interested I can do that. From: Nicolas Richard theonewiththeevill...@yahoo.fr Date: Wed, 5 Mar 2014 16:38:58 +0100 Subject: [PATCH] org.el (org-version): mention that HERE is ignored in non-interactive uses. --- lisp/org.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 64ee668..5c1b61e 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -298,7 +298,8 @@ identifier. ;;;###autoload (defun org-version (optional here full message) Show the org-mode version in the echo area. -With prefix argument HERE, insert it at point. +With prefix argument HERE (this is ignored in non-interactive +uses), insert it at point. When FULL is non-nil, use a verbose version string. When MESSAGE is non-nil, display a message with the version. (interactive P) -- 1.8.3.2
[O] Bug: [patch] also tangle headlines that begin with lower case string comment [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Hi, Trying to tangle code blocks in a headline line like: #+begin_src org ,* Comment retrouver #+end_src I struggled to understand what I was doing wrong because it didn't tangle anything. In fact, the french word Comment was mistakenly parsed as the org-comment-string, and so the headline was skipped. Let's avoid that (see patch below). I take the opportuinty to ask if we should try and make this function use org-element instead. My naïve approach doesn't work: #+begin_src emacs-lisp (save-excursion (org-back-to-heading t) (let ((elt (org-element-at-point))) (while (and elt (not (org-element-property :commentedp elt))) (setq elt (org-element-property :parent elt))) elt)) #+end_src because an heading doesn't know what its parent heading is (the property is nil). This can be fixed by doing: #+begin_src emacs-lisp (defun org-babel-under-commented-heading-p () Return t if currently under a commented heading. (unless (org-before-first-heading-p) (save-excursion (org-back-to-heading t) (let ((elt (org-element-at-point))) (while (and elt (not (org-element-property :commentedp elt))) (setq elt (and (org-up-heading-safe) (org-element-at-point elt #+end_src byt I'm not sure it is very pretty. Opinions ? Anyway, here's the quicker fix : From: Nicolas Richard theonewiththeevill...@yahoo.fr Date: Wed, 5 Mar 2014 14:54:49 +0100 Subject: [PATCH] * ob-tangle.el (org-babel-under-commented-heading-p): Disable case folding to avoid matching Comment at beg of headline. --- lisp/ob-tangle.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 0096ac9..9f0ea0d 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -361,7 +361,8 @@ that the appropriate major-mode is set. SPEC has the form: Return t if currently under a commented heading. (unless (org-before-first-heading-p) (if (let ((hd (nth 4 (org-heading-components - (and hd (string-match (concat ^ org-comment-string) hd))) + (and hd (let (case-fold-search) + (string-match (concat ^ org-comment-string) hd t (save-excursion (and (org-up-heading-safe) -- Nico.
[O] Bug: add elisp to org-babel-tangle-lang-exts to support elisp source blocks [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Hello, elisp (vs emacs-lisp) code blocks are supported via an entry org-src-lang-modes but not in org-babel-tangle-lang-exts. The patch below is to fix that. From: Nicolas Richard theonewiththeevill...@yahoo.fr Date: Wed, 5 Mar 2014 16:49:30 +0100 Subject: [PATCH] lisp/ob-tangle.el: elisp should get tangled to .el files. --- lisp/ob-tangle.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 5797ea4..8923e16 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -41,7 +41,8 @@ (declare-function org-before-first-heading-p org ()) (defcustom org-babel-tangle-lang-exts - '((emacs-lisp . el)) + '((emacs-lisp . el) +(elisp . el)) Alist mapping languages to their file extensions. The key is the language name, the value is the string that should be inserted as the extension commonly used to identify files -- 1.8.3.2
Re: [O] exporter for latex g-brief - extending \begin{document}
Hi Rasmus Have you tried ox-koma-letter.el? not yet, I just started recently switching back to latex and g-brief did what I needed for a formal german letter and I just need it once per month so far. #+TITLE: title #+BEGIN_g-brief ... here comes text #+END_g-brief OK thanks, I take it as indication that the exporter can't be configured to do this implicitely... Yes. could you please be more specific? ... Oh I see... http://orgmode.org/worg/exporters/koma-letter-export.html depends on the following org-mode version 8.0 or greater cheers Rolf
Re: [O] org-element-context doesn't parse consistently link with spaces
Hi Nicolas, Nicolas Richard theonewiththeevill...@yahoo.fr writes: OTOH, I find it a bad idea that some arguments are ignored in non-interactive uses, it'd be better to have a function which fully obeys its arguments, and has an interactive spec which sets the argument. If you're interested I can do that. Of course I'm interested, thanks in advance! -- Bastien
Re: [O] org-element-context doesn't parse consistently link with spaces
Bastien b...@gnu.org writes: Hi Nicolas, Nicolas Richard theonewiththeevill...@yahoo.fr writes: OTOH, I find it a bad idea that some arguments are ignored in non-interactive uses, it'd be better to have a function which fully obeys its arguments, and has an interactive spec which sets the argument. If you're interested I can do that. Of course I'm interested, thanks in advance! Could you review this ? thanks. From: Nicolas Richard theonewiththeevill...@yahoo.fr Date: Wed, 5 Mar 2014 17:25:45 +0100 Subject: [PATCH] lisp/org.el (org-version): obey all arguments in non-interactive uses. --- lisp/org.el | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 5c1b61e..11184cc 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -297,12 +297,11 @@ identifier. ;;;###autoload (defun org-version (optional here full message) - Show the org-mode version in the echo area. -With prefix argument HERE (this is ignored in non-interactive -uses), insert it at point. -When FULL is non-nil, use a verbose version string. -When MESSAGE is non-nil, display a message with the version. - (interactive P) + Show the org-mode version. +Interactively, or when MESSAGE is non-nil, show it in echo area. +With prefix argument, or when HERE is non-nil, insert it at point. +In non-interactive uses, a reduced version string is output unless FULL is given. + (interactive (list current-prefix-arg t (not current-prefix-arg))) (let* ((org-dir (ignore-errors (org-find-library-dir org))) (save-load-suffixes (when (boundp 'load-suffixes) load-suffixes)) (load-suffixes (list .el)) @@ -322,12 +321,12 @@ When MESSAGE is non-nil, display a message with the version. (concat mixed installation! org-install-dir and org-dir)) org-loaddefs.el can not be found!))) (version1 (if full version org-version))) -(if (org-called-interactively-p 'interactive) - (if here - (insert version) - (message version)) - (if message (message version1)) - version1))) +(when here (insert version1)) +(when message (message %s version1)) +version1)) + + + (defconst org-version (org-version)) -- 1.8.3.2
Re: [O] Bug: [patch] also tangle headlines that begin with lower case string comment [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Hello, Nicolas Richard theonewiththeevill...@yahoo.fr writes: I take the opportuinty to ask if we should try and make this function use org-element instead. My naïve approach doesn't work: #+begin_src emacs-lisp (save-excursion (org-back-to-heading t) (let ((elt (org-element-at-point))) (while (and elt (not (org-element-property :commentedp elt))) (setq elt (org-element-property :parent elt))) elt)) #+end_src because an heading doesn't know what its parent heading is (the property is nil). This can be fixed by doing: #+begin_src emacs-lisp (defun org-babel-under-commented-heading-p () Return t if currently under a commented heading. (unless (org-before-first-heading-p) (save-excursion (org-back-to-heading t) (let ((elt (org-element-at-point))) (while (and elt (not (org-element-property :commentedp elt))) (setq elt (and (org-up-heading-safe) (org-element-at-point elt #+end_src byt I'm not sure it is very pretty. Opinions ? Of course, `org-element-at-point' can parse headlines, but if speed is a factor, since headline syntax is not context-dependent, it is often worth considering using regexps. Also, don't forget `org-with-limited-levels' when you need to tell a headline from an inlinetask. Regards, -- Nicolas Goaziou
Re: [O] org-element cache and LAST_REPEAT
Hello, Michael Brand michael.ch.br...@gmail.com writes: On Tue, Mar 4, 2014 at 8:58 PM, Matt Lundin m...@imapmail.org wrote: I suspect this is related the bug I reported earlier today: http://permalink.gmane.org/gmane.emacs.orgmode/82979 I guess the same bug. I have overseen your report. This should be fixed. Thanks to both of you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] org-element cache and LAST_REPEAT
Hi Nicolas On Wed, Mar 5, 2014 at 8:11 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: This should be fixed. Thanks to both of you for reporting it. It works, thank you. Michael
[O] Google + org-mode agenda? can it be done?
Can the google calendar work with org-mode agenda please? I haven't seen any indication that it can be done when I've been googling around. But I thought that I would ask anyway. And on the same tack, can google tasks work with org-modes TODO lists please? Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots Debian testing, Fluxbox 1.3.5, emacs 24.3.1 Registered Linux user 561944 signature.asc Description: PGP signature
Re: [O] how to force org-mode to interpret number as string
Bastien b...@gnu.org writes: Hi Stefan, Stefan Huchler stefan.huch...@mail.de writes: The Problem is that that org-mode seems to auto-format the salary column as a number. That a problem here, but I guess this is handy in many circumstances. Why don't use just turn the number into a string in your code? if I could do that, without loosing the numbers behind the point I would be ok with that, but I dont want a fixed system for 1 table, but for a random table. I wrote something similar in python: https://github.com/spiderbit/mmailer I just wanted to migrate it into org-mode/emacs because I have not to deal with csv files and because I can use the email-ability from emacs/gnus. Its just stupid to have a seperate smtp-client-code and smtp-auth-settings in such tool. Its around 500 lines of code in emacs I would get that done in maybe 20 lines of code. If that problem would not occur. If there is something in elisp that is like that: if is-that-a-number(column): column = number-to-string(give-the-complete-number(column)) I would be happy to use that ^^. But If he saves it as number I think he will not save how many zeros were behind the point. So basicly there is no solution to it that will satisfy me. I really struggle to use the org-mode structures its always a little bit off, it sounds all good but fails in small details. Sorry whining but it is frustrating when you have 99% and you need to get the 1% problem out of the way but it will not happen except writing seperate 1000 lines of code in R or something like that (that was the workaround for my last problem with my last group-by problem, with org-mode tables. That then makes the 99% just worthless because it is useless if its static code that is not dynamic and works for this kind of problems but only for this one example of the problem. I dont want to repreat myself. Maybe I even could make that code a seperate small emacs-package. Because there seems that there is no serial-mail tool for emacs right now. Maybe I am wrong here, but I searched long and did not find one. Maybe you or somebody else can point me to it, then I maybe dont need that to work anymore. It´s just so stupid that seems for me very general problems, that you maybe have a implizit declaration of a variable but you should still have a way to define it manually there is even a way to do this, to force a field to be a number but not to force it to be a string. Something like that: tblfm: $4 = ($4);N or was it \N why is there no \S and good. ok its not in the information gathering and a seperate process but in the table you have at least the full number there. Hope there is one emacs-way to do that. That dont need learning another programming language like R and works for any strings. I am a bit disapointed in org-tables because they never work like I need them too. I think the only alterantive would be to save the org-capture data in a csv-file so I have to write thousends of lines of code to manage paths and projects and whatever like I have in python. Then because csv works better in not converting without me saying it to convert a string to a number. and then use file-open blabla. But nice that you did answer that fast ;)
[O] How to collect multiple source blocks with the same name at the same level
Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson
[O] inline source code blocks
Some questions about inline source code blocks: - They're not fontified even when org-src-fontify-natively is true -- correct? - They're not included in tangled code; is that intended behavior? The manual does not seem to say they're different from normal code blocks, except for syntax. There are also mailing list messages that suggest they're not meant to be exported. What is the correct understanding? I can submit a patch to the manual once I understand this myself. - For very short code snippets (1-2 lines), it would be good to allow specifying (via properties) a default language for code blocks (say C) and a prefix character (say ''), after which one could write int i; and have this be the equivalent of +BEGIN_SRC c int i; +END_SRC by analogy with short literal examples : such as this Would this break any Org invariants? (Context: trying to use Org for literate programming in C++; interested in others' experience in this area). Thanks, Ilya
Re: [O] How to collect multiple source blocks with the same name at the same level
noweb? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] How to collect multiple source blocks with the same name at the same level
Aloha Grant, I'm not certain what you're after. From the Org mode manual: * outline header :PROPERTIES: :header-args::cache yes :END: Perhaps :header-args: :tangle myfile.el All the best, Tom Grant Rettke g...@wisdomandwonder.com writes: Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Thomas S. Dye http://www.tsdye.com
Re: [O] Google + org-mode agenda? can it be done?
Sharon Kimble boudic...@talktalk.net writes: Can the google calendar work with org-mode agenda please? I haven't seen any indication that it can be done when I've been googling around. But I thought that I would ask anyway. Synchronization is not seamless, but it can be accomplished with some setup. See: http://orgmode.org/worg/org-tutorials/org-google-sync.html And on the same tack, can google tasks work with org-modes TODO lists please? This tool does bi-directional synchronization (org-files - google tasks). Note: it synchronizes files, not the agenda's todo list. https://bitbucket.org/edgimar/michel-orgmode Matt
Re: [O] Bug: [patch] also tangle headlines that begin with lower case string comment [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Of course, `org-element-at-point' can parse headlines, but if speed is a factor, since headline syntax is not context-dependent, it is often worth considering using regexps. I don't know if speed is terribly important here, but since my suggested approach uses a loop instead of recursion, it ends up being faster for nested headlines (more than 5 levels). This obviously could be fixed in the initial approach too. Since we know where point is, we could also use (org-element-headline-parser nil t) instead of (org-element-at-point). That's a tiny bit faster. For those interested, here's timing info: (progn (defun yf/org-babel-under-commented-heading-p () Return t if currently under a commented heading. (unless (org-before-first-heading-p) (save-excursion (org-back-to-heading t) (let ((elt (org-element-headline-parser nil t))) (while (and elt (not (org-element-property :commentedp elt))) (setq elt (and (org-up-heading-safe) (org-element-headline-parser nil t elt (elp-instrument-list '(org-babel-under-commented-heading-p yf/org-babel-under-commented-heading-p)) (let ((org-element-use-cache t)) (with-temp-buffer (insert * foo bar ** bal *** bal bal * bal ** bal *** bal bal * bal ** bal *** bal bal * bal ** bal) (org-mode) (goto-char (point-min)) (forward-line 4) ;; - 0 for top level, etc. ;; (profiler-reset) (let ((n 100)) (garbage-collect) (dotimes (_ n) (org-babel-under-commented-heading-p)) (dotimes (_ n) (yf/org-babel-under-commented-heading-p)) (elp-results) ) ;; (profiler-report) ))) But as I said, I don't think speed matters much for this specific function. Also, don't forget `org-with-limited-levels' when you need to tell a headline from an inlinetask. I have absolutely no idea if this is important here. -- Nicolas.
Re: [O] Bug: [patch] also tangle headlines that begin with lower case string comment [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Of course, `org-element-at-point' can parse headlines, but if speed is a factor, since headline syntax is not context-dependent, it is often worth considering using regexps. I don't know if speed is terribly important here, but since my suggested approach uses a loop instead of recursion, it ends up being faster for nested headlines (more than 5 levels). This obviously could be fixed in the initial approach too. Since we know where point is, we could also use (org-element-headline-parser nil t) instead of (org-element-at-point). That's a tiny bit faster. For those interested, here's timing info: (progn (defun yf/org-babel-under-commented-heading-p () Return t if currently under a commented heading. (unless (org-before-first-heading-p) (save-excursion (org-back-to-heading t) (let ((elt (org-element-headline-parser nil t))) (while (and elt (not (org-element-property :commentedp elt))) (setq elt (and (org-up-heading-safe) (org-element-headline-parser nil t elt (elp-instrument-list '(org-babel-under-commented-heading-p yf/org-babel-under-commented-heading-p)) (let ((org-element-use-cache t)) (with-temp-buffer (insert * foo bar ** bal *** bal bal * bal ** bal *** bal bal * bal ** bal *** bal bal * bal ** bal) (org-mode) (goto-char (point-min)) (forward-line 4) ;; - 0 for top level, etc. ;; (profiler-reset) (let ((n 100)) (garbage-collect) (dotimes (_ n) (org-babel-under-commented-heading-p)) (dotimes (_ n) (yf/org-babel-under-commented-heading-p)) (elp-results) ) ;; (profiler-report) ))) Also, don't forget `org-with-limited-levels' when you need to tell a headline from an inlinetask. I have absolutely no idea if this is important here. -- Nicolas.
Re: [O] Bug: [patch] also tangle headlines that begin with lower case string comment [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Nicolas Richard theonewiththeevill...@yahoo.fr writes: I don't know if speed is terribly important here, but since my suggested approach uses a loop instead of recursion, it ends up being faster for nested headlines (more than 5 levels). This obviously could be fixed in the initial approach too. Since we know where point is, we could also use (org-element-headline-parser nil t) instead of (org-element-at-point). That's a tiny bit faster. `org-element-headline-parser' is a bit low-level. Also, it will still retrieve all entry properties, which explains why regexps are faster. Anyway, it doesn't matter much if speed is not an issue. Regards, -- Nicolas Goaziou
Re: [O] How to collect multiple source blocks with the same name at the same level
Exactly I'm doing a #+BEGIN_SRC emacs-lisp :tangle .emacs.el :noweb tangle What I'm aiming for is the case where you have lots of code blocks interspersed with written language... and want them to accumulate under a single identifier. I will keep digging. On Wed, Mar 5, 2014 at 3:39 PM, Thomas S. Dye t...@tsdye.com wrote: Aloha Grant, I'm not certain what you're after. From the Org mode manual: * outline header :PROPERTIES: :header-args::cache yes :END: Perhaps :header-args: :tangle myfile.el All the best, Tom Grant Rettke g...@wisdomandwonder.com writes: Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Thomas S. Dye http://www.tsdye.com -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson
Re: [O] How to collect multiple source blocks with the same name at the same level
Yup I'm using noweb references. On Wed, Mar 5, 2014 at 3:35 PM, Samuel Wales samolog...@gmail.com wrote: noweb? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW. -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson
Re: [O] How to collect multiple source blocks with the same name at the same level
Here is what I was looking for: http://orgmode.org/manual/noweb_002dref.html *** Windows [fn:39] :PROPERTIES: :noweb-ref: uxo-decision :END: Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC On Wed, Mar 5, 2014 at 4:24 PM, Grant Rettke g...@wisdomandwonder.comwrote: Exactly I'm doing a #+BEGIN_SRC emacs-lisp :tangle .emacs.el :noweb tangle What I'm aiming for is the case where you have lots of code blocks interspersed with written language... and want them to accumulate under a single identifier. I will keep digging. On Wed, Mar 5, 2014 at 3:39 PM, Thomas S. Dye t...@tsdye.com wrote: Aloha Grant, I'm not certain what you're after. From the Org mode manual: * outline header :PROPERTIES: :header-args::cache yes :END: Perhaps :header-args: :tangle myfile.el All the best, Tom Grant Rettke g...@wisdomandwonder.com writes: Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson Hi, My goal is to intersperse code blocks with comments about them like this: == Menu bars are not required [fn:38] #+NAME: uxo-decision1 #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+NAME: uxo-decision2 #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == And replace it with something like this: == *** Setup :PROPERTY: :name: uxo-decision :END Menu bars are not required [fn:38] #+BEGIN_SRC emacs-lisp (menu-bar-mode 0) #+END_SRC Don't need auto-save #+BEGIN_SRC emacs-lisp (disable-auto-save) #+END_SRC == Basically I'm going through a config file and want write a lot but to be able to refer to all of the snippets as a single ended and tangle them accordingly. What is the right way to do this? My apologies for having to ask this; for some bizarre reason I am not finding the example to do this though I know I have read it. Regards, -- Thomas S. Dye http://www.tsdye.com -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson
Re: [O] How to collect multiple source blocks with the same name at the same level
Hi Grant, I think you can do this with the noweb-ref property/header arg. There’s an example very similar (if not identical) to your use case in the info manual, node “(org) noweb-ref” -- Aaron Ecay
Re: [O] How to collect multiple source blocks with the same name at the same level
Aha, I see you found it too. I should run fetchmail more frequently...sorry for the noise. 2014ko martxoak 5an, Aaron Ecay-ek idatzi zuen: Hi Grant, I think you can do this with the noweb-ref property/header arg. There’s an example very similar (if not identical) to your use case in the info manual, node “(org) noweb-ref” -- Aaron Ecay -- Aaron Ecay
Re: [O] How to collect multiple source blocks with the same name at the same level
Thanks Aaron: http://orgmode.org/manual/noweb_002dref.html On Wed, Mar 5, 2014 at 4:41 PM, Aaron Ecay aarone...@gmail.com wrote: Hi Grant, I think you can do this with the noweb-ref property/header arg. There’s an example very similar (if not identical) to your use case in the info manual, node “(org) noweb-ref” -- Aaron Ecay -- Grant Rettke | ACM, AMA, COG, IEEE 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 seriously.” --Thompson
[O] column-mode can not do an estimate effort summation on day/week modifiers
Hello,
I'm creating a new org file today and I'm using work estimates that use
day(d) and week(w) modifiers. Specifically, I have the following defined:
#+PROPERTY: Effort_ALL 0 1:00 4:00 1d 2d 1w 2w
#+COLUMNS: %40ITEM(Task) %17Effort(Estimated Effort){:} %CLOCKSUM
The problem I'm having is with column-mode and the estimate effort sum. It
appears that the normal effort summation wants purely HH:MM formatted work
estimates. I spent some time trying to understand that part of the code but
some of those column functions are pretty big (read: I'm a semi-literate
elisper). I did come up with the following to define my own summary-type :d
#+begin_src elisp
(add-to-list 'org-columns-compile-map
'(:d add_duration
(lambda (rest x) (apply '+ (mapcar
'org-duration-string-to-minutes (mapcar 'prin1-to-string x) t)
#+end_src
First version wasn't using the prin1-to-string and I noticed
org-duration-string-to-minutes was being passing only the integer part of
a 1d work effort. Adding the prin1-to-string processing merely made it
not error anymore but still isn't doing what I'd like.
Is there a way to get the entire work effort passed to my function? Or a
better suggestion?
Thanks,
--
Jon Miller
Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
On Tue, Mar 4, 2014 at 3:45 PM, Simon Thum simon.t...@gmx.de wrote: This seems to be a question of objective. Do you want to encode, i.e. maintain some reversible original in an url no matter what, or do you want to fix url's which wouldn't otherwise be legal? In the latter case, the question mark should probably be retained. I believe the former. If the user types in a working link, the exporter shouldn't break it. This could be fixed by sprinkling org-url-decode through various backends, but that suggests to me that the problem may be upstream. Michael
[O] Odd interaction with Python sessions and Org 8.2.5
Hi, I'm having trouble getting clean output from org 8.2.5 when I combine session based evaluation and capturing results from standard out. (See first example below) This is on Emacs 24.3 with the default python mode settings and nothing relevant in my init.el except for activating python support. Is this expected behavior or is there someway I can fix the first example? Michael -8---8 #+TITLE: Hello World * Standard Out + Session (Problem) #+BEGIN_SRC python :results output :session *Python* def test(): print Hello World test() #+END_SRC #+RESULTS: : : ... Hello World * Standard Out + No Session (Fine) #+BEGIN_SRC python :results output def test(): print Hello World test() #+END_SRC #+RESULTS: : Hello World * Value + Session #+BEGIN_SRC python :session *Python* def test(): print Hello World test() #+END_SRC #+RESULTS: * Value + No Session #+BEGIN_SRC python def test(): print Hello World test() #+END_SRC #+RESULTS: : None
[O] Bug: Org-agenda-files replaces directories with explicit filenames [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/sindikat/.emacs.d/elpa/org-20140303/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. I have a directory tasks/ in org-agenda-files variable. When i add a file to org-agenda-files variable through C-c [ command (org-agenda-file-to-front), the directory path is replaced by paths of the files, that are currently in that directory. It is bad, because when i add some files to tasks/ later on, they will not contribute to my agenda. This question was also posted on StackOverflow: http://stackoverflow.com/questions/10569746/org-agenda-files-replaces-directories-with-explicit-filenames Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.6) of 2013-12-23 on brahms, modified by Debian Package: Org-mode version 8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/sindikat/.emacs.d/elpa/org-20140303/)
