Re: [O] Exporting source code blocks as LaTeX figures

2013-05-20 Thread Thomas S. Dye
Aloha James,

James Harkins jamshar...@gmail.com writes:

 On Sat, May 18, 2013 at 3:39 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 instead? I.e., why don't you apply caption to src block? You can tweak
 the position of the caption with captionpos option in listings
 environment.

 Wow, I hadn't thought of that. Actually that works better in a lot of ways.

 Then the next problem... I'm going to have some figures that need to
 span two columns. According to [1], I should use \begin{figure*} ...
 \end{figure*}. Is there a way to do that using a special block? (First
 guess, #+BEGIN_figure* causes the special block not to be
 recognized.) Or do I need to write the literal LaTeX code for that?


No, you don't need to write literal LaTeX code. See Section 12.7.4 of
the manual, which describes setting the :float attribute to
'multicolumn'.

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com



Re: [O] Exporting source code blocks as LaTeX figures

2013-05-20 Thread James Harkins
On Mon, May 20, 2013 at 2:30 PM, Thomas S. Dye t...@tsdye.com wrote:
 Then the next problem... I'm going to have some figures that need to
 span two columns. According to [1], I should use \begin{figure*} ...
 \end{figure*}. Is there a way to do that using a special block? (First
 guess, #+BEGIN_figure* causes the special block not to be
 recognized.) Or do I need to write the literal LaTeX code for that?

 No, you don't need to write literal LaTeX code. See Section 12.7.4 of
 the manual, which describes setting the :float attribute to
 'multicolumn'.

That section of the manual seems to describe the behavior for images. I did try:

#+ATTR_LaTeX: :multicolumn :options [htb]
#+BEGIN_figure
...
#+END_figure

... and :multicolumn had no effect on the output LaTeX code (either
with or without the preceding : -- I tried both):

\begin{figure}[htb]
\lstset{language={},label=code1,caption={Some code},numbers=none}
\begin{lstlisting}
// SuperCollider code here
.
\end{lstlisting}
\end{figure}

Nor does this make a difference:

#+ATTR_LaTeX: :float multicolumn :options [htb]
#+BEGIN_figure

And if I omit BEGIN_figure altogether, and try to apply :float
directly to the source code block, then the floating environment
doesn't appear in the LaTeX code at all.

The other reference to multicolumn is for table export, and this isn't
a table either. So I think, as currently designed, :multicolumn simply
doesn't apply.

I'm aware that BEGIN_figure delimits a special block which
translates into LaTeX as an arbitrary environment, and not all
environments can be floated safely... but perhaps one approach for the
future would be to consider BEGIN_figure to be an extra-special
special block where we know that the properties of LaTeX floating
bodies are valid.

Or relax the restriction so that BEGIN_figure* no longer tries to
treat _ as a subscript marker.

hjh



Re: [O] Bug: html quoting tags are transformed after exporting [8.0.2 (8.0.2-10-g3e1d83-elpa @ d:/SDTs/Emacs/lisp/org/)]

2013-05-20 Thread Kelvin Hu
Hi,

Thanks for your quick replies, I have not subscribed the org mailing list
yet, so I had to search this mailing list and then found your nice
solution, and sorry for the late reply.

Usually I read org manual through org mode's official website, seems now
the description of html quoting(
http://orgmode.org/org.html#Quoting-HTML-tags) is still unchanged, maybe
some extra effort is needed to update this page?

and I noticed the patch is modifying **org.texi**, but I cannot find it in
my org mode package (I installed org mode through emacs' package management
system), so where can I find this file?

Thanks in advance,
Kelvin


Re: [O] CDLaTeX (4.0) not working in Org mode (8.0.3)?

2013-05-20 Thread Longmin WANG
On Mon, May 20, 2013 at 11:14 AM, Omid omidl...@gmail.com wrote:

 I see the following strange behavior from Org-CDLaTeX (OCDL).

 Outside a * heading it works. Inside a * heading (or anything under that)
 it does NOT work. What can be causing this?

 Here is a minimal example:

 # Org CDLaTeX (OCDL) works here (at least does not issue an error)
 \[
 x^2
 \]

 * heading
 ** subheading
# Org CDLaTeX (OCDL) does NOT work here. Pressing ^ (caret) or _
# (underscore) causes the following error to appear in *Messages*
# buffer:
#
# call-interactively: Symbol's value as variable is void:
# last-command-char
\[
x
\]
# Same error here.
\begin{align*}
x
\end{align*}


last-command-char should be changed to last-command-event in cdlatex.el.

-- 
Longmin Wang (http://wanglm.droppages.com/)
Nankai University, 94 Weijin Road, Tianjin 300071, P. R. China
http://math.nankai.edu.cn/~wanglm/


Re: [O] Exporting source code blocks as LaTeX figures

2013-05-20 Thread Nicolas Goaziou
Hello,

James Harkins jamshar...@gmail.com writes:

 The other reference to multicolumn is for table export, and this isn't
 a table either. So I think, as currently designed, :multicolumn simply
 doesn't apply.

Correct. The first attached patch implements :float multicolumn
and :float figure handling for source blocks. Would you mind to test it?

 I'm aware that BEGIN_figure delimits a special block which
 translates into LaTeX as an arbitrary environment, and not all
 environments can be floated safely... but perhaps one approach for the
 future would be to consider BEGIN_figure to be an extra-special
 special block where we know that the properties of LaTeX floating
 bodies are valid.

The second patch introduces :starred attribute for special blocks in
latex back-end, e.g.,

  #+attr_latex: :starred t :options [b]
  #+begin_figure
  something
  #+end_figure

I think it could be useful. Do you?


Regards,

-- 
Nicolas Goaziou
From cbc4a3a0b98cab9455bd7d3bd8b0ea8bfe8ea34e Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Mon, 20 May 2013 10:43:18 +0200
Subject: [PATCH 1/2] ox-latex: Implement :float attribute for source blocks

* lisp/ox-latex.el (org-latex-src-block): Handle :float attribute. Its
  value can be set to figure, multicolumn or nil.

This needs to be documented in Org manual.
---
 lisp/ox-latex.el | 142 +++
 1 file changed, 80 insertions(+), 62 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 41cf1d0..669c84b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2073,21 +2073,27 @@ contextual information.
 			(continued (org-export-get-loc src-block info))
 			(new 0)))
 	   (retain-labels (org-element-property :retain-labels src-block))
-	   (long-listing
-	(let ((attr (org-export-read-attribute :attr_latex src-block)))
-	  (if (plist-member attr :long-listing)
-		  (plist-get attr :long-listing)
-		org-latex-long-listings
+	   (attributes (org-export-read-attribute :attr_latex src-block))
+	   (long-listing (if (plist-member attributes :long-listing)
+			 (plist-get attributes :long-listing)
+			   org-latex-long-listings))
+	   (float (plist-get attributes :float)))
   (cond
;; Case 1.  No source fontification.
((not org-latex-listings)
 	(let* ((caption-str (org-latex--caption/label-string src-block info))
-	   (float-env (and (not long-listing)
-			   (or label caption)
-			   (format \\begin{figure}[H]\n%s%%s\n\\end{figure}
-   caption-str
+	   (float-env
+		(cond (long-listing %s)
+		  ((string= multicolumn float)
+		   (format \\begin{figure*}[%s]\n%s%%s\n\\end{figure*}
+			   org-latex-default-figure-position
+			   caption-str))
+		  ((or label caption (string= figure float))
+		   (format \\begin{figure}[H]\n%s%%s\n\\end{figure}
+			   caption-str))
+		  (t %s
 	  (format
-	   (or float-env %s)
+	   float-env
 	   (concat (format \\begin{verbatim}\n%s\\end{verbatim}
 			   (org-export-format-code-default src-block info))
;; Case 2.  Custom environment.
@@ -2097,46 +2103,52 @@ contextual information.
 			   custom-env))
;; Case 3.  Use minted package.
((eq org-latex-listings 'minted)
-	(let ((float-env
-	   (and (not long-listing)
-		(or label caption)
-		(format \\begin{listing}[H]\n%%s\n%s\\end{listing}
-			(org-latex--caption/label-string src-block info
-	  (body
-	   (format
-		\\begin{minted}[%s]{%s}\n%s\\end{minted}
-		;; Options.
-		(org-latex--make-option-string
-		 (if (or (not num-start)
-			 (assoc linenos org-latex-minted-options))
-		 org-latex-minted-options
-		   (append `((linenos)
-			 (firstnumber ,(number-to-string (1+ num-start
-			   org-latex-minted-options)))
-		;; Language.
-		(or (cadr (assq (intern lang) org-latex-minted-langs)) lang)
-		;; Source code.
-		(let* ((code-info (org-export-unravel-code src-block))
-		   (max-width
-			(apply 'max
-			   (mapcar 'length
-   (org-split-string (car code-info)
-			 \n)
-		  (org-export-format-code
-		   (car code-info)
-		   (lambda (loc num ref)
-		 (concat
-		  loc
-		  (when ref
-			;; Ensure references are flushed to the right,
-			;; separated with 6 spaces from the widest line
-			;; of code.
-			(concat (make-string (+ (- max-width (length loc)) 6)
-	 ?\s)
-(format (%s) ref)
-		   nil (and retain-labels (cdr code-info)))
+	(let* ((caption-str (org-latex--caption/label-string src-block info))
+	   (float-env
+		(cond (long-listing %s)
+		  ((string= multicolumn float)
+		   (format \\begin{listing*}\n%%s\n%s\\end{listing*}
+			   caption-str))
+		  ((or label caption (string= figure float))
+		   (format \\begin{listing}[H]\n%%s\n%s\\end{listing}
+			   caption-str))
+		  (t %s)))
+	   (body
+		(format
+		 \\begin{minted}[%s]{%s}\n%s\\end{minted}
+		 ;; 

Re: [O] CDLaTeX (4.0) not working in Org mode (8.0.3)?

2013-05-20 Thread Omid
Thanks. I confirm that this in fact solves the problem.


On Mon, May 20, 2013 at 3:57 AM, Longmin WANG longminw...@gmail.com wrote:



 On Mon, May 20, 2013 at 11:14 AM, Omid omidl...@gmail.com wrote:

 I see the following strange behavior from Org-CDLaTeX (OCDL).

 Outside a * heading it works. Inside a * heading (or anything under that)
 it does NOT work. What can be causing this?

 Here is a minimal example:

 # Org CDLaTeX (OCDL) works here (at least does not issue an error)
 \[
 x^2
 \]

 * heading
 ** subheading
# Org CDLaTeX (OCDL) does NOT work here. Pressing ^ (caret) or _
# (underscore) causes the following error to appear in *Messages*
# buffer:
#
# call-interactively: Symbol's value as variable is void:
# last-command-char
\[
x
\]
# Same error here.
\begin{align*}
x
\end{align*}


 last-command-char should be changed to last-command-event in cdlatex.el.

 --
 Longmin Wang (http://wanglm.droppages.com/)
 Nankai University, 94 Weijin Road, Tianjin 300071, P. R. China
 http://math.nankai.edu.cn/~wanglm/



Re: [O] Org 8.0 HTML Export

2013-05-20 Thread Suvayu Ali
Hi Scott,

On Sun, May 19, 2013 at 09:08:18PM -0400, Scott Randby wrote:
 I'm working on switching to 8.0 and I'm having a few difficulties. I use
 my own style sheet for web pages, and I figured out that I needed to
 change #+STYLE: to #+HTML_HEAD: in order to use my style sheet. However,
 I don't want to include the default style and the default script when I
 export. I've been looking around in the ORG-NEWS file and the
 documentation, but I don't see anything different than what I have now.
 I have this in my init.el:
 
 (setq org-export-html-style )
 (setq org-export-html-style-include-default nil)
 (setq org-export-html-style-include-scripts nil)
 (setq org-export-html-table-tag table)
 
 What do I need to change?

http://orgmode.org/worg/org-8.0.html#sec-5

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] Org-mode styled beamer presentations

2013-05-20 Thread Suvayu Ali
Hi Marcin and Rasmus,

On Mon, May 20, 2013 at 02:33:13AM +0200, Rasmus wrote:
 Marcin Borkowski mb...@wmi.amu.edu.pl writes:
  https://twitter.com/marcin_mbork/status/335890494980767746
  http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29
  https://github.com/mbork/beamerorgtheme
 
 Excellent!  It reminds me of brain-damage.sty ¹ :)
 
 Here's Marcin's pdf example:
 
http://mbork.pl/download/Slides_about_LaTeX_editing.pdf

This is beautiful!  I think I'll use it sometime.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.



[O] [patch] ox-latex.el: support for pgf files

2013-05-20 Thread Rasmus
This patch adds support for pgf files.  pgf is the machine upon which
tikz is build.  For instance matplotlib (of Python) and printpgf (of
Octave) both produces pgf files.  It's just a question of recognizing
the extension.  With this patch the following document exports
correctly:

#+TITLE: PGF test
#+LATEX_HEADER: \usepackage{pgf}
#+BEGIN_SRC emacs-lisp :exports none
  (set (make-local-variable 'org-latex-pdf-process)
   '(xelatex -pdf %f))
#+END_SRC
#+BEGIN_SRC python :results raw :exports results
  from matplotlib import pylab as plt
  x, y = plt.rand(2)
  plt.scatter(x, y)
  fig = test.pgf
  plt.savefig(fig) ## utf8 by default
  return(.join([[[file:, fig, ]]]))
#+END_SRC

–Rasmus

-- 
Hooray!From ff4f43378779eb557213df1cd474a5232333af7d Mon Sep 17 00:00:00 2001
From: rasmus.pank rasmus.p...@gmail.com
Date: Mon, 20 May 2013 11:58:47 +0200
Subject: [PATCH] Support for pgf files in ox-latex.el

	* ox-latex.el: pgf is recognized as an inline image and
	treated the same way tikz files.

Python matplotlib and pgfprint for Octave generates pgf plots
rather than TiKZ plots.  They need just be included via \input{.}.

TINYCHANGE
---
 lisp/ox-latex.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 41cf1d0..fdada8b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -420,7 +420,7 @@ environment.
   :type 'string)
 
 (defcustom org-latex-inline-image-rules
-  '((file . \\.\\(pdf\\|jpeg\\|jpg\\|png\\|ps\\|eps\\|tikz\\)\\'))
+  '((file . \\.\\(pdf\\|jpeg\\|jpg\\|png\\|ps\\|eps\\|tikz\\|pgf\\)\\'))
   Rules characterizing image files that can be inlined into LaTeX.
 
 A rule consists in an association whose key is the type of link
@@ -1739,7 +1739,7 @@ used as a communication channel.
 		(if (not (string-match \\`\\[\\(.*\\)\\]\\' opt)) opt
 		  (match-string 1 opt
 	 image-code)
-(if (equal filetype tikz)
+(if (member filetype '(tikz pgf))
 	;; For tikz images:
 	;; - use \input to read in image file.
 	;; - if options are present, wrap in a tikzpicture environment.
-- 
1.8.2.3



Re: [O] [patch] ox-latex.el: support for pgf files

2013-05-20 Thread Rasmus
Rasmus ras...@gmx.us writes:

 For instance matplotlib (of Python) and printpgf (of Octave) both
 produces pgf files.

Looking over files, printpgf actually produces TiKZ and /not/ pgf
files, it seems.  My apology.  (But matplotlib does use pgf).

–Rasmus

-- 
I almost cut my hair, it happened just the other day




Re: [O] Build fail with emacs 24.3.1

2013-05-20 Thread Bastien
Hi Achim,

Achim Gratz strom...@nexgo.de writes:

 Bastien writes:
 Aside from the issue of whether using macros here is needed or
 appropriate, I can't find anything wrong with the macros or their use so
 far.  If that upholds, the test not working points to a rather
 substantial bug in either the test framework or Emacs 24.3. 

 It's not too late to explore this.

 This has been whittled down to a small test case after reverting the
 changes locally and finally reported as Emacs bug #14422.

Thanks for narrowing down the problem and reporting it as a bug.

For the record: independantly of the problem, I think it's better
to use defuns instead of macros in Org's code for this.

Best,

-- 
 Bastien



[O] Possible bug with new exporter and org-babel

2013-05-20 Thread giles
I came across this issue whilst trying to use or to generate some
release notes in a prettier format.

Start with an  org file consisting of only two lines:

* Noddy
call_req()

Then export to LaTeX C-c C-e l o

This fails with the message:

org-babel-ref-resolve: Reference 'req' not found in this buffer

I've just updated to current github head and the issue remains.


-- 
Giles Chamberlin




Re: [O] Org 8.0 HTML Export

2013-05-20 Thread Scott Randby
On 05/20/2013 05:22 AM, Suvayu Ali wrote:
 Hi Scott,
 
 On Sun, May 19, 2013 at 09:08:18PM -0400, Scott Randby wrote:
 I'm working on switching to 8.0 and I'm having a few difficulties. I use
 my own style sheet for web pages, and I figured out that I needed to
 change #+STYLE: to #+HTML_HEAD: in order to use my style sheet. However,
 I don't want to include the default style and the default script when I
 export. I've been looking around in the ORG-NEWS file and the
 documentation, but I don't see anything different than what I have now.
 I have this in my init.el:

 (setq org-export-html-style )
 (setq org-export-html-style-include-default nil)
 (setq org-export-html-style-include-scripts nil)
 (setq org-export-html-table-tag table)

 What do I need to change?
 
 http://orgmode.org/worg/org-8.0.html#sec-5
 
 Hope this helps,
 

Thanks, that worked.

Scott Randby



[O] Switch org-agenda-get-* defuns to operate on date ranges

2013-05-20 Thread Jonas Hörsch
hello everyone,

i've just started to use calfw to get a nice calendar-like display of my
agenda. unfortunately i was slighly dismayed at the build-up speed
easily exceeding a few seconds on my not so packed schedule. profiling
into the code i found that the problem mainly is:

there exists only the possibility to retrieve agenda data for one day
day, org-agenda.el's org-agenda-get-day-entries, rather than for a range
of days. this makes it necessary to loop over --get-day-entries to collect
all entries to show in the monthly calendar.

--get-day-entries for its part has to parse (basically regex-search
through) the respective org agenda file completely on each invocation;
effectively done by org-agenda-get-{todos,blocks,sexps,...}.

i imagine it is quite feasible to implement
(defun org-agenda-get-entries (file beg end rest args) ...)
to sift through FILE but once and return an alist like
((date . (entry1 entry2 ..)) ..)
containing all entries between dates BEG and END, inclusive.

neglecting the extra overhead for sorting entries into the alist, this
promises to speed up typical weekly agenda collection by a factor of 7
and calfw even by a factor of approx. 30, shouldn't it?

before i start a local branch to try myself on this refactoring work,
i'd welcome a few comments, why i should be likely to fail or succeed!

cheers,
jonas




Re: [O] Tbl: precision for cells

2013-05-20 Thread Darlan Cavalcante Moreira

If everything fail you can always process the table with babel to create a
new table the way you like. You could add a function for that to the
library of babel to have it always available.

It is less convenient then a format specifier for the whole table as you
want, but it is a very powerful and flexible way.

--
Darlan

At Sun, 19 May 2013 16:05:33 +0200,
Suvayu Ali wrote:
 
 On Sun, May 19, 2013 at 06:11:03AM +0200, Manfred Lotz wrote:
  
  I know that I could add ;%.2f to each formula in the table. However, I
  would like to specify %.2f only one time for the whole table. 
 
 The format specifier is per formula.  I do not know of any way to have a
 per table format specifier, sorry.
 
 Cheers,
 
 -- 
 Suvayu
 
 Open source is the future. It sets us free.
 



Re: [O] Possible bug with new exporter and org-babel

2013-05-20 Thread Eric Schulte
Where *is* req defined?  So far the behavior you describe seems
expected.

Thanks,

gi...@pexip.com writes:

 I came across this issue whilst trying to use or to generate some
 release notes in a prettier format.

 Start with an  org file consisting of only two lines:

 * Noddy
 call_req()

 Then export to LaTeX C-c C-e l o

 This fails with the message:

 org-babel-ref-resolve: Reference 'req' not found in this buffer

 I've just updated to current github head and the issue remains.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] Possible bug with new exporter and org-babel

2013-05-20 Thread giles
Eric Schulte schulte.e...@gmail.com writes:

 Where *is* req defined?  So far the behavior you describe seems
 expected.

Sorry for the ambiguity - req isn't defined!

Let me explain a little more clearly: I'm trying to generate some
release notes using org-mode, pulling data from the github issue
tracking system.  I'm really just using org as a text markup
language. One comment in the issue tracker included a stack trace of the
form

  /foo/bar/call_req() 

where call_req is a function defined in our (non-org) code.  The
presence of this plain text string in the body of my org document causes
exporting to fail.

I'm not familiar with either the new exporter or the details of babel
(though a happy user of it), but my expected behaviour would be that any
babel cleverness would require more to invoke it than just call_foo()
or that there would be some means to say, on a document by document
basis do not invoke babel

In any event: is there a way I can include the phrase call_req() in
the plain body of my document? Ideally without escaping it, but so so be
it.

Thanks for your patience.


-- 
Giles Chamberlin




Re: [O] [patch] ox-koma-letter.el: credit [1/4]

2013-05-20 Thread Alan Schmitt
Rasmus writes:

 This one just updates the credit: most importantly with Viktor.

This is a great idea, however you seem to have forgotten the patch.

Alan



Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

2013-05-20 Thread Alan Schmitt
Hello Rasmus,

Rasmus writes:

 This could be a problematic change.  It changes the way :with-subject
 works.  I've added changes to allow the subject style to be choose as
 a radio list with customize.  The reason is that LaTeX becomes unhappy
 if it is not a supported value.  If #+OPTIONS subject:t the default is
 used.  If #+OPTIONS subject:my-crazy-string it tries that and most
 likely hell will break loose.

 Viktor, you're usage of ox-koma-letter.el is quite different from mine
 in that you rely (heavily?) on LCO files.  If you could test this and
 see what you think of it it would be great.  On my system it doesn't
 break anything vital but I might have missed something.  

According to my very limited emacs-lisp knowledge, this looks fine. I
would suggest a couple renamings:

beavior - behavior
fteropening - afteropening
No-export - noexport (so that it looks like the other ones).

Best,

Alan



Re: [O] [patch] ox-koma-letter.el: credit [1/4]

2013-05-20 Thread Rasmus
Alan Schmitt alan.schm...@polytechnique.org writes:

 Rasmus writes:

 This one just updates the credit: most importantly with Viktor.

 This is a great idea, however you seem to have forgotten the patch.

Right.  Need to figure out that git email program . . . 

-- 
⠠⠵From 4dfe8ba80661c4e35c9f3de8313b8ddef65846a3 Mon Sep 17 00:00:00 2001
From: rasmus.pank ras...@gmx.us
Date: Sun, 19 May 2013 15:43:24 +0200
Subject: [PATCH 1/4] Updated author list of ox-koma-letter.el

* ox-koma-letter.el: added Viktor Rosenfeld and Rasmus as
contributors to ox-koma-letters.el.

TINYCHANGE
---
 contrib/lisp/ox-koma-letter.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 96c0569..2389025 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -4,6 +4,9 @@

 ;; Author: Nicolas Goaziou n.goaziou AT gmail DOT com
 ;; Alan Schmitt alan.schmitt AT polytechnique DOT org
+;; Viktor Rosenfeld listuser36 AT gmail DOT com
+;; Rasmus Pank Roulund emacs AT pank DOT eu
+
 ;; Keywords: org, wp, tex

 ;; This program is free software: you can redistribute it and/or modify
@@ -265,7 +268,7 @@ holding export options.
 	 (signature (plist-get info :signature)))
  (concat
   ;; Letter Class Option File
-  (when lco
+  (when lco
 	(let ((lco-files (split-string lco  ))
 	  (lco-def ))
 	  (dolist (lco-file lco-files lco-def)
--
1.8.2.3


Re: [O] [patch] ox-koma-letter.el: credit [3/4]

2013-05-20 Thread Alan Schmitt
Hello again,

Rasmus writes:

 This is probably the most fun change.  It adds special tags PS, ENCL,
 CC, AFTER_CLOSING as in my last patch set, but it uses heading this
 time.  E.g. ENCLs are under the heading * ENCL :ENCL:.  This was
 suggested by Nicolas, and it's nicer.  The ideas comes from
 ox-groff.el file¹.  Thanks Luis!

This is great, thanks. I'd like to have the opinion of others on the
code, but I very much welcome this change.

 One thing I'd like to discuss is whether to adopt headings for TO and
 FROM also.  The Groff exporter already does so for it's letters.  The
 main benefit is that it allows for org-syntax.  IMO it's a lot nicer
 to look at as well.  Check the org-groff site in the footnote for an
 example.

 I'd be happy to look into this the next time I have a free day for
 programming if you guys (also) find in a more appealing.  (One
 additional benefit would be that for simple documents it wouldn't
 matter whether groff or scrlttr2 was used as backend).

This would be very helpful indeed.

Alan



Re: [O] M-RET and C-RET turn current line of text into a heading?

2013-05-20 Thread John Hendy
On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote:

 Hi,

 My user input is partially to blame for this, I think. See toward the
 end of this thread:

 http://comments.gmane.org/gmane.emacs.orgmode/69794

 I was under the impression that the behavior of M-RET had changed, but I
 may have given a wrong or incomplete description of the old behavior I
 seemed to remember and wanted back. I agree that the current behavior
 does not seem ideal either.

 Here's some more misguided user input: Wouldn't it be intuitive if M-RET
 at the beginning of a line turned that line into a heading (as it
 currently does), but M-RET at the end of a line inserted a new heading
 below (would require a change from the current workings)? Not sure about
 M-RET somewhere in the middle of a line.


I've been following this thread and there has been some great
discussion about future plans for re-write and context-sensitive
functionality. In the mean time, can we revert the C-RET behavior back
to adding a new headline? I'm finding it incredibly frustration to
have no way to just add a new headline below the current contents of a
headline, even if it's folded. I'm adding some individuals to my
contact file and have no way to just M-RET or C-RET to add a new
headline quickly except to navigate and manually type a series of *'s.

If we could return one of these to the old functionality, that would
be great. (Or a recommended new way to just add a headline vs.
transforming the last line into a header.)


Thanks,
John


 Yours,
 Christian


 Eric Abrahamsen writes:

 For the past couple of weeks I'm finding that both M-RET and C-RET turn
 the line under point into a heading, instead of inserting a new heading
 elsewhere. This happens with `org-M-RET-may-split-line' set to anything.

 So this:

 #+begin_src org
 * Chapter One
 :PROPERTIES:
 :some_prop: t
 :END:
 In which not [point is here] very much happens. But this is a further test 
 to see
 what happens on multiline text.
 #+end_src

 becomes:

 #+begin_src org
 * Chapter One
 :PROPERTIES:
 :some_prop: t
 :END:
 * In which not very much happens. But this is a further test to see
 what happens on multiline text.
 #+end_src

 This also happens with emacs -Q. Has no one else seen this?

 Thanks,
 Eric





Re: [O] M-RET and C-RET turn current line of text into a heading?

2013-05-20 Thread John Hendy
On Mon, May 20, 2013 at 10:54 AM, John Hendy jw.he...@gmail.com wrote:
 On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote:

 Hi,

 My user input is partially to blame for this, I think. See toward the
 end of this thread:

 http://comments.gmane.org/gmane.emacs.orgmode/69794

 I was under the impression that the behavior of M-RET had changed, but I
 may have given a wrong or incomplete description of the old behavior I
 seemed to remember and wanted back. I agree that the current behavior
 does not seem ideal either.

 Here's some more misguided user input: Wouldn't it be intuitive if M-RET
 at the beginning of a line turned that line into a heading (as it
 currently does), but M-RET at the end of a line inserted a new heading
 below (would require a change from the current workings)? Not sure about
 M-RET somewhere in the middle of a line.


 I've been following this thread and there has been some great
 discussion about future plans for re-write and context-sensitive
 functionality. In the mean time, can we revert the C-RET behavior back
 to adding a new headline? I'm finding it incredibly frustration to
 have no way to just add a new headline below the current contents of a
 headline, even if it's folded. I'm adding some individuals to my
 contact file and have no way to just M-RET or C-RET to add a new
 headline quickly except to navigate and manually type a series of *'s.

 If we could return one of these to the old functionality, that would
 be great. (Or a recommended new way to just add a headline vs.
 transforming the last line into a header.)

Sorry for the noise. I think I just pulled on Friday, but a pull just
now and re-make seems to have returned C-RET to doing what I thought
it should. I may have pulled and never restarted my emacs session, so
it's quite possible this was fixed earlier.


Thanks for that!
John



 Thanks,
 John


 Yours,
 Christian


 Eric Abrahamsen writes:

 For the past couple of weeks I'm finding that both M-RET and C-RET turn
 the line under point into a heading, instead of inserting a new heading
 elsewhere. This happens with `org-M-RET-may-split-line' set to anything.

 So this:

 #+begin_src org
 * Chapter One
 :PROPERTIES:
 :some_prop: t
 :END:
 In which not [point is here] very much happens. But this is a further test 
 to see
 what happens on multiline text.
 #+end_src

 becomes:

 #+begin_src org
 * Chapter One
 :PROPERTIES:
 :some_prop: t
 :END:
 * In which not very much happens. But this is a further test to see
 what happens on multiline text.
 #+end_src

 This also happens with emacs -Q. Has no one else seen this?

 Thanks,
 Eric





Re: [O] [patch] ox-koma-letter.el: credit [1/4]

2013-05-20 Thread Alan Schmitt
Rasmus writes:

 Alan Schmitt alan.schm...@polytechnique.org writes:

 Rasmus writes:

 This one just updates the credit: most importantly with Viktor.

 This is a great idea, however you seem to have forgotten the patch.

 Right.  Need to figure out that git email program . . . 

I applied it. I had to edit it to remove the spurious diff at the end
for it to apply cleanly, though.

Alan



[O] Counter-intuitive behavior of org-insert-heading

2013-05-20 Thread Matt Lundin
The following commit introduced a bug in org-insert-heading.

 commit 3449c6d001b8d261b104bc9dd42bf1290d74bc0b
 Author: Bastien Guerry b...@altern.org
 Date:   Thu Apr 11 00:35:31 2013 +0200
 
 org.el (org-insert-heading): Convert the current line into a headline
 
 * org.el (org-insert-heading-respect-content): Fix docstring.
 (org-insert-heading): When in a non-empty non-headline line,
 convert the current line into a headline.
 
 Thanks to Bernt Hansen for reporting this issue

I have org-insert-heading-respect-content set to nil.

Previously, when hit M-Ret at the end of a line, a new headline was
created on the next line. Pressing return at the end of the line
containing the date would result in a new headline, as expected. E.g.,

* A heading
  [2013-05-20 Mon 11:02]

...would become

* A heading
  [2013-05-20 Mon 11:02]
* 

... with the cursor placed after the new asterisk

And if the cursor was at the end of a folded headline, such as.

* A heading...

...a new heading would be created as expected...

* A heading...
*

With the commit above, however, the following happens when I hit the
cursor at the end of the line:

* A heading
* [2013-05-20 Mon 11:02]

And with a folded headline, the same thing happens. When the cursor is 
placed after the invisible section and I hit M-Ret:

* A heading...

...unfolds and becomes...

* A heading
* [2013-05-20 Mon 11:02]

Best,
Matt




Re: [O] M-RET and C-RET turn current line of text into a heading?

2013-05-20 Thread Matt Lundin
John Hendy jw.he...@gmail.com writes:

 On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote:

 I've been following this thread and there has been some great
 discussion about future plans for re-write and context-sensitive
 functionality. In the mean time, can we revert the C-RET behavior back
 to adding a new headline? I'm finding it incredibly frustration to
 have no way to just add a new headline below the current contents of a
 headline, even if it's folded. I'm adding some individuals to my
 contact file and have no way to just M-RET or C-RET to add a new
 headline quickly except to navigate and manually type a series of *'s.

 If we could return one of these to the old functionality, that would
 be great. (Or a recommended new way to just add a headline vs.
 transforming the last line into a header.)

 Sorry for the noise. I think I just pulled on Friday, but a pull just
 now and re-make seems to have returned C-RET to doing what I thought
 it should. I may have pulled and never restarted my emacs session, so
 it's quite possible this was fixed earlier.

That's curious. It has not been fixed here with the latest git.

I reported this in another thread:

http://permalink.gmane.org/gmane.emacs.orgmode/72399

Sorry to have missed this thread.

Matt



Re: [O] Possible bug with new exporter and org-babel

2013-05-20 Thread Eric Schulte
gi...@pexip.com writes:

 Eric Schulte schulte.e...@gmail.com writes:

 Where *is* req defined?  So far the behavior you describe seems
 expected.

 Sorry for the ambiguity - req isn't defined!

 Let me explain a little more clearly: I'm trying to generate some
 release notes using org-mode, pulling data from the github issue
 tracking system.  I'm really just using org as a text markup
 language. One comment in the issue tracker included a stack trace of the
 form

   /foo/bar/call_req() 

 where call_req is a function defined in our (non-org) code.  The
 presence of this plain text string in the body of my org document causes
 exporting to fail.

 I'm not familiar with either the new exporter or the details of babel
 (though a happy user of it), but my expected behaviour would be that any
 babel cleverness would require more to invoke it than just call_foo()
 or that there would be some means to say, on a document by document
 basis do not invoke babel


Oh, I understand now, thanks for explaining.


 In any event: is there a way I can include the phrase call_req() in
 the plain body of my document? Ideally without escaping it, but so so be
 it.


You can either set the `org-export-babel-evaluate' variable to nil,
which will inhibit all babel evaluation (this could be done using a file
local variable), or you can escape call_req() as in the attached
example.

#+Options: ^:{}

* Foo
You can avoid attempted evaluation if the call is made to be an
example (this will then export in monospace).

=call_req()=

Escaped inside a =call_req()= line of text.

Another way to escape the stack trace as an example.
: /foo/bar/call_req()


 Thanks for your patience.

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte


Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-20 Thread François Pinard
Max Mikhanosha m...@openchat.com writes:

 [...] (require 'org-screenshot) [...]

Thanks, Max, for sharing this! :-)

François

P.S. I appreciate the org-screenshot-image-directory function: by making
it easy to override, the feature has been immediately useful to me.



Re: [O] Possible bug with new exporter and org-babel

2013-05-20 Thread giles
Eric Schulte schulte.e...@gmail.com writes:

 Oh, I understand now, thanks for explaining.

I think I talk minimal example a little too far!


 In any event: is there a way I can include the phrase call_req() in
 the plain body of my document? Ideally without escaping it, but so so be
 it.

 You can either set the `org-export-babel-evaluate' variable to nil,

That's the one I need: basically a way to 'dumb down' the exporter.
Thanks .

-- 
Giles Chamberlin




Re: [O] #+ATTR_LaTeX no longer honoured

2013-05-20 Thread Daniel F
It's strange that you say that link is not up-to date (altho I can see that
the version you've linked to is also linked from the main page),
because it says here: http://orgmode.org/manual/index.html#Top

 This manual is for Org version 8.0.3 (release_8.0.3).

Is it possible to maybe put some sort of message that would say that the
manual is outdated?


On Mon, May 20, 2013 at 12:31 AM, Nicolas Goaziou n.goaz...@gmail.comwrote:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

  Paul Stansell paulstans...@gmail.com writes:
 
  Hello,
 
  I've noticed that #+ATTR_LaTeX seems to be no longer honoured (I'm
  using release_8.0.3-133-ga5872)
 
  This is demonstrated for the attached org file.  It's the exact
  example from http://orgmode.org/manual/Images-in-LaTeX-export.html.
 
  I expect the exported latex file (C-c C-e l l) to contain something like
 
\includegraphics[width=5cm,angle=90]{./dummy.png}
 
  but I instead it contains
 
\includegraphics[width=.9\linewidth]{./dummy.png}
 
  Thanks,
 
  Paul
 
  PS. I'm using Emacs 24.2.1 and I tested with the minimal org-mode
  set-up from http://orgmode.org/manual/Feedback.html.
 
  I won't even attempt to give an overview of how attribute syntax has
  changed/is changing, or explain why and how the manual is out of date,
  but while we're waiting for someone else to do that, here's the line
  you're looking for:
 
  #+ATTR_LaTeX: :width 5cm :options angle=90

 The manual is up-to-date (sections about HTML and ODT export may lag
 a bit behind), but the URL isn't. In particular, see:

   http://orgmode.org/org.html#LaTeX-specific-attributes

  Very briefly, I think attributes that may be common to multiple backends
  are now given as eg :width or :height (with no equals sign before the
  value), while attributes that are rarer or likely backend-specific are
  stuffed into one :options attribute, with the keys/values written more
  literally.

 AFAIK, :options is specific to latex back-end. Common attributes are set
 the usual way, i.e. with :attribute value syntax. Though it's
 impossible to recognize them all. So :options is handy to add raw
 arguments.

 Anyway, all attributes should be documented in the manual.


 Regards,

 --
 Nicolas Goaziou




-- 
Sincerely yours,
-- Daniil


Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

2013-05-20 Thread Rasmus

 This could be a problematic change.  It changes the way :with-subject
 works.  I've added changes to allow the subject style to be choose as
 a radio list with customize.  The reason is that LaTeX becomes unhappy
 if it is not a supported value.  If #+OPTIONS subject:t the default is
 used.  If #+OPTIONS subject:my-crazy-string it tries that and most
 likely hell will break loose.

 Viktor, you're usage of ox-koma-letter.el is quite different from mine
 in that you rely (heavily?) on LCO files.  If you could test this and
 see what you think of it it would be great.  On my system it doesn't
 break anything vital but I might have missed something.  

 According to my very limited emacs-lisp knowledge, this looks fine. 

I found a bug in that the subject variable should be a list cf. the
KOMA manual.  This patch fixes this.

It's pretty complex for something so simple, and I might be inclined
to admit to the put it in a LCO-file approach might be better.

From the commit message:

If =#+OPTIONS:subject:nil= neither =\setkomavar{subject}{.}= nor
=\KOMAoption{subject}{.}= are exported.

If =#+OPTIONS:subject:t= =`org-koma-letter-subject-format'= is used
for =\KOMAoption{subject}{.}=.

If =#+OPTIONS:subject:(x y z)= then =\KOMAoption{subject}{x,y,z}=.

 beavior - behavior
 fteropening - afteropening
 No-export - noexport (so that it looks like the other ones).

Thanks!  I should run wcheck when coding . . .

–Rasmus

-- 
Powered by magic pixies!From d11e4fd682ac593da04c3e4c8edf5eb84c9d0c59 Mon Sep 17 00:00:00 2001
From: rasmus.pank rasmus.p...@gmail.com
Date: Sun, 19 May 2013 17:32:44 +0200
Subject: [PATCH 2/4] ox-koma-letter: changed handling of subject

* ox-koma-letter.el: =`org-koma-letter-subject-format'= is now a
set list.  If nil neither subject format nor type is
exported.
* ox-koma-letter.el: allow for t value of =#+OPTIONS: subject:VALUE=
* ox-koma-letter.el: export of subject format is independent
of title, but title is not independent of =:with-subject=.

The issue was with =#+OPTIONS: subject:t= one would get a LaTeX.

New behavior:

If =#+OPTIONS:subject:nil= neither =\setkomavar{subject}{.}= nor
=\KOMAoption{subject}{.}= are exported.

If =#+OPTIONS:subject:t= =`org-koma-letter-subject-format'= is used
for =\KOMAoption{subject}{.}=.

If =#+OPTIONS:subject:(x y z)= then \KOMAoption{subject}{x,y,z}.
---
 contrib/lisp/ox-koma-letter.el | 65 ++
 1 file changed, 53 insertions(+), 12 deletions(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 2389025..6a3811f 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -6,7 +6,6 @@
 ;; Alan Schmitt alan.schmitt AT polytechnique DOT org
 ;; Viktor Rosenfeld listuser36 AT gmail DOT com
 ;; Rasmus Pank Roulund emacs AT pank DOT eu
-
 ;; Keywords: org, wp, tex
 
 ;; This program is free software: you can redistribute it and/or modify
@@ -123,10 +122,35 @@
   :group 'org-export-koma-letter
   :type 'string)
 
-(defcustom org-koma-letter-use-subject untitled
-  Use the title as the letter's subject.
-  :group 'org-export-koma-letter
-  :type 'string)
+(defcustom org-koma-letter-subject-format '(beforeopening left untitled)
+  Use the title as the subject of the letter.  At the time of
+writing the following values are allowed:
+
+ - afteropening: subject after opening
+ - beforeopening: subject before opening
+ - centered: subject centered
+ - left:subject left-justified
+ - right: subject right-justified
+ - titled: add title/description to subject
+ - underlined: set subject underlined (see note in text please)
+ - untitled: do not add title/description to subject.
+ - No-export: do no insert a subject even if present.
+
+Please refer to the KOMA-script manual (Table 4.16. in the
+English manual of 2012-07-22)
+  :type '(set   (const  afteropening)
+		(const  beforeopening)
+		(const  centered)
+		(const  left)
+		(const  right)
+		(const  underlined)
+		(const  titled)
+		(const  untitled)
+		(const :tag No export nil)
+		(string))
+  :group 'org-export-koma-letter)
+
+
 
 (defcustom org-koma-letter-use-backaddress t
   Print return address in small line above to address.
@@ -179,7 +203,7 @@ Use `foldmarks:true' to activate default fold marks or
 (:with-phone nil phone org-koma-letter-use-phone)
 (:with-email nil email org-koma-letter-use-email)
 (:with-place nil place org-koma-letter-use-place)
-(:with-subject nil subject org-koma-letter-use-subject))
+(:with-subject nil subject org-koma-letter-subject-format))
   :translate-alist '((export-block . org-koma-letter-export-block)
 		 (export-snippet . org-koma-letter-export-snippet)
 		 (keyword . org-koma-letter-keyword)
@@ -300,12 +324,29 @@ holding export options.
;; Document start
\\begin{document}\n\n
;; Subject
-   (let ((with-subject (plist-get info :with-subject)))
- (when with-subject
-   (concat
-	(format 

Re: [O] M-RET and C-RET turn current line of text into a heading?

2013-05-20 Thread John Hendy
On Mon, May 20, 2013 at 11:14 AM, Matt Lundin m...@imapmail.org wrote:
 John Hendy jw.he...@gmail.com writes:

 On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com 
 wrote:

 I've been following this thread and there has been some great
 discussion about future plans for re-write and context-sensitive
 functionality. In the mean time, can we revert the C-RET behavior back
 to adding a new headline? I'm finding it incredibly frustration to
 have no way to just add a new headline below the current contents of a
 headline, even if it's folded. I'm adding some individuals to my
 contact file and have no way to just M-RET or C-RET to add a new
 headline quickly except to navigate and manually type a series of *'s.

 If we could return one of these to the old functionality, that would
 be great. (Or a recommended new way to just add a headline vs.
 transforming the last line into a header.)

 Sorry for the noise. I think I just pulled on Friday, but a pull just
 now and re-make seems to have returned C-RET to doing what I thought
 it should. I may have pulled and never restarted my emacs session, so
 it's quite possible this was fixed earlier.

 That's curious. It has not been fixed here with the latest git.

Very curious! Your thread is exactly what I was experiencing before my
pull/make clean/make this morning. Now I'm on:

Org-mode version 8.0.3 (release_8.0.3-139-g419b69 @
/home/jwhendy/.elisp/org.git/lisp/)

It's working and I verified it several times to make sure. Indeed, as
with you, the most frustrating was it turning the last line of a
folded headline into a new headline while staying sort of folded (or,
for me, even bumping the ellipsis down below the current headline so
one couldn't unfold it anymore).

I guess I'm not sure what to say. I am experiencing what I would
expect since my last pull, so I don't really feel compelled to re-pull
to see if it's re-broken!


Best regards,
John


 I reported this in another thread:

 http://permalink.gmane.org/gmane.emacs.orgmode/72399

 Sorry to have missed this thread.

 Matt



Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-20 Thread Russell Adams
On Thu, May 16, 2013 at 11:21:56PM -0400, Max Mikhanosha wrote:
 Hi All,

 I've been writing some documentation in OrgMode with screenshots, and
 as with any screenshot taking, it takes a while to get one just right.

Max,

I use this for all screenshots. This inserts a link named by buffer
with a timestamp appended using the Imagemagick import utility, where
I can just click a window or drag an area.

(defun org-screenshot ()
  Take a screenshot into a time stamped unique-named file in the same 
directory as the org-buffer and insert a link to this file.
  (interactive)
  (setq filename (concat (make-temp-name (concat (buffer-file-name) _ 
(format-time-string %Y%m%d_%H%M%S_)) ) .png))
  (call-process import nil nil nil filename)
  (insert (concat [[ filename ]])))

What advantages would org-screenshot provide by comparison?

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3



Re: [O] Bugs in org-drill

2013-05-20 Thread Lukas Fuernkranz
Hi,

On Tue, May 14, 2013 at 5:19 PM, Ivan Kanis ban...@kanis.fr wrote:
 I tried 1.8 two weeks ago. I got two bugs in org-drill:

 1) When doing the quizz for some cards I get prompted for a date.
 2) More annoying I got entries pushed for review in 8000 days.

 1 is a nuisance, 2 made me downgrade.

 I have attached the drill file I was using.

I also encountered problem 1 and opened a bug report:
https://bitbucket.org/eeeickythump/org-drill/issue/9/org-drill-doesnt-accept-near-miss-and



Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

2013-05-20 Thread John Hendy
On Mon, May 20, 2013 at 5:15 PM, John Hendy jw.he...@gmail.com wrote:
 Sorry for the long title, but that's the summary! I fired up a fresh
 Emacs session and used =C-a s search-term RET= to navigate to a
 headline in the results by putting the cursor on the line and pressing
 RET.

 The file text was all black.

 If I visited the file directly, I had the typical color-coded text for
 headlines/keywords. I decided to replicate with a minimal config, and
 I was able to. Here's the context of the min config:

 #+begin_min-config
 ;; set load paths
 ;; set load dirs and global config options
 (add-to-list 'load-path ~/.elisp/org.git/lisp/)
 (add-to-list 'load-path ~/.elisp/org.git/contrib/lisp)
 #+end_min-config

 This was on a work file, and I couldn't initially replicate with a
 test file... but it appears it has to do with my header options.
 Here's the test file:

 #+begin_src org
 #+setupfile: ~/org/aux/setupfile.org
 #+options: :t num:t author:t creator:nil tags:t toc:nil date:t
 #+latex_header: \usepackage{lscape}
 #+latex_header: \usepackage{amsmath}

 * Test headline

 Some paragraph just to give me a keyword to search for

 ** Sub headline

 Some more text in the next headline
 #+end_src

 My process:
 - emacs -Q
 - M-x load-file RET ~/path/to/min-config RET
 - C-x C-f /path/to/file.org RET
 - C-c [ to add to agenda list
 - C-x C-k RET to kill buffer
 - M-x org-agenda RET s RET text RET
 - Navigate to test.org matching line RET
 - File looks like attached pic

 I deleted everything but my #+setupfile line and it still does that.

 Without any #+ options at the top of the file, it appears in color.


 John

As a follow up, if I directly visit the file first, it's in color.
Then, while still visiting the file, I run org-agenda s search-text
RET and navigate to where I want to go. This pops up the agenda panel
in place of the file until I select where I want to navigate. At this
point, we're still in color after going from agenda to the desired
location...

*But*, any headlines that weren't already unfolded (and shown in
color) remain in black and white. Additionally, if I change any of the
headlines that were in color, they change from fontified in color to
only black and white. I also have leading stars hidden; after editing
a headline they appear as well.

Thankfully, behavior seems normal at this point, so it's not like I'm
messing up my org file by working on it. It's just a bit jarring since
I'm so used to seeing it in color.


John



Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

2013-05-20 Thread John Hendy
On Mon, May 20, 2013 at 5:15 PM, John Hendy jw.he...@gmail.com wrote:
 Sorry for the long title, but that's the summary! I fired up a fresh
 Emacs session and used =C-a s search-term RET= to navigate to a
 headline in the results by putting the cursor on the line and pressing
 RET.

 The file text was all black.

 If I visited the file directly, I had the typical color-coded text for
 headlines/keywords. I decided to replicate with a minimal config, and
 I was able to. Here's the context of the min config:

 #+begin_min-config
 ;; set load paths
 ;; set load dirs and global config options
 (add-to-list 'load-path ~/.elisp/org.git/lisp/)
 (add-to-list 'load-path ~/.elisp/org.git/contrib/lisp)
 #+end_min-config

 This was on a work file, and I couldn't initially replicate with a
 test file... but it appears it has to do with my header options.
 Here's the test file:

 #+begin_src org
 #+setupfile: ~/org/aux/setupfile.org
 #+options: :t num:t author:t creator:nil tags:t toc:nil date:t
 #+latex_header: \usepackage{lscape}
 #+latex_header: \usepackage{amsmath}

 * Test headline

 Some paragraph just to give me a keyword to search for

 ** Sub headline

 Some more text in the next headline
 #+end_src

 My process:
 - emacs -Q
 - M-x load-file RET ~/path/to/min-config RET
 - C-x C-f /path/to/file.org RET
 - C-c [ to add to agenda list
 - C-x C-k RET to kill buffer
 - M-x org-agenda RET s RET text RET
 - Navigate to test.org matching line RET
 - File looks like attached pic

 I deleted everything but my #+setupfile line and it still does that.

Last bit of input -- when this behavior is displayed, if I C-c C-c on
my options block at the top of the file, it returns to fontified
behavior and stays that way (even if meddling with headlines). It
appears that navigating to a headline with various #+keyword lines is
not letting Org recognize something. Refreshing the setup seems to
handles this. This is on:

Org-mode version 8.0.3 (release_8.0.3-139-g419b69 @
/home/jwhendy/.elisp/org.git/lisp/)

Happy to try anything else or provide more info. For now, I think I've
made enough noise about this!


Thanks,
John


 Without any #+ options at the top of the file, it appears in color.


 John



[O] TOC in HTML export - how to change formatting of ToDo levels?

2013-05-20 Thread David Rogoff
Hi all.

I've just started diving back into org-mode.  I'm mostly using it for ToDo / 
Status tracking.  I've been trying to change the format of the TOC entries with 
little success.  I've figured out how to use org-export-html-style to change 
the CSS markup for my customized ToDo levels, but that just affects the 
formatting in the body of the document.  The table of contents appears to 
ignore that.  I've been digging through org-html.el and the TOC formatting 
(around line 1474) looks to be mostly card-coded with almost no variables to 
control anything.   Any ToDo status of done is not marked up at all and 
anything else is just marked as class todo instead of the actual class of the 
item.

Am I missing something?  The only solution I've found is to write a script to 
fix the HTML after exporting.  Any better solution?   It's a very big ToDo list 
and I (and others who will look at the document) want to see the actual status 
(preferably with the CSS font/text markups) in the TOC to know which items to 
look into for further details.

Thanks!

 David

FYI, running emacs 24.3.1 on RHEL 5.3 and org-mode 7.9.3f


Re: [O] Exporting source code blocks as LaTeX figures

2013-05-20 Thread James Harkins
On May 20, 2013 4:54 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:

 Hello,

 James Harkins jamshar...@gmail.com writes:

  The other reference to multicolumn is for table export, and this isn't
  a table either. So I think, as currently designed, :multicolumn simply
  doesn't apply.

 Correct. The first attached patch implements :float multicolumn
 and :float figure handling for source blocks. Would you mind to test it?

Sure, I can try both... but not until later today or maybe tomorrow.

Thanks!
hjh


Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-20 Thread Max Mikhanosha
At Mon, 20 May 2013 13:45:48 -0500,
Russell Adams wrote:
 I use this for all screenshots. This inserts a link named by buffer
 with a timestamp appended using the Imagemagick import utility, where
 I can just click a window or drag an area.
 
 (defun org-screenshot ()
   Take a screenshot into a time stamped unique-named file in the same 
 directory as the org-buffer and insert a link to this file.
   (interactive)
   (setq filename (concat (make-temp-name (concat (buffer-file-name) _ 
 (format-time-string %Y%m%d_%H%M%S_)) ) .png))
   (call-process import nil nil nil filename)
   (insert (concat [[ filename ]])))
 
 What advantages would org-screenshot provide by comparison?

I started with the similar function.

To me the most useful feature is actually screenshot rotation
shortcuts, that cycle image before point, with other files in the
`(org-screenshot-image-directory)'.

Taking screenshot itself and inserting link is simple I agree. 

Maybe that rotation code can be uplifted into Org itself , because I
think its probably useful for people working with a lot of image
links, not just screenshots. Another is specifying screenshot delay
by C-u prefix (C-u C-u C-u - 3 seconds), for making screenshot of menus.

I would love to add more to it, but don't have time. If someone wants
to hack on it, you welcome :-)

Some ideas are:

 1. Allow customizing the screenshot program used, ie like imagemagic

 2. Option to automatically rotate when taking a screenshot, and the
first thing before point is already an image

 3. Command to enter crop mode, where you would press arrow keys (or
jklh) and it would crop the displayed image only (emacs supports
that in properties), and then on RET will use image manipulation
program to crop it

 4. Have ability to inject screenshot via emacsclient, so that you can
bind a global shortcut instead, it feels silly to go to emacs to
take screenshot.. I prefer to make lots of screenshot first, and
then use rotate keys to select ones I like most

Regards,
  Max



[O] patch for htmlize.el

2013-05-20 Thread Eric Schulte
Hi,

I'd like to commit the following patch which improves htmlize's handling
of svg image overlays.  I couldn't find an upstream for htmlize, is it
appropriate to patch htmlize in the Org-mode source tree?

Thanks,

From 4611b177def45bf23c2cfb1caf0b12baa5e0e91b Mon Sep 17 00:00:00 2001
From: Eric Schulte schulte.e...@gmail.com
Date: Mon, 20 May 2013 18:15:05 -0600
Subject: [PATCH] export inline svg images with htmlize

---
 contrib/lisp/htmlize.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/contrib/lisp/htmlize.el b/contrib/lisp/htmlize.el
index c03d605..3bf5949 100644
--- a/contrib/lisp/htmlize.el
+++ b/contrib/lisp/htmlize.el
@@ -601,10 +601,12 @@ list.
  (htmlize-attr-escape (file-relative-name file))
  alt-attr)))
   ((plist-get imgprops :data)
-   (format img src=\data:image/%s;base64,%s\%s /
-   (or (plist-get imgprops :type) )
-   (base64-encode-string (plist-get imgprops :data))
-   alt-attr)
+	   (if (equalp (plist-get imgprops :type) 'svg)
+	   (plist-get imgprops :data)
+	 (format img src=\data:image/%s;base64,%s\%s /
+		 (or (plist-get imgprops :type) )
+		 (base64-encode-string (plist-get imgprops :data))
+		 alt-attr))
 
 (defconst htmlize-ellipsis ...)
 (put-text-property 0 (length htmlize-ellipsis) 'htmlize-ellipsis t htmlize-ellipsis)
-- 
1.8.2.3


-- 
Eric Schulte
http://cs.unm.edu/~eschulte


[O] Effort entry and confusing effort estimates

2013-05-20 Thread Ken Mankoff
Hi,

I'm looking into effort and time tracking and have a few questions about
efforts,

1) What is the difference between C-c C-x C-e and C-c C-x e?

When I set an effort while clocked in, C-c C-x C-e asks for an effort and
formats it in a format I understand such as 00:30 or 1d. When not clocked
in, I have to use C-c C-x e (no CTRL for the last one) and it doesn't seem
to parse my entry for a timestamp or convert from 8h to 1d. For example, I
can enter an effort of aoeu and it accepts that.

2) When clocked in and using C-c C-x C-e, the conversion seems buggy:

I enter - converted to
1d - 08:00
2d - 16:00
3d - 1d 00:00
4d - 1d 08:00
7d - 2d 08:00
1w - 1d 16:00

I get that 1 day is 8 hours, and 2d 8h == 1d 16h, but I'm still confused
why 2d is 16h and 3d is 1d.

Thanks,

   -k.


Re: [O] RFQ - new contribution - org-screenshot.el

2013-05-20 Thread Russell Adams
On Mon, May 20, 2013 at 08:14:16PM -0400, Max Mikhanosha wrote:
 To me the most useful feature is actually screenshot rotation
 shortcuts, that cycle image before point, with other files in the
 `(org-screenshot-image-directory)'.

That is useful!

 Taking screenshot itself and inserting link is simple I agree.

True.

 Maybe that rotation code can be uplifted into Org itself , because I
 think its probably useful for people working with a lot of image
 links, not just screenshots. Another is specifying screenshot delay
 by C-u prefix (C-u C-u C-u - 3 seconds), for making screenshot of menus.

I suppose that depends on the tool?

 I would love to add more to it, but don't have time. If someone wants
 to hack on it, you welcome :-)

I think you were off to a great start!

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3



Re: [O] GFDL

2013-05-20 Thread Ben Finney
Carsten Dominik carsten.domi...@gmail.com writes:

 I have asked RMS about this, and he says that the [GNU FDL] license
 should be present in printed versions of the document. I find it very
 hard to believe that this must be the case.

That matches my understanding. It may be hard to believe that such an
obnoxious intent was deliberate, but I think it is in our interests to
believe it true.

 It bothers me mostly for the guide, where I did spend a lot of time to
 make it compact, and now something like one fifth of it is license
 text.  We may actually consider to re-release the guide under a
 different license.

Please use this as an opportunity to seriously consider relicensing the
entire work (programs, documentation, etc.) of Org-mode under the same
license: the GNU GPL. It does not have the special problems of the FDL,
and having the whole work under the same license terms makes it simpler
and clearer.

 Will try to find a solution here.

Wishing you fortune in coming to a good solution.

-- 
 \“The problem with television is that the people must sit and |
  `\keep their eyes glued on a screen: the average American family |
_o__) hasn't time for it.” —_The New York Times_, 1939 |
Ben Finney




[O] Customizing Org 8.0 Export

2013-05-20 Thread Scott Randby
First, I am using Org version 8.0.3-140-g84bae8.

I'm having some weird customization issues that I don't know how to
resolve.

When Emacs is started, not all the org variables are visible or
available for customization. Here is an example involving HTML export
customization.

1. Start Emacs
2. M-x customize-group org-export-html
   - None of the org-html variables appear on the list.
3. M-x customize-variable org-html-head
   - Changes to org-export-html-head
4. Open up an org file to export to HTML
5. C-c C-e h h
6. M-x customize-group org-export-html
   - Now the org-html variables appear
7. M-x customize-variable org-html-head
   - Works

I can live with the above behavior, but I have a problem when it comes
to customizing LaTeX export.

1. In a manner similar to the org-html variable situation described
   above, variables such as org-latex-classes are not available for
   customization when Emacs is started. One must do C-c C-e l p on an
   org file to make these variables available.

2. I want to put the following in my init.el:

 (add-to-list 'org-latex-classes
 '(notesclass
   \\documentclass{article}
   (\\section{%s} . \\newsection{%s})
   (\\subsection{%s} . \\newsubsection{%s})))

But when I do, I get the following on startup:

  Warning (initialization): An error occurred while loading
  `/home/srandby/.emacs.d/init.el':

  Symbol's value as variable is void: org-latex-classes

  To ensure normal operation, you should investigate and remove
  the cause of the error in your initialization file.  Start
  Emacs with the `--debug-init' option to view a complete error
  backtrace.

This means I cannot put the above code in my init.el file where I
want it to be.

Is there any way to make all of org's variables available for
customization on startup?

Scott Randby




Re: [O] Effort entry and confusing effort estimates

2013-05-20 Thread Ken Mankoff
Doh. I get the math now. 3d is 3*8h = 1d. Ok. Confusing but I get it.

But I'm still confused what 'org-set-effort' expects/interprets compared to
'org-clock-modify-effort-estimate'. Any clarification will be much
appreciated.

Thanks,

   -k.


On Mon, May 20, 2013 at 8:32 PM, Ken Mankoff mank...@gmail.com wrote:

 Hi,

 I'm looking into effort and time tracking and have a few questions about
 efforts,

 1) What is the difference between C-c C-x C-e and C-c C-x e?

 When I set an effort while clocked in, C-c C-x C-e asks for an effort and
 formats it in a format I understand such as 00:30 or 1d. When not clocked
 in, I have to use C-c C-x e (no CTRL for the last one) and it doesn't seem
 to parse my entry for a timestamp or convert from 8h to 1d. For example, I
 can enter an effort of aoeu and it accepts that.

 2) When clocked in and using C-c C-x C-e, the conversion seems buggy:

 I enter - converted to
 1d - 08:00
 2d - 16:00
 3d - 1d 00:00
 4d - 1d 08:00
 7d - 2d 08:00
 1w - 1d 16:00

 I get that 1 day is 8 hours, and 2d 8h == 1d 16h, but I'm still confused
 why 2d is 16h and 3d is 1d.

 Thanks,

-k.



Re: [O] Customizing Org 8.0 Export

2013-05-20 Thread John Hendy
On May 20, 2013 9:03 PM, Scott Randby sran...@gmail.com wrote:

 First, I am using Org version 8.0.3-140-g84bae8.

 I'm having some weird customization issues that I don't know how to
 resolve.

 When Emacs is started, not all the org variables are visible or
 available for customization. Here is an example involving HTML export
 customization.

 1. Start Emacs
 2. M-x customize-group org-export-html
- None of the org-html variables appear on the list.
 3. M-x customize-variable org-html-head
- Changes to org-export-html-head
 4. Open up an org file to export to HTML
 5. C-c C-e h h
 6. M-x customize-group org-export-html
- Now the org-html variables appear
 7. M-x customize-variable org-html-head
- Works

 I can live with the above behavior, but I have a problem when it comes
 to customizing LaTeX export.

 1. In a manner similar to the org-html variable situation described
above, variables such as org-latex-classes are not available for
customization when Emacs is started. One must do C-c C-e l p on an
org file to make these variables available.

 2. I want to put the following in my init.el:

  (add-to-list 'org-latex-classes
  '(notesclass
\\documentclass{article}
(\\section{%s} . \\newsection{%s})
(\\subsection{%s} . \\newsubsection{%s})))

 But when I do, I get the following on startup:

   Warning (initialization): An error occurred while loading
   `/home/srandby/.emacs.d/init.el':

   Symbol's value as variable is void: org-latex-classes

   To ensure normal operation, you should investigate and remove
   the cause of the error in your initialization file.  Start
   Emacs with the `--debug-init' option to view a complete error
   backtrace.

 This means I cannot put the above code in my init.el file where I
 want it to be.

 Is there any way to make all of org's variables available for
 customization on startup?


Yes, see the original exporter announcement:

http://article.gmane.org/gmane.emacs.orgmode/65574

Section 3.0 calls out two methods of setting available backends. I'm
guessing you are customizing org-export-backends vs (require 'ox-backend).
Try requiring the backend and all associated variables will be there on
startup.

John

 Scott Randby