Re: [O] [PATCH] ob-shell
Hello, I have a little patch (attached) that does check the version of bash, and uses associative arrays (or doesn't) depending on that version. The problem now is that the test suite will only work on one platform t a time, i.e. if there is a bash4 there, it will pass, but if it has bash3, it will work as intended, but return a different value set. Is there a way to have platform-dependent tests ? --Pascal On Wed, Aug 13, 2014 at 3:29 PM, Alan Schmitt alan.schm...@polytechnique.org wrote: On 2014-08-13 15:20, Pascal Fleury fle...@google.com writes: Yes, sorry for late reaction (it's holiday season here :-). Funny, it's holiday season here as well (in Bretagne) ;-) This is an issue I introduced with the assoc. arrays, which does not verify if the installed version of bash handles them (from bash4 on). It needs a modification in the setup code that checks the version and only issues assoc. array code when bash supports it. And it so happens that Macs have bash3 installed. Will try to find such a machine and add the test. Thanks a lot. If I can help, please let me know. Best, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 -- --paf 0001-ob-shell-now-checks-for-the-current-bash-version-bef.patch Description: Binary data
Re: [O] org-element-at-point fails in programming-modes
Nick Dokos ndo...@gmail.com writes:
Nick Dokos ndo...@gmail.com writes:
Sebastien Vauban sva-n...@mygooglest.com
writes:
Nick Dokos wrote:
Thorsten Jolitz tjol...@gmail.com writes:
Thorsten Jolitz tjol...@gmail.com 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.
One machine is running Gnus v. 5.13: that one smooshes the code
blocks together.
The other is running Ma Gnus v. 0.12: that one leaves empty
lines between blocks.
Maybe they switched to the new parser between versions, that parses a
src-block with :post-blank's, but does not take them into account when
interpreting?
,[ C-h f mm-display-inline-fontify RET ]
| mm-display-inline-fontify is a compiled Lisp function in `mm-view.el'.
|
| (mm-display-inline-fontify HANDLE optional MODE)
|
| Insert HANDLE inline fontifying with MODE.
| If MODE is not set, try to find mode automatically.
`
is responsable here, and if we would find the place where 'handle' is
parsed (I couldn't in reasonable time) we would probably know what is
the problem ('handle' is the src-block in this case, 'mode' is 'org').
--
cheers,
Thorsten
Re: [O] export for Beamer with author options
Hello, Aaron Ecay aarone...@gmail.com writes: You’re right...I inadvertently tested the proposed solution with the latex backend, but it turns out there’s a small difference between how the latex and beamer backends calculate their \author. I think both backends should behave identically here and that the latex behavior is more correct (i.e. #+options: author:nil suppresses generation of \author entirely), and the attached patch makes beamer follow latex’s lead. OK. Please apply. Thank you. Regards, -- Nicolas Goaziou
Re: [O] LATEX_HEADER export problem
Hello,
Charles Millar mill...@verizon.net writes:
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
[...]
Note - the triple |newcommand{\RATE}{65.00} is present
whether\newcommand\foo{bar} is commented or uncommented in mysetup
I cannot reproduce the problem.
Regards,
--
Nicolas Goaziou
Re: [O] [babel][PATCHES] exporting inline source code
Hello, Nicolas Berthier nbe...@member.fsf.org writes: Indeed. I fixed it in the new attached patch. Thanks. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] export for Beamer with author options
I realize you were responding to Aaron on this, but for my own education, how does on apply? Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Aaron Ecay aarone...@gmail.com writes: You’re right...I inadvertently tested the proposed solution with the latex backend, but it turns out there’s a small difference between how the latex and beamer backends calculate their \author. I think both backends should behave identically here and that the latex behavior is more correct (i.e. #+options: author:nil suppresses generation of \author entirely), and the attached patch makes beamer follow latex’s lead. OK. Please apply. Thank you. Regards,
Re: [O] org-element-at-point fails in programming-modes
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Nick Dokos ndo...@gmail.com writes: One machine is running Gnus v. 5.13: that one smooshes the code blocks together. The other is running Ma Gnus v. 0.12: that one leaves empty lines between blocks. Do they both fontify blocks ? Yes. -- Nick
Re: [O] export for Beamer with author options
torys.ander...@gmail.com (Tory S. Anderson) writes: I realize you were responding to Aaron on this, but for my own education, how does on apply? Please push your patch on master branch is more explicit. Regards,
Re: [O] [babel][PATCHES] exporting inline source code
Hi Nicolas, thanks for implementing this. Nicolas Goaziou m...@nicolasgoaziou.fr writes: Nicolas Berthier nbe...@member.fsf.org writes: Indeed. I fixed it in the new attached patch. Thanks. Applied. Thank you. Since the patch has been applied, I get a Not at a block error when finding some org-mode files -- I'll investigate later if it is needed, just dropping this here now in case the bug is obvious. -- Bastien
Re: [O] org-element-at-point fails in programming-modes
Thorsten Jolitz tjol...@gmail.com writes:
Nick Dokos ndo...@gmail.com writes:
Nick Dokos ndo...@gmail.com writes:
Sebastien Vauban sva-n...@mygooglest.com
writes:
Nick Dokos wrote:
Thorsten Jolitz tjol...@gmail.com writes:
Thorsten Jolitz tjol...@gmail.com writes:
...
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.
One machine is running Gnus v. 5.13: that one smooshes the code
blocks together.
The other is running Ma Gnus v. 0.12: that one leaves empty
lines between blocks.
Maybe they switched to the new parser between versions, that parses a
src-block with :post-blank's, but does not take them into account when
interpreting?
No clue.
,[ C-h f mm-display-inline-fontify RET ]
| mm-display-inline-fontify is a compiled Lisp function in `mm-view.el'.
|
| (mm-display-inline-fontify HANDLE optional MODE)
|
| Insert HANDLE inline fontifying with MODE.
| If MODE is not set, try to find mode automatically.
`
is responsable here, and if we would find the place where 'handle' is
parsed (I couldn't in reasonable time) we would probably know what is
the problem ('handle' is the src-block in this case, 'mode' is 'org').
The stack trace on Ma Gnus v. 0.12 (and probably on 5.13 as well) looks like
this:
mm-display-inline-fontify((#buffer *mm-uu*-975097 (text/x-org) nil nil
nil nil nil nil) org-mode)
mm-display-org-inline((#buffer *mm-uu*-975097 (text/x-org) nil nil nil
nil nil nil))
mm-display-inline((#buffer *mm-uu*-975097 (text/x-org) nil nil nil nil
nil nil))
mm-display-part((#buffer *mm-uu*-975097 (text/x-org) nil nil nil nil nil
nil) t)
byte-code(... [ignored type gnus-summary-buffer buffer gnus-inhibit-images
handle string-match throw nil buffer-live-p get-buffer \\`image/
mm-inline-override-p 4 inline mm-attachment-override-p mm-automatic-display-p
mm-inlinable-p mm-inlined-p mm-automatic-external-display-p t split-string /
text rassq message insert-char 10 2 0 1 gnus-unbuttonized-mime-type-p
gnus-insert-mime-button (set-buffer gnus-summary-buffer) ((error))
derived-mode-p gnus-article-mode mm-display-part mm-display-inline
gnus-article-insert-newline \n -1 put-text-property gnus-undeletable
gnus-treat-article application/pgp-signature not-attachment display text
gnus-article-mime-handle-alist ...] 6)
gnus-mime-display-single((#buffer *mm-uu*-975097 (text/x-org) nil nil
nil nil nil nil))
gnus-mime-display-part((#buffer *mm-uu*-975097 (text/x-org) nil nil nil
nil nil nil))
mapcar(gnus-mime-display-part ((#buffer *mm-uu* (text/plain (charset .
gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region
#marker (moves after insertion) at 3806 in *Article gmane.emacs.orgmode*
#marker at 4171 in *Article gmane.emacs.orgmode*))) nil nil nil nil)
(#buffer *mm-uu*-161616 (text/x-org) nil (lambda nil (let
((inhibit-read-only t)) (delete-region #marker (moves after insertion) at 4172
in *Article gmane.emacs.orgmode* #marker at 4210 in *Article
gmane.emacs.orgmode*))) nil nil nil nil) (#buffer *mm-uu*-975097
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-44672
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-414536
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-4102 (text/plain
(charset . gnus-decoded)) nil nil nil nil nil nil)))
gnus-mime-display-mixed(((#buffer *mm-uu* (text/plain (charset .
gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region
#marker (moves after insertion) at 3806 in *Article gmane.emacs.orgmode*
#marker at 4171 in *Article gmane.emacs.orgmode*))) nil nil nil nil)
(#buffer *mm-uu*-161616 (text/x-org) nil (lambda nil (let
((inhibit-read-only t)) (delete-region #marker (moves after insertion) at 4172
in *Article gmane.emacs.orgmode* #marker at 4210 in *Article
gmane.emacs.orgmode*))) nil nil nil nil) (#buffer *mm-uu*-975097
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-44672
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-414536
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-4102 (text/plain
(charset . gnus-decoded)) nil nil nil nil nil nil)))
gnus-mime-display-part((multipart/mixed (#buffer *mm-uu* (text/plain
(charset . gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t))
(delete-region #marker (moves after insertion) at 3806 in *Article
gmane.emacs.orgmode* #marker at 4171 in *Article gmane.emacs.orgmode*))) nil
nil nil nil) (#buffer *mm-uu*-161616 (text/x-org) nil (lambda nil (let
((inhibit-read-only t)) (delete-region #marker (moves after insertion) at 4172
in *Article gmane.emacs.orgmode* #marker at 4210 in *Article
gmane.emacs.orgmode*))) nil nil nil nil) (#buffer *mm-uu*-975097
(text/x-org) nil nil nil nil nil nil) (#buffer *mm-uu*-44672
(text/x-org) nil
Re: [O] org-element-at-point fails in programming-modes
Nicolas Goaziou m...@nicolasgoaziou.fr writes: AFAIK, [:space:] is not compatible with XEmacs. FWIW, I'm less and less sure why we should worry about XEmacs compatibility. I wish some XEmacs user could step up and take care of all these XEmacs compatibility issue. -- Bastien
Re: [O] [PATCH] Make the regexp matching the beginning of a table more explicit
Hi Samuel, Samuel Loury konubi...@gmail.com writes: I would like to provide a very tiny change in the regexp matching a beginning of table in org-table.el. Applied in master, thanks, -- Bastien
Re: [O] org-element-at-point fails in programming-modes
Thorsten Jolitz tjol...@gmail.com writes: Maybe they switched to the new parser between versions, that parses a src-block with :post-blank's, but does not take them into account when interpreting? I tried an experiment : (defun org-mode (rest _) t) and refresh. The newlines didn't come back (but fontification obviously disappeared). So I guess it isn't org-mode's fault. I would like to blame (mm-uu-dissect) but I didn't look into it. I'll take the opportunity to test if it'll also eat multiple blank lines (I think it will) : #+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 (There should be 1, then 2, then 3 blanks lines between the successives blocks above.) -- Nico.
Re: [O] [bug] commit 5512bedee breaks insert diary in agenda
Hi Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: changes made on 28 July, commit 5512bedee, breaks insert diary functionality. In particular, i d in the agenda inserts the new entry in the wrong place in a date-tree diary org file. Reverting this commit fixes the problem. Reverted, thanks for reporting this. Nikolai, if you can rework this patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=5512bedee so that it fixes the problem we discussed without introducing the bug Eric reported, please go ahead. Thanks, -- Bastien
Re: [O] Orgmode/Koma script letter
Rasmus ras...@gmx.us writes: Is there something wrong in what I am doing or is there a problem? I don't think there is a code bug. There is a potentially a documentation bug in the first line of the doc string you mentioned. Indeed, this is a documentation bug -- can one of you provide a patch for it? Thanks! -- Bastien
Re: [O] clock-in clock-out problems
Nick Dokos ndo...@gmail.com writes: OK - glad it's working. It was a pretty weird bug. Thanks for taking care of this! -- Bastien
Re: [O] Updating to 8.2.5 broke org-mode
Marcelo de Moraes Serpa celose...@gmail.com writes: @Achim Thanks - replacing (require 'org-install) with (require 'org-loaddefs) solved the issue! What about removing (require 'org-loaddefs) altogether? -- Bastien
Re: [O] org-element-at-point fails in programming-modes
Nicolas Richard theonewiththeevill...@yahoo.fr writes: I would like to blame (mm-uu-dissect) but I didn't look into it. I now blame (mm-uu-dissect). The following patch fixes it, but that part of the code must be there for a reason... and I don't know what it is. Modified lisp/gnus/mm-uu.el diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el index 423324a..2200caa 100644 --- a/lisp/gnus/mm-uu.el +++ b/lisp/gnus/mm-uu.el @@ -668,10 +668,7 @@ value of `mm-uu-text-plain-type'. (setq end-point (point) (or (not (setq func (mm-uu-function-2 entry))) (funcall func))) - (if (and ( start-point text-start) - (progn -(goto-char text-start) -(re-search-forward . start-point t))) + (if ( start-point text-start) (push (mm-make-handle (mm-uu-copy-to-buffer text-start start-point) mm-uu-text-plain-type) -- Nico.
[O] Article Mode eats newlines between src-blocks (was Re: org-element-at-point fails in programming-modes)
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Thorsten Jolitz tjol...@gmail.com writes: Maybe they switched to the new parser between versions, that parses a src-block with :post-blank's, but does not take them into account when interpreting? I tried an experiment : (defun org-mode (rest _) t) and refresh. The newlines didn't come back (but fontification obviously disappeared). So I guess it isn't org-mode's fault. I would like to blame (mm-uu-dissect) but I didn't look into it. I'll take the opportunity to test if it'll also eat multiple blank lines (I think it will) : #+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 (There should be 1, then 2, then 3 blanks lines between the successives blocks above.) I don't see any blank lines between the blocks. This is how a string that is fontified in mm-view.el looks like, no matter if there are trailing blank lines: , | #+BEGIN_SRC emacs-lisp\n (- 2 2)\n#+END_SRC\n ` i.e. thats the value of HANDLE in this function: , | (mm-display-inline-fontify HANDLE optional MODE) ` So either they missed the additional final \n's for all but the last block when parsing, or they forgot to handle them when inserting the fontified string again. PS I renamed this thread because the original topic, which is still more important for me (!), is not discussed anymore. -- cheers, Thorsten
[O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-ignore-timestamp
Hi list, what is the difference between these two options? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] [bug] commit 5512bedee breaks insert diary in agenda
On Friday, 22 Aug 2014 at 15:51, Bastien wrote: Hi Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: changes made on 28 July, commit 5512bedee, breaks insert diary functionality. In particular, i d in the agenda inserts the new entry in the wrong place in a date-tree diary org file. Reverting this commit fixes the problem. Reverted, thanks for reporting this. Thanks. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.1, Org release_8.3beta-246-g77d0da
Re: [O] org-element-at-point fails in programming-modes
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Thorsten Jolitz tjol...@gmail.com writes: Maybe they switched to the new parser between versions, that parses a src-block with :post-blank's, but does not take them into account when interpreting? I tried an experiment : (defun org-mode (rest _) t) and refresh. The newlines didn't come back (but fontification obviously disappeared). So I guess it isn't org-mode's fault. I would like to blame (mm-uu-dissect) but I didn't look into it. I'll take the opportunity to test if it'll also eat multiple blank lines (I think it will) : #+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 (There should be 1, then 2, then 3 blanks lines between the successives blocks above.) No blank lines in v5.13, a single blank line in Ma Gnus v. 0.12. -- Nick
[O] Running Node.js and exporting css.
Couple of weeks ago, I accidentally spammed the message board with several
attempts to send up a couple of patches for some problems I was seeing.
So, firstly, apologies for the spam.
The two problems I was seeing were related to executing js using node.js,
and exporting css with vendor properties.
The node.js problem is that it will start putting in newlines if a
structure is past some size. I think this may be fixable by changing
some settings in node.js, but it was also easy enough to change the regex
to look past newlines in org. An example of the problem can be seen by
running the following
#+BEGIN_SRC js
return [[1, 2],[1, 2],[1, 2],[1, 2],[1, 2],[1, 2],[1,2]]
#+END_SRC
If you remove just one of the inner arrays, it will work as desired.
The other problem is just as short. Simply export the following when you
have org-src-fontify-natively set.
#+BEGIN_SRC css
foo {
-webkit-appearance: none;
}
#+END_SRC
I cobbled a small change that seemed to fix that.
At any rate, again apologies for the previous spam. I didn't want to just
respam immediately with an apology.
Thanks!
--
josh
Re: [O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-ignore-timestamp
Try
C-h v org-agenda-todo-ignore-with-date
C-h v org-agenda-todo-ignore-timestamp
There are substantial differences between the two.
org-agenda-todo-ignore-with-date, when set, ignores all dates, and overrides
org-agenda-todo-ignore-{scheduled|deadline}
org-agenda-todo-ignore-timestamp is more configurable to ignore past, future,
all, or {-}N days in the past or future
Hope this helps!
-Original Message-
From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org
[mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On
Behalf Of Marcin Borkowski
Sent: Friday, August 22, 2014 7:33 AM
To: Org-mode mailing list
Subject: [O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-ignore-
timestamp
Hi list,
what is the difference between these two options?
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
This message is intended for the sole use of the individual and entity to which
it is addressed and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. If you are not the intended
addressee, nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone the
message or any information contained in the message. If you have received this
message in error, please immediately advise the sender by reply email and
delete the message. Thank you.
[O] bug in org-babel emacs-lisp output?
I have noticed a possible bug in the output of src blocks, especially
for emacs-lisp blocks.
This block works fine.
#+BEGIN_SRC emacs-lisp :results raw
'(nil (a . b))
#+END_SRC
#+RESULTS:
(nil (a . b))
This block however, gives me an error that is due to nil being the first
element of the list.
#+BEGIN_SRC emacs-lisp
'(nil (a . b))
#+END_SRC
#+RESULTS:
gives this error:
org-babel-insert-result: Args out of range: #killed buffer, 0, 1
A traceback shows:
Debugger entered--Lisp error: (args-out-of-range #buffer *temp* 0 1)
orgtbl-to-orgtbl((nil (a . b)) (:fmt (lambda (cell) (format %s cell
org-babel-insert-result((nil (a . b)) (value replace) (emacs-lisp
'(nil (\a\ . \b\)) ((:comments . ) (:shebang . ) (:cache . no)
(:padline . ) (:noweb . no) (:tangle . no) (:exports . code) (:results
. replace value) (:session . none) (:hlines . yes) (:colnames . no)
(:result-type . value) (:result-params value replace) (:rowname-names)
(:colname-names)) nil 0 #marker at 95 in test.org) nil 0 emacs-lisp)
org-babel-execute-src-block(nil)
org-babel-execute-src-block-maybe()
org-babel-execute-maybe()
org-babel-execute-safely-maybe()
run-hook-with-args-until-success(org-babel-execute-safely-maybe)
org-ctrl-c-ctrl-c(nil)
funcall-interactively(org-ctrl-c-ctrl-c nil)
call-interactively(org-ctrl-c-ctrl-c nil nil)
command-execute(org-ctrl-c-ctrl-c)
Another example that fails:
#+BEGIN_SRC emacs-lisp :results value
'('(nil nil) (a . b))
#+END_SRC
orgtbl-format-line: Wrong type argument: listp, b
But, this works
#+BEGIN_SRC emacs-lisp :results value
'((nil . c) (a . b))
#+END_SRC
#+RESULTS:
| (nil . c) | (a . b) |
It seems like the issue is that the output does not go into a table too
well, and the error is a formatting one. Maybe this error should be
caught, and a default of raw should be output when a table cannot be
made? right now my workaround is specifying the :results raw when I hit
these situations, but it doesn't seem right.
--
---
John Kitchin
http://kitchingroup.cheme.cmu.edu
Re: [O] org-element-at-point fails in programming-modes
Nick Dokos ndo...@gmail.com writes: Nick Dokos ndo...@gmail.com writes: Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com 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. One machine is running Gnus v. 5.13: that one smooshes the code blocks together. The other is running Ma Gnus v. 0.12: that one leaves empty lines between blocks. I cannot reproduce on my system. For Ma I use the git head from today. I tested v5.13 using emacs-bzr from today (rev. 117722) and rev. 117624 from the beginning of August. —Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
Re: [O] [PATCH] ob-shell
Pascal Fleury writes: Please forget about the previous patch I submitted, I have a new one that should work now on all platforms. Let me know if it should be formatted differently. You don't really want to fork into bash each time you're about to run a shell code block just to find out if it suppports associative arrays. This needs to be determined at customization time. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] How to get cookies working with TODOs?
Nick Dokos ndo...@gmail.com writes: Sharon Kimble boudic...@skimble.plus.com 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 Thanks for this Nick, that's got it all working nicely. Sorry for not replying sooner but I've been testing things out. 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.93.1 signature.asc Description: PGP signature
Re: [O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-ignore-timestamp
Dnia 2014-08-22, o godz. 15:41:34
Subhan Michael Tindall subh...@familycareinc.org napisał(a):
Try
C-h v org-agenda-todo-ignore-with-date
C-h v org-agenda-todo-ignore-timestamp
That's where I started;).
There are substantial differences between the two.
org-agenda-todo-ignore-with-date, when set, ignores all dates, and
overrides org-agenda-todo-ignore-{scheduled|deadline}
org-agenda-todo-ignore-timestamp is more configurable to ignore past,
future, all, or {-}N days in the past or future
Doesn't this suggest that org-agenda-todo-ignore-with-date is
obsolete?
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] export for Beamer with author options
Dnia 2014-08-22, o godz. 15:37:28
Nicolas Goaziou m...@nicolasgoaziou.fr napisał(a):
torys.ander...@gmail.com (Tory S. Anderson) writes:
I realize you were responding to Aaron on this, but for my own
education, how does on apply?
Please push your patch on master branch is more explicit.
And before this happens, you might want to try
#+LATEX_HEADER: \author[short-author]{Really \\long \\author}
#+LATEX_HEADER: \newcommand{\author}[2][]{}
Regards,
With greetings from the Department of Dirty TeX Hacks,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
[O] Marks not visible in column view
Hi, in the agenda we can mark several entries for bulk processing. In the following example, the second and third agenda entries are marked. To indicate they are marked, a '' symbol is shown right before them: Projects: TODO Write the document Projects: TODO Call Bob Projects: TODO Arrange meeting with Laura Now, if we enter column view, those marks are not visible. For example, the following column view shows the title, the TODO keyword, and the estimated effort for all entries: Write the document | TODO | 0:30 | Call Bob | TODO | 0:15 | Arrange meeting with Laura | TODO | 0:10 | Is it possible to have the column view show which entries are marked? Thanks, Gonzalo
Re: [O] export for Beamer with author options
Dnia 2014-08-22, o godz. 20:56:50
Marcin Borkowski mb...@wmi.amu.edu.pl napisał(a):
#+LATEX_HEADER: \author[short-author]{Really \\long \\author}
#+LATEX_HEADER: \newcommand{\author}[2][]{}
Oops, my bad. Actually, it should be \renewcommand. (Though I didn't
test this idea.)
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] export for Beamer with author options
2014ko abuztuak 22an, Nicolas Goaziou-ek idatzi zuen: torys.ander...@gmail.com (Tory S. Anderson) writes: I realize you were responding to Aaron on this, but for my own education, how does on apply? Please push your patch on master branch is more explicit. Pushed. Thanks, -- Aaron Ecay
Re: [O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-ignore-timestamp
-Original Message-
From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org
[mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On
Behalf Of Marcin Borkowski
Sent: Friday, August 22, 2014 11:54 AM
To: emacs-orgmode@gnu.org
Subject: Re: [O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-
ignore-timestamp
Dnia 2014-08-22, o godz. 15:41:34
Subhan Michael Tindall subh...@familycareinc.org napisał(a):
Try
C-h v org-agenda-todo-ignore-with-date C-h v
org-agenda-todo-ignore-timestamp
That's where I started;).
There are substantial differences between the two.
org-agenda-todo-ignore-with-date, when set, ignores all dates, and
overrides org-agenda-todo-ignore-{scheduled|deadline}
org-agenda-todo-ignore-timestamp is more configurable to ignore past,
future, all, or {-}N days in the past or future
Doesn't this suggest that org-agenda-todo-ignore-with-date is obsolete?
It's functionality is subsumed by org-agenda-todo-ignore-timestamp all, yes.
I believe it was either added or expanded considerably fairly recently. Who
knows what would break if you removed it though?
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
This message is intended for the sole use of the individual and entity to which
it is addressed and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. If you are not the intended
addressee, nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone the
message or any information contained in the message. If you have received this
message in error, please immediately advise the sender by reply email and
delete the message. Thank you.
Re: [O] org-agenda-todo-ignore-with-date vs. org-agenda-todo-ignore-timestamp
Dnia 2014-08-22, o godz. 21:02:56 Subhan Michael Tindall subh...@familycareinc.org napisał(a): Doesn't this suggest that org-agenda-todo-ignore-with-date is obsolete? It's functionality is subsumed by org-agenda-todo-ignore-timestamp all, yes. [...] Well, except that it isn't. A quick experiment on my agenda showed that setting org-agenda-todo-ignore-timestamp gave more TODOs in the global TODO list than setting org-agenda-todo-ignore-with-date. I can run further experiments to pinpoint the difference, but maybe somebody just *knows* that? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
[O] [PATCH] ob-R.el: Add customizable R command primary prompt setting
list/ob-R.el (org-babel-R-command-primary-prompt, org-babel-R-evaluate-session): Former adds customizable prompt value the latter utilizes it. My R prompt looks like this ℝ . Babel needs to know more how to handle various situations so the regex used in `org-babel-R-evaluate-session' to identify the prompt looks like this ^\\([ ]*[ℝ+\\.][ ]?\\)+\\([[0-9]+\\|[ ]\\). It is required to handle various R prompt situations correctly. It may change over time to handle more situations. The user doesn't need to know about those details. The user only cares about the R prompt alone. For example, when they set the prompt in R it looks like this =options(prompt=ℝ )=, it is very simple. It should be this simple for bable, too. This change adds a user customizable variable for the prompt from user perspective `org-babel-R-command-primary-prompt'. That variable is utilized in `org-babel-R-evaluate-session' where the full regular expression to match the prompt is constructed. This makes it very easy to handle a custom prompt since from the R side of things, the value of `org-babel-R-command-primary-prompt' is the only thing that the user needs to know to set. Via custom it looks like this '(org-babel-R-command-primary-prompt ℝ). TINYCHANGE --- lisp/ob-R.el | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lisp/ob-R.el b/lisp/ob-R.el index 41b943c..1cb675b 100644 --- a/lisp/ob-R.el +++ b/lisp/ob-R.el @@ -87,6 +87,11 @@ this variable.) :version 24.1 :type 'string) +(defcustom org-babel-R-command-primary-prompt + User configurable portion of the primary prompt. + :group 'org-babel + :type 'string) + (defvar ess-local-process-name) ; dynamically scoped (defun org-babel-edit-prep:R (info) (let ((session (cdr (assoc :session (nth 2 info) @@ -413,6 +418,7 @@ last statement in BODY, as elisp. (list body org-babel-R-eoe-indicator) \n)) (inferior-ess-send-input)) \n + (concat ^\\([ ]*[ org-babel-R-command-primary-prompt +\\.][ ]?\\)+\\([[0-9]+\\|[ ]\\)) line) (defun org-babel-R-process-value-result (result column-names-p) R-specific processing of return value. -- 1.9.2 0001-ob-R.el-Add-customizable-R-command-primary-prompt-se.patch Description: Binary data
