Re: [O] [ANN] org-link-edit.el --- Slurp and barf with Org links
Rasmus wrote: > Kyle Meyer writes: > >> remove description words like Paredit lets you do with S-expressions. >> I've put these Paredit-inspired slurping and barfing commands for Org >> link descriptions in org-link-edit.el > > That's so need! > > Did you/will you add it to contrib? I'm glad you think it looks useful. I haven't added it contrib (I don't have push access and wasn't sure if others would be interested), but I'd be happy for it to be in contrib. -- Kyle
Re: [O] Parent path for links
Giacomo M wrote: [...] > What happens is that in project.org I end up specifying a lot of links all > starting with ~/working/project/. This is useful as I can directly jump > from "organization" to "action", or just to switch in a quicker way across > project files. [...] > Would you have any suggestions for reducing the redundancy of a common > parent path for links in a subtree/file? Is the reason this redundancy bothers you visual? (I'm guessing it is because it shouldn't be any extra work to insert the link if you're using org-store-link.) In that case, you could make a command that adds a link description with the file base name (assuming these file links tend to not have descriptions). Another possibility (which I haven't really thought through or tested) is to use a custom link type that grabs the project directory from somewhere (below I use a property value) and then uses that as the default directory. #+begin_src elisp (org-add-link-type "project" 'km/org-project-open) (defun km/org-project-open (path) "Open PATH with `default-directory' set to PROJECT property." (let ((project (org-entry-get nil "PROJECT" 'inherit))) (if project (let ((default-directory project)) (org-open-link-from-string (concat "file:" path))) (user-error "Project property not defined" #+end_src (Notice that km/org-project-open is actually making an ordinary file link to support things like "::*heading"... definitely a hack). You could specify the property value at the top of the project file #+PROPERTY: project /path/to/project or as a project property on a heading * heading :PROPERTIES: :PROJECT: /path/to/project :END: This would then allow for links to a file name relative to the project directory, like project:file-name.org and project:file-name.org::*Heading -- Kyle
[O] [bug] org time stamp can't read time
Hi, When I call org-time-stamp (C-c .) from Emacs -q and give a time such as "11:00" and nothing else I get <2015-02-19>. I would expect something like <2015-02-19 11:00>, as in v8.2. —Rasmus -- Slowly unravels in a ball of yarn and the devil collects it
[O] Parent path for links
Dear all, I'm experimenting the following path structure: 1. ~/org/ is where I keep all my org files for organization purposes (e.g. project.org contains all TODOs, notes, events, and links related to "project") and is sync'd with a GIT server. 2. ~/working/project/ is where I keep all the non-organizational files related to "project", which are potentially big and thus the folder is saved on an external drive/Dropbox. What happens is that in project.org I end up specifying a lot of links all starting with ~/working/project/. This is useful as I can directly jump from "organization" to "action", or just to switch in a quicker way across project files. I know there is an header arg (i.e. dir) for the path of code execution, but I am not aware of anything similar for link referencing. Would you have any suggestions for reducing the redundancy of a common parent path for links in a subtree/file? Thanks, Giacomo
Re: [O] [patch, ox-latex] better hyperref and title options
Nicolas Goaziou writes:
> Since KEYWORDS and DESCRIPTION are really back-end dependant, I vote for
> moving them from `org-export-options-alist' to back-end definitions.
> Using `org-element-parse-secondary-string' will be required in this
> case.
> WDYT? Also, supposing you agree, do you want to do a patch (caveat:
> there's "org.texi" messing involved)?
So irrespective of this, here's an updated patch that uses
secondary-string parsing. Should I add it to master before or after I get
done with this moving description and keywords?
—Rasmus
--
This is the kind of tedious nonsense up with which I will not put
>From 30334b0bf1d68fcc4479e26d51296099505657cd Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Wed, 11 Feb 2015 02:18:09 +0100
Subject: [PATCH] ox-latex: Format-spec for hyperref and title
* ox-latex.el (org-latex-format-spec): New function with format-specs.
(org-latex-template): Use org-latex-format-spec.
(org-latex-hyperref-template): New defaults and use
org-latex-format-spec.
(org-latex-title-command): Use org-latex-format-spec.
* ORG-NEWS: Mention change.
---
etc/ORG-NEWS | 3 ++
lisp/ox-latex.el | 88 +---
2 files changed, 74 insertions(+), 17 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 03fcfb2..4e1bc42 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -233,6 +233,9 @@ Exact heading search for links now ignore spaces and cookies. This is
the case for links of the form ~file:projects.org::*task title~, as
well as links of the form ~file:projects.org::some words~
when ~org-link-search-must-match-exact-headline~ is not nil.
+*** ~org-latex-hyperref-template~, ~org-latex-title-command~ formatting
+New formatting keys are supported. See ~org-latex-format-spec~.
+Further, ~org-latex-hyperref-template~ has new default value.
* Version 8.2
** Incompatible changes
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6eddad0..27daf8f 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -383,11 +383,25 @@ are written as utf8 files."
(defcustom org-latex-title-command "\\maketitle"
"The command used to insert the title just after \\begin{document}.
-If this string contains the formatting specification \"%s\" then
-it will be used as a formatting string, passing the title as an
-argument."
+
+This format string may contain these elements:
+
+ %a for AUTHOR keyword
+ %t for TITLE keyword
+ %k for KEYWORDS line
+ %d for DESCRIPTION line
+ %c for CREATOR line
+ %l for Language keyword
+ %L for capitalized language keyword
+ %D for DATE keyword
+
+If you need to use a \"%\" character, you need to escape it
+like that: \"%%\".
+
+Setting :latex-title-command in publishing projects will take
+precedence over this variable."
:group 'org-export-latex
- :type 'string)
+ :type '(string :tag "Format string"))
(defcustom org-latex-toc-command "\\tableofcontents\n\n"
"LaTeX command to set the table of contents, list of figures, etc.
@@ -397,20 +411,30 @@ the toc:nil option, not to those generated with #+TOC keyword."
:type 'string)
(defcustom org-latex-hyperref-template
- "\\hypersetup{\n pdfkeywords={%k},\n pdfsubject={%d},\n pdfcreator={%c}}\n"
+ "\\hypersetup{\n pdfauthor={%a},\n pdftitle={%t},\n pdfkeywords={%k},
+ pdfsubject={%d},\n pdfcreator={%c}, \n pdflang={%L}}\n"
"Template for hyperref package options.
-Value is a format string, which can contain the following placeholders:
+This format string may contain these elements:
+ %a for AUTHOR keyword
+ %t for TITLE keyword
%k for KEYWORDS line
%d for DESCRIPTION line
%c for CREATOR line
+ %l for Language keyword
+ %L for capitalized language keyword
+ %D for DATE keyword
+
+If you need to use a \"%\" character, you need to escape it
+like that: \"%%\".
-Set it to the empty string to ignore the command completely."
+Setting :latex-hyperref-template in publishing projects will take
+precedence over this variable."
:group 'org-export-latex
:version "25.1"
:package-version '(Org . "8.3")
- :type 'string)
+ :type '(string :tag "Format string"))
Headline
@@ -1193,6 +1217,35 @@ just outside of it."
INFO is a plist used as a communication channel."
(org-export-translate s :latex info))
+(defun org-latex--format-spec (info)
+ "Create a format-spec for e.g. `org-latex-hyperref-template'.
+Also used by `org-latex-title-command'
+
+INFO is a plist used as a communication channel."
+ (let ((objects '(bold code entity export-snippet inline-babel-call
+ inline-src-block italic latex-fragment
+ latex-math-block link macro strike-through
+ subscript superscript timestamp underline
+ verbatim))
+ (language (let ((lang (plist-get info :language)))
+ (or (cdr (assoc lang org-latex-babel-language-alist))
+ lang ""
+`((?a . ,(or (org-export-data (plist-get info :author) info) ""))
+ (?t . ,(or (org-export-data (plist-get info :title) info) ""))
+ (?k . ,(org-export-data
Re: [O] [patch] better(?) indention for cdlatex-environment
Hi,
Nicolas Goaziou writes:
>> Perhaps there are clever ways to figure it out. I say there are too many
>> dynamics and "fixes" in the code to get cdlatex-environment to work
>> already. Just consider this example where | is cursor
>>
>>- foo | bar
>>
>> Midway through, when ENV is reinserted, but before indentation the
>> end-marker will be *after* bar which is a line after \end{ENV}...
>
> This is exactly what we want: indent (non empty) lines starting in
> [BEG ; END[. Or am I missing something?
OK, the missing key is org-indent-line-to. It works better in this case
and I can use end.
>> Anyway it reminded me that I missed "re-implementing" one feature of
>> cdlatex, namely moving the cursor to the right place. I refind this
>> place do it by inserting a funny string and replacing it. A poor man's
>> marker, I guess...
>
> Another option: when ENV is inserted the first time, store (e.g., in N)
> how many (forward-line -1) are needed to go back to BEG. At the end of
> the process, move to BEG then (forward-line n). I assume point is always
> left on an empty lines. If it is not the case, you also need to store
> current column, relatively to end of line.
OK it now does this.
—Rasmus
--
Dung makes an excellent fertilizer
>From a0dca50b09baede2e7c63ec6b9bedb976b3a3b96 Mon Sep 17 00:00:00 2001
From: rasmus
Date: Tue, 10 Feb 2015 12:02:59 +0100
Subject: [PATCH] org.el: Change indention for cdlatex environments
* org.el (org-cdlatex-environment-indent): Use different indent
algorithm based on content above the new latex-environment.
---
lisp/org.el | 59 ++-
1 file changed, 54 insertions(+), 5 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4f047b2..e15e622 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18645,12 +18645,61 @@ Revert to the normal definition outside of these fragments."
(call-interactively (key-binding (vector last-input-event))
(defun org-cdlatex-environment-indent (&optional environment item)
- "Execute `cdlatex-environment' and indent the inserted environment."
+ "Execute `cdlatex-environment' and indent the inserted environment.
+
+ENVIRONMENT and ITEM are passed to `cdlatex-environment'.
+
+The inserted environment is indented to current indentation
+unless point is at the beginning of the line, in which the
+environment remains unintended."
(interactive)
- (cdlatex-environment environment item)
- (let ((element (org-element-at-point)))
-(org-indent-region (org-element-property :begin element)
- (org-element-property :end element
+ ;; cdlatex-environment always return nil. Therefore, capture output
+ ;; first and determine if an environment was selected.
+ (let* ((beg (point-marker))
+ (end (copy-marker (point) t))
+ (inserted (progn
+ (ignore-errors (cdlatex-environment environment item))
+ (< beg end)))
+ ;; Figure out how many lines to move forward after the
+ ;; environment has been inserted.
+ (lines (when inserted
+ (save-excursion
+ (- (cl-loop while (< beg (point))
+with x = 0
+do (forward-line -1)
+(cl-incf x)
+finally return x)
+ (if (progn (goto-char beg)
+ (and (progn (skip-chars-forward " \t") (eolp))
+ (progn (skip-chars-backward " \t") (bolp
+ 1 0)
+ (env (org-trim (delete-and-extract-region beg end
+(when inserted
+ ;; Get indentation of next line unless at column 0.
+ (let ((ind (if (bolp) 0
+ (save-excursion
+ (org-return-indent)
+ (prog1 (org-get-indentation)
+ (when (progn (skip-chars-forward " \t") (eolp))
+ (delete-region beg (point)))
+ (bol (progn (skip-chars-backward " \t") (bolp
+ ;; Insert a newline before environment unless at column zero
+ ;; to "escape" the current line. Insert a newline if
+ ;; something is one the same line as \end{ENVIRONMENT}.
+ (insert
+ (concat (unless bol "\n") env
+ (when (and (skip-chars-forward " \t") (not (eolp))) "\n")))
+ (unless (zerop ind)
+ (save-excursion
+ (goto-char beg)
+ (while (< (point) end)
+ (unless (eolp) (org-indent-line-to ind))
+ (forward-line
+ (goto-char beg)
+ (forward-line lines)
+ (org-indent-line-to ind)))
+(set-marker beg nil)
+(set-marker end nil)))
LaTeX fragments
--
2.3.0
[O] Set a property or take action on state change to done
I know the hooks are in there somewhere, but is there any relatively straightforward way to set a particular property, or run a function to do so, when a TODO changes status to a DONE state? Thanks! Subhan This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you.
Re: [O] Citation syntax: a revised proposal
Hi,
Nicolas Goaziou writes:
> Richard Lawrence writes:
>> We have already seen a couple of examples in this thread of properties
>> that one might want to specify in a backend-agnostic way:
>> - special-case capitalization
>> - user-defined type/command/label/etc.
>>
>> Other things one might want to do include:
>> - indicating when a citation should be placed in a footnote
>> - extracting arbitrary bibliographic field(s)
>
> I disagree. These properties should be associated to the subtype.
> Having two places to set them is asking for trouble.
>
> IMO, there is little incentive to define a set of options for a single
> use. Creating a dedicated subtype /once/ makes more sense.
>
> Also the syntax stays clean.
+1. A subtype is ∞ customizable. With a highlevel API, e.g. based on
org-bibtex plist is enough for any relevant task.
>> - providing an overlay string for displaying complicated/ugly
>> citations
>
> I don't think Org should provide this. Overlays are slow. Also, there is
> no good default for displaying citations. However, an external library
> could do that.
I think overlays would be nice, e.g. for multiple authors, but [cite: pre
@key post] it's almost effortless to read, so I don't care much.
Someone mentioned that e.g. Zotero has poor keys by default. Of course
one way to get around this is inserting a zotero entry as a org-bibtex
entry and give it nice key. Problem solved.
>> And I think there is no reason, at the moment, to expect that these are
>> the only possible uses for arbitrary backend-agnostic properties that a
>> user can interpret, either via export filters or via in-buffer
>> customizations.
>
> Export filters are orthogonal to the problem at hand. They are applied
> after handlers. We are discussing about handlers here (e.g., there are
> custom link types and export filters for links).
+1. Handling subtypes in a filter is a bad idea. It's already hard doing
stuff without extracting the element from the text-properties.
Customization should be done over a list of plist of entries imo, e.g.
((:common-pre "pre" :common-post "post" :type "cite" :subtype "subtype")
(:type "article" :title "t" :author "a" :pre "pre" :post "post")
(:type "article" :title "t" :author "a" :pre "pre" :post "post"))
Utility functions like citeauthor should be available so that you can
generate e.g. genetive cite as
(cite-mapconcat
(lambda (cite) (concat (citeauthor cite) "'s (" (citeyeat cite) ")" ))
citations)
> I think we should postpone the idea of attributes for object, as it gets
> in the way of the discussion. IMO,
>
> [cite/subtype: ...]
>
> is all we need, syntax-wise.
+1
Though [cite:subtype:whatever] has a higher RK metric. . .
—Rasmus
--
Me gusta la noche, me gustas tú
Re: [O] Citation syntax: a revised proposal
Aaron Ecay writes: > Hi Nicolas, > > 2015ko otsailak 18an, Nicolas Goaziou-ek idatzi zuen: >> >> I think we should postpone the idea of attributes for object, as it gets >> in the way of the discussion. IMO, >> >> [cite/subtype: ...] >> >> is all we need, syntax-wise. > > The question of attributes for objects arose out of the desire to attach > attributes to citations. So, I think it needs to be decided whether to > support a special syntax for citation attributes, or defer that to the > more general question of attributes for objects. In the latter case, a > significant number of “power user” (read: early adopter) features won’t > be available until object attributes are also implemented. Attributes are useful in their own right, but for the problem at hand they are a distraction (IMO, but I'm also not a power-user). > IOW, citation syntax and object attributes are separate discussions, > but are also (possibly) both part of the path from the status quo to > citation support in org core. Why? With one λ the sky is the limit! It can call whatever crazy functions that do whatever crazy things you can imagine. IOW: if you are old enough to color your citations pink in latex you are also old enough to write a macro that adds [cite:COLOR] or [cite:subtype-color] for all colors in the rainbow... —Rasmus -- Me gusta la noche, me gustas tú
Re: [O] Citation syntax: a revised proposal
I was thinking the same thing as Aaron ;) What could one do with a "link-like" object with arbitrary attributes/properties... Hmm... maybe this idea: http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ without the kludgy parsing? It will be so confusing to future people why they have to have a cite: in them ;) Aaron Ecay writes: > Hi Samuel, > > 2015ko otsailak 18an, Samuel Wales-ek idatzi zuen: >> >> i have a silly question: whatever syntax we choose, will it be able to >> be used, in the future, for new org features nobody has thought of >> yet, that are unrelated to citations? > > Do you mean how the syntax and implementation of links was used to > support a new org feature completely unrelated to web URLs, namely > citations? ;) > > [It’s entirely unclear from your message, at least to me, whether you > think these future features would be a good thing or a bad thing.] -- 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] Citation syntax: a revised proposal
hi aaron, On 2/18/15, Aaron Ecay wrote: > Do you mean how the syntax and implementation of links was used to > support a new org feature completely unrelated to web URLs, namely > citations? ;) heh heh. :] that applies to the outer syntax only. i mean, for example, plists vs. something less general. > [It’s entirely unclear from your message, at least to me, whether you > think these future features would be a good thing or a bad thing.] they haven't happened yet, so i don't have an opinion on them. :] samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Citation syntax: a revised proposal
Hi Samuel, 2015ko otsailak 18an, Samuel Wales-ek idatzi zuen: > > i have a silly question: whatever syntax we choose, will it be able to > be used, in the future, for new org features nobody has thought of > yet, that are unrelated to citations? Do you mean how the syntax and implementation of links was used to support a new org feature completely unrelated to web URLs, namely citations? ;) [It’s entirely unclear from your message, at least to me, whether you think these future features would be a good thing or a bad thing.] -- Aaron Ecay
Re: [O] Citation syntax: a revised proposal
Hi Nicolas, 2015ko otsailak 18an, Nicolas Goaziou-ek idatzi zuen: > > I think we should postpone the idea of attributes for object, as it gets > in the way of the discussion. IMO, > > [cite/subtype: ...] > > is all we need, syntax-wise. The question of attributes for objects arose out of the desire to attach attributes to citations. So, I think it needs to be decided whether to support a special syntax for citation attributes, or defer that to the more general question of attributes for objects. In the latter case, a significant number of “power user” (read: early adopter) features won’t be available until object attributes are also implemented. IOW, citation syntax and object attributes are separate discussions, but are also (possibly) both part of the path from the status quo to citation support in org core. -- Aaron Ecay
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes:
> I know that this is technically easy to handle from the backend's
> perspective. But I have a concern related to Stefan's:
>
> Stefan Nobis writes:
>
>> The drawback is that now subtype is hard or even impossible to vary
>> for different backends. Therefore I would suggest that either org has
>> to define the allowed values of subtype or else we should define that
>> subtype has to be handled by the user (e.g. for use in private filter
>> functions) and is out of the scope of org (maybe this would be a good
>> place of extensions like org-ref to plug in their machinery).
>
> Basically, I am worried that neither of these options is very good.
>
> If the subtype is interpreted by backends, I think it will become hard
> to use as an author. If each backend treats different subtypes as
> significant, but some backends overlap in which subtypes they accept,
> then as an author you have to keep track of which subtypes work in which
> backends, and which don't, and whether the default behavior is OK for
> your citations in backends you care about. If you are targeting more
> than one backend, that could mean a lot of trips to the manual. And if
> user-supplied subtypes are also permissible, you have to keep track of
> the distinction between `official' subtypes and your own.
I wasn't clear. Subtype should be interpreted by back-ends means it has
no impact on syntax. However a user should be able to dictate what the
back-end should do with it, much like `org-add-link-type'.
A new library, e.g. "org-cite.el" would provide all the tools necessary
to build custom handlers for subtypes. Thus, power users can do whatever
they want with cite objects.
Nevertheless, Org needs to provide at least one built-in handler so
casual users are not required to do anything when writing
[cite: see @Doe98 p.87] or even @Doe99.
This default handler may be also customized by power users, but we're
not there yet.
> On the other hand, if the subtype is just a user-supplied label, which
> can be interpreted by a filter but which backends will otherwise ignore,
> things are nice and simple. You just don't use a subtype unless you are
> also supplying a way to interpret it on every backend that you care
> about. But that kind of situation is exactly what the extra-info part
> of the syntax is for; in that case,
>
> [cite/my-subtype: ...]
>
> would just be an exceptional way of writing
>
> [cite: ...]{:type my-subtype}
>
> or whatever. I'm not totally convinced yet that the convenience of the
> former is worth blurring the line between `stuff that definitely works
> on all backends' and `stuff that might not work on all backends'.
>
>> Moreover [cite: ...]{...} syntax really makes sense if it is the
>> equivalent to #+attr_... keywords, so we can generalize it to links. As
>> a consequence, {...} should include a reference to back-end. E.g.,
>>
>> [cite:...]{latex :color pink}
>
> We have already seen a couple of examples in this thread of properties
> that one might want to specify in a backend-agnostic way:
> - special-case capitalization
> - user-defined type/command/label/etc.
>
> Other things one might want to do include:
> - indicating when a citation should be placed in a footnote
> - extracting arbitrary bibliographic field(s)
I disagree. These properties should be associated to the subtype.
Having two places to set them is asking for trouble.
IMO, there is little incentive to define a set of options for a single
use. Creating a dedicated subtype /once/ makes more sense.
Also the syntax stays clean.
> - providing an overlay string for displaying complicated/ugly
> citations
I don't think Org should provide this. Overlays are slow. Also, there is
no good default for displaying citations. However, an external library
could do that.
> And I think there is no reason, at the moment, to expect that these are
> the only possible uses for arbitrary backend-agnostic properties that a
> user can interpret, either via export filters or via in-buffer
> customizations.
Export filters are orthogonal to the problem at hand. They are applied
after handlers. We are discussing about handlers here (e.g., there are
custom link types and export filters for links).
> So I suggest that we also allow backend-agnostic properties here in
> addition to backend-specific ones. My preference would be that we just
> let these backend-agnostic properties occur at the front, and separate
> the backend-specific ones with labeled pipes, like you suggested
> earlier:
>
> [cite: ...]{:my-key1 my-val1 ... |latex: :lkey1 lval1 ... |html: ...}
>
> I'm OK with disallowing the backend-agnostic properties for other types
> of objects if that is necessary, though I don't see how it would hurt to
> allow them, as long as it's not Org's responsibility to interpret
> them.
I think we should postpone the idea of attributes for object, as it gets
in the way of the discussion. IMO,
[cite/subtype: ...
Re: [O] Embedding diagrams in Org
On Wednesday, 18 Feb 2015 at 13:51, Eduardo Ochs wrote: [...] > perfect, as it supposes that the person trying it has already enabled > latex support in babel! You mean people don't automatically have this enabled already? ;-) But, yes, you are correct! My org customisations are so many that I forget what are defaults and what are not. I'm glad that you got help from #org-mode; I actually have that channel in another emacs window but I wasn't looking at it. I keep telling myself to get another monitor but there isn't room for a third one on my desk :( I do wonder, however, why we need to turn languages on or off? It would be nice if org-babel would do this automatically when a language specific src block is encountered... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-843-ga5f1a3.dirty
Re: [O] Embedding diagrams in Org
Hi,
Eric S Fraga writes:
> On Wednesday, 18 Feb 2015 at 13:34, Marcin Borkowski wrote:
>> Hello all,
>>
>> I need to embed some diagrams (graphs of functions, for instance, or
>> trees) in an Org file. Any suggestions on how to do it? In case of
>> ditaa, I can use a source block and the "results" line, and see the
>> image with C-c C-x C-v. Can I do a similar thing with Asymptote? How
>> hard/time-consuming would it be to add support e.g. for tikz or other
>> such tools?
>
> Support for tikz is there implicitly in that there is support for
> LaTeX. I use tikz all the time.
>
> Simple example attached.
>
> I do believe others have used asymptote in the past.
>
> HTH,
> eric
I also use tikz in my org files. I just include a slightly more
involved version of Eric's example to show some of the beauty of org.
This includes a caption for the diagram, and different output formats
for different export routes.
Best,
Andreas
--8<---cut here---start->8---
#+LATEX_HEADER: \usepackage{tikz}
* tikz example
#+name: tikz_example
#+header: :packages '(("" "tikz"))
#+header: :file (by-backend (latex "example_diagram.tikz") (html
"example_diagram.svg") (t "example_diagram.png"))
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 800
#+header: :results file raw
#+header: :fit yes
#+begin_src latex
\begin{tikzpicture}
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[->] (a) -- (b);
\end{tikzpicture}
#+end_src
#+caption: A tikz example diagram with a caption
#+results: tikz_example
[[file:example_diagram.png]]
--8<---cut here---end--->8---
Re: [O] Citation syntax: a revised proposal
[disclaimer: i do not currently use citations, so i have no stake in citation syntax per se, just a tendency to ask highly generic silly questions.]
Re: [O] Citation syntax: a revised proposal
i have a silly question: whatever syntax we choose, will it be able to be used, in the future, for new org features nobody has thought of yet, that are unrelated to citations? my preference is to forestall future syntax creep, enhance consistency, and amortize the effort in supporting a syntax [including e.g. supporting quoting, escaping, hiding, labeling, nesting, debugging, parsing, searching, etc.]. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
[O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil
Hi Glenn,
> Damian Nadales wrote:
>
>
> > - Run emacs -Q
> >
> > - Create an org-mode file (i.e. ``myorgfile.org``)
> >
> > - Insert the following text:
> >
> > o #+BEGIN_SRC C++
> >
> > #+END_SRC
> >
> > - Edit the source block by placing the cursor inside the SRC block.
> >
[Damian Nadales]
By the way, here editing should be done by placing the cursor in the org buffer
``myorgfile.org``, and then pressing C-' to edit the source code in a different
buffer. And this is the buffer that cannot be killed.
> > - Start C++ mode (c++-mode)
> >
> > - Try to kill the buffer.
>
> Please do
>
> M-x toggle-debug-on-error
>
> repeat the problem, and post the resulting backtrace.
> (I can't reproduce it.)
[Damian Nadales]
This is what I got.
Debugger entered--Lisp error: (wrong-type-argument overlayp nil)
delete-overlay(nil)
#[nil "\301!\207" [org-edit-src-overlay delete-overlay] 2]()
kill-buffer("*Org Src myorgfile.org[ c++ ]*")
call-interactively(kill-buffer nil nil)
command-execute(kill-buffer)
Thanks for your help.
-- The information contained in this communication and any attachments is
confidential and may be privileged, and is for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. Unless explicitly stated otherwise in the body of this
communication or the attachment thereto (if any), the information is provided
on an AS-IS basis without any express or implied warranties or liabilities. To
the extent you are relying on this information, you are doing so at your own
risk. If you are not the intended recipient, please notify the sender
immediately by replying to this message and destroy all copies of this message
and any attachments. The sender nor the company/group of companies he or she
represents shall be liable for the proper and complete transmission of the
information contained in this communication, or for any delay in its receipt.
Re: [O] Citation syntax: a revised proposal
Hi Nicolas and all,
Nicolas Goaziou writes:
> Richard Lawrence writes:
>
>> Actually, your post has convinced me that it may be worth allowing some
>> explicit name for a type in the [cite: ...] part of the syntax, although
>> I am still leery about what this would mean for non-LaTeX backends.
>
> Each back-end can decide to use it or simply ignore it. Also [cite:...]
> should be equivalent to [cite:default: ...], for some value of "default"
> decided by the target back-end.
I know that this is technically easy to handle from the backend's
perspective. But I have a concern related to Stefan's:
Stefan Nobis writes:
> The drawback is that now subtype is hard or even impossible to vary
> for different backends. Therefore I would suggest that either org has
> to define the allowed values of subtype or else we should define that
> subtype has to be handled by the user (e.g. for use in private filter
> functions) and is out of the scope of org (maybe this would be a good
> place of extensions like org-ref to plug in their machinery).
Basically, I am worried that neither of these options is very good.
If the subtype is interpreted by backends, I think it will become hard
to use as an author. If each backend treats different subtypes as
significant, but some backends overlap in which subtypes they accept,
then as an author you have to keep track of which subtypes work in which
backends, and which don't, and whether the default behavior is OK for
your citations in backends you care about. If you are targeting more
than one backend, that could mean a lot of trips to the manual. And if
user-supplied subtypes are also permissible, you have to keep track of
the distinction between `official' subtypes and your own.
On the other hand, if the subtype is just a user-supplied label, which
can be interpreted by a filter but which backends will otherwise ignore,
things are nice and simple. You just don't use a subtype unless you are
also supplying a way to interpret it on every backend that you care
about. But that kind of situation is exactly what the extra-info part
of the syntax is for; in that case,
[cite/my-subtype: ...]
would just be an exceptional way of writing
[cite: ...]{:type my-subtype}
or whatever. I'm not totally convinced yet that the convenience of the
former is worth blurring the line between `stuff that definitely works
on all backends' and `stuff that might not work on all backends'.
> Moreover [cite: ...]{...} syntax really makes sense if it is the
> equivalent to #+attr_... keywords, so we can generalize it to links. As
> a consequence, {...} should include a reference to back-end. E.g.,
>
> [cite:...]{latex :color pink}
We have already seen a couple of examples in this thread of properties
that one might want to specify in a backend-agnostic way:
- special-case capitalization
- user-defined type/command/label/etc.
Other things one might want to do include:
- indicating when a citation should be placed in a footnote
- extracting arbitrary bibliographic field(s)
- providing an overlay string for displaying complicated/ugly citations
And I think there is no reason, at the moment, to expect that these are
the only possible uses for arbitrary backend-agnostic properties that a
user can interpret, either via export filters or via in-buffer
customizations.
So I suggest that we also allow backend-agnostic properties here in
addition to backend-specific ones. My preference would be that we just
let these backend-agnostic properties occur at the front, and separate
the backend-specific ones with labeled pipes, like you suggested
earlier:
[cite: ...]{:my-key1 my-val1 ... |latex: :lkey1 lval1 ... |html: ...}
I'm OK with disallowing the backend-agnostic properties for other types
of objects if that is necessary, though I don't see how it would hurt to
allow them, as long as it's not Org's responsibility to interpret them.
Best,
Richard
Re: [O] Embedding diagrams in Org
On Wed, Feb 18, 2015 at 12:19 PM, Eric S Fraga wrote:
> On Wednesday, 18 Feb 2015 at 13:34, Marcin Borkowski wrote:
>> Hello all,
>>
>> I need to embed some diagrams (graphs of functions, for instance, or
>> trees) in an Org file. Any suggestions on how to do it? In case of
>> ditaa, I can use a source block and the "results" line, and see the
>> image with C-c C-x C-v. Can I do a similar thing with Asymptote? How
>> hard/time-consuming would it be to add support e.g. for tikz or other
>> such tools?
>
> Support for tikz is there implicitly in that there is support for
> LaTeX. I use tikz all the time.
>
> Simple example attached.
>
> I do believe others have used asymptote in the past.
>
> HTH,
> eric
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
> release_8.3beta-843-ga5f1a3.dirty
Hi Eric,
I tested your example - with `C-c C-e l o' to export to LaTeX and open
the PDF file -, and the ellipse in the middle of the sentence appeared,
but the block
#+begin_src latex :results latex raw :exports results
\begin{tikzpicture}
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[->] (a) -- (b);
\end{tikzpicture}
#+end_src
did not make its way to the t.tex file... I asked for help in the
#org-mode channel at freenode, as I am an Org newbie, and found a fix.
Your example is one of the best one I've seen so far of diagrams-
in-Org-for-newbies, but it seems to be at least one micro-bug from
perfect, as it supposes that the person trying it has already enabled
latex support in babel!
Here is an idea to make your example more newbie-friendly: add the
comments below to it.
# Note that you may have to add latex support to babel
# to make the tikzpicture block work...
# see: (info "(org)Languages")
# try: (org-babel-do-load-languages 'org-babel-load-languages '((latex . t)))
#
# To disable to question "Evaluate this latex code block on your system?",
# see: (info "(org)Code evaluation security")
# try: (setq org-confirm-babel-evaluate nil)
Cheers =),
Eduardo Ochs
eduardoo...@gmail.com
http://angg.twu.net/
http://angg.twu.net/eev-intros/find-eval-intro.html
Re: [O] [bug] Alignment bug in clock tables
Stormking writes:
> You are right but I always have pretty entities turned on, so
> it doesn't bother me that much. Wasn't it changed to \emsp
> (m-dash) so it would look better in exported HTML or LaTeX?
It was.
> Otherwise, I would suggest something like \-- or \__
See above.
> I just tested the alignment in a generic table. I have set \emsp
> to be displayed as as dash ("-"). An explicit re-align of a table
> containing this entity works,
Same as displaying "-".
> but the auto-alignment that happens while you type does not.
Ditto.
Regards,
Re: [O] [bug] Alignment bug in clock tables
Stormking web.de> writes: > Wasn't it changed to \emsp > (m-dash) so it would look better in exported HTML or LaTeX? I have to correct myself on this one, \emsp ist a m-space, not a m-dash
Re: [O] [BUG] org-clock-display is partial (only some entries are counted)
Nicolas Goaziou wrote: > Sebastien Vauban writes: > >>> See `org-clock-display-default-range'. Basically, clock display only >>> consider clocks in the current year, by default. >> >> For me, what makes more sense is "show all" (as, unlike dynamic blocks, >> we have no visible indication of what's get considered in the total). >> >> Though, it seems not to exit... > > With a double prefix argument, you can specify interactively an > arbitrary wide range (e.g., "-15y" "+15y"). I still consider the default behavior as dangerous -- because the novice is not aware (except if obvious) that some clock times may be dropped in the computation, and I find that scary --, but thanks anyway for the workaround. Best regards, Seb -- Sebastien Vauban
Re: [O] [bug] Alignment bug in clock tables
Nicolas Goaziou nicolasgoaziou.fr> writes:
>
> Stormking web.de> writes:
>
> > Wouldn't it be better to fix the alignment code so it works with
> > pretty entities? Because that's the real problem here.
>
> There are two problems here.
>
> One is obviously due to misalignment when using overlays.
>
> The other one is that \emph is not easily readable when
> `org-pretty-entities' is nil.
You are right but I always have pretty entities turned on, so
it doesn't bother me that much. Wasn't it changed to \emsp
(m-dash) so it would look better in exported HTML or LaTeX?
Otherwise, I would suggest something like \-- or \__
I just tested the alignment in a generic table. I have set \emsp
to be displayed as as dash ("-"). An explicit re-align of a table
containing this entity works, but the auto-alignment that
happens while you type does not.
Ciao, Stormking
Re: [O] on the fragility of export to ODT
On Wednesday, 18 Feb 2015 at 14:55, Nicolas Goaziou wrote: [...] > Apparently `org-odt-inline-image-rules' dismisses pdf files as images. > What happens if you add PDF extension to the list? Ah ha! Adding pdf to the list of extensions (using customize, not editing the code at this point) enables the exporter to run to completion. This is a great step forward as I can now get a document that I can do something with. The exporter seems to be collecting the images: they end up in the actual ODT file. However, viewing the file in libreoffice shows placeholders where the images should be but with a "Read-Error" message. The captions are there but the images are empty. I guess that libreoffice cannot handle PDF images, which probably shouldn't surprise me... Now that I know what the problem is, I can see a way forward: all of my images are created within the org document using babel and I can have an alternate target of PNG for odt export. I would imagine that the easiest change in org would be to simply have an error message telling the user that PDF files cannot be used as images? Alternatively, would it be possible to invoke imagemagick to convert PDF images to PNG as we do with LaTeX snippets? Thanks for all your help on this, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-843-ga5f1a3.dirty
Re: [O] [BUG] org-clock-display is partial (only some entries are counted)
Sebastien Vauban writes: >> See `org-clock-display-default-range'. Basically, clock display only >> consider clocks in the current year, by default. > > For me, what makes more sense is "show all" (as, unlike dynamic blocks, > we have no visible indication of what's get considered in the total). > > Though, it seems not to exit... With a double prefix argument, you can specify interactively an arbitrary wide range (e.g., "-15y" "+15y"). Regards,
Re: [O] [bug] Alignment bug in clock tables
Stormking writes: > Wouldn't it be better to fix the alignment code so it works with > pretty entities? Because that's the real problem here. There are two problems here. One is obviously due to misalignment when using overlays. The other one is that \emph is not easily readable when `org-pretty-entities' is nil. Patches welcome. Regards,
Re: [O] [bug] Alignment bug in clock tables
Nicolas Goaziou nicolasgoaziou.fr> writes: > > Hello, > > Stormking web.de> writes: > > > Without any effect, it seems. I wonder if anybody actually uses these > > features. > > What character do you suggest to use instead of \emph? Wouldn't it be better to fix the alignment code so it works with pretty entities? Because that's the real problem here.
Re: [O] [bug] Alignment bug in clock tables
Hello, Stormking writes: > Without any effect, it seems. I wonder if anybody actually uses these > features. What character do you suggest to use instead of \emph? "*" is not possible due to a collision with bold syntax (i.e. "***" is parsed as a bold star). Regards, -- Nicolas Goaziou
Re: [O] Embedding diagrams in Org
On Wednesday, 18 Feb 2015 at 13:34, Marcin Borkowski wrote:
> Hello all,
>
> I need to embed some diagrams (graphs of functions, for instance, or
> trees) in an Org file. Any suggestions on how to do it? In case of
> ditaa, I can use a source block and the "results" line, and see the
> image with C-c C-x C-v. Can I do a similar thing with Asymptote? How
> hard/time-consuming would it be to add support e.g. for tikz or other
> such tools?
Support for tikz is there implicitly in that there is support for
LaTeX. I use tikz all the time.
Simple example attached.
I do believe others have used asymptote in the past.
HTH,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
release_8.3beta-843-ga5f1a3.dirty
#+latex_header: \usepackage{tikz}
* tikz with babel
This example generates a figure using tikz and exports it as raw latex
#+begin_src latex :results latex raw :exports results
\begin{tikzpicture}
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[->] (a) -- (b);
\end{tikzpicture}
#+end_src
Alternatively, you can put tikz inline:
#+latex: \tikz \draw[rotate=30] (0,0) ellipse (6pt and 3pt);
which should appear in the middle of the sentence.
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes:
> Actually, your post has convinced me that it may be worth allowing some
> explicit name for a type in the [cite: ...] part of the syntax, although
> I am still leery about what this would mean for non-LaTeX backends.
Each back-end can decide to use it or simply ignore it. Also [cite:...]
should be equivalent to [cite:default: ...], for some value of "default"
decided by the target back-end.
> I did not appreciate before that switching from one type to another is
> something you probably want to be able to do really easily, like with
> query-replace, even if you are making use of the other parts of the
> syntax to express distinctions like in-text vs. parenthetical
> citations.
>
> So, two questions for the group:
>
> 1) Is it worth allowing a name for a user-defined type in the [cite: ...]
> part, or is it OK to confine user-defined types to the second part
> (like: [cite: ...] %%(:type foo) or [cite: ...]{:type foo})?
Expecting subtype in the header doesn't add a limitation to pre or post
text.
Moreover [cite: ...]{...} syntax really makes sense if it is the
equivalent to #+attr_... keywords, so we can generalize it to links. As
a consequence, {...} should include a reference to back-end. E.g.,
[cite:...]{latex :color pink}
> 2) If a user-defined type can go in the [cite: ...] part, where should
> it go? Nicolas has suggested:
>
> [cite:subtype ...]
>
> or
>
> [cite:subtype: ...]
>
> I would personally (aesthetically, don't ask me why) prefer:
>
> [cite/subtype: ...]
>
> or
>
> [cite|subtype: ...]
>
> But maybe there are other options I haven't thought of.
I'm fine with any of these, although the latter looks less nice to me.
Regards,
Re: [O] Bug: code blocks with multiple word names create single word result-blocks leading to collisions [8.2.10 (8.2.10-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20141013/)]
Hello,
Joost Helberg writes:
> noweb-syntax allows blanks in names of code blocks. The result-blocks
> of these code blocks are named as well, but have everything behind the
> first word stripped. This leads to result-block collisions in case
> there are two code blocks starting with the same word.
>
> Is this intentional? Why doesn't org-mode support sentences for code
> block names?
>
> It boils down to the regexp /org-babel-src-name-w-name-regexp/. It
> matches a name; the match-string function is used for retrieving this
> name. The regexp should obviously match the rest of the text too.
>
> The original ob-core.el uses:
> ="\\([^ ()\f\t\n\r\v]+\\)"=
> to match the name. Check the ' ' behind the caret.
>
> The regexp I tested has the space removed. Hence, it will match the
> full length name.
> #+begin_src emacs-lisp
> (setq org-babel-src-name-w-name-regexp
> (concat org-babel-src-name-regexp
> "\\("
> org-babel-multi-line-header-regexp
> "\\)*"
> "\\([^()\f\t\n\r\v]+\\)"))
> #+end_src
>
>
> Will this just fix or also break things? Was the blank deliberately
> added? If all OK, can someone please commit/push it?
Applied. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Bug: code blocks with multiple word names create single word result-blocks leading to collisions [8.2.10 (8.2.10-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20141013/)]
Joost Helberg wrote: > "Sebastien" == Sebastien Vauban writes: >> Joost Helberg wrote: >>> noweb-syntax allows blanks in names of code blocks. > >> Are you sure? Where did you read that? > > It's in https://www.cs.tufts.edu/~nr/noweb/johnson-lj.pdf. Well, that's the real noweb, not Org's partial implementation. > In org-mode it works as specified; the noweb expansion of names with > multiple words works fine. > >>> The result-blocks of these code blocks are named as well, but have >>> everything behind the first word stripped. This leads to >>> result-block collisions in case there are two code blocks starting >>> with the same word. > >> Quite logic if, in fact, it just reads the first token... which is >> what happens, IIUC. > > I expect it to read the full name, which may have more than one word. > >> Of course, you could expect to get an error or warning reported. > > In order to run snippets of code which are also in use as noweb-items, > it's currently impossible to use names with multiple words where the > first word collides with other names. My patch allows the use of code > blocks with sentences as names hence enjoying the literate in literate > programming a lot more. > > I fail to see a reason for the result-blocks to have only one-word > names, it doesn't break anything if these carry the full name of the > code block. I understand you may desire that, and that it can be useful, but I'm not sure whether this is so obvious to implement. Nicolas will certainly give you more information on that. Best regards, Seb -- Sebastien Vauban
Re: [O] on the fragility of export to ODT
Eric S Fraga writes:
> Your suggested change does indeed yield more interesting and, I guess,
> potentially more helpful information. The output is:
>
> ,
> | OpenDocument export failed: FIXME: Resolve #("#+NAME: fig:radar-chart-urea
> | #+CAPTION: Radar chart for the urea process which does not require a
> catalyst.
> | #+RESULTS[10c1bfffde9a020d138a430992eb2f43c29c9257]:
> | [[file:radar-chart-urea.pdf]]
> |
> | " 40 107 (:parent (#("Radar chart for the urea process which does not
> require a catalyst." 0 67 (:parent #2)
> `
>
> but it unfortunately doesn't tell me how to fix the problem.
Apparently `org-odt-inline-image-rules' dismisses pdf files as images.
What happens if you add PDF extension to the list?
Regards,
Re: [O] Bug: code blocks with multiple word names create single word result-blocks leading to collisions [8.2.10 (8.2.10-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20141013/)]
Sebastian, > "Sebastien" == Sebastien Vauban writes: > From: Sebastien Vauban > To: emacs-orgmode@gnu.org > Subject: Re: [O] Bug: code blocks with multiple word names create > Date: 2015-02-18T14:06:07+0100 > Hello, > Joost Helberg wrote: >> noweb-syntax allows blanks in names of code blocks. > Are you sure? Where did you read that? It's in https://www.cs.tufts.edu/~nr/noweb/johnson-lj.pdf. In org-mode it works as specified; the noweb expansion of names with multiple words works fine. >> The result-blocks of these code blocks are named as well, but have >> everything behind the first word stripped. This leads to result-block >> collisions in case there are two code blocks starting with the same >> word. > Quite logic if, in fact, it just reads the first token... which is what > happens, IIUC. I expect it to read the full name, which may have more than one word. > Of course, you could expect to get an error or warning reported. In order to run snippets of code which are also in use as noweb-items, it's currently impossible to use names with multiple words where the first word collides with other names. My patch allows the use of code blocks with sentences as names hence enjoying the literate in literate programming a lot more. I fail to see a reason for the result-blocks to have only one-word names, it doesn't break anything if these carry the full name of the code block. regards, Joost > Best regards, > Seb > -- > Sebastien Vauban -- Snow B.V.
Re: [O] Bug: code blocks with multiple word names create single word result-blocks leading to collisions [8.2.10 (8.2.10-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20141013/)]
Hello, Joost Helberg wrote: > noweb-syntax allows blanks in names of code blocks. Are you sure? Where did you read that? > The result-blocks of these code blocks are named as well, but have > everything behind the first word stripped. This leads to result-block > collisions in case there are two code blocks starting with the same > word. Quite logic if, in fact, it just reads the first token... which is what happens, IIUC. Of course, you could expect to get an error or warning reported. Best regards, Seb -- Sebastien Vauban
[O] Bug: code blocks with multiple word names create single word result-blocks leading to collisions [8.2.10 (8.2.10-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20141013/)]
hi,
noweb-syntax allows blanks in names of code blocks. The result-blocks
of these code blocks are named as well, but have everything behind the
first word stripped. This leads to result-block collisions in case
there are two code blocks starting with the same word.
Is this intentional? Why doesn't org-mode support sentences for code
block names?
It boils down to the regexp /org-babel-src-name-w-name-regexp/. It
matches a name; the match-string function is used for retrieving this
name. The regexp should obviously match the rest of the text too.
The original ob-core.el uses:
="\\([^ ()\f\t\n\r\v]+\\)"=
to match the name. Check the ' ' behind the caret.
The regexp I tested has the space removed. Hence, it will match the
full length name.
#+begin_src emacs-lisp
(setq org-babel-src-name-w-name-regexp
(concat org-babel-src-name-regexp
"\\("
org-babel-multi-line-header-regexp
"\\)*"
"\\([^()\f\t\n\r\v]+\\)"))
#+end_src
Will this just fix or also break things? Was the blank deliberately
added? If all OK, can someone please commit/push it?
Example code below:
The following snippet can be executed (C-c C-c) and included in some
script down at the bottom of this file.
#+NAME: echo the stuff
#+BEGIN_SRC sh
echo "ape nut miss"
#+END_SRC
#+RESULTS: echo the stuff
: ape nut miss
Do names with only one word still work?
#+NAME: doit
#+BEGIN_SRC sh
echo "cat boom spoil"
#+END_SRC
#+RESULTS: doit
: cat boom spoil
The next snippet will leave it's result after being executed in the
above #+RESULT: line, not the result below the code. It can be
included however in the bottom-script using noweb notation.
#+NAME: echo other stuff
#+BEGIN_SRC sh
echo "tune fire goat"
#+END_SRC
#+RESULTS: echo other stuff
: tune fire goat
We use this shell-snippet in the following script and execute it,
noweb works fine:
#+BEGIN_SRC sh :noweb yes
<>
<>
#+END_SRC
#+RESULTS:
| ape | nut | miss |
| tune | fire | goat |
many regards,
Joost
Emacs : GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
of 2014-10-13 on w520jo
Package: Org-mode version 8.2.10 (8.2.10-elpaplus @
/home/joost/.emacs.d/elpa/org-plus-contrib-20141013/)
--
Snow B.V.
[O] Embedding diagrams in Org
Hello all, I need to embed some diagrams (graphs of functions, for instance, or trees) in an Org file. Any suggestions on how to do it? In case of ditaa, I can use a source block and the "results" line, and see the image with C-c C-x C-v. Can I do a similar thing with Asymptote? How hard/time-consuming would it be to add support e.g. for tikz or other such tools? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] [BUG] org-clock-display is partial (only some entries are counted)
Hello, Nicolas Goaziou wrote: > Sebastien Vauban writes: > >> As you can see on http://screencast.com/t/B0knccOCqco, the output of the >> command org-clock-display (bound to C-c C-x C-d) -- which displays >> subtree times in the entire buffer -- is partial: for a reason which >> still escapes me, meetings A and B are not counted... > > See `org-clock-display-default-range'. Basically, clock display only > consider clocks in the current year, by default. For me, what makes more sense is "show all" (as, unlike dynamic blocks, we have no visible indication of what's get considered in the total). Though, it seems not to exit... Best regards, Seb -- Sebastien Vauban
Re: [O] [bug] Alignment bug in clock tables
Francesco Pizzolante writes: > > Hi Stormking, > > Sorry for my very late reply: I thank you very much for your workaround > which enables me to have well aligned clock tables. > > I also take the opportunity to bump up this thread. Without any effect, it seems. I wonder if anybody actually uses these features. Ciao, Stormking
Re: [O] [ANN] org-link-edit.el --- Slurp and barf with Org links
Kyle Meyer writes: > remove description words like Paredit lets you do with S-expressions. > I've put these Paredit-inspired slurping and barfing commands for Org > link descriptions in org-link-edit.el That's so need! Did you/will you add it to contrib? Thanks, Rasmus -- This space is left intentionally blank
Re: [O] ox-html: stand-alone export option?
Hi Melanie, Melanie Bacou writes: > I'm using ox-html to work on shared documents with my > collaborators. We're working off a Dropbox account and converting our > org files to HTML periodically. Cool. > Problem with all cloud storages is they don't work with relative links > inside HTML (links to external images, CSS, and JS resources). I use git and ssh to a wm which I guess is different from "cloud storages" so maybe I don't understand. If you open the browser of my.html and you have an absolute path to https://orgmode.org/logo.png the browser would display it no? Likewise for img/logo.png. Probably I've misunderstood. . . > We would really benefit from having a "stand-alone" HTML exporter > feature that automatically embeds all external references into one > single HTML file, so they can be shared with Dropbox, Google Drive, > OneDrive and the likes. Would you base64 encode images and inline code or do you have something else in mind with single HTML file? It's not built into Org ATM. In the short run maybe there's a tool that can do. For instance, in Firefox it will save auxiliary material when you save a page. I don't know if also save whatever scripts you rely on from whatever CDN far away... > Has this been discussed previously? Would there be any other work around? I think there was one guy who had patch that would automatically download external images. Pretty neat. I don't know if it was applied in the end. —Rasmus -- ツ
Re: [O] Citation syntax: a revised proposal
On Tuesday, 17 Feb 2015 at 20:03, Richard Lawrence wrote: [...] > I would personally (aesthetically, don't ask me why) prefer: > > [cite/subtype: ...] as do I as it mirrows mime-types, e.g. text/plain, text/x-org-mode, ... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-843-ga5f1a3.dirty
Re: [O] on the fragility of export to ODT
On Tuesday, 17 Feb 2015 at 22:04, Nicolas Goaziou wrote:
[...]
> However, there's a simpler solution. In- "ox-odt.el", function
> `org-odt-link--infer-description', line 2655 (but it depends on Org
> version), there is
>
> (t (error "FIXME: Resolve %s" destination))
>
> Replace it with
>
> (t (error "FIXME: Resolve %s" (org-element-interpret-data destination
>
> reload Org then trigger the error. The backtrace should be more interesting.
Hi Nicolas,
thanks for taking the time to try to help me out on this.
Your suggested change does indeed yield more interesting and, I guess,
potentially more helpful information. The output is:
,
| OpenDocument export failed: FIXME: Resolve #("#+NAME: fig:radar-chart-urea
| #+CAPTION: Radar chart for the urea process which does not require a catalyst.
| #+RESULTS[10c1bfffde9a020d138a430992eb2f43c29c9257]:
| [[file:radar-chart-urea.pdf]]
|
| " 40 107 (:parent (#("Radar chart for the urea process which does not require
a catalyst." 0 67 (:parent #2)
`
but it unfortunately doesn't tell me how to fix the problem.
A paragraph back, I have a link [[fig:radar-chart-urea]] and this
information in *Messages* is the full content of where the link target
is defined. If I remove the link, the export fails with a similar error
to above but now due to the next link. Obviously, removing all the
links (or any, for that matter) is not a viable solution...
Any advice?
Thanks again,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
release_8.3beta-843-ga5f1a3.dirty
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes:
> 1) Is it worth allowing a name for a user-defined type in the [cite:
> ...] part, or is it OK to confine user-defined types to the second
> part (like: [cite: ...] %%(:type foo) or [cite: ...]{:type foo})?
IMHO it is better to have such an important part of the citation in a
prominent position, therefore I'm in favour of Nicolas suggestion of
[cite:subtype: ...]{backend options}
with the four variations for "cite" (i.e. "[cite:...]", "[Cite:...]",
"[(cite):...]", and "[(Cite):...]").
The drawback is that now subtype is hard or even impossible to vary
for different backends. Therefore I would suggest that either org has
to define the allowed values of subtype or else we should define that
subtype has to be handled by the user (e.g. for use in private filter
functions) and is out of the scope of org (maybe this would be a good
place of extensions like org-ref to plug in their machinery).
> 2) If a user-defined type can go in the [cite: ...] part, where should
> it go?
> [cite:subtype ...]
> [cite:subtype: ...]
> [cite/subtype: ...]
> [cite|subtype: ...]
I favor [cite:subtype: ...] a very tiny bit over the other variants.
--
Until the next mail...,
Stefan.
