Re: [O] Capture with org-directory not working?

The workaround with lambda worked, thanks a lot! As I mentioned I didn't have any problems with the templates in years but they stopped working after a recent update. Alex On Tue, Nov 29, 2016 at 3:05 PM, Nick Dokos wrote: > Alexander Vorobiev

Re: [O] [Patch v2] Add support for sqsh sql src blocks

Thanks for your comments Nicolas! I hope this is better. -Micah * lisp/ob-sql.el (org-babel-sql-dbstring-sqsh): New Function. Make sqsh command line args for databse connection. (org-babel-execute:sql): Add support for sqsh engine TINYCHANGE ob-sql.el | 52

Re: [O] [BUG] Upcoming deadlines sorted in reverse order

Hello, Matt Lundin writes: > With commit 9299efa3519b3ef3191e8dc06a4466696c720f6c, upcoming deadlines > in the agenda are sorted in reverse order, with more distant deadlines > appearing first and imminent and overdue deadlines appearing last. > > Running emacs -Q and using

Re: [O] [BUG] Scheduled items in past show time of day in agenda

Hello, Matt Lundin writes: > With commit 69ec6258b65a5d317f0dcb275ec2d5a90f72f191 I find that > non-repeating timestamps with a time-of-day designation continue to > appear at a particular time in the agenda even when they are in the > past. > > For instance, using emacs -Q,

Re: [O] Capture with org-directory not working?

Alexander Vorobiev writes: > I have recently started having this issue with my capture templates. In my > case I want to ask the user > (me) which file should be used to store the note, so I have a bunch of > templates like this > > (setq org-capture-templates >  

[O] [BUG] Upcoming deadlines sorted in reverse order

With commit 9299efa3519b3ef3191e8dc06a4466696c720f6c, upcoming deadlines in the agenda are sorted in reverse order, with more distant deadlines appearing first and imminent and overdue deadlines appearing last. Running emacs -Q and using the following org file... * An overdue deadline

Re: [O] [BUG] Scheduled items in past show time of day in agenda

confirmed

[O] [BUG] Scheduled items in past show time of day in agenda

Hi everyone, With commit 69ec6258b65a5d317f0dcb275ec2d5a90f72f191 I find that non-repeating timestamps with a time-of-day designation continue to appear at a particular time in the agenda even when they are in the past. For instance, using emacs -Q, i find thagt the following item scheduled for

[O] org-batch-agenda-csv issue

Hello, I am trying to automatically extract the todo's from my orgmode files and format them for display via a widget on my desktop. The following command works fine with no errors when executed in a terminal emacs -batch -l ~/.emacs -eval '(org-batch-agenda-csv "a")' However when I setup the

Re: [O] Capture with org-directory not working?

I have recently started having this issue with my capture templates. In my case I want to ask the user (me) which file should be used to store the note, so I have a bunch of templates like this (setq org-capture-templates '(("o" "Project todo" entry (file+headline

Re: [O] v9.0 running babel blocks

On 2016-11-28 08:51, Ista Zahn writes: > On Nov 28, 2016 5:54 AM, "Alan Schmitt" > wrote: >> >> Hello again, >> >> On 2016-11-28 09:01, Alan Schmitt writes: >> >> > I'm sorry to write again about this, but the

Re: [O] DEADLINE: position in entry

Hello, Yasushi SHOJI writes: > /tmp/a.org: > * DONE org > DEADLINE: [2016-01-07 Thu 17:39] > > SCHEDULED: <2015-09-29 Tue .+1w> OK. I get it. Since SCHEDULED: keyword is misplaced, it is ignored. However, the repeating time-stamp is not. Org really sees something

Re: [O] [PATCH] ox-odt.el: Fix LaTeX formulae in opendocument exports

Hello, Lixin Chin writes: > Fixing a bug in org-mode 9.0 where setting a LaTeX -> MathML converter > (`org-latex-to-mathml-convert-command') and exporting an org-mode > document containing LaTeX equations to opendocument fails. Applied. Thank you. Regards, -- Nicolas

Re: [O] [PATCH] org.el: Relax the match criteria for MathML header line

Hello, Lixin Chin writes: > This fixes a minor bug in converting LaTeX equations to MathML. The > default match criteria for the toplevel is unnecessarily strict, > and should probably be relaxed. Applied. Thank you. Regards, -- Nicolas Goaziou