Re: [O] Columns with marking characters are exported to latex (Org 8)
Hello, Nick Dokos writes: > That leaves the somewhat counterintuitive case of a completely empty > first column which is therefore deemed special and gets stripped. This > could be "fixed" as a special case but instead I propose to document that > behaviour in the above section, with a suggested workaround: if you > really, really want an empty first column, then add a second one. An empty first column shouldn't be considered as special. "ox.el" handles this case fine (see `org-export-table-has-special-column-p'). This is not the case yet for radio tables. Note that the goal is to use "ox.el" in radio tables. Regards, -- Nicolas Goaziou
Re: [O] How to get cookies working with TODOs?
Eric Abrahamsen writes: > Sharon Kimble writes: > >> I'm trying to get cookies working with TODO items. The source document >> is a book I'm writing and is an outline of each section and chapters so >> that I can see what is still to be done. I'm writing it in latex but >> doing the outline in orgs-mode. >> >> * TODO CHAPTER 1 - preface [0%] >> ** DONE Disclaimer >> CLOSED: [2014-07-30 Wed 23:49] >> ** DONE Introduction >> CLOSED: [2014-07-30 Wed 23:50] >> >> >> Following "5.5 Breaking tasks down into subtasks" in the "org.pdf" I >> should be able to 'C-c C-c' on the cookie and it updates the cookie, >> except it doesn't work in this case. There are 5 sections which are all >> completed in this chapter, but the cookie doesn't update. >> >> * TODO CHAPTER 2 - preamble [0/11] [0%] >> :PROPERTIES: >> :COOKIE_DATA: todo recursive >> :END: >> ** DONE An overview of the endocrine system >> CLOSED: [2014-07-31 Thu 02:12] >> >> Like it shows on page 55. But the cookie doesn't update either in this case. > > Hmm, I just tried your example above, and it worked just fine. I didn't > even need to hit C-c C-c, just adding TODOs and toggling their state > updated the cookie automatically. I'm using Org-mode version 8.3beta > (release_8.3beta-232-g644e60 @ /home/eric/.emacs.d/org-mode/lisp/) > > Are you using a relatively recent Org? > Eric - I'm using "Org-mode version 8.2.7c (release_8.2.7c @ /home/boudiccas/git/org-mode/lisp/)", which is fairly recent so should be okay. Hmm, if they work for you then its something in my set-up. And after having a play, the cookie is only changed when it is toggled [C-c C-t] to "Waiting" which then shows --8<---cut here---start->8--- ** WAITING Anise CLOSED: [2014-08-20 Wed 10:29] --8<---cut here---end--->8--- And only _waiting_ shows as closed, none of these other conditions do - --8<---cut here---start->8--- #+TODO: TODO DONE NEXT IN-PROGRESS NOTES FIXME WAITING --8<---cut here---end--->8--- The conditions are set specifically for this one file, and I've just reverted to a previous 'setq org-todo-keyword-faces' and that now shows those sections marked as 'DONE' as being closed. If I 'C-c C-c' a TODO item, whether showing as "TODO/DONE/whatever" it triggers the setting of 'org-tags'! So something is screwy there, but I don't know what! But it does not trigger the insertion of "CLOSED:" Nick - I do have 'org-provide-todo-statistics' set to "t" I've just uploaded my 'setup-orgmode.el' file to my bitbucket, at "https://bitbucket.org/boudiccas/dots/src/d1c750572c9367c3d86b5a1f9cfa200e07e9d988/emacs/setup-orgmode.el?at=master"; and I would be very grateful if anybody could tell me where I'm going wrong, and then how to put it right, please? I think that the problems all stem from my set-up, but I can't see exactly where. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.3.92.1 signature.asc Description: PGP signature
[O] Agenda ical export omissions: sexp, hour-in-headline
I have a shell function that exports my agenda to an ical file and uploads it for Google to read; however, there seem to be a couple glaring omissions from the ical. Here's the bash line that works over my agenda for export: emacs --batch --user $USER --eval "(progn (org-agenda-list nil nil 'year) (org-icalendar-combine-agenda-files))" It skips the following sort of agenda entries: *** 09:05-09:55 CS 7637 Weekly Class @ Klaus 2447 <%%(org-class 2014 8 18 2014 12 12 1)> and: %%(org-anniversary 2015 03 26) Glory %d Birthday So, it doesn't seem to ical-ify sexp dates, and it doesn't seem to do times (09:05-09:55) in the headers. Is there anything to be done for this? I've just discovered the agenda power of these mighty functions but will be limited in my use of them if they can't be exported. - Tory
Re: [O] How to get cookies working with TODOs?
On Wednesday, 20 Aug 2014 at 11:46, Sharon Kimble wrote: [...] > Hmm, if they work for you then its something in my set-up. And after > having a play, the cookie is only changed when it is toggled [C-c C-t] to > "Waiting" which then shows > > ** WAITING Anise > CLOSED: [2014-08-20 Wed 10:29] > > > And only _waiting_ shows as closed, none of these other conditions do - > > #+TODO: TODO NEXT IN-PROGRESS NOTES FIXME | WAITING DONE > > The conditions are set specifically for this one file, and I've just > reverted to a previous 'setq org-todo-keyword-faces' and that now shows > those sections marked as 'DONE' as being closed. > > If I 'C-c C-c' a TODO item, whether showing as "TODO/DONE/whatever" it > triggers the setting of 'org-tags'! So something is screwy there, but I > don't know what! But it does not trigger the insertion of "CLOSED:" It probably has to do with the fact that you haven't put a "|" anywhere so only the WAITING type is one that indicates a completed task? Look at the Workflow states section of the manual. Something like this might work better for you: #+TODO: TODO NEXT IN-PROGRESS NOTES FIXME | WAITING DONE Note the move of DONE to the end and the addition of |. The important thing about the move of DONE is not that it be last but that it be placed after the |. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.1, Org release_8.3beta-246-g77d0da
Re: [O] Columns with marking characters are exported to latex (Org 8)
Nicolas Goaziou writes: > Hello, > > Nick Dokos writes: > >> That leaves the somewhat counterintuitive case of a completely empty >> first column which is therefore deemed special and gets stripped. This >> could be "fixed" as a special case but instead I propose to document that >> behaviour in the above section, with a suggested workaround: if you >> really, really want an empty first column, then add a second one. > > An empty first column shouldn't be considered as special. "ox.el" > handles this case fine (see `org-export-table-has-special-column-p'). > This is not the case yet for radio tables. > OK - I'll special-case it in org-table-clean-before-export then for now. > Note that the goal is to use "ox.el" in radio tables. > Thanks! -- Nick
[O] org-element-at-point fails in programming-modes
Hi List, with point at the beginning of each of the following blocks, `org-element-at-point' does recognize the correct type when buffer is in org-mode and other text-modes, but not so in programming modes, e.g. the *scratch* buffer (lisp-interaction-mode). Then only the src-block is recognized correctly, all the others are parsed as paragraphs. * ORG SCRATCH #+BEGIN_QUOTE hallo world #+END_QUOTE #+BEGIN_COMMENT hallo world #+END_COMMENT #+BEGIN_EXAMPLE hallo world #+END_EXAMPLE #+BEGIN_SRC emacs-lisp hallo world #+END_SRC Although Org functions are of course made only for working in org-mode and its a bit hard to see at first sight how this could be useful, I wonder if the regexps could be made a bit more general to make `org-element-at-point' work in programming modes too (most likely this behaviour is caused by references to character-classes that differ in text-modes and programming-modes)? -- cheers, Thorsten
Re: [O] How to get cookies working with TODOs?
Sharon Kimble writes: > > ** WAITING Anise > CLOSED: [2014-08-20 Wed 10:29] > > > And only _waiting_ shows as closed, none of these other conditions do - > > #+TODO: TODO DONE NEXT IN-PROGRESS NOTES FIXME WAITING > > ... > > I think that the problems all stem from my set-up, but I can't see exactly > where. > That should probably be #+TODO: TODO NEXT IN-PROGRESS NOTES FIXME WAITING | DONE See (info "(org) TODO keywords as workflow states") -- Nick
Re: [O] org-element-at-point fails in programming-modes
Thorsten Jolitz writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are gone and it looks like this: > * ORG SCRATCH > > #+BEGIN_QUOTE > hallo world > #+END_QUOTE > #+BEGIN_COMMENT > hallo world > #+END_COMMENT > #+BEGIN_EXAMPLE > hallo world > #+END_EXAMPLE > #+BEGIN_SRC emacs-lisp > hallo world > #+END_SRC Am I the only one seeing this? Bug in gnus/message mode? -- cheers, Thorsten
Re: [O] org-element-at-point fails in programming-modes
Thorsten Jolitz writes: > Thorsten Jolitz writes: > > As a side-remark, I did send these blocks with emptly lines between them, > and when I look at my post in gmane the format looks alright, however > when I open it in gnus the empty lines are gone and it looks like this: > >> * ORG SCRATCH >> >> #+BEGIN_QUOTE >> hallo world >> #+END_QUOTE >> #+BEGIN_COMMENT >> hallo world >> #+END_COMMENT >> #+BEGIN_EXAMPLE >> hallo world >> #+END_EXAMPLE >> #+BEGIN_SRC emacs-lisp >> hallo world >> #+END_SRC > > Am I the only one seeing this? Bug in gnus/message mode? I see empty lines between the blocks in gnus. -- Nick
Re: [O] org-element-at-point fails in programming-modes
> Although Org functions are of course made only for working in org-mode
> and its a bit hard to see at first sight how this could be useful, I
> wonder if the regexps could be made a bit more general to make
> `org-element-at-point' work in programming modes too (most likely this
> behaviour is caused by references to character-classes that differ in
> text-modes and programming-modes)?
The reason is that a newline has the "endcomment" syntax in programming
modes, but has "whitespace" syntax in text modes. So the regexp
"\\+BEGIN_\\(\\S-+\\)" (which can be found in org-element.el) matches
e.g. "+BEGIN_QUOTE\nhallo" instead of just "+BEGIN_QUOTE".
("\\S-" means "anything that doesn't have whitespace syntax")
You could wrap your code in a (with-syntax-table org-mode-syntax-table
...) and cross fingers, or simply do the (org-element-at-point)
computations in a temporary (org-mode) buffer.
HTH,
--
Nico.
Re: [O] org-element-at-point fails in programming-modes
Thorsten Jolitz writes: > Am I the only one seeing this? Bug in gnus/message mode? I also see the problem. I suspect that it happens when Gnus fontifies the blocks. Doing "C-u g" shows that the "source" of the message is correct (i.e. has the newlines). -- Nico.
Re: [O] org-element-at-point fails in programming-modes
Nick Dokos wrote: > Thorsten Jolitz writes: >> Thorsten Jolitz writes: >> >> As a side-remark, I did send these blocks with emptly lines between them, >> and when I look at my post in gmane the format looks alright, however >> when I open it in gnus the empty lines are gone and it looks like this: >> >>> * ORG SCRATCH >>> >>> #+BEGIN_QUOTE >>> hallo world >>> #+END_QUOTE >>> #+BEGIN_COMMENT >>> hallo world >>> #+END_COMMENT >>> #+BEGIN_EXAMPLE >>> hallo world >>> #+END_EXAMPLE >>> #+BEGIN_SRC emacs-lisp >>> hallo world >>> #+END_SRC >> >> Am I the only one seeing this? Bug in gnus/message mode? > > I see empty lines between the blocks in gnus. I don't see the empty lines, like Thorsten. While, if you look at the raw message (C-u g, in Gnus), I see well that you had separated the blocks. If Nick does not see the problem, that must be a bug in our configs? Best regards, Seb -- Sebastien Vauban
[O] [PATCH] Make the regexp matching the beginning of a table more explicit
Hi,
I would like to provide a very tiny change in the regexp matching a
beginning of table in org-table.el.
Its current value is "^\\(\\*+ \\)\\|[ \t]*|". The second part of the
regexp ("[ \t]*|") indicates that it matches any | character, following
spaces or not. This means that the "[ \t]" is useless.
Actually, it matches my :tags expression in the #+BEGIN: clocktable part
because its value is :tags "@home|@computer".
I think that Carsten Dominik wanted the | character to be matched only
when at the beginning of a line (modulo indentation spaces).
I then added the ^ character in this part of the regexp to make it work
that way.
Please find the patch attached.
From 04fe96d8782719b2ef90afd16c6b3dcfbd9349c6 Mon Sep 17 00:00:00 2001
From: Konubinix
Date: Wed, 20 Aug 2014 14:32:47 +0200
Subject: [PATCH] Make the regexp matching the beginning of a table more
explicit
* org-table.el (org-table-get-remote-range): Make the regexp matching the
beginning of a table more explicit, all | characters were matched, even those
contained into the :tags value (like in :tags "@home|@computer"). This caused
the | character to be interpreted as the beginning of a line. Now, the | is
matched only if it is at the beginning at a line (modulo beginning spaces).
---
lisp/org-table.el | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lisp/org-table.el b/lisp/org-table.el
index d1609f9..5654783 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -42,7 +42,7 @@
(string backend &optional body-only ext-plist))
(declare-function aa2u "ext:ascii-art-to-unicode" ())
(declare-function calc-eval "calc" (str &optional separator &rest args))
-
+
(defvar orgtbl-mode) ; defined below
(defvar orgtbl-mode-menu) ; defined when orgtbl mode get initialized
(defvar constants-unit-system)
@@ -2768,7 +2768,7 @@ not overwrite the stored one."
(user-error "Invalid field specifier \"%s\""
(match-string 0 form)))
(setq form (replace-match formrpl t t form)))
-
+
(if lispp
(setq ev (condition-case nil
(eval (eval (read form)))
@@ -5053,7 +5053,7 @@ list of the fields in the rectangle."
(widen)
(goto-char loc)
(forward-char 1)
- (unless (and (re-search-forward "^\\(\\*+ \\)\\|[ \t]*|" nil t)
+ (unless (and (re-search-forward "^\\(\\*+ \\)\\|^[ \t]*|" nil t)
(not (match-beginning 1)))
(user-error "Cannot find a table at NAME or ID %s" name-or-id))
(setq tbeg (point-at-bol))
--
2.0.1
--
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A
pgpWYPfLyerkh.pgp
Description: PGP signature
Re: [O] org-element-at-point fails in programming-modes
Nicolas Richard writes:
>> Although Org functions are of course made only for working in org-mode
>> and its a bit hard to see at first sight how this could be useful, I
>> wonder if the regexps could be made a bit more general to make
>> `org-element-at-point' work in programming modes too (most likely this
>> behaviour is caused by references to character-classes that differ in
>> text-modes and programming-modes)?
>
> The reason is that a newline has the "endcomment" syntax in programming
> modes, but has "whitespace" syntax in text modes. So the regexp
> "\\+BEGIN_\\(\\S-+\\)" (which can be found in org-element.el) matches
> e.g. "+BEGIN_QUOTE\nhallo" instead of just "+BEGIN_QUOTE".
> ("\\S-" means "anything that doesn't have whitespace syntax")
Yes, thats more or less what I expected to be the root cause of the problem.
> You could wrap your code in a (with-syntax-table org-mode-syntax-table
> ...) and cross fingers, or simply do the (org-element-at-point)
> computations in a temporary (org-mode) buffer.
Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
mandatory, couldn't a more robust construct be used, either something
like this (untested) regexp:
,
| "[^[:space:]\\n]+"
`
or a custom character-class that consists of whitespace plus newline?
--
cheers,
Thorsten
Re: [O] org-element-at-point fails in programming-modes
Sebastien Vauban writes: > Nick Dokos wrote: >> Thorsten Jolitz writes: >>> Thorsten Jolitz writes: >>> >>> As a side-remark, I did send these blocks with emptly lines between them, >>> and when I look at my post in gmane the format looks alright, however >>> when I open it in gnus the empty lines are gone and it looks like this: >>> * ORG SCRATCH #+BEGIN_QUOTE hallo world #+END_QUOTE #+BEGIN_COMMENT hallo world #+END_COMMENT #+BEGIN_EXAMPLE hallo world #+END_EXAMPLE #+BEGIN_SRC emacs-lisp hallo world #+END_SRC >>> >>> Am I the only one seeing this? Bug in gnus/message mode? >> >> I see empty lines between the blocks in gnus. > > I don't see the empty lines, like Thorsten. > ... and on a different machine, I don't see them either. Now I have to figure out what's different between them. Nick
Re: [O] "#+begin_src R :results output drawer" doesn't work.
when i remove recentf catch file, it's ok. thank.---Original---From: "Aaron Ecay"Date: 2014/08/13 14:19:01To: "Feng Shu";"emacs-orgmode";Subject: Re: [O] "#+begin_src R :results output drawer" doesn't work.Hi Feng, 2014ko abuztuak 9an, Feng Shu-ek idatzi zuen: > > #+begin_src R :results output drawer > "1" > "2" > #+end_src > > #+RESULTS: > : 2 > Like Eric, I cannot reproduce this behavior. Can you send us the output of the following code block, to check the exact version of org that is giving you this unexpected result? #+BEGIN_SRC emacs-lisp (org-version nil t) #+END_SRC Thanks, -- Aaron Ecay
Re: [O] Columns with marking characters are exported to latex (Org 8)
* Nick Dokos, 20.08.2014 18:34:15: That leaves the somewhat counterintuitive case of a completely empty first column which is therefore deemed special and gets stripped. This could be "fixed" as a special case but instead I propose to document that behaviour in the above section, with a suggested workaround: if you really, really want an empty first column, then add a second one. this is a programming problem, which exceeds by far my horizons, so I can not say much about this, it was just important for me to point out the problem, sorry, I think here I can not help . but of course I can live with your solution no matter what it looks like... Regards Thorsten * Deutsch - erkannt * Englisch * Englisch
Re: [O] Columns with marking characters are exported to latex (Org 8)
Thorsten Grothe writes: > * Nick Dokos, 20.08.2014 18:34:15: > >> That leaves the somewhat counterintuitive case of a completely empty >> first column which is therefore deemed special and gets stripped. This >> could be "fixed" as a special case but instead I propose to document that >> behaviour in the above section, with a suggested workaround: if you >> really, really want an empty first column, then add a second one. > > this is a programming problem, which exceeds by far my horizons, so I > can not say much about this, it was just important for me to point out > the problem, sorry, I think here I can not help . but of course I > can live with your solution no matter what it looks like... > As Nicolas pointed out, I can't get away with just documenting the behaviour, so I plan to: o revert the previous patch - that will make your latest example work, but it will break your previous example (but you can work around it for now by adding an extra empty column 1). I'll do the revert tonight. o then (probably this weekend) work on special-casing the empty column case in org-table-clean-before-export, which will get rid of the necessity of using the workaround above. -- Nick
Re: [O] Stop export on bad link?
On Sun, Jul 27, 2014 at 7:27 AM, Bastien wrote:
> Hi Jacob,
>
> Jacob Gerlach writes:
>
> > Is it possible to configure the exporter to stop and throw an error
> > for a bad link?
>
> No. But what is really a "bad link"? Is it bad because it cannot be
> exported to a specific backend?
>
By bad, I meant a link that can't be resolved (perhaps because of a typo).
Org already handles this by formatting the "bad" link with texttt in latex.
For example:
-
* First
In [[frst]], we see the ECM.
-
Exports to:
-
\section{First}
\label{sec-1}
In \texttt{frst}, we see the ECM.
-
Whereas
* First
In [[First]], we see the ECM.
exports as:
\section{First}
\label{sec-1}
In \ref{sec-1}, we see the ECM.
After further digging, I found org-latex-link-with-unknown-path-format.
Since I usually export directly to pdf, I can achieve my desired result by
customizing this variable to some undefined control sequence (i.e.
\BADLINK), in which case latex complains, but I have to hunt down the error
in the *Org PDF LaTeX Output* buffer. It would be great if the export would
just quit and move point to the offending link
>
> --
> Bastien
>
[O] problem with markdown exporter
I've turn on Markdown exporting with (require 'ox-md). Citations aren't
being exported properly, so I'm trying to customize it. I have the
following setup:
(org-add-link-type
"textcite" (lambda (key) (org-open-file cby-references-file t nil key))
(lambda (path desc format)
(cond
((eq format 'latex) (format "\\textcite{%s}" path))
((eq format 'md) (format "[@%s]" path))
((eq format 'odt) (format "%s" desc))
((eq format 'html) (format "%s" path))
)))
Which works for latex, odt, and hml. But it doesn't appear that the
format string is ever being set to 'md, and so the [[cite:foo][Foo,
]] in my org file isn't getting converted to [@foo].
Searching online I find many strings matching "(eq format 'odt)" or
'latex but none with 'md. Is there some other way to achieve this?
Thanks,
-k.
[O] LATEX_HEADER export problem
Hi,
I have the following in a file that I export to LaTeX
#+LATEX_CLASS: mysetup
#+LATEX_HEADER: \newcommand{\RATE}{65.00}
mysetup class
(add-to-list 'org-latex-classes
'("mysetup"
"\\documentclass[11pt,letterpaper,oneside]{scrartcl}
\\usepackage{verbatim}
% \\usepackage[T1]{fontenc}
% \\usepackage{charter,parskip,setspace,layout} commented out for Komascript
\\usepackage{charter,setspace,layout}
\\usepackage{array,graphicx}
\\usepackage{tabularx,tabulary}
\\usepackage{longtable}
\\usepackage{numprint}
\\npstyleenglish
\\usepackage[at]{easylist}
\\usepackage{csquotes}
%\\usepackage[letterpaper,margin=1.00in]{geometry}
\\usepackage[letterpaper,left=1.00in,right=1.00in,top=1.00in,bottom=0.50in]{geometry}
% \\usepackage[top=1.0in,bottom=0.4in,left=1.2in,nohead]{geometry}
%\\pagestyle{empty}
\\pagenumbering{arabic}
%\\newcommand\\foo{bar}
[NO-DEFAULT-PACKAGES]
[NO-PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
When I export the pdf is generated, however with an error; the following
output to the *.tex results
ss[11pt,letterpaper,oneside]{scrartcl}
\usepackage{verbatim}
% \usepackage[T1]{fontenc}
% \usepackage{charter,parskip,setspace,layout}
\usepackage{charter,setspace,layout}
\usepackage{array,graphicx}
\usepackage{tabularx,tabulary}
\usepackage{longtable}
\usepackage{numprint}
\npstyleenglish
\usepackage[at]{easylist}
\usepackage{csquotes}
%\usepackage[letterpaper,margin=1.00in]{geometry}
\usepackage[letterpaper,left=1.00in,right=1.00in,top=1.00in,bottom=0.50in]{geometry}
% \usepackage[top=1.0in,bottom=0.4in,left=1.2in,nohead]{geometry}
%\pagestyle{empty}
\pagenumbering{arabic}
%\newcommand\foo{bar}
\newcommand{\RATE}{65.00}
\newcommand{\RATE}{65.00}
\newcommand{\RATE}{65.00}
\date{}
Note - the triple |newcommand{\RATE}{65.00} is present
whether\newcommand\foo{bar} is commented or uncommented in mysetup
When *.tex is typset there are two "\RATE already defined" errors.
I have searched around for an answer/solution. Any suggestions?
As I said, the pdf is still typeset; all I want is to be rid of this error.
Charlie Millar
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Re: [O] ob-lilypond code cleanup
Nicolas Goaziou writes: > FWIW, I think prefix conformance should go to maint. Patch has been split and just the prefix conformance committed to maint in b8bd2147cb. Introduction of defcustom, some code cleanups and associated tests committed to master in 64821bd967. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Thierry Banel writes:
> You are trying to create a C++ project bigger than a few lines, in Org-mode.
> This is very close to the idea of "literate programming" from Donal Knuth.
> You may find inspiration here:
> http://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming
>
> There is an example of a "hello world" shell project split over three source
> blocks.
> Here it is translated from Shell to C++ (try it, it works):
>
> #+name: hello-world-prefix
> #+begin_src C++ :exports none
> printf ("/---\\\n");
> #+end_src
>
> #+name: hello-world-postfix
> #+begin_src C++ :exports none
> printf ("\\---/\n");
> #+end_src
>
> #+name: hello-world-main-begin
> #+begin_src C++ :exports none
> #include
> int main()
> {
> #+end_src
>
> #+name: hello-world-main-end
> #+begin_src C++ :exports none
> return 0;
> }
> #+end_src
>
> #+name: hello-world
> #+begin_src C++ :tangle hello :exports none :noweb yes :results output
> <>
> <>
> printf ("| hello world |\n");
> <>
> <>
> #+end_src
>
> #+RESULTS: hello-world
> : /---\
> : | hello world |
> : \---/
Really interesting. We can take some blocks and combine them inside
a source block. Thanks for this information.
Another question if you allow me ?
Looking at code in Ob-C you transform a table/list variable in a C array
of char*. Should it not be std::wstring ? some unicode string ?
Best Ernesto
[O] file-truename: Variable binding depth exceeds max-specpdl-size when tangling
Good afternoon, While debugging one of my babel documents, I re-read [this] documentation on `:noweb-ref'. What I had wanted to do was to define a bunch of source blocks and then at the end of the heading to tangle them all into a file. This was just a natural thing to do while /in the flow/ and *not* thinking about the document structure. Here is the simplest possible example. , | | * Demo | :PROPERTIES: | :noweb-ref: demo | :END: | | #+begin_src emacs-lisp | (message "demo") | #+end_src | | #+begin_src emacs-lisp | (message "this") | #+end_src | | #+begin_src sh :tangle ~/tmp/demo.el :noweb yes | «demo» | #+end_src ` When you try and tangle this, you get the error: file-truename: Variable binding depth exceeds max-specpdl-size You can increase the size but it will run out: ╭ │ (setq max-specpdl-size 1500) ╰ Feel like I have caused an endless loop by asking babel to collect all references to `demo' and place them inside of a sourceblock, when that sourceblock itself will be collected. That said, I'm not sure where to go next and simply moved it up one heading. Questions: • What did I do wrong here? • Am I the only one to ever encounter this? • Web search did not reveal a lot quickly Here is the org and emacs version ╭ │ (org-version nil t) ╰ ╭ │ Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpaplus @ /Users/gcr/.emacs.d/.cask/24.3.1/elpa/org-plus-contrib-20140811/) ╰ ╭ │ (emacs-version) ╰ ╭ │ GNU Emacs 24.3.1 (x86_64-apple-darwin13.2.0, Carbon Version 1.6.0 AppKit 1265.2) │ of 2014-07-03 on orion ╰ Kind regards, gcr
Re: [O] file-truename: Variable binding depth exceeds max-specpdl-size when tangling
Hi Grant, 2014ko abuztuak 20an, Grant Rettke-ek idatzi zuen: > > Good afternoon, > > While debugging one of my babel documents, I re-read [this] > documentation on `:noweb-ref'. > > What I had wanted to do was to define a bunch of source blocks and then > at the end of the heading to tangle them all into a file. This was just > a natural thing to do while /in the flow/ and *not* thinking about the > document structure. > > Here is the simplest possible example. > > , > | > | * Demo > | :PROPERTIES: > | :noweb-ref: demo > | :END: > | > | #+begin_src emacs-lisp > | (message "demo") > | #+end_src > | > | #+begin_src emacs-lisp > | (message "this") > | #+end_src > | > | #+begin_src sh :tangle ~/tmp/demo.el :noweb yes > | «demo» > | #+end_src > ` Because the to-be-tangled code block is also under the headline with the :noweb-ref property, it will try to include itself inside itself, leading to an infinite regress. Adding a headline before the third code block fixes the issue. -- Aaron Ecay
[O] [PATCH] ox-latex: fix lost export option latex-custom-id-labels
Hi everyone, I recently pulled from master and noticed that an option in the LaTeX export backend that I rely on had gotten lost in the shuffle. (I didn't check the history, but I believe it must have been removed accidentally, since the code that checks this option is still there.) Here is a patch to re-introduce it. Thanks! Best, Richard >From 0b351bfc2e494bb010a4c27768a5ccd2ae846367 Mon Sep 17 00:00:00 2001 From: Richard Lawrence Date: Wed, 20 Aug 2014 16:55:50 -0700 Subject: [PATCH] ox-latex: fix lost export option * lisp/ox-latex.el (latex): reintroduce `latex-custom-id-labels' option in backend TINYCHANGE --- lisp/ox-latex.el |1 + 1 file changed, 1 insertion(+) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 6ea35c5..c14d6dc 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -110,6 +110,7 @@ ;; Other variables. (:latex-active-timestamp-format nil nil org-latex-active-timestamp-format) (:latex-classes nil nil org-latex-classes) +(:latex-custom-id-labels nil nil org-latex-custom-id-as-label) (:latex-default-figure-position nil nil org-latex-default-figure-position) (:latex-default-table-environment nil nil org-latex-default-table-environment) (:latex-default-table-mode nil nil org-latex-default-table-mode) -- 1.7.10.4
Re: [O] [RFC] Rewrite `org-entry-properties' using parser
Nicolas Goaziou writes: Hello, > You may want to read my answer again. There is no "write this, write > that" in it. I'm pointing out what is missing or flawed and _suggesting_ > alternative approaches. I appreciate your comments and input, but unfortunately I gave up on the original idea because I did not want to make another "much more time consuming than planned" side-project out of this. >> so I rather leave this to you (or whoever wants to do it). > Unfortunately, my plate is full at the moment. Ok, so I simplified the task and wrote ,[ C-h f org-dp-filter-node-props RET ] | org-dp-filter-node-props is a Lisp function in `org-dp-lib.el'. | | (org-dp-filter-node-props FILTER &optional NEGATE-P SILENT-P) | | Return filtered node-properties. | FILTER should either be the car of one of the cons-pairs in | `org-dp-prop-filters' or a regexp-string. If NEGATE-P is non-nil, | the properties not matched by the filter are returned. If | SILENT-P is non-nil, no message is printed if no property-drawer | is found. ` - this function acts on element-type 'node-property', not 'headline' - it does not attempt to replace `org-entry-properties' or to be compatible with its signature, its written from scratch. but it does what I want - make it easy to filter out application properties and user defined properties from the usual property-mix found in property drawers. It relies on the following constants: ,[ C-h v org-dp-prop-filters RET ] | org-dp-prop-filters is a variable defined in `org-dp-lib.el'. | Its value is ((special . org-special-properties) | (custom . org-custom-properties) | (default . org-default-properties) | (file . org-file-properties) | (global mapcar 'car org-global-properties) | (org) | (user-defined)) | | Alist of filter-types and associated property-classes. ` (do I miss an Org property class here?) ,[ C-h v org-dp-org-props RET ] | org-dp-org-props is a variable defined in `org-dp-lib.el'. | [...] | Union of special, custom, file and global properties, as well | as those properties specified by the user in customizable | variable `org-dp-misc-props'. ` Thus given the following Org headline two typical function calls would be: #+BEGIN_SRC emacs-lisp :results raw (save-excursion (outline-next-heading) (org-dp-filter-node-props "^foo-.")) #+END_SRC #+results: ((foo-star . star1) (foo-bar . bar1)) #+BEGIN_SRC emacs-lisp :results raw (save-excursion (outline-next-heading) (org-dp-filter-node-props 'org t)) #+END_SRC #+results: ((cho-bar . bar2) (foo-star . star1) (foo-bar . bar1)) * ORG SCRATCH :PROPERTIES: :CUSTOM_ID: abc123 :CATEGORY: mycat :foo-bar: bar1 :foo-star: star1 :cho-bar: bar2 :END: PS For completeness I attach the code: #+BEGIN_SRC emacs-lisp (defun org-dp-filter-node-props (filter &optional negate-p silent-p) "Return filtered node-properties. FILTER should either be the car of one of the cons-pairs in `org-dp-prop-filters' or a regexp-string. If NEGATE-P is non-nil, the properties not matched by the filter are returned. If SILENT-P is non-nil, no message is printed if no property-drawer is found." (let ((props (save-excursion (and (or (org-at-heading-p) (outline-previous-heading)) (re-search-forward org-property-drawer-re nil 'NOERROR 1) (progn (goto-char (match-beginning 0)) (org-dp-contents) filtered-props) (if (not props) (unless silent-p (message "Could not find properties at point %d in buffer %s." (point) (current-buffer))) (org-element-map props 'node-property (lambda (--prop) (let* ((key (org-element-property :key --prop)) (val (org-element-property :value --prop)) (memberp (case filter ((special custom default file global) (member-ignore-case key (eval (cdr-safe (assoc filter org-dp-prop-filters) (org (member-ignore-case key org-dp-org-props)) (t (if (stringp filter) (string-match filter key) (error "Not a valid filter: %s" filter)) (when (or (and negate-p (not memberp)) (and (not negate-p) memberp)) (setq filtered-props (cons (cons key val) filtered-props)) filtered-props))) #+END_SRC -- cheers, Thorsten
Re: [O] [PATCH] ox-latex: fix lost export option latex-custom-id-labels
Hi Richard, 2014ko abuztuak 20an, Richard Lawrence-ek idatzi zuen: > > Hi everyone, > > I recently pulled from master and noticed that an option in the LaTeX > export backend that I rely on had gotten lost in the shuffle. (I didn't > check the history, but I believe it must have been removed accidentally, > since the code that checks this option is still there.) Here is a patch > to re-introduce it. > This option was lost in commit 7a956c38, and indeed its removal looks like an accident. I pushed your patch. Thanks for your vigilance, -- Aaron Ecay
