Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Hi Thorsten, Thorsten Jolitz writes: > Hi List, > > evaluating this 3 times does not work as expected: > > , > | * A > | > | #+header: :results raw replace > | #+begin_src emacs-lisp > | (+ 2 2) > | #+end_src > | > | #+results: > | 4 > | 4 > | 4 > ` > > Independent from argument order, 'replace' (which should be default > anyway) is ignored. Try adding the :wrap, which works for me: , | * A | | #+header: :results raw replace :wrap | #+begin_src emacs-lisp | (+ 2 2) | #+end_src | | #+results: | #+BEGIN_RESULTS | 4 | #+END_RESULTS ` Regards, Andreas
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Andreas Leha writes: > Hi Thorsten, > > Thorsten Jolitz writes: > >> Hi List, >> >> evaluating this 3 times does not work as expected: >> >> , >> | * A >> | >> | #+header: :results raw replace >> | #+begin_src emacs-lisp >> | (+ 2 2) >> | #+end_src >> | >> | #+results: >> | 4 >> | 4 >> | 4 >> ` >> >> Independent from argument order, 'replace' (which should be default >> anyway) is ignored. > > > Try adding the :wrap, which works for me: > > , > | * A > | > | #+header: :results raw replace :wrap > | #+begin_src emacs-lisp > | (+ 2 2) > | #+end_src > | > | #+results: > | #+BEGIN_RESULTS > | 4 > | #+END_RESULTS > ` This actually works here too, thanks. But is this wrapping results block 'neutral', i.e. is its content treated just like raw Org syntax in all situations? E.g. when I create a dblock from elisp, would #+results: #+BEGIN_RESULTS #+begin my-dblock (foo) #+end #+END_RESULTS be equivalent to #+results: #+begin my-dblock (foo) #+end in all cases? However, the combo ':results raw replace' seems like the natural fit when programmatically creating content in an Org file with a src_block that might eventually be evaluated more than once. That it does not work 'as-is' seems too much of a surprise to not call it a bug (at least when the manual does not mention it as special case). -- cheers, Thorsten
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Thorsten Jolitz writes: > Andreas Leha writes: > >> Hi Thorsten, >> >> Thorsten Jolitz writes: >> >>> Hi List, >>> >>> evaluating this 3 times does not work as expected: >>> >>> , >>> | * A >>> | >>> | #+header: :results raw replace >>> | #+begin_src emacs-lisp >>> | (+ 2 2) >>> | #+end_src >>> | >>> | #+results: >>> | 4 >>> | 4 >>> | 4 >>> ` >>> >>> Independent from argument order, 'replace' (which should be default >>> anyway) is ignored. >> >> >> Try adding the :wrap, which works for me: >> >> , >> | * A >> | >> | #+header: :results raw replace :wrap >> | #+begin_src emacs-lisp >> | (+ 2 2) >> | #+end_src >> | >> | #+results: >> | #+BEGIN_RESULTS >> | 4 >> | #+END_RESULTS >> ` > > This actually works here too, thanks. But is this wrapping results block > 'neutral', i.e. is its content treated just like raw Org syntax in all > situations? E.g. when I create a dblock from elisp, would > > #+results: > #+BEGIN_RESULTS > #+begin my-dblock >(foo) > #+end > #+END_RESULTS > > be equivalent to > > #+results: > #+begin my-dblock >(foo) > #+end > > in all cases? > > However, the combo ':results raw replace' seems like the natural fit > when programmatically creating content in an Org file with a src_block > that might eventually be evaluated more than once. That it does not work > 'as-is' seems too much of a surprise to not call it a bug (at least when > the manual does not mention it as special case). My use-case is actually this, and it won't work with wrapped results: , | ** Utility Function :ARCHIVE: | | #+name: create-subtree-with-dblock | #+header: :var name="foo" | #+header: :var prms=":bar loo" | #+header: :results replace raw | #+begin_src emacs-lisp | (format |(concat "\n\n** Overview :READONLY:\n\n" | "#+begin: %s %s\n\n#+end:\n") | name prms) | #+end_src | | #+results: dblock | | | ** Overview :READONLY: | | #+begin: foo :bar loo | | #+end: ` -- cheers, Thorsten
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Hi Thorsten, Thorsten Jolitz writes: > Thorsten Jolitz writes: > >> Andreas Leha writes: >> >>> Hi Thorsten, >>> >>> Thorsten Jolitz writes: >>> Hi List, evaluating this 3 times does not work as expected: , | * A | | #+header: :results raw replace | #+begin_src emacs-lisp | (+ 2 2) | #+end_src | | #+results: | 4 | 4 | 4 ` Independent from argument order, 'replace' (which should be default anyway) is ignored. >>> >>> >>> Try adding the :wrap, which works for me: >>> >>> , >>> | * A >>> | >>> | #+header: :results raw replace :wrap >>> | #+begin_src emacs-lisp >>> | (+ 2 2) >>> | #+end_src >>> | >>> | #+results: >>> | #+BEGIN_RESULTS >>> | 4 >>> | #+END_RESULTS >>> ` >> >> This actually works here too, thanks. But is this wrapping results block >> 'neutral', i.e. is its content treated just like raw Org syntax in all >> situations? E.g. when I create a dblock from elisp, would >> >> #+results: >> #+BEGIN_RESULTS >> #+begin my-dblock >>(foo) >> #+end >> #+END_RESULTS >> >> be equivalent to >> >> #+results: >> #+begin my-dblock >>(foo) >> #+end >> >> in all cases? >> >> However, the combo ':results raw replace' seems like the natural fit >> when programmatically creating content in an Org file with a src_block >> that might eventually be evaluated more than once. That it does not work >> 'as-is' seems too much of a surprise to not call it a bug (at least when >> the manual does not mention it as special case). > > My use-case is actually this, and it won't work with wrapped results: > > , > | ** Utility Function :ARCHIVE: > | > | #+name: create-subtree-with-dblock > | #+header: :var name="foo" > | #+header: :var prms=":bar loo" > | #+header: :results replace raw > | #+begin_src emacs-lisp > | (format > |(concat "\n\n** Overview :READONLY:\n\n" > | "#+begin: %s %s\n\n#+end:\n") > | name prms) > | #+end_src > | > | #+results: dblock > | > | > | ** Overview :READONLY: > | > | #+begin: foo :bar loo > | > | #+end: > ` I am not in the position to answer this. But the combo "raw replace" is problematic, I think, in that it is hard to say how much there is to be replaced. So I think some delimiters (as produced by :wrap) are necesarry in the general case. If I understand correctly, you want to nest blocks: A source block nested in a results block. I think, that is not possible. So, for that use case, I guess, another construct (other than results block) would be necessary. But other people might have the proper answer here... Regards, Andreas
Re: [O] Indentation messed up after example block
On 2014-07-06 20:03 York Zhao wrote: > Hi list, > > I just noticed a problem that org-mode indentation gets messed up after > "example" block. Here is ECM: > > #+STARTUP: indent > > * Level one > ** Level two > Indentation is right. > > #+BEGIN_EXAMPLE > * Example at level one > #+END_EXAMPLE > > Indentation is wrong. The asterisk followed by a space followed by text in your example block is recognized by org as a headline. So org thinks everything under that headline is the body of the headline. You can fix this by not letting "* Example at level one" start at the beginning of the line, but instead indent it by one or more spaces or prefix it with some other character(s). HTH, -- Alexander Baier
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Andreas Leha writes: > Hi Thorsten, >> My use-case is actually this, and it won't work with wrapped results: >> >> , >> | ** Utility Function :ARCHIVE: >> | >> | #+name: create-subtree-with-dblock >> | #+header: :var name="foo" >> | #+header: :var prms=":bar loo" >> | #+header: :results replace raw >> | #+begin_src emacs-lisp >> | (format >> |(concat "\n\n** Overview :READONLY:\n\n" >> | "#+begin: %s %s\n\n#+end:\n") >> |name prms) >> | #+end_src >> | >> | #+results: dblock >> | >> | >> | ** Overview :READONLY: >> | >> | #+begin: foo :bar loo >> | >> | #+end: >> ` > > > I am not in the position to answer this. But the combo "raw replace" is > problematic, I think, in that it is hard to say how much there is to be > replaced. So I think some delimiters (as produced by :wrap) are > necesarry in the general case. I really don't want to dig into the Org Babel internals here, but that might well be the reason, since inserting multi-line raw Org syntax into the buffer makes it hard to tell whats new and whats old without some extra work/bookkeeping (doing a diff or so ...). > If I understand correctly, you want to nest blocks: A source block > nested in a results block. I think, that is not possible. So, for that > use case, I guess, another construct (other than results block) would be > necessary. Is a single , | #+results: dblock ` line seen as block (together will the following results)? Would surprise me, but I don't know. I don't want to nest blocks, I want to insert plain raw Org syntax into the buffer that is subsequently treated just like the other content I typed in by hand before (assuming the the leading #+results: line does not affect the contents usual interpretation). Maybe I'm bending Org-modes flexibility a bit too much here, but this is my real-world use-case. -- cheers, Thorsten
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Thorsten Jolitz writes: >> If you give the source code block a name, it should work as expected. > > Not over here - does it work for you? No. Sorry for the noise. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Thorsten Jolitz writes: > Hi List, > > evaluating this 3 times does not work as expected: > > , > | * A > | > | #+header: :results raw replace > | #+begin_src emacs-lisp > | (+ 2 2) > | #+end_src > | > | #+results: > | 4 > | 4 > | 4 > ` > > Independent from argument order, 'replace' (which should be default > anyway) is ignored. Right - `raw' inserts results without delimiters so org has no idea where they end and cannot delete them (try org-babel-remove-result) or replace them. -- Nick
Re: [O] org-mode date stamp with just month?
That property then is something that we may set as a buffer local
variable set in the file itself for cases where want only months in
the entire file?
How might we get that form for only parts of a file in which the rest
of that file we want the standard date format?
Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
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
On Sun, Jul 6, 2014 at 7:05 PM, Thorsten Jolitz wrote:
> David Rogoff writes:
>
>> I can’t see how to insert a datestamp with just year and month. I’m
>> adding an archive of various past events that I don’t have the exact
>> date for.
>
> Maybe try
>
> ,[ C-h v org-time-stamp-custom-formats RET ]
> | org-time-stamp-custom-formats is a variable defined in `org.el'.
> | Its value is ("<%m/%d/%y %a>" . "<%m/%d/%y %a %H:%M>")
> |
> | Documentation:
> | Custom formats for time stamps. See `format-time-string' for the syntax.
> | These are overlaid over the default ISO format if the variable
> | `org-display-custom-times' is set. Time like %H:%M should be at the
> | end of the second format. The custom formats are also honored by export
> | commands, if custom time display is turned on at the time of export.
> |
> | You can customize this variable.
> |
> | [back]
> `
>
> --
> cheers,
> Thorsten
>
>
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
It sounds like you wanted the same thing that I did. What I wanted is something like running 'script' before starting a REPL and just capturing the output and that is it. That output is not being used to be inserted back into the document or anything... it just captured the results of commands sent into the REPL. I tried a lot of different combinations until I felt like my goal was simple: 1. Wrap the output. 2. Put the output in a "sh" type result, something from the shell 3. Let replace work This is what was the best: , | #+PROPERTY: header-args+:results output scalar pp replace ` Grant Rettke | ACM, ASA, FSF, IEEE, SIAM 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 On Mon, Jul 7, 2014 at 8:56 AM, Nick Dokos wrote: > Thorsten Jolitz writes: > >> Hi List, >> >> evaluating this 3 times does not work as expected: >> >> , >> | * A >> | >> | #+header: :results raw replace >> | #+begin_src emacs-lisp >> | (+ 2 2) >> | #+end_src >> | >> | #+results: >> | 4 >> | 4 >> | 4 >> ` >> >> Independent from argument order, 'replace' (which should be default >> anyway) is ignored. > > Right - `raw' inserts results without delimiters so org has no idea > where they end and cannot delete them (try org-babel-remove-result) > or replace them. > -- > Nick > >
Re: [O] still seeing semi-regular lockups
>> + zfill-org-paragraph-boundary 7,240 0% > What is that, if I may ask? That's in my `zfill-mode' based on `refill-mode', and the function is part of the machinery to handle the automatic refilling of org paragraph. > + ac-handle-post-command 2985 56% > + timer-event-handler1786 33% > + redisplay_internal (C function) 131 2% [...] > So I suspected the `auto-complete'. I tried M-x auto-complete to turn it off > which worked, the typing was fast again. M-x auto-complete to turn it back on > and typing became extremely slow again. > Indeed. auto-complete developers may be interested in your report. This is not > an Org bug, though. Yes, it is highly possible to be a bug in `auto-complete' and I will report it to the `auto-complete' developers as soon as I get a bit more time. And I totally understand if you decide not to spend time on this until I can further prove that this is still an org-mode problem. However, I think it might be too early to draw the conclusion at this point that this has nothing to do with org-mode. This is because `auto-complete' started to manifest the problem after doing a bunch of org-mode specific operations, more specifically, after running `org-drlll' on 8 `org-mode' buffers, which suggested the possibility of the leftover side effect introduced by org-mode operations. And the problem could be in `org-drlll', but also very possibly be in org-mode core because `org-drlll' uses the APIs provided by `org-mode' core. Anyways, the other one I reported yesterday seemed to be related to org-element cache stuff and I will follow your suggestion to try to reproduce it. But I may not have much time this week anymore. Will definitely try it this weekend for sure. Regards, York
Re: [O] Directly search for Headlines?
John Durden writes: > Hello, > > Can you search directly for headlines in all agenda-files, with the > name of the headline, not tags? If so, how? If not, wouldn't this be > useful? > Try `s' in the agenda perhaps? --- Nick
[O] Directly search for Headlines?
Hello, Can you search directly for headlines in all agenda-files, with the name of the headline, not tags? If so, how? If not, wouldn't this be useful? Thanks for answers
Re: [O] Indentation messed up after example block
>> Hi list, >> >> I just noticed a problem that org-mode indentation gets messed up after >> "example" block. Here is ECM: >> >> #+STARTUP: indent >> >> * Level one >> ** Level two >> Indentation is right. >> >> #+BEGIN_EXAMPLE >> * Example at level one >> #+END_EXAMPLE >> >> Indentation is wrong. > The asterisk followed by a space followed by text in your example block > is recognized by org as a headline. So org thinks everything under that > headline is the body of the headline. I knew this is exactly the reason. But the question is shouldn't `org-mode' ignore headlines in example block. I'm not sure whether this is easy or not though. > You can fix this by not letting "* Example at level one" start at the > beginning of the line, but instead indent it by one or more spaces or prefix > it with some other character(s). Smart workaround. Thanks.
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Nick Dokos writes: > Thorsten Jolitz writes: > >> Hi List, >> >> evaluating this 3 times does not work as expected: >> >> , >> | * A >> | >> | #+header: :results raw replace >> | #+begin_src emacs-lisp >> | (+ 2 2) >> | #+end_src >> | >> | #+results: >> | 4 >> | 4 >> | 4 >> ` >> >> Independent from argument order, 'replace' (which should be default >> anyway) is ignored. > > Right - `raw' inserts results without delimiters so org has no idea > where they end and cannot delete them (try org-babel-remove-result) > or replace them. ok, I see from `org-babel-remove-result': , | (when (looking-at (concat org-babel-result-regexp ".*$")) ...) ` seems a bit tricky to adapt this to 'raw results ... But at least there should be a hint in the manual that ':results raw replace' is not supposed to work, and what would be a possible workaround. -- cheers, Thorsten
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Grant Rettke writes: > It sounds like you wanted the same thing that I did. > > What I wanted is something like running 'script' before starting a > REPL and just capturing the output and that is it. That output is not > being used to be inserted back into the document or anything... it > just captured the results of commands sent into the REPL. > > I tried a lot of different combinations until I felt like my goal was > simple: > 1. Wrap the output. > 2. Put the output in a "sh" type result, something from the shell > 3. Let replace work > > This is what was the best: > > , > | #+PROPERTY: header-args+:results output scalar pp replace > ` Nice trick, it gets very close to what I want (and I start to get this :header-args+, :results+ ... syntax): , | #+results: dblock | : | : | : ** Overview :READONLY: | : | : #+begin: foo :bar loo | : | : #+end: ` Have you found a way to get rid of those leading colons (maybe with a hook for post-processing the results before they are printed or so)? > Grant Rettke | ACM, ASA, FSF, IEEE, SIAM > 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 > > > On Mon, Jul 7, 2014 at 8:56 AM, Nick Dokos wrote: >> Thorsten Jolitz writes: >> >>> Hi List, >>> >>> evaluating this 3 times does not work as expected: >>> >>> , >>> | * A >>> | >>> | #+header: :results raw replace >>> | #+begin_src emacs-lisp >>> | (+ 2 2) >>> | #+end_src >>> | >>> | #+results: >>> | 4 >>> | 4 >>> | 4 >>> ` >>> >>> Independent from argument order, 'replace' (which should be default >>> anyway) is ignored. >> >> Right - `raw' inserts results without delimiters so org has no idea >> where they end and cannot delete them (try org-babel-remove-result) >> or replace them. >> -- >> Nick >> >> > > -- cheers, Thorsten
Re: [O] org-mode date stamp with just month?
Grant Rettke writes:
> That property then is something that we may set as a buffer local
> variable set in the file itself for cases where want only months in
> the entire file?
>
> How might we get that form for only parts of a file in which the rest
> of that file we want the standard date format?
I really don't know, I just thought that this variable could be a
starting point for the OP for some deeper digging ...
> Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
> 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
>
>
> On Sun, Jul 6, 2014 at 7:05 PM, Thorsten Jolitz wrote:
>> David Rogoff writes:
>>
>>> I can’t see how to insert a datestamp with just year and month. I’m
>>> adding an archive of various past events that I don’t have the exact
>>> date for.
>>
>> Maybe try
>>
>> ,[ C-h v org-time-stamp-custom-formats RET ]
>> | org-time-stamp-custom-formats is a variable defined in `org.el'.
>> | Its value is ("<%m/%d/%y %a>" . "<%m/%d/%y %a %H:%M>")
>> |
>> | Documentation:
>> | Custom formats for time stamps. See `format-time-string' for the
>> | syntax.
>> | These are overlaid over the default ISO format if the variable
>> | `org-display-custom-times' is set. Time like %H:%M should be at the
>> | end of the second format. The custom formats are also honored by
>> | export
>> | commands, if custom time display is turned on at the time of export.
>> |
>> | You can customize this variable.
>> |
>> | [back]
>> `
>>
>> --
>> cheers,
>> Thorsten
>>
>>
>
>
--
cheers,
Thorsten
Re: [O] Indentation messed up after example block
Hi, Alexander Baier writes: > On 2014-07-06 20:03 York Zhao wrote: ... >> #+BEGIN_EXAMPLE >> * Example at level one >> #+END_EXAMPLE >> >> Indentation is wrong. > > The asterisk followed by a space followed by text in your example block > is recognized by org as a headline. So org thinks everything under that > headline is the body of the headline. I hit this very problem recently and first assumed it must be a bug. But, since it's documented[1] I guess it's a "feature". Although one I don't immediately see a use for. I hit this when capturing some logging info which happened to have a line starting with a triple-*. Trying to manually find such offending lines in a large EXAMPLE block is too tedious to contemplate. A better way, which is implied by that footnote, is to use Org Src buffers when entering the content of EXAMPLE blocks in the first place. I do like: C-c' Where is me pasting or typing whatever is the content of the EXAMPLE block. This will not only indent the entire block with a couple of spaces but will "escape" the problematic headline asterisk with the "special syntax" comma. -Brett. [1] http://orgmode.org/manual/Literal-examples.html#fnd-4 pgpxexQb8TG5u.pgp Description: PGP signature
Re: [O] Directly search for Headlines?
On 2014-07-07 at 11:19, Nick Dokos wrote: > John Durden writes: > >> Can you search directly for headlines in all agenda-files, with the >> name of the headline, not tags? If so, how? If not, wouldn't this be >> useful? >> > > Try `s' in the agenda perhaps? Yes this feature would be useful. "s" in agenda just saves all Org Buffers for me. My work-around is to search for "* Foo", but this doesn't find headlines with TODO items. -k.
[O] Syntax highlighting on export to html with minimal init.el WAS: A simple org tangle and weave makefile
Grant Rettke writes:
> I think that I ran into the same thing and someone else explained that
> the htmlize package
> is required to get syntax highlighting on export.
OK - I realized that I had syntax highlighting even without htmlize -
but only in black and white, i.e. underlined, bold, etc.
But not for R (although I guess the reason is the black and white, as
the block is shown as R). For emacs-lisp and makefile, I have the bold,
underlined, ... but also no color.
below find my minimal init.el which I call with the make file below
,
| * Minimal init.el file for makefile usage
| :PROPERTIES:
| :comments: no
| :header-args+: :tangle ./init.el
| :header-args+: :comments yes
| :header-args+: :eval never
| :END:
| ** Load up Org Mode and Org Babel for elisp embedded in Org Mode files
| #+begin_src emacs-lisp
| (add-to-list 'load-path "~/.emacs.d/org-mode/lisp")
| (add-to-list 'load-path "~/.emacs.d/org-mode/contrib/lisp")
| #+end_src
|
| ** load up Org-mode and Org-babel
| #+begin_src emacs-lisp
| (require 'org)
| #+end_src
|
| ** Package initialization
| #+begin_src emacs-lisp
| (package-initialize)
| (require 'cask "/usr/local/opt/cask/cask.el")
| (cask-initialize)
| (require 'pallet)
| #+end_src
|
| ** Enable org languages
| #+begin_src emacs-lisp
| (org-babel-do-load-languages
| 'org-babel-load-languages
| '((R . t)
|(latex . t)
|(sh . t)
|(plantuml . t)
|(emacs-lisp . t)
|))
| #+end_src
|
| ** Setup org-ref
| #+begin_src emacs-lisp
| (require 'reftex-cite)
| (require 'dash)
| (org-babel-load-file "~/.emacs.d/org-ref/org-ref.org")
| (setq reftex-default-bibliography '("~/Documents/Mendeley/bibliography.bib"))
| (setq org-ref-default-bibliography '("~/Documents/Mendeley/bibliography.bib"))
| #+end_src
|
| ** enable fontified code export to html
| #+begin_src emacs-lisp
| ;; (require 'htmlize)
| (setq org-src-fontify-natively t)
| #+end_src
|
| ** Enable fontified code export to LaTeX / pdf
| #+begin_src emacs-lisp
| (setq org-latex-listings t)
| (add-to-list 'org-latex-packages-alist '("" "listings"))
| (add-to-list 'org-latex-packages-alist '("" "color"))
| #+end_src
`
and here is the extract of the makefile I use which contains the export
to html:
,
| PROJECT=prodMixStands
|
| EMACS=emacs
| BATCH_EMACS=$(EMACS) --batch -Q -l ./init.el
|
| html: prodMixStands.org
| $(info ===)
| $(info Exporting to html)
| $(info *** DOES NOT EXPORT PROPERLY ***)
| $(info ===)
| $(BATCH_EMACS) $(PROJECT).org -f org-html-export-to-html
| open $(PROJECT).html
`
Any suggestions what I am missing?
Cheers,
Rainer
>
> ,
> | (require 'htmlize)
> `
> Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
> 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
>
>
> On Fri, Jul 4, 2014 at 10:26 AM, Rainer M Krug wrote:
>> Following an older thread.
>>
>> I would like to use a make file to export my document, and I am
>> essentially following Eric's suggestion. But I have some problems which
>> I did not manage to solve:
>>
>> html: I would like to have syntax highlighting in the document, but I
>> don't manage. I have added the following
>>
>> ,
>> | ;;Initialization of my org version
>> | ;; Enable org languages
>> | (org-babel-do-load-languages
>> | 'org-babel-load-languages
>> | '((R . t)
>> |(latex . t)
>> |(sh . t)
>> |(plantuml . t)
>> |(emacs-lisp . t)
>> |))
>> |
>> | ;; Setup org-ref
>> | (require 'reftex-cite)
>> | (require 'dash)
>> | (org-babel-load-file "~/.emacs.d/org-ref/org-ref.org")
>> | (setq reftex-default-bibliography
>> '("~/Documents/Mendeley/bibliography.bib"))
>> | (setq org-ref-default-bibliography
>> '("~/Documents/Mendeley/bibliography.bib"))
>> |
>> | (setq org-src-fontify-natively t)
>> `
>>
>> to a minimal init.el which I use to initialize the emacs session using
>> the following in the make file:
>>
>> ,
>> | PROJECT=prodMixStands
>> | EMACS=emacs
>> | BATCH_EMACS=$(EMACS) --batch -Q --no-desktop -l ~/.emacs.d/init.minimal.el
>> | html:
>> | $(BATCH_EMACS) $(PROJECT).org -f org-html-export-to-html
>> `
>>
>> The result is still without syntax highlighting - what am I missing?
>>
>> Thanks
>>
>> Rainer
>>
>>
>>
>> Eric Schulte writes:
>>
>>> Grant Rettke writes:
>>>
Hi,
My goals was to have a simple makefile to tangle and weave a document;
so org-mk was out of scope.
Just wondering; how could I have done it better?
##
INIT=.emacs.el
$(INIT): TC3F.org
time emacs --batch --no-init-file --load .org-mode.emacs.el
--find-file TC3F.org --funcall org-babel-tangle --kill
TC3F.html: $(INIT)
time emacs --batch --no-init-file --load .org-mode.emacs.el
--find-file TC3F.org
Re: [O] Directly search for Headlines?
Ken Mankoff writes: > On 2014-07-07 at 11:19, Nick Dokos wrote: >> John Durden writes: >> >>> Can you search directly for headlines in all agenda-files, with the >>> name of the headline, not tags? If so, how? If not, wouldn't this be >>> useful? >>> >> >> Try `s' in the agenda perhaps? > > Yes this feature would be useful. > > "s" in agenda just saves all Org Buffers for me. for me too > My work-around is to search for "* Foo", but this doesn't find headlines > with TODO items. Internally, the necessary functionality already exists: ,[ C-h f org-map-entries RET ] | org-map-entries is a compiled Lisp function in `org.el'. | | (org-map-entries FUNC &optional MATCH SCOPE &rest SKIP) | | Call FUNC at each headline selected by MATCH in SCOPE. | | [...] | MATCH is a tags/property/todo match as it is used in the agenda tags view. | Only headlines that are matched by this query will be considered during | the iteration. When MATCH is nil or t, all headlines will be | visited by the iteration. | | SCOPE determines the scope of this command. It can be any of: | | nil The current buffer, respecting the restriction if any | treeThe subtree started with the entry at point | region The entries within the active region, if any | region-start-level | The entries within the active region, but only those at | the same level than the first one. | fileThe current buffer, without restriction | file-with-archives | The current buffer, and any archives associated with it | agenda All agenda files | agenda-with-archives | All agenda files with any archive files associated with them | (file1 file2 ...) | If this is a list, all files in the list will be scanned [...] ` or ,[ C-h f org-element-map RET ] | org-element-map is a compiled Lisp function in `org-element.el'. | | (org-element-map DATA TYPES FUN &optional INFO FIRST-MATCH | NO-RECURSION WITH-AFFILIATED) | | Map a function on selected elements or objects. | | DATA is a parse tree, an element, an object, a string, or a list | of such constructs. TYPES is a symbol or list of symbols of | elements or objects types (see `org-element-all-elements' and | `org-element-all-objects' for a complete list of types). FUN is | the function called on the matching element or object. It has to | accept one argument: the element or object itself. | [...] ` One could either use something like this #+begin_src emacs-lisp (defun tj/match-true-headlines-1 () (interactive) (org-element-map (org-element-parse-buffer 'headline) 'headline (lambda (--entry) (let ((true-headline (org-element-property :title --entry))) (when (string-match "world" true-headline) true-headline) #+end_src #+results: : tj/match-true-headlines-1 or like this #+begin_src emacs-lisp (defun tj/match-true-headlines-2 () (interactive) (org-map-entries (lambda () (when (looking-at org-complex-heading-regexp) (let ((true-headline (match-string 4))) (when (string-match "world" true-headline) (org-no-properties true-headline))) #+end_src #+results: : tj/match-true-headlines-2 Lets try some test headlines after evaluating the above src_blocks. * Hello world ** What a wonderful world ** Nice work if you can get it *** Don't get around much anymore *** World music #+begin_src emacs-lisp :results table (tj/match-true-headlines-1) #+end_src #+results: | Hello world | What a wonderful world | World music | #+begin_src emacs-lisp :results table (delq nil (tj/match-true-headlines-2)) #+end_src #+results: | Hello world | What a wonderful world | World music | So both versions match the correct headlines in this *outorg-edit-buffer* (where I write my message-mode email in full org-mode). I don't know if this can be done with existing Org Agenda functionality (as always, its quite likely...) If not, to be useful this should be integrated in the Org Agenda framework. -- cheers, Thorsten
Re: [O] org-mode date stamp with just month?
On 2014-07-07 16:40 Grant Rettke wrote: > That property then is something that we may set as a buffer local > variable set in the file itself for cases where want only months in > the entire file? File local variables? HTH, -- Alexander Baier
Re: [O] org-mode date stamp with just month?
Alexander Baier writes: > On 2014-07-07 16:40 Grant Rettke wrote: >> That property then is something that we may set as a buffer local >> variable set in the file itself for cases where want only months in >> the entire file? > > File local variables? ,[ C-h f make-variable-buffer-local RET ] | make-variable-buffer-local is an interactive built-in function in `C | source code'. | [...] ` Aren't file-local and buffer-local variable really aliases? In the Emacs world both names are used, but they seem to refer to the same thing, except maybe that file-local vars are defined persistently in the file? Not sure really ... -- cheers, Thorsten
Re: [O] Directly search for Headlines?
Ken Mankoff writes: > On 2014-07-07 at 11:19, Nick Dokos wrote: >> John Durden writes: >> >>> Can you search directly for headlines in all agenda-files, with the >>> name of the headline, not tags? If so, how? If not, wouldn't this be >>> useful? >>> >> >> Try `s' in the agenda perhaps? > > Yes this feature would be useful. > > "s" in agenda just saves all Org Buffers for me. > Sorry, I meant `s' in the agenda dispatcher: C-c a s > My work-around is to search for "* Foo", but this doesn't find headlines > with TODO items. > > -k. C-c a S perhaps? Nick
Re: [O] org-mode date stamp with just month?
Thorsten Jolitz writes: > Alexander Baier writes: > >> On 2014-07-07 16:40 Grant Rettke wrote: >>> That property then is something that we may set as a buffer local >>> variable set in the file itself for cases where want only months in >>> the entire file? >> >> File local variables? > > ,[ C-h f make-variable-buffer-local RET ] > | make-variable-buffer-local is an interactive built-in function in `C > | source code'. > | [...] > ` > > Aren't file-local and buffer-local variable really aliases? In the Emacs > world both names are used, but they seem to refer to the same thing, > except maybe that file-local vars are defined persistently in the file? > Not sure really ... Not really: a buffer may or may not be associated with a file, so its buffer-locals cannot possibly be file-locals. Ditto for a buffer that *is* associated with a file, but which then is given a bunch of buffer-locals (e.g. associated with a minor mode for that file). OTOH, file-locals are read from the file when the file is opened and they *do* become buffer-local at that point. And yes, file-locals could be used to satisfy the OP's first request. AFAIK, there is no way to satisfy the second request (i.e. for only parts of the file). org-time-stamp-custom-formats is for visual display only: the underlying timestamp is standard ISO and the custom one is overlaid iff org-display-custom-times is set (but if I read the docstring correctly, the custom format is honored during export in this case, so it is a bit more than visual display). However, there is no way to have that variable set one way for part of the file and another way for a different part. Nick
Re: [O] Directly search for Headlines?
On 2014-07-07 at 15:11, Nick Dokos wrote: > Ken Mankoff writes: > >> On 2014-07-07 at 11:19, Nick Dokos wrote: >>> John Durden writes: >>> Can you search directly for headlines in all agenda-files, with the name of the headline, not tags? If so, how? If not, wouldn't this be useful? >>> >>> Try `s' in the agenda perhaps? > > Sorry, I meant `s' in the agenda dispatcher: > > C-c a s > C-c a S > I use the key combos you suggest all the time, but the OP wanted to just search HEADLINES. Maybe the above methods work if you use regex and exploit the fact that all headlines have "*" characters in them, but this use of regex seems a bit overly complex. -k.
Re: [O] Directly search for Headlines?
Ken Mankoff writes: > On 2014-07-07 at 15:11, Nick Dokos wrote: >> Ken Mankoff writes: >> >>> On 2014-07-07 at 11:19, Nick Dokos wrote: John Durden writes: > Can you search directly for headlines in all agenda-files, with the > name of the headline, not tags? If so, how? If not, wouldn't this be > useful? > Try `s' in the agenda perhaps? >> >> Sorry, I meant `s' in the agenda dispatcher: >> >> C-c a s >> C-c a S >> > > I use the key combos you suggest all the time, but the OP wanted to just > search HEADLINES. Maybe the above methods work if you use regex and > exploit the fact that all headlines have "*" characters in them, but > this use of regex seems a bit overly complex. > Yes, I understand that, but limiting the search space with C-c a s seems to me to be a good solution for keyword searching. If there are too many results, you can then do C-s of the same keyword in the resulting results buffer and step exactly through the headlines that match. It's not hard to write a more specialized tool either. I think an application of org-map-entries could easily do what the OP wanted (although the devil *will* be in the details). The question is whether it's worth it, or whether the current tools adequately meet the need. Nick
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
On Mon, Jul 7, 2014 at 10:31 AM, Thorsten Jolitz wrote: > Have you found a way to get rid of those leading colons (maybe with a > hook for post-processing the results before they are printed or so)? No I have not. I'm not sure how to think about it yet.
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Thorsten Jolitz writes: > Grant Rettke writes: > >> It sounds like you wanted the same thing that I did. >> >> What I wanted is something like running 'script' before starting a >> REPL and just capturing the output and that is it. That output is not >> being used to be inserted back into the document or anything... it >> just captured the results of commands sent into the REPL. >> >> I tried a lot of different combinations until I felt like my goal was >> simple: >> 1. Wrap the output. >> 2. Put the output in a "sh" type result, something from the shell >> 3. Let replace work >> >> This is what was the best: >> >> , >> | #+PROPERTY: header-args+:results output scalar pp replace >> ` > > Nice trick, it gets very close to what I want (and I start to get this > :header-args+, :results+ ... syntax): > > , > | #+results: dblock > | : > | : > | : ** Overview :READONLY: > | : > | : #+begin: foo :bar loo > | : > | : #+end: > ` > > Have you found a way to get rid of those leading colons (maybe with a > hook for post-processing the results before they are printed or so)? > > Output shorter than org-babel-min-lines-for-block-output (10 by default) is colon-commented. If it's longer, then it's wrapped in an example block. If you prefer that always, set it to 0. Nick
Re: [O] babel evaluation of python and utf-8
El Fri, 04 Jul 2014 16:08:10 +0200 Alan Schmitt va escriure: > > On 2014-06-26 18:07, Daniel Clemente writes: > > >> > >> #+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output > >> print(u'é') > >> #+END_SRC > >> > > > > I also see the same problem here. Even if you include # -*- coding: utf-8 > > -*-as the first line. > > > > Shouldn't org-babel already be using utf-8 instead of ASCII for > > input/output? > > > > By the way, with Python3 it doesn't happen since it doesn't need the > > coding:utf-8 declaration anymore. > > Should this be considered a bug, or do we require python 3 for such > things? > I think if the user writes the # -*- coding: utf-8 -*- line, org-mode should pass it. With that, all Pythons (Python2, Python3) work well, so I wouldn't say there's a bug in Python. It would be in org-mode.
