Re: [O] org-passwords.el and encryption

2016-03-13 Thread Julien Cubizolles
Eric S Fraga  writes:

> On Saturday, 12 Mar 2016 at 11:50, Julien Cubizolles wrote:
>> I've recently started using org-passwords.el. I'm using symmetric
>> encryption for the gpg file where the passwords are stored. I've seen
>> mention of several ways to avoid typing the passphrase over and over in
>> one session: using gpg-agent or not... What would you recommend ?
>
> I use gpg-agent in conjunction with keychain.  Generally works very
> well.

I'll give it a try, thanks.



Re: [O] Bug: Smart quotes for LaTeX export broken in tables [8.3.4 (8.3.4-9-gfda14f-elpa @ elpa/org-20160307/)]

2016-03-13 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> *"test"*

Did you tweak `org-emphasis-regexp-components'? Does it also happen with
non-interactively?

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Smart quotes for LaTeX export broken in tables [8.3.4 (8.3.4-9-gfda14f-elpa @ elpa/org-20160307/)]

2016-03-13 Thread Achim Gratz
Nicolas Goaziou writes:
> Unfortunately, I cannot reproduce the failure. Neither can our buildbot.
> Could you investigate a bit more about it?  For example, how is the
> document below exported to ASCII?
>
>   #+options: ':t
>   #+language: en
>
>   *"test"*

--8<---cut here---start->8---
Table of Contents   

   
_   

   


   


   


   


   
*"test"*

   


   
Org-mode version 8.3.4 (release_8.3.4-15-gdd9be3 @  

   
/usr/share/emacs/site-lisp/org/)

   
--8<---cut here---end--->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Bug: Bulk reschedule with reschedule logging on fails [8.3.4 (8.3.4-5-gdc68d2-elpaplus @ /home/tyria/.emacs.d/elpa/org-plus-contrib-20160229/)]

2016-03-13 Thread Nicolas Goaziou
Hello,

Allen Li  writes:

> The TODO items need to be scheduled first (since it's the REschedule
> that is causing it).  Can you try:
>
> * TODO A
> SCHEDULED: <2016-01-01 Mon>
> * TODO B
> SCHEDULED: <2016-01-01 Mon>

I can now reproduce it.

This raises another question, though. What is a reasonable behaviour for
bulk schedule+log?

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Smart quotes for LaTeX export broken in tables [8.3.4 (8.3.4-9-gfda14f-elpa @ elpa/org-20160307/)]

2016-03-13 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> This might have fixed the functionality, but the test you introduced
> fails on Emacs 24.4 on Raspbian/Jessie:

Unfortunately, I cannot reproduce the failure. Neither can our buildbot.
Could you investigate a bit more about it?  For example, how is the
document below exported to ASCII?

  #+options: ':t
  #+language: en
  *"test"*

Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Exception when trying to export inlined-code [8.3.4 (8.3.4-9-gfda14f-elpa @ ~/.emacs.d/elpa/org-20160307/)]

2016-03-13 Thread Nicolas Goaziou
Hello,

Shlomi Vaknin  writes:

> Does the cache persist to disk? Can I clear it?

It doesn't. You can clear it with `org-element-cache-reset'.


Regards,

-- 
Nicolas Goaziou



Re: [O] org-collector - propview display problems

2016-03-13 Thread Nicolas Goaziou
Hello,

dche  writes:

> With my actual configuration Org-mode 8.3.4 and GNU Emacs 24.3.1
> (i386-mingw-nt6.1.7601), I get the following output :
>
>
> #+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols 
>
> #+END:

It should be ((string= SPENDTYPE "food")).

> #+BEGIN: propview :cols (ITEM (+ 400 amount)) :scope tree :match "example"

Here: (ITEM (+ 400 AMOUNT))

Properties are returned upper-cased by `org-entry-properties'.


Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Exception when trying to export inlined-code [8.3.4 (8.3.4-9-gfda14f-elpa @ ~/.emacs.d/elpa/org-20160307/)]

2016-03-13 Thread Shlomi Vaknin
Hey,


> You can call `org-reload' with an universal argument.

Oh thanks, noted!


> This is indeed a cache corruption.

Does the cache persist to disk? Can I clear it?

I can recall exactly what I did, but after playing around with some things,
exporting started working again on without setting the cache to nil. I
guess I did clear that cache, and would love to know how ;)

Thanks a lot for all your help,
Shlomi


Re: [O] Bug: Smart quotes for LaTeX export broken in tables [8.3.4 (8.3.4-9-gfda14f-elpa @ elpa/org-20160307/)]

2016-03-13 Thread Achim Gratz
Nicolas Goaziou writes:
> Fixed. Thank you.

This might have fixed the functionality, but the test you introduced
fails on Emacs 24.4 on Raspbian/Jessie:

--8<---cut here---start->8---
Test test-org-export/activate-smart-quotes backtrace:
  (if (unwind-protect (setq value-99840 (apply fn-99838 args-99839)) (
  (let (form-description-99842) (if (unwind-protect (setq value-99840 
  (let ((value-99840 (quote ert-form-evaluation-aborted-99841))) (let 
  (let ((fn-99838 (function equal)) (args-99839 (list (quote ("
  (lambda nil (let ((fn-99763 (function equal)) (args-99764 (list (quo
  #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC
  funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  #[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\316%DC\2
  funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\
  ert-run-test([cl-struct-ert-test test-org-export/activate-smart-quot
  ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
  ert-run-tests("\\(org\\|ob\\)" #[385 "\306\307\"\203D\211\211G\310
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
  org-test-run-batch-tests("\\(org\\|ob\\)")
  eval((org-test-run-batch-tests org-test-select-re))
  command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-
  command-line()
  normal-top-level()
Test test-org-export/activate-smart-quotes condition:
(ert-test-failed
 ((should
   (equal '...
(let ... ...)))
  :form
  (equal
   ("foo")
   (#("*foo*" 0 1 ... 8 11 ... 18 19 ...)))
  :value nil :explanation
  (list-elt 0
(arrays-of-different-length 17 19 "foo"
#("*foo*" 0 1 ... 8 
11 ... 18 19 ...)
first-mismatch-at 0
--8<---cut here---end--->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] [PATCH] call_*() is not working inside #+DATE

2016-03-13 Thread Rafael Laboissiere

* Nicolas Goaziou  [2016-03-13 18:24]:


Rafael Laboissiere  writes:


It would be much better if the following construct worked:

#+DATE: src_sh{git show -s --date=short --format="%cd [%h]" HEAD}

Unfortunately, it does not.  This behavior (or misbehavior, I do not 
know) can be traced down to the org-element-context function.


[snip]


Values from keyword are not parsed. Org used to make an exception for an 
arbitrary bunch of them (e.g., DATE, TITLE, etc.). Now it is up to the 
export back-ends to decide what keyword is going to be parsed.


I can think of two ways to solve this:

 1. Only evaluate the Babel code during export. Upon exporting the
document, parsed keywords are known, so
`org-babel-exp-process-buffer' may try to find "hidden" Babel code
and execute it.

This would however introduce a discrepancy between
org-babel-execute-buffer and the behaviour upon exporting.

 2. Sort parsed keywords from regular ones at the syntax level, much
like we did for export blocks recently. I.e., every keyword is
parsed expect those marked as verbatim. I don't have an idea bout
the involved syntax.

This would probably induce some backward incompatibility.

WDYT?


Thanks for your proposal.

I would vote for solution #1.  The discrepancy between 
org-babel-execute-buffer and the behaviour upon exporting that you 
mention would not bother me.


Whatever solution is adopted (or if the current behavior is kept), the 
info documentation must be updated.  Do you agree with the patch that I 
proposed earlier in this thread?


Best,

Rafael



Re: [O] Bug: Exception when trying to export inlined-code [8.3.4 (8.3.4-9-gfda14f-elpa @ ~/.emacs.d/elpa/org-20160307/)]

2016-03-13 Thread Nicolas Goaziou
Hello,

Shlomi Vaknin  writes:

> Without setting it to nil, here is the complete backtrace of an uncompiled
> org (I simply erased all elc files, that sufficient, right?)

You can call `org-reload' with an universal argument.

> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>   goto-char(nil)

This is indeed a cache corruption. Unfortunately, the backtrace doesn't
help to tell what action is responsible for that.

Thank you anyway.


Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] call_*() is not working inside #+DATE

2016-03-13 Thread Nicolas Goaziou
Hello,

Rafael Laboissiere  writes:

> It would be much better if the following construct worked:
>
> #+DATE: src_sh{git show -s --date=short --format="%cd [%h]" HEAD}
>
> Unfortunately, it does not.  This behavior (or misbehavior, I do not 
> know) can be traced down to the org-element-context function.  Suppose 
> that you have the following content in a org-mode buffer:
>
> #+DATE: src_sh{date}
> src_sh{date}
>
> With the cursor just after the underscore in the #+DATE line, 
> org-element-context returns:
>
> (keyword
>  (:key "DATE" :value "src_sh{date}" :begin 1 :end 22 :post-blank 0 
> :post-affiliated 1 :parent nil))
>
> On the other hand, with the cursor just after the underscore in the next 
> line, org-element-context returns (as it should be):
>
> (inline-src-block
>  (:language "sh" :value "date" :parameters nil :begin 22 :end  34 
> :post-blank 0
>    :parent (paragraph (:begin 22 :end 35 :contents-begin 22 :contents-end 
> 35 :post-blank 0
>    :post-affiliated 22 :parent nil
>
> This is the reason why Org-babel does not evaluate the inline source 
> block in the #+DATE line.

Values from keyword are not parsed. Org used to make an exception for an
arbitrary bunch of them (e.g., DATE, TITLE, etc.). Now it is up to the
export back-ends to decide what keyword is going to be parsed.

I can think of two ways to solve this:

  1. Only evaluate the Babel code during export. Upon exporting the
 document, parsed keywords are known, so
 `org-babel-exp-process-buffer' may try to find "hidden" Babel code
 and execute it.

 This would however introduce a discrepancy between
 org-babel-execute-buffer and the behaviour upon exporting.

  2. Sort parsed keywords from regular ones at the syntax level, much
 like we did for export blocks recently. I.e., every keyword is
 parsed expect those marked as verbatim. I don't have an idea bout
 the involved syntax.

 This would probably induce some backward incompatibility.

WDYT?


Regards,

-- 
Nicolas Goaziou



Re: [O] Exporting math code containing a cases environment to LaTeX

2016-03-13 Thread Francesco Turco
On Sun, Mar 13, 2016, at 09:13, Eric S Fraga wrote:
> Yes, indeed.  I forgot to ask what version of org you were using!
> 
> I'm glad the old format works for you.

I forgot to thank you for the help! :)



Re: [O] Exporting math code containing a cases environment to LaTeX

2016-03-13 Thread Eric S Fraga
On Saturday, 12 Mar 2016 at 19:33, Francesco Turco wrote:

[...]

> But I can use #+begin_latex and #+end_latex instead.
>
> I read the former syntax is new and will be released with Org Mode 9.0.
> Is that true?

Yes, indeed.  I forgot to ask what version of org you were using!

I'm glad the old format works for you.