Re: [O] org-passwords.el and encryption
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/)]
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/)]
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/)]
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/)]
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/)]
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
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/)]
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/)]
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
* 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/)]
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
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
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
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.