Re: [O] org-edit-special doesn't work within #+BEGIN_LaTeX blocks anymore
On Sunday, 7 Sep 2014 at 21:14, Nicolas Goaziou wrote: Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: I ran into this change today. I like being able to edit latex in its own mode without having to resort to babel. Actually, this is a consequence of a known bug. See my last reply in thread at http://permalink.gmane.org/gmane.emacs.orgmode/90336 Thanks Nicolas but I don't actually understand this. blush IIRC, I used to be able to edit LaTeX special blocks in a similar way as babel src blocks but I no longer can. Is this correct? If so, why? It's not a deal breaker, by the way. I can survive by using LaTeX src blocks instead. thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.1, Org release_8.3beta-310-g38d0eb signature.asc Description: PGP signature
Re: [O] org-ref no key found
Hi John, I think I can replicate the org-ref bug now (if it is a bug). This is the situation: a) If I open emacs, load a file that already has some link, and click on the link (or place the cursor on it and press enter) I get the no key found message and I cannot open the notes file (I get a Wrong type argument: stringp, nil), although the link to the pdf file works. If I open more than one file, links do not work in any of them. At this point if I check the value of the org-ref-default-bibliography variable, I get the correct path and filename of my .bib file. b) If I insert a new citation (using Ctrl-]) in any of the documents, links work as they should in all documents (this is, I get the title and I can open the notes file). I should say that I am not using the org-ref-insert-bibliography-link function, because I use biblatex and I prefer to insert the Latex \printbibliography command. But if use it and insert the bibliography link, the behaviour does not change. This is what I have in my .emacs file that is related to RefTex and org-ref: -- ;; Load RefTex (add-hook 'LaTeX-mode-hook 'turn-on-reftex) ; with AUCTeX LaTeX mode (autoload 'reftex-mode reftex RefTeX Minor Mode t) (autoload 'turn-on-reftex reftex RefTeX Minor Mode nil) (autoload 'reftex-citation reftex-cite Make citation nil) (autoload 'reftex-index-phrase-mode reftex-index Phrase mode t) (add-hook 'LaTeX-mode-hook 'turn-on-reftex) ; with AUCTeX LaTeX mode (add-hook 'latex-mode-hook 'turn-on-reftex) ; with Emacs latex mode ;; Make RefTeX faster (setq reftex-enable-partial-scans t) (setq reftex-save-parse-info t) (setq reftex-use-multiple-selection-buffers t) (setq reftex-plug-into-AUCTeX t) (setq reftex-default-bibliography '(/home/julian/Documents/Refs/BibTex/references.bib)) (setq reftex-sort-bibtex-matches author) ; Sort entries found in BibTex database (setq bibtex-dialect biblatex) -- (require 'org-ref) (setq org-ref-bibliography-notes /home/julian/Documents/org files/notes.org org-ref-default-bibliography '(/home/julian/Documents/Refs/BibTex/references.bib) org-ref-pdf-directory /home/julian/Documents/Refs/) (setq org-ref-default-citation-link parencite) -- I am sending you very simple .org and .bib files that (in my computer) reproduce this behaviour. In this file I did use org-ref-insert-bibliography-link. Let me know if I can give you any other information. All the best, Julian trial.bib Description: Binary data trial.org Description: Lotus Organizer Julian M. Burgos writes: John, for some weird reason everything seems to be working now. Thanks for your help... I will let you know if I break it again. John Kitchin writes: that is odd. this means org-ref is not finding the key you clicked on. could you send me a small example that reproduces your problem (an org-file and the bib file)? Julian M. Burgos jul...@hafro.is writes: Hi John, No, they still do not work even after I click on the bibliography link and get my .bib file opened. Julian John Kitchin writes: Julian M. Burgos jul...@hafro.is writes: If you click on the bibliography link to open the file, and then go back to your org-file, do the cite links work? I suspect the notes problem is related to the no key found problem. Hello everyone, I am playing around with Joh Kitchin's excellent org-ref, and I am having a few issues. In my .emacs file I have set up the values for the org-ref-bibliography-notes, org-ref-default-bibliography, and org-ref-pdf-directory. With this I can access my .bib database and use org-ref-insert-cite link to add a citation link with no problems. But when I press enter on the cite link, I get the following message: no key found (No key found) (p)df (u)rl (n)otes (q) quit If I press p I get the pdf file, but if I press n I get the following message: Wrong type argument: stringp, nil. Any ideas how to solve this? Many thanks, Julian -- Julian Mariano Burgos, PhD Hafrannsóknastofnun/Marine Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: jul...@hafro.is
Re: [O] org-edit-special doesn't work within #+BEGIN_LaTeX blocks anymore
Eric S Fraga e.fr...@ucl.ac.uk writes: Thanks Nicolas but I don't actually understand this. blush IIRC, I used to be able to edit LaTeX special blocks in a similar way as babel src blocks but I no longer can. Is this correct? If so, why? To cut a long story short, I tried to solve a special-block/export-block ambiguity, but my solution was wrong and export blocks in master started acting weird. I suggested another, not backward-compatible, solution and I'm waiting for comments about it. Anyhow, I reverted this mess: situation should be back to normal. Regards, -- Nicolas Goaziou
[O] Make html password protected?
Hi I do not have much experience with html and websites (what an understatement!) but I would like to publish / export a simple html page password protected. Is ther an easy way to do it in word? The content is not highly confidential or sensitive, just some analysis for a paper of which I would like to provide regular feedback to my co-authors and which should not be to easily readable by others. Any suggestions? Rainer -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgptryG02Ks_m.pgp Description: PGP signature
Re: [O] [BUG] org-table-beginning/end-of-field
Hello, Florian Beck f...@miszellen.de writes: The argument of `org-table-beginning-of-field' and `org-table-end-of-field' is in fact not optional. Thanks for the patch. Though, wouldn't it make more sense to properly handle a missing argument instead? Regards, -- Nicolas Goaziou
[O] Floating Table of figures in html export?
Hi now that I have a floating TOC in my exported html, is there a way of 1) adding a Table of Figures in the html export (I have it in the LaTeX export), and 2) how can I make this one floating as well? Thanks, Rainer -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgpAss7aKwKsb.pgp Description: PGP signature
Re: [O] Difference :header-args: and :header-args+:?
I would like to ping this question, as it is still bothering me and I could not find any explanation. Thanks, Rainer Aaron Ecay aarone...@gmail.com writes: Hi Rainer, 2014ko irailak 5an, Rainer M Krug-ek idatzi zuen: Absolutely - but this has been (unfortunately!!!) be deprecated: Quoted from the manual [1] : , | [1] The deprecated syntax for default header argument properties, using | the name of the header argument as a property name directly, evaluates | the property as seen by the corresponding source block definition. This | behavior has been kept for backwards compatibility. ` I was using this deprecated behavior and I was *very* happy with it, but I am trying to adjust to the new syntax. So how can I use the new syntax? Eric Schulte has said http://mid.gmane.org/87wqce0w9n@gmail.com that the deprecation of this feature is “premature”. I didn’t realize at the time that the deprecation was also included in the manual rather than just a code comment. Possibly it should be un-deprecated. Certainly I agree that the suggested replacement is less capable. Sorry I can’t help more. Maybe Eric or Achim (who introduced the deprecation) will comment. -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgpQtmWoH1Rmf.pgp Description: PGP signature
Re: [O] org-edit-special doesn't work within #+BEGIN_LaTeX blocks anymore
Thanks for the update and explanation. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.1, Org release_8.3beta-310-g38d0eb signature.asc Description: PGP signature
Re: [O] [PATCH] org-table-beginning/end-of-field
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Thanks for the patch. Though, wouldn't it make more sense to properly handle a missing argument instead? How about this? -- Florian Beck From 4fb2bbff2238d15ae7c896e0eb268b74ea4e56dc Mon Sep 17 00:00:00 2001 From: Florian Beck f...@miszellen.de Date: Mon, 8 Sep 2014 14:08:56 +0200 Subject: [PATCH] org-table: fix arguments of `org-table-beginning-of-field' and `org-table-end-of-field'. Also fix docstring and cleanup code. * lisp/org-table.el (org-table--border-of-field): new function (org-table-beginning-of-field): call it (org-table-end-of-field): call it --- lisp/org-table.el | 45 + 1 file changed, 21 insertions(+), 24 deletions(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 547f933..31fda57 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -1061,37 +1061,34 @@ Before doing so, re-align the table if necessary. (if (looking-at | ?) (goto-char (match-end 0 -(defun org-table-beginning-of-field (optional n) - Move to the end of the current table field. -If already at or after the end, move to the end of the next table field. -With numeric argument N, move N-1 fields forward first. - (interactive p) +(defun org-table--border-of-field (n move-fn element cmp-fn) (let ((pos (point))) (while ( n 1) (setq n (1- n)) - (org-table-previous-field)) -(if (not (re-search-backward | (point-at-bol 0) t)) - (user-error No more table fields before the current) - (goto-char (match-end 0)) - (and (looking-at ) (forward-char 1))) -(if (= (point) pos) (org-table-beginning-of-field 2 + (funcall move-fn)) +(goto-char (org-element-property element (org-element-context))) +(if (and ( n 0) (funcall cmp-fn (point) pos)) + (org-table--border-of-field 2 move-fn element cmp-fn -(defun org-table-end-of-field (optional n) +(defun org-table-beginning-of-field (optional n) Move to the beginning of the current table field. -If already at or before the beginning, move to the beginning of the -previous field. +If already at or before the beginning and N is not 0, move to the +beginning of the previous table field. With numeric argument N, move N-1 fields backward first. (interactive p) - (let ((pos (point))) -(while ( n 1) - (setq n (1- n)) - (org-table-next-field)) -(when (re-search-forward | (point-at-eol 1) t) - (backward-char 1) - (skip-chars-backward ) - (if (and (equal (char-before (point)) ?|) (looking-at )) - (forward-char 1))) -(if (= (point) pos) (org-table-end-of-field 2 + (org-table--border-of-field (or n 1) + 'org-table-previous-field + :contents-begin '=)) + +(defun org-table-end-of-field (optional n) + Move to the end of the current table field. +If already at or after the end and N is not 0, move to the end of the +next field. +With numeric argument N, move N-1 fields forward first. + (interactive p) + (org-table--border-of-field (or n 1) + 'org-table-next-field + :contents-end '=)) ;;;###autoload (defun org-table-next-row () -- 1.9.1
[O] org, tables export to html with colors?
hi Is there a way to add colors to a org table such that the color appears in the html exported version. I know that *test* will give boldface, but colors? thanks Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
Re: [O] Difference :header-args: and :header-args+:?
Rainer M Krug writes: Aaron Ecay aarone...@gmail.com writes: I have a question concerning the property :header-args:. In addition to :header-args: there is also :header-args+:. Since essentially you're asking about property syntax, please read the corresponding chapter of the manual. 1) If I set some properties globally and in a subtree I want to *add* a *new* header argument - do I have to use the + or not? If you do that at the same level (old-non-lang-specific, non-lang-specific, lang-specific) then yes. 2) If I set some properties globally and in a subtree I want to *change* a *single* header argument which *was set globally* - do I have to use the + or not? You can only override a header argument, not change it. Again, if you do this at the same level and there are other header arguments at that level, then the + variant is what you want. Are you aware that you can set individual header args as properties? Something like (at the file level): Are you aware that this doesn't quite do what you think it does, some of the time, when things become more complex than your example? I was using this deprecated behavior and I was *very* happy with it, but I am trying to adjust to the new syntax. So how can I use the new syntax? If you maybe had an example of what you're trying to do instead of asking stuff about things you don't want to do? Otherwise, have a look at orgmode.git/testing/examples/ob-header-arg-defaults.org and adapt to your needs. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] Difference :header-args: and :header-args+:?
Aaron Ecay writes: Eric Schulte has said http://mid.gmane.org/87wqce0w9n@gmail.com that the deprecation of this feature is “premature”. I didn’t realize at the time that the deprecation was also included in the manual rather than just a code comment. Possibly it should be un-deprecated. It shouldn't, owing to a number of essentially un-fixable corner cases and its inherent non-scaleability. Certainly I agree that the suggested replacement is less capable. Do you have an example of something that it cannot do (modulo the bugs and corners of the deprecated syntax)? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] bug#18414: org-mobile checksum stuff supressing errors and using inconsistent checksum
Hi Taylor, Taylor Sutton tayl...@mit.edu writes: I can fix it. It looks like your understanding of the problems is enough to propose a patch -- would you like to propose one? Thanks in advance, -- Bastien
Re: [O] [PATCH] org-table-beginning/end-of-field
Florian Beck f...@miszellen.de writes: How about this? Nice. Some comments follow. From 4fb2bbff2238d15ae7c896e0eb268b74ea4e56dc Mon Sep 17 00:00:00 2001 From: Florian Beck f...@miszellen.de Date: Mon, 8 Sep 2014 14:08:56 +0200 Subject: [PATCH] org-table: fix arguments of `org-table-beginning-of-field' fix needs to be capitalized. and `org-table-end-of-field'. Also fix docstring and cleanup code. You need a shorter summary, e.g., org-table: Fix org-table/beginning/end/-of-field. The second sentence should go at the end of the commit message. Also, there's no full stop on summary lines. * lisp/org-table.el (org-table--border-of-field): new function new needs to be capitalized. Also there's a missing full stop. (org-table-beginning-of-field): call it (org-table-end-of-field): call it (org-table-beginning-of-field, org-table-end-of-field): Call it. +(defun org-table--border-of-field (n move-fn element cmp-fn) A docstring would be nice, even for a helper function. (let ((pos (point))) (while ( n 1) (setq n (1- n)) - (org-table-previous-field)) -(if (not (re-search-backward | (point-at-bol 0) t)) - (user-error No more table fields before the current) - (goto-char (match-end 0)) - (and (looking-at ) (forward-char 1))) -(if (= (point) pos) (org-table-beginning-of-field 2 + (funcall move-fn)) While you're at it, I suggest (dotimes (_ (1- n)) (funcall move-fn)) instead of (while ( n 1) ...) Also, note that you can avoid requiring MOVE-FN, ELEMENT and CMP-FN if you decide that ( n 0) = (#'org-table-next-field :contents-end #'=) ( n 0) = (#'org-table-previous-fierd :contents-begin #'=) Up to you. +(goto-char (org-element-property element (org-element-context))) You need to be more careful here. You might be outside of a table, or within an object contained in a cell, e.g., | some *bold* object | where (org-element-context) on bold will return a `bold' type object with different :contents-begin and :contents-end values. IOW, you need to let-bind (org-element-context) and find the first `table', `table-row' or `table-cell' object/element among it and its parents. Then - if no such ancestor is found: return an error (not at a table) - if `table' is found but point is not within [:contents-begin :contents-end[ interval, return an error (not inside the table) - if `table' or `table-row' is found, you need to apply org-table/previous/next/-field once (and diminish N by one) to make sure point will be left on a regular cell, if possible. +(if (and ( n 0) (funcall cmp-fn (point) pos)) + (org-table--border-of-field 2 move-fn element cmp-fn I don't think ( n 0) is necessary, is it? Also, I suggest to use `when' (or `and' if return value matters) over one-armed `if'. -(defun org-table-end-of-field (optional n) +(defun org-table-beginning-of-field (optional n) Move to the beginning of the current table field. -If already at or before the beginning, move to the beginning of the -previous field. +If already at or before the beginning and N is not 0, move to the +beginning of the previous table field. With numeric argument N, move N-1 fields backward first. I wouldn't start a new line here. Also don't forget double spaces: If already at or before the beginning and N is not 0, move to the beginning of the previous table field. With numeric argument N, move N-1 fields backward first. + (org-table--border-of-field (or n 1) + 'org-table-previous-field + :contents-begin '=)) Nitpick: #'org-table-previous-field and #'=. +(defun org-table-end-of-field (optional n) + Move to the end of the current table field. +If already at or after the end and N is not 0, move to the end of the +next field. +With numeric argument N, move N-1 fields forward first. + (interactive p) + (org-table--border-of-field (or n 1) + 'org-table-next-field + :contents-end '=)) Ditto. Thank you for taking care of this. There are bonus points if you can write tests along with this change. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] remap orgtbl-ascii-plot to C-c #
Thierry Banel tbanelweb...@free.fr writes: Le 03/09/2014 20:22, Nicolas Goaziou a écrit : It looks good but I realized (a bit late) we cannot use C-c p as it is reserved to users, as any C-c LETTER combination. Here is a patch to change the key-binding of `orgtbl-ascii-plot' from C-c p to C-c # (The little grid symbol # seems appropriate for a plot). (But of course another key combination is still possible). It is better than C-c p, but I think a common prefix for plotting table would be better. You need to also tell org.texi about this change. C-c # is already mapped to `org-update-statistics-cookies'. It makes sense only on a header with a cookie like this: * Header [12/45] Note that there is no such limitation for statistics cookies: - My plan [1/2] - [X] Step 1 - [ ] Step 2 It is even technically possible to have one in a table. Regards, -- Nicolas Goaziou
Re: [O] Symbol's value as variable is void: org-planning-line-re
Nick Dokos ndokos at gmail.com writes: Check your load-path. Thanks. My load-path seems to put Org from git first. Moving that checkout back to 288ffa fixes, newer versions have the problem behaviors. Am I overlooking something that could still lead to a mixed Org version?: (/home/myuser/.emacs.d/el-get/package/elpa/ido-ubiquitous-2.9 ... /home/myuser/.emacs.d/el-get/org-mode/lisp /home/myuser/.emacs.d/el-get/org-mode/contrib/lisp /home/myuser/.emacs.d/el-get/org-mode ... ~/.emacs.d/el-get/ /home/myuser/.emacs.d/el-get/el-get/methods ~/.emacs.d/el-get/el-get /etc/emacs /usr/share/emacs/site-lisp /usr/share/emacs/site-lisp/site-gentoo.d /usr/share/emacs/24.4.50/lisp ... /usr/share/emacs/24.4.50/lisp/org ...) Jeff
Re: [O] Symbol's value as variable is void: org-planning-line-re
Jeff Kowalczyk writes: Thanks. My load-path seems to put Org from git first. Moving that checkout back to 288ffa fixes, newer versions have the problem behaviors. Am I overlooking something that could still lead to a mixed Org version?: Yes, you may not use anything from Org before the load-path gets set up. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] Managing articles in orgmode and collaboration
Hello,
I’d like to keep my library of scientific articles in orgmode, along
with notes, links to external files (mostly PDF), etc. This has been
discussed repeatedly on this list, for example in the recent thread
http://thread.gmane.org/gmane.emacs.orgmode/78983.
Most solutions seem to be based around a central BibTeX file and take
advantage of RefTeX to navigate between citations to articles (in LaTeX
or org files), the BibTeX file, related entries in an org-file, and
linked external files. Often the key that connects the various items is
a unique label (in LastnameYear format, for example). This key is used
as label when citing and in BibTeX, as orgmode CUSTOM_ID, and as the
filename of an associated external file.
This seems to work well for people who have complete control over the
articles they write. But what about articles with co-authors? These
must be self-contained, so one needs a separate BibTeX file for each
article project. Let’s say that a co-author adds a new reference to a
common project, but the cited paper is already in my database under a
different label. Maybe that very paper is already cited in an older
article with different co-authors using a different \cite label?
Does anyone have a solution that handles such cases nicely? Perhaps
something along these lines: My (own, i.e. controlled by myself) library
of articles lives in one/several org files. Each entry there contains
links to external files, URLs, DOIs, etc. and enough information to
create a BibTeX record. (Such entries could be generated almost
automatically from .bib files found on the internet.) A custom Emacs
function allows to create BibTeX records for use in project-specific
.bib-files from the orgfile-entries. Now the last missing piece is to
connect things also in the other direction: allow to jump to the related
org-entry for a paper from a \cite{} in a paper, even if the reference
has been added to the .bib file by a colleague.
This last piece is the most difficult to realize. It would require
either a rather smart search, or a robust CUSTOM_ID (Perhaps
LastnameYearPagenr would be unique and robust enough?).
I’m interested in discussing these issues.
Re: [O] Difference :header-args: and :header-args+:?
Hi Achim, 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: Aaron Ecay writes: Eric Schulte has said http://mid.gmane.org/87wqce0w9n@gmail.com that the deprecation of this feature is “premature”. I didn’t realize at the time that the deprecation was also included in the manual rather than just a code comment. Possibly it should be un-deprecated. It shouldn't, owing to a number of essentially un-fixable corner cases and its inherent non-scaleability. Can you say more about the corner cases? I looked for discussion on the mailing list around the time your changes were introduced. I only found a message http://article.gmane.org/gmane.emacs.orgmode/73832 (in a thread about how/where #+call lines insert their results) that treats the change as a fait accompli, (“I agree that this didn't make all that much sense in the past, but with property evaluation and elisp argument evaluation now anchored to the point of call [...]”) I could have missed something, of course. As to the non-scalability, that should be fixed by some combination of the parser cache and retrieving all properties at once (via ‘org-entry-properties’) rather than ‘org-entry-get’-ing them one-by-one. There are a couple recent threads about this. Here’s one http://mid.gmane.org/87tx5xunas@gmail.com about a reimplementation of the property API functions in terms of the parser. Here http://mid.gmane.org/CAAjq1mdioFFD-K9gX=ducb205lyabqfkgobkfgyaciv0stt...@mail.gmail.com the speed tradeoffs of the two approaches are discussed. (IOW, as presently implemented the classical method is not scalable, but said unscalability is by no means “inherent”.) Certainly I agree that the suggested replacement is less capable. Do you have an example of something that it cannot do (modulo the bugs and corners of the deprecated syntax)? See the attached file for two examples, one related to #+call lines and one not. Again, can you say more about what you mean by the bugs and corners of the deprecated syntax? The #+call behavior doesn’t seem like a bug, but basically a difference in whether header args are dynamically (wrt point of call) or lexically (wrt point of definition) scoped. Dynamic vs. lexical scoping is not a bug, but a matter of taste/language design/etc. Most computer languages with which I’m familiar (Python, R, C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been slowly but steadily moving in that direction for years. Thus this new suggested dynamic-type behavior for header args is surprising to me. The first demonstration in the attachment (not related to #+calls) seems like a much clearer case of deficiency of the new system: an inability to inherit different args from different levels. (Please factor away from the nonsense strings in place of “yes” and “no” – I wanted to make it clear where each value was coming from, and assure that they were not being generated by default. Of course in a real use case the values for these header args would be “yes” and “no”. Also, one could also demonstrate the problem with header args that can take an arbitrary string value by design, like :session.) From your other mail: 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: Rainer M Krug writes: Aaron Ecay aarone...@gmail.com writes: [...] Are you aware that you can set individual header args as properties? Something like (at the file level): Are you aware that this doesn't quite do what you think it does, some of the time, when things become more complex than your example? Again, can you say more about what you mean here? As a personal anecdote, I have never been surprised by the behavior of “classic” header arg properties. I was using this deprecated behavior and I was *very* happy with it, but I am trying to adjust to the new syntax. So how can I use the new syntax? If you maybe had an example of what you're trying to do instead of asking stuff about things you don't want to do? Otherwise, have a look at orgmode.git/testing/examples/ob-header-arg-defaults.org I find the content of this file incredibly dense, and the suggestion of its use as documentation bordering on a joke. (Documentation may not exist, and that just means an area for improvement has been found. But it’s not as though we’re all going to read that file and suddenly understand what you mean.) It looks like it is trying to demonstrate inheritance and overriding of :var header args. I can’t figure out why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. That is a very confusing interaction (to name just one). It’s also not clear to me how it relates to other header args, since vars supplement each other, whereas other types of header replace. -- Aaron Ecay * Prelim Run this code first: #+begin_src emacs-lisp (require 'cl-lib) (defun awe-show-headers (rest headers) (pp-to-string (save-excursion
