Re: [O] How do you interact with org src blocks for your gmane.emacs.orgmode correspondence?

[Thorsten Jolitz]

Grant Rettke  writes:

> On Sat, Nov 1, 2014 at 5:58 AM, Thorsten Jolitz  wrote:
>> And there is a new library
>>
>> [[http://goo.gl/pYYzS6][outorg-export]]
>
> I just used http://goo.gl/pYYzS6 and it worked fine; that looks like
> an org mode link.

It is an Org-mode link inserted with C-c C-l while writing the post in
the *outorg-edit-buffer*, in case this was a question.

-- 
cheers,
Thorsten

Re: [O] [RFC] Change property drawer syntax

[Christian Egli]

John Hendy  writes:

> I use this, or at least things like this. For example:
>
> * task
> :PROPERTIES:
> :start:2014-11-03-08:00
> :task_id:  task_d
> :depends: task_a task_b task_c
> :duration: 30min
> :END:
>
> Not multi-line, but currently I can feed any property that matches a
> tj3 attribute (e.g. "task_id") and Org will "do the right thing."

This usage is perfectly fine and will continue to work. There are some
very obscure attributes that taskjuggler (and the exporter) support,
such as note and journalentry. These can span multiple lines. They can
be used to add notes or more structured "journal" entries. A
journalentry has several subparts (headline, summary, etc) but I don't
think we need to support this. IMHO the best "resolution" to this is to
simply take the two attributes note and journalentry out of the list of
exported attributes.

Or maybe better yet, add a note to the docstring. Maybe I'll just do
that.

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [O] Syntax inconsistency?

[Nicolas Goaziou]

Hello,

Marcin Borkowski  writes:

> just wondering: on one hand, we have lines like
>
> #+OPTIONS: toc:nil

This is a keyword.

> On the other hand, we have
>
> #+ATTR_ASCII: :width 10

This is an attribute.

> Why is the syntax (seemingly, at least) inconsistent?  Why not
> `width:10' or `:toc nil'?

These are two different things, so there is no real reason to make them
look like each other. Also, and more importantly, moving OPTIONS to the
other syntax is, IMO, unreadable:

  #+OPTIONS: :| t :^ nil :* t :\n t

Note there is also another syntax type, e.g.,:

 #+TOC: headlines 2


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC/PATCH] org-goto: Update for isearch changes

[Nicolas Goaziou]

Kyle Meyer  writes:

> To follow up on this:
>
> I think the reason why setting only one doesn't work is because isearch
> specifies both of them.
>
> (define-key map "\r" 'isearch-exit)
> (define-key map [return] 'isearch-exit)
>
> Since the return key is given a binding, it's not translated to the
> corresponding ASCII character and, as a result, needs to be overridden
> specifically. At least, that's my understanding based on
> (info "(emacs)Named ASCII Chars").

OK. So let's bind both of them to nil then. Thanks for the
investigation.


Regards,

Re: [O] [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Christian Egli  writes:

> This usage is perfectly fine and will continue to work. There are some
> very obscure attributes that taskjuggler (and the exporter) support,
> such as note and journalentry. These can span multiple lines. They can
> be used to add notes or more structured "journal" entries. A
> journalentry has several subparts (headline, summary, etc) but I don't
> think we need to support this. IMHO the best "resolution" to this is to
> simply take the two attributes note and journalentry out of the list of
> exported attributes.

I still don't get how a journalentry or a note spanning multiple lines
look like.

Org doesn't support multi line properties. But this could be a drawer or
a block.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change property drawer syntax

[Christian Egli]

Nicolas Goaziou  writes:

> Hello,
>
> Christian Egli  writes:
>
>> I see that it is too late now, but let me still note that the
>> taskjuggler exporter is quite liberal in what attribute values it allows
>> for exporting. I've never used it and I haven't ever seen anyone using
>> it, but in theory you could give a task a note or a journalentry which
>> spans multiple lines. This will no longer be possible with this
>> change.
>
> I'm not sure to understand what is a note or a journalentry which spans
> multiple lines. Could you give an example?

Speaking in taskjuggler syntax it would be as follows:

task alpha "Alpha Test" {
  effort 1w
  depends !!software
  allocate test, dev2
  note "Hopefully most bugs will be found and fixed here."
  journalentry 2002-03-01 "Contract with Peter not yet signed" {
author boss
alert red
summary -8<-
  The paperwork is stuck with HR and I can't hunt it down.
->8-
details -8<-
  If we don't get the contract closed within the next week,
  the start of the testing is at risk.
->8-
  }
}

AFAIK the org-mode taskjuggler exporter was previously able to handle
this if given the following headline:

* task
:PROPERTIES:
:Effort:  1w
:depends: software
:allocate: test dev2
:note: "Hopefully most bugs will be found and fixed here."
:journalentry: 2002-03-01 "Contract with Peter not yet signed" {
author boss
alert red
summary -8<-
  The paperwork is stuck with HR and I can't hunt it down.
->8-
details -8<-
  If we don't get the contract closed within the next week,
  the start of the testing is at risk.
->8-
  }
:END:

Oh, and btw: there can be more than one journalentry. So, given this
taskjuggler feature is not very often used and drawer machinery is not
really suited for this use case I suggest we just drop support for it.
Maybe the user can just squeeze the whole entry on one line interspersed
with \ns.

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

[O] custom agenda: tag filter not exported anymore in Version 8.2.10

[sane]

Hello,

i got a linux machine having org mode 8.2.4 and a windows machine having 
8.2.10
when i export a custom agenda view (or using mobile org export) on the 
linux machine my tag filters like -Work are correctly handled (in the 
example all :Work: tags are filtered out). on the windows machine the 
agenda is showing the correct result in emacs, but the export is not 
filtering as desired.


Was there any change, so that tag filters are not correctly exported 
anymore or am i overlooking something here?


Any help is appreciated.

Thank you

Michael

Re: [O] Bug: Org leaves whitespace around :LOGBOOK: [8.2.10 (release_8.2.10 @ /home/jsynacek/.local/share/emacs/24.4/lisp/org/)]

[Jan Synacek]

Nicolas Goaziou  writes:
> Hello,
>
> Jan Synacek  writes:
>
>> I'm not sure if this is by design or not, but it sure looks like a bug
>> to me and is quite annoying.
>>
>> Reproducer:
>> 1) emacs -Q
>> 2) eval the following:
>> (require 'org)
>> (setq org-log-done 'time)
>> (setq org-log-into-drawer t)
>> (setq org-todo-keywords
>>   '((sequence "TODO(t)" "WAITING(w@/!)" "|" "DONE(d!)")))
>> 3) create a temporary org-mode buffer, insert an item in it, and C-c C-t
>>on the item (set the item to the WAITING state)
>> 4) notice the whitespace after :LOGBOOK: and :END:, creating sort of a box
>>
>> Emacs  : GNU Emacs 24.4.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9)
>>  of 2014-10-22 on jsynacek-ntb-work.brq.redhat.com
>> Package: Org-mode version 8.2.10 (release_8.2.10 @ 
>> /home/jsynacek/.local/share/emacs/24.4/lisp/org/)
>
> FWIW, I cannot reproduce it on development version (8.3_beta).

Git bisect log:

bad: [3f484a52775c8873a3b1b44e8264e01369850a8a] Fix headline insertion after an 
empty headline
good: [e112f3c0df49264998d4ae8df545c9940692f68f] ox-texinfo: Fix corner case 
when fixing a node name
good: [409913b253de2de1b49f9468a4b77b9292e090c4] Fix `org-promote' error
bad: [dc16617f46d64073e4d06308f7150c46d992a408] orgguide.texi: Small fixes
good: [2e5b3dede103bba0071144ec7b7fc250471c1463] org-element: Interpret 
headlines according to `org-o;dd-levels-only'
bad: [2de0c1c3da1e7f9859b82d8af0167c60545c5c5f] Fix 37bf05
bad: [37bf0576f2f2894c6e37239ee8db63a3ef21a840] org-element: Make properties 
parsing more robust
first bad commit: [37bf0576f2f2894c6e37239ee8db63a3ef21a840] org-element: Make 
properties parsing mor;e robust

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat


signature.asc
Description: PGP signature

Re: [O] M-S-up/down on plain lists containing text (or multilevel lists)

[James Harkins]

Nicolas Goaziou  nicolasgoaziou.fr> writes:

> Both `M-S-up' and `M-S-down' work line wise and ignore any structure
> around point. OTOH, `M-up' and `M-down' should do what you want.

BTW the name of the menu item is misleading. C-h C-k M-S-up:

~~
It is bound to ,,.
~~

This is why I thought that M-S-up/down would work on entry + contents -- I
looked in the Emacs menu and saw "Move Subtree Up," and I didn't think to
check the docstring (which contradicts the name in the menu by saying,
correctly, "Drag the line at point up").

hjh

Re: [O] M-S-up/down on plain lists containing text (or multilevel lists)

[Nicolas Goaziou]

James Harkins  writes:

> BTW the name of the menu item is misleading. C-h C-k M-S-up:
>
> ~~
> It is bound to , Subtree Up>,.
> ~~
>
> This is why I thought that M-S-up/down would work on entry + contents -- I
> looked in the Emacs menu and saw "Move Subtree Up," and I didn't think to
> check the docstring (which contradicts the name in the menu by saying,
> correctly, "Drag the line at point up").

What improvement are you suggesting then?


Regards,

Re: [O] Syntax inconsistency?

[Marcin Borkowski]

On 2014-11-03, at 09:28, Nicolas Goaziou wrote:

> Hello,
>
> Marcin Borkowski  writes:
>
>> just wondering: on one hand, we have lines like
>>
>> #+OPTIONS: toc:nil
>
> This is a keyword.
>
>> On the other hand, we have
>>
>> #+ATTR_ASCII: :width 10
>
> This is an attribute.
>
>> Why is the syntax (seemingly, at least) inconsistent?  Why not
>> `width:10' or `:toc nil'?
>
> These are two different things, so there is no real reason to make them
> look like each other. Also, and more importantly, moving OPTIONS to the
> other syntax is, IMO, unreadable:
>
>   #+OPTIONS: :| t :^ nil :* t :\n t
>
> Note there is also another syntax type, e.g.,:
>
>  #+TOC: headlines 2

Thanks for your clarifications!  Things seem still a bit hazy for me,
but I guess I'll have to live with it:-).

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] M-S-up/down on plain lists containing text (or multilevel lists)

[James Harkins]

At Mon, 03 Nov 2014 13:48:56 +0100,
Nicolas Goaziou wrote:
> James Harkins  writes:
> > BTW the name of the menu item is misleading. C-h C-k M-S-up:
> >
> > ~~
> > It is bound to , > Subtree Up>,.
> 
> What improvement are you suggesting then?

Upon further reflection, I think the best would be to bind org-metaup/down to 
the "move subtree" menu items, rather than org-shiftmetaup. I'm guessing that 
this is the more common use case (because moving a whole subtree doesn't 
destroy the structure of that subtree, while moving a line does), so I think it 
would make more sense to put the more common case in the menu.

hjh

[O] The order of interpreting when exporting

[Marcin Borkowski]

Hi there,

do I get it right that exporting starts with the deepest parts, and then
proceeds to the outer ones?  I.e., when I have a function call of the
type

(org-html-whatever (element contents info))

then the `contents' are already interpreted by similar functions at the
lower (`inner') levels?  Taking an even more concrete example: is
org-html-item run (repeatedly, for each item) before
org-html-plain-list?

Just wanted to know, I'm building two things at the same time: a custom
exporter and a mental model of one;-).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

[O] bug#11774: bug#11774: bug#11774: org-mode causes undo boundaries to be lost

[Stefan Monnier]

> There is one possible bug.  I have undo-boundary on self-insert-hook.
> If I do newline-and-indent, for some reason both the newline and the
> indent get undo boundaries.  My expectation is that typing RET should
> only have one undo boundary.
> I don't know if that is user expectation error, but seems worth mentioning.

Maybe the issue is simply that you need to be careful to put your
undo-boundary "late" on the post-self-insert-hook (i.e. to use the
`append' argument of add-hook).

If not, then please post a new bug-report about it, so we can see
on which side it should be solved.


Stefan

Re: [O] [bug] Alignment bug in clock tables

[Stormking]

Francesco Pizzolante  writes:

> 
> Hi Joost,
> 
> > I reported this on September 2nd too.

I'm having this problem, too. The code that aligns the clocktable
seems to count the "\emsp" entity as five characters. But with
pretty entities turned on, it's displayed as only one character.

The same is true for the code that shortens the headline if the
narrow option is used.

Ciao, Stormking

Re: [O] syntax highlighting of inline LaTeX fragments

[Brady Trainor]

Rasmus  writes:

> The variable `org-highlight-latex-and-related' should allow you to
> highlight inline math.

Thank you.

Takes care of all,
- $..$
- $$..$$ (w/ newlines)
- \(..\)
- \[..\] (w/ newlines)
- \begin{equation}..\end{equation} (w/ newlines)

--
Brady

Re: [O] Org and ledger

[Eric S Fraga]

On Friday, 31 Oct 2014 at 12:32, Vikas Rawal wrote:
> I have started using ledger with Org, and would be interested in knowing 
> experiences of other users.

I use ledger within org in the literate programming sense.  This allows
me to have different ledger entries all over the place under different
headings but can then use one src block to generate whatever I want,
either a balance or a register, say.

> 2. Generating reports: Babel results do not use the standard Org table
> syntax. 

Yes, this is true.  It may be possible to change the output of ledger
(using --format, say) to something that babel could process into a
table.  However, I do find ledger a little clumsy in this regard but
maybe that's just the documentation.  

An extra complication is the big difference between ledger v2 and v3 in
terms of invoking it.  What version are you using?
 
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-475-g25d50e

Re: [O] [RFC/PATCH] org-goto: Update for isearch changes

[Kyle Meyer]

Nicolas Goaziou  wrote:
[...]
> OK. So let's bind both of them to nil then. Thanks for the
> investigation.

I've attached an updated patch. It now includes a comment about which
version removed isearch-other-control-char, and the commit message has
been extended to explain why both 'C-m' and RET are bound to nil.

Thanks for your comments.

>From 2d560370d1626544265d2c21559a0f138ef39ec9 Mon Sep 17 00:00:00 2001
From: Kyle Meyer 
Date: Sun, 2 Nov 2014 01:32:43 -0400
Subject: [PATCH] org-goto: Update for isearch changes

* lisp/org.el (org-goto): Update for isearch changes that removed
isearch-other-control-char.

isearch-other-control-char has been removed from isearch.el [1]. The
default interface for org-goto uses isearch-other-control-char to pass
certain key presses from org-goto-local-auto-isearch-map to
org-goto-map. Specifically, 'C-i' calls org-cycle and 'C-m' calls
org-goto-ret.

With the current isearch, the keys that should be passed to org-goto-map
can be set to nil. In addition to 'C-i' and 'C-m', RET must also be set
to nil because isearch-mode-map sets both 'C-m' and RET.

[1] bzr revision 114586, git commit aa04ac2c6,
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15200


---
 lisp/org.el | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 5b365b0..a70275c 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7523,8 +7523,14 @@ (defun org-get-location (buf help)
 
 (defvar org-goto-local-auto-isearch-map (make-sparse-keymap))
 (set-keymap-parent org-goto-local-auto-isearch-map isearch-mode-map)
-(define-key org-goto-local-auto-isearch-map "\C-i" 'isearch-other-control-char)
-(define-key org-goto-local-auto-isearch-map "\C-m" 'isearch-other-control-char)
+;; `isearch-other-control-char' was removed in Emacs 24.4.
+(if (boundp 'isearch-other-control-char)
+(progn
+  (define-key org-goto-local-auto-isearch-map "\C-i" 'isearch-other-control-char)
+  (define-key org-goto-local-auto-isearch-map "\C-m" 'isearch-other-control-char))
+  (define-key org-goto-local-auto-isearch-map "\C-i" nil)
+  (define-key org-goto-local-auto-isearch-map "\C-m" nil)
+  (define-key org-goto-local-auto-isearch-map [return] nil))
 
 (defun org-goto-local-search-headings (string bound noerror)
   "Search and make sure that any matches are in headlines."
-- 
2.1.3


-- 
Kyle

Re: [O] The order of interpreting when exporting

[Nicolas Goaziou]

Hello,

Marcin Borkowski  writes:

> do I get it right that exporting starts with the deepest parts, and then
> proceeds to the outer ones?

Correct.


Regards,

-- 
Nicolas Goaziou

[O] [PATCH] org-transpose-word: inherit text mode syntax table?

[Eric Abrahamsen]

Something that has subconsciously bothered me for years:
`org-transpose-words' does its transposition using a blank syntax table,
rather than inheriting from text-mode-syntax-table, meaning we don't get
any of the default text-mode transposition behavior. The most immediate
problem is that apostrophes get "left behind" during transposition. Ie:

I can't| transpose this --> I can transpose|'t this

and not

I can't| transpose this --> I transpose can't| this

The fix would be as simple as the attached patch. I don't know if this
would break anything elsewhere, but I can't imagine it would...

Eric
>From a11bb44a6ab200c4159b03094948bc9b77c0e983 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Mon, 3 Nov 2014 11:22:13 -0800
Subject: [PATCH] Make org-transpose-words use text-mode-syntax-table

* lisp/org.el (org-mode-transpose-word-syntax-table): Make this table
  inherit from `text-mode-syntax-table'.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1e7d8d9..c6b0a1c 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5542,7 +5542,7 @@ The following commands are available:
 		   ("8.2.6" . "24.4")))
 
 (defvar org-mode-transpose-word-syntax-table
-  (let ((st (make-syntax-table)))
+  (let ((st (make-syntax-table text-mode-syntax-table)))
 (mapc (lambda(c) (modify-syntax-entry
 		  (string-to-char (car c)) "w p" st))
 	  org-emphasis-alist)
-- 
2.1.3

[O] bug#11774: Emacs 24.3: newline-and-indent has two undo boundaries

[Samuel Wales]

Reporting as suggested by Stefan.

In order to bunch up undos by 1 instead of the hardcoded 20, I do this:

  (add-hook 'post-self-insert-hook #'undo-boundary 'append)

This or advice used to work, then around Emacs 24.1 it stopped
working.  Stefan patched it in 24.3.  It now works in most cases.  The
history is in this Debian bug:

  Re: [O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost

I use undo-tree 0.6.6.  The bug also occurs with it turned off.

When I press RET when it is bound to newline-and-indent, the newline
and the indentation are undone separately.  I expected the RET to be
undone.

This is a minor issue for me, but might point to other cases.

Thanks.

Samuel

Re: [O] M-S-up/down on plain lists containing text (or multilevel lists)

[Nicolas Goaziou]

James Harkins  writes:

> Upon further reflection, I think the best would be to bind
> org-metaup/down to the "move subtree" menu items, rather than
> org-shiftmetaup. I'm guessing that this is the more common use case
> (because moving a whole subtree doesn't destroy the structure of that
> subtree, while moving a line does), so I think it would make more
> sense to put the more common case in the menu.

Indeed, that's a bug in the menu. Thank you for reporting it.


Regards,

Re: [O] [RFC/PATCH] org-goto: Update for isearch changes

[Nicolas Goaziou]

Kyle Meyer  writes:

> I've attached an updated patch. It now includes a comment about which
> version removed isearch-other-control-char, and the commit message has
> been extended to explain why both 'C-m' and RET are bound to nil.

Applied with a minor tweak: boundp -> fboundp.

Thank you.


Regards,

Re: [O] [PATCH] org-transpose-word: inherit text mode syntax table?

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> Something that has subconsciously bothered me for years:
> `org-transpose-words' does its transposition using a blank syntax table,
> rather than inheriting from text-mode-syntax-table, meaning we don't get
> any of the default text-mode transposition behavior. The most immediate
> problem is that apostrophes get "left behind" during transposition. Ie:
>
> I can't| transpose this --> I can transpose|'t this
>
> and not
>
> I can't| transpose this --> I transpose can't| this
>
> The fix would be as simple as the attached patch. I don't know if this
> would break anything elsewhere, but I can't imagine it would...

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change property drawer syntax

[Nicolas Goaziou]

Christian Egli  writes:

> AFAIK the org-mode taskjuggler exporter was previously able to handle
> this if given the following headline:
>
> * task
> :PROPERTIES:
> :Effort:  1w
> :depends: software
> :allocate: test dev2
> :note: "Hopefully most bugs will be found and fixed here."
> :journalentry: 2002-03-01 "Contract with Peter not yet signed" {
> author boss
> alert red
> summary -8<-
>   The paperwork is stuck with HR and I can't hunt it down.
> ->8-
> details -8<-
>   If we don't get the contract closed within the next week,
>   the start of the testing is at risk.
> ->8-
>   }
> :END:

I'm surprised it worked. Anyway, you're right, it will not anymore.

> Oh, and btw: there can be more than one journalentry. So, given this
> taskjuggler feature is not very often used and drawer machinery is not
> really suited for this use case I suggest we just drop support for it.
> Maybe the user can just squeeze the whole entry on one line interspersed
> with \ns.

I think a #+begin_journalentry ... #+end_journalentry with proper
attributes would be enough.


Regards,

Re: [O] Bug: Org leaves whitespace around :LOGBOOK: [8.2.10 (release_8.2.10 @ /home/jsynacek/.local/share/emacs/24.4/lisp/org/)]

[Nicolas Goaziou]

Jan Synacek  writes:

> Git bisect log:
>
> bad: [3f484a52775c8873a3b1b44e8264e01369850a8a] Fix headline insertion after 
> an empty headline
> good: [e112f3c0df49264998d4ae8df545c9940692f68f] ox-texinfo: Fix corner case 
> when fixing a node name
> good: [409913b253de2de1b49f9468a4b77b9292e090c4] Fix `org-promote' error
> bad: [dc16617f46d64073e4d06308f7150c46d992a408] orgguide.texi: Small fixes
> good: [2e5b3dede103bba0071144ec7b7fc250471c1463] org-element: Interpret 
> headlines according to `org-o;dd-levels-only'
> bad: [2de0c1c3da1e7f9859b82d8af0167c60545c5c5f] Fix 37bf05
> bad: [37bf0576f2f2894c6e37239ee8db63a3ef21a840] org-element: Make properties 
> parsing more robust
> first bad commit: [37bf0576f2f2894c6e37239ee8db63a3ef21a840] org-element: 
> Make properties parsing mor;e robust

I think it's good enough if it is fixed in Org 8.3.

Regards,

Re: [O] [RFC/PATCH] org-goto: Update for isearch changes

[Kyle Meyer]

Nicolas Goaziou  wrote:
[...]
> Applied with a minor tweak: boundp -> fboundp.

Thanks for catching that.

-- 
Kyle

Re: [O] The order of interpreting when exporting

[Marcin Borkowski]

On 2014-11-03, at 18:20, Nicolas Goaziou wrote:

>> do I get it right that exporting starts with the deepest parts, and then
>> proceeds to the outer ones?
>
> Correct.

Thanks!

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] The order of interpreting when exporting

[Nicolas Goaziou]

Marcin Borkowski  writes:

> On 2014-11-03, at 18:20, Nicolas Goaziou wrote:
>
>>> do I get it right that exporting starts with the deepest parts, and then
>>> proceeds to the outer ones?
>>
>> Correct.
>
> Thanks!

As a side note, when reaching the outer parts, you can also discard
everything exported so far within and start afresh with different
options, or a different back-end (e.g., with
`org-export-data-with-backend').

IOW, the order is flexible.


Regards,

[O] odt export of subtree: set/suppress the date in the export

[Steinar Bang]

 Emacs version: GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN
 Org version: Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ 
c:/ProgramFiles/emacs-24.3/lisp/org/)

I use org to take notes in meetings.

When I make an ODT export of the subtree for the meeting minutes, I
would like the date in the ODT document to be the date of the meeting
and not the date when I'm making the export.

Is this possible?

Thanks!

Re: [O] Bug (regression) in org-replace-disputed-keys. Bisected.

[Nicolas Goaziou]

Hello,

Teika Kazura  writes:

> Now a real fix. There're two candidates:
>
> (i) Revert the wrong commit. Since it was in fact done in two separate 
> commits[2], you need another patch, not git-revert. Here it is:
> 
> diff -u -r org-8.2.7c-orig/lisp/org.el org-8.2.7c/lisp/org.el
> --- org-8.2.7c-orig/lisp/org.el   2014-09-30 18:10:54.485977061 +0900
> +++ org-8.2.7c/lisp/org.el2014-09-30 18:11:24.293602328 +0900
> @@ -16220,8 +16220,7 @@
>  (defvar org-read-date-inactive)
>  
>  (defvar org-read-date-minibuffer-local-map
> -  (let* ((org-replace-disputed-keys nil)
> -  (map (make-sparse-keymap)))
> +  (let* ((map (make-sparse-keymap)))
>  (set-keymap-parent map minibuffer-local-map)
>  (org-defkey map (kbd ".")
>  (lambda () (interactive)
> 

I think this change is appropriate. Could you provide a patch with git
format-patch?


Regards,

-- 
Nicolas Goaziou

Re: [O] Previewing chemfig

[John Kitchin]

g"Garreau, Alexandre"  writes:

I cannot reproduce this, my math previews work fine. just the chemfig is
messed up.

> On 2014-11-02 at 22:48, John Kitchin wrote:
>> Nicolas Goaziou  writes:
>>
>> Interestingly, this:
>>
>> #+LATEX_HEADER: \usepackage{chemfig}
>>
>>
>> $\chemfig{A-B-[1]C-[3]-D-[7]E-[6]F}$
>>
>>
>> exports to pdf correctly, but the latex preview is not correct. All the
>> letters are jumbled on top of each other.
>
> Ok, I tested again, and found that actually any preview (even without
> chemfig) completely stops working when I add
> « #+LATEX_HEADER:\usepackage{chemfig} », even pure maths. I just get
> little shrinked transparent void rectangles.
>
> I’m on Debian Testing (Jessy) and hence use Org version 7.9.3f (GNU
> Emacs 24.3).
>

-- 
---
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu

Re: [O] odt export of subtree: set/suppress the date in the export

[Christian Moe]

Hi,

Does setting the subtree's :EXPORT_DATE: property to the date of the
meeting do what you're looking for?

Yours,
Christian

Steinar Bang writes:

>  Emacs version: GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on 
> MARVIN
>  Org version: Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ 
> c:/ProgramFiles/emacs-24.3/lisp/org/)
>
> I use org to take notes in meetings.
>
> When I make an ODT export of the subtree for the meeting minutes, I
> would like the date in the ODT document to be the date of the meeting
> and not the date when I'm making the export.
>
> Is this possible?
>
> Thanks!

Re: [O] Bug: ox-taskjuggler :effort: property incorrectly converted when in minutes

[John Hendy]

On Sun, Nov 2, 2014 at 5:25 PM, Nicolas Goaziou  wrote:
> John Hendy  writes:
>
>> Thanks for the explanation. I pretty much only use duration, which has
>> never had an issue. As a fluke I used effort and noticed the big
>> difference. Thanks for illuminating the situation!
>
> Actually, I was slightly wrong. According to
> `org-duration-string-to-minutes' and `org-effort-durations' docstrings,
> Org accepts modifiers for numbers. IOW
>
>   :Effort: 3d
>
> is a valid value in Org.
>
> The real problem is that "min" is not recognized as a valid modifier,
> since "30min" is basically the same as "30" or "0:30".
>
> I changed `org-effort-durations' default value to include "min" as
> a modifier, which will make your original example work.

Awesome -- thanks a ton!


John

>
>
> Regards,

[O] (noob) interactive template? how?

[Sven Ehret]

Hello,

sorry for my noob question. I searched the list but cannot find anything
that would fit.

My question is: How would I use the template(s) on
http://lebensverrueckt.haktar.org/articles/org-mode-Food/ ?

Thank you for your attention!

Best, Sven.

-- 
Sven Ehret
E-Mail-Verschlüsselung? Ist gerne möglich.

Re: [O] (noob) interactive template? how?

[Brady Trainor]

Sven Ehret  writes:

> Hello,
>
> sorry for my noob question. I searched the list but cannot find anything
> that would fit.
>

It's not clear how noob you are? To Emacs? To Org-mode?

Do you know how to execute the emacs-lisp? Or otherwise insert into your init 
file?

Do you know that these functions are commands because of the "(interactive)" 
lines, so can be called with M-x? Do you know the M-x ALT+x deal?

The functions look for a headline "* Recipe", so your org buffer should have 
that first. M-x recipe-template will prompt for Titel due to "read-string" (I 
type "M-x describe-function" with cursor on "read-string" to read the 
documentation, or the more brief "C-h f").

The command "food/gen-shopping-list" seems to look for an entry "* 
Einkaufsliste", and headlines with "TOCOOK" state, but I did not succeed in 
getting the command to work. Perhaps I should have had some tabular data like 
can be found at 
http://sachachua.com/blog/2012/06/emacs-org-grocery-lists-batch-cooking/. 

Hope this helps reshape your question at least. 

> My question is: How would I use the template(s) on
> http://lebensverrueckt.haktar.org/articles/org-mode-Food/ ?
>
> Thank you for your attention!
>
> Best, Sven.

[O] Org-plot/org-babel-gnuplot not working

[Garreau, Alexandre]

Hello, when I do `org-plot/gnuplot' on a org-plot figure it says
“org-plot/gnuplot: Cannot open load file: gnuplot”.

I also tried org-babel-gnuplot, and on an example code, C-c C-c says
“org-babel-execute-src-block: No org-babel-execute function for
gnuplot!”.

I’m under Debian Testing (Jessy), have version "GNU Emacs 24.3.1
(i586-pc-linux-gnu, GTK+ Version 3.12.2) of 2014-09-07 on babin,
modified by Debian", with Org version 7.9.3f, I’ve installed gnuplot-x11
package via distro, then gnuplot-mode via distro *and* elpa, then org-babel
via ELPA (not found in distro), and I put some come in my init.el to
activate gnuplot, according this:
.

What could be the cause?


pgpKL9y5K5HV9.pgp
Description: PGP signature

Re: [O] Org-plot/org-babel-gnuplot not working

[John Hendy]

On Nov 3, 2014 7:44 PM, "Garreau, Alexandre"  wrote:
>
> Hello, when I do `org-plot/gnuplot' on a org-plot figure it says
> “org-plot/gnuplot: Cannot open load file: gnuplot”.
>
> I also tried org-babel-gnuplot, and on an example code, C-c C-c says
> “org-babel-execute-src-block: No org-babel-execute function for
> gnuplot!”.
>
> I’m under Debian Testing (Jessy), have version "GNU Emacs 24.3.1
> (i586-pc-linux-gnu, GTK+ Version 3.12.2) of 2014-09-07 on babin,
> modified by Debian", with Org version 7.9.3f, I’ve installed gnuplot-x11
> package via distro, then gnuplot-mode via distro *and* elpa, then
org-babel
> via ELPA (not found in distro), and I put some come in my init.el to
> activate gnuplot, according this:
> .
>
> What could be the cause?

Let me take a look. I believe I wrote that worg page a long time ago. I no
longer use gnuplot but would be happy to try and reproduce!

Could you post the gnuplot/babel relevant stuff from your .emacs?

For the record, I'm on Org 8+ and there have been a lot of changes since
7.9, so my results and yours may vary. Then again, I would have written
that from 7.x, so who knows. More in a bit, unless someone beats me :)

John