[O] Bug: org-publish problem for pictures with thumbnails but without explicit width specification [7.9.3f (release_7.9.3f-17-g7524ef @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Dear orgmode developers, Bug can be reproduces the following way: Test.org with the content: A picture follows. [[file:img/a.JPG][file:img/a.thumb.JPG]] Now use org-publish to generate nice html out of the org file (using the org-publish-project-alist given in the appendix) will fail with the following back trace: Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match(width= nil) org-html-handle-links(#([[file:img/a.JPG][file:img/a.thumb.JPG]] ... byte-code... org-export-as-html... org-publish-org-to... org-publish-org-to-html... org-publish-file... ... As it used to work in some previous version of org mode (2 years ago??) I was curious to find out why it is broken. Apparently this line brakes it (from backtrace): org-html.el:1040: (when (save-match-data (string-match width= attr)) It seems that attr is null which makes it fail?! If I change the original file to have a width everything works flawless: A picture follows. #+ATTR_HTML: width=256 [[file:img/a.JPG][file:img/a.thumb.JPG]] I hope/I think it should not be required to give a width. Unfortunately I don't know enough Lisp yet to propse a proper fix. Can you help out? Thanks, Jonathan Emacs : GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org Package: Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ /Applications/Emacs.app/Contents/Resources/lisp/org/) current state: == (setq org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers) org-confirm-shell-link-function 'yes-or-no-p org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-export-latex-format-toc-function 'org-export-latex-format-toc-default org-export-blocks '((src org-babel-exp-src-block nil) (export-comment org-export-blocks-format-comment t) (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil)) org-export-first-hook '(org-beamer-initialize-open-trackers) org-export-interblocks '((src org-babel-exp-non-block-elements)) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-publish-project-alist '((org-notes :base-directory ~/git/jdees/org/ :base-extension org :publishing-directory ~/git/jdees/html/ :auto-sitemap t :recursive t :publishing-function org-publish-org-to-html :headline-levels 4 :auto-preamble t :language de :email [nur j] :author dees :style link rel=\stylesheet\ type=\text/css\ href=\css/stylesheet.css\ / :link_up sitemap\.html) (org-static :base-directory ~/git/jdees/org/ :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf :publishing-directory ~/git/jdees/html/ :recursive t :publishing-function org-publish-attachment)
[O] Bug: table example in the manual doesn't export [8.3beta (release_8.3beta-1216-gb856f6 @ /home/youngfrog/sources/org-mode/lisp/)]
In (info (org) Column groups) There's an example: --8---cut here---start-8--- | N | N^2 | N^3 | N^4 | sqrt(n) | sqrt[4](N) | |---+-+-+-+-+| | / || ||| | | 1 | 1 | 1 | 1 | 1 | 1 | | 2 | 4 | 8 | 16 | 1.4142 | 1.1892 | | 3 | 9 | 27 | 81 | 1.7321 | 1.3161 | |---+-+-+-+-+| #+TBLFM: $2=$1^2::$3=$1^3::$4=$1^4::$5=sqrt($1)::$6=sqrt(sqrt(($1))) --8---cut here---end---8--- But it won't export (e.g. to html) correctly because [4] is interpreted as a footnote. Here's a (trimmed down) backtrace : --8---cut here---start-8--- Debugger entered--Lisp error: (error Definition not found for footnote 4) signal(error (Definition not found for footnote 4)) error(Definition not found for footnote %s 4) org-export-get-footnote-definition (...) org-element-map (...) org-export-collect-footnote-definitions org-html-footnote-section org-html-inner-template org-export-as org-export-to-file org-html-export-to-html org-export-dispatch(nil) call-interactively(org-export-dispatch nil nil) --8---cut here---end---8--- Emacs : GNU Emacs 25.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2015-06-11 on Aurora Package: Org-mode version 8.3beta (release_8.3beta-1216-gb856f6 @ /home/youngfrog/sources/org-mode/lisp/)
Re: [O] Bug: org-publish problem for pictures with thumbnails but without explicit width specification [7.9.3f (release_7.9.3f-17-g7524ef @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hello, Dees, Jonathan jonathan.d...@sap.com writes: Test.org with the content: A picture follows. [[file:img/a.JPG][file:img/a.thumb.JPG]] Now use org-publish to generate nice html out of the org file (using the org-publish-project-alist given in the appendix) will fail with the following back trace: Debugger entered--Lisp error: (wrong-type-argument stringp nil) Org 7.9.3f is quite old. I suggest to update Org (or Emacs) and try again. If I change the original file to have a width everything works flawless: A picture follows. #+ATTR_HTML: width=256 [[file:img/a.JPG][file:img/a.thumb.JPG]] The new syntax would be: #+ATTR_LATEX: :width 256 ... Regards, -- Nicolas Goaziou
Re: [O] Bug: table example in the manual doesn't export [8.3beta (release_8.3beta-1216-gb856f6 @ /home/youngfrog/sources/org-mode/lisp/)]
Hello, Nicolas Richard youngf...@members.fsf.org writes: In (info (org) Column groups) There's an example: | N | N^2 | N^3 | N^4 | sqrt(n) | sqrt[4](N) | |---+-+-+-+-+| | / || ||| | | 1 | 1 | 1 | 1 | 1 | 1 | | 2 | 4 | 8 | 16 | 1.4142 | 1.1892 | | 3 | 9 | 27 | 81 | 1.7321 | 1.3161 | |---+-+-+-+-+| #+TBLFM: $2=$1^2::$3=$1^3::$4=$1^4::$5=sqrt($1)::$6=sqrt(sqrt(($1))) But it won't export (e.g. to html) correctly because [4] is interpreted as a footnote. Fixed in 2c66e40c6755c042bc6bd0632058ccdba009f50f. Thank you. Regards, -- Nicolas Goaziou
Re: [O] problem with ox-pandoc export
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Nicolas Goaziou mail-gpy5sjqteqhwkn9pgdnjrvaujnlxr...@public.gmane.org writes: So this is not a Pandoc export back-end (i.e. a back-end that translates Org syntax into Pandoc's extended Markdown syntax). If the pandoc back-end is some flavor of Markdown, shouldn't it be better named `ox-md-pandoc'? Which one are you talking about, the one from ELPA or the one I suggest adding to core? The former doesn't translate to Markdown at all. It simply calls pandoc on an Org document to produce something else. It depends on how well pandoc's Org importer behaves, i.e, how much Org syntax it does support. Therefore, I suggest to write an Org to native pandoc's syntax. It would be derived from ox-md but that doesn't mean its name must be prefixed with ox-md, consider, for example ox-beamer and ox-latex. BTW, when looking at Markdown formats known by Pandoc, there are: - Pandoc markdown - Pandoc markdown_github - Pandoc markdown_mmd - Pandoc markdown_phpextra - Pandoc markdown_strict Is the Pandoc back-end exporting the flavor known as Pandoc markdown? See above. Regards, -- Nicolas Goaziou
Re: [O] Tangling takes long - profiling and calling R
Hello, Aaron Ecay aarone...@gmail.com writes: There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. I'm all ears to bug reports. However, the point is not about deprecating the feature. It /is/ marked as deprecated already, and has been so during the last two years. Keeping both is just confusing and not necessary, since you can override properties locally, with appropriate arguments. I suggest to remove the old dynamic setting and improve the new lexical one, if needed. Of course, it can wait Org 8.4, but it should be signaled during Org 8.3 release already. Regards, -- Nicolas Goaziou
Re: [O] Problems Setting Properties
Hi, I believe I have solved my problem by removing a stray asterisk in a subtree I often edit frantically: :PROPERTIES: :ID: 28a0bc23-ff9f-4631-b602-fc8d4e581c2d :END:* Thanks, Ed On 31/05/15 23:05, Nicolas Goaziou wrote: Hello, Edward Guyatt edwardguy...@gmx.co.uk writes: When I try to set a property in my planner file (15005 lines to go wrong :P), I get an error message. Here is the backtrace from saying C-c C-x p (org-set-property) on any heading. Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) org-buffer-property-keys(nil t t) org-read-property-name() org-set-property(nil nil) call-interactively(org-set-property nil nil) command-execute(org-set-property) I get the same result saying C-c C-c s at a property drawer. The backtrace is missing steps. Could you reload Org uncompiled and reproduce it? I've only experienced this recently after upgrading from Debian Wheezy to Jessie, so from org-mode 7.8.11-1 to 8.2.10-1. Could you try development version of Org, i.e. 8.3-beta? Regards,
Re: [O] [patch, ox-latex] caption and :float nil
Hi Rasmus,
2015ko uztailak 1an, Rasmus-ek idatzi zuen:
Hi,
Aaron Ecay aarone...@gmail.com writes:
AFAICS you sent the original message only to me. I’m replying also to
the org mode list. You may want to resend the patch attachment though,
since the quoting in this reply will probably mangle it.
http://permalink.gmane.org/gmane.emacs.orgmode/98791
??
Both Gmail and my MUA (notmuch) showed the message as addressed only to
me, but now that I examine the raw headers I see a Newsgroups: line. I
guess you sent the list copy via NNTP instead of email? In any case, I
didn’t notice it. Sorry.
I think this should depend on the value of org-latex-listings:
nil - use \captionof{float}
You mean figure. But a source block in not a float.
Yes.
t - use \captionof{listing}
minted - use \captionof{listing} (see below for why)
We could also unconditionally use captionof in case of verbatim output for
src blocks, even if float is required, which would allow us to kill
float.sty from default package alist.
BTW: In the current code we uses \captionof{listing}{caption} with minted.
This seems incompatible.
Minted uses listing as itsf floating environment; see sec. 5 of the
minted manual. So this seems correct in fact.
Consider this minimal example
\documentclass{article}
\usepackage{minted}
\usepackage{capt-of}
\begin{document}
\begin{minted}{lisp}
(+ 1 1 )
\end{minted}
\captionof{listing}{test}
\end{document}
This is the error I get when compiling:
ERROR: Undefined control sequence.
--- TeX said ---
\@tempf ... \@parboxrestore \normalsize \@fs@capt
{\@nameuse
{fnum@#1}}{\ign...
l.8 \captionof{listing}{test}
It works fine when I use another counter than listing.
OK, I’ve done some more investigation. By default, minted uses
\newfloat from the float package to create the listing float class.
This does not set up the caption integration. OTOH, adding the newfloat
option to minted uses \DeclareFloatingEnvironment from the newfloat
package, which works. IOW, replacing the relevant line in your MWE with
the following makes it work:
\usepackage[newfloat]{minted}
I’m not sure how that should be integrated in the picture – perhaps org
should recommend (require) this invocation of minted.
But I have not really used minted so I don't know if I did the
test correctly. minted has a [H] placement through it's listings
environment, it seems, so I don't think we need captionof there.
I’m not sure that minted provides this separately from the float
package. So it’s probably better to use \captionof in the minted case
as well. Certainly it will make things more consistent from org’s POV.
I guess it doesn't. In any, minted.sty has
\RequirePackage{float}
So we can be sure [H] is available. Thus, we should just rely on
float.
But this is an implementation detail of minted, and could change in a
future release.
--
Aaron Ecay
Re: [O] problem with ox-pandoc export
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Alan Schmitt alan.schm...@polytechnique.org writes: In short, it exports the org file to another temporary org file (using the pandoc exporter that inherits from the org exporter), then it calls the pandoc binary to convert from org to the target format. The first step (org to temporary org) is used to extract some information from the org file that is used in further steps (like creating a custom CSS or adding arguments to the call to the pandoc binary). So this is not a Pandoc export back-end (i.e. a back-end that translates Org syntax into Pandoc's extended Markdown syntax). If the pandoc back-end is some flavor of Markdown, shouldn't it be better named `ox-md-pandoc'? BTW, when looking at Markdown formats known by Pandoc, there are: - Pandoc markdown - Pandoc markdown_github - Pandoc markdown_mmd - Pandoc markdown_phpextra - Pandoc markdown_strict Is the Pandoc back-end exporting the flavor known as Pandoc markdown? Best regards, Seb -- Sebastien Vauban
Re: [O] problem with ox-pandoc export
Hello, Nicolas Goaziou writes: Sebastien Vauban writes: Nicolas Goaziou writes: So this is not a Pandoc export back-end (i.e. a back-end that translates Org syntax into Pandoc's extended Markdown syntax). If the pandoc back-end is some flavor of Markdown, shouldn't it be better named `ox-md-pandoc'? Which one are you talking about, the one from ELPA or the one I suggest adding to core? The latter. The former doesn't translate to Markdown at all. It simply calls pandoc on an Org document to produce something else. It depends on how well pandoc's Org importer behaves, i.e, how much Org syntax it does support. Therefore, I suggest to write an Org to native pandoc's syntax. It would be derived from ox-md but that doesn't mean its name must be prefixed with ox-md, I'd think it'd make more sense, yes. consider, for example ox-beamer and ox-latex. Even if it's not necessarily like that for all cases. _My_ point of view is simply to make `ox-pandoc' more visible as an alternative option when one wants to export to Markdown: simply by looking at file names, by Googling or by looking at require calls used in other's configs, one would expect that `ox-md' and `ox-md-pandoc' would both generate markdown. For Beamer, it could be similar, except that people don't necessarily search for latex when trying to export to beamer. Best regards, Seb -- Sebastien Vauban
Re: [O] Org-lint -- Lisp error: (wrong-type-argument arrayp nil)
Hello, Nicolas Goaziou writes: Fabrice Niessen writes: When trying to lint my Org mode refcard [1], I get this error: Debugger entered--Lisp error: (wrong-type-argument arrayp nil) Fixed. Thank you. Same error with file https://github.com/fniessen/refcard-org-babel/blob/master/docs/eval.org. Using Org-mode version 8.3beta (release_8.3beta-1265-g2c66e4), updated this morning. Best regards, Fabrice -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] [patch, ox-latex] caption and :float nil
Aaron Ecay aarone...@gmail.com writes:
OK, I’ve done some more investigation. By default, minted uses
\newfloat from the float package to create the listing float class.
This does not set up the caption integration. OTOH, adding the newfloat
option to minted uses \DeclareFloatingEnvironment from the newfloat
package, which works. IOW, replacing the relevant line in your MWE with
the following makes it work:
\usepackage[newfloat]{minted}
I’m not sure how that should be integrated in the picture – perhaps org
should recommend (require) this invocation of minted.
That's weird. The capt-of documentation recommend the float.sty way of
adding new environments.
I guess it doesn't. In any, minted.sty has
\RequirePackage{float}
So we can be sure [H] is available. Thus, we should just rely on
float.
But this is an implementation detail of minted, and could change in a
future release.
That's a good point.
I updated the patches.
1. Rework captions when float is nil and caption is not. Kill usage of
[H] as it's the same as a nonfloat. A src block is always a nonfloat
unless it is not.
2. Update documentation.
3. Kill float dependency.
Does anybody disagree to especially the third change? Otherwise I'll push
it.
Rasmus
--
Together we will make the possible totay impossible!
From a0b7c47e37c3c5c62492236562a5f19a38efc06f Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Wed, 1 Jul 2015 01:12:42 +0200
Subject: [PATCH 1/3] ox-latex: Support captions for None-floats
* ox-latex.el (org-latex--caption/label-string): Format
nonfloating captions using the capt-of package.
(org-latex--inline-image, org-latex-src-block)
(org-latex--org-table): Allow none-float and caption.
---
etc/ORG-NEWS | 1 +
lisp/ox-latex.el | 88
2 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ea7a2de..9592f88 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -398,6 +398,7 @@ set using the hh:mm:ss format.
~org-clone-subtree-with-time-shift~ now accepts 0 as an argument for
the number of clones, which removes the repeater from the original
subtree and creates one shifted, repeating clone.
+*** None-floating tables, graphics and blocks can have captions
** Miscellaneous
*** Strip all meta data from ITEM special property
ITEM special property does not contain TODO, priority or tags anymore.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 11fa00d..31d804b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1109,21 +1109,37 @@ caption nor label, return the empty string.
For non-floats, see `org-latex--wrap-label'.
(let* ((label (org-latex--label element info nil t))
(main (org-export-get-caption element))
+ (attr (org-export-read-attribute :attr_latex element))
+ (type (org-element-type element))
+ (nonfloat (or (and (plist-member attr :float)
+ (not (plist-get attr :float))
+ main)
+ (and (eq type 'src-block)
+ (not (plist-get attr :float))
+ (memq (plist-get info :latex-listings)
+ '(nil minted)
(short (org-export-get-caption element t))
- (caption-from-attr-latex
- (org-export-read-attribute :attr_latex element :caption)))
+ (caption-from-attr-latex (plist-get attr :caption)))
(cond
((org-string-nw-p caption-from-attr-latex)
(concat caption-from-attr-latex \n))
((and (not main) (equal label )) )
((not main) (concat label \n))
;; Option caption format with short name.
- (short (format \\caption[%s]{%s%s}\n
- (org-export-data short info)
- label
- (org-export-data main info)))
- ;; Standard caption format.
- (t (format \\caption{%s%s}\n label (org-export-data main info))
+ (t
+ (format (if nonfloat \\captionof{%s}%s{%s%s}\n
+ \\caption%s%s{%s%s}\n)
+ (if nonfloat
+ (case type
+ (paragraph figure)
+ (src-block (if (plist-get info :latex-listings)
+ listing
+ figure))
+ (t (symbol-name type)))
+ )
+ (if short (format [%s] (org-export-data short info)) )
+ label
+ (org-export-data main info))
(defun org-latex-guess-inputenc (header)
Set the coding system in inputenc to what the buffer is.
@@ -1975,14 +1991,15 @@ used as a communication channel.
;; Retrieve latex attributes from the element around.
(attr (org-export-read-attribute :attr_latex parent))
(float (let ((float (plist-get attr :float)))
- (cond ((and (not float) (plist-member attr :float)) nil)
- ((string= float wrap) 'wrap)
+ (cond ((string= float wrap) 'wrap)
((string= float sideways) 'sideways)
((string= float multicolumn) 'multicolumn)
((or float
(org-element-property :caption parent)
(org-string-nw-p (plist-get attr :caption)))
- 'figure
+ (if (and (plist-member attr :float) (not float)) 'nonfloat
+ 'figure))
+ ((and (not float) (plist-member attr
[O] Tangle including code used for :results graphic?
Hi I have the following source block: #+NAME: fig_plot #+begin_src R :exports results :file-ext pdf :results graphics :width 4.5 :height 6 plot( runif(100), runif(100) ) #+end_src which works fine. But I would like to have the surrounding plotting code in the tangled file as well, so that I can, outside org, update the graph by just running the tangled script. Is there an option to tangle *including the automatic plotting code* so that the plot is created on the pdf device with the options given? If not, how can I achieve this? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] can't assign to hline relative reference:
Marijn Schouten (hkBst) hk...@gentoo.org writes: It says that there is a known issue with hline references on the left side of table formulas, but I did not quite understand the details. To tell the truth, this is not crystal clear to me either. There seems to be a proposed fix by interpreting said references as ranges with the same on both sides, for example @II$2 would become @II$2..@II$2 and would then be interpreted properly. Was the issue with this fix that it does not work in all cases? A solution properly handling all cases of @I and al. on lhs is welcome. Meanwhile, I'd rather use a consistent error than provide something that just partly works. There was a mention that fixing the issue might involve rewriting much of org-table. Is that a concern? Not really, as long as invasive changes are covered by tests. Regards,
Re: [O] Tangling takes long - profiling and calling R
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Aaron Ecay aarone...@gmail.com writes: There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. I'm all ears to bug reports. However, the point is not about deprecating the feature. It /is/ marked as deprecated already, and has been so during the last two years. Keeping both is just confusing and not necessary, since you can override properties locally, with appropriate arguments. I suggest to remove the old dynamic setting and improve the new lexical one, if needed. Of course, it can wait Org 8.4, but it should be signaled during Org 8.3 release already. What I am missing in the new syntax is the possibility to *change* the value of one header argument or to *remove* one. There is , | :header-args: tangle testfile.R ` Which sets the property header-args, there is , | :header-args+: noweb yes ` which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments and possibly , | :header-args-+: noweb exec ` which would *replace* the noweb yes with noweb exec, so it is effectively identical to , | :header-args-: noweb | :header-args+: noweb exec ` I know this might be difficult as header-args is simply a string, but I think when these additions would be there, the old syntax could be translated into the new syntax. Cheers, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] problem with ox-pandoc export
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Which one are you talking about, the one from ELPA or the one I suggest adding to core? The former doesn't translate to Markdown at all. It simply calls pandoc on an Org document to produce something else. It depends on how well pandoc's Org importer behaves, i.e, how much Org syntax it does support. Why do we need a pandoc exporter? And why do we need it in core? There's already quite a few backends to work on when we want to improve the general exporter framework. By all means, I'm not against a pandoc exporter, I'm just trying to understand the reasoning. Note: my distro doesn't have a binary pandoc package so I have never tried it. Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
[O] Maybe 1st ox-texinfo manual in the wild
Hi, The magit 2.1 manual was typeset using ox-texinfo, it seems. Neat. https://raw.githubusercontent.com/magit/magit/master/Documentation/magit.org http://magit.vc/manual/magit.pdf Rasmus -- Vote for proprietary math!
Re: [O] problem with ox-pandoc export
Fabrice Popineau fabrice.popin...@supelec.fr writes: To export documents to the epub format and produce ebooks ? (I certainly would be interested in it). Isn't an EPUB more or less a zipped XHTML project? Wouldn't ox-html + magic be a shorter and potentially less error prone route to get an epub? AFAICT, we support everything for EPUB3: XHTML, SVG, CSS and MathML. ox-odt has magic to zip projects which can be factored out or replicated. Rasmus -- I feel emotional landscapes they puzzle me
Re: [O] problem with ox-pandoc export
You are right. I'm curious to see which route is the easiest. I'll try very soon. Fabrice Le 2 juil. 2015 16:35, Rasmus ras...@gmx.us a écrit : Fabrice Popineau fabrice.popin...@supelec.fr writes: To export documents to the epub format and produce ebooks ? (I certainly would be interested in it). Isn't an EPUB more or less a zipped XHTML project? Wouldn't ox-html + magic be a shorter and potentially less error prone route to get an epub? AFAICT, we support everything for EPUB3: XHTML, SVG, CSS and MathML. ox-odt has magic to zip projects which can be factored out or replicated. Rasmus -- I feel emotional landscapes they puzzle me
Re: [O] insert default template when I create a new org buffer?
On Wednesday, 1 Jul 2015 at 18:53, Kyle Meyer wrote: [...] Perhaps you could add it to find-file-hook (not tested): or ,[ C-h v find-file-not-found-functions RET ] | find-file-not-found-functions is a variable defined in `files.el'. | Its value is nil | | This variable may be risky if used as a file-local variable. | | Documentation: | List of functions to be called for `find-file' on nonexistent file. | These functions are called as soon as the error is detected. | Variable `buffer-file-name' is already set up. | The functions are called in the order given until one of them returns non-nil. | | [back] ` -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1216-gb856f6.dirty
Re: [O] problem with ox-pandoc export
2015-07-02 14:02 GMT+02:00 Rasmus ras...@gmx.us: Why do we need a pandoc exporter? And why do we need it in core? To export documents to the epub format and produce ebooks ? (I certainly would be interested in it). Emacs could certainly do the job too, but if it is already done ... why bother ? Fabrice
Re: [O] Org-lint -- Lisp error: (wrong-type-argument arrayp nil)
Fabrice Niessen fni-news-TA4HMoP+1wHrZ44/dzw...@public.gmane.org writes: Same error with file https://github.com/fniessen/refcard-org-babel/blob/master/docs/eval.org. I cannot reproduce it. Could you pull again wip-lint and try one more time? Thank you. Regards,
Re: [O] task b starts when task a is marked as DONE?
default org has info (org) TODO dependencies for blocking. you can also use hooks or org-depend to change state when you doneify. i think the one missing feature is the ability to put scheduled [in addition to changing state on] a remote task when a task is done. not sure why this is missing. perhaps that's wrong and it is possible. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com Ramsay's disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] task b starts when task a is marked as DONE?
Sharon Kimble boudic...@skimble.plus.com writes: How can I have a task start when a primary task ends. I mean like this - * TODO task a - fill the rubbish bag * TODO task b - put rubbish bag into the bin outside. So in this case task b starts when task a is marked as DONE. Is it possible for this to occur please? what do you mean by start? Are you talking about clocking, about TODO states, about something else? -- Nick
[O] task b starts when task a is marked as DONE?
How can I have a task start when a primary task ends. I mean like this - --8---cut here---start-8--- * TODO task a - fill the rubbish bag * TODO task b - put rubbish bag into the bin outside. --8---cut here---end---8--- So in this case task b starts when task a is marked as DONE. Is it possible for this to occur please? Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk Debian 8.0, fluxbox 1.3.7, emacs 24.5.50.2 signature.asc Description: PGP signature
Re: [O] Tangling takes long - profiling and calling R
Hi Rainer, 2015ko uztailak 2an, Rainer M Krug-ek idatzi zuen: What I am missing in the new syntax is the possibility to *change* the value of one header argument or to *remove* one. There is , | :header-args: tangle testfile.R ` (Nit: I think all your examples are missing an additional colon before the header arg name, so the above should be “:header-args: :tangle testfile.R”) Which sets the property header-args, there is , | :header-args+: noweb yes ` which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) and possibly , | :header-args-+: noweb exec ` which would *replace* the noweb yes with noweb exec, so it is effectively identical to , | :header-args-: noweb | :header-args+: noweb exec ` OTOH this is a real difference. It corresponds in the old system to * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: :noweb: exec :END: #+begin_src emacs-lisp ... ;; noweb=exec #+end_src ** Three #+begin_src emacs-lisp ... ;; noweb=yes #+end_src I know this might be difficult as header-args is simply a string, This is precisely the issue: this would require extending properties to allow them to be used/interpreted as string-plists, instead of merely strings as they presently are. It would necessitate changing or adding lots of functions related to the property API. Then you have header args like “:results” which can take multiple words. Do we want to support something like the following (from the old system), which would require even more changes on top of properties-as-plist-strings in the new one: * One :PROPERTIES: :results: output :END: ** Two :PROPERTIES: :results+: table :END: #+begin_src emacs-lisp ... ;; results = output table #+end_src ** Three :PROPERTIES: :results+: list :END: #+begin_src emacs-lisp ... ;; results = output list #+end_src (AFAIK even whether property+ prepends or appends to the property value as a string is not defined, which is already a potential issue though not one that crops up for babel which is order-insensitive.) Aaron PS I am aware that all the examples I quoted are uninteresting in the context of a single source block, which could just use header arguments. Consider a large library of babel organized, taking the last example I constructed, like: * Blocks with interesting output ** Blocks which output interesting tables a dozen blocks ** Blocks which output interesting lists another dozen PPS Under either system there’s the issue of the :post header arg, which composes in a non-concatenative way. You might have: * Things which should be wrapped in delimiters :PROPERTIES: :post: wrap-delims(*this*) :END: ** Things which should be in red text :PROPERTIES: :post: make-red(*this*) :END: #+begin_src emacs-lisp ;; produce a result which should be delimited and red #+end_src The result we want is for :post to read wrap-delims(make-red(*this*)) or make-red(wrap-delims(*this*)), depending on our opinion of red delimiters. But post is very brittle in any case, so this problem isn’t very important. -- Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Hi Nicolas,
2015ko uztailak 2an, Nicolas Goaziou-ek idatzi zuen:
Hello,
Aaron Ecay aarone...@gmail.com writes:
There is also a semantic difference in the two approaches as to whether
a remote invocation of a babel block (via e.g. #+call) uses the
properties from the block’s document position, or from the call’s.
Before deprecating the feature, the bugs should be fixed (if they are
really bugs), and the semantic differences explicated better.
I'm all ears to bug reports.
Could you take a look at
http://mid.gmane.org/87fvg07vzi.fsf@Rainer.invalid, specifically the
paragraph beginning “That looks like a bug”?
However, the point is not about deprecating the feature. It /is/ marked
as deprecated already, and has been so during the last two years.
I don’t want to argue the semantics excessively, but “deprecated” should
mean that users:
1) actually change their behavior when creating new documents, or at
least
2) are aware that the old behavior is in danger of disappearing.
A footnote in the manual and a comment in the elisp file don’t really
achieve this, as evidenced by the periodic discussions of this point that
we have. Additionally, last year Eric commented that the deprecation was
“premature” http://article.gmane.org/gmane.emacs.orgmode/87739. This
arguably means (among other things) that more effort to publicize it and
work on its replacement is needed, something that has not really happened.
(Unless you count repetitive and inconclusive ML threads as a publicity
campaign.)
The inclusion of the warning in org-lint is a concrete step forward.
Keeping both is just confusing and not necessary, since you can override
properties locally, with appropriate arguments.
Neither syntax is necessary, by this metric. We could just make do with
local arguments, not needing properties at all.
IOW, this doesn’t distinguish between these two approaches.
I suggest to remove the old dynamic setting and improve the new
lexical one, if needed.
The dynamic vs. lexical metaphor is not very helpful either. I myself
invoked it, with opposite polarity, in the last thread. Achim and I had
a long discussion, without reaching any conclusion. That discussion
starts here http://mid.gmane.org/87r3zlrcnt@gmail.com. It might
be good if you read that whole thread (which is the same one that I have
already linked several times).
There has been no justification for the new property system proposed
other than questions of taste such as the above, and efficiency. The
efficiency considerations could be solved in several ways. One obvious
one would be to use a single call to org-entry-properties rather than N
calls to org-entry-get. I feel like a broken record saying this, but it
was a solution I suggested already, in the last thread
http://mid.gmane.org/87r3zlrcnt@gmail.com. Another, more
ambitious, solution would be to use the parser cache for
org-entry-{properties,get}. There was a patch for this
http://article.gmane.org/gmane.emacs.orgmode/89326, which never landed
for a variety of reasons.
There are differences in the expressivity of the two systems – such as
the (AFAICS new) one pointed out by Rainer in this thread – which have
not been explained or justified. I hope that these can be addressed,
and alternatives considered if necessary, before the change is imposed
on org users.
--
Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 2 juil. 2015 à 13:51, Nicolas Goaziou m...@nicolasgoaziou.fr a écrit : Hello, Aaron Ecay aarone...@gmail.com writes: There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. I'm all ears to bug reports. However, the point is not about deprecating the feature. It /is/ marked as deprecated already, and has been so during the last two years. Keeping both is just confusing and not necessary, since you can override properties locally, with appropriate arguments. I suggest to remove the old dynamic setting and improve the new lexical one, if needed. Of course, it can wait Org 8.4, but it should be signaled during Org 8.3 release already. Just out of interest - could you give me a short explanation or a link to where it is discussed why this change was made? Thanks, Rainer Regards, -- Nicolas Goaziou
Re: [O] Tangling takes long - profiling and calling R
Aaron Ecay aarone...@gmail.com writes: which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) Quickly, just on that particular point: what you'd put there would be the toggle of the property (here :noweb: no), but that's of course sort of limited to boolean values which have an explicit no (or nil) value; so I admit I just cover this particular exemple. Best regards, Seb -- Sebastien Vauban
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 2 juil. 2015 à 18:35, Aaron Ecay aarone...@gmail.com a écrit : Hi Rainer, 2015ko uztailak 2an, Rainer M Krug-ek idatzi zuen: What I am missing in the new syntax is the possibility to *change* the value of one header argument or to *remove* one. There is , | :header-args: tangle testfile.R ` (Nit: I think all your examples are missing an additional colon before the header arg name, so the above should be “:header-args: :tangle testfile.R”) You are right - I always make this error. Which sets the property header-args, there is , | :header-args+: noweb yes ` which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) No - not possible with the old syntax, but I was already missing it there. And it would make sense to have it. But one was at least able to set the header argument to the default value. and possibly , | :header-args-+: noweb exec ` which would *replace* the noweb yes with noweb exec, so it is effectively identical to , | :header-args-: noweb | :header-args+: noweb exec ` OTOH this is a real difference. It corresponds in the old system to * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: :noweb: exec :END: #+begin_src emacs-lisp ... ;; noweb=exec #+end_src ** Three #+begin_src emacs-lisp ... ;; noweb=yes #+end_src I know this might be difficult as header-args is simply a string, This is precisely the issue: this would require extending properties to allow them to be used/interpreted as string-plists, instead of merely strings as they presently are. It would necessitate changing or adding lots of functions related to the property API. Then you have header args like “:results” which can take multiple words. Do we want to support something like the following (from the old system), which would require even more changes on top of properties-as-plist-strings in the new one: * One :PROPERTIES: :results: output :END: ** Two :PROPERTIES: :results+: table :END: #+begin_src emacs-lisp ... ;; results = output table #+end_src ** Three :PROPERTIES: :results+: list :END: #+begin_src emacs-lisp ... ;; results = output list #+end_src (AFAIK even whether property+ prepends or appends to the property value as a string is not defined, which is already a potential issue though not one that crops up for babel which is order-insensitive.) Cheers, Rainer Aaron PS I am aware that all the examples I quoted are uninteresting in the context of a single source block, which could just use header arguments. Consider a large library of babel organized, taking the last example I constructed, like: * Blocks with interesting output ** Blocks which output interesting tables a dozen blocks ** Blocks which output interesting lists another dozen PPS Under either system there’s the issue of the :post header arg, which composes in a non-concatenative way. You might have: * Things which should be wrapped in delimiters :PROPERTIES: :post: wrap-delims(*this*) :END: ** Things which should be in red text :PROPERTIES: :post: make-red(*this*) :END: #+begin_src emacs-lisp ;; produce a result which should be delimited and red #+end_src The result we want is for :post to read wrap-delims(make-red(*this*)) or make-red(wrap-delims(*this*)), depending on our opinion of red delimiters. But post is very brittle in any case, so this problem isn’t very important. -- Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 2 juil. 2015 à 20:21, Sebastien Vauban sva-n...@mygooglest.com a écrit : Aaron Ecay aarone...@gmail.com writes: which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) Quickly, just on that particular point: what you'd put there would be the toggle of the property (here :noweb: no), but that's of course sort of limited to boolean values which have an explicit no (or nil) value; so I admit I just cover this particular exemple. But this was possible with the old syntax, but not with the new one - right? Best regards, Seb -- Sebastien Vauban
Re: [O] problem with ox-pandoc export
Rasmus ras...@gmx.us writes: Why do we need a pandoc exporter? And why do we need it in core? Note that I said would be nice, not need. Pandoc has quite a few export formats that we will probably never have an export back-end for. It avoids re-inventing the wheel. Also Pandoc can export to Org syntax. It seems fair to allow the reciprocal. Regards,
Re: [O] problem with ox-pandoc export
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Note that I said would be nice, not need. OK. Pandoc has quite a few export formats that we will probably never have an export back-end for. It avoids re-inventing the wheel. And it is high quality exporter(s)? Are there any exporters in particular that we need? I don't see it as reinventing the wheel. One example, does pandoc have something like the ox filters? Also Pandoc can export to Org syntax. It seems fair to allow the reciprocal. I fail to see the logic here. Anyway, great if somebody wants to work on it. Thanks, Rasmus -- Governments should be afraid of their people
