Re: [O] Minimal overhead Org-mode blogging system
On Sat, 21 Jan 2012 00:53:33 -0500, Nick Dokos wrote: > Scott Randby wrote: > > > On 01/20/2012 01:19 PM, Chris Gray wrote: > > > On Thu, 19 Jan 2012 23:15:16 +0100, Steinar Bang wrote: > > >>> Puneeth Chaganti : > > >> > > >>> This is totally home brew stuff. > > >> > > >> Well, thank you for sharing this home brew stuff. > > >> I've been trying to use the other org based blog solutions, but they > > >> have all failed for some reason or other, and they have also seemed > > >> abandoned. > > > > > > Have another look at ikiwiki. Either plugin for org works (I am the > > > author of one of them), and the nice thing is that it is a really > > > complete system. It has plugins [1] for just about anything you could > > > want to do with a blog or wiki, and is generally well-engineered. > > > > > > If you have any trouble with my plugin, please open an issue on github. > > > I promise it's not abandoned. :) > > > > > > Cheers, > > > Chris > > > > > > [1] http://ikiwiki.info/plugins/ > > > > Unless this plugin does not have "org" in its name, then it cannot be > > found on this page. What plugin are you talking about? > > > > Scott Randby > > > > Chris's plugin is on github. You can clone it with > >git clone git://github.com/chrismgray/ikiwiki-org-plugin.git > Thanks, I should have been more clear. Both the plugins are documented here: http://ikiwiki.info/todo/org_mode/ Cheers, Chris
Re: [O] Quoting characters?
No solution, but sympathy. Syntax risk is difficult to prevent in Org I wonder if we can come up with incremental improvements that involve more universal escaping, quoting, nesting, etc. mechanisms somehow? (This is /not/ intended to be a sly plug for my universal syntax proposal. That's not intended to replace all existing syntax, but only to be used for future syntax. However, I do have a list of parsing risk issues on the list someplace that might be a reference.) -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] How to include comments on export? org-exp-blocks.el?
We had a wonderful discussion of it once, along with different possible uses for inline tasks, inclusion of paragraphs, non-exported headlines for easier structure editing, universal syntax, and returning text to higher level. On my blog I use a colored background, which could also serve as comment blocks: #+HTML: Some text. #+HTML: A bit rudimentary perhaps. Samuel On 2011-10-24, Herbert Sitz wrote: > I'm trying to see if there is a way to include comments on export, to show > up as > something like the comments boxes you see in MS Word. > > I see Eric Schulte did some work on this and that somehow it ended up (I > think) > as part of what you could do using the org-exp-blocks addon. But I'm not > sure > how you actually use it. > > Can someone give an example of how org-exp-blocks (or anything else) could > be > used to export comment blocks as graphic notes in the text? > > Thanks, > > Herb > > > > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] Minimal overhead Org-mode blogging system
Scott Randby wrote: > On 01/20/2012 01:19 PM, Chris Gray wrote: > > On Thu, 19 Jan 2012 23:15:16 +0100, Steinar Bang wrote: > >>> Puneeth Chaganti : > >> > >>> This is totally home brew stuff. > >> > >> Well, thank you for sharing this home brew stuff. > >> I've been trying to use the other org based blog solutions, but they > >> have all failed for some reason or other, and they have also seemed > >> abandoned. > > > > Have another look at ikiwiki. Either plugin for org works (I am the > > author of one of them), and the nice thing is that it is a really > > complete system. It has plugins [1] for just about anything you could > > want to do with a blog or wiki, and is generally well-engineered. > > > > If you have any trouble with my plugin, please open an issue on github. > > I promise it's not abandoned. :) > > > > Cheers, > > Chris > > > > [1] http://ikiwiki.info/plugins/ > > Unless this plugin does not have "org" in its name, then it cannot be > found on this page. What plugin are you talking about? > > Scott Randby > Chris's plugin is on github. You can clone it with git clone git://github.com/chrismgray/ikiwiki-org-plugin.git Nick
Re: [O] Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)
FWIW: It might be the case that we will want to consider the multi-value property idea and the multi-line property idea together at some point. (With or without serialization for the latter.) I think multi-line properties will eventually be needed (in some form) in any case for things like org-contacts and they provide a simple way of allowing more data without imposing semantics. In other words, they are usable even if we don't standardize multi-value semantics. However, Babel and OP both need multi-value properties. What should a multi-value property be semantically? Effectively a vector? Effectively an alist? Both are possibilities. Outside of Babel and OP's case, do we need a layer of semantics on properties? Do we want one? Should we set Babel's interpretation of multi-value properties in stone for the rest of Org? Also, should there be an interface to multi-value properties other than accumulation? Give me the 3rd value of property? Give me the value that matches this string? Set the 3rd value? Set (and replace) the value that matches? Is accumulation a substitute for multi-line properties? Or do we want something nicer for that purpose so that editing and reading are easier, so that there is no order-dependence of property fields, and so on? Just philosophical/design questions. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] Minimal overhead Org-mode blogging system
On 01/20/2012 01:19 PM, Chris Gray wrote: > On Thu, 19 Jan 2012 23:15:16 +0100, Steinar Bang wrote: >>> Puneeth Chaganti : >> >>> This is totally home brew stuff. >> >> Well, thank you for sharing this home brew stuff. >> I've been trying to use the other org based blog solutions, but they >> have all failed for some reason or other, and they have also seemed >> abandoned. > > Have another look at ikiwiki. Either plugin for org works (I am the > author of one of them), and the nice thing is that it is a really > complete system. It has plugins [1] for just about anything you could > want to do with a blog or wiki, and is generally well-engineered. > > If you have any trouble with my plugin, please open an issue on github. > I promise it's not abandoned. :) > > Cheers, > Chris > > [1] http://ikiwiki.info/plugins/ Unless this plugin does not have "org" in its name, then it cannot be found on this page. What plugin are you talking about? Scott Randby > >
Re: [O] Capitalisation and good taste ?
> A long time ago all capitals was the only way these keywords were > supported. Since then they have become case insensitive and I use all > lowercase for most of my keywords now (#+begin_src:, #+begin_example: > etc) > > With fontification these stand out enough now and the capitalization can > be removed. So I'm kind of late to this party, but like Bernt, I've been favoring lowercase #+ keywords; I believe it looks cleaner and easier on the eyes. However, if functions that autogenerate keywords (e.g. #+results from code blocks and easy templates) default to a particular case, forcing a different case as a user becomes unappealing (consistency trumps aesthetics). If we want to keep org truly keyword-case-agnostic, then there should be a user-customized variable that easy templates and org-babel result blocks would follow. --Leo
[O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Since all source blocks are evaluated on export, I don't think it should be necessary to issue org-babel-execute-buffer before invoking export. However, running HTML export without org-babel-execute-buffer currently produces garbage output. On the other hand, I have several examples where running HTML export _after_ org-babel-execute-buffer produces the wrong output due to the fact that :results replace directive appears to append instead of replacing the output I am attaching three simple examples where I simulate generating and exporting image data (I just generate and print filenames). If I understand the documentation correctly, they are all supposed to produce identical output on HTML export; however, none of the files produces the expected output, namely, blocks of the form: | some output | images/conv1.png | | images/conv1.png \-- Here, the first two lines should be enclosed in a code block, and the last line should be raw org output. To reproduce, load any of my examples, do C-c C-e h <- will produce garbage output on export C-c C-v b <- will produce expected output in the buffer C-c C-e h <- will produce extraneous output on export despite :results replace being on C-c C-v b <- will produce extraneous output in the buffer This was tested on my test-export4.org, but the other examples behave in a similar fashion. --Leo test-export4.org Description: Binary data test-export5.org Description: Binary data test-export7.org Description: Binary data
Re: [O] latex export of #+header: lines
Jambunathan K writes: > Andreas Leha writes: > >> Andreas Leha writes: >> >>> "Sebastien Vauban" >>> writes: >>> >>> Hi Andreas, Andreas Leha wrote: > I am experiencing a problem with the latex exporter: #+header: lines > are visible in the exported file. > > Example: > > /==\ > * test header tag > #+caption: foo > #+label: fig:fig1 > #+name: foo > #+header: :file foo.png > #+header: :width 3600 :height 3600 :res 600 > #+begin_src R :exports results :results graphics > plot(1:10, 1:10) > #+end_src > \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb >>> >>> >>> Hi Seb, >>> >>> thanks for the reply! >>> >>> But as far as I know, #+LaTeX_HEADER (as described >>> here http://orgmode.org/org.html#Header-and-sectioning) is a different >>> thing from babel source block header arguments (as described here >>> http://orgmode.org/org.html#Code-block-specific-header-arguments) >>> >>> I use both quite extensively. >>> >>> The #+header: tags can be avoided by creating lng #+begin_src >>> lines. But still, they should not appear in the exported tex code, I >>> think. >>> >>> Best, >>> Andreas >> >> Just tried, and the odt export has them as well. Maybe a problem on my >> test file? Or is the #+header(s): tag somehow deprecated? > > If you remove the indentation of "#+header:" line (and thereby force it > to start at column 0) you will see that (atleast) the ODT export doesn't > have the header lines. > > I think the problem is not with the latex or odt backends as such but in > the export pre-processor. > Hi Jambunathan, thanks for this work-around with the removal of the indentation. Works for #+ATTR_ODT: in the LaTeX export as well. Cheers, Andreas
[O] Is it possible to include #+call lines in HTML export?
Currently, my org files look something like this: * And now, let's do the analysis ! #+call: foo(bar) #+results: : earth-shattering results : gonna land me a Nobel /and/ a Fields! But because #+call is not exported, it's not clear what function was called and with what parameters. It makes a lot of sense for it to be included in the export (unless its evaluation is turned off via e.g. :eval no-export), but I can't find an option for this. --Leo
Re: [O] [bug] Tables in lists not exported to ODT
Eric S Fraga writes: > By the way, I was surprised, upon reading your comments in the git log, > that OpenDocument doesn't support tables within lists. This seems like > a silly restriction? Given that OpenDocument uses XML for its encoding, > I would have thought that a hierarchical structure in a document would > be trivial to represent. Do you know what the reasoning was? Just > curious! You would have to read the DTD for OpenDocument, but I would guess that this is similar to the distinction between block-level and inline elements in XHTML. In fact it is exactly the hierarchical nature of the definition that makes it possible to prevent the inclusion of higher level elements as sub-elements of their children. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [BABEL,PATCH] Map "screen language" to shell-script-mode
Applied, Thanks.
Litvinov Sergey writes:
> A patch maps "screen language" to shell-script-mode.
>
> From 8b802edb789eb50ddffcc9f040afcb7870db0181 Mon Sep 17 00:00:00 2001
> From: Litvinov Sergey
> Date: Fri, 20 Jan 2012 18:26:59 +0100
> Subject: [PATCH] Map "screen" to shell-script-mode
>
> ---
> lisp/org-src.el |3 ++-
> testing/examples/ob-screen-test.org |5 +
> 2 files changed, 7 insertions(+), 1 deletions(-)
> create mode 100644 testing/examples/ob-screen-test.org
>
> diff --git a/lisp/org-src.el b/lisp/org-src.el
> index 11ce461..5357dd8 100644
> --- a/lisp/org-src.el
> +++ b/lisp/org-src.el
> @@ -153,7 +153,8 @@ but which mess up the display of a snippet in Org
> exported files.")
> (defcustom org-src-lang-modes
>'(("ocaml" . tuareg) ("elisp" . emacs-lisp) ("ditaa" . artist)
> ("asymptote" . asy) ("dot" . fundamental) ("sqlite" . sql)
> -("calc" . fundamental) ("C" . c) ("cpp" . c++))
> +("calc" . fundamental) ("C" . c) ("cpp" . c++)
> +("screen" . shell-script))
>"Alist mapping languages to their major mode.
> The key is the language name, the value is the string that should
> be inserted as the name of the major mode. For many languages this is
> diff --git a/testing/examples/ob-screen-test.org
> b/testing/examples/ob-screen-test.org
> new file mode 100644
> index 000..19ce147
> --- /dev/null
> +++ b/testing/examples/ob-screen-test.org
> @@ -0,0 +1,5 @@
> +#+Title: a collection of examples for ob-screen tests
> +#+begin_src screen :session create-tmpdir
> + mkdir -p $TMPDIR
> + cd $TMPDIR
> +#+end_src
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [bug] :eval header argument ignored in the #+call: block
Leo Alekseyev writes:
> Suppose I have a code block foo, and I want to call it several times
> in my org file. However, foo may be a slow function, and so any time
> I evaluate buffer non-interactively (e.g. HTML export) I want to
> enable only one out of many calls to :foo
>
> The following doesn't work, but I think it should, since the #+call:
> line should run foo with the header argument :eval no-export
>
> #+NAME: foo
> #+BEGIN_SRC R :var turn_on_output="FALSE"
> if(turn_on_output) { X11() }
> #+END_SRC
>
> #+CALL: foo[:eval no-export](turn_on_output="TRUE") ## this STILL
> evaluates on export
>
Thanks for sharing this example. It indicated two bugs in the existing
code base. I've just pushed up fixes for both bugs, the attached
Org-mode file can be used to confirm that this is now working.
#+Title: foo
A buffer in which we want =foo= to be run when called interactively
from /any/ call line, but to only be run by a single call line on
export. Ensure this works by executing this buffer to html while
tracking =foo-called.times= with =tail -f /tmp/foo-called.times=.
#+NAME: foo
#+BEGIN_SRC sh :var id="foo"
echo "called by $id at $(date +%s.%N)" |tee -a /tmp/foo-called.times
#+END_SRC
This will *not* be run on export.
#+call: foo[:eval no-export]("bar")
This *will* be run on export.
#+call: foo("baz")
>
> Furthermore, a better solution to the situation I described above
> might be to set the :eval no-export header argument in the source
> block definition, and then over-ride it in the one #+call line that I
> want to run during export. Unfortunately, it doesn't seem that this
> is currently possible.
>
The reason this second option doesn't work is that there is currently no
positive argument to the :eval header argument, rather it can only be
used to *inhibit* evaluation.
Cheers,
>
> --Leo
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [bug] src_ blocks seem broken in org-babel-execute-buffer
Leo Alekseyev writes: > With the latest Org, issuing org-babel-execute-buffer on any buffer > that has inline src_ blocks fails with "wrong type argument: > consp, nil" > > For instance, Eric Schulte's own code sample on > http://eschulte.me/org-scraps/scraps/2011-08-21-inline-code-block-and-downstream-src-blocks.html > doesn't run. > > Can anyone confirm and/or offer a fix? > I've just pushed up a fix. Thanks for catching this, > > --Leo > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [BUG?][babel] Re: Including source when exporting in PDF
Rainer M Krug writes:
> On 18/01/12 01:57, Frozenlock wrote:
>> I'm sorry, but I don't quite understand...
>>
>> Would it be possible to send a minimum working example of your org
>> file?
>>
>
> The example is below:
>
This is likely the most evil snippet of Org-mode code I have ever
seen. :)
#+Options: ^:nil
* name src_emacs-lisp{(buffer-file-name)}
#+BEGIN_SRC emacs-lisp :results org :exports code :var buffer-file-name=(buffer-file-name)
(org-babel-tangle)
#+END_SRC
I can confirm that it does modify the value of the file on disk as part
of the export process. Additionally, the src_emacs_lisp in the header
does not export any results because by the time (buffer-file-name) is
called the code is living in a temporary export buffer which is not
visiting a file, note that a heading like the following would probably
give the result you're after
* name src_emacs-lisp{org-current-export-file}
similarly you want the tangling to be done in the original Org-mode file
(not the temporary export file), so that should be placed in a header
argument as well. Try the following less evil version on for size and
let me know if it doesn't solve your problems.
#+Options: ^:nil
* name src_emacs-lisp{org-current-export-file}
One block to tangle.
#+BEGIN_SRC emacs-lisp :tangle yes
(message "I am tangled")
#+END_SRC
One block to export.
#+BEGIN_SRC emacs-lisp :exports results :var foo=(org-babel-tangle)
(message "I just tangled %S during export" foo)
#+END_SRC
>
>
> * name src_emacs-lisp{(buffer-file-name)}
> #+BEGIN_SRC emacs-lisp :results org :exports results :var
> buffer-file-name=(buffer-file-name)
> (org-babel-tangle)
> #+END_SRC
>
>
> If I put the text in the ### lines in a new org file and export it, it
> is modified as described below.
>
> My guess is that it has to do with the fact that on export, a
> temporary copy is created, and some confusion is happening with which
> file is tangled.
>
> Cheers,
>
> Rainer
>
>>
>>
>> On Mon, Jan 16, 2012 at 6:21 AM, Rainer M Krug
>> wrote: On 15/01/12 06:29, Frozenlock wrote:
> This babel block should do the following:
>
> - When exporting, automatically tangle the babel blocks. -
> Then take the resulting files and add them to a zip file,
> along with the original .org file. - Add the necessary
> \usepackage and latex commands to insert the zipfile.
>
> Let me know if something isn't like you want.
>
> Here is the babel block to add to your source (org) file:
>
> #+BEGIN_SRC
> emacs-lisp :results org :exports results :var
> buffer-file-name=(buffer-file-name) (let ((filename
> (file-name-nondirectory (file-name-sans-extension
> buffer-file-name (shell-command (concat "zip -j "
> filename ".zip " filename".org " (mapconcat '(lambda (arg)
> (convert-standard-filename (expand-file-name arg)))
> (org-babel-tangle) " "))) (concat
> "#+LATEX_HEADER:\\usepackage{attachfile2}\n" "#+LATEX:
> \\vfill \\textattachfile[print=false,color=0.5 0.5
> 0.5]{"filename".zip}{Source (.org) \\& other files...}\n"))
> #+END_SRC ==
>>
>> Thanks for this code - it looks good, but there is a serious
>> problem:
>>
>> src_emacs_lisp{} expressions are evaluated and replaced with the
>> result in the org file, which does not happen when tangling from
>> the buffer itself. Example:
>>
>> * name
>> src_emacs-lisp{(buffer-file-name)} #+BEGIN_SRC emacs-lisp :results
>> org :exports results :var buffer-file-name=(buffer-file-name)
>> (org-babel-tangle) #+END_SRC
>>
>>
>> If I export the file above, the file get changed to:
>>
>> * name
>>
>> #+BEGIN_SRC emacs-lisp :results org :exports results :var
>> buffer-file-name=(buffer-file-name) (org-babel-tangle) #+END_SRC
>>
>>
>> Is there something wrong with the code?
>>
>> Rainer
>>
>>
>
>
> On a related note, I've added some improvements to my own way
> to export in multiple format and add the files along with the
> source. The latex commands and usepackage are included, so no
> need to add them elswhere in the org file:
>
> == # Make sure this babel block
> is the last one in the buffer; # block after this one won't
> be evaluated before the txt and html export. #+BEGIN_SRC
> emacs-lisp :results org :exports results :var
> buffer-file-name=(buffer-file-name) (let
> ((org-export-babel-evaluate nil)); don't evaluate in
> 'recursive' exports (save-window-excursion ;; avoid leakage
> when more than one org export in block (org-export-as-ascii
> org-export-headline-lev
Re: [O] automatic tangle
I've just added the two functions below to org-src.el. Cheers, András Major writes: > Thanks Eric, > > Thanks a lot for the quick reply. Any chances of this being > incorporated into Org-Mode in the near future? > > András > > > On 1/14/12, Eric Schulte wrote: >> András Major writes: >> >>> Hi Sebastien, >>> I have the impression it's already there: if you edit your code directly in the Org buffer, without opening an indirect buffer, the only thing you have to do is: >>> >>> That's precisely what I want to avoid. I'd like to use the >>> language-specific indentation and highlighting using the indirect >>> buffer. Basically, what I'm after is a quick keyboard command that >>> tangles the entire file while I'm in the indirect buffer. >>> >> >> The following functions provide for (1) easily executing code in the >> org-mode buffer related to the current edit buffer and (2) tangling the >> org-mode buffer related to the current edit buffer. Binding (2) to a >> key in `org-src-mode' should provide the functionality you describe. >> >> #+BEGIN_SRC emacs-lisp >> (defmacro org-src-in-org-buffer (&rest body) >> `(save-window-excursion >>(org-edit-src-exit 'save) >>,@body >>(setq msg (current-message)) >>(if (eq org-src-window-setup 'other-frame) >>(let ((org-src-window-setup 'current-window)) >> (org-edit-src-code 'save)) >> (org-edit-src-code 'save)) >>(message (or msg "" >> >> (defun org-src-tangle (arg) >> (interactive "P") >> (org-src-in-org-buffer (org-babel-tangle arg))) >> #+END_SRC >> >> I think that the above should be folded into org-src.el, but I'm not >> entirely sure how. (1) could be used to perform a number of functions >> in the org buffer from an edit buffer, although off the top of my head >> I'm not sure if there exists a need for this aside from tangling. >> >> Best, >> >> -- >> Eric Schulte >> http://cs.unm.edu/~eschulte/ >> > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Minimal overhead Org-mode blogging system
On Thu, 19 Jan 2012 23:15:16 +0100, Steinar Bang wrote: > > Puneeth Chaganti : > > > This is totally home brew stuff. > > Well, thank you for sharing this home brew stuff. > I've been trying to use the other org based blog solutions, but they > have all failed for some reason or other, and they have also seemed > abandoned. Have another look at ikiwiki. Either plugin for org works (I am the author of one of them), and the nice thing is that it is a really complete system. It has plugins [1] for just about anything you could want to do with a blog or wiki, and is generally well-engineered. If you have any trouble with my plugin, please open an issue on github. I promise it's not abandoned. :) Cheers, Chris [1] http://ikiwiki.info/plugins/
[O] Organizing by time or by subject and an idea
I use org-mode for all of my work notes. For the most part, I'm very happy with it. I know everything is in there somewhere and I can find it. I currently have one file for my projects organized something like this: #+begin_src org * Tracking This is for misc todos. It's just a repo for holding them until done and then I typically archive them. * Project 1 ** Journals *** 2011 November [2011-11-15 Tue] Weekly project update :mtg: Summary [2011-11-22 Tue] Weekly project update :mtg: *** todo action item 1 *** done action item 2 CLOSED: [2012-01-11 Wed 18:01] *** cancelled action item 3 CLOSED: [2011-12-26 Mon 11:05] [2011-11-28 Mon] Met with Person to go over test methods :mtg: Summary *** 2012 January [2012-01-03 Tue] Weekly project update :mtg: [2012-01-10 Tue] Weekly project update :mtg: [2012-01-11 Wed] Analytical testing [2012-01-17 Tue] Weekly project update :mtg: * Other project trees Similar stuff as Project 1 * Misc Journals Journal entries organized similarly as above, but not on my main projects * Reference Odds and ends that I just need to put somewhere for reference later #+end_src So, one of the issues I've constantly struggled with in org is whether to try and create a skeleton outline of all of the aspects of the project and fill it in bit by bit during things like weekly meetings... or whether to do what I do above and go chronologically, simply creating journal entries for the day something happens. Part of the reason for choosing chronological is that I am required to document Intellectual Property related concepts. Time ordering makes it simple to just print out an export of the items since my last brain dump and past them into a technical notebook for dating/witnessing. To just keep adding means my exports will either be redundant (include all the stuff I pasted last time too) or tedious (find all new updates and move to separate temp file for exporting). Last night as I drifted off to bed I had an idea connected to role as team leader I have. It involves ordering by outline, but having some way to show time-based updates. Imagine "snapshots" of exports/org-files. Perhaps: --- View as of two weeks ago when just creating a new project outline tree: #+begin_src org * Project 1 ** Material evaluations ** Test results ** Voice of customer feedback ** Business plan #+end_src --- Now imagine a team meeting has occurred: #+begin_src org * Project 1 ** Material evaluations *** Polymer A + polymer B: John Smith has evaluated this combination and it has acceptable such and such properties. Will proceed with the following DOE to confirm: [table of proposed experiments] *** Polymer C + D: So and so also suggested looking into this combination ** Test results ** Voice of customer feedback ** Business plan #+end_src --- More time has passed and testing and another team meeting occurred #+begin_src org * Project 1 ** Material evaluations *** Polymer A + polymer B: John Smith has evaluated this combination and it has acceptable such and such properties. Will proceed with the following DOE to confirm: [table of proposed experiments] *** Polymer C + D: So and so also suggested looking into this combination ** Test results John's test results are in. He confirmed A+B will be successful and C+D has failed crucial requirements: [table of experimental results, graphs, etc.] Based on these results, the team decided to move forward with a small scale pilot run of material. ** Voice of customer feedback *** Team proposed week of [date] to move forward with voice of customer feedback for prototypes using A+B. ** Business plan *** Voice of customer will feed into value proposition and help determine sale price #+end_src So... you get where I'm going, hopefully. I've thought of trying to switch to an outline format by subject rather than date simply because I think it makes way more sense. I'm constantly digging through date trees for updates on the same subject matter that span several team meetings. What I find neat is that I could publish my org-mode file as the team leader to html and perhaps create some sort of iterative snapshot view for the team. They could click through hotlinks for each revision date in some sort of header that would feature all new tree items in bold or something. It could create an "OS X like time machine" view of the project history and make it easy to see when things happened. Thoughts? I'm open to suggestions on how to organize my information better as well and am curious whether orgmoders typically opt for time based entries (like mine far above) or a more outline/subject-focused approach. For now, I've just been trying to get everything entered *s
Re: [O] org-babel order of evaluation
On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel wrote: > On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote: >> Rick Frankel writes: >> >> Turns out it was not that difficult to change this behavior. You and >> Leo are both correct that in-buffer-order evaluation is more natural and >> expected than the previous behavior. I've just pushed up a fix after >> which evaluating the following Eric, The fix doesn't seem to be working for me when I export the buffer to HTML. The ordering of call and source blocks once again becomes randomized, and in general, exported file is missing a bunch of stuff unless I run org-babel-execute-buffer prior to export. Since the export engine does its own evaluation, it doesn't seem like org-babel-execute-buffer should be a necessity. But I can't run org-babel-execute-buffer on anything with a src_ inline block as it gives me an error. I'm attaching two files which do not export correctly, at least when one doesn't run org-babel-execute-buffer; just do C-c C-e h and look at the output. --Leo test-export4.org Description: Binary data test-export6.org Description: Binary data
[O] [BABEL,PATCH] Map "screen language" to shell-script-mode
A patch maps "screen language" to shell-script-mode.
>From 8b802edb789eb50ddffcc9f040afcb7870db0181 Mon Sep 17 00:00:00 2001
From: Litvinov Sergey
Date: Fri, 20 Jan 2012 18:26:59 +0100
Subject: [PATCH] Map "screen" to shell-script-mode
---
lisp/org-src.el |3 ++-
testing/examples/ob-screen-test.org |5 +
2 files changed, 7 insertions(+), 1 deletions(-)
create mode 100644 testing/examples/ob-screen-test.org
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 11ce461..5357dd8 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -153,7 +153,8 @@ but which mess up the display of a snippet in Org exported files.")
(defcustom org-src-lang-modes
'(("ocaml" . tuareg) ("elisp" . emacs-lisp) ("ditaa" . artist)
("asymptote" . asy) ("dot" . fundamental) ("sqlite" . sql)
-("calc" . fundamental) ("C" . c) ("cpp" . c++))
+("calc" . fundamental) ("C" . c) ("cpp" . c++)
+("screen" . shell-script))
"Alist mapping languages to their major mode.
The key is the language name, the value is the string that should
be inserted as the name of the major mode. For many languages this is
diff --git a/testing/examples/ob-screen-test.org b/testing/examples/ob-screen-test.org
new file mode 100644
index 000..19ce147
--- /dev/null
+++ b/testing/examples/ob-screen-test.org
@@ -0,0 +1,5 @@
+#+Title: a collection of examples for ob-screen tests
+#+begin_src screen :session create-tmpdir
+ mkdir -p $TMPDIR
+ cd $TMPDIR
+#+end_src
--
1.7.3.4
[O] [bug] src_ blocks seem broken in org-babel-execute-buffer
With the latest Org, issuing org-babel-execute-buffer on any buffer that has inline src_ blocks fails with "wrong type argument: consp, nil" For instance, Eric Schulte's own code sample on http://eschulte.me/org-scraps/scraps/2011-08-21-inline-code-block-and-downstream-src-blocks.html doesn't run. Can anyone confirm and/or offer a fix? --Leo
Re: [O] links to headline in LaTeX export
On 20 Jan 2012, at 17:34, Thomas S. Dye wrote: Hmmm, I can't reproduce your results on my setup. What version of Org mode are you using? I'm using the one bundled with Aquamacs 2.4, which is 6.33x. Looking at the web site, I see that it's quite outdated. I'll try to update it this week-end and see if it fixes things. Thanks a lot for your help, Alan
Re: [O] links to headline in LaTeX export
"Alan Schmitt" writes:
> On 20 Jan 2012, at 15:42, Thomas S. Dye wrote:
>
>> Aloha Alan,
>>
>> Your LaTeX output indicates that this setting:
>>
>> (setq org-export-latex-hyperref-format "\\ref{%s}")
>>
>> hasn't taken effect for one reason or another.
>>
>> What do you get with C-h v org-export-latex-hyperref-format RET?
>
> I get what I would expect:
> org-export-latex-hyperref-format's value is "\\ref{%s}"
>
> For some reason it is not taken into account, and I'll have to
> investigate why. I'm exporting doing "C-c @" to choose the sub-tree to
> export, then "C-c C-e l" to get the LaTeX.
>
> Alan
>
Aloha Alan,
Hmmm, I can't reproduce your results on my setup. What version of Org
mode are you using?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] custom agenda command with function doesn't work
El 20/01/12 17:02, Bastien escribió:
Hi Juan,
Juan Queipo de Llano Moya writes:
If I define a custom agenda command like (without using the command):
("q" "Tasks by member" ((tags-todo "+Resp=\"Me\"") (tags-todo "+Resp=
\"Pablo\"") (tags-todo "+Resp=\"Miguel\"") (tags-todo "+Resp=\"Carlos
\"")))
It works, but if use this agenda command:
("q" "Tasks by member" (org-sec-tasksbymember))
I got an error of Wrong type argument: listp, org-sec-tasksbymember
You want
(setq org-agenda-custom-commands
`(("q"
"Tasks by member"
,(org-sec-tasksbymember
Look for Macro expansion in the Emacs (lisp) manual.
HTH,
It works!
Thanks a lot. I've learned something today. :)
*Juan Queipo de Llano Moya*
Re: [O] Minimal overhead Org-mode blogging system
Eric Schulte writes: > Note that regular Org-mode projects [1] do *not* re-publish every single > page after an update, but rather only publish pages which have changed > since the previous publish. Thus a git repository with a pos-update > hook which runs `org-publish' in a batch Emacs session does a good job > of publishing updates without having to re-publish the entire site. > > This is the approach taken for my lab's wiki [2], which is just a git > repository [3] with a post-update hook and a couple of helper scripts > [4] which re-publish updated pages after every commit. FWIW, this is also the way Worg is published. -- Bastien
Re: [O] IMAP support for VM links in orgmode (org-vm.el)
Konrad Hinsen writes: > The attached patch (relative to yesterday's state of the orgmode git > repository) adds the possibility to have org-mode links to IMAP folders in > VM and to messages inside IMAP folders. It requires VM 8.2.0a or > later. Applied -- thanks! PS: wrt my previous message, I forgot Konrad already signed FSF papers. -- Bastien
Re: [O] custom agenda command with function doesn't work
Hi Juan,
Juan Queipo de Llano Moya writes:
> If I define a custom agenda command like (without using the command):
> ("q" "Tasks by member" ((tags-todo "+Resp=\"Me\"") (tags-todo "+Resp=
> \"Pablo\"") (tags-todo "+Resp=\"Miguel\"") (tags-todo "+Resp=\"Carlos
> \"")))
>
> It works, but if use this agenda command:
> ("q" "Tasks by member" (org-sec-tasksbymember))
> I got an error of Wrong type argument: listp, org-sec-tasksbymember
You want
(setq org-agenda-custom-commands
`(("q"
"Tasks by member"
,(org-sec-tasksbymember
Look for Macro expansion in the Emacs (lisp) manual.
HTH,
--
Bastien
Re: [O] Some more org-mode shirts
heathmatlock writes: > I became distracted from real work last night and created some org-mode > shirts: > > http://open.spreadshirt.com Nice! I just shared this on the G+ account. Thanks, -- Bastien
Re: [O] Issue with org-fontify-done-headline
Hi Brian, "Brian J. Carlson" writes: > In the latest git version of org I've been having problems with > org-fontify-done-headline. thanks for spotting this problem and for the suggested solution, it is now fixed. Best, -- Bastien
Re: [O] C-u C-c C-q refuses to work, sometimes
Hi François, pin...@iro.umontreal.ca (François Pinard) writes: > In (org) Setting tags, there is in the paragraph for `C-c C-q > (`org-set-tags-command')': > > When called with a `C-u' prefix, all tags in the current buffer will > be aligned to that column, just to make things look nice. > > If I open file "epsilon.org" with the cursor at the very beginning, just > before "#+TITLE:', command `C-u C-c C-q' yields: > > Before first headline at position 1 in buffer epsilon.org Fixed, thanks. -- Bastien
Re: [O] IMAP support for VM links in orgmode (org-vm.el)
Hi Konrad, Konrad Hinsen writes: > The attached patch (relative to yesterday's state of the orgmode git > repository) adds the possibility to have org-mode links to IMAP folders in > VM and to messages inside IMAP folders. It requires VM 8.2.0a or > later. The patch looks good to me. Did you sign FSF papers? If not, I cannot apply the patch, as it is non-trivial... I'm not a VM user myself, so please VM folks test this patch and report any problem. Best, -- Bastien
Re: [O] [bug] Table editing is enabled in source code blocks!
Hi Sébastien, "Sebastien Vauban" writes: > "Table editing" comes into play when editing source code blocks! Fixed, thanks. -- Bastien
Re: [O] links to headline in LaTeX export
On 20 Jan 2012, at 15:42, Thomas S. Dye wrote:
Aloha Alan,
Your LaTeX output indicates that this setting:
(setq org-export-latex-hyperref-format "\\ref{%s}")
hasn't taken effect for one reason or another.
What do you get with C-h v org-export-latex-hyperref-format RET?
I get what I would expect:
org-export-latex-hyperref-format's value is "\\ref{%s}"
For some reason it is not taken into account, and I'll have to
investigate why. I'm exporting doing "C-c @" to choose the sub-tree to
export, then "C-c C-e l" to get the LaTeX.
Alan
[O] [bug] :eval header argument ignored in the #+call: block
Suppose I have a code block foo, and I want to call it several times
in my org file. However, foo may be a slow function, and so any time
I evaluate buffer non-interactively (e.g. HTML export) I want to
enable only one out of many calls to :foo
The following doesn't work, but I think it should, since the #+call:
line should run foo with the header argument :eval no-export
#+NAME: foo
#+BEGIN_SRC R :var turn_on_output="FALSE"
if(turn_on_output) { X11() }
#+END_SRC
#+CALL: foo[:eval no-export](turn_on_output="TRUE") ## this STILL
evaluates on export
Furthermore, a better solution to the situation I described above
might be to set the :eval no-export header argument in the source
block definition, and then over-ride it in the one #+call line that I
want to run during export. Unfortunately, it doesn't seem that this
is currently possible.
--Leo
Re: [O] links to headline in LaTeX export
"Alan Schmitt" writes:
> Hello,
>
> I'm trying to have links (in the form of \ref and \label) work in
> LaTeX export, but I cannot seem to succeed. I'm following the advice
> of http://orgmode.org/worg/org-tutorials/org-latex-export.html
> (section 16). I have two problems with my links: first I would like
> the text to be the section number as is the usual in LaTeX, and second
> the links sometimes point to the wrong place. This second problem
> seems to occur when the target is after the source.
>
> Here is a small input showing the problem:
>
> * Title
>
> ** Section 1
>
> Text.
>
> ** Section 2
>
> I would like a link to [[Section%201][Section 1]] or [[Section 3]].
>
> ** Section 3
>
> I would like a link to [[Section%202][Section 2]].
>
>
>
> Exporting to LaTeX gives:
>
> % Created 2012-01-20 Fri 11:05
> \documentclass[11pt]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{soul}
> \usepackage{amssymb}
> \usepackage{hyperref}
>
>
> \title{test}
> \author{Alan Schmitt}
> \date{20 January 2012}
>
> \begin{document}
>
> \maketitle
>
> \setcounter{tocdepth}{3}
> \tableofcontents
> \vspace*{1cm}
> \section{Title}
> \label{sec-1}
>
>
> \subsection{Section 1}
> \label{sec-1.1}
>
>
> Text.
>
> \subsection{Section 2}
> \label{sec-1.2}
>
>
> I would like a link to \hyperref[sec-1.1]{Section 1} or
> \hyperref[sec-1.2]{Section 3}.
>
> \subsection{Section 3}
> \label{sec-1.3}
>
>
> I would like a link to \hyperref[sec-1.2]{Section 2}.
>
> \end{document}
>
> Any suggestion?
>
> Thanks,
>
> Alan
>
>
Aloha Alan,
Your LaTeX output indicates that this setting:
(setq org-export-latex-hyperref-format "\\ref{%s}")
hasn't taken effect for one reason or another.
What do you get with C-h v org-export-latex-hyperref-format RET?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] links to headline in LaTeX export
On 20 Jan 2012, at 12:05, Eric S Fraga wrote: "Alan Schmitt" writes: Hello, I'm trying to have links (in the form of \ref and \label) work in LaTeX export, but I cannot seem to succeed. I'm following the advice You could always do this directly using label and ref explicitly? See attached org document. This may not be the ideal solution but at least it works and is fairly unobtrusive... Thanks a lot. It works great and solves both issues. It's not as pretty as a real link, but it will clearly do until I understand better how LaTeX export works. Alan
Re: [O] links to headline in LaTeX export
"Alan Schmitt" writes:
> Hello,
>
> I'm trying to have links (in the form of \ref and \label) work in
> LaTeX export, but I cannot seem to succeed. I'm following the advice
You could always do this directly using label and ref explicitly? See
attached org document. This may not be the ideal solution but at least
it works and is fairly unobtrusive...
HTH,
eric
* Introduction
#+LaTeX: \label{sec1}
This is some introductory text.
* Methodology
Here we describe what we actually did to address the problem described in \ref{sec1}.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.163.gbded9)
[O] links to headline in LaTeX export
Hello,
I'm trying to have links (in the form of \ref and \label) work in LaTeX
export, but I cannot seem to succeed. I'm following the advice of
http://orgmode.org/worg/org-tutorials/org-latex-export.html (section
16). I have two problems with my links: first I would like the text to
be the section number as is the usual in LaTeX, and second the links
sometimes point to the wrong place. This second problem seems to occur
when the target is after the source.
Here is a small input showing the problem:
* Title
** Section 1
Text.
** Section 2
I would like a link to [[Section%201][Section 1]] or [[Section 3]].
** Section 3
I would like a link to [[Section%202][Section 2]].
Exporting to LaTeX gives:
% Created 2012-01-20 Fri 11:05
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{amssymb}
\usepackage{hyperref}
\title{test}
\author{Alan Schmitt}
\date{20 January 2012}
\begin{document}
\maketitle
\setcounter{tocdepth}{3}
\tableofcontents
\vspace*{1cm}
\section{Title}
\label{sec-1}
\subsection{Section 1}
\label{sec-1.1}
Text.
\subsection{Section 2}
\label{sec-1.2}
I would like a link to \hyperref[sec-1.1]{Section 1} or
\hyperref[sec-1.2]{Section 3}.
\subsection{Section 3}
\label{sec-1.3}
I would like a link to \hyperref[sec-1.2]{Section 2}.
\end{document}
Any suggestion?
Thanks,
Alan
Re: [O] [bug] Tables in lists not exported to ODT
Jambunathan K writes: >> One comment: for tables that are indented, it probably makes sense to >> have the table take up 100% of the width available to it? > > Do you want to maximize the real-estate available for tables - indented > or otherwise. > > Indentation for tables consume some real estate. Are you saying that you > want no indentation for tables AND have them occupy 100% of paper-width > (save for margins). > >> In any case, is there an easy way to customise this from within >> LibreOffice? I note that, in etc/styles/OrgOdtContentTemplate.xml, >> you have defined OrgTable with 96% for the width but I have no idea >> how to change that value from within LibreOffice. > > I am open to bumping the number to 100% by default, if that makes the > exporter more usable. > > Btw, I was trying to make the tables cute-looking (i.e., have them > occupy just the right amount of space) There is no easy way to do it > from within org-odt + LibreOffice combo. I understand what you were trying to do! And I think that, for general tables, you have taken the right approach. It is just that for tables within an indented environment, i.e. a list, the result is not as pretty. However, given your description of the limitations imposed by Oasis etc., I think it would be best to keep things as they are as the general use will benefit from your current style decisions. Oh, and many thanks for explaining the way that ODT styling and so on works. Very helpful. [...] > Based on your (LaTeX) experience, what is the best way to typeset > tables. Should they be put in a frame and configurable as floats? There are two use cases: floating tables with captions etc and inline tables. In latex, both use the tabular (and other similar) environment for the actual table contents. This is then encapsulated within a table environment if a floating table is desired. In both cases, tables will take up as much width as required by the contents of the table and, by default, columns will be just as wide individually as necessary for their respective contents. A tabular environment is formatted as a character and so will only be centred if that is specified for the paragraph it is in. The table environment will centre the tabular environment within its floating environment. Anyway, with respect to formatting, I think you have made the right choices, given the limitations you have to work under, so I recommend you leave things as they are! The results are perfectly fine and look good in the majority of cases, IMO. Whether a table should be in a floating environment or not is more difficult to answer. My instinctive reaction is to say that they should be. However, my experience (limited) with MS Word and LibreOffice leads me to think that this causes problems in general. I find the behaviour of floating frames in word processors to be somewhat unpredictable and difficult to control, but that could simply be me! ;-) Others may be better placed to voice an opinion in this case. Thanks again, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.8.03 (release_7.8.03.163.gbded9)
