[O] [PATCH] [need test]Restruct `org-create-formula-image' function
`org-create-formula-image-with-dvipng' and `org-create-formula-image-with-imagemagick' share a good deal of logic, so combine them to a function. 0001-Restruct-org-create-formula-image-function.patch Description: Binary data
Re: [O] process diagrams with dot and some glue using org
Rick Frankel r...@rickster.com writes:
[...]
I (sort of) disagree. I think specifying required arguments as header
vars makes the calling requirements clearer. Perhaps:
#+HEADER: :var nodes='() graph='()
would be better...
rick
For Karl's benefit, the following is the latest version of the
graph-from-tables source code block including the above suggestion from
Rick and also the addition of an options variable.
#+begin_src org
,#+name: graph-from-tables
,#+header: :var options= :var nodes='() graph='()
,#+BEGIN_SRC emacs-lisp :colnames yes
(org-babel-execute:dot
(concat
digraph {\n
options \n ;; //rankdir=LR;\n ;; remove comment characters '//'
for horizontal layout; add for vertical layout
(mapconcat
(lambda (x)
(format %s [label=\%s\ shape=%s style=\filled\
fillcolor=\%s\]
(car x)
(nth 1 x)
(if (string= (nth 2 x)) box (nth 2 x))
(if (string= (nth 3 x)) none (nth 3 x))
)) nodes \n)
\n
(mapconcat
(lambda (x)
(format %s - %s [taillabel=\%s\]
(car x) (nth 1 x) (nth 2 x))) graph \n)
}\n) params)
,#+END_SRC
#+end_src
I can update the tutorial on Worg if desired.
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.6-341-g338603
Re: [O] elpa's copy of org-version.el
Pierre Téchoueyres writes: Melpa provides an org-mode from GIT too. Look like this version is buggy. It's completely bogus, indeed. It was added on July 15, but they can't have tested it. Stay away at least from this part of Melpa… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Simplifying the weekly agenda a tiny bit, howto?
Hi, François Pinard pin...@iro.umontreal.ca writes: There are a pile of commands for shifting timestamps/scheduled/deadline Which I often use. The annoyance of doing explicit shifting is that I have to look at the repeater to decide the shifting amount. I much prefer if it could be automatic, not requiring human scrutiny each time. What about providing a new command to shift the timestamp with the step being the shifting amount? The command could do exactly the same thing as what is done when you close the repeated TODO task, except for the TODO - DONE - TODO transition. Would that command fulfil your need? -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A pgpsVpY9a9Wwn.pgp Description: PGP signature
Re: [O] koma letter exporter: changing the priority of options
Hi,
Alan Schmitt wrote:
- (format \\KOMAoption{backaddress}{%s}\n (if with-backaddress true
false))
- (format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks
with-foldmarks false))
- (format \\KOMAoption{fromphone}{%s}\n (if with-phone true false))
- (format \\KOMAoption{fromemail}{%s}\n (if with-email true
false
+ (if with-backaddress (format \\KOMAoption{backaddress}{true}\n) )
+ (if (not (equal with-foldmarks true)) (format
\\KOMAoption{foldmarks}{%s}\n with-foldmarks) )
+ (if with-phone (format \\KOMAoption{fromphone}{true}\n) )
+ (if with-email (format \\KOMAoption{fromemail}{true}\n) )))
If I read the patch correctly then the consequence is that you cannot
configure your LCO file to set defaults for these values and inhibit
them in specific letters by setting the corresponding option to nil. For
example, in my LCO file I enable all of these options but sometimes I
don't want to have foldmarks or a backaddress or whatever. So I can
write #+OPTIONS: backaddress:nil and it is supressed. The patch changes
that.
I did some experiments and it seems that by default foldmarks is
true. The idea behind the patch is that, if we don't change the default
values, then things are not output. Let me know if this is fine with you
and I'll commit this. (I'll also edit the work with the new default
values.)
I still have an issue with the default value for email. I have set-up my
email address in emacs, and it's picked up by the koma exporter. I want
to use a different address in my work letters (which use a custom lco
file), but the email address is overridden by the one picked up by the
following function:
(defun org-koma-letter-email ()
Return the current `user-mail-address'
user-mail-address)
What I propose is the following:
- we leave the default AUTHOR and EMAIL at nil
- if they are still nil, we output the default values _before_ inputting
the lco file
- if they are no longer nil, we output their values _after_ inputting
the lco file
This way, if they are not defined in the file, then the lco can override
them, otherwise the local option will be the one used.
What do you think?
Seems fine by me.
Cheers,
Viktor
Alan
Re: [O] koma letter exporter: changing the priority of options
Hi, Rasmus wrote: I think we need to treat koma variables more generally (I have some sketches locally) if anything. Not make their behavior more specialized. Could you elaborate on what you mean by this? But you'd still end up with two emails in your file, and if you lost the LCO file the other email would still be there. That is a valid criticism. I'd rather not have data specified in the TeX file that is overwritten later on. However, if you lose the LCO file, presumably you can't regenerate the lettern anyway. I slightly less mind-boggling approach would be to replace the default function with one that (1) fetches the LCO values from the file (but what if they are remote?); (2) obtains the path via kpsewhich (run from the current dir); (3) run grep on each of these files with some intelligent keyword. The only hard part is (1) and (2) and (3) are almost foolproof. That approach, in my view, seems overly complicated and also very brittle. Cheers, Viktor –Rasmus -- ツ
Re: [O] process diagrams with dot and some glue using org
On Sat, Jul 20, 2013 at 12:02:18PM +0100, Eric S Fraga wrote:
[...]
For Karl's benefit, the following is the latest version of the
graph-from-tables source code block including the above suggestion from
Rick and also the addition of an options variable.
#+begin_src org
,#+name: graph-from-tables
,#+header: :var options= :var nodes='() graph='()
nit. the extra `:var' isn't necessary:
#+header: :var options= nodes='() graph='()
,#+BEGIN_SRC emacs-lisp :colnames yes
(org-babel-execute:dot
(concat
digraph {\n
options \n ;; //rankdir=LR;\n ;; remove comment characters
'//' for horizontal layout; add for vertical layout
(mapconcat
(lambda (x)
(format %s [label=\%s\ shape=%s style=\filled\
fillcolor=\%s\]
(car x)
(nth 1 x)
(if (string= (nth 2 x)) box (nth 2 x))
(if (string= (nth 3 x)) none (nth 3 x))
)) nodes \n)
\n
(mapconcat
(lambda (x)
(format %s - %s [taillabel=\%s\]
(car x) (nth 1 x) (nth 2 x))) graph \n)
}\n) params)
,#+END_SRC
#+end_src
I can update the tutorial on Worg if desired.
Re: [O] koma letter exporter: changing the priority of options
Hi Viktor and Allan, I think we need to treat koma variables more generally (I have some sketches locally) if anything. Not make their behavior more specialized. Could you elaborate on what you mean by this? I want to be able to generate and set /any/ Koma variable from emacs, including making my own ones. Sometimes I use custom koma variables depending on the letter and my footer then looks for the values of the koma variables and typeset the footer depending on which variables are available. As half of current template sets koma variables, this seems like something worthwhile doing. I have a defun to set an arbitrary koma variables, but I haven't looked more into it. But you'd still end up with two emails in your file, and if you lost the LCO file the other email would still be there. That is a valid criticism. I'd rather not have data specified in the TeX file that is overwritten later on. However, if you lose the LCO file, presumably you can't regenerate the lettern anyway. Nah, but you still wrong data in your template. I slightly less mind-boggling approach would be to replace the default function with one that (1) fetches the LCO values from the file (but what if they are remote?); (2) obtains the path via kpsewhich (run from the current dir); (3) run grep on each of these files with some intelligent keyword. The only hard part is (1) and (2) and (3) are almost foolproof. That approach, in my view, seems overly complicated and also very brittle. I not advocating for its inclusion as a general solution(!), but as a specific solution in the case where you don't want to set the user email to nil, but still want to use it some of the time. It's brittle to the extend that Texlive is brittle. Kpsewhich should find the files (running from the same folder) if latex can find them. Making the /location/ of a variable /in the output/ a function of whether it's one value or the other is an ugly hack IMO. (Same as the above, but the above you can keep in your own config file). If we want to go down that path a better way is to let the user decide on the relative importance of variables versus LCO files. 1. To let the placement of koma variables and lco files be configurable via special [BRACKET] keywords as in org-latex-class. 2. To let the preamble be blocks, as with the end material (ps cc encl), and let users deceit the way they want material to come. E.g. if some variable is '(komavars lco) then lco is typeset before komavars. –Rasmus -- Dung makes an excellent fertilizer
Re: [O] [PATCH] [need test]Restruct `org-create-formula-image' function
feng shu tuma...@gmail.com writes: `org-create-formula-image-with-dvipng' and `org-create-formula-image-with-imagemagick' share a good deal of logic, so combine them to a function. I have wondered aloud in the past whether it is necessary to have two methods for this. They are pretty much equivalent although the imagemagick method is IMO slightly less brittle than the dvipng method. So instead of spending time to tie them even more closely together, we should investigate whether one of them should go. Maybe we can have a poll... -- Nick
Re: [O] [babel] feature request: debug messages
Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Hi Andreas, This should be easy to turn on or off using the newly introduced :prologue and :epilogue header arguments. See the manual and the following example. #+Title: debug messages #+Property: session *R* #+Property: prologue (format print(\entering %s\) (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x - 2 + 2 #+end_src #+name: block-2 #+begin_src R y - x + x #+end_src Execute the whole buffer =C-c C-v b= to see the prologue in action. Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I would love to see messages like 'entering block foo...' and '...leaving block foo' printed to my R console. This would be very handy when I evaluate a subtree (C-c C-v s) with a lot of #+call lines and some lengthy ones. I know that (1) I could implement that myself at in the source blocks. But I would love if orgmode did that for me (2) Such messages are already printed to the emacs *Messages* buffer. But that buffer might not be visible and I can not switch to it, without interrupting the evaluation. Anyway it would be much nicer to see that output together with the other output, that my code generates. In essence it would be very helpful, if there was a variable org-babel-print-debug-messages (or org-babel-debug-level...) which if non-nil would cause that messages to be printed. Or is there somewhere already? Regards, Andreas thanks for the quick answer! The :prologue and :epilogue header arguments have indeed slipped my attention and they look really interesting! I see, that they are documented, but somehow, they seem to not get their headline and TOC entry? I have three problems with your example, though: 1) It does not run 2) It does not work 3) It won't be usable for 'my' epilogue, correct? ;-) Ah! My fault. I had to add prologue and epilogue support to ob-R.el when working through the example I sent, but then I forgot to commit that support to Org-mode. I've just pushed up that commit, and re-worked my example file to avoid the issue of prologue being applied to the emacs-lisp code block (using the very nice and also new language-specific PROPERTY header arguments). Finally, I don't use epilogues in the example because (as the last thing evaluated) they would override the code block results. Hopefully the following: 1. will run 2. will work 3. will be usable Cheers, #+Title: debug messages #+Property: header-args:R :session *R* :prologue (format print(\entering %s\) (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp :results silent (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x - 2 + 2 #+end_src #+RESULTS: block-1 : 4 #+name: block-2 #+begin_src R y - x + x #+end_src #+RESULTS: block-2 : 8 Execute the whole buffer =C-c C-v b= to see the prologue in action. 1) It does not run, because org tries to do the prologue also on the emacs-lisp block defining the function of the prologue. So, I get format: Symbol's function definition is void: get-current-name I changed the #+property line to #+Property: header-args:R :prologue (format print(\entering %s\) (get-current-name)) which solved that problem. 2) But still it does not work: This is what I get in my *R* buffer: --8---cut here---start-8--- R version 3.0.1 (2013-05-16) -- Good Sport Copyright (C) 2013 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R ist freie Software und kommt OHNE JEGLICHE GARANTIE. Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. Tippen Sie 'license()' or 'licence()' für Details dazu. R ist ein Gemeinschaftsprojekt mit vielen Beitragenden. Tippen Sie 'contributors()' für mehr Information und 'citation()', um zu erfahren, wie R oder R packages in Publikationen zitiert werden können. Tippen Sie 'demo()' für einige Demos, 'help()' für on-line Hilfe, oder
Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer
Øyvind Stegard oyvi...@ifi.uio.no writes: Daimrod daim...@gmail.com writes: [...] Thanks for the bug report! Don't you think that checking if one of the buffer would be enough and faster? With something like (every #'get-file-buffer org-contacts-files) Hi, I thought about that, yes. But what about when an org-contacts buffer is killed and subsequently re-opened (like using `find-alternate-file' with same file name). Then the buffer will exist for the file, but it will be a new instance, and the markers in org-contacts-db will still be dead. That's why I decided to just check the markers instead. You're right, good catch! I've installed the patch and haven't felt any slowdown, but I've a small contacts file. If people complain about slowdown we could add a buffer local hook to ask before killing contacts files. Regards, Øyvind -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [babel] feature request: debug messages
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Hi Andreas, This should be easy to turn on or off using the newly introduced :prologue and :epilogue header arguments. See the manual and the following example. #+Title: debug messages #+Property: session *R* #+Property: prologue (format print(\entering %s\) (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x - 2 + 2 #+end_src #+name: block-2 #+begin_src R y - x + x #+end_src Execute the whole buffer =C-c C-v b= to see the prologue in action. Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I would love to see messages like 'entering block foo...' and '...leaving block foo' printed to my R console. This would be very handy when I evaluate a subtree (C-c C-v s) with a lot of #+call lines and some lengthy ones. I know that (1) I could implement that myself at in the source blocks. But I would love if orgmode did that for me (2) Such messages are already printed to the emacs *Messages* buffer. But that buffer might not be visible and I can not switch to it, without interrupting the evaluation. Anyway it would be much nicer to see that output together with the other output, that my code generates. In essence it would be very helpful, if there was a variable org-babel-print-debug-messages (or org-babel-debug-level...) which if non-nil would cause that messages to be printed. Or is there somewhere already? Regards, Andreas thanks for the quick answer! The :prologue and :epilogue header arguments have indeed slipped my attention and they look really interesting! I see, that they are documented, but somehow, they seem to not get their headline and TOC entry? I have three problems with your example, though: 1) It does not run 2) It does not work 3) It won't be usable for 'my' epilogue, correct? ;-) Ah! My fault. I had to add prologue and epilogue support to ob-R.el when working through the example I sent, but then I forgot to commit that support to Org-mode. I've just pushed up that commit, and re-worked my example file to avoid the issue of prologue being applied to the emacs-lisp code block (using the very nice and also new language-specific PROPERTY header arguments). Finally, I don't use epilogues in the example because (as the last thing evaluated) they would override the code block results. Hopefully the following: 1. will run 2. will work 3. will be usable Cheers, #+Title: debug messages #+Property: header-args:R :session *R* :prologue (format print(\entering %s\) (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp :results silent (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x - 2 + 2 #+end_src #+RESULTS: block-1 : 4 #+name: block-2 #+begin_src R y - x + x #+end_src #+RESULTS: block-2 : 8 Execute the whole buffer =C-c C-v b= to see the prologue in action. 1) It does not run, because org tries to do the prologue also on the emacs-lisp block defining the function of the prologue. So, I get format: Symbol's function definition is void: get-current-name I changed the #+property line to #+Property: header-args:R :prologue (format print(\entering %s\) (get-current-name)) which solved that problem. 2) But still it does not work: This is what I get in my *R* buffer: --8---cut here---start-8--- R version 3.0.1 (2013-05-16) -- Good Sport Copyright (C) 2013 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R ist freie Software und kommt OHNE JEGLICHE GARANTIE. Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. Tippen Sie 'license()' or 'licence()' für Details dazu. R ist ein Gemeinschaftsprojekt mit vielen Beitragenden. Tippen Sie 'contributors()' für mehr Information und 'citation()', um zu erfahren, wie R oder R packages in Publikationen zitiert werden können. Tippen Sie
Re: [O] [babel] feature request: debug messages
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Hi Andreas, This should be easy to turn on or off using the newly introduced :prologue and :epilogue header arguments. See the manual and the following example. #+Title: debug messages #+Property: session *R* #+Property: prologue (format print(\entering %s\) (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x - 2 + 2 #+end_src #+name: block-2 #+begin_src R y - x + x #+end_src Execute the whole buffer =C-c C-v b= to see the prologue in action. Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I would love to see messages like 'entering block foo...' and '...leaving block foo' printed to my R console. This would be very handy when I evaluate a subtree (C-c C-v s) with a lot of #+call lines and some lengthy ones. I know that (1) I could implement that myself at in the source blocks. But I would love if orgmode did that for me (2) Such messages are already printed to the emacs *Messages* buffer. But that buffer might not be visible and I can not switch to it, without interrupting the evaluation. Anyway it would be much nicer to see that output together with the other output, that my code generates. In essence it would be very helpful, if there was a variable org-babel-print-debug-messages (or org-babel-debug-level...) which if non-nil would cause that messages to be printed. Or is there somewhere already? Regards, Andreas thanks for the quick answer! The :prologue and :epilogue header arguments have indeed slipped my attention and they look really interesting! I see, that they are documented, but somehow, they seem to not get their headline and TOC entry? I have three problems with your example, though: 1) It does not run 2) It does not work 3) It won't be usable for 'my' epilogue, correct? ;-) Ah! My fault. I had to add prologue and epilogue support to ob-R.el when working through the example I sent, but then I forgot to commit that support to Org-mode. I've just pushed up that commit, and re-worked my example file to avoid the issue of prologue being applied to the emacs-lisp code block (using the very nice and also new language-specific PROPERTY header arguments). Finally, I don't use epilogues in the example because (as the last thing evaluated) they would override the code block results. Hopefully the following: 1. will run 2. will work 3. will be usable Cheers, #+Title: debug messages #+Property: header-args:R :session *R* :prologue (format print(\entering %s\) (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp :results silent (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x - 2 + 2 #+end_src #+RESULTS: block-1 : 4 #+name: block-2 #+begin_src R y - x + x #+end_src #+RESULTS: block-2 : 8 Execute the whole buffer =C-c C-v b= to see the prologue in action. 1) It does not run, because org tries to do the prologue also on the emacs-lisp block defining the function of the prologue. So, I get format: Symbol's function definition is void: get-current-name I changed the #+property line to #+Property: header-args:R :prologue (format print(\entering %s\) (get-current-name)) which solved that problem. 2) But still it does not work: This is what I get in my *R* buffer: --8---cut here---start-8--- R version 3.0.1 (2013-05-16) -- Good Sport Copyright (C) 2013 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R ist freie Software und kommt OHNE JEGLICHE GARANTIE. Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. Tippen Sie 'license()' or 'licence()' für Details dazu. R ist ein Gemeinschaftsprojekt mit vielen Beitragenden. Tippen Sie 'contributors()' für mehr Information und 'citation()', um zu erfahren, wie R oder R packages in
Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer
Daimrod daim...@gmail.com writes: [...] You're right, good catch! I've installed the patch and haven't felt any slowdown, but I've a small contacts file. If people complain about slowdown we could add a buffer local hook to ask before killing contacts files. If speed turns out to be an issue, then simply caching references to the contact buffers and validating those references with `buffer-live-p' should be quicker and just as reliable. (Checking markers was just a quick solution on my part that did not require changes to any data structures.) Øyvind -- Øyvind Stegard http://stegard.net/
[O] Agenda Search and org-agenda-text-search-extra-files
Hello, I have some questions concerning the search function in org-mode: (1) I have several files in listed in the variable /org-agenda-text-search-extra-files/. At lease one file is definitely not searched using /org-agenda-search-view/. It is an ordinary org file: --8 #+DATE: [2013-07-05 Di 09:10] #+CATEGORY: #+TAGS: #+DESCRIPTION: #+TITLE: Man kann nicht nicht zitieren - Ein Sammelsurium Some Text here. Some more Text here... --8 I have now idea why the search function skips that file. Can anyone give a hint? Using /org-occur/ the file will be searched like any other listed in /org-agenda-text-search-extra-files/. (2) I also tried to set up the org-agenda-text-search-extra-files using an expression I found on the mailing list [1]; it would be easier if I had not to manually extend the variable any time a new file is added. --8 (directory-files ~/directory t ^[^.#].*\\.\\(org$\\|org_archive$\\)) --8 I tried different versions because I was not sure how to interpret the example, e.g.: --8 '(org-agenda-text-search-extra-files (quote ( (directory-files ~/org t ^[^.#].*\\.\\(org$\\|org_archive$\\)) ))) and '(org-agenda-text-search-extra-files (quote ( (~/org t ^[^.#].*\\.\\(org$\\|org_archive$\\)) ))) and '(org-agenda-text-search-extra-files (quote ( (~/org/ t ^[^.#].*\\.\\(org$\\|org_archive$\\)) ))) but after committing a search org-mode tells me that /org or /org/ ist not an org-file (which is obviously true and tells me that the directory and the regex is not concatenated, but how should it look?) Many thanks for pointers to the right direction! Thanks Martin -- [1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00267.html -- ~~ | G. Martin Butz | m.b...@hfk-bremen.de | www.mkblog.org | ~~
[O] bug#14910: org-mode `org-open-at-point' doesn't follow id links
Hi Oleh, Oleh oleh.kre...@gmail.com writes: As the subject says. This bug is fixed in upstream Org. You can either install Org separately or wait for the next stable version to be merged in Emacs. Thanks, -- Bastien
Re: [O] elpa's copy of org-version.el
Pierre Téchoueyres pierre.techoueyres at free.fr writes: Ok I've found *my* mistake : Melpa provides an org-mode from GIT too. Look like this version is buggy. Thanks for your help with this, but I'm still not entirely sure what I should do. Are you saying that when I install org via elpa I should _not_ install this one: org 20130720 installed Outline-based notes management and organizer [git] because it's from git? Should I be looking for an org installation from github? I can't see one in my package list. Should I uninstall my broken org, disable melpa to try again to install org from elpa? Thanks
Re: [O] elpa's copy of org-version.el
Hello Paul, Here is what I've done : 1) check you've the org-elpa repository configured : my package-archives has this value ((gnu . http://elpa.gnu.org/packages/;) (marmalade . http://marmalade-repo.org/packages/;) (melpa . http://melpa.milkbox.net/packages/;) (org-elpa . http://orgmode.org/elpa/;)) 2) install melpa package from melpa (special handling for the MELPA repository [github]) 3) exclude org from melpa by adding / customize var package-archive- exclude-alist. Mine has this value '((melpa org)) this is explained on melpa home page in customization section (near http://melpa.milkbox.net/#installing). 4) uninstall org-2013... 5) exit emacs then install org-20130715 (you should only see a version like mmdd and no longer see a version with mmdd_hhmm) Hope this could help Pierre Le samedi 20 juillet 2013 16:52:10 Paul Stansell a écrit : Pierre Téchoueyres pierre.techoueyres at free.fr writes: Ok I've found *my* mistake : Melpa provides an org-mode from GIT too. Look like this version is buggy. Thanks for your help with this, but I'm still not entirely sure what I should do. Are you saying that when I install org via elpa I should _not_ install this one: org 20130720 installed Outline-based notes management and organizer [git] because it's from git? Should I be looking for an org installation from github? I can't see one in my package list. Should I uninstall my broken org, disable melpa to try again to install org from elpa? Thanks
Re: [O] elpa's copy of org-version.el
Yes, that is helpful. Thanks very much!
[O] org-version.el missing in elpa/org-20130720.1353
Updated elpa today and found out org-version.el was missing in elpa/org-20130720.1353 -- Rene
Re: [O] [PATCH] [need test]Restruct `org-create-formula-image' function
Nick Dokos ndo...@gmail.com writes: feng shu tuma...@gmail.com writes: `org-create-formula-image-with-dvipng' and `org-create-formula-image-with-imagemagick' share a good deal of logic, so combine them to a function. I have wondered aloud in the past whether it is necessary to have two methods for this. They are pretty much equivalent although the imagemagick method is IMO slightly less brittle than the dvipng method. So instead of spending time to tie them even more closely together, we should investigate whether one of them should go. Maybe we can have a poll... imagemagick method is useful for xelatex users, but it compile a snippet more slower than dvipng method. We don't need remove one of them. we can do like this: 1. conbine tex:dvipng and tex:imagemagick to tex:image 2. remove `org-latex-create-formula-image-program' 3. defcustom `org-create-formula-image-processes' in my patch. 4. update document. It is very similar `org-latex-pdf-process' --
