Re: [O] How to place things differently in dot
2015-03-26 23:19 GMT+01:00 Cecil Westerhof cldwester...@gmail.com:
2015-03-26 22:49 GMT+01:00 Nick Dokos ndo...@gmail.com:
Cecil Westerhof cldwester...@gmail.com writes:
In this way I do not get an empty column. It would be better when K
would put between and below H and I, but I think I can live with it.
Just put I after K and the subgraph.
That works. It is even better when I put both H and I after it.
I also found a way to get resources at the correct place.
I changed to a digraph:
#+BEGIN_SRC dot :file test.png :cmdline -Kdot -Tpng
digraph {
A
B
C
utilities [label = Utility's]
D
E
F [shape = rectangle]
subgraph cluster_resources {
color=blue
resources [label = Resources]
}
G
G_ [style=invisible]
K
subgraph cluster_ta {
color=blue
{rank = same; L, M}
L
M
}
H
I
{rank = same; D, E, F}
{rank = same; G_, K}
A - F
B - F
C - F
A - D
utilities - resources [style=invisible]
E - F
F - K [dir = back]
F - G [dir = back]
F - H [dir = back]
F - I [dir = back]
G - G_ [style=invisible]
K - L
K - M
L - M
}
#+END_SRC
There is only one problem: I see the arrowhead with:
utilities - resources
and:
'G - G_'
Is there a way to get rid of those?
--
Cecil Westerhof
Re: [O] How to place things differently in dot
2015-03-27 7:57 GMT+01:00 Cecil Westerhof cldwester...@gmail.com:
2015-03-26 23:19 GMT+01:00 Cecil Westerhof cldwester...@gmail.com:
2015-03-26 22:49 GMT+01:00 Nick Dokos ndo...@gmail.com:
Cecil Westerhof cldwester...@gmail.com writes:
In this way I do not get an empty column. It would be better when K
would put between and below H and I, but I think I can live with it.
Just put I after K and the subgraph.
That works. It is even better when I put both H and I after it.
I also found a way to get resources at the correct place.
I changed to a digraph:
#+BEGIN_SRC dot :file test.png :cmdline -Kdot -Tpng
digraph {
A
B
C
utilities [label = Utility's]
D
E
F [shape = rectangle]
subgraph cluster_resources {
color=blue
resources [label = Resources]
}
G
G_ [style=invisible]
K
subgraph cluster_ta {
color=blue
{rank = same; L, M}
L
M
}
H
I
{rank = same; D, E, F}
{rank = same; G_, K}
A - F
B - F
C - F
A - D
utilities - resources [style=invisible]
E - F
F - K [dir = back]
F - G [dir = back]
F - H [dir = back]
F - I [dir = back]
G - G_ [style=invisible]
K - L
K - M
L - M
}
#+END_SRC
There is only one problem: I see the arrowhead with:
utilities - resources
and:
'G - G_'
Is there a way to get rid of those?
I found that also:
[style=invisible, arrowhead = none]
--
Cecil Westerhof
Re: [O] [bug] fuzzy link not matching commented headlines
Great, thanks for the quick fix! Well, besides exports there is also tangling. Still, thanks for the warning. I am aware of the exports 'issue' but turned it into a feature while automatically removing unresolvable internal links. As a result, we get a nice private comment system for notes only relevant to author during writing phase. (Notes in drawers are fine, but cannot be linked up, as far as I know.) All best, mc On 2015-03-26 Thu 22:09, Nicolas Goaziou wrote: Hello, Martin Carlé m...@aiguphonie.com writes: Guess it's a bug that fuzzy links won't match a commented headline whereas the other internal link types (custom_id and org ID) do. Or is there a special purpose for this specific type of link regarding comments? Just check the following example: ,-- | * First headline | 1. fuzzy link to [[Second headline]] -- ok | 2. fuzzy link to commented [[Third headline]] -- fails | | 3. custom_id link to commented [[#Fourth][Fourth headline]] -- ok | 4. id link to commented [[id:D91E1EF3-2918-4F37-98EB-E2C92ACBE372][Fifth headline]] -- ok | | * Second headline | | * COMMENT Third headline | | * COMMENT Fourth headline | :PROPERTIES: | :CUSTOM_ID: Fourth | :END: | | * Fifth headline | :PROPERTIES: | :ID: D91E1EF3-2918-4F37-98EB-E2C92ACBE372 | :END: | `-- Thank you. This should be fixed in 22f732c2553cc8ab42e8465018042bf0f49b6f4f. However, this kind of link is sort of pointless, since it is bound to fail during export, as the targeted headline will be removed. As a consequence, this document cannot be exported, even though COMMENT keyword is only meaningful during export. Regards, -- Fetch my gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F smime.p7s Description: S/MIME cryptographic signature
Re: [O] Updating to the current org-mode in emacs trunk, and Org stable
Hello, Rasmus ras...@gmx.us writes: Marc Ihm m...@ihm.name writes: What's the schedule of merging these changes to the stable versions of Org and to Emacs trunk? My guess: After v8.3 is released. I don't think anybody is working preparing a release at the moment. —Rasmus which would be a pity ... Is there any way, how, many hands with small contributions might get this going ? If you want to help make a release you should get in touch with Bastien and ask how you can help, I guess. I have absolutely no clue what a release entails. . . Other than creating a changelog... I mean: get real work done, instead of just nudging the usual activists ? I don't know what you are trying to say here. Plenty of work is going on IRL and in Org master. AFAIK, Bastien (Cc'ed) is working on a 8.3 release, but also needs to catch-up with all the traffic on the ML. Regards, -- Nicolas Goaziou
Re: [O] :ignoreheading: works with LaTeX export, but not HTML
Hello, Richard Stanton stan...@haas.berkeley.edu writes: I want to put some headers in my org file that don't get exported. If I put :ignoreheading: after the title, it correctly does not get exported to LaTeX, but it still appears when I export to HTML (with the text :ignoreheading: on the same line). Am I missing something? In my setup I have the lines :ignoreheading: is a feature implemented in ox-beamer.el only. This is not a common feature for all back-ends. Regards, -- Nicolas Goaziou
Re: [O] [bug?, ox-latex] creator not commented out
Rasmus ras...@gmx.us writes: Yeah, but I don't know what the right change is. I can remove the creator part from the ox-latex template and make the hyperref spec ignore :with-creator. What about keeping the creator part at the end of the template and ignore :with-creator in the hyperref spec? Regards,
Re: [O] comment section with latex_header
Hi Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: I see. I did not consider any possible slow-downs. I'd expect COMMENT to behave exactly like # in every regard -- not only export. That is a clearly defined behaviour, that should not produce confusion. As explained, this is not realistic. OK, then I'll update my mental model about COMMENTs. If COMMENT is only valid for export, then I would actually recommend to rename it to make that clear. The manual is, IMO, pretty explicit: Finally, a ‘COMMENT’ keyword at the beginning of an entry, but after any other keyword or priority cookie, comments out the entire subtree. In this case, the subtree is not exported and no code block within it is executed either. The command below helps changing the comment status of a headline. I completely agree. My question was, what a use case would be that requires a COMMENT that behaves different from #'ing the individual lines (and is not covered by :noexport: already). I don't think there is any. This is basically what my first patch did (i.e., removing any COMMENT subtree at the very beginning of export process), but it nevertheless surprised some users. Well, in that case my updated mental model should not change anything. Thanks, Andreas
Re: [O] [bug] fuzzy link not matching commented headlines
Martin Carlé m...@aiguphonie.com writes: Great, thanks for the quick fix! Well, besides exports there is also tangling. Still, thanks for the warning. I am aware of the exports 'issue' but turned it into a feature while automatically removing unresolvable internal links. As a result, we get a nice private comment system for notes only relevant to author during writing phase. (Notes in drawers are fine, but cannot be linked up, as far as I know.) You can #+NAME drawers, and therefore, link to them. Regards,
Re: [O] comment section with latex_header
Andreas Leha andreas.l...@med.uni-goettingen.de writes: I see. I did not consider any possible slow-downs. I'd expect COMMENT to behave exactly like # in every regard -- not only export. That is a clearly defined behaviour, that should not produce confusion. As explained, this is not realistic. If COMMENT is only valid for export, then I would actually recommend to rename it to make that clear. The manual is, IMO, pretty explicit: Finally, a ‘COMMENT’ keyword at the beginning of an entry, but after any other keyword or priority cookie, comments out the entire subtree. In this case, the subtree is not exported and no code block within it is executed either. The command below helps changing the comment status of a headline. I completely agree. My question was, what a use case would be that requires a COMMENT that behaves different from #'ing the individual lines (and is not covered by :noexport: already). I don't think there is any. This is basically what my first patch did (i.e., removing any COMMENT subtree at the very beginning of export process), but it nevertheless surprised some users. Regards,
[O] ':post' Direct execution via Emacs Lisp
Hi, We can read in the manual: 14.8.2.25 ‘:post’ The ‘:post’ header argument is used to post-process the results of a code block execution. When a post argument is given, the results of the code block will temporarily be bound to the ‘*this*’ variable. This variable may then be included in header argument forms such as those used in *note var:: header argument specifications allowing passing of results to other code blocks, or direct execution via Emacs Lisp. ^^^ IIUC, it means that we can post process the data in Emacs Lisp, that is, by calling an Emacs Lisp function, not another source block. However, the example only shows how to do it with another source block. Is my understanding correct or not? If so, how can I post process the result with an Emacs Lisp function? Cheers, -- Daimrod/Greg
Re: [O] Org-Mode and Mac OS X advice
Hello All, Just a quick email to say thanks for all the advice and tips. Regards, Chris
Re: [O] [bug?, ox-latex] creator not commented out
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rasmus ras...@gmx.us writes: Yeah, but I don't know what the right change is. I can remove the creator part from the ox-latex template and make the hyperref spec ignore :with-creator. What about keeping the creator part at the end of the template and ignore :with-creator in the hyperref spec? Fixed in e9fd199. In e9fd199 meta-data is always available via the specs in ox-latex and always inserted in ox-odt. An empty generator, which could be produced before, is definitely wrong cf: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415092_253892949 But we could allow for no meta generator field, if that's desirable. I guess the rightᵀᴹ approach would be to make the meta data configurable as with hyperref. —Rasmus -- There are known knowns; there are things we know that we know
Re: [O] comment section with latex_header
Hi, On 03/27/2015 12:02 PM, Nicolas Goaziou wrote: Andreas Leha andreas.l...@med.uni-goettingen.de writes: I completely agree. My question was, what a use case would be that requires a COMMENT that behaves different from #'ing the individual lines (and is not covered by :noexport: already). I don't think there is any. This is basically what my first patch did (i.e., removing any COMMENT subtree at the very beginning of export process), but it nevertheless surprised some users. Just a note: I didn't know of :noexport: before Andreas brought it up in this thread. If you revert the second patch, please put a note in the release notes for the next org release, so the other babel users know a migration path. Best regards Robert
Re: [O] [ox, patch] Keywords what should go in ox?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: I have now reviewed this section twice, and I have no clue what you want me to change there. There's no :with-keywords or :with-description. I don't know either. I was sure that :keywords and :description were here, but, oddly, it isn't the case. That's a documentation bug as long as these keywords are in ox.el. By this logic we'd have to add *every* global keyword, no? Does it make sense? At least SUBTITLE for ox-texinfo in not documented here. That's also a documentation bug. Note that it should probably be :texinfo-subtitle (and :texinfo-subauthor). Unless we add a #+SUBTITLE... So should I go ahead a kill KEYWORD and DESCRIPTION in ox? —Rasmus -- Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] :ignoreheading: works with LaTeX export, but not HTML
On Fri, Mar 27, 2015 at 6:53 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: :ignoreheading: is a feature implemented in ox-beamer.el only. This is not a common feature for all back-ends. IIUC, this question is about performance of the filter shown in the OP, not about the built in feature in ox-beamer. Removed the escaped backquote from the string-match regexp seems to work for both Latex and HTML, but I can't comment on why this is the case or whether it might have unintended consequences. Regards, Jake
Re: [O] org-ref and ODT export
The markdown file will not contain the bibliography. You have to use pandoc to get that, e.g. create a bibtex file containing the citations, and run something like pandoc --bibliography=test.bib --filter pandoc-citeproc test.md -o test.odt This works on a minimal kind of example for me. see also http://kitchingroup.cheme.cmu.edu/blog/2015/01/29/Export-org-mode-to-docx-with-citations-via-pandoc/ Jordi Inglada writes: John Kitchin jkitc...@andrew.cmu.edu wrote: There is no odt support. I am not sure what the best way to do that is, since I don't know how to format the citations in odt. You could try exporting to markdown and then use pandoc to convert to odt. I think the citations export as pandoc citations in markdown export. Thank you for your prompt reply. I tried the markdown export and, yes, the citations get exported as for instance [@breimandecisiontrees], but the markdown file does not contain the reference itself. I don't know markdown, so there is something I am not doing correctly. Best wishes, Jordi Jordi Inglada writes: Hello, I am a very happy user of your org-ref package, mainly for getting bibtex entries from DOIs, organizing my bibliography and writing papers in LaTeX. I need to export a document in ODT format and it seems that the cite:xxx references do not get exported. Is this a missing feature or is there some specific configuration to set up to make it work? I have also tried using pandoc to export to Word, but the behavior is the same. Thanks for your great work. Best wishes, Jordi -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] ':post' Direct execution via Emacs Lisp
I cannot see anyway to use direct execution of emacs lisp code in this (and nothing I have tried actually works). Any emacs-lisp code seems to get evaluated before running the block and *this* is not defined then. As advertised, this works: #+name: wrap #+BEGIN_SRC emacs-lisp :var data= (concat \n data \n)) #+END_SRC #+BEGIN_SRC python :post wrap(*this*) print 66 #+END_SRC #+RESULTS: : : 66 : But I don't see a way in org-babel-ref-resolve to resolve emacs-lisp as a :post argument. Daimrod writes: Hi, We can read in the manual: 14.8.2.25 ‘:post’ The ‘:post’ header argument is used to post-process the results of a code block execution. When a post argument is given, the results of the code block will temporarily be bound to the ‘*this*’ variable. This variable may then be included in header argument forms such as those used in *note var:: header argument specifications allowing passing of results to other code blocks, or direct execution via Emacs Lisp. ^^^ IIUC, it means that we can post process the data in Emacs Lisp, that is, by calling an Emacs Lisp function, not another source block. However, the example only shows how to do it with another source block. Is my understanding correct or not? If so, how can I post process the result with an Emacs Lisp function? Cheers, -- tProfessor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] [ox, patch] #+SUBTITLE
Hi,
I'm starting a new thread as the previous discussion attracted much
dissuasion not directly related to the patch in question. Changes:
- Html subtitles now follow the W3 recommendations, I think/hope. It
would be great if somebody who knows css would check the styling.
- The texinfo subtitle is interpreted.
- Documentation and NEWS is added.
Note: *the patch does not touch ox.el*. SUBTITLE is *only* supported in a
tiny fraction of the backends, namely ox-latex, ox-ascii, ox-html, and
ox-odt.
—Rasmus
--
Er du tosset for noge' lårt!
From 6d4e46af0b9ef5623c1a638c4659997fb735350b Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Sun, 1 Mar 2015 22:09:19 +0100
Subject: [PATCH] ox: Add SUBTITLE property in some backends
* ox-ascii.el (org-ascii-template--document-title)
(org-ascii-template--document-title)
ox-deck.el (org-deck-title-slide-template)
ox-s5.el (org-s5-title-slide-template)
ox-html.el (org-html--build-meta-info, org-html-format-spec)
(org-html--build-meta-info, org-html-format-spec)
(org-html--build-meta-info, org-html-format-spec)
ox-org.el (org), (org-org-keyword): Use SUBTITLE.
* ox-beamer.el (org-beamer-template)
ox-html (org-html-template)
ox-latex.el (org-latex-template)
ox-org (org-org-template): Insert SUBTITLE.
* ox-html (org-html-preamble-format) (org-html-postamble-format):
Update docstring.
* ox-html (org-html-style-default): Add .subtitle style and
change .title style.
* ox-texinfo.el (org-texinfo-template): Interpret subtitle.
* org.texi (Export settings): Document SUBTITLE.
* ORG-NEWS: Add entry on SUBTITLE.
The patch adds a #+SUBTITLE keyword to ox-ascii, ox-latex, ox-html and
ox-odt.
---
contrib/lisp/ox-deck.el | 2 ++
contrib/lisp/ox-s5.el | 2 ++
doc/org.texi| 7 ++-
etc/ORG-NEWS| 3 +++
lisp/ox-ascii.el| 23 ++-
lisp/ox-beamer.el | 10 +-
lisp/ox-html.el | 37 +++--
lisp/ox-latex.el| 41 -
lisp/ox-odt.el | 32 +---
lisp/ox-org.el | 9 +++--
lisp/ox-texinfo.el | 10 +++---
11 files changed, 150 insertions(+), 26 deletions(-)
diff --git a/contrib/lisp/ox-deck.el b/contrib/lisp/ox-deck.el
index 0ebde41..a76384b 100644
--- a/contrib/lisp/ox-deck.el
+++ b/contrib/lisp/ox-deck.el
@@ -259,6 +259,7 @@ Defaults to styles for the title page.
(defcustom org-deck-title-slide-template
h1%t/h1
+h2%s/h2
h2%a/h2
h2%e/h2
h2%d/h2
@@ -446,6 +447,7 @@ holding export options.
;; title page
(format %s id='title-slide' class='slide'
(plist-get info :html-container))
+ ;; TODO: format-spec isn't great for missing details.
(format-spec org-deck-title-slide-template (org-html-format-spec info))
(format /%s (plist-get info :html-container))
;; toc page
diff --git a/contrib/lisp/ox-s5.el b/contrib/lisp/ox-s5.el
index b003919..8b28692 100644
--- a/contrib/lisp/ox-s5.el
+++ b/contrib/lisp/ox-s5.el
@@ -174,6 +174,7 @@ or an empty string.
(defcustom org-s5-title-slide-template
h1%t/h1
+h2%s/h2
h2%a/h2
h3%e/h3
h4%d/h4
@@ -329,6 +330,7 @@ holding export options.
;; title page
(format %s id='title-slide' class='slide'
(plist-get info :html-container))
+ ;; TODO: format-spec isn't great for missing details.
(format-spec org-s5-title-slide-template (org-html-format-spec info))
(format /%s (plist-get info :html-container))
;; table of contents.
diff --git a/doc/org.texi b/doc/org.texi
index 6b56c4a..64a34e5 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10711,6 +10711,12 @@ default value is @code{:export:}. Within a subtree tagged with
below). When headlines are selectively exported with @code{:export:}
anywhere in a file, text before the first headline is ignored.
+@item SUBTITLE
+@cindex #+SUBTITLE
+The document subtitle. The keyword is supported by by @LaTeX{}-backends,
+HTML backends, ASCII backends, the texinfo backend, and the ODT backend. You
+can use several such keywords for long subtitles.
+
@item EXCLUDE_TAGS
@cindex #+EXCLUDE_TAGS
@vindex org-export-exclude-tags
@@ -13174,7 +13180,6 @@ to define your own class in @code{org-texinfo-classes}, which see. Set
@subsubheading Title and copyright page
@cindex #+TEXINFO_PRINTED_TITLE
-@cindex #+SUBTITLE
The default template includes a title page for hard copy output. The title
and author displayed on this page are extracted from, respectively,
@code{#+TITLE} and @code{#+AUTHOR} keywords (@pxref{Export settings}). It is
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9c262f4..7f53123 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -323,6 +323,9 @@ leading spaces within table cells.
*** New MathJax configuration options.
Org uses the MathJax CDN by default. See the manual and the docstring
of ~org-html-mathjax-options~ for details.
Re: [O] org-drill problem: questions are blank
On Thu, 26 Mar 2015, at 17:26, J. David Boyd wrote: Peter Westlake peter.westl...@pobox.com writes: From time to time Org-drill shows me a blank window instead of a question. The frame, mode line and prompt to answer are visible, but there's nothing in the window at all. As a workaround I can type t to edit the tags, and the question will appear. A sample file is enclosed. It's a new file without any of the org-drill property drawers just to keep the example short and to avoid having to wait for the question to be scheduled to be shown again, but the problem *does* still happen when the drawers are present. To reproduce the bug, run org-drill in drillbug.org; the question MC gives a blank screen. I'm using org-drill with the latest version of Org-mode, git commit 2f58e3c011ec84f621905332d8df68b83da580d9, on Emacs 24.3.1, 2014-09-30. Peter. There's no attached file... Ugh! There is now, sorry. Peter. drillbug.org Description: Lotus Organizer
Re: [O] [ox, patch] #+SUBTITLE
Hi Rasmus, Rasmus ras...@gmx.us writes: Hi, I'm starting a new thread as the previous discussion attracted much dissuasion not directly related to the patch in question. Changes: - Html subtitles now follow the W3 recommendations, I think/hope. It would be great if somebody who knows css would check the styling. - The texinfo subtitle is interpreted. - Documentation and NEWS is added. Note: *the patch does not touch ox.el*. SUBTITLE is *only* supported in a tiny fraction of the backends, namely ox-latex, ox-ascii, ox-html, and ox-odt. —Rasmus [... the patch ...] I have not followed the discussion. But I like a uniform subtitle support across relevant backends. So, my only question is: this patch does not include ox-beamer, right? This is where I include my own latex subtitle most times Regards, Andreas
Re: [O] [ox, patch] #+SUBTITLE
Andreas Leha andreas.l...@med.uni-goettingen.de writes: I have not followed the discussion. But I like a uniform subtitle support across relevant backends. So, my only question is: this patch does not include ox-beamer, right? This is where I include my own latex subtitle most times Beamer is derived from ox-latex. So it's supported. Quoting the changelog: * ox-beamer.el (org-beamer-template) [...]: Insert SUBTITLE. —Rasmus -- This space is left intentionally blank
Re: [O] hiding the PROPERTIES drawer
Hello, Leo Ufimtsev lufim...@redhat.com writes: I think he meant completely hiding the property drawer, so it wouldn't even be a one-liner. This is not possible. Completely hiding data in a document sounds very wrong, anyway. Regards, -- Nicolas Goaziou
Re: [O] hiding the PROPERTIES drawer
I think he meant completely hiding the property drawer, so it wouldn't even be a one-liner. Leo Ufimtsev | Intern Software Engineer @ Eclipse Team - Original Message - From: Richard Lawrence richard.lawre...@berkeley.edu To: emacs-orgmode@gnu.org Cc: Randomcoder randomcod...@gmail.com Sent: Wednesday, March 25, 2015 10:18:32 AM Subject: Re: [O] hiding the PROPERTIES drawer Hi Randomcoder, Randomcoder randomcod...@gmail.com writes: Is there an easier solution to hiding the :PROPERTIES: drawer by default ? I'm not sure that a solution is needed. In my setup (Org master branch, Emacs 23), the PROPERTIES drawer is always folded by default. I've never done anything to make this happen; as far as I know, it's the default behavior in Org. So: is there something in your setup that's causing the drawer NOT to be folded? (Try loading Org in emacs -Q, then see if property drawers are folded by default or not.) If you need help finding out what's responsible, send us more specific information about your Org version and configuration. (I need the ID to be there, but I don't want to see it, and so I would prefer the drawer to be hidden/folded) Do you need the drawer to be hidden, or is having it folded enough? Best, Richard
Re: [O] [bug?, ox-latex] creator not commented out
Rasmus ras...@gmx.us writes: Fixed in e9fd199. Thank you. In e9fd199 meta-data is always available via the specs in ox-latex and always inserted in ox-odt. An empty generator, which could be produced before, is definitely wrong cf: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415092_253892949 But we could allow for no meta generator field, if that's desirable. I guess the rightᵀᴹ approach would be to make the meta data configurable as with hyperref. Sounds good. Regards,
Re: [O] [ox, patch] #+SUBTITLE
Rasmus ras...@gmx.us writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: I have not followed the discussion. But I like a uniform subtitle support across relevant backends. So, my only question is: this patch does not include ox-beamer, right? This is where I include my own latex subtitle most times Beamer is derived from ox-latex. So it's supported. Quoting the changelog: * ox-beamer.el (org-beamer-template) [...]: Insert SUBTITLE. Thanks! Will be using this (or another patch providing this) a lot once it is applied! - Andreas
Re: [O] ':post' Direct execution via Emacs Lisp
On Fri, 27 Mar 2015, John Kitchin wrote: I cannot see anyway to use direct execution of emacs lisp code in this (and nothing I have tried actually works). Any emacs-lisp code seems to get evaluated before running the block and *this* is not defined then. The quoted part of the manual does suggest that lisp snippets should work like `:post (do-something *this*)' But perhaps *this* (pun intended) is what was meant: an emacs-lisp block can refer to `*this*' without needing to pass the value as a header argument. #+NAME: abc #+BEGIN_SRC emacs-lisp (concat *this* and that) #+END_SRC #+BEGIN_SRC emacs-lisp :post abc() T-H-I-S #+END_SRC #+RESULTS: : T-H-I-S and that [snip] We can read in the manual: 14.8.2.25 ‘:post’ The ‘:post’ header argument is used to post-process the results of a code block execution. When a post argument is given, the results of the code block will temporarily be bound to the ‘*this*’ variable. This variable may then be included in header argument forms such as those used in *note var:: header argument specifications allowing passing of results to other code blocks, or direct execution via Emacs Lisp. ^^^ Chuck
Re: [O] bug in org-export-smart-quotes
Jay Dixit di...@aya.yale.edu writes: Hi everyone, I've noticed that when I use quotation marks in conjunction with an em dash (—), org-export-smart-quotes gets confused and forgets to activate smart quotes for the closing quotation mark. If my org-mode file contains a sentence like this... A [[http://spp.sagepub.com/content/early/2015/01/23/1948550614568867.abstract][new study]] published in Psychological and Personality Science has found that helping other people---what scientists call being prosocial---increases your odds of finding a long-term relationship. ...then it exports to HTML like this: A new study published in Social Psychological and Personality Science has found that helping other people—what scientists call being “prosocial—increases your odds of finding a long-term relationship. Note the non-smart closing quotation mark. Does anyone know a fix for this? The regexps are probably looking for spaces - try ... people --- what scientists call being prosocial --- increases Nick
Re: [O] ':post' Direct execution via Emacs Lisp
that makes sense. Charles C. Berry writes: On Fri, 27 Mar 2015, John Kitchin wrote: I cannot see anyway to use direct execution of emacs lisp code in this (and nothing I have tried actually works). Any emacs-lisp code seems to get evaluated before running the block and *this* is not defined then. The quoted part of the manual does suggest that lisp snippets should work like `:post (do-something *this*)' But perhaps *this* (pun intended) is what was meant: an emacs-lisp block can refer to `*this*' without needing to pass the value as a header argument. #+NAME: abc #+BEGIN_SRC emacs-lisp (concat *this* and that) #+END_SRC #+BEGIN_SRC emacs-lisp :post abc() T-H-I-S #+END_SRC #+RESULTS: : T-H-I-S and that [snip] We can read in the manual: 14.8.2.25 ‘:post’ The ‘:post’ header argument is used to post-process the results of a code block execution. When a post argument is given, the results of the code block will temporarily be bound to the ‘*this*’ variable. This variable may then be included in header argument forms such as those used in *note var:: header argument specifications allowing passing of results to other code blocks, or direct execution via Emacs Lisp. ^^^ Chuck -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] bug in org-export-smart-quotes
Hi Nick, Thanks for the suggestion. Putting extra spaces in the original solves the smart quotes issue, but creates unwanted spaces on either side of the em dash: A new study http://spp.sagepub.com/content/early/2015/01/23/1948550614568867.abstract published in Social Psychological and Personality Science has found that helping other people — what scientists call being “prosocial” — increases your odds of finding a long-term relationship. Thanks, Jay --- Jay Dixit jaydixit.com (646) 355-8001 Jay Dixit On Fri, Mar 27, 2015 at 2:45 PM, Jay Dixit di...@aya.yale.edu wrote: Hi everyone, I've noticed that when I use quotation marks in conjunction with an em dash (—), org-export-smart-quotes gets confused and forgets to activate smart quotes for the closing quotation mark. If my org-mode file contains a sentence like this... A [[ http://spp.sagepub.com/content/early/2015/01/23/1948550614568867.abstract][new study]] published in Psychological and Personality Science has found that helping other people---what scientists call being prosocial---increases your odds of finding a long-term relationship. ...then it exports to HTML like this: A new study http://spp.sagepub.com/content/early/2015/01/23/1948550614568867.abstract published in Social Psychological and Personality Science has found that helping other people—what scientists call being “prosocial—increases your odds of finding a long-term relationship. Note the non-smart closing quotation mark. Does anyone know a fix for this? Thanks! Jay --- Jay Dixit jaydixit.com (646) 355-8001 Jay Dixit
[O] bug in org-export-smart-quotes
Hi everyone, I've noticed that when I use quotation marks in conjunction with an em dash (—), org-export-smart-quotes gets confused and forgets to activate smart quotes for the closing quotation mark. If my org-mode file contains a sentence like this... A [[ http://spp.sagepub.com/content/early/2015/01/23/1948550614568867.abstract][new study]] published in Psychological and Personality Science has found that helping other people---what scientists call being prosocial---increases your odds of finding a long-term relationship. ...then it exports to HTML like this: A new study http://spp.sagepub.com/content/early/2015/01/23/1948550614568867.abstract published in Social Psychological and Personality Science has found that helping other people—what scientists call being “prosocial—increases your odds of finding a long-term relationship. Note the non-smart closing quotation mark. Does anyone know a fix for this? Thanks! Jay --- Jay Dixit jaydixit.com (646) 355-8001 Jay Dixit
Re: [O] bug in org-export-smart-quotes
Jay Dixit di...@aya.yale.edu writes: Thanks for the suggestion. Putting extra spaces in the original solves the smart quotes issue, but creates unwanted spaces on either side of the em dash: I understand but I can't really help. If I'm right that the regexps are looking for a space[fn:1] (and that's a big if), then the only way to fix it is to modify one or more of them (see org-export-smart-quotes-regexps, which btw is a defconst, so not really meant to be modified), but I'm not up to that task. Let's hope that I'm wrong and somebody comes up with a simpler solution. Nick Footnotes: [fn:1] or, rather, for something that the dash does not satisfy
Re: [O] Org-Mode and Mac OS X advice
On Thu, Mar 26, 2015 at 9:18 AM, Chris Willard ch...@meliser.co.uk wrote: Hello All, I am thinking about changing to a Mac from Windows and wanted to check that there are no issues with using org-mode in OS X. No problems here; including exports to PDF via LaTeX. I would like to know what version of Emacs people use (e.g. Aquamacs) and also if there are any issues using org-mode on a Mac. For example, I export to PDF frequently so would like to know if I need any other software for this. I use native Gnu Emacs from Homebrew. I've alternated between release and --HEAD in the past; I'm currently using a release version and not the Git Master. $ brew info emacs emacs: stable 24.4 (bottled), devel 24.4-dev, HEAD https://www.gnu.org/software/emacs/ /usr/local/Cellar/emacs/24.4 (3922 files, 119M) * Built from source with: --cocoa, --with-gnutls From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/emacs.rb I use MacTex for the Tex/LaTeX pieces. Many thanks, Chris
[O] Is it possible to implement a TARGET date in addition to SCHEDULED and DEADLINE?
I wonder how difficult it would be to add a 3rd TARGET date to headings/tasks, which is treated similar to Deadline and Scheduled dates (can be used in agenda, can be easily set and modified, ...) : example: * TODO [#A] My org-mode task TARGET: 2015-04-01 Mi SCHEDULED: 2015-03-30 Mo Background: I often use artificial deadlines to specify that a certain task shall be done until tomorrow (or another date). And this date is neither the starting date nor is it a real deadline. Up to now I'm using the DEADLINE date for this purpose, but I don't like that solution, as it is confusing for me to know which deadlines are real hard deadlines (e.g. I have to send in my tax declaration until a certain date and not one day later) and those artificial ones, which not carved in stone. So is there an easy way (I don't know, how modular org-mode is set up) to add this 3rd TARGET date to org-mode? Martin
