Re: [O] bug with org-clone-subtree-with-time-shift?
Hi Ingmar, Ingmar Meissner writes: > it seems to me that "org-clone-subtree-with-time-shift" is not > working correct with org-mode 8.0. Usually i could specify a time > shift, but not anymore. Did i miss something? David explanations are correct, but your email made me think I've been too heavy-handed with this change. It makes more sense to skip the time-shift prompt when there is no time-stamp and to have it by default when there is a time-stamp. So this is now how the command behaves. And when called with C-u, it will skip the time-shift prompt unconditionally. Thanks for bringing this up! -- Bastien
Re: [O] Can't Sort with New, 8.0 Sort Methods
Hi Richard, Richard Lawrence writes: > And mentioned a fix that works for me here: > http://article.gmane.org/gmane.emacs.orgmode/70893 I applied your fix, thanks a lot for it! -- Bastien
Re: [O] Bug: org-refresh-category-properties: Invalid function: org-with-silent-modifications [8.0 (8.0-3-g7248fb-elpaplus @ /home/gcharron/.emacs.d/elpa/org-plus-contrib-20130418/)]
Hi Gilles, Gilles Charron writes: > Can't display agenda or sparse tree on org 8.0; (installed via elpa) always > reporting: > > org-indent-add-properties: Invalid function: org-with-silent-modifications You probably hit the famous ELPA installation bug, which is mentioned early in the 8.0 release notes. When installing from ELPA, please do so from a fresh Emacs session where no Org function has been called. If you still have the bug, please consider using the .tar.gz distribution instead. -- Bastien
Re: [O] Does Org support Related or "See Also" Properties?
Hi Nick, Nick M. Daly writes: > When exported into an agenda, the consolidated org agenda would read: > > Friday 19 April 2013 > customer: 09:00-09:30 Scheduled: TODO Meeting with Pete > > Are these wild dreams just dreams, or does Org Mode support such lovely > magic? The problem is: what would RET do on this agenda line? Go to which entry? You can always put some hacks in `org-agenda-finalize-hook' but it's easier to try to keep your Org files clean ;) -- Bastien
Re: [O] [babel] Purpose of :results raw
Hello Nicolas,
Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>
>> Now that ":results drawer" has been introduced, I wonder why we still have
>> ":results raw".
>>
>> As once stated in this ML:
>>
>> The sole purpose of raw results is to allow inserting an headline (I
>> mean a real headline, not comma protected) in the buffer, because
>> headlines cannot be contained in anything else than headlines.
>>
>> But drawer does the same.
>
> What makes you think drawers do the same?
The fact that the following output a normally behaving headline[1], AFAICS.
--8<---cut here---start->8---
#+begin_src sh :results drawer :exports both
echo "* Unescaped headline"
#+end_src
#+results:
:RESULTS:
* Unescaped headline
:END:
--8<---cut here---end--->8---
Though, effectively, when exported, it's not right:
--8<---cut here---start->8---
\lstset{language=sh,numbers=none}
\begin{lstlisting}
echo "* Unescaped headline"
\end{lstlisting}
:RESULTS:
\section*{Unescaped headline}
\label{sec-7}
:END:
--8<---cut here---end--->8---
as ":RESULTS:" and ":END:" words aren't removed from the export.
> Drawers cannot contain headlines.
Do you mean it, because of the wrong export? By wrong, I don't mean "buggy",
but "not foreseen as I (= me) thought".
Best regards,
Seb
[1] Correct face used in the Org buffer, correct folding when TAB'ing, etc.
--
Sebastien Vauban
Re: [O] ox-taskjuggler : Correct a small typo and deal with Scheduled and deadline in task
Hi Baptiste, Baptiste writes: > hereafter a small typo correction, plus the capability to use DEADLINE: > and SCHEDULED: in task (special export format for milestones). I applied the code typo fix, thanks! http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=774b53 As for the other part, I'll let Christian review/apply it. If you can, send this change as a git commit with git format-patch, with a proper changelog, that's far easier for the reviewer. See http://orgmode.org/worg/org-contribute.html#sec-4-2 Best, -- Bastien
Re: [O] New exporter and defgroup
Hi, yes, this *is* a problem. Suvayu Ali writes: > Can we have some sort of a check while loading Org that picks up these > shadowed variables and "deletes" them? I think Achim has been thinking about some incantation for this (at install time). Maybe if this can be done after installation, we could document it somewhere... not really sure. I didn't want to change defgroup, it would have been confusing to have to groups for the same purpose -- with no real clue on which one was the most recent one. -- Bastien
Re: [O] APPT_WARNTIME not honored anymore in 8.0
April, 19 at 19:48 Bastien wrote: >> I should get a notice 17mn before 20:00 that I need to go to karaoke. >> Now it does the default 90mn. It's a regression. > > I can't reproduce this -- I assume you added the appointment with > `org-agenda-to-appt', right? AFAIK yes. I might have time next week to investigate. -- It's the InterNIC's fault. -- BOFH excuse #3
Re: [O] New exporter and defgroup
Bastien writes: >> Can we have some sort of a check while loading Org that picks up these >> shadowed variables and "deletes" them? > > I think Achim has been thinking about some incantation for this > (at install time). Maybe if this can be done after installation, > we could document it somewhere... not really sure. It would have to be done each time Org is loaded. Unfortunately Emacs doesn't provide an interface for removing such definitions, so you'd have to traverse a number of not-too-well documented data structures to get rid of them. I'm still not sure I found all of these nor if there are adverse effects of doing that. Eric Frage (IIRC) was testing a rough version of what I was trying to do, he reported he was seeing problems that he wanted to investigate further. Now, with the dust from all the other changes settling, we might pick up where we left before: --8<---cut here---start->8--- ;; ;; Kill our ancestors ;; ;; clean load-path (setq load-path (delq nil (mapcar (function (lambda (p) (unless (string-match "lisp/org$" p) p)) load-path))) ;; remove property list to defeat cus-load and remove autoloads (mapatoms (function (lambda (s) (let ((sn (symbol-name s))) (when (string-match "^\\(org\\|ob\\|ox\\)-?" sn) (setplist s nil) (when (autoloadp s) (unintern s))) (add-to-list 'load-path "/path/to/org") (load "org-loaddefs.el" nil nil 'nosuffix) --8<---cut here---end--->8--- This assumes it is run before any Org functions have been used and makes no attempt to check if that's true. Another unverified assumption is that nothing has polluted the namespaces that Org uses. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] New maintainer
Tassilo Horn writes: > Jambunathan K writes: > >> How do you interpret the following block extracted from my assignment >> >> , >> | 2. Developer will report occasionally, on Developer’s initiative >> | and whenever requested by FSF, the changes and/ or enhancements >> | which are covered by this contract, and (to the extent known to ^^^ ^^^ ^^^ >> | Developer) any outstanding rights, or claims of rights, of any >> | person, that might be adverse to the rights of Developer or FSF >> | or to the purpose of this contract. >> ` > > Well, the FSF's intention here is to make sure that contributors report > back when they change employers, and the new employer doesn't want that > his employees contribute to some GNU project (maybe because that project > is in the same business as the company). So I think of that more of a > safety measure in order not to run into long-running, painful > lawsuits. Your interpretation is too narrow. The phrase "and" (marked above) there makes all the difference. My reading of the above para and Richard's response down below are consistent. , http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00066.html | If a contributor wants to specify precisely which changes are | assigned, he, she or it can talk with the FSF about it. We can | work something out. However, we'd prefer to be able to use all of | someone's changes without specific arrangements. ` >> FSF clearly side-steps the important question - when is a work >> actually assigned. Assignment is not a process but an event tied to >> specific time and date. > > As far as I understand it (just after reading one of my FSF CAs), the > changes you apply to a program where you've assigned past & future > changes are assigned as soon as they are written. They don't need to be > published, distributed, placed in a special repository location, etc. Assignment of rights is for the purpose of defending GPL. It is *not* and *cannot* be an annexation policy. What you state above amounts to annexation policy. Assignment of rights is my prerogative. I can do it selectively or cancel it. FSF cannot interfere with what is an individual decision. I will only quote an authoritative and responsible source. Focus on last sentence in the below quote. , http://lwn.net/Articles/543436/ | | Anyway, it's unfortunate the Corbet's article above doesn't | reiterate the advantages of assigning to FSF to | developers. Specifically, the FSF takes on the obligation of being | the publisher of the code (which can sometimes be a dangerous act | in today's world), and also, FSF handles enforcement of the GPL | for the codebase. Finally, FSF gives a liberal license back to the | developer (i.e., Jambunathan could have always made proprietary | software out of his own assigned works after doing the | assignment), and FSF further promises never to publish a | proprietary version of the software itself. | ` I interpret "proprietary" above to mean "any work (available to public, it is GPL right?) that is not part of Emacs distribution". Theoretically speaking, it is OK to have future assignment in place *and* have works that are assigned, as well as non-assigned *simultaneously*. If a work is not part of Emacs, then it is "not assigned" to FSF. Simple and practical definition. It is also important to note that the above paragraph from a FSF board member is in some conflict with RMS's own claim. , http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00409.html | | A diff for Emacs is always a change to Emacs. I will think about | the questions raised by a separate Lisp file. | ` In my opinion, the most appropriate thing to state would be "A diff to Emacs submitted to the official channels of the suite - either the maintainer, mailing list or bug subsystem, *unless stated otherwise* is potentially part of Emacs, in a non-revocable way." It will be inappropriate for anyone to claim, my local changes to doc-view.el that I share with a co-worker is a diff to Emacs and hence part of Emacs. A change is either part of Emacs or not. When I say Emacs, I mean the official GNU Emacs distributed from gnu.org. Now the primary part of current dispute is that it falls in a grey area 1. My files are new. 2. "Org in Emacs Bzr trunk" is not the same as "Org outside of Emacs trunk". One is "part of Emacs" while the other is "not part of Emacs". There is a clear dichotomy here. It is easy to answer "Is this file part of Emacs?" with a "Yes" or "No". Saying that a file is i
Re: [O] Release 8.0
On Apr 19, 2013, at 1:53 PM, Brian van den Broek wrote: > On 18 Apr 2013 18:05, "Carsten Dominik" wrote: > > > > On 18.4.2013, at 18:41, Bastien wrote: > > > > > Dear all, > > > > > > I'm releasing Org 8.0. > > > > This is a beautiful release. Just reading the list of changes wets > > my appetite to try it all out. A looong list con contributors. > > > > Thanks to you all for your contributions! > > An intimidatingly long list of changes, actually. :-) > > For what it is worth, I think if Bastien erred in the list of contributors he > thanked, it was on the side of over-inclusion, rather than under. In the last > year or so, I think I've contributed a tiny change doc patch, a bug report or > two, and a few "Please, could someone magically make it work like this?" > messages, yet I find myself included. > Yes, indeed! Honestly, I didn't read the long list of contributors that carefully at first. I decided to take another read after through your message, and ... Wow... I really didn't expect my name be in the list, since I have only sent a few messages to the list. > Congrats and thanks to all who helped in whatever way. The efforts from the > heroic and steady to minor and irregular have all helped to make my life > better. > Congratulations to all the orgmode users! Please allow me to take this chance to express my sincere gratitude to everyone subscribed to this orgmode mailing list and also people who contributed in other ways! It is you who have made orgmode so fantastic! Best Regards, Xiao-Yong
Re: [O] New maintainer
On 18/04/13 22:52, Tom Davey wrote: Hi everybody, I'm just an Org user, one of the many anonymous persons who have benefited from this fantastic piece of software. Over the past two years I have come to use Org every day, all day long, more than any other application with the possible exception of a Web browser. It's hard to overestimate the value I receive from Org, the sheer personal effectiveness I've gained. Bastien, a thousand thanks for your work as maintainer. Thanks as well to all the other skillful and creative programmers on this list who make org continually more powerful and astonishing. Especial thanks to Carsten, both for the past and now in advance as the new maintainer. With grateful regards to all, Tom Davey Me too:) Many thanks to Bastien for all his hard work and for patiently answering questions and fixing bugs. Also welcome back to Carsten! Best wishes, Ian.
Re: [O] Beamer export ignoring org-beamer-environments-extra?
On Apr 20, 2013 2:34 PM, "Nicolas Goaziou" wrote: > James Harkins writes: > > > The Beamer exporter assumes that environment names will be all lowercase: > > > > ;; Use specified environment. > > (t (downcase env) > > It should now be fixed. Thank you for the detailed report. I'm not able to test again right now, but in my earlier testing, simply removing downcase was ok for my CJK extra but the export failed for noteNH (something about stringp). It's worth testing that. This turns out to have been quite an adventure anyway. I've been using the Ubuntu packages for latex, which date back to 2009, and CJK itself isn't getting a lot of developer attention. Consensus online seemed to be to upgrade, so now I'm in the middle of 8-9 hours of downloads from texlive. If I'm lucky, I *might* be able to try another beamer export right around bedtime (7 pm now). :-| hjh
[O] About documentation of macro replacement
I think info:org#Macro%20replacement should be refined. I really don't understand what this node is talking about. It says: You can define text snippets with #+MACRO: name replacement text $1, $2 are arguments What does "$1", "$2" mean here? It isn't mentioned before, and I only know what it means in the spreadsheet. And it doesn't look like a C/Lisp/m4/TeX macro. -- Best regards, Xue Fuqiao. http://www.gnu.org/software/emacs/
Re: [O] About documentation of macro replacement
Hello, xfq writes: > I think info:org#Macro%20replacement should be refined. I really don't > understand what this node is talking about. It says: > > You can define text snippets with > #+MACRO: name replacement text $1, $2 are arguments > > What does "$1", "$2" mean here? It isn't mentioned before, and I only > know what it means in the spreadsheet. And it doesn't look like a > C/Lisp/m4/TeX macro. $1 and $2 are placeholders for macro arguments. $1 will be replaced by the first argument and $2 by the second one. You can provide a new phrasing for the section and we'll consider adding it to the manual. Regards, -- Nicolas Goaziou
Re: [O] [babel] Purpose of :results raw
Hello, "Sebastien Vauban" writes: > The fact that the following output a normally behaving headline[1], AFAICS. > > #+begin_src sh :results drawer :exports both > echo "* Unescaped headline" > #+end_src > > #+results: > :RESULTS: > * Unescaped headline > :END: > > Though, effectively, when exported, it's not right: [...] > Do you mean it, because of the wrong export? By wrong, I don't mean "buggy", > but "not foreseen as I (= me) thought". Both cycling mechanism and fontification are bad indicators about the syntax at point. Use either `org-element-at-point' or `org-element-context' to know what is really parsed, according to the Org syntax. I will slowly integrate org-element-at-point in core interactive functions, like visibility cycling. Though, fontification will have to wait, because the parser isn't ready for that yet. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-export-as doesn't work after update [8.0 (8.0-3-g7248fb-elpa @ /home/mike/.emacs.d/elpa/org-20130418/)]
Can't this behaviour be fixed? It's quite confusing. On 19 Apr 2013 23:28, "Nicolas Goaziou" wrote: > Mike Vella writes: > > > Hi Nicolas, But I don't understand why it autocompletes with tab if it no > > longer exists as a command? I think this is confusing behaviour? > > You may have loaded old org-html.el from Org bundled with Emacs. > > > Regards, > > -- > Nicolas Goaziou >
Re: [O] MobileOrg for iOS approved and soon to be available in the app store
Sean Escriva gmail.com> writes: > > For those interested in MobileOrg on iOS devices, it has been approved > and will be back in the store soon, it can take up to 24 hours to > become available. > > See this github issue for further info: > https://github.com/MobileOrg/mobileorg/issues/24 > > Enjoy! > -sean If you install Sean's update but still get the dreaded Unspecified Error when syncing note that the location of the files have changed from MobileOrg to Apps/MobileOrg (Sean mentioned elsewhere that this was required by the new Dropbox API), so you'll have to update org-mobile-directory accordingly. For instance, for a default install of Dropbox: (setq org-mobile-directory "~/Dropbox/Apps/MobileOrg"); Cheers, Dave.
Re: [O] Bug: org-export-as doesn't work after update [8.0 (8.0-3-g7248fb-elpa @ /home/mike/.emacs.d/elpa/org-20130418/)]
Hello, Mike Vella writes: > Can't this behaviour be fixed? It's quite confusing. > On 19 Apr 2013 23:28, "Nicolas Goaziou" wrote: > >> Mike Vella writes: >> >> > Hi Nicolas, But I don't understand why it autocompletes with tab if it no >> > longer exists as a command? I think this is confusing behaviour? >> >> You may have loaded old org-html.el from Org bundled with Emacs. This is probably coming from your configuration. Check if you don't load the wrong Org version before loading the correct one. Regards, -- Nicolas Goaziou
[O] Tabular overview of org-element.el
Hi Nicolas, Hi List,
I prepared a tabular overview of org-element.el to get a better
understanding of how Nicolas modeled and Org file, and I thought it
might be useful for others so I share it here.
I did not know where to put 'plain-link', but maybe I simply overlooked
it in one place.
___
ORG ELEMENTS - A TABULAR OVERVIEW
Thorsten Jolitz
___
<2013-04-20 Sa>
Table of Contents
_
1 org-element: Elements, Objects and Successors
.. 1.1 Elements
. 1.1.1 Abbreviations
. 1.1.2 Element List
.. 1.2 Objects
. 1.2.1 Object List
. 1.2.2 Object Variables
.. 1.3 Successors
. 1.3.1 Abbreviations
. 1.3.2 Sets of Successors
. 1.3.3 Objects restrictions
2 org-element: Keywords and Properties
.. 2.1 Affiliated Keywords
.. 2.2 Document Properties
3 Left-over
1 org-element: Elements, Objects and Successors
===
1.1 Elements
1.1.1 Abbreviations
---
Abbrev Meaning
---
GE? Greater Element?
SecVal-Location Secondary Value Location
Recur? Recursive?
1.1.2 Element List
--
"Complete list of element types."
"List of recursive element types aka Greater Elements."
"Alist between element types and location of secondary
value."
Element GE? SecVal-Location
---
babel-call
center-block X
clock
comment
comment-block
diary-sexp
drawer X
dynamic-blockX
example-block
export-block
fixed-width
footnote-definition X
headline X:title
horizontal-rule
inlinetask X:title
item X:tag
keyword
latex-environment
node-property
paragraph
plain-list X
planning
property-drawer X
quote-block X
quote-section
section X
special-blockX
src-block
tableX
table-row
verse-block
1.2 Objects
~~~
1.2.1 Object List
-
"Complete list of object types."
"List of recursive object types."
"Alist of translations between object type and successor
name. Sharing the same successor comes handy when, for
example, the regexp matching one object can also match the
other object."
"Alist between element types and location of secondary
value."
Object Recur? Successor(type) SecVal-Location
-
boldX text-markup
codetext-markup
entity latex-or-entity
export-snippet X
footnote-reference X:inline-definition
inline-babel-call X
inline-src-blockX
italic X text-markup
line-break X
latex-fragment latex-or-entity
linkX X
macro X
radio-targetX X
statistics-cookie X
strike-through X text-markup
subscript X sub/superscript
superscript X sub/superscript
table-cell X X
target X
timestamp X
underline X text-markup
verbatimtext-markup
1.2.2 Object Variables
--
"List of buffer-local variables used when parsing objects.
These variables are copied to the temporary buffer created
by `org-export-secondary-string'."
object-variables '(org-link-abbrev-alist-local)
Example for `org-link-abbrev-alist-local'
,
| (("bib" . "~/bibtex/literatur.bib::%s")
| ("notes" . "~/git/org/notes.org::#%s")
| ("papers" . "~/doc/papers/%s.pdf"))
`
1.3 Successors
~~
1.3.1 Abbreviations
---
abbrev meaning
-
all all successors
std-set standard-set
std-set-nlb standard-set-no-line-break
l-setlink-set
tc-set table-cell-set
tr-set table-row-set
rt-set radio-target-set
1.3.2 Sets of Successors
"Complete list of successors."
members\set all std-set std-set-nlb l-set tc-set tr-set rt-set
--
export-snippet XXXX X
footnote-reference XXX X
inline-babel-call XXX
Re: [O] phone links...
Michael Strey writes:
>> - You should use `org-link-display-format' instead of
>> `org-contacts-strip-link'.
>
> I don't think so. `org-link-display-format' returns the description of
> the link if there is one. My `org-contacts-strip-link' always returns
> the target. Using `org-link-display-format' would lead to wrong results
> with links like
> [[mailto:f...@bar.com][foo (at) bar (dot) com]]
> [[tel:+49 351 4129535][+49 (0)351 4129535]]
You're right, I had misunderstood the function.
>> - You have done some unrelated changes (fix some typos, ...), could you
>> provide a separated patches for them?
>
> Oh =:-|, another struggle with Git. I'm still learning and will do my best.
If you're not already using magit[1] I highly recommend it to you. You
can use it to commit only a portion of the changes (you can also do it
with "git commit --interactive" but I find it easier with magit).
>> Regarding `org-contacts-split-property', I haven't found anything about
>> multiple values within a node property in `org-element' and the syntax
>> description doesn't mention it, so you were right to roll your own. :)
>
> That wasn't me. This (disputable) feature was already there for the
> :EMAIL: proprerty. Actually, I don't like multiple values within a node
> property and would prefer a VCard-like syntax like
>
> #+BEGIN_SRC org
> *** Strey, Michael
> :PROPERTIES:
> :KIND: individual
> :ORG: STREY Consult
> :FN: Michael Strey
> :N:Strey;Michael;;
> :ADR;TYPE=home:;;my street;my city;federal state;post code;my country
> :EMAIL: mailto:st...@myprovider.de
> :EMAIL;PREF=1:mailto:m...@mycompany.biz
> :TEL;TYPE="fax,work":[[tel:0321 21104568]]
> :TEL;TYPE="fax,home":[[tel:0351 4129535]]
> :TEL;TYPE="voice,home":[[tel:0351 4129535]]
> :LANG: de
> :ICON: ~/GTD/Icons/icon-strey_michael.jpg
> :END:
> #+END_SRC
I must admit I am unsure about this. On one side it does solve some
problems, on the other side I don't really like the idea of adding this
extra syntax on top of properties.
I think it's fine to use semicolons to separate values in node
properties, but I would like to expose a clean API to manipulate users
and user's properties so that we don't have to use `*-split-*'
everywhere.
For example it could expose your previous example into this:
#+BEGIN_SRC lisp
'((kind "individual")
(org "STREY Consult")
(fn "Michael Strey")
(n ("Stry" "Michael" ""))
(adr ("" "" "my street" "my city" "federal state" "post code" "my country")
:type home)
(email "mailto:st...@myprovider.de";)
(email "mailto:m...@mycompany.biz"; :pref 1)
(tel "[[tel:0321 21104568]]" :type "fax,work")
(tel "[[tel:0351 4129535]]" :type "fax,home")
(tel "[[tel:0351 4129535]]" :type "voice,home")
(lang "de")
(icon "~/GTD/Icons/icon-strey_michael.jpg"))
#+END_SRC
>> However, I think it would be better to store the separators in a
>> variable (like `org-contacts-property-values-separator') and maybe even
>> to use it by default instead of `split-string-default-separators'
>> because we use it more and because it's easy to forget.
>
> That was already hard-coded before in Feng's
> `org-contacts-vcard-format'. But yes, you are right. Since it is
> limited by some constraints we should make it an extra variable.
>
>>
>> > +(loop for email in (org-contacts-split-property
>> > email-list)
>>
>>
>> > + for gravatar = (gravatar-retrieve-synchronously
>> > (org-contacts-strip-link email))
>
> This should be correctly and worked for me during my tests.
> Confusingly `email-list' is not a list but a string here.
My bad (again :/).
Regards,
1. https://github.com/magit/magit
--
Daimrod/Greg
pgpA1Yp4mnukl.pgp
Description: PGP signature
Re: [O] Tabular overview of org-element.el
Hello, Thorsten Jolitz writes: > I prepared a tabular overview of org-element.el to get a better > understanding of how Nicolas modeled and Org file, and I thought it > might be useful for others so I share it here. > > I did not know where to put 'plain-link', but maybe I simply overlooked > it in one place. It belongs to `org-element-all-successors', which means it is a successor. Actually, it is a dumbed down successor for links, as it only finds plain links, i.e. links with no markup at all. E.g., http://orgmode.org This is necessary as some contexts (i.e. link descriptions) can only contain such links. HTH, -- Nicolas Goaziou
[O] Org Mode 8
After replacing 7.9.4 with 8.0 the link insertion gave a variable void error that was corrected by re-installing 7.9.4. After browsing the * update files and seeing nothing that was helpful I send this message and continue using 7.9.4.
Re: [O] Org Mode 8
On Sat, Apr 20, 2013 at 10:38 AM, Paul Schlesinger wrote: > After replacing 7.9.4 with 8.0 the link insertion gave a variable void error > that was corrected by re-installing 7.9.4. After browsing the * update files > and seeing nothing that was helpful I send this message and continue using > 7.9.4. We'll need more details to help you. At the very least, what was the variable that was flagged as void? This wouldn't be uncommon, as a lot of names changed in the 8.0 release. Did you scan the upgrade guide? - http://orgmode.org/worg/org-8.0.html The first possibility that came to mind was a variable like org-export-backend-* (where backend = html, latex, etc.) which has now been renamed to org-backend-*. But again, with no details at all... we won't be able to help you. Thanks! John > >
Re: [O] Tabular overview of org-element.el
Nicolas Goaziou writes: > Hello, > > Thorsten Jolitz writes: > >> I prepared a tabular overview of org-element.el to get a better >> understanding of how Nicolas modeled and Org file, and I thought it >> might be useful for others so I share it here. >> >> I did not know where to put 'plain-link', but maybe I simply overlooked >> it in one place. > > It belongs to `org-element-all-successors', which means it is > a successor. Actually, it is a dumbed down successor for links, as it > only finds plain links, i.e. links with no markup at all. E.g., > > http://orgmode.org > > This is necessary as some contexts (i.e. link descriptions) can only > contain such links. Whats kind of confusing for me is that all other successors are either 'atomic' objects or 'object-categories' containing 'atomic' objects: , | Object Recur? Successor(type) SecVal-Location | - |boldX text-markup |codetext-markup |entity latex-or-entity |export-snippet X |footnote-reference X:inline-definition |inline-babel-call X |inline-src-blockX |italic X text-markup |line-break X |latex-fragment latex-or-entity |linkX X |macro X |radio-targetX X |statistics-cookie X |strike-through X text-markup |subscript X sub/superscript |superscript X sub/superscript |table-cell X X |target X |timestamp X |underline X text-markup |verbatimtext-markup ` Only plain-link is an 'outlier' in this systematic. What is a link like ,--- | http://orgmode.org `--- then, when encountered in an Org document? If its not an object nor an element, then it is (anonymous) part of the String that forms a paragraph? Its easy to understand that some objects can be successors of other objects/elements, others not, and that its sometimes convenient to organize similar successor objects into successor-categories. Its not so easy to understand how something can be a successor but not an object. -- cheers, Thorsten
Re: [O] Tabular overview of org-element.el
Thorsten Jolitz writes: > Nicolas Goaziou writes: > >> Hello, >> >> Thorsten Jolitz writes: >> >>> I prepared a tabular overview of org-element.el to get a better >>> understanding of how Nicolas modeled and Org file, and I thought it >>> might be useful for others so I share it here. >>> >>> I did not know where to put 'plain-link', but maybe I simply overlooked >>> it in one place. >> >> It belongs to `org-element-all-successors', which means it is >> a successor. Actually, it is a dumbed down successor for links, as it >> only finds plain links, i.e. links with no markup at all. E.g., >> >> http://orgmode.org >> >> This is necessary as some contexts (i.e. link descriptions) can only >> contain such links. > > > Whats kind of confusing for me is that all other successors are either > 'atomic' objects or 'object-categories' containing 'atomic' objects: > > , > | Object Recur? Successor(type) SecVal-Location > | - > |boldX text-markup > |codetext-markup > |entity latex-or-entity > |export-snippet X > |footnote-reference X:inline-definition > |inline-babel-call X > |inline-src-blockX > |italic X text-markup > |line-break X > |latex-fragment latex-or-entity > |linkX X > |macro X > |radio-targetX X > |statistics-cookie X > |strike-through X text-markup > |subscript X sub/superscript > |superscript X sub/superscript > |table-cell X X > |target X > |timestamp X > |underline X text-markup > |verbatimtext-markup > ` > > Only plain-link is an 'outlier' in this systematic. What is a link like > > ,--- > | http://orgmode.org > `--- > > then, when encountered in an Org document? If its not an object nor an > element, then it is (anonymous) part of the String that forms a paragraph? > Its easy to understand that some objects can be successors of other > objects/elements, others not, and that its sometimes convenient to > organize similar successor objects into successor-categories. > > Its not so easy to understand how something can be a successor but not > an object. "http://orgmode.org"; _is_ a link object, like [[http://orgmode.org]]. There are two successors for the same object type, one being more selective than the other. This special successor was introduced (lately) because there was no image syntax in Org. So we needed to recognize: [[http://orgmode.org][./unicorn.jpg]] as an image pointing to an URL. In fact, we could separate `plain-link' objects from `link' objects, but the benefit is not obvious, so `plain-link' is just considered as a sub-type of `link'. Regards, -- Nicolas Goaziou
Re: [O] Does Org support Related or "See Also" Properties?
Hi Bastien, thanks for the prompt reply. Bastien writes: >> When exported into an agenda, the consolidated org agenda would read: >> >> Friday 19 April 2013 >> customer: 09:00-09:30 Scheduled: TODO Meeting with Pete > > The problem is: what would RET do on this agenda line? Go to which > entry? You can always put some hacks in `org-agenda-finalize-hook' > but it's easier to try to keep your Org files clean ;) I would assume that RET would jump to the source item (the one with the "See also" property). It's unfortunately difficult for me to keep my source files clean: my schedule is composed of three different and unrelated sources, which vary daily. I export those sources to three different org files and combine those with my personal schedule to figure out what needs to be done every day. Since the exported sources get overwritten, I have to copy each event into my own (clean) org file and then unschedule the exported one, to keep the agenda clean. It's... silly, but it mostly works. If anybody wants a spreadsheet-to-org-file exporter, just let me know. :) Nick pgp3d6IiznJGZ.pgp Description: PGP signature
Re: [O] Tabular overview of org-element.el
Nicolas Goaziou writes:
> Thorsten Jolitz writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Thorsten Jolitz writes:
>>>
I prepared a tabular overview of org-element.el to get a better
understanding of how Nicolas modeled and Org file, and I thought it
might be useful for others so I share it here.
I did not know where to put 'plain-link', but maybe I simply overlooked
it in one place.
>>>
>>> It belongs to `org-element-all-successors', which means it is
>>> a successor. Actually, it is a dumbed down successor for links, as it
>>> only finds plain links, i.e. links with no markup at all. E.g.,
>>>
>>> http://orgmode.org
>>>
>>> This is necessary as some contexts (i.e. link descriptions) can only
>>> contain such links.
>>
>>
>> Whats kind of confusing for me is that all other successors are either
>> 'atomic' objects or 'object-categories' containing 'atomic' objects:
>>
>> ,
>> | Object Recur? Successor(type) SecVal-Location
>> | -
>> |boldX text-markup
>> |codetext-markup
>> |entity latex-or-entity
>> |export-snippet X
>> |footnote-reference X:inline-definition
>> |inline-babel-call X
>> |inline-src-blockX
>> |italic X text-markup
>> |line-break X
>> |latex-fragment latex-or-entity
>> |linkX X
>> |macro X
>> |radio-targetX X
>> |statistics-cookie X
>> |strike-through X text-markup
>> |subscript X sub/superscript
>> |superscript X sub/superscript
>> |table-cell X X
>> |target X
>> |timestamp X
>> |underline X text-markup
>> |verbatimtext-markup
>> `
>>
>> Only plain-link is an 'outlier' in this systematic. What is a link like
>>
>> ,---
>> | http://orgmode.org
>> `---
>>
>> then, when encountered in an Org document? If its not an object nor an
>> element, then it is (anonymous) part of the String that forms a paragraph?
>> Its easy to understand that some objects can be successors of other
>> objects/elements, others not, and that its sometimes convenient to
>> organize similar successor objects into successor-categories.
>>
>> Its not so easy to understand how something can be a successor but not
>> an object.
>
> "http://orgmode.org"; _is_ a link object, like [[http://orgmode.org]].
> There are two successors for the same object type, one being more
> selective than the other.
>
> This special successor was introduced (lately) because there was no
> image syntax in Org. So we needed to recognize:
>
> [[http://orgmode.org][./unicorn.jpg]]
>
> as an image pointing to an URL. In fact, we could separate `plain-link'
> objects from `link' objects, but the benefit is not obvious, so
> `plain-link' is just considered as a sub-type of `link'.
So in fact there are link objects that might belong to 'decorated-link'
or 'plain-link', but this has not been made explicit because there is
only one special case where its not sufficient to simply use super-type
'link'.
Maybe its worth to notice that wrt 'plain-link' there are some hidden
implicit things going on in the background. First of all, there are no
other subtypes of object-types - object 'link' would be the only
object-type with two subtypes ('plain-link' and 'decorated-link' or
whatever). And the object 'link' is used as successor but does not fit
all situations where a link can be used.
I know this might be of no practical relevance at the moment, and might
seem like a case of excessive pea-counting, but now that Org-mode has
such a wonderful parsing and exporting framework, there might well be a
trend towards more formalization in the future - and this will cause
hiccups for anyone who tries such formalization.
To keep the system consistent, there should be two types of link objects
('plain-link' and 'decorated-link') that are both successors too, and
maybe additionally a successor category 'link' that can be applied when
distinction between the two link object-types does not matter.
--
cheers,
Thorsten
Re: [O] Tabular overview of org-element.el
Thorsten Jolitz writes:
> So in fact there are link objects that might belong to 'decorated-link'
> or 'plain-link', but this has not been made explicit because there is
> only one special case where its not sufficient to simply use super-type
> 'link'.
That and the fact that it was introduced very recently.
> Maybe its worth to notice that wrt 'plain-link' there are some hidden
> implicit things going on in the background. First of all, there are no
> other subtypes of object-types - object 'link' would be the only
> object-type with two subtypes ('plain-link' and 'decorated-link' or
> whatever). And the object 'link' is used as successor but does not fit
> all situations where a link can be used.
Actually there is also `radio-link' sub-type. But it doesn't need its
own successor function so far.
> I know this might be of no practical relevance at the moment, and might
> seem like a case of excessive pea-counting, but now that Org-mode has
> such a wonderful parsing and exporting framework, there might well be a
> trend towards more formalization in the future - and this will cause
> hiccups for anyone who tries such formalization.
To be honest, I hope that Org will grow a proper syntax for images
instead (i.e. without overloading link syntax). Many (most?) text markup
languages have one (e.g. Markdown). If it does, the `plain-link'
successor becomes useless and the case is closed.
> To keep the system consistent, there should be two types of link objects
> ('plain-link' and 'decorated-link') that are both successors too, and
> maybe additionally a successor category 'link' that can be applied when
> distinction between the two link object-types does not matter.
That's what I talked about indeed, but besides consistency, there's not
much benefit to do that. I'd rather have images as full-fledged objects,
something like:
[img:""]
which could possibly be extended with properties for export:
[img:"" :prop1 val1 :prop2 val2]
Regards,
--
Nicolas Goaziou
Re: [O] Superscripts and subscripts
Hello, Christian Moe writes: >>> Nicolas Goaziou writes: Of course, we could work around this with a new rule saying "the longest match wins", which, in this case, is the underline. But it would be better to find a more elegant solution, one which would remove the sole ambiguity, AFAICT, in Org syntax. > > How did this work before? I never tried subscript after whitespace. But > we had both superscript-after-whitespace and > underlining-with-underscores working at the same time, without the > ambiguity causing problems as far as I remember. Simple: underline text was always handled (i.e. protected for further transformation) before subscript. But this doesn't remove the ambiguity. It just adds another parameter: the parsing order. Regards, -- Nicolas Goaziou
Re: [O] Superscripts and subscripts
Hello,
Achim Gratz writes:
> Nicolas Goaziou writes:
>> Of course, we could work around this with a new rule saying "the longest
>> match wins", which, in this case, is the underline. But it would be
>> better to find a more elegant solution, one which would remove the sole
>> ambiguity, AFAICT, in Org syntax.
>>
>> Suggestions welcome.
>
> How about {}^{14}C or {^{14}}C?
It means that a white space before a sub/superscript marker is invalid.
In that case, we can also use "\nbsp" entity instead of {}. It's longer,
but more standard.
Another option would be to change syntax for underline, doubling the
underscore characters:
__underline__
The other advantage is that it may be less ambiguous if we ever allow
text markup within words.
Regards,
--
Nicolas Goaziou
Re: [O] Bug in new exporter with babel blocks
Hello, Aaron Ecay writes: > 2013ko urtarrilak 23an, Nicolas Goaziou-ek idatzi zuen: >> You needn't. org-exp-blocks functionalities are supported by the new >> exporter out of the box. > > Can you say more about this? I looked for but did not find a > replacement to the org-export-blocks variable (an alist associating > block types with functions to export them). I found it very easy to > hook into the new exporter, but perhaps I missed something? No, you didn't miss anything. I was thinking about `org-special-blocks.el'. The exporter doesn't implement org-exp-blocks functionalities. Though, IIRC, org-exp-blocks was mostly deprecated when Babel was introduced. That's why old ditaa and dot "exp-blocks" were moved to src block languages. > For parsing, yes. But for export I want a way to say “I don’t care what > Org thinks the export of this block is. Give me the raw contents, and I > will tell you what the export should be.” > > This is how the ditaa special-block code used to work; I see that it has > now morphed into a babel language, which makes some kind of sense. I’m > not sure it does in general. > > My use case is glossed examples for linguistics: my special block > contains three lines, which are a sentence in a foreign language and a > translation. By inserting markup in a way which is easy to automate, > you can get LaTeX to align the words of one language with the words of > the other. I don’t want any org processing of the text of the examples: > it might contain backslashes, stars, etc., all of which should be passed > verbatim to LaTeX. This does not feel like source code, it cannot be > evaluated or tangled, I would not want these blocks to be included in > org-babel-next-src-block, etc. It is data. Source code is for the processing function. Anyway, just store your text in example blocks, and create a src block in any language to do the processing. Then you can call the processing function on all of your example blocks. I suggest to keep the example blocks in a non-exportable section. You can also remove all named example blocks before export, via a hook. Your call. #+begin_src org * Data :noexport: #+name: words #+BEGIN_EXAMPLE a b c #+END_EXAMPLE #+name: #+BEGIN_SRC emacs-lisp :var x=words (upcase x) #+END_SRC * Contents #+call: words(:var x=words) #+end_src Regards, -- Nicolas Goaziou
Re: [O] Tabular overview of org-element.el
Nicolas Goaziou writes:
>> To keep the system consistent, there should be two types of link objects
>> ('plain-link' and 'decorated-link') that are both successors too, and
>> maybe additionally a successor category 'link' that can be applied when
>> distinction between the two link object-types does not matter.
>
> That's what I talked about indeed, but besides consistency, there's not
> much benefit to do that. I'd rather have images as full-fledged objects,
> something like:
>
> [img:""]
>
> which could possibly be extended with properties for export:
>
> [img:"" :prop1 val1 :prop2 val2]
That sounds like a very good idea to me, from the point of view of a
user, and from the point of view of somebody who tries to understand the
system you used for modeling Org files. And consistency can turn out
very beneficial in the long run, even if the benefits are not so obvious
at the moment.
--
cheers,
Thorsten
[O] Bug: Footnotes break iCalendar export [8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)]
Hi Org maintainers,
I've been trying to get iCalendar export working with my agenda files
again since upgrading to 8.0, and I've found that footnotes break the
agenda export to .ics. The problem is that a plain text version of the
footnotes in the file ends up in the output "floating loose"---not
wrapped by VEVENT tags or any other tags---resulting in an unparseable
.ics file (at least according to Google Calendar).
Here's a sample Org file to illustrate:
* Entry 1
This entry has some text with an inline footnote[fn:: which isn't
very interesting]
* Entry 2
This entry has some text with an external footnote[fn:1]
* Appointment with Someone
<2013-04-20 Sat 15:00>
* Footnotes
[fn:1] which still isn't very interesting
And here's the output I get when I export this
(via C-c a < a C-x C-w /tmp/test.ics):
BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:OrgMode
PRODID:-//Richard Lawrence//Emacs with Org mode//EN
X-WR-TIMEZONE:America/Los_Angeles
X-WR-CALDESC:
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20130420T211153Z
UID:TS1-5b8f14ac-d380-437f-88dd-4ed0a4ebacb9
DTSTART:20130420T15
DTEND:20130420T17
SUMMARY:Appointment with Someone
DESCRIPTION:<2013-04-20 Sat 15:00>
CATEGORIES:test
END:VEVENT
Footnotes
─
[1] which isn't very interesting
[2] which still isn't very interesting
END:VCALENDAR
Note that I still seem to get the behavior when I restrict the export to
headlines matching certain tags. In that case, even footnotes from
entries which should not be exported end up in the output, which seems
pretty strange.
It doesn't make much sense to me to have footnotes when exporting to a
calendar format, so is there any way to suppress exporting footnotes in
this case?
Thanks!
Best,
Richard
Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1)
of 2013-01-08 on murphy, modified by Debian
Package: Org-mode version 8.0.1 (release_8.0.1 @ /home/rwl/src/org-mode/lisp/)
current state:
==
(setq
org-todo-keyword-faces '(("WAITING" . "orange"))
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-custom-commands '(("r" "Reading list" tags-todo "+reading") ("S" .
"STUDY context searches") ("Sf" todo "FIND") ("Sp" todo "PRINT")
("Sr" todo "READ") ("Sn" todo "NOTES") ("St"
tags-todo "+STUDY") ("P" tags-todo "+CAMPUS") ("D" tags-todo "+COMPUTER")
("H" tags-todo "+HOME") ("E" tags-todo
"ERRAND|BUY") ("F" tags "+FREETIME") ("X" tags-todo "+EXERCISE")
("Z" "Export to iCalendar file" tags
"event|appointment" nil
("~/Documents/website/public_html/lib/attachments/calendar.ics"))
)
org-agenda-files '("~/Documents/philosophy/dissertation/tasks.org"
"~/org/school.org" "~/org/life.org" "~/org/beer.org" "~/org/food.org")
org-metaup-hook '(org-babel-load-in-session-maybe)
org-capture-templates '(("s" "School")
("st" "Todo" entry (file+olp "~/org/school.org"
"Tasks" "Spring 2013") (file "~/org/templates/todo.txt") :prepend t)
("sy" "Todo (from active region or kill ring)" entry
(file+olp "~/org/school.org" "Tasks" "Spring 2013")
(file "~/org/templates/todo-with-yank.txt") :prepend
t)
("sl" "Todo (with link)" entry (file+olp
"~/org/school.org" "Tasks" "Spring 2013") (file
"~/org/templates/todo-with-link.txt")
:prepend t)
("se" "Event" entry (file+headline "~/org/school.org"
"Events") (file "~/org/templates/event.txt") :prepend t)
("sr" "Reading" entry (file+olp "~/org/school.org"
"Reading list") (file "~/org/templates/reading.txt") :prepend t)
("sa" "Appointment" entry (file+olp "~/org/school.org"
"Tasks" "Spring 2013") (file "~/org/templates/appointment.txt") :prepend t)
("sb" "Bookmark" entry (file+olp "~/org/school.org"
"Bookmarks") (file "~/org/templates/bookmark-school.txt"))
("sc" "Class" entry (file+olp "~/org/school.org"
"Semester Schedule" "Spring 2013" "Classes") (file "~/org/templates/class.txt"))
("ss" "Semester" entry (file+olp "~/org/school.org"
"Semester Schedule") (file "~/org/templates/semester.txt") :prepend t)
("d" "Dissertation")
("dt" "Todo" entry (file+olp
"~/Documents/philosophy/dissertation/tasks.org" "Tasks") (file
"~/org/templates/todo.txt") :prepend t)
("de" "Event" entry (file+headline
"~/Documents/philosophy/dissertation/tasks.org" "Events") (file
"~/org/templates/event.txt")
:prepend t)
("dr" "Reading" entry (file+olp
"~/Documents/philosophy/dissertation/tasks.org" "Reading list")
(file "~/org/templates/reading.txt") :prepend t)
Re: [O] [PATCH 04/10] Add 'light argument to some uses of org-babel-get-src-block-info
Aaron Ecay writes: > Hi Eric, > > 2013ko apirilak 3an, Eric Schulte-ek idatzi zuen: >> >> Aaron Ecay writes: >> >>> * lisp/ob-core.el (org-babel-do-key-sequence-in-edit-buffer), >>> (org-babel-expand-noweb-references), >>> * lisp/ob-tangle.el (org-babel-tangle): >>> Use 'light argument to `org-babel-get-src-block-info'. >> >> I'd like to apply this patch, however tracing the effects of these >> changes can be tricky and `org-babel-expand-noweb-references' and >> `org-babel-tangle' are both core functions. >> >> Have you run the test suite to confirm that these changes don't break >> any existing tests? > > The test suite gives no failures with this patch. Then please go ahead and apply this patch (or re-send it to me and I can apply it). Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Specified colnames
"Sebastien Vauban" writes: > Eric, > > Eric Schulte wrote: >> "Sebastien Vauban" writes: >>> Eric Schulte wrote: > Extra question: tested with a sh block, both of the above do work, that is > with strings or symbols. Which one is supposed to be better (that is, > will be > more portable with time), if there is one? Both will be maintained. The contribution of a test exercising both options could provide an extra guarantee of perseverance. This is also a good first step towards editing the code. :) >>> >>> Here's my trial to do so [...]. >>> Does this correspond to what you're asking for? >> >> Close, could you prepare this as a patch against the current code base? >> That way I can simply apply it locally and more easily test it. > See the above, could you prepare this as a patch so that I can more easily read/use/test it? Thanks, > > I've fixed the "abortion" problem I had with the test... > > Updated version: > > --8<---cut here---start->8--- > (ert-deftest test-ob/specific-colnames () > "Test passing specific column names." > (should >(equal "#+name: input-table > | id | var1 | > |+--| > | 1 | bar | > | 2 | baz | > > #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) > echo \"$data\" > #+end_src > > #+results: > | Rev | Author | > |-+| > | 1 | bar| > | 2 | baz| > > " > (org-test-with-temp-text "#+name: input-table > | id | var1 | > |+--| > | 1 | bar | > | 2 | baz | > > #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) > echo \"$data\" > #+end_src > " > (org-babel-execute-src-block) > (buffer-string) > --8<---cut here---end--->8--- > > Though, it generates an incomprehensible error (for me): > > --8<---cut here---start->8--- > Debugger entered--Lisp error: (wrong-type-argument consp nil) > apply(debug (error (wrong-type-argument consp nil))) > ert--run-test-debugger([cl-struct-ert--test-execution-info > [cl-struct-ert-test test-ob/specific-colnames "Test passing specific column > names." (lambda nil (let ((fn-802 (function equal)) (args-803 (list "#+name: > input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz > |\n\n#+begin_src sh :var data=input-table :exports results :colnames '(Rev > Author)\necho \"$data\"\n#+end_src\n\n#+results:\n| Rev | Author > |\n|-+|\n| 1 | bar|\n| 2 | baz|\n\n" (let ... ... > (let ((value-804 (quote ert-form-evaluation-aborted-805))) (let > (form-description-806) (if (unwind-protect ... ... ...) nil (ert-fail > form-description-806))) value-804))) nil :passed nil] > [cl-struct-ert-test-failed nil nil (wrong-type-argument consp nil) ((t setcar > nil ((:comments . "") (:shebang . "") (:cache . "") (:padline . "") (:noweb . > "") (:tangle . "") (:exports . "") (:results . ""))) (nil let* ((c (nthcdr 2 > i))) (setcar c merged-params)) (nil let ((i info)) (let* ((c (nthcdr 2 i))) > (setcar c merged-params)) i) (nil org-babel-check-evaluate (let ((i info)) > (let* ((c ...)) (setcar c merged-params)) i)) (nil if > (org-babel-check-evaluate (let ((i info)) (let* (...) (setcar c > merged-params)) i)) (progn (let* ((params ...) (cachep ...) (new-hash ...) > (old-hash ...) (cache-current-p ...)) (cond (cache-current-p ...) (... > ...) (nil let* ((info (if info (copy-tree info) > (org-babel-get-src-block-info))) (merged-params (org-babel-merge-params (nth > 2 info) params))) (if (org-babel-check-evaluate (let (...) (let* ... ...) i)) > (progn (let* (... ... ... ... ...) (cond ... ...) (t > org-babel-execute-src-block) (nil progn (org-mode) (progn (insert "#+name: > input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz > |\n\n#+begin_src sh :var data=input-table :exports results :colnames '(Rev > Author)\necho \"$data\"\n#+end_src\n") (goto-char (point-min))) > (org-babel-execute-src-block) (buffer-string)) (nil unwind-protect (progn > (org-mode) (progn (insert "#+name: input-table\n| id | var1 > |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var > data=input-table :exports results :colnames '(Rev Author)\necho > \"$data\"\n#+end_src\n") (goto-char (point-min))) > (org-babel-execute-src-block) (buffer-string)) (and (buffer-name temp-buffer) > (kill-buffer temp-buffer))) (nil save-current-buffer (set-buffer temp-buffer) > (unwind-protect (progn (org-mode) (progn (insert "#+name: input-table\n| id | > var1 |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var > data=input-table :exports results :colnames '(Rev Author)\necho > \"$data\"\n#+end_src\n") (goto-char ...)) (org-babel-execute-src-block) > (buffer-string)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer > (nil let ((temp-buffer (generate-new
Re: [O] [PATCH 03/10] Clean up various org-babel-*-maybe commands
Aaron Ecay writes: > Hi Bastien, > > Thanks for your comments. > > 2013ko apirilak 3an, Bastien-ek idatzi zuen: > > [...] > >>> org-babel-get-src-block-info is a potentially expensive operation, which >>> is why its ‘light’ argument exists. But in any case, it is overkill to >>> query the whole info, if all that is needed is whether point is in a >>> block or not. Factor the simplified common code out into a macro. >> >> The let-bound info variable is not only used to check if we are within >> a src block, it is also passed as an argument to functions, see the ^^ >> marks below. > > All of these functions will re-calculate the info if it is not > passed, using org-babel-get-src-block-info. So not passing it does no > harm. > Could re-calculating the info cause referenced blocks to be executed more than once? If so then we should continue passing the info and *not* simply re-calculate it later on. Cheers, > >> >>> --- >>> lisp/ob-core.el | 31 +-- >>> 1 file changed, 17 insertions(+), 14 deletions(-) >>> >>> diff --git a/lisp/ob-core.el b/lisp/ob-core.el >>> index 723aa9d..283628e 100644 >>> --- a/lisp/ob-core.el >>> +++ b/lisp/ob-core.el >>> @@ -365,15 +365,22 @@ of potentially harmful code." >>> (or (org-babel-execute-src-block-maybe) >>> (org-babel-lob-execute-maybe))) >>> >>> +(defmacro org-babel-when-in-src-block (&rest body) >>> + `(if (or (org-babel-where-is-src-block-head) >>> + (org-babel-get-inline-src-block-matches)) >>> + (progn >>> +,@body >>> +t) >>> + nil)) >> >> (Please always add a docstring of defuns and defmacros) > > I’ll resend the patch with a docstring and fixing the commit message > problems you and Achim pointed out. > > > [...] > > >>> @@ -433,8 +436,8 @@ then run `org-babel-load-in-session'." >>> Detect if this is context for a org-babel src-block and if so >>> then run `org-babel-pop-to-session'." >>> (interactive) >>> - (let ((info (org-babel-get-src-block-info))) >>> -(if info (progn (org-babel-pop-to-session current-prefix-arg info) t) >>> nil))) >> >>> + (org-babel-when-in-src-block >>> + (org-babel-pop-to-session current-prefix-arg))) >> >> (Let's use the current name `org-babel-switch-to-session' instead of >> the obsolete alias.) > > OK. > >> >> Maybe we don't always need to pass the info as an argument, but at >> least for this last example it is needed. > > o-b-switch-to-session does nothing with the info argument but pass it > along to o-b-initiate-session, which will recalculate it if it is > missing. So it takes 2 hops in contrast to the 1 in the other cases, > but it still gets recalculated. -- Eric Schulte http://cs.unm.edu/~eschulte
[O] [solution] Chinese characters in Beamer export
FWIW, this is what it took for me to get Chinese characters to export
in beamer. (Adding a TODO to write this up for worg.)
1. Use texlive 2012. (The Ubuntu packages for 12.04 date back to 2009.
I couldn't get them to work for this.)
2. In the preamble of your org document:
#+LaTeX_HEADER: \usepackage{CJKutf8}
#+BEGIN_LaTeX
\AtBeginDocument{%
\begin{CJK}{UTF8}{gbsn}}
\AtEndDocument{%
\end{CJK}}
#+END_LaTeX
These LaTeX snippets come from the documentation of the CJK package.
"gbsn" is for simplified Chinese characters (used on the mainland).
Other options for Chinese may be found at:
http://en.wikibooks.org/wiki/LaTeX/Internationalization#Chinese
That pretty much did it (although it took quite a bit of sleuthing to
find this, thanks to a fair amount of out of date information that
will never, ever die in the big search engines).
Except for one problem. LaTeX inputenc will complain about the Chinese
characters being "not set up for use with LaTeX," but the document
does render. I'll have to leave that question aside for the moment,
but this isn't the last time I'll need Chinese characters in a
presentation so I'll come back to that before posting anything on
worg. (Or, maybe a sophisticated LaTeX user knows what is wrong?)
hjh
Re: [O] [solution] Chinese characters in Beamer export
James Harkins writes:
> FWIW, this is what it took for me to get Chinese characters to export
> in beamer. (Adding a TODO to write this up for worg.)
>
> 1. Use texlive 2012. (The Ubuntu packages for 12.04 date back to 2009.
> I couldn't get them to work for this.)
>
> 2. In the preamble of your org document:
>
> #+LaTeX_HEADER: \usepackage{CJKutf8}
>
> #+BEGIN_LaTeX
> \AtBeginDocument{%
> \begin{CJK}{UTF8}{gbsn}}
> \AtEndDocument{%
> \end{CJK}}
> #+END_LaTeX
>
> These LaTeX snippets come from the documentation of the CJK package.
> "gbsn" is for simplified Chinese characters (used on the mainland).
> Other options for Chinese may be found at:
>
> http://en.wikibooks.org/wiki/LaTeX/Internationalization#Chinese
>
> That pretty much did it (although it took quite a bit of sleuthing to
> find this, thanks to a fair amount of out of date information that
> will never, ever die in the big search engines).
>
> Except for one problem. LaTeX inputenc will complain about the Chinese
> characters being "not set up for use with LaTeX," but the document
> does render. I'll have to leave that question aside for the moment,
> but this isn't the last time I'll need Chinese characters in a
> presentation so I'll come back to that before posting anything on
> worg. (Or, maybe a sophisticated LaTeX user knows what is wrong?)
I suppose you've already considered using XeTeX? I've got this in my
style files, and it Just Works. I suppose there's more tweaking that
could be done, but I haven't had to bother so far:
\usepackage{fontspec}
\usepackage[indentfirst=false]{xeCJK}
\setCJKmainfont{AR PL New Kai}
Of course, using XeTeX isn't always an option...
Eric
Re: [O] [babel] Purpose of :results raw
On Fri, Apr 19, 2013 at 5:27 PM, Nicolas Goaziou wrote:
>
>
> Hello,
>
> "Sebastien Vauban"
> writes:
>
>> Now that ":results drawer" has been introduced, I wonder why we still have
>> ":results raw".
>>
>> As once stated in this ML:
>>
>> The sole purpose of raw results is to allow inserting an headline (I
>> mean
>> a real headline, not comma protected) in the buffer, because headlines
>> cannot be contained in anything else than headlines.
>>
>> But drawer does the same.
>
> What makes you think drawers do the same? Drawers cannot contain
> headlines.
>
But back to the original question, what does =:results raw=
accomplish? From my view, even if they *can* contain headlines, they
get exported twice, and re-running the code block just adds duplicate
output to whatever was already there. Consider this test file:
#+begin_src orgmode
* Heading
#+begin_src R :session r :results output raw :exports results
cat("* Heading2\n")
cat("This is some test text\n")
#+end_src
#+RESULTS:
* Heading2
This is some test text
#+begin_src R :session r :results output drawer :exports results
cat("* Heading3\n")
cat("This is some test text\n")
#+end_src
#+RESULTS:
:RESULTS:
* Heading3
This is some test text
:END:
* Heading 4
#+begin_src R :session r :results output drawer :exports results
cat("This is some test text\n")
#+end_src
#+RESULTS:
:RESULTS:
This is some test text
:END:
#+end_src
"** Heading2" gets exported twice, and the :RESULTS: and :END: drawer
property indicators are also being exported. Yes, I can delete the
=:results raw= output, but that's time consuming, especially as one
tweaks code and re-evaluates to check the results. One has to do this
every time not to flood the document with duplicate results.
See Eric Schulte's response here:
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
I was getting multiple instance with =:results output raw= and was
instructed to use =:results output org= for the very reason that it
would be able to discern the output and replace it upon subsequent
block evaluations.
Now consider this recent thread:
- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg70016.html
The gist of that long discussion is that =:results output org= was
replaced by =:results output drawer=, but it seems we haven't
recreated all of the existing functionality. There's another thread
out there in which for a while it was to be =:results output wrap=
and/or =:wrap org= in order to do something like this (output actual
Org-mode syntax from a code block and have it exported as if it was
actually written in the document).
There are instances where I'd like to generate numerous plots and then
create subheadings for the various iterations of my loops, so having
the ability to actual print "** Subheading" to a results block and
have it exported would be useful. Seems that =:results raw= is now the
only way to do that, and export only works if you delete whatever
results are down there already prior to doing so.
Let me know if there's another/better way.
Thanks,
John
>
> Regards,
>
> --
> Nicolas Goaziou
>
>
