Re: [O] Exporting source code blocks as LaTeX figures
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
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/)]
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)?
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
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)?
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
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
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
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
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
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
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
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
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
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
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
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]
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]
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 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]
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?
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?
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]
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
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?
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
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
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
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
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]
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?
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
