Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'
On Wednesday 11 February 2015 11:32 AM, Vaidheeswaran wrote: This should be fixed. Thank you. Not yet. See attached files. Operator error. Sorry.
Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'
On Wednesday 11 February 2015 02:58 AM, Nicolas Goaziou wrote: Hello, Christian Moe writes: An ODT cross-reference to the footnote? That makes sense, but should that be achieved by footnoting inside a footnote, or is the appropriate thing to do to use a dedicated target and link? [fn:1] footdef1, see also [[thatotherfootnote]]. [fn:2]<>footdef2 That seems to works nicely e.g. in HTML export. But I get an error message when I try it in ODT export (OpenDocument export failed: number-or-marker-p, nil -- can't be more detailed at the moment because my debugger doesn't seem to work correctly). This should be fixed. Thank you. Not yet. See attached files. Regards, text1 [fn:1][fn:2][fn:3] [fn:1] footdef1 [[fn-3]] [fn:2] footdef2 [[See foonotnote 3][fn-3]] [fn:3] <> footdef2 test.odt Description: application/vnd.oasis.opendocument.text
Re: [O] orgmode as a transcription tool?
On Sat Feb 07 2015 at 10:38, Marcin Borkowski wrote: > On 2015-02-03, at 06:45, Basile (The Flammable Project) > wrote: > >> Hello, >> >> You should have a look at EMMS. It's suite easy to setup on linux. But if >> you are using a MS Windows OS, it does requiert more settings. But >> everything you light ne controlable within Emacs. > > FWIW, here's my config (and two helper functions to make seeking a bit > easier): > > http://mbork.pl/2015-02-07_Emms_and_transcripts This is great - many thanks! I'm using it now, taking a break during crosstalk in a recorded meeting. I, too, had problems with skipping backwards - your solution worked for me. And the scale of the skipping is off for me, too - a setting of -10 will skip back about 2 or 3 seconds. I'm doing this on osx with homebrew's build of head-branch emacs and the homebrew mplayer, and it works amazingly well. Cheers - bw -- Bill White . bi...@wolfram.com "No, ma'am, we're musicians."
Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'
On Wednesday 11 February 2015 02:59 AM, Nicolas Goaziou wrote: Hello, Vaidheeswaran C writes: That said, it is difficult for me to conceive of a footnote that is referenced solely by other footnotes. i.e., it is reasonable to assume that a given footnote is either not referenced at all or is referenced atleast once in the main text itself. There's no need to make such an assumption. I still think that the snippet I shared should have worked. Clearly `org-export-footnote-first-reference-p' is misbehaving. Using link-target within the footnotes should be fixed. Thank you. This could be a workaround. But it introduces the overhead of conjuring up a new link. Instead of sneaking a <<>> link right in to the text, another alternative would be to go with: #+NAME: test [fn:1] footdef1. Regards,
Re: [O] Citations, continued
Richard Lawrence writes:
> Hi Tom and all,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Richard Lawrence writes:
>>
>>> Conceptually, something like `@key:year' isn't a citation, but merely
>>> indirection, because it doesn't actually provide the reader of the
>>> rendered document enough information to look up the reference. I think
>>> we can cut down on the number of `citation' types that the syntax should
>>> support if we distinguish citations from indirection like this.
>>
>> I don't think this concept holds in the LaTeX world. I'm fairly certain
>> that citation commands like \citeauthor and \citeyear create an entry in
>> the bibliography.
>
> Fair enough. I just meant that something like
>
> "As the reader may verify, \citeyear{Doe99} fails to make any progress
> on this issue."
>
> doesn't render into a form that allows the reader to know which work is
> being talked about, even if that work appears in the bibliography; the
> author has to supply more context for it to make sense. Thus, \citeyear
> and friends are more of a convenience for the author than commands to
> produce a (complete) citation that the reader can use.
>
> But I don't really care so much about the right definition of "citation"
> as about the fact that supporting an equivalent for these commands in
> non-LaTeX backends strikes me as really hard, which makes me wonder if
> the effort required to support them is worth the convenience gained by
> representing them in the main citation syntax.
>
> It seems like it would be hard because providing equivalents for things
> like \citeauthor or \citetitle in, say, HTML would require the exporter
> to know a *lot* about how to format names and titles in the context
> where those citations appear. This is a very non-trivial problem.
>
> But perhaps the exporter could rely on an external CSL processor for
> things like this? I don't really know if CSL can handle this kind of
> `partial' citation -- if it can, and if CSL is part of the plan for
> exporting citations in non-LaTeX backends, then I have no real objection
> to representing them in the citation syntax, because they are indeed
> convenient.
>
> Best,
> Richard
Couldn't the syntax be extensible so it accommodates any citation
command?
Perhaps each backend could support an appropriate set of commands and
fallback to a default if the user tries an unsupported command?
If a LaTeX user wants all the citation commands for an html document,
there are converters such as tex4ht. Org mode doesn't need to reinvent
that wheel.
I expect that ox-latex will often need to support new citation commands
as the humanities continue to develop styles based on biblatex. Perhaps
we should view extensible syntax as "backend extensible" rather than
"user extensible"?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Citations, continued
Hi Tom and all,
t...@tsdye.com (Thomas S. Dye) writes:
> Richard Lawrence writes:
>
>> Conceptually, something like `@key:year' isn't a citation, but merely
>> indirection, because it doesn't actually provide the reader of the
>> rendered document enough information to look up the reference. I think
>> we can cut down on the number of `citation' types that the syntax should
>> support if we distinguish citations from indirection like this.
>
> I don't think this concept holds in the LaTeX world. I'm fairly certain
> that citation commands like \citeauthor and \citeyear create an entry in
> the bibliography.
Fair enough. I just meant that something like
"As the reader may verify, \citeyear{Doe99} fails to make any progress on this
issue."
doesn't render into a form that allows the reader to know which work is
being talked about, even if that work appears in the bibliography; the
author has to supply more context for it to make sense. Thus, \citeyear
and friends are more of a convenience for the author than commands to
produce a (complete) citation that the reader can use.
But I don't really care so much about the right definition of "citation"
as about the fact that supporting an equivalent for these commands in
non-LaTeX backends strikes me as really hard, which makes me wonder if
the effort required to support them is worth the convenience gained by
representing them in the main citation syntax.
It seems like it would be hard because providing equivalents for things
like \citeauthor or \citetitle in, say, HTML would require the exporter
to know a *lot* about how to format names and titles in the context
where those citations appear. This is a very non-trivial problem.
But perhaps the exporter could rely on an external CSL processor for
things like this? I don't really know if CSL can handle this kind of
`partial' citation -- if it can, and if CSL is part of the plan for
exporting citations in non-LaTeX backends, then I have no real objection
to representing them in the citation syntax, because they are indeed
convenient.
Best,
Richard
Re: [O] Citations, continued
Richard Lawrence writes: > Conceptually, something like `@key:year' isn't a citation, but merely > indirection, because it doesn't actually provide the reader of the > rendered document enough information to look up the reference. I think > we can cut down on the number of `citation' types that the syntax should > support if we distinguish citations from indirection like this. I don't think this concept holds in the LaTeX world. I'm fairly certain that citation commands like \citeauthor and \citeyear create an entry in the bibliography. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Citations, continued
Hi Stefan, Stefan Nobis writes: > Richard Lawrence writes: > >> Rasmus writes: > >>> Citation types for extracting parts: >>> citeauthor, citetitle, citeyear, citedate, citeurl, > >> As I've said in other posts, I think maybe we should not think of >> these as `citation' commands and thus don't need to represent them >> in citation syntax. Instead I suggest we give authors tools to >> insert this information into documents directly. > > This would render changes quite hard. Maybe I misspelled something in > the database or I choosed the wrong reference: With above part > extractors all I have to do at most is to replace the @key. But if > data is copied verbatim, I have to search for all years, author names, > titles, urls etc. Very error prone. That's true, and I realize that's a disadvantage. (Though I think these are errors that, for the most part, normal proof-reading will correct anyway.) I know these commands are convenient, and that not having them would introduce this class of errors, but the question is whether they are so important that it's worth providing an equivalent for them in non-LaTeX backends. For my part, it seems like the convenience is not worth the effort that would be required to make the exporter handle these correctly in general. (For example, it seems the exporter would then have to worry about things like quoting and emphasizing document titles -- which means worrying about context, document type, locale and language, quotation styles, etc.) But maybe I'm wrong; can you make the case that it is indeed worth it? Best, Richard
Re: [O] Raw .org file for manual(s)?
How about a raw compact guide. The complete guide won't really load into Emacs very well on my machine. On Tue, Feb 10, 2015 at 12:18 PM, Rasmus wrote: > Lawrence Bottorff writes: > > > What would the github link be? > > https://github.com/tsdye/orgmanual > > Tom frequents the list regularly if you want to know more about it. > > —Rasmus > > -- > Evidence suggests Snowden used a powerful tool called monospaced fonts > > >
[O] [patch, ox] suppress title
Hi,
Sometime when requiring custom formatting of the header for a document, it
would be nice to be able to use #+TITLE without triggering the insertion
of the tile (e.g. \maketitle in latex and title in ox-html). For
instance, one might have special org-html-preamble code. This patch adds
an "#+OPTIONS: title:{nil,t}" option.
Any objections?
Thanks,
Rasmus
--
If you can mix business and politics wonderful things can happen!
>From 94a3415fecb3976edc4fa3d4a5078a33774326ae Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Wed, 11 Feb 2015 00:09:39 +0100
Subject: [PATCH] ox: Optional export of title
* ox.el (org-export-with-title): New variable.
* ox (org-export-options-alist),
ox-ascii.el (org-ascii-template--document-title),
ox-beamer.el (org-beamer-template), ox-html.el (org-html-template),
ox-latex.el (org-latex-template), ox-man.el (org-man-template),
ox-odt.el (org-odt-template), ox-org.el (org-org-template),
ox-publish.el (org-publish-project-alist),
ox-texinfo.el (org-texinfo-template),
ox-groff.el (org-groff--mt-head): Use new variable.
* ox-koma-letter.el (org-koma-letter-use-title): Mark obsolete.
* test-ox.el (test-org-export/parse-option-keyword): Add :with-title.
This is useful in e.g. ox-html where title can be set via
`org-html-preamble-template' or when using the {{{title}}}-macro.
---
contrib/lisp/ox-groff.el | 4 +++-
contrib/lisp/ox-koma-letter.el | 14 +++---
lisp/ox-ascii.el | 4 +++-
lisp/ox-beamer.el | 3 ++-
lisp/ox-html.el| 7 ---
lisp/ox-latex.el | 3 ++-
lisp/ox-man.el | 3 ++-
lisp/ox-odt.el | 3 ++-
lisp/ox-org.el | 3 ++-
lisp/ox-publish.el | 3 ++-
lisp/ox-texinfo.el | 11 ++-
lisp/ox.el | 10 ++
testing/lisp/test-ox.el| 4 ++--
13 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/contrib/lisp/ox-groff.el b/contrib/lisp/ox-groff.el
index b618395..31b4e0f 100644
--- a/contrib/lisp/ox-groff.el
+++ b/contrib/lisp/ox-groff.el
@@ -563,7 +563,9 @@ See `org-groff-text-markup-alist' for details."
(t (format ".AF \"%s\" \n" (or org-groff-organization "")
;; 2. Title
- (let ((subtitle1 (plist-get attr :subtitle1))
+ (let ((title (if (plist-get info :with-title)
+ title ""))
+ (subtitle1 (plist-get attr :subtitle1))
(subtitle2 (plist-get attr :subtitle2)))
(cond
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index de40fe6..ed556a8 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -338,16 +338,6 @@ This option can also be set with the OPTIONS keyword, e.g.:
:group 'org-export-koma-letter
:type 'boolean)
-(defcustom org-koma-letter-use-title t
- "Non-nil means use a title in the letter if present.
-This option can also be set with the OPTIONS keyword,
-e.g. \"title:nil\".
-
-See also `org-koma-letter-prefer-subject' for the handling of
-title versus subject."
- :group 'org-export-koma-letter
- :type 'boolean)
-
(defcustom org-koma-letter-default-class "default-koma-letter"
"Default class for `org-koma-letter'.
The value must be a member of `org-latex-classes'."
@@ -383,6 +373,9 @@ was not present."
(defvar org-koma-letter-special-contents nil
"Holds special content temporarily.")
+(make-obsolete-variable 'org-koma-letter-use-title
+ 'Org-export-with-title
+ "25.1" 'set)
;;; Define Back-End
@@ -418,7 +411,6 @@ was not present."
(:with-phone nil "phone" org-koma-letter-use-phone)
(:with-place nil "place" org-koma-letter-use-place)
(:with-subject nil "subject" org-koma-letter-subject-format)
-(:with-title nil "title" org-koma-letter-use-title)
(:with-title-as-subject nil "title-subject" org-koma-letter-prefer-subject)
;; Special properties non-nil when a setting happened in buffer.
;; They are used to prioritize in-buffer settings over "lco"
diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index f7bc319..c4b34cb 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -969,7 +969,9 @@ INFO is a plist used as a communication channel."
;; Links in the title will not be resolved later, so we make
;; sure their path is located right after them.
(info (org-combine-plists info '(:ascii-links-to-notes nil)))
- (title (org-export-data (plist-get info :title) info))
+ (title (if (plist-get info :with-title)
+ (org-export-data (plist-get info :title) info)
+ ""))
(author (and (plist-get info :with-author)
(let ((auth (plist-get info :author)))
(and auth (org-export-data auth info)
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index f53b359..1d23746 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -877,7 +877,8 @@ holding export options."
"\\begin{document}\n\n"
;; 10. Title command.
(org-element-normalize-string
- (cond ((string=
Re: [O] Strange behavior with block agendas
Hello, Yuri Niyazov writes: If a block agenda exists, with say, agenda on top and todo on the bottom, then by default it opens to "today". It is possible then to press j and select a different date to go to. After that, if we hit "r" to redisplay, we get different behavior: - If the point is in the agenda section of the buffer, then the agenda is redisplayed with the date that was selected after hitting "j" - If the point is in the todo section of the buffer, then the agenda is redisplayed with today's date. Do you guys think this is correct behavior, or inconsistent behavior? >>> >>> Where is point when you are hitting 'j' in these cases? >> >> "j" is on the agenda. When I try to hit "j" on the todo list, I get a >> "Not allowed in todo-type agenda buffers" message, so that's not >> relevant. The same happens with "b"and "f" It looks like a minor inconsistency. "r" should probably keep last selected date. Would you want to provide a patch for that? Regards, -- Nicolas Goaziou
Re: [O] [bug] both ox-md and ox-man both occupy 'm'
Hello, Rasmus writes: > Check: > > (let ((org-export-dispatch-use-expert-ui nil)) > (mapc 'require '(ox-man ox-md)) > (org-export-dispatch)) > > I guess we could just move man to 'M'? Indeed. Thanks. Regards, -- Nicolas Goaziou
Re: [O] [patch] better(?) indention for cdlatex-environment
Hello,
Rasmus writes:
> Cdlatex environment inserted via org-cdlatex-environment-indent are pretty
> bad at getting the right indention. Consider:
>
> - concept :: a long description of concept |
>
> Where | is cursor. When I call org-cdlatex-environment-indent, I expect
>
> - concept :: a long description of concept
> \begin{equation}
> |
> \end{equation}
>
> But I get
>
> - concept :: a long description of concept
> \begin{equation}
> |
> \end{equation}
>
> This is because it determines the indention after the element is inserted
> at column zero. So the correct indention /is/ column zero but I wanted it
> to be part of the description. IOW I want Org to use the correct
> indention of when the time when I call the command.
>
> Note that I can still get an environment at column zero by issuing the
> command here:
>
> - concept :: a long description of concept
> |
>
> This patch just fixes this for org-cdlatex-indent-environment only, but
> maybe it's more correct to fix it in org-indent-region?
`org-indent-region' is right here, so I don't see what should be fixed
there.
You can get real indentation by indenting a new line first. What about
the following?
(defun org-cdlatex-environment-indent (&optional environment item)
(org-return-indent)
(beginning-of-line)
(let ((ind (org-get-indentation)))
(cdlatex-environment environment item)
(save-excursion (forward-line -1) (org-indent-to-column ind))
(save-excursion (forward-line 1) (org-indent-to-column ind))
(org-indent-to-column ind)))
Regards,
--
Nicolas Goaziou
[O] [bug] both ox-md and ox-man both occupy 'm'
Hi, Check: (let ((org-export-dispatch-use-expert-ui nil)) (mapc 'require '(ox-man ox-md)) (org-export-dispatch)) I guess we could just move man to 'M'? –Rasmus -- Governments should be afraid of their people
Re: [O] [PATCH]: BUG fix and Add header-args property to source block info
Nicolas Goaziou writes: > Hello, > > Rainer M Krug writes: > >> Please find attached the below described patch including the fix for the >> error reported - function raises error when property value is numeric. > > Looks good. Thank you. Thanks. >From 6461f4de49fbcd002913a58ac5b47453e965ac0d Mon Sep 17 00:00:00 2001 From: "Rainer M. Krug" Date: Tue, 10 Feb 2015 09:32:46 +0100 Subject: [PATCH] ob-core.el: Fix numeric error and add header-args * lisp/ob-core.el (org-babel-view-src-block-info): when a property value was numeric, an error was raised. Fixed by converting property value to string before evauation. * lisp/ob-core.el (org-babel-view-src-block-info): Add property string "header args" to output of org-babel-view-src-block-info to make debugging of header-args setting problems easier. * lisp/ob-core.el (org-babel-view-src-block-info): Add property string for language specific "header args:LANG" to output of org-babel-view-src-block-info to make debugging of header-args setting problems easier. --- lisp/ob-core.el | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index ceda1aa..aa39c11 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -409,12 +409,16 @@ a window into the `org-babel-get-src-block-info' function." (header-args (nth 2 info))) (when name(funcall printf "Name: %s\n" name)) (when lang(funcall printf "Lang: %s\n" lang)) + (funcall printf "Properties:\n") + (funcall printf "\t:header-args \t%s\n" (org-entry-get (point) "header-args" t)) + (funcall printf "\t:header-args:%s \t%s\n" lang (org-entry-get (point) (concat "header-args:" lang) t)) + (when (funcall full switches) (funcall printf "Switches: %s\n" switches)) (funcall printf "Header Arguments:\n") (dolist (pair (sort header-args (lambda (a b) (string< (symbol-name (car a)) (symbol-name (car b)) - (when (funcall full (cdr pair)) + (when (funcall full (format "%s" (cdr pair))) (funcall printf "\t%S%s\t%s\n" (car pair) (if (> (length (format "%S" (car pair))) 7) "" "\t") -- 2.3.0 > Could you provide an appropriate commit message? Here is the patch attached with the commit message - hope it is OK. > Bonus points if you also add a test. Are there some guidelines on how to write tests? Never done this before... Rainer > > Regards, -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [PATCH]: BUG fix and Add header-args property to source block info
Hello, Rainer M Krug writes: > Please find attached the below described patch including the fix for the > error reported - function raises error when property value is numeric. Looks good. Thank you. Could you provide an appropriate commit message? Bonus points if you also add a test. Regards, -- Nicolas Goaziou
Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'
Hello, Vaidheeswaran C writes: > That said, it is difficult for me to conceive of a footnote that is > referenced solely by other footnotes. i.e., it is reasonable to assume > that a given footnote is either not referenced at all or is referenced > atleast once in the main text itself. There's no need to make such an assumption. Using link-target within the footnotes should be fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'
Hello, Christian Moe writes: > An ODT cross-reference to the footnote? That makes sense, but should > that be achieved by footnoting inside a footnote, or is the appropriate > thing to do to use a dedicated target and link? > > [fn:1] footdef1, see also [[thatotherfootnote]]. > > [fn:2] <>footdef2 > > That seems to works nicely e.g. in HTML export. > > But I get an error message when I try it in ODT export (OpenDocument > export failed: number-or-marker-p, nil -- can't be more detailed at the > moment because my debugger doesn't seem to work correctly). This should be fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH]: Add header-args property to source block info
"Charles C. Berry" writes: > On Tue, 10 Feb 2015, Rainer M Krug wrote: > >> Hi >> >> Following a recent discussion (based on me forgetting a ":" when setting >> the property :header-args), I added the output of the property >> header-args to the output of org-babel-get-src-block-info to make >> debugging easier. > [snip] >> >> Using the patched version, one gets the following: >> >> , >> | Lang: R >> | Properties: >> |:header-args:exports both :results output exports code >> |:header-args:R :session somename >> | Header Arguments: >> |:cache no >> |:exportsboth >> |:hlines no >> |:noweb no >> |:resultscode exports output replace >> |:sessionsomename >> |:tangle no >> ` >> > > This is handy! > > Just a thought: > > Perhaps allow an `(interactive "P)' type `arg' to determine whether to > present the properties? > > i.e. C-u C-c C-v C-i reveals both Properties: and Header Arguments:, while > C-c C-v C-i just the latter. Apart from having no idea how I can do this, I think it would add just another layer of complexity which is actually not needed as this is just an information to be assessed visually and not to be parsed by some code - so I do not assume there are any backward compatibility issues. Also, as the information presented is only relative small (20 lines max?) it is still quite easy to see the original information. If the patch would strip away information or add a huge amount of it, I would completely agree with your suggestion, but as it stands, I see no harm in leaving it as it is in the patch. Cheers, Rainer > > Best, > > Chuck > > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] closing column mode for beamer export
Hi,
Thanks for the suggestion.
I tried making the columns bigger "BEAMER_col: 0.8 or whatever
Didn't work.
I tried making the image bigger (but maybe org doesn't see that)
I don't have any other ideas on how to do this. Maybe because I have no
text in the slide?
Larrabee
--
L. Larrabee Strow
UMBC Physics Department
Email: st...@umbc.edu
Office: 724-663-7341
Google Voice: 724-663-1441 (best for messages)
Cell: 724-288-6933 (usually OFF)
On Tue, Feb 10, 2015 at 1:02 PM, Eric S Fraga wrote:
> On Tuesday, 10 Feb 2015 at 15:42, Larrabee Strow wrote:
> > I am trying to put a second row of two columns in a org beamer slide.
> >
> > No problems with doing the first row, two column.
> >
> > I can't figure out any way to put in the second row of two columns.
> > (I am trying to show a 2x2 grid of images, with titles.)
> >
> > It appears to me I need something that produces and \end{columns}
> > after my first row of columns.
>
> I don't think you need to do anything complicated.
>
> I have found that individual columns will go to the next "row" of
> columns if the running total of the widths is greater than the page
> width (\textwidth). So basically if the first two columns take up most
> of the width, the next column you start will go below. Try it and
> see. It works for me.
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
> release_8.3beta-798-g528b90
>
Re: [O] closing column mode for beamer export
On Tuesday, 10 Feb 2015 at 15:42, Larrabee Strow wrote:
> I am trying to put a second row of two columns in a org beamer slide.
>
> No problems with doing the first row, two column.
>
> I can't figure out any way to put in the second row of two columns.
> (I am trying to show a 2x2 grid of images, with titles.)
>
> It appears to me I need something that produces and \end{columns}
> after my first row of columns.
I don't think you need to do anything complicated.
I have found that individual columns will go to the next "row" of
columns if the running total of the widths is greater than the page
width (\textwidth). So basically if the first two columns take up most
of the width, the next column you start will go below. Try it and
see. It works for me.
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-798-g528b90
Re: [O] [PATCH]: Add header-args property to source block info
On Tue, 10 Feb 2015, Rainer M Krug wrote: Hi Following a recent discussion (based on me forgetting a ":" when setting the property :header-args), I added the output of the property header-args to the output of org-babel-get-src-block-info to make debugging easier. [snip] Using the patched version, one gets the following: , | Lang: R | Properties: | :header-args:exports both :results output exports code | :header-args:R :session somename | Header Arguments: | :cache no | :exportsboth | :hlines no | :noweb no | :resultscode exports output replace | :sessionsomename | :tangle no ` This is handy! Just a thought: Perhaps allow an `(interactive "P)' type `arg' to determine whether to present the properties? i.e. C-u C-c C-v C-i reveals both Properties: and Header Arguments:, while C-c C-v C-i just the latter. Best, Chuck
Re: [O] Raw .org file for manual(s)?
Lawrence Bottorff writes: > What would the github link be? https://github.com/tsdye/orgmanual Tom frequents the list regularly if you want to know more about it. —Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
Re: [O] Raw .org file for manual(s)?
What would the github link be? On Tue, Feb 10, 2015 at 12:06 PM, Rasmus wrote: > Lawrence Bottorff writes: > > > I'd like a copy of the documentation (short, long manuals) in their > > original .org format. Where can I find them? My first logical guess was > to > > get the org distribution. But /doc/ doesn't seem to have them as .org > files. > > It's in texi. E.g. doc/org.texi. There's a dated version of the > org-manual written in Org on github. > > -- > Lasciate ogni speranza, voi che leggete questo. > > >
Re: [O] Raw .org file for manual(s)?
Lawrence Bottorff writes: > I'd like a copy of the documentation (short, long manuals) in their > original .org format. Where can I find them? My first logical guess was to > get the org distribution. But /doc/ doesn't seem to have them as .org files. It's in texi. E.g. doc/org.texi. There's a dated version of the org-manual written in Org on github. -- Lasciate ogni speranza, voi che leggete questo.
[O] Raw .org file for manual(s)?
I'd like a copy of the documentation (short, long manuals) in their original .org format. Where can I find them? My first logical guess was to get the org distribution. But /doc/ doesn't seem to have them as .org files. LB
Re: [O] Citations, continued
Richard Lawrence writes: > Rasmus writes: >> Citation types for extracting parts: >> citeauthor, citetitle, citeyear, citedate, citeurl, > As I've said in other posts, I think maybe we should not think of > these as `citation' commands and thus don't need to represent them > in citation syntax. Instead I suggest we give authors tools to > insert this information into documents directly. This would render changes quite hard. Maybe I misspelled something in the database or I choosed the wrong reference: With above part extractors all I have to do at most is to replace the @key. But if data is copied verbatim, I have to search for all years, author names, titles, urls etc. Very error prone. I think, even citeauthor or citeurl are citations. A normal "\cite" command is nothing else than a short reference to all the detail data in the bibliography. And sometimes context allows to make these references even shorter, by only using the author name or a year etc. I don't really see the distinction between citation and indirection - each citation is as much an indirection as e.g. citeyear is. -- Until the next mail..., Stefan.
Re: [O] bug - active and inactive time stamps incorrect year for current date and rest of month
Hello, Charles Millar writes: > When I call either active or inactive timestamps and enter the current > date from the keyboard, i.e. 2/10, rather than simply pressing enter > the result is <2016-02-10 Wed> or [2016-02-10 Wed], i.e. the year is > already advanced. If I enter any date in the rest of the month in same > manner such as 2/28 same result, <2016-02-28 Sun> or [2016-02-28 Sun] > the year and day of the week are advanced. The behavior disappears > when I go to the next month. This should be fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Citations, continued
Rasmus writes: > So, the (opinionated) useful defaults in biblatex are: > cite(s), parencite(s), footcite(s), texcite(s), fullcite, > footfullcite, nocite So that is to say we need to be able to express the following distinctions (did I miss anything?): - in-text vs. parenthetical (parencite vs. textcite) - normal citation vs. multi-cite citation with common pre and post notes (-s variants) - producing a full bibliography entry, or not (-full- variants) - footnoted, or not (foot- variants) - producing output, or not (nocite) I am not sure about that the last two need to be represented in citation syntax itself. Do we need a separate way of indicating that a citation should appear in a footnote? Org already has footnote syntax...can't authors just put citations in an Org footnote? As for nocites, I liked your earlier suggestion that we have a #+NOCITE keyword (which could be specified multiple times). So I am not sure this needs to be in citation syntax proper, either. > Citation types for extracting parts: > citeauthor, citetitle, citeyear, citedate, citeurl, As I've said in other posts, I think maybe we should not think of these as `citation' commands and thus don't need to represent them in citation syntax. Instead I suggest we give authors tools to insert this information into documents directly. Best, Richard
Re: [O] Citations, continued
>
> Ok, sorry I didn't check the natbib manual carefully. AFAIK you get
> numbers with biblatex without any author-year options so:
>
> \cite{k}, \parencite{k} → [Num]
> \textcite{k} → A [Num]
>
> Is this similar to \numcite? From natbib is seems to be intended for
> people who use author-year, but still wants numbers. Is that correct?
I don't think so. It is just the number that the citation has in the
bibliography, not in brackets or parens, and usually not
superscripted. We use it to get something like this in the exported
document:
"This is seen in Ref. 9"
With the other commands you get something like:
"This is seen in Ref. [9]"
or if you have a superscripted style:
"This is seen in Ref. ^9"
>
> —Rasmus
--
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] Citations, continued
Hi Nicolas and all, Nicolas Goaziou writes: > If year, or author, are needed, I suggested to append some optional > parameter to the key, e.g., > > [cite: pre @key:year post] I proposed exactly this earlier in the thread, but then I came to the conclusion that we shouldn't do it. Conceptually, something like `@key:year' isn't a citation, but merely indirection, because it doesn't actually provide the reader of the rendered document enough information to look up the reference. I think we can cut down on the number of `citation' types that the syntax should support if we distinguish citations from indirection like this. Practically speaking, I think this would also be too hard to implement correctly. Once you can say things like "@key:title", you have to worry about how this will be formatted in the exported document (in quotes? italics? etc.), and it's just not clear how to do that in general. Instead, I suggest that Org supports this kind of indirection via other means, perhaps by providing functions to look up the required data and insert it directly into the text, where the author can format it as desired. So I would suggest that we *don't* try to capture what LaTeX does with \citeyear, \citeauthor, etc. in the citation syntax. Best, Richard
[O] Org-mode and YASnippet
Hello, does anyone use YASnippet with Org? I tried, but ran into a strange problem: when I type into a placeholder field, I get a space after each letter. Did anyone run into this, too? TIA, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Citations, continued
John Kitchin writes:
> Rasmus writes:
>
>> Nicolas Goaziou writes:
>>
>>> Another option is to mimic custom links, if that's what you're thinking
>>> of, which means to store every user-defined keyword in a variable and
>>> build a regexp out of it. I dislike it even more because the document is
>>> not portable anymore, as it requires you to share your custom keywords.
>>
>> So, the (opinionated) useful defaults in biblatex are:
>> cite(s), parencite(s), footcite(s), texcite(s), fullcite,
>> footfullcite, nocite
>>
>> Citation types for extracting parts:
>> citeauthor, citetitle, citeyear, citedate, citeurl,
>
> If citenum was also in that list, then I agree. It is not that likely
> there is little need for custom style.
Ok, sorry I didn't check the natbib manual carefully. AFAIK you get
numbers with biblatex without any author-year options so:
\cite{k}, \parencite{k} → [Num]
\textcite{k} → A [Num]
Is this similar to \numcite? From natbib is seems to be intended for
people who use author-year, but still wants numbers. Is that correct?
—Rasmus
--
Vote for proprietary math!
[O] closing column mode for beamer export
I am trying to put a second row of two columns in a org beamer slide.
No problems with doing the first row, two column.
I can't figure out any way to put in the second row of two columns.
(I am trying to show a 2x2 grid of images, with titles.)
It appears to me I need something that produces and \end{columns}
after my first row of columns.
I have seen in the maillist and manual statement about using
ignoreheading property, but nothing I tried worked, I am sure I just
don't understand the instructions on this. What I want is below, but
I need something after the first row that starts a new column
***
:PROPERTIES:
:BEAMER_col: 0.5
:END:
\centering L2 Bias
#+ATTR_LaTeX: :width \linewidth
[[./g039__bias_z1.pdf]]
***
:PROPERTIES:
:BEAMER_col: 0.5
:END:
\centering L2 Std.
#+ATTR_LaTeX: :width \linewidth
[[./g039__std_z1.pdf]]
**HERE a need equivalent to a carriage return/line feed
***
:PROPERTIES:
:BEAMER_col: 0.5
:END:
\centering L2 Bias Row Number 2
#+ATTR_LaTeX: :width \linewidth
[[./g039__bias_z1_v2.pdf]]
***
:PROPERTIES:
:BEAMER_col: 0.5
:END:
\centering L2 Std. Row Number 2
#+ATTR_LaTeX: :width \linewidth
[[./g039__std_z1_v2.pdf]]
Thanks.
Re: [O] Citations, continued
Nicolas Goaziou writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Yes, I typically use what I call a multicite to get multiple citations
>> with biblatex. It just inserts {key}. I precede two or more of these
>> with a placeholder--π for parencites, † for textcites, or ƒ for
>> footcites--and then use a filter to insert \parencites, etc. This is
>> crude, and wouldn't work in a more general setting, but it serves for
>> the work I do.
>
> If you write something like
>
> [cite: pre1 @k1 post1; pre2 @k2 post2]
>
> wouldn't it possible to guess you want to use multicite? IOW, does using
> "multicite" really implies a change in the syntax?
>
>
> Regards,
Yes, but it doesn't capture the citation command, AFAICT.
Something like
[cite: pre1 @k1 post1; pre2 @k2 post2 :command paren|text|foot]
would do.
All the best,
Tom
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] Citations, continued
Rasmus writes: > Nicolas Goaziou writes: > >> Another option is to mimic custom links, if that's what you're thinking >> of, which means to store every user-defined keyword in a variable and >> build a regexp out of it. I dislike it even more because the document is >> not portable anymore, as it requires you to share your custom keywords. > > So, the (opinionated) useful defaults in biblatex are: > cite(s), parencite(s), footcite(s), texcite(s), fullcite, > footfullcite, nocite > > Citation types for extracting parts: > citeauthor, citetitle, citeyear, citedate, citeurl, If citenum was also in that list, then I agree. It is not that likely there is little need for custom style. > > From natbib: > citet (== textcite), citep (== parencite). > > Keys I don't care about, since they are quite biblatex specific: > smartcite, autocide, parentcite*, uppercase variants. *volcites(s) > (any objections?) None from me. > > In natbib: >citealt, citalp, starred variants > > So that's 17 support keys and two aliases. I guess this would deter most > authors from needing custom styles. > >> Note that it rules out colons from KEY syntax (but we can use another >> less common character, e.g. "|"). > > The default bibtex.el style generates keys like "%A%y:%t", so I think ":" > is no good, appealing as it is. > > —Rasmus > > > Footnotes: > ¹ which is just > [cite: common pre; pre1 @k1 post1; ⋯; preN @kN postN; common post] -- 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] ODT export: Issues with `org-export-footnote-first-reference-p'
On Tuesday 10 February 2015 06:26 PM, Christian Moe wrote: Thanks for this. You have [fn:1] footdef1[fn:2] [fn:2] footdef2 What do you expect to see in ODT? Presumably not a footnote in a footnote, since LibreOffice doesn't allow you to place one. An ODT cross-reference to the footnote? That makes sense, Yes. but should that be achieved by footnoting inside a footnote Yes, just like that in the snippet. That said, it is difficult for me to conceive of a footnote that is referenced solely by other footnotes. i.e., it is reasonable to assume that a given footnote is either not referenced at all or is referenced atleast once in the main text itself.
Re: [O] [PATCH]: BUG fix and Add header-args property to source block info
Please find attached the below described patch including the fix for the error reported - function raises error when property value is numeric. Cheers, Rainer diff --git a/lisp/ob-core.el b/lisp/ob-core.el index ceda1aa..aa39c11 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -409,12 +409,16 @@ a window into the `org-babel-get-src-block-info' function." (header-args (nth 2 info))) (when name(funcall printf "Name: %s\n" name)) (when lang(funcall printf "Lang: %s\n" lang)) + (funcall printf "Properties:\n") + (funcall printf "\t:header-args \t%s\n" (org-entry-get (point) "header-args" t)) + (funcall printf "\t:header-args:%s \t%s\n" lang (org-entry-get (point) (concat "header-args:" lang) t)) + (when (funcall full switches) (funcall printf "Switches: %s\n" switches)) (funcall printf "Header Arguments:\n") (dolist (pair (sort header-args (lambda (a b) (string< (symbol-name (car a)) (symbol-name (car b)) - (when (funcall full (cdr pair)) + (when (funcall full (format "%s" (cdr pair))) (funcall printf "\t%S%s\t%s\n" (car pair) (if (> (length (format "%S" (car pair))) 7) "" "\t") Rainer M Krug writes: > Hi > > Following a recent discussion (based on me forgetting a ":" when setting > the property :header-args), I added the output of the property > header-args to the output of org-babel-get-src-block-info to make > debugging easier. Before the function resulted in the following output > (using my faulty code block): > > , > | Lang: R > | Header Arguments: > | :cache no > | :exportsboth > | :hlines no > | :noweb no > | :resultscode exports output replace > | :sessionsomename > | :tangle no > | > ` > > One only saw that the property :results was not correct but not where it > came from. > > Using the patched version, one gets the following: > > , > | Lang: R > | Properties: > | :header-args:exports both :results output exports code > | :header-args:R :session somename > | Header Arguments: > | :cache no > | :exportsboth > | :hlines no > | :noweb no > | :resultscode exports output replace > | :sessionsomename > | :tangle no > ` > > Here one can clearly see that the property :header-args is not set > correctly and can easily trace it down in the original org file. > > Also, actually seeing the property :header-args makes it easier to > understand the whole inheritance of header arguments and how header-args > and header-args+ interact. > > The same applir=es to the property :header-args:R (or any language > specific header-args:language property) > > Cheers, > > Rainer > > > Here is again the faulty org file which lead to the patch: > > #+PROPERTY: header-args:R :session somename > #+PROPERTY: header-args :exports both > #+PROPERTY: header-args+ :results output > * The bug > This file create an (possibly endless?) loop during export > * here exports both > #+begin_src R > cat(13+14) > #+end_src > > * and here only code > :PROPERTIES: > :header-args+: exports code > :END: > #+begin_src R > paste(13+14) > #+end_src > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index ceda1aa..94a07f6 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -409,6 +409,10 @@ a window into the `org-babel-get-src-block-info' > function." > (header-args (nth 2 info))) > (when name(funcall printf "Name: %s\n" name)) > (when lang(funcall printf "Lang: %s\n" lang)) > + (funcall printf "Properties:\n") > + (funcall printf "\t:header-args \t%s\n" (org-entry-get (point) > "header-args" t)) > + (funcall printf "\t:header-args:%s \t%s\n" lang (org-entry-get > (point) (concat "header-args:" lang) t)) > + > (when (funcall full switches) (funcall printf "Switches: %s\n" > switches)) > (funcall printf "Header Arguments:\n") > (dolist (pair (sort header-args -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
[O] bug - active and inactive time stamps incorrect year for current date and rest of month
When I call either active or inactive timestamps and enter the current date from the keyboard, i.e. 2/10, rather than simply pressing enter the result is <2016-02-10 Wed> or [2016-02-10 Wed], i.e. the year is already advanced. If I enter any date in the rest of the month in same manner such as 2/28 same result, <2016-02-28 Sun> or [2016-02-28 Sun] the year and day of the week are advanced. The behavior disappears when I go to the next month. GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5) of 2014-12-19 on brahms, modified by Debian Org-mode version 8.3beta (release_8.3beta-806-g0be849 @ /usr/share/emacs/site-lisp/org-mode/lisp/) Is it intended that only the shift + arrow keys be used during the current month? Charlie Millar
[O] [FIXED] Re: [BUG] in org-babel-get-src-block-info when certain :header-args are set
Update: The problem occurs whenever a property value is a number. so , | #+PROPERTY: header-args :tangle-mode 292 ` also produces the error. Fix included in other patch. Rainer Rainer M Krug writes: > Rasmus writes: > >> Rainer M Krug writes: >> >>> #+PROPERTY: header-args :tangle-mode (identity #o444) >>> >>> * Initial plottings >>> #+begin_src R >>> plot(1) >>> #+end_src >>> >>> When calling org-babel-view-src-block-info (C-c C-v C-i) on the code >>> block above, I get the error below. >>> >>> I don't have the slightest clue what this means or how it can be fixed, >>> but it caused by the call to (identity #o444). >> >> Is #o444 significant to you? > > Well - it is more or less straight out of the org manual: > > , > | 14.8.2.24 `:tangle-mode' > | > | > | The `tangle-mode' header argument controls the permission set on tangled > | files. The value of this header argument will be passed to > | `set-file-modes'. For example, to set a tangled file as read only use > | `:tangle-mode (identity #o444)', or to set a tangled file as executable > | use `:tangle-mode (identity #o755)'. Blocks with `shebang' (*Note > | shebang::) header arguments will automatically be made executable unless > | the `tangle-mode' header argument is also used. The behavior is > | undefined if multiple code blocks with different values for the > | `tangle-mode' header argument are tangled to the same file. > | > ` > > I don't know if I could use anything else. > >> >> I guess you could use, or maybe a lambda that combines #o444 whatever it >> means with your src. I have no clue what #o444 means or :tangle-mode and >> I never heard of org-babel-view-src-block-info so take it with a grain of >> salt. > > org-babel-view-src-block-info : Bound to C-c C-v C-i by default (?). > > , > | Display information on the current source block. > | This includes header arguments, language and name, and is largely > | a window into the `org-babel-get-src-block-info' function. > ` > > Very useful as I have found out recently. > >> >> #+PROPERTY: header-args :tangle-mode (lambda (src) (identity src)) >> >> * Initial plottings >> #+begin_src R >> plot(1) >> #+end_src >> >> Or >> >> #+PROPERTY: header-args :tangle-mode identity src >> >> * Initial plottings >> #+begin_src R >> plot(1) >> #+end_src -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
[O] And another useful function for header arguments
I just found the following function: , | C-c C-v C-c runs the command org-babel-check-src-block, which is an | interactive autoloaded compiled Lisp function in `ob-core.el'. | | It is bound to C-c C-v c, C-c C-v C-c. | | (org-babel-check-src-block) | | Check for misspelled header arguments in the current code block. ` I'm gonna use it a lot! Cheers, Rainer -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] timeline view - showing times
Marcin Borkowski writes: > On 2015-02-09, at 18:43, Paul Rudin wrote: > >> If I type "C-c a L" I get a list of durations for each day - for example: >> >> Monday 9 February 2015 W07 >> Clocked: (0:53) Revise document X >> Clocked: (1:12) Meet Fred >> ... > > Wow. I don't get this behavior, though I'd like to. Is this the default? > I think so, although conceivably I have some customisation that's changed things from the default. What do you see if you select timeline from the agenda commands?
Re: [O] timeline view - showing times
Subhan Michael Tindall writes:
> This is probably overkill, but I use this:
> (setq org-agenda-custom-commands (quote (
> ("c" "Clock" ((agenda ""
> ((org-agenda-sticky nil)
>
> (org-agenda-ndays 1)
>
> (org-agenda-span-1)
>
> (org-agenda-use-time-grid t)
>
> (org-agenda-show-log (quote clockcheck))
>
> (org-agenda-clockreport nil
> This gives me a handy dandy report like this:
That's great, thanks. Just what I need.
I took the time grid bit out, as I find it a bit confusing that the grid
lines for times that happen during an activity line comes after the end
of the activity. I suppose changing that would involve splitting a
contiguous activity at the grid lines.
Re: [O] ODT export: Issues with `org-export-footnote-first-reference-p'
Hi, Thanks for this. You have [fn:1] footdef1[fn:2] [fn:2] footdef2 What do you expect to see in ODT? Presumably not a footnote in a footnote, since LibreOffice doesn't allow you to place one. An ODT cross-reference to the footnote? That makes sense, but should that be achieved by footnoting inside a footnote, or is the appropriate thing to do to use a dedicated target and link? [fn:1] footdef1, see also [[thatotherfootnote]]. [fn:2] <>footdef2 That seems to works nicely e.g. in HTML export. But I get an error message when I try it in ODT export (OpenDocument export failed: number-or-marker-p, nil -- can't be more detailed at the moment because my debugger doesn't seem to work correctly). So either way, there seems to be something that needs fixing. Yours, Christian Vaidheeswaran writes: > The attached file, when exported to ODT fails to open in LibreOffice > exporter. The reason failure is that the exported __XML__ file has > "nested footnote definiton" i.e., a footnote definition within a > footnote definiton. In concrete terms, there is some confusion wrt > the return value of `org-export-footnote-first-reference-p'. > > (Hint: Start with `org-odt-footnote-reference'. If my hunch is right, > the `org-export-data' invocation there may also need a fix). > > I will be happy to circulate a patch to ox-odt.el.
Re: [O] [patch] better(?) indention for cdlatex-environment
Rasmus writes:
> Hi,
>
> Cdlatex environment inserted via org-cdlatex-environment-indent are pretty
> bad at getting the right indention. Consider:
>
> - concept :: a long description of concept |
>
> Where | is cursor. When I call org-cdlatex-environment-indent, I expect
>
> - concept :: a long description of concept
> \begin{equation}
> |
> \end{equation}
Actually, this doesn't work with a one-line description since
(org-get-indent) is then zero there. I think a more complicated solution
is necessary. Maybe org-indent-region could take an optional argument of
previous indention, though that still doesn't solve the one-line
description case...
—Rasmus
--
One thing that is clear: it's all down hill from here
Re: [O] [BUG] in org-babel-get-src-block-info when certain :header-args are set
Rasmus writes: > Rainer M Krug writes: > >> #+PROPERTY: header-args :tangle-mode (identity #o444) >> >> * Initial plottings >> #+begin_src R >> plot(1) >> #+end_src >> >> When calling org-babel-view-src-block-info (C-c C-v C-i) on the code >> block above, I get the error below. >> >> I don't have the slightest clue what this means or how it can be fixed, >> but it caused by the call to (identity #o444). > > Is #o444 significant to you? Well - it is more or less straight out of the org manual: , | 14.8.2.24 `:tangle-mode' | | | The `tangle-mode' header argument controls the permission set on tangled | files. The value of this header argument will be passed to | `set-file-modes'. For example, to set a tangled file as read only use | `:tangle-mode (identity #o444)', or to set a tangled file as executable | use `:tangle-mode (identity #o755)'. Blocks with `shebang' (*Note | shebang::) header arguments will automatically be made executable unless | the `tangle-mode' header argument is also used. The behavior is | undefined if multiple code blocks with different values for the | `tangle-mode' header argument are tangled to the same file. | ` I don't know if I could use anything else. > > I guess you could use, or maybe a lambda that combines #o444 whatever it > means with your src. I have no clue what #o444 means or :tangle-mode and > I never heard of org-babel-view-src-block-info so take it with a grain of > salt. org-babel-view-src-block-info : Bound to C-c C-v C-i by default (?). , | Display information on the current source block. | This includes header arguments, language and name, and is largely | a window into the `org-babel-get-src-block-info' function. ` Very useful as I have found out recently. > > #+PROPERTY: header-args :tangle-mode (lambda (src) (identity src)) > > * Initial plottings > #+begin_src R > plot(1) > #+end_src > > Or > > #+PROPERTY: header-args :tangle-mode identity src > > * Initial plottings > #+begin_src R > plot(1) > #+end_src -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [BUG] in org-babel-get-src-block-info when certain :header-args are set
Rainer M Krug writes: > #+PROPERTY: header-args :tangle-mode (identity #o444) > > * Initial plottings > #+begin_src R > plot(1) > #+end_src > > When calling org-babel-view-src-block-info (C-c C-v C-i) on the code > block above, I get the error below. > > I don't have the slightest clue what this means or how it can be fixed, > but it caused by the call to (identity #o444). Is #o444 significant to you? I guess you could use, or maybe a lambda that combines #o444 whatever it means with your src. I have no clue what #o444 means or :tangle-mode and I never heard of org-babel-view-src-block-info so take it with a grain of salt. #+PROPERTY: header-args :tangle-mode (lambda (src) (identity src)) * Initial plottings #+begin_src R plot(1) #+end_src Or #+PROPERTY: header-args :tangle-mode identity src * Initial plottings #+begin_src R plot(1) #+end_src -- . . . The proofs are technical in nature and provides no real understanding
[O] [patch] better(?) indention for cdlatex-environment
Hi,
Cdlatex environment inserted via org-cdlatex-environment-indent are pretty
bad at getting the right indention. Consider:
- concept :: a long description of concept |
Where | is cursor. When I call org-cdlatex-environment-indent, I expect
- concept :: a long description of concept
\begin{equation}
|
\end{equation}
But I get
- concept :: a long description of concept
\begin{equation}
|
\end{equation}
This is because it determines the indention after the element is inserted
at column zero. So the correct indention /is/ column zero but I wanted it
to be part of the description. IOW I want Org to use the correct
indention of when the time when I call the command.
Note that I can still get an environment at column zero by issuing the
command here:
- concept :: a long description of concept
|
This patch just fixes this for org-cdlatex-indent-environment only, but
maybe it's more correct to fix it in org-indent-region?
—Rasmus
--
. . . It begins of course with The Internet. A Net of Peers
>From 1a61c446fa1c92df9ba28a68d13188c296b8b718 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 | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 9bc67a8..e0a8842 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18647,10 +18647,24 @@ Revert to the normal definition outside of these fragments."
(defun org-cdlatex-environment-indent (&optional environment item)
"Execute `cdlatex-environment' and indent the inserted environment."
(interactive)
- (cdlatex-environment environment item)
- (let ((element (org-element-at-point)))
-(org-indent-region (org-element-property :begin element)
- (org-element-property :end element
+ (let* ((ind (org-get-indentation))
+ (ind-str (make-string ind ? )))
+(cdlatex-environment environment item)
+(let* ((element (org-element-at-point))
+ (beg (org-element-property :begin element))
+ (end (org-element-property :end element)))
+ ;; Make a rough estimate of the indention. We do this to
+ ;; because `org-indent-region' will always guess column zero,
+ ;; when dealing with e.g. description items.
+ (save-excursion
+ ;; Walk backwards. Otherwise we'd need markers.
+ (goto-char end)
+ (beginning-of-line)
+ (while (>= (point) beg)
+ (insert ind-str)
+ (forward-line -1)))
+ ;; indent cursor
+ (forward-char ind
LaTeX fragments
--
2.3.0
[O] ODT export: Issues with `org-export-footnote-first-reference-p'
The attached file, when exported to ODT fails to open in LibreOffice exporter. The reason failure is that the exported __XML__ file has "nested footnote definiton" i.e., a footnote definition within a footnote definiton. In concrete terms, there is some confusion wrt the return value of `org-export-footnote-first-reference-p'. (Hint: Start with `org-odt-footnote-reference'. If my hunch is right, the `org-export-data' invocation there may also need a fix). I will be happy to circulate a patch to ox-odt.el. text1 [fn:1] #+BEGIN_QUOTE text2 [fn:2] #+END_QUOTE [fn:1] footdef1.[fn:2] [fn:2] footdef2 test.odt Description: application/vnd.oasis.opendocument.text
[O] [BUG] in org-babel-get-src-block-info when certain :header-args are set
Hi --8<---cut here---start->8--- #+PROPERTY: header-args :tangle-mode (identity #o444) * Initial plottings #+begin_src R plot(1) #+end_src --8<---cut here---end--->8--- When calling org-babel-view-src-block-info (C-c C-v C-i) on the code block above, I get the error below. I don't have the slightest clue what this means or how it can be fixed, but it caused by the call to (identity #o444). , | Debugger entered--Lisp error: (wrong-type-argument sequencep 292) | #[(it) "G\301V\207" [it 0] 2](292) | org-babel-view-src-block-info() | call-interactively(org-babel-view-src-block-info nil nil) | command-execute(org-babel-view-src-block-info) | Debugger entered--Lisp error: (wrong-type-argument sequencep 292) | #[(it) "G\301V\207" [it 0] 2](292) | org-babel-view-src-block-info() | call-interactively(org-babel-view-src-block-info nil nil) | command-execute(org-babel-view-src-block-info) ` , | Org-mode version 8.3beta (release_8.3beta-798-g528b90 @/Users/rainerkrug/.emacs.d/org-mode/lisp/) | GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local ` reproduced without configuration. Cheers, Rainer -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Citations, continued
Hi, Nicolas Goaziou writes: > Rasmus writes: > >> So, the (opinionated) useful defaults in biblatex are: >> cite(s), parencite(s), footcite(s), texcite(s), fullcite, >> footfullcite, nocite > > Isn't footcite/footfullcite a choice made at the document's level > instead of per citation? If that's the case, it could go in a keyword, > e.g., > > #+LATEX_CITATION: :style footcite > I have only used footcite in beamer presentations so far. It is quite common to show a fullframe image and have a footcitation. But I also mixed them with parencites, when a specicic item on the page is attributed to a given reference. Maybe one could debate about using something other that footcite for the former use case. So, I don't have too strong an opinion here. I just wanted to throw in a use-case where this decision was not made on the per-document level. Regards, Andreas
Re: [O] Citations, continued
Nicolas Goaziou writes:
>> So, the (opinionated) useful defaults in biblatex are:
>> cite(s), parencite(s), footcite(s), texcite(s), fullcite,
>> footfullcite, nocite
>
> Isn't footcite/footfullcite a choice made at the document's level
> instead of per citation? If that's the case, it could go in a keyword,
> e.g.,
>
> #+LATEX_CITATION: :style footcite
I guess you'd distinguish between fullcite and footfullcite then? I have
only ever used fullcite for illustrative purposes, e.g. demonstrating the
citation style. And I guess footcite is an alternative to
{textcite, parencite}.
>> Citation types for extracting parts:
>> citeauthor, citetitle, citeyear, citedate, citeurl,
>
> Can't this be attached to the key, as a filter?
Do you mean an ox-filter here or the slash "/"? It's more complex and but
probably also prettier. "[@K/author]" looks nice. I haven't seen "/" in
bibtex keys.
In any case, an ox-filter is no good. You sometimes need it for
constructing sentences, e.g. I like to keep out the year when it's obvious
to ease reading::
A (Y) showed foo. Note that A assumed that ...
> Then what about
>
> [cite:command: common pre; pre1 @key1 post1; ... ; common post]
Could work.
> where command is anything matching is constituted of alphanumeric
> characters only (this is just a guess, a proper regexp is yet to be
> determined).
>
> LaTeX back-end will see "command" and less advanced back-ends "cite", so
> that the same document can be exported through multiple back-ends.
OK. But what if I want to use, say, my "genitive" citation, "A's (Y)", in
html? This is perhaps a question of whether we'll manage to find a tool
to handle this for us, or we'll have to do it lisp.
> However, this syntax doesn't handle in-text citation for other back-ends
> than LaTeX. Hence the [@key post] proposal, or even @key [post], which
> I find more elegant than
>
> [citet: ...] / [citep: ...]
So [@key post] is equivalent to [cite:default_command: @key post]. Does
it scale to an arbitrary length of keys, e.g. [@k1 post1; ⋯; @kN postN]?
Could [@: pre1 @k1 post1; ⋯; preN @kN postN] be used if you need prenotes?
Or only [cite:⋯].
Would you "expand" all short citations in the early ox parsing?
I don't care for "@key [post]"
>> The default bibtex.el style generates keys like "%A%y:%t", so I think ":"
>> is no good, appealing as it is.
>
> Then "/" (filter) or "|" (pipe).
Why do you write "filter" after the slash? Am I supposed to think about
ox-filters?
—Rasmus
--
Governments should be afraid of their people
Re: [O] Org-mode Beamer graphviz & images
Thanks a lot Eric
The small sise was just there for my experiments to ensure my attributes
were processed
Thanks again i will be able to finish my deck of slides.
I did not know this syntax but I guessed that the workflow was the problem
Kind regards
Le 10 févr. 2015 10:51, "Eric S Fraga" a écrit :
> On Monday, 9 Feb 2015 at 21:59, deadbrain wrote:
> > Hi all org-mode gurus,
> > I am trying to generate a deck of slides using Emacs/org-mode /beamer &
> > some companion tools (graphviz & plantuml).
> > I have a problem to set the dimensions for the graphviz (or plantuml)
> > generated pictures.
> > Whatever the version used (tested 8.2.10-30 or 8.3-beta from git) and
> > whatever the option (ATTR_LATEX set) the TEX file generated does not
> > contain the right scaling options.
>
> Two changes are required to get this to work.
>
> 1. you need to have the latex attribute just before the image. To do
>this, execute the src block which will generate the results
>line. Then move the attribute line to just before the RESULTS
>directive.
>
> 2. you need to tell the exporter that the results to export are a file.
>
> In summary, I got your example to work with the following snippet:
>
> --8<---cut here---start->8---
> #+name: graph-info-figure
> #+begin_src dot :file graph-intro.png :cmdline -Kdot -Tpng :results file
> digraph G{
> node1 -> node2
> node1 -> node3
> node3 -> node4
> node3 -> node5
> }
> #+end_src
>
> #+ATTR_LATEX: :height 3cm
> #+results: graph-info-figure
> [[file:graph-intro.png]]
> --8<---cut here---end--->8---
>
> I named the src block as I find that it is good practice in general to
> do so...
>
> Note that I changed the size directive to 3cm to see the effect clearly!
>
> HTH,
> eric
>
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
> release_8.3beta-798-g528b90
>
Re: [O] Citations, continued
Rasmus writes: > So, the (opinionated) useful defaults in biblatex are: > cite(s), parencite(s), footcite(s), texcite(s), fullcite, > footfullcite, nocite Isn't footcite/footfullcite a choice made at the document's level instead of per citation? If that's the case, it could go in a keyword, e.g., #+LATEX_CITATION: :style footcite > Citation types for extracting parts: > citeauthor, citetitle, citeyear, citedate, citeurl, Can't this be attached to the key, as a filter? > From natbib: > citet (== textcite), citep (== parencite). > > Keys I don't care about, since they are quite biblatex specific: > smartcite, autocide, parentcite*, uppercase variants. *volcites(s) (any > objections?) > > In natbib: >citealt, citalp, starred variants > > So that's 17 support keys and two aliases. I guess this would deter most > authors from needing custom styles. Then what about [cite:command: common pre; pre1 @key1 post1; ... ; common post] where command is anything matching is constituted of alphanumeric characters only (this is just a guess, a proper regexp is yet to be determined). LaTeX back-end will see "command" and less advanced back-ends "cite", so that the same document can be exported through multiple back-ends. Also [cite: common pre; pre1 @key1 post1; ... ; common post] would be equivalent to [cite:default_command: common pre; pre1 @key1 post1; ... ; common post] where "default_command" would be set in a defcustom within "ox-latex.el". However, this syntax doesn't handle in-text citation for other back-ends than LaTeX. Hence the [@key post] proposal, or even @key [post], which I find more elegant than [citet: ...] / [citep: ...] > The default bibtex.el style generates keys like "%A%y:%t", so I think ":" > is no good, appealing as it is. Then "/" (filter) or "|" (pipe). Regards,
Re: [O] Citations, continued
Nicolas Goaziou writes:
> I think
>
> [cite: common pre; pre1 @k1 post1; pre2 @k2 post2; common post]
>
> is regular and readable enough. So, there's no need to add special
> support for multicite.
Definitely.
In latex you'd just use multicite whenever more than two keys within one
cite-group.
[cite: common pre; pre1 @k1 post1; pre2 @k2 post2; common post]
→ \textcites(common pre)(common post)[pre1][post1]{k1}[pre2][post2]{k2}
^^^
And:
[cite: @k1; k2] → \textcites()()[][]{k1}[][]{k2}
or \textcites{k1}{k2}
—Rasmus
--
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] Org-mode Beamer graphviz & images
On Monday, 9 Feb 2015 at 21:59, deadbrain wrote:
> Hi all org-mode gurus,
> I am trying to generate a deck of slides using Emacs/org-mode /beamer &
> some companion tools (graphviz & plantuml).
> I have a problem to set the dimensions for the graphviz (or plantuml)
> generated pictures.
> Whatever the version used (tested 8.2.10-30 or 8.3-beta from git) and
> whatever the option (ATTR_LATEX set) the TEX file generated does not
> contain the right scaling options.
Two changes are required to get this to work.
1. you need to have the latex attribute just before the image. To do
this, execute the src block which will generate the results
line. Then move the attribute line to just before the RESULTS
directive.
2. you need to tell the exporter that the results to export are a file.
In summary, I got your example to work with the following snippet:
--8<---cut here---start->8---
#+name: graph-info-figure
#+begin_src dot :file graph-intro.png :cmdline -Kdot -Tpng :results file
digraph G{
node1 -> node2
node1 -> node3
node3 -> node4
node3 -> node5
}
#+end_src
#+ATTR_LATEX: :height 3cm
#+results: graph-info-figure
[[file:graph-intro.png]]
--8<---cut here---end--->8---
I named the src block as I find that it is good practice in general to
do so...
Note that I changed the size directive to 3cm to see the effect clearly!
HTH,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-798-g528b90
Re: [O] Citations, continued
Rasmus writes: > Nicolas Goaziou writes: > >> If you write something like >> >> [cite: pre1 @k1 post1; pre2 @k2 post2] >> >> wouldn't it possible to guess you want to use multicite? IOW, does using >> "multicite" really implies a change in the syntax? > > To fully support multicite you need keyless citations in the beginning and > the end of the list, e.g. > > [cite: common pre; pre1 @k1 post1; pre2 @k2 post2; common post] > > Of course, for textcite it's easy to replicate wihtout. For parencites > and footcites, less so. I think [cite: common pre; pre1 @k1 post1; pre2 @k2 post2; common post] is regular and readable enough. So, there's no need to add special support for multicite. Regards,
Re: [O] Citations, continued
Nicolas Goaziou writes: > If you write something like > > [cite: pre1 @k1 post1; pre2 @k2 post2] > > wouldn't it possible to guess you want to use multicite? IOW, does using > "multicite" really implies a change in the syntax? To fully support multicite you need keyless citations in the beginning and the end of the list, e.g. [cite: common pre; pre1 @k1 post1; pre2 @k2 post2; common post] Of course, for textcite it's easy to replicate wihtout. For parencites and footcites, less so. —Rasmus -- May contains speling mistake
Re: [O] Citations, continued
Nicolas Goaziou writes: > Another option is to mimic custom links, if that's what you're thinking > of, which means to store every user-defined keyword in a variable and > build a regexp out of it. I dislike it even more because the document is > not portable anymore, as it requires you to share your custom keywords. So, the (opinionated) useful defaults in biblatex are: cite(s), parencite(s), footcite(s), texcite(s), fullcite, footfullcite, nocite Citation types for extracting parts: citeauthor, citetitle, citeyear, citedate, citeurl, >From natbib: citet (== textcite), citep (== parencite). Keys I don't care about, since they are quite biblatex specific: smartcite, autocide, parentcite*, uppercase variants. *volcites(s) (any objections?) In natbib: citealt, citalp, starred variants So that's 17 support keys and two aliases. I guess this would deter most authors from needing custom styles. > Note that it rules out colons from KEY syntax (but we can use another > less common character, e.g. "|"). The default bibtex.el style generates keys like "%A%y:%t", so I think ":" is no good, appealing as it is. —Rasmus Footnotes: ¹ which is just [cite: common pre; pre1 @k1 post1; ⋯; preN @kN postN; common post] -- Er du tosset for noge' lårt!
[O] [PATCH]: Add header-args property to source block info
Hi Following a recent discussion (based on me forgetting a ":" when setting the property :header-args), I added the output of the property header-args to the output of org-babel-get-src-block-info to make debugging easier. Before the function resulted in the following output (using my faulty code block): , | Lang: R | Header Arguments: | :cache no | :exportsboth | :hlines no | :noweb no | :resultscode exports output replace | :sessionsomename | :tangle no | ` One only saw that the property :results was not correct but not where it came from. Using the patched version, one gets the following: , | Lang: R | Properties: | :header-args:exports both :results output exports code | :header-args:R :session somename | Header Arguments: | :cache no | :exportsboth | :hlines no | :noweb no | :resultscode exports output replace | :sessionsomename | :tangle no ` Here one can clearly see that the property :header-args is not set correctly and can easily trace it down in the original org file. Also, actually seeing the property :header-args makes it easier to understand the whole inheritance of header arguments and how header-args and header-args+ interact. The same applir=es to the property :header-args:R (or any language specific header-args:language property) Cheers, Rainer Here is again the faulty org file which lead to the patch: --8<---cut here---start->8--- #+PROPERTY: header-args:R :session somename #+PROPERTY: header-args :exports both #+PROPERTY: header-args+ :results output * The bug This file create an (possibly endless?) loop during export * here exports both #+begin_src R cat(13+14) #+end_src * and here only code :PROPERTIES: :header-args+: exports code :END: #+begin_src R paste(13+14) #+end_src --8<---cut here---end--->8--- diff --git a/lisp/ob-core.el b/lisp/ob-core.el index ceda1aa..94a07f6 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -409,6 +409,10 @@ a window into the `org-babel-get-src-block-info' function." (header-args (nth 2 info))) (when name(funcall printf "Name: %s\n" name)) (when lang(funcall printf "Lang: %s\n" lang)) + (funcall printf "Properties:\n") + (funcall printf "\t:header-args \t%s\n" (org-entry-get (point) "header-args" t)) + (funcall printf "\t:header-args:%s \t%s\n" lang (org-entry-get (point) (concat "header-args:" lang) t)) + (when (funcall full switches) (funcall printf "Switches: %s\n" switches)) (funcall printf "Header Arguments:\n") (dolist (pair (sort header-args -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Citations, continued
Rasmus writes: > Not necessarily. I could do: > >(defun rasmus/gentive-citation (citation-element backend) > (case backend ...) ...) > >(add-to-list 'org-cite-types 'rasmus/gentive-citation ) > > E.g. for genitive citations such as "Smith's (1984) model", which can be > mostly emulated using primitives (:author and :year) if biblatex is not > available. As explained in another message, I'd like to avoid custom citations (portability issues). >> If more than two different keys are needed in a single document, use of >> custom links or raw LaTeX would then be unavoidable. OTOH, this gives us >> very readable citations within the buffer in most cases. > > Perhaps. But then we are back at not having proper support across > backends—which might be unavoidable in any case. Yet, aim high! Obtaining reasonable support for citations in every major back-end is already aiming high in my book. Anyway, I'm fine with having more powerful citation syntax for LaTeX, but let's keep the syntax as simple as possible. As I once was told, Org is not a programming language. Regards,
Re: [O] Citations, continued
t...@tsdye.com (Thomas S. Dye) writes:
> Yes, I typically use what I call a multicite to get multiple citations
> with biblatex. It just inserts {key}. I precede two or more of these
> with a placeholder--π for parencites, † for textcites, or ƒ for
> footcites--and then use a filter to insert \parencites, etc. This is
> crude, and wouldn't work in a more general setting, but it serves for
> the work I do.
If you write something like
[cite: pre1 @k1 post1; pre2 @k2 post2]
wouldn't it possible to guess you want to use multicite? IOW, does using
"multicite" really implies a change in the syntax?
Regards,
Re: [O] Citations, continued
John Kitchin writes: > Why cannot there be a list of acceptable keywords eg > > [citenum: > [citeyear: > [citeauthor: > > which a backend would be responsible for handling, including a default > handler for unknown keywords? It has the same problem as [pre @key post] syntax: it is slower to parser. This is because you cannot know beforehand the keyword, so you have to check almost every [...] in the document. Another option is to mimic custom links, if that's what you're thinking of, which means to store every user-defined keyword in a variable and build a regexp out of it. I dislike it even more because the document is not portable anymore, as it requires you to share your custom keywords. If year, or author, are needed, I suggested to append some optional parameter to the key, e.g., [cite: pre @key:year post] Note that it rules out colons from KEY syntax (but we can use another less common character, e.g. "|"). Regards,
Re: [O] [BUG] on export resulting in endless evaluation
Charles Berry writes: > Rainer M Krug krugs.de> writes: > >> >> Sebastien Vauban >> writes: >> >> > Rainer M Krug wrote: >> >> Charles Berry writes: >> >>> Rainer M Krug krugs.de> writes: >> >> when exporting the fillowing org file, I get an endless loop of >> evaluations. >> >> --8<---cut here---start->8--- >> #+PROPERTY: header-args :exports both >> #+PROPERTY: header-args+ :results output >> * The bug >> This file create an (possibly endless?) loop during export >> * here exports both >> #+begin_src R >> cat(13+14) >> #+end_src >> >> * and here only code >> :PROPERTIES: >> :header-args+: exports code >> :END: >> #+begin_src R >> paste(13+14) >> #+end_src >> --8<---cut here---end--->8--- >> >>> > > [discussion of problem, diagnostic methods, and cures deleted] > > >> 1) I thought that header-args is simply a string, but it already seems >> to be a list? > > Depends on which `header-args' one is discussing: > > 1. A property, as in `(org-entry-get (point) "header-args" t)' > > 2. The value of `(nth 2 (org-babel-get-src-block-info))' > > 3. The value of an elisp variable like `org-babel-default-header-args' > > 4. The 4th string matched by `org-babel-src-block-regexp' > > 5. The first string matched by `org-babel-multi-line-header-regexp' > > 1, 4 and 5 are strings. 2 and 3 are lists. Wow - there are many... But this helps quite a bit. > >> > [more questions deleted] >> > > Exactly what happens and when is a long story, involving a bunch of > functions. > > You might start by reading `org-babel-get-src-block-info' and > `org-babel-merge-params'. > > I think most of what you need to know really is in > >(info "(org) Using header arguments") > and >(info "(org) Property syntax") > > Just remember that a property called `header-args' is a string until Babel > starts working on it. So your original code, returns the "property called 'header-args'", (1) while your function below returns the one from 2) above. That clarifies. > > >> 5) Is there any way in getting, in this function, the same output >> (header-args) as from the code block suggested by Charles: >> > > You might try Thanks - but I was thinking about the ot=her way round, how I could get the "property called 'header-args'" (1) within the function called when using C-c C-v C-i to help in debugging - found a way of doing it and will send a patch. > #+BEGIN_SRC emacs-lisp :results pp >(cons (org-entry-get (point) "header-args" t) > (nth 2 (org-babel-get-src-block-info))) > #+END_SRC > > HTH, Most definitely, Thanks, Rainer > > Chuck > > > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
