Re: [O] patch for htmlize.el

[Carsten Dominik]

Yes, that is all right at least for now, please go ahead.

Thanks!

- Carsten

On 21 mei 2013, at 02:16, Eric Schulte  wrote:

> 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 
> 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 ""
> -   (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 ""
> +  (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

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

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> 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

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Customizing Org 8.0 Export

[John Hendy]

On May 20, 2013 9:03 PM, "Scott Randby"  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
>
>

Re: [O] Effort entry and confusing effort estimates

[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  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.
>

[O] Customizing Org 8.0 Export

[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] GFDL

[Ben Finney]

Carsten Dominik  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

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

[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

[O] Effort entry and confusing effort estimates

[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.

[O] patch for htmlize.el

[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 
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 ""
-   (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 ""
+		 (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

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

[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

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

[James Harkins]

On May 20, 2013 4:54 PM, "Nicolas Goaziou"  wrote:
>
> Hello,
>
> James Harkins  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

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

[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] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

[John Hendy]

On Mon, May 20, 2013 at 5:15 PM, John Hendy  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

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

[John Hendy]

On Mon, May 20, 2013 at 5:15 PM, John Hendy  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] Bugs in org-drill

[Lukas Fuernkranz]

Hi,

On Tue, May 14, 2013 at 5:19 PM, Ivan Kanis  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] RFQ - new contribution - org-screenshot.el

[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] M-RET and C-RET turn current line of text into a heading?

[John Hendy]

On Mon, May 20, 2013 at 11:14 AM, Matt Lundin  wrote:
> John Hendy  writes:
>
>>> On Wed, May 15, 2013 at 2:54 AM, Christian Moe  
>>> 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] [patch] ox-koma-letter.el: subject changes [2/4]

[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" 
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 
 ;; Viktor Rosenfeld 
 ;; Rasmus Pank Roulund 
-
 ;; 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 "\\KOMAoption{subject}{%s}\n" with-subject

Re: [O] #+ATTR_LaTeX no longer honoured

[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 wrote:

> Hello,
>
> Eric Abrahamsen  writes:
>
> > Paul Stansell  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] Possible bug with new exporter and org-babel

[giles]

Eric Schulte  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] RFQ - new contribution - org-screenshot.el

[François Pinard]

Max Mikhanosha  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

[Eric Schulte]

gi...@pexip.com writes:

> Eric Schulte  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] M-RET and C-RET turn current line of text into a heading?

[Matt Lundin]

John Hendy  writes:

>> On Wed, May 15, 2013 at 2:54 AM, Christian Moe  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

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

[Matt Lundin]

The following commit introduced a bug in org-insert-heading.

 commit 3449c6d001b8d261b104bc9dd42bf1290d74bc0b
 Author: Bastien Guerry 
 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] [patch] ox-koma-letter.el: credit [1/4]

[Alan Schmitt]

Rasmus writes:

> Alan Schmitt  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

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

[John Hendy]

On Mon, May 20, 2013 at 10:54 AM, John Hendy  wrote:
> On Wed, May 15, 2013 at 2:54 AM, Christian Moe  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] M-RET and C-RET turn current line of text into a heading?

[John Hendy]

On Wed, May 15, 2013 at 2:54 AM, Christian Moe  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] [patch] ox-koma-letter.el: credit [3/4]

[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] [patch] ox-koma-letter.el: credit [1/4]

[Rasmus]

Alan Schmitt  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" 
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 
 ;; Alan Schmitt 
+;; Viktor Rosenfeld 
+;; Rasmus Pank Roulund 
+
 ;; 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: subject changes [2/4]

[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]

[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] Possible bug with new exporter and org-babel

[giles]

Eric Schulte  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] Possible bug with new exporter and org-babel

[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] Tbl: precision for cells

[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.
> 

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

[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] Org 8.0 HTML Export

[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 "")
>>
>> What do I need to change?
> 
> 
> 
> Hope this helps,
> 

Thanks, that worked.

Scott Randby

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

[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] Build fail with emacs 24.3.1

[Bastien]

Hi Achim,

Achim Gratz  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

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

[Rasmus]

Rasmus  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

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

[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" 
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] Org-mode styled beamer presentations

[Suvayu Ali]

Hi Marcin and Rasmus,

On Mon, May 20, 2013 at 02:33:13AM +0200, Rasmus wrote:
> Marcin Borkowski  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.

Re: [O] Org 8.0 HTML Export

[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 "")
> 
> What do I need to change?



Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

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

[Omid]

Thanks. I confirm that this in fact solves the problem.


On Mon, May 20, 2013 at 3:57 AM, Longmin WANG  wrote:

>
>
> On Mon, May 20, 2013 at 11:14 AM, Omid  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
> 
>

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

[Nicolas Goaziou]

Hello,

James Harkins  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 
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]{%

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

[Longmin WANG]

On Mon, May 20, 2013 at 11:14 AM, Omid  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

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

[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] Exporting source code blocks as LaTeX figures

[James Harkins]

On Mon, May 20, 2013 at 2:30 PM, Thomas S. Dye  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