Re: [O] [babel] feature request: debug messages
Eric Schulte writes: > Andreas Leha writes: > >> Andreas Leha writes: >> >>> Andreas Leha writes: >>> Hi Eric, Eric Schulte writes: > Andreas Leha writes: > >> Hi Eric, >> >> >> Eric Schulte writes: >> >>> Hi Andreas, >>> >>> This should be easy to turn on or off using the newly introduced >>> :prologue and :epilogue header arguments. See the manual and the >>> following example. >>> >>> #+Title: debug messages >>> #+Property: session *R* >>> #+Property: prologue (format "print(\"entering %s\")" >>> (get-current-name)) >>> >>> An elisp block to simplify the =:prologue= definition. >>> #+begin_src emacs-lisp >>> (defun get-current-name () >>> (save-excursion >>> (goto-char org-babel-current-src-block-location) >>> (while (and (forward-line -1) >>> (looking-at org-babel-multi-line-header-regexp))) >>> (when (looking-at org-babel-src-name-w-name-regexp) >>> (org-no-properties (match-string 3) >>> #+end_src >>> >>> Two blocks with simple assignments. >>> >>> #+name: block-1 >>> #+begin_src R >>> x <- 2 + 2 >>> #+end_src >>> >>> #+name: block-2 >>> #+begin_src R >>> y <- x + x >>> #+end_src >>> >>> Execute the whole buffer =C-c C-v b= to see the prologue in action. >>> >>> Andreas Leha writes: >>> Hi all, I would love to see messages like 'entering block foo...' and '...leaving block foo' printed to my R console. This would be very handy when I evaluate a subtree (C-c C-v s) with a lot of #+call lines and some lengthy ones. I know that (1) I could implement that myself at in the source blocks. But I would love if orgmode did that for me (2) Such messages are already printed to the emacs *Messages* buffer. But that buffer might not be visible and I can not switch to it, without interrupting the evaluation. Anyway it would be much nicer to see that output together with the other output, that my code generates. In essence it would be very helpful, if there was a variable org-babel-print-debug-messages (or org-babel-debug-level...) which if non-nil would cause that messages to be printed. Or is there somewhere already? Regards, Andreas >> >> >> thanks for the quick answer! The :prologue and :epilogue header >> arguments have indeed slipped my attention and they look really >> interesting! I see, that they are documented, but somehow, they seem to >> not get their headline and TOC entry? >> >> I have three problems with your example, though: >> 1) It does not run >> 2) It does not work >> 3) It won't be usable for 'my' epilogue, correct? >> ;-) >> > > Ah! My fault. I had to add prologue and epilogue support to ob-R.el > when working through the example I sent, but then I forgot to commit > that support to Org-mode. I've just pushed up that commit, and > re-worked my example file to avoid the issue of prologue being applied > to the emacs-lisp code block (using the very nice and also new > language-specific PROPERTY header arguments). > > Finally, I don't use epilogues in the example because (as the last thing > evaluated) they would override the code block results. > > Hopefully the following: > 1. will run > 2. will work > 3. will be usable > > Cheers, > > #+Title: debug messages > #+Property: header-args:R :session *R* :prologue (format > "print(\"entering %s\")" (get-current-name)) > > An elisp block to simplify the =:prologue= definition. > #+begin_src emacs-lisp :results silent > (defun get-current-name () > (save-excursion > (goto-char org-babel-current-src-block-location) > (while (and (forward-line -1) > (looking-at org-babel-multi-line-header-regexp))) > (when (looking-at org-babel-src-name-w-name-regexp) > (org-no-properties (match-string 3) > #+end_src > > Two blocks with simple assignments. > > #+name: block-1 > #+begin_src R > x <- 2 + 2 > #+end_src > > #+RESULTS: block-1 > : 4 > #+name: block-2 > #+begin_src R > y <- x + x > #+end_src > > #+RESULTS: block-2 > : 8 > > Execute the whole buffer =C-c C-v b= to see the prologue in action. > >> >> 1) >> It does not run, because org tries to do the prologue also on the >> emacs-lisp block defining the function of the prologue. So, I get >> "format: Symbol's function definition is vo
Re: [O] english automatically option added to latex's babel package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 19 Jul 2013 13:00:26 +0200
Rasmus wrote:
> Eric S Fraga writes:
>
> > Renato writes:
> >
> >> Hi, I've customized org-latex-packages-alist and added the package
> >> "babel", with option "italian", however in my latex exports I get:
> >
> > Add it with AUTO instead of italian and then specify the language in
> > your document using
> >
> > #+language: it
> >
> > If you want Italian for all documents by default, set
> > org-export-default-language:
>
> These are the recommend instructions, yes, and indeed how I imagined
> people to use it.
>
> I looked at it and while I can reproduce there's no bug.
>
> Start from emacs -q and eval
>
> (require 'ox-latex)
> (add-to-list 'org-latex-default-packages-alist '("italian" babel nil))
>
> When I export the document
>
> #+begin_src org
>* titel
> #+end_src
>
> the language defaults to org-export-default-language which is "en".
> So it does what you'd expect and loads English in front of Italian
> 'cause it's the document language.
>
> Compare to what Eric says:
>
> #+begin_src org
> #+LANGUAGE: it
>* titel
> #+end_src
>
> You get only Italian.
>
> So it guesses the language correctly.
Hi, many thanks. Yes the #+language option is perfect, as I still want
my default language to be english.
cheers,
renato
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR8OMdAAoJEBz6xFdttjrfNmEH/AijrA9V1AM2DyiSFqy+ZF23
LiNIGUTQwuCsI5LZPi3q4Xv80CyvQLuJGlazBTL3uN684bCgNXbaTEPaisET8ZHc
Z8dyrbr3JP+TVhvK9FV9ypF5I7NPc69nQ50aGtFk+g6I016iPe+dLfppr16hnVCv
vIvTE7DU4uZU8lZn7LGMU3dRPm1DX5GNmFXOzqg+Lqgif2PSn7Ny3UCFMAwgxuGX
Zf/PReKx4gcwdo7FQIJbCweFVNS8VOM7p0CuMW3VtSZrV4WKG5RppoQ8O7qA1u5V
YBYcpYAYyns107zv7U5U8LUvlKi50IIbNAKCD8Apbp6EquYdZM5Zo3gTwMw2NVk=
=XPer
-END PGP SIGNATURE-
Re: [O] Standardize #+BIBLIOGRAPHY line
Jambunathan K writes: >> #+toc: headlines :levels 4 > > (:toc headlines :levels 4) Btw, I forgot to mention that BIBLIOGRAPHY is itself a "table of citations".
Re: [O] Standardize #+BIBLIOGRAPHY line
Nicolas
Getting Citation right to cater to general needs is going to be complex.
This is mainly because
1. Org's object syntax is very rudimentary and not "extensible"
2. "real-world" citations may need some annotations page number etc.
I think it is good to *atleast make a move* in standardizing the cite
elements. My gut feeling is that cite objects - for now - should be
coded as \cite { } latex objects. This specifically means that link
syntax for cite should NOT BE ENCOURAGED (or STRONGLY DISCOURAGED).
As an aside, I am inclined to think of cite objects as "special class"
of "footnote" elements. Footnotes are unique in that it "interlinks"
both object and element worlds. Elements can have attributes attached
to them. Consider for example, a syntax like this.
Joshu's "Mu" [cite: blyth_zen_1966] is a koan that a practioner must
break through.
#+ATTR_PAGE: :page 17
[cite:blyth_zen_1966] Zen and Zen Classics, Volume 4, Mumonkan
Now what goes within the brackets - "blyth_zen_1966" - is just a label.
The attributes of that object are set in a paragraph that is
"introduced" with that label (as above).
> However, I think it ought to be merged in ox-bibtex.el instead.
Does the author have copyright assignments for contributing to Emacs?
Taru Karttunen
As a personal policy, I don't want to touch a file which wouldn't end up
in Emacs proper.
Any changes that I make to Emacs - that includes Org-mode - is
*guaranteed* to end up in Emacs proper. It's going to happen in it's
own time.
> "ox-bibtex" name is misleading as it is not directly related to "bibtex"
> program. At its core, it merely introduces a BIBLIOGRAPHY keyword and
> [[cite:...]] links. It also provides accessors and predicates wrt them:
>
> - org-bibtex-get-file
> - org-bibtex-get-style
> - org-bibtex-get-arguments
> - org-bibtex-citation-p
> - org-bibtex-get-citation-key
These wouldn't be necessary if the reader syntax is improved.
Why not create an ox-cite.el, make yourself the author and move your own
changes to that file. You can also FAKE a `citation-reference' object
so that the backend consumers are totally unaware of how these objects
are represented in the Org document.
We can have separate ox-bibtex.el and ox-jabref.el - I call them as
"citation processors". They will be providing the "standard"
transcoders - `org-CITATION-PROCESSOR-citation-reference' and
`org-CITATION-PROCESSOR-bibliography'. As noted in previous mail,
having first class transcoders will help, in switching an export backend
to switch to someother citation processor. One just has to switch the
translators.
> Maybe all of this calls for a generalization of the reader function.
> Something like "stuff everything before the first keyword as the value
> of a generic keyword". IOW,
>
> #+keyword: :a val :b val2=>(:a "val" :b "val2")
> #+keyword: text :a val =>(:head "text" :a "val")
> #+keyword: text :head other =>not good
How about, making the keyword itself as a property, if the option string
DOESN'T is not introduced by a symbol.
#+keyword: :a val :b val2=>(:a "val" :b "val2")
#+keyword: text :a b :c d=>(:keyword text :a b :c d)
> #+toc: headlines :levels 4
(:toc headlines :levels 4)
> #+BEAMER_THEME: Madrid
(:beamer-theme Madrid)
> #+BEAMER_THEME: Rochester [height=20pt]
(:beamer-theme Rochester [height=20pt])
These all will become "values" of a `keyword' element.
> Regards,
Re: [O] Standardize #+BIBLIOGRAPHY line
> I understand. You can still use ox-bibtex.el for now, and just ignore > all the "[[cite:...]]" part. Each citation processor should reside in it's own file. So ox-jabref.el is the right place for my changes. It seems that you are not interested in introducing ox-cite.el or a make-shift `citation-reference' element. That's fine. Atleast, I have explored to see whether we can strike a common ground. > Though, it would obviously be best if original "org-bibtex.el" author > (Cc'ed) had already signed FSF papers. Ok. > Regards,
Re: [O] [ANN] Bibliography support ODT + JabRef
I have finalized the JabRef + ODT export. The changes can be pulled
from my own repo at
HomePage: http://repo.or.cz/w/org-mode/org-kjn.git
Pull URL: git://repo.or.cz/org-mode/org-kjn.git
http://repo.or.cz/r/org-mode/org-kjn.git
For purposes of quick testing, the files attached in the parent should
be good enough.
Here goes the commmit log.
ox-odt: Add support for JabRef
* contrib/lisp/ox-jabref.el: New file.
* lisp/org.el (org-modules): Add ox-jabref.
* etc/styles/OrgOdtStyles.xml (Bibliography_20_Heading)
(Bibliography, OrgBibliographyList): New styles.
* lisp/ox-odt.el (org-export-define-backend): New non-standard
element `citation-reference'. Register
`org-odt--translate-cite-fragments'.
(org-odt--translate-cite-fragments): New filter.
(org-odt-citation-transcoders): New user option.
(org-odt-citation-reference, org-odt-citation-reference/numbered):
Stock transcoders for `citation-reference' elements.
(org-odt-keyword): Handle BIBLIOGRAPHY.
(org-odt--export-wrap): Make the condition case debuggable.
Also add autoloads for citation transcoders provided by
ox-jabref.el.
NOTE: Review all the above changes once ox.el provides standard
tools for handling citaitons.
___
ORG-JABREF
Jambunathan K
___
Table of Contents
_
1 Quick start guide:
2 Developer (or Implementation) notes
1 Quick start guide:
1. Install [JabRef]
This module is tested with version JabRef-2.9.2.jar.
2. Install the JabRef plugin [Chicago Export filters for Org-mode].
3. Configure ox-jabref.el
,
| M-x customize-group RET org-jabref RET
`
Review the settings.
4. Configure ox-odt.el
,
| M-x customize-variable RET org-odt-citation-transcoders RET
`
Following settings are recommended.
1. No citation support
,
| (setq org-odt-citation-transcoders
| '(org-odt-latex-fragment . ignore))
`
This is the default setting.
- #+BIBLIOGRAPHY is ignored.
- \cite{} directives are typeset as plain text.
2. Numeric Citations
,
| (setq org-odt-citation-transcoders
| '(org-odt-citation-reference/numbered
| . org-jabref-odt-bibliography/numbered))
`
- #+BIBLIOGRAPHY is replaced with numerical listing of
Bibliographic entries. The listing includes only cited keys
and is sorted on the order in which the cite keys are seen in
the Org file.
- \cite{} directives are replaced with numeric links to the
associated Bibliographic entry.
3. Unnumbered (or Text) Citations with Filtered Bibliography
,
| (setq org-odt-citation-transcoders
| '(org-jabref-odt-citation-reference/text
| . org-jabref-odt-bibliography/filtered))
`
- #+BIBLIOGRAPHY is replaced with listing of Bibliographic
entries. The listing is limited to just the cited keys. The
listing is sorted based on the order chosen by JabRef engine.
- \cite{} directives are replaced with textual links to the
associated Bibliographic entry.
4. Unnumbered (or Text) Citations with Filtered Bibliography
,
| (setq org-odt-citation-transcoders
| '(org-jabref-odt-citation-reference/text
| . org-jabref-odt-bibliography/unfiltered))
`
- #+BIBLIOGRAPHY is replaced with listing of *all* Bibliographic
entries. The listing is limited to just the cited keys. The
listing is sorted based on the order chosen by JabRef engine.
- \cite{} directives are replaced with textual links to the
associated Bibliographic entry.
5. Add the following line to your Org file and export.
,
| #+BIBLIOGRAPHY: MyLibrary.bib
`
[JabRef] http://jabref.sourceforge.net/
[Chicago Export filters for Org-mode]
http://repo.or.cz/w/JabRefChicagoForOrgmode.git/blob_plain/HEAD:/net.sf.jabref.export.Chicago.ODF(English)-1.2.jar
2 Developer (or Implementation) notes
=
The current #+BIBLIOGRAPHY is defined in contrib/lisp/ox-bibtex.el.
The syntax defined therein, is specific to a particular Citation
Processor (i.e., bibtex2html) and cannot be expected to be honored by
all backends AND citation processors[1].
1. So having a "style" specification in a keyword line that is shared
across all backends is absurd.[2]
2. It is unclear how well a "limit: " option can be honored by *ALL*
citation processor
Re: [O] Standardize #+BIBLIOGRAPHY line
Jambunathan K writes: > Will it go as part of "in text" or will it go in to References list or > both. For command line based processing, I see foresee issues with: > > 1. Multiple keys. > 2. Stuff like "Ibid." > 3. Sort order of keys. > 4. Numbering of entries. To add to that list, will Citation entry be intermixed as a footnote with other regular footnotes.
Re: [O] [PATCH] Enable silent visibility cycling
Thorsten Jolitz writes: > seems to be a bigger project No, it is not. Unless you consider adding these a bigger project. (defvar org-message-level) (defun org-message (level other args) ) s/message/org-message/ at some places. Just to remind to you, I am not the gatekeeper for this project, so what I say is not binding.
Re: [O] Standardize #+BIBLIOGRAPHY line
Nicolas Goaziou writes: > before discussing (again) citations syntax I understand that talking about citations syntax will lead to bike-shedding. Every one - including me - seem to have an (un)informed opinion of it. The intent of the mail - as the subject - says is to 1. To standardize the in buffer syntax for Bibliography based on existing implementations. 2. To check your interest in "faking" a citation-reference object. This is a programmatic interface as opposed to a specific Org syntax. > we must ensure that this is a realistic goal. It is, unless we want the whole earth and sky.
Re: [O] Standardize #+BIBLIOGRAPHY line
I am not sure how many people will read this or make sense out of it. Anyways, here I go. Rasmus writes: > - textcite k :pre x :post y → K (pre, year, post) > - parencite k :p x :post y→ (pre, K, year post) > - cite k :pre x :post y → K pre K year post > - footcite k :pre x :post y → [fn::pre K Year post.] > - citeauthor k :pre x :post y → pre K post > - citeyear k :pre x :post y → pre year post JabRef's command line doesn't take pre and post arguments. Both JabRef and Zotero use LibreOffice application APIs to insert citations. i.e., citations are introduced manually, by hand. But JabRef lets you "translate a key" be it k -> Author(k) or k->Date(k) or k->Author-Date(k) in a "context-free" manner. By "contex free", I mean, it wouldn't bother about whether the key occurs for the first time or whether it occurs for second time (think Ibid) etc. Writing in Org should feel natural. It should be fuzzy but powerful. Specifically, it shouldn't read like Lisp. So having ":pre" and ":post" elements or going extra lengths to get the precise parenthesis (Is it [] or ()?) or the separators (Is it , or ;?) would be an overkill. The immediate requirement should be to create a good enough working draft that can be circulated among peers or sent to the publisher for a professional processing. Parser enhancements or introducing new syntax elements - that are heavy-weight - should be avoided all costs. What is needed is "expressivity" not "extensibility" Pre and Post are inherently positional. So, if one can identify where the middle part is - in all your examples it a Key or f(Key), for some "f" - then identifying a pre and post components should be easy provided the "cite span" is delineated by explicit markup or "natural" boundaries. Approach 1: Delineate a "cite span" using [] Con: Parser enhancement could be non-trivial because it introduces a new Org-syntax delimiter. One can map this, \autocite[59][See also](Becker2010) => See also Becker, 59 to this Org syntax: [See also [cite:Becker2010] 59] Let pre and post occur in natural order but use extra markers to indicate a "span" or a stretch. Approach 2: Delineate using natural boundaries. Con: Parser enhancement is pretty localized just footnote elements. Less bugs and better expressivity. Another variation could be #+BEGIN_SRC org [fn:Becker2010p59] and [fn:Becker2010p503] [fn:Becker2010p59] See also [cite:Becker2010] 59 [fn:Becker2010p503] See also [cite:Becker2010] 503 #+END_SRC Here Becker2010p59 and Becker2010p503 are opaque labels. They could as well be tom and harry, for example. #+BEGIN_SRC org [fn:tom] and [fn:dick] [fn:tom] See also [cite:Becker2010] 59. Some extra note, if the note is to be stored right within Org. [fn:dick] See also [cite:Becker2010] 503 #+END_SRC #+BEGIN_SRC org [fn:tom] and [fn:dick] #+ATTR_?: See also [cite:Becker2010] 59. [fn:tom] Some extra note, if the note is to be stored right within Org. [fn:dick] See also [cite:Becker2010] 503 #+END_SRC Here "the content of an object" is specified using a combination of "label" and "element". The leading sentence/phrase or paragraph of footnote definition, if it contains [cite: ] element, can assumed to specify pre and post. The rest of the sentence or paragraph can be a "note" that augments the specific citation. The [cite:...] elements itself delineates (by virtue of it's position) the pre and post elements. The use of object designated with label + element could be used in conjunction with Image links as well. This is just what ASCII uses to translate links but with a "ATTR_" twist attached to the "labeled paragraph" See [Orgmode Logo] #+ATTR_HTML: Put whatever here. [Orgmode Logo] http://orgmode.org/org-mode-unicorn.png
Re: [O] Standardize #+BIBLIOGRAPHY line
Rasmus writes: > The system should exhibit some flexibility supporting e.g. notes, > parencite (prenote, key, year, postnote) and textcite key (prenote, > year, postnote). But there could be others. E.g. someone mentioned > using DOIs etc. I am not a scholar. I have never used Bibliographies before nor do I foresee that I would have a need for it. If someone is keen, it wouldn't be difficult to compile a common cases of "what" of citation specification. Atleast the minimal that the community itself has used in the past. I want to include year, page, some phrase =>Output should look like this - both in cite Intext & Reference. How the syntax is specified and how it is implemented in Elisp should be left to others. For example, you can create a "bibliography.org" page in Worg (or may be in some other Wiki). You simply record the fact that wrapping of cite fragments is an issue. To make progress, all information should be collected in a manner that someone else can build upon.
[O] Standardize #+BIBLIOGRAPHY line
(Fixed up the subject and CC line.)
As for #+ATTR_BACKEND lines, they *must* be prefixed with the citation
processor's name.
It is unlikely that there will be a convergence of what Org-wide
':citation-style' values are. In that case, they can be converted to
citation-processor specific style.
#+ATTR_LATEX: :bib-style plain
#+ATTR_HTML: :bib2html-style apa
#+ATTR_ODT: :jabref-style chicago-author-date
In ODT case, I translate (latex-frag ...) to (citation-reference )
I have the following defcustom to choose JabRef as the "citation
processor" for ODT backend.
If we standardize on this convention, one can for example choose JabRef
or Zotero as the citation processor for various backends.
(defcustom org-odt-citation-transcoders
'(ox-jabref-citation-reference . ox-jabref-bibliography)
"Transcoders to handle citations."
:type '(choice (const :tag "Don't process citations" nil)
(cons :tag "Citation transcoders"
(function :tag "For \\cite{} fragments" :value
ox-jabref-citation-reference)
(function :tag "For BIBLIOGRAPHY " :value
ox-jabref-bibliography)))
:group 'org-export-odt
:version "24.1")
You *may* want to wrap this aspect in to a tool.
<- The following part is same as earlier message ->
Nicolas
I am finalizing JabRef support for ODT. At *some* future point in time,
I will include ox-jabref.el (and all other patches) in official Emacs
distribution.
Meanwhile, could you standardize the syntax for some `keyword' elements
so that they can be parse with `org-export-read-attribute'.
Currently, I am interested in BIBLIOGRAPHY. You may also want to do the
same for #+toc: lines.
#+ATTR_ODT: :jabref-intext-filter chicago.ODF.text :jabref-reference-filter
chicago.ODF.reference
#+ATTR_HTML: :bib2html-options "-a b -c -d"
#+BIBLIOGRAPHY: :bib-file MyLibrary.bib :citation-style "chicago-note" :limit t
:bib-file will be mandatory. (It is basically the input database, need
not *necessarily* be a .bib file.)
:citation-style will be advisory. Backends may choose to ignore or
honor the style.
:limit t can be supported by ODT via jabref.
You may also want to review the #+TOC settings, more for consistency
than anything else.
Instead of
#+toc: headlines 4
we can have
#+toc: headlines :levels 4
or
#+toc: :type headlines :levels 4
Re: [O] Standardize #+BIBLIOGRAPHY line
Let me state unequivocally that I am willing to co-operate . Nicolas Goaziou writes: > I'm just pointing out two things: > > - ox-bibtex will have to be implemented differently (e.g., no more > defadvices). Citation are "obivously" objects, whatever be their underlying syntax. I am not happy with the defadvices and a recent change to introduce cite links. I feel like puking when I look at "#+BIBLIOGRAPHY" line. So, let's start with standardizing "#+BIBLIOGRAPHY" line. Having a bib file or a bib database would be a good start. > So, it's not just about moving ox-bibtex into another directory. My mails don't make references to "moving ox-bibtex in to another directory" at all. We are talking about standardizing #+BIBLIOGRAPHY line, that is all. I have no other agenda. > - before discussing (again) citations syntax, we must ensure that this > is a realistic goal. IOW we need a proof of concept for, at least, > every major back-end (including ASCII). Ascii should be the easier with JabRef atleast. Ofcourse, interested people should take up issues with JabRef team and sort out issues or clarify what their layout format mean. My intention is to merely show via a prorotype that JabRef seems like a viable citation processor. If you (or someone else) is going to implement Citation processor in elisp itself, it's going to be a bigger effort. Nothing wrong with it. 1. It is wrong to assume ".bib" files as the "only" input database. (Zotero is gaining traction and is apparently well-funded. But the tool itself is not mature.) 2. Org can NEVER be a full-blown document preparation system. It is going to be good enough for pre-prints or for one of sharing of documents. Nothing more. (2) implies that we can as well settle for a "simpler" cite syntax. As I see it, there will be ox-jabref.el, ox-bibtex.el and ox-zotero.el. The responsibility from the ox.el side of things is to merely bless a specific arrangement. The citation processors are not good enough to get in to the core Emacs, but they can definitely be included in GNU ELPA. I insist on Emacs and GNU ELPA not because I earn any brownie points or feeds my pride but because it will ensure the longevity of work and to some extent bitrot-proof-ness.
Re: [O] Standardize #+BIBLIOGRAPHY line
> As expressed elsewhere I think > > [cite:key :pre xxx :post yyy :mycrazykey zzz] > > is the most desirable syntax. Where would the pre, post text would go. Will it go as part of "in text" or will it go in to References list or both. For command line based processing, I see foresee issues with: 1. Multiple keys. 2. Stuff like "Ibid." 3. Sort order of keys. 4. Numbering of entries. > The system should exhibit some flexibility supporting e.g. notes, > parencite (prenote, key, year, postnote) and textcite key (prenote, > year, postnote). But there could be others. E.g. someone mentioned > using DOIs etc. > I'd be willing to put in work on ox-bibliography, although I don't > know if my 'skillz' suffice. This is just escaping :-). You already have some ideas on "what"s and "how"s. You put "what" in "what" and "how" in "how". IME, Confusion, lethargy or escapism starts when "what" gets mixed with "how". "Collection" can happen now. "Processing" can happen later.
Re: [O] [PATCH] Enable silent visibility cycling
Jambunathan K writes: > Thorsten Jolitz writes: > >> seems to be a bigger project > > No, it is not. Unless you consider adding these a bigger project. > > (defvar org-message-level) > > (defun org-message (level other args) > > > ) > > s/message/org-message/ at some places. > > Just to remind to you, I am not the gatekeeper for this project, so what > I say is not binding. Looks good, better than doing isolated local patches. -- cheers, Thorsten
Re: [O] [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Dear Eric, please find attached a patch, to describe the different standard values for system-wide header arguments in the manual. Hope that might help to avoid confusion in the future. All the best Torsten On 25 July 2013 00:30, Eric Schulte wrote: > Torsten Wagner writes: > > > Hi Rick, Hi Sebastien, > > > > thanks for your inputs. > > Well I guess Sebastien is half-right. The different settings make at > least > > it even more tricky to see what is going on. > > Here is a table with the settings as I found them on my system (which I > did > > not change) > > > > #+BEGIN_ORG > > > > | org-babel-default-header-args| ((:session . "none") (:results . > > "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . > > "no") (:tangle . "no") (:padnewline . "yes")) | > > | org-babel-default-lob-header-args| ((:exports . > > "results")) > > | > > | org-babel-default-inline-header-args | ((:session . "none")(:results . > > "replace")(:exports . > > "results")) > > | > > > > #+END_ORG > > > > As you can see the most prominent cause for trouble might be :hlines > > As Rick should in his message it does still not solve all problems but it > > helps to make it more clear. > > > > This is related to > http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175. > > > > > I assume Eric is on holiday or otherwise busy but I guess he will find > this > > thread and might can give us some idea, whether there was an intention in > > dealing with tables in that way or whether it is really considered as a > bug. > > > > Yes, I've been very busy. > > > > > However, Sebastian pointed out a very important fact. Different default > > settings for different ways of calling a source code block. I believe > that > > this should find its way into the manual. > > > > I'm happy to apply patches to the manual. > > > > > All the best > > > > Torsten > > > > > > > > > > On 22 July 2013 13:20, Torsten Wagner wrote: > > > >> Hi, > >> > >> I want to summarize the problem I found, using tables as input to source > >> code blocks. > >> This observation was shared with Rick and I would be glad to help fixing > >> that. > >> > >> Within the attached file one can see a typical example. > >> > >> It all comes down to a differently interpretation of tables with > respect > >> to horizontal line. > >> > >> #+TBLNAME: with-hline > >> | A | B | C | > >> |---+---+---| > >> | 1 | 2 | 3 | > >> | X | Y | Z | > >> > >> and > >> > >> #+TBLNAME: without-hline > >> | A | B | C | > >> | 1 | 2 | 3 | > >> | X | Y | Z | > >> > >> will give different results being called by > >> > >> #+name: python-element > >> #+begin_src python :var table=with-hline :exports results > >> return table[1] > >> #+end_src > >> > >> or > >> > >> #+CALL: python-echo(with-hline) > >> > >> Please see the attached file for details. > >> > >> From what I was able to observe: > >> > >> 1. Calling a table with hline, the result of the source code block miss > >> the first row. Indexing is possible only for the second and third row > (in > >> the given example) > >> > >> 2. Having no hline, the first row is available, indexing of the first > row > >> works too. > >> > >> Using a Call construct: > >> 1. for a table without hline, indexing works but it does not work for a > >> table with hline. > >> 2. Interestingly, using the CALL functions, the type of both tables in > >> python is list for the entire table, however, indexing a table with > hlines, > >> the type becomes NoneType whereas for a table without hline it is still > of > >> type list. > >> > >> > >> Hope that can somehow help to get an idea what is going on. > >> > >> > >> Greetings > >> > >> Torsten > >> > >> > >> > >> > >> > >> > > -- > Eric Schulte > http://cs.unm.edu/~eschulte > babel_standard_header_settings_doc.patch Description: Binary data
Re: [O] [babel] feature request: debug messages
> > This helps a lot. Thanks! Happy this worked out. > Now, I will this into all my org files. > Check out the library of babel of things that you want to have globally available. Best, > > Cheers, > Andreas > > > > -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Torsten Wagner writes: > Dear Eric, > > please find attached a patch, to describe the different standard values for > system-wide header arguments in the manual. > Hope that might help to avoid confusion in the future. > > All the best > Thanks for sending this along. Would you mind making two small changes? 1. Format the patch by first committing it to your local git repo, and then generating the patch with "git format-patch -o /tmp/ HEAD~1", which will write the patch to your /tmp/ directory. That way it will easily apply (this version does not apply for me). Also, please put the string TINYCHANGE in your commit message, because the patch is small and you haven't signed the FSF papers. see http://orgmode.org/worg/org-contribute.html 2. I we shouldn't put the actual values in the manual, as they will likely change in the code at some point, and then the manual and code will be incomplete. The values of any emacs variable are easily looked up, either with elisp or through the customization interface. Thanks, > > Torsten > > > On 25 July 2013 00:30, Eric Schulte wrote: > >> Torsten Wagner writes: >> >> > Hi Rick, Hi Sebastien, >> > >> > thanks for your inputs. >> > Well I guess Sebastien is half-right. The different settings make at >> least >> > it even more tricky to see what is going on. >> > Here is a table with the settings as I found them on my system (which I >> did >> > not change) >> > >> > #+BEGIN_ORG >> > >> > | org-babel-default-header-args| ((:session . "none") (:results . >> > "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . >> > "no") (:tangle . "no") (:padnewline . "yes")) | >> > | org-babel-default-lob-header-args| ((:exports . >> > "results")) >> > | >> > | org-babel-default-inline-header-args | ((:session . "none")(:results . >> > "replace")(:exports . >> > "results")) >> > | >> > >> > #+END_ORG >> > >> > As you can see the most prominent cause for trouble might be :hlines >> > As Rick should in his message it does still not solve all problems but it >> > helps to make it more clear. >> > >> >> This is related to >> http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175. >> >> > >> > I assume Eric is on holiday or otherwise busy but I guess he will find >> this >> > thread and might can give us some idea, whether there was an intention in >> > dealing with tables in that way or whether it is really considered as a >> bug. >> > >> >> Yes, I've been very busy. >> >> > >> > However, Sebastian pointed out a very important fact. Different default >> > settings for different ways of calling a source code block. I believe >> that >> > this should find its way into the manual. >> > >> >> I'm happy to apply patches to the manual. >> >> > >> > All the best >> > >> > Torsten >> > >> > >> > >> > >> > On 22 July 2013 13:20, Torsten Wagner wrote: >> > >> >> Hi, >> >> >> >> I want to summarize the problem I found, using tables as input to source >> >> code blocks. >> >> This observation was shared with Rick and I would be glad to help fixing >> >> that. >> >> >> >> Within the attached file one can see a typical example. >> >> >> >> It all comes down to a differently interpretation of tables with >> respect >> >> to horizontal line. >> >> >> >> #+TBLNAME: with-hline >> >> | A | B | C | >> >> |---+---+---| >> >> | 1 | 2 | 3 | >> >> | X | Y | Z | >> >> >> >> and >> >> >> >> #+TBLNAME: without-hline >> >> | A | B | C | >> >> | 1 | 2 | 3 | >> >> | X | Y | Z | >> >> >> >> will give different results being called by >> >> >> >> #+name: python-element >> >> #+begin_src python :var table=with-hline :exports results >> >> return table[1] >> >> #+end_src >> >> >> >> or >> >> >> >> #+CALL: python-echo(with-hline) >> >> >> >> Please see the attached file for details. >> >> >> >> From what I was able to observe: >> >> >> >> 1. Calling a table with hline, the result of the source code block miss >> >> the first row. Indexing is possible only for the second and third row >> (in >> >> the given example) >> >> >> >> 2. Having no hline, the first row is available, indexing of the first >> row >> >> works too. >> >> >> >> Using a Call construct: >> >> 1. for a table without hline, indexing works but it does not work for a >> >> table with hline. >> >> 2. Interestingly, using the CALL functions, the type of both tables in >> >> python is list for the entire table, however, indexing a table with >> hlines, >> >> the type becomes NoneType whereas for a table without hline it is still >> of >> >> type list. >> >> >> >> >> >> Hope that can somehow help to get an idea what is going on. >> >> >> >> >> >> Greetings >> >> >> >> Torsten >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Eric Schulte >> http://cs.unm.edu/~eschulte >> > > diff --git a/doc/org.texi b/doc/org.texi > index 55c421d..d8987d6 100644 > --- a/doc/org.texi > +++ b/doc/org.texi > @@ -14066,6 +14066,16 @@ blocks. > (assq-delete-all :noweb org-babel-default-header-a
Re: [O] #+header keywords for #+call keyword?
I don't believe there are any restrictions on the number of header lines before a code block. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] feature request: debug messages
Hi Eric, Eric Schulte writes: >> >> This helps a lot. Thanks! > > Happy this worked out. > >> Now, I will this into all my org files. >> > > Check out the library of babel of things that you want to have globally > available. Thanks for the hint. If I put it there, I still have to #+call it from every org file, correct? Regards, Andreas
Re: [O] [babel] feature request: debug messages
Andreas Leha writes: > Hi Eric, > > Eric Schulte writes: > >>> >>> This helps a lot. Thanks! >> >> Happy this worked out. >> >>> Now, I will this into all my org files. >>> >> >> Check out the library of babel of things that you want to have globally >> available. > > Thanks for the hint. If I put it there, I still have to #+call it from > every org file, correct? > Sorry, ignore the library of babel, you can just add that function definition to your .emacs. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Sorry for breaking the thread, i deleted the prior message. On 2013-07-23 08:25, Sebastien Vauban wrote: See the contents of the following vars: - `org-babel-default-header-args' for source blocks - `org-babel-default-inline-header-args' for inline source blocks - `org-babel-default-lob-header-args' for `#+call' lines Tracing through the function `org-babel-lob-execute', it seems that `org-babel-default-lob-header-args' are not actually referenced or used, but the variable `org-babel-default-header-args:emacs-lisp' (default to `((:hlines . "yes") (:colnames . "no"))') is. `org-babel-default-lob-header-args' is only reference in the function `org-babel-exp-non-block-element' (used for export only), so i don't think it actually has any effect. So, given the above, and the following example: #+name: test #+BEGIN_SRC emacs-lisp "foo" #+END_SRC #+call: test() the complete list of header arguments for the call line are: #+BEGIN_EXAMPLE (:comments . #1="") (:shebang . #1#) (:cache . "no") (:padline . #1#) (:noweb . "no") (:tangle . "no") (:exports . "results") (:results . "replace") (:var . "results=test()") (:colnames . "no") (:hlines . "yes") (:padnewline . "yes") (:session . "none") #+END_EXAMPLE rick
[O] using a simple numerical variable in an org text ocument
Hi, I'm making a very simple org-document -- a packing list for a trip. It has entries like - 4 mugs - for sleeping bags - 4 thermarest pads I'd like to replace the numbers there by a variable -- so if I make a list for 4 people, the number displayed will be '4'; but if the list is for 2 people, the number displayed will be 2. Better would be if I could also do simple arithmetic manipulations (x * 6 dinners for a week...). I there a really simple way to do this? if it's not really easy, it won't really seem worth it, but if it is really easy, I will use it a lot... Thanks guys! Matt
[O] "ignoreheading" for non-beamer export
Hi, I found an inventive solution by Suvayu to discard headlines from export here [1], but the 8.0+ solution throws an error in my environment. (defun sa-ignore-headline (contents backend info) "Ignore headlines with tag `ignoreheading'." (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii) (string-match "\\`.*ignoreheading.*\n" (downcase headline))) (replace-match "" nil nil headline))) (add-to-list 'org-export-filter-headline-functions 'sa-ignore-headline) --> string-match: Symbol's value as variable is void: headline It seems it should actually be: (defun sa-ignore-headline (contents backend info) "Ignore headlines with tag `ignoreheading'." (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii) (string-match "\\`.*ignoreheading.*\n" (downcase contents))) (replace-match "" nil nil contents))) (add-to-list 'org-export-filter-headline-functions 'sa-ignore-headline) I'm not allowed to reply to the answer on stackexchange, so I'm posting here. Thanks. hjh [1] http://stackoverflow.com/questions/10295177/is-there-an-equivalent-of-org-modes-b-ignoreheading-for-non-beamer-documents
[O] [babel] transfer a list of tables to a source code block
Hi, I have a few functions defined with babel, which need to work on an list of tables. At the moment I use something like :var table1= :var table2= etc. As you can see this is rather inflexible. I am looking for a way to receive a list of tables, whereas table[0] would refer to the first table, etc. Does someone know how to achieve this? To make the best use of both worlds, I thought it would be nice to define a list which contains the names of the tables and somehow manage to access the tables from this list. #+NAME: listoftables - name1 - name2 - name3 #+CALL: myfunction(lst=listoftables) I tried to play around with this idea but did not get a solution yet For the moment I receive the names of the tables only as a string and search for ways to actually transfer the table itself. Thanks for ideas and thoughts... Torsten
Re: [O] Encoding Problem in export?
Hello, David Maus writes: > IIRC org-link-escape is not used to create URLs but to escape > characters in a link that would otherwise conflict with Orgmode syntax > (e.g. square brackets). > Org applies percent escaping to a link before > it is stored in the buffer and applies unescaping when it reads a link > back. > > The percent sign is hardcoded because if org-link-escape/unescape is > used in this way we must make sure that the identity of a link is > preserved. If we would *not* escape the percent sign, then an original > link with percent encoded characters would be read back wrongly, > i.e. with the percent escaped characters unescaped. [...] > There is, of course, the nasty thing that we don't know if the link in > a buffer went through org-link-escape or not. E.g. if you paste > > , > | > [[http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml]] > ` > > into the buffer you'll get a broken link because org-link-open assumes > the link to be escaped by org. > > The bottom-line: Org creates link programmatically (org-store-link) > and needs a mechanism to protected conflicting characters. It chose > percent-escaping and in order to preserve the identity of a link Org > has to escape the escape-character. > > Hope that helps! It does. I think we are hunting two hares and that's why we are failing so far. There are two URI transformations involved. One is mandatory (escape square brackets in URI), and the other one is optional (normalize URI for external processes consumption). The former must be bi-directional, as escaping brackets must be transparent to the user (e.g., when editing a link with `org-insert-link'). The latter needn't and can happen on the fly, just before the URI is sent to whatever needs it (e.g., a browser). Therefore, I suggest to use three functions: - `org-link-escape will first %-escape "%" characters, and then "[" and "]" characters. `org-link-unescape' will reverse the operation. These function cannot break a link, encoded or not. They are applied when a link is created programmatically and read back for user editing. - `org-link-encode'[1] will %-escape every forbidden character in the URI. It doesn't need any "reverse" function. It will be called when opening a link, or parsing it. I think it shouldn't escape "%" characters, though, so that it can be applied on both encoded and plain strings. Since it isn't perfect (it doesn't parse URI), it should also be very conservative (i.e. allow more characters such as "=" or "&") and not get in the way. WDYT? Regards, [1] `url-encode-url' was introduced in Emacs 24.3. It is too young to be used mainstream, even though it does a better job than `org-link-escape'. We will benefit from it when Emacs 25 is out (i.e. when Emacs 23 support is dropped). -- Nicolas Goaziou
[O] Bug: koma-letter-export does not work [8.0.6 (8.0.6-5-gb4a8ec-elpa @ /home/stefan/.emacs.d/elpa/org-20130722/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
I tried the recipe on this site:
http://orgmode.org/worg/exporters/koma-letter-export.html
C-c C-e gives the following error message:
Debugger entered--Lisp error: (error "org-export-backend-menu accessing a
non-org-export-backend")
signal(error ("org-export-backend-menu accessing a non-org-export-backend"))
error("%s accessing a non-%s" org-export-backend-menu org-export-backend)
byte-code("\305.\211.\203. \n@.\306
\"\203. \307\301\305\"\210\nA\211.\204.*\310 !\2034. G\311Y\2034. \312H\f>\204:.\313\314\315\316#\210 \317H\207"
[org-export-invisible-backends ignored --dolist-tail-- name
cl-struct-org-export-backend-tags nil org-export-derived-backend-p throw
vectorp 8 0 error "%s accessing a non-%s" org-export-backend-menu
org-export-backend 7] 5)
#[(b) "@.\302\303\215)\207" [b name ignored (byte-code
"\305.\211.\203. \n@.\306
\"\203. \307\301\305\"\210\nA\211.\204.*\310 !\2034. G\311Y\2034. \312H\f>\204:.\313\314\315\316#\210 \317H\207"
[org-export-invisible-backends ignored --dolist-tail-- name
cl-struct-org-export-backend-tags nil org-export-derived-backend-p throw
vectorp 8 0 error "%s accessing a non-%s" org-export-backend-menu
org-export-backend 7] 5)] 2]((latex :translate-alist ((bold . org-latex-bold)
(center-block . org-latex-center-block) (clock . org-latex-clock) (code .
org-latex-code) (comment lambda (&rest args) "") (comment-block lambda (&rest
args) "") (drawer . org-latex-drawer) (dynamic-block . org-latex-dynamic-block)
(entity . org-latex-entity) (example-block . org-latex-example-block)
(export-block . org-latex-export-block) (export-snippet .
org-latex-export-snippet) (fixed-width . org-latex-fixed-width)
(footnote-definition . org-latex-footnote-definition) (footnote-reference .
org-latex-footnote-reference) (headline . org-latex-headline) (horizontal-rule
. org-latex-horizontal-rule) (inline-src-block . org-latex-inline-src-block)
(inlinetask . org-latex-inlinetask) (italic . org-latex-italic) (item .
org-latex-item) (keyword . org-latex-keyword) (latex-environment .
org-latex-latex-environment) (latex-fragment . org-latex-latex-fragment)
(line-break . org-latex-line-break) (link . org-latex-link) (paragraph .
org-latex-paragraph) (plain-list . org-latex-plain-list) (plain-text .
org-latex-plain-text) (planning . org-latex-planning) (property-drawer lambda
(&rest args) "") (quote-block . org-latex-quote-block) (quote-section .
org-latex-quote-section) (radio-target . org-latex-radio-target) (section .
org-latex-section) (special-block . org-latex-special-block) (src-block .
org-latex-src-block) (statistics-cookie . org-latex-statistics-cookie)
(strike-through . org-latex-strike-through) (subscript . org-latex-subscript)
(superscript . org-latex-superscript) (table . org-latex-table) (table-cell .
org-latex-table-cell) (table-row . org-latex-table-row) (target .
org-latex-target) (template . org-latex-template) (timestamp .
org-latex-timestamp) (underline . org-latex-underline) (verbatim .
org-latex-verbatim) (verse-block . org-latex-verse-block)) :options-alist
((:latex-class "LATEX_CLASS" nil org-latex-default-class t)
(:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t) (:latex-header
"LATEX_HEADER" nil nil newline) (:latex-header-extra "LATEX_HEADER_EXTRA" nil
nil newline) (:latex-hyperref-p nil "texht" org-latex-with-hyperref t) (:date
"DATE" nil "\\today" t)) :menu-entry (108 "Export to LaTeX" ((76 "As LaTeX
buffer" org-latex-export-as-latex) (108 "As LaTeX file"
org-latex-export-to-latex) (112 "As PDF file" org-latex-export-to-pdf) (111 "As
PDF file and open" (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b)
(org-open-file (org-latex-export-to-pdf nil s v b)
mapcar(#[(b) "@.\302\303\215)\207" [b name ignored (byte-code
"\305.\211.\203. \n@.\306
\"\203. \307\301\305\"\210\nA\211.\204.*\310 !\2034. G\311Y\2034. \312H\f>\204:.\313\314\315\316#\210 \317H\207"
[org-export-invisible-backends ignored --dolist-tail-- name
cl-struct-org-export-backend-tags nil org-export-derived-backend-p throw
vectorp 8 0 error "%s accessing a non-%s" org-export-backend-menu
org-export-backend 7] 5)] 2] ((latex :translate-alist ((bold . org-latex-bold)
(center-block . org-latex-center-block) (clock . org-latex-clock) (code .
org-latex-code) (comment lambda (&rest args) "") (comment-block lambda (&rest
args) "") (drawer . org-latex-drawer) (dynamic-block . org-latex-dynamic-block)
(entity . org-latex-entity) (example-block . org-latex-example-block)
(export-block . org-latex-export-block) (export-snippet .
org-latex-export-snippet) (fixed-width . org-latex-fixed-width)
(foo
Re: [O] using a simple numerical variable in an org text ocument
Matt Price writes: > Hi, > > I'm making a very simple org-document -- a packing list for a trip. > It has entries like > > - 4 mugs > - for sleeping bags > - 4 thermarest pads > > > I'd like to replace the numbers there by a variable -- so if I make a > list for 4 people, the number displayed will be '4'; but if the list > is for 2 people, the number displayed will be 2. Better would be if I > could also do simple arithmetic manipulations (x * 6 dinners for a > week...). I there a really simple way to do this? if it's not really > easy, it won't really seem worth it, but if it is really easy, I will > use it a lot... Use a table with a named reference, e.g. stored as subtree property. See [[http://orgmode.org/org.html#The-spreadsheet][Spreadsheets]]. , | * My Trip | :PROPERTIES: | :people: 4 | :END: | | | item | factor | total | | |++---| | | toothbrush | 1 | 4 | | | socks | 4 |16 | | #+TBLFM: $3=$2*$PROP_people ` -- cheers, Thorsten
[O] Finding LAST copy of a given headline in a file
So I've been working on this issue, & still don't have it quite worked out like I would want. What I would like to do is either) Have template that inserts itself under the LAST entry in the target file for a given headline OR composes the right strings to use file+olp to find the specific headline under the current date's date-tree heading. For example, I have a date tree with Ticket X under each of several days, including today's date. I want to insert an entry * What I did today with some additional information under Ticket X for today. * 2013 ** 2013-07-25 *** 2013-07-24 Wednesday Ticket X * LOG ticket X stuff for Wednesday *** 2013-07-25 Thursday Ticket X * LOG ticket X stuff Ticket Y ** Log ticket y stuff Any pointers? -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] Finding LAST copy of a given headline in a file
Hello Subhan, On Thu, Jul 25, 2013 at 03:29:10PM -0700, Subhan Tindall wrote: > Have template that inserts itself under the LAST entry in the target file > for a given headline What problem do you have with the above? Can you give us a minimal example? > composes the right strings to use file+olp to find the specific headline > under the current date's date-tree heading. > For example, I have a date tree with Ticket X under each of several > days, including today's date. > I want to insert an entry * What I did today with some additional > information under Ticket X for today. > > * 2013 > ** 2013-07-25 > *** 2013-07-24 Wednesday > Ticket X > * LOG ticket X stuff for Wednesday > *** 2013-07-25 Thursday > Ticket X > * LOG ticket X stuff > Ticket Y > ** Log ticket y stuff Date trees can be tricky. As far as I understand, you want to add a subheading to entries for a day. I do not think file+datetree can do that. I would recommend you try file+function instead. It should be easy to implement. You could use org-map-entries to find the headline in your headline finding function. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] Finding LAST copy of a given headline in a file
Yes, you are correct, file+datetree does not do this. A while ago I suggested a file+datetree+headline type function be added, but it was not received well. I attempted a function for use with file+function, but couldn't get it quite working. I'm not quite sure how to use org-map-entries to find headlines? Thanks! Subhan On Thu, Jul 25, 2013 at 3:51 PM, Suvayu Ali wrote: > Hello Subhan, > > On Thu, Jul 25, 2013 at 03:29:10PM -0700, Subhan Tindall wrote: > > Have template that inserts itself under the LAST entry in the target file > > for a given headline > > What problem do you have with the above? Can you give us a minimal > example? > > > composes the right strings to use file+olp to find the specific headline > > under the current date's date-tree heading. > > For example, I have a date tree with Ticket X under each of several > > days, including today's date. > > I want to insert an entry * What I did today with some additional > > information under Ticket X for today. > > > > * 2013 > > ** 2013-07-25 > > *** 2013-07-24 Wednesday > > Ticket X > > * LOG ticket X stuff for Wednesday > > *** 2013-07-25 Thursday > > Ticket X > > * LOG ticket X stuff > > Ticket Y > > ** Log ticket y stuff > > Date trees can be tricky. As far as I understand, you want to add a > subheading to entries for a day. I do not think file+datetree can do > that. I would recommend you try file+function instead. It should be > easy to implement. You could use org-map-entries to find the headline > in your headline finding function. > > Hope this helps, > > -- > Suvayu > > Open source is the future. It sets us free. > > -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] using a simple numerical variable in an org text ocument
Matt Price writes: > Hi, > > I'm making a very simple org-document -- a packing list for a trip. > It has entries like > > - 4 mugs > - for sleeping bags > - 4 thermarest pads > > > I'd like to replace the numbers there by a variable -- so if I make a > list for 4 people, the number displayed will be '4'; but if the list > is for 2 people, the number displayed will be 2. Better would be if I > could also do simple arithmetic manipulations (x * 6 dinners for a > week...). I there a really simple way to do this? if it's not really > easy, it won't really seem worth it, but if it is really easy, I will > use it a lot... Or, if you insist on checkboxes (private conversation), you might put this function in your .emacs and run it to replace all numbers (that are either factors or totals) with num * people (when people >= 0) or with num / people (when people > 0). #+begin_src emacs-lisp (defun tj/calc-total-items (people) "Replace factor cookies with factor * people totals." (interactive "NPeople: ") (save-excursion (save-restriction (save-match-data (goto-char (point-min)) (widen) (while (not (eobp)) (and (org-at-item-checkbox-p) (looking-at (concat "\\(^[[:space:]]*-[[:space:]]" "\\[[-X\s]\\][[:space:]]\\)" "\\([[:digit:]]+\\)\\([[:space:]]+\\)")) (let* ((num (string-to-number (match-string-no-properties 2))) (total (if (>= people 0) (* num people) (/ num (abs people) (replace-match (format "%s" total) nil nil nil 2))) (forward-line)) #+end_src #+results: : tj/calc-total-items Use either as ,-- | M-x tj/calc-total-items RET 7 RET `-- or ,-- | C-7 M-x tj/calc-total-items RET `-- in your org-buffer. When there are e.g. 7 people, this checkbox list - [ ] 1 toothbrushes - [ ] 4 socks turns into - [ ] 7 toothbrushes - [ ] 28 socks after applying the above command in this buffer, and the change is reversed when applying ,-- | M-x tj/calc-total-items RET -7 RET `-- or ,-- | C--7 M-x tj/calc-total-items RET `-- afterwards. Note that you must stick to the format ,-- | - [ ] <> text `-- for this to work. -- cheers, Thorsten
Re: [O] using a simple numerical variable in an org text ocument
Hi,
Thorsten Jolitz writes:
> Matt Price writes:
>
>> Hi,
>>
>> I'm making a very simple org-document -- a packing list for a trip.
>> It has entries like
>>
>> - 4 mugs
>> - for sleeping bags
>> - 4 thermarest pads
>>
>>
>> I'd like to replace the numbers there by a variable -- so if I make a
>> list for 4 people, the number displayed will be '4'; but if the list
>> is for 2 people, the number displayed will be 2. Better would be if I
>> could also do simple arithmetic manipulations (x * 6 dinners for a
>> week...). I there a really simple way to do this? if it's not really
>> easy, it won't really seem worth it, but if it is really easy, I will
>> use it a lot...
>
> Or, if you insist on checkboxes (private conversation), you might put this
> function in your .emacs and run it to replace all numbers (that are either
> factors or totals) with num * people (when people >= 0) or with num / people
> (when people > 0).
>
If you want to use checkboxes, couldn't you use a babel code block and
then =call= it on each entry?
#+begin_src org
,#+MACRO: count call_Sample(x=$1)[:results raw]
,* Test
:PROPERTIES:
:var: people=5
:END:
- [ ] call_Sample(x=2)[:results raw] socks
- [ ] call_Sample(x=1)[:results raw] toothbrushes
- [ ] {{{count(3)}}} shoes
,#+name: Sample
,#+header: :var x=1 :results raw
,#+begin_src emacs-lisp
(* x people)
,#+end_src
,#+RESULTS: Sample
5
#+end_src
You can then wrap it in a macro to avoid having to write out quite as
much per line (as the last entry demonstrates.
Then just adjust the value of the =:var:= property to match how many
people, and your export will provide the correct values
> #+begin_src emacs-lisp
> (defun tj/calc-total-items (people)
> "Replace factor cookies with factor * people totals."
> (interactive "NPeople: ")
> (save-excursion
> (save-restriction
> (save-match-data
> (goto-char (point-min))
> (widen)
> (while (not (eobp))
> (and (org-at-item-checkbox-p)
> (looking-at
> (concat
>"\\(^[[:space:]]*-[[:space:]]"
>"\\[[-X\s]\\][[:space:]]\\)"
>"\\([[:digit:]]+\\)\\([[:space:]]+\\)"))
> (let* ((num
> (string-to-number
> (match-string-no-properties 2)))
> (total
> (if (>= people 0)
> (* num people)
>(/ num (abs people)
>(replace-match
> (format "%s" total) nil nil nil 2)))
> (forward-line))
> #+end_src
>
> #+results:
> : tj/calc-total-items
>
>
> Use either as
>
> ,--
> | M-x tj/calc-total-items RET 7 RET
> `--
>
> or
>
> ,--
> | C-7 M-x tj/calc-total-items RET
> `--
>
> in your org-buffer.
>
> When there are e.g. 7 people, this checkbox list
>
> - [ ] 1 toothbrushes
> - [ ] 4 socks
>
> turns into
>
> - [ ] 7 toothbrushes
> - [ ] 28 socks
>
> after applying the above command in this buffer, and the change is
> reversed when applying
>
> ,--
> | M-x tj/calc-total-items RET -7 RET
> `--
>
> or
>
> ,--
> | C--7 M-x tj/calc-total-items RET
> `--
>
> afterwards. Note that you must stick to the format
>
> ,--
> | - [ ] <> text
> `--
>
> for this to work.
Regards,
--
Jonathan
Re: [O] Encoding Problem in export?
At Thu, 25 Jul 2013 23:46:34 +0200, Nicolas Goaziou wrote: > > Hello, > > David Maus writes: > > > > > The bottom-line: Org creates link programmatically (org-store-link) > > and needs a mechanism to protected conflicting characters. It chose > > percent-escaping and in order to preserve the identity of a link Org > > has to escape the escape-character. > > > > Hope that helps! > > It does. > > I think we are hunting two hares and that's why we are failing so far. > > > There are two URI transformations involved. One is mandatory (escape > square brackets in URI), and the other one is optional (normalize URI > for external processes consumption). The former must be bi-directional, > as escaping brackets must be transparent to the user (e.g., when editing > a link with `org-insert-link'). The latter needn't and can happen on the > fly, just before the URI is sent to whatever needs it (e.g., a browser). > > Therefore, I suggest to use three functions: > > - `org-link-escape will first %-escape "%" characters, and then "[" > and "]" characters. `org-link-unescape' will reverse the operation. > > These function cannot break a link, encoded or not. They are applied > when a link is created programmatically and read back for user > editing. It's not just square brackets, but also non-ascii characters. Consider a link that contains UTF-8 encoded characters and is inserted into a Org buffer encoded in ISO-8859-1. Oh, and: ASCII controll characters. A link description with newlines. Obviously changing the algorithm of org-link-escape/unescape also creates a BC-issue. > > - `org-link-encode'[1] will %-escape every forbidden character in the > URI. It doesn't need any "reverse" function. It will be called when > opening a link, or parsing it. > > I think it shouldn't escape "%" characters, though, so that it can > be applied on both encoded and plain strings. Since it isn't perfect > (it doesn't parse URI), it should also be very conservative (i.e. > allow more characters such as "=" or "&") and not get in the way. You would have to select the list of forbidden characters based on the link protocol. The assumption underlying the current implementation is to delegate dealing with forbidden characters to the consuming application. Thus I would limit this to known URI protocols, i.e. http: and https:. Best, -- David > > WDYT? > > > Regards, > > [1] `url-encode-url' was introduced in Emacs 24.3. It is too young to be > used mainstream, even though it does a better job than > `org-link-escape'. We will benefit from it when Emacs 25 is out (i.e. > when Emacs 23 support is dropped). > > -- > Nicolas Goaziou -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de
