Re: [O] Exporting Org markup unrendered to html
On Monday, 18 Apr 2016 at 07:10, Michael Welle wrote: > Hello, > > I want to export Org task descriptions to html. It's a text about Org, > so I want the tasks to appear in html as they appear in an Org buffer, > colouring is a bonus ;). > > I tried: > > #+BEGIN_SRC org > * TODO foo > #+END_SRC You have to escape the leading *'s with a , as in #+BEGIN_SRC org ,* TODO foo #+END_SRC If you use C-c ' to edit the src block, it does this for you automatically. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-705-g716e33
[O] gpg encryption warning
On gpg encrypting (symmetrical) a file I get the warning: mouse-minibuffer-check: Wrong type argument: window-valid-p, # after clicking ok in the encryption dialogue buffer. The actual encryption seems to work, with password and repeat password prompts. I am using emacs-25.1.50.1, git-pulled and built today. I do not get the warning with emacs-24.5.1. Colin.
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
I don't think so. I haven't seen this be the case. A simple example like this works as expected I think. #+BEGIN_SRC emacs-lisp (setq x 4) #+END_SRC #+RESULTS: : 4 #+BEGIN_SRC emacs-lisp (+ x 9) #+END_SRC #+RESULTS: : 13 So far, I have only seen where this makes some new things possible. e.g. This will not work unless evaluated with lexical-binding #+BEGIN_SRC emacs-lisp :results value :lexical yes ;; Graham's alambda (defmacro alambda (parms &rest body) `(cl-labels ((self ,parms ,@body)) #'self)) (setq N (alambda (n) (if (> n 0) (cons n (self (- n 1)) (princ (funcall N 3)) #+END_SRC #+RESULTS: | 3 | 2 | 1 | This just provides a different approach to :var I think. #+BEGIN_SRC emacs-lisp :lexical '((x . 23)) (print x) #+END_SRC #+RESULTS: : 23 I would be interested to see any counter examples though, where behavior changes, or stops working. Adam Porter writes: > John Kitchin writes: > > Forgive my ignorance--I haven't really dug into lexical scoping yet--but > what is the basic effect will this change have on elisp code blocks? > Say I'm doing some sort-of literate development and I have some code > blocks that `setq' here and there, setting vars in the Emacs > environment. Will the scope of these vars now be limited to their code > blocks? Would I need to disable lexical scoping? Thanks. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] isbn-to-bibtex (from org-ref) fails
I found a (save-buffer) in the bibtex entry clean functions and took that out. I think it solves this problem. Julien Cubizolles writes: > John Kitchin writes: > >> thanks for the report. I think I have fixed it in a recent push. > > It now gets the bibtex entry right however its behaviour is strange: it > asks twice for a file name to save. The first query seems ok but if you > give again the bib file as argument the second time, you get a worrying > message about overwriting it. > > Julien. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Bug: group tags defined in org-tag-persistent-alist do not match their subtags [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/jorge/.emacs.d/elpa/org-20160404/)]
Hello,
Jorge Peixoto de Morais Neto writes:
> Suppose I wanted "animal" to be a group tag matching itself and
> "mammal". I would like them to be mutually exclusive to avoid
> redundancy. So I would define them in org-tag-persistent-alist as
> such:
> (:startgroup)
> ("animal" . ?a)
> (:grouptags)
> ("mammal" . ?m)
> (:endgroup)
>
> But then a tag search (e.g. trough org-match-sparse-tree) for "animal"
> does not match an entry tagged as "mammal". I expected it to match.
Fixed in master. Thank you.
> To ease debugging, I have created a new .emacs.d and removed all
> unnecessary customizations (but still included a copy of my usual
> ~/.emacs.d/elpa). I have also reduced the .org file to a minimum. I
> provide them as a compressed archive (.txz) here:
> https://www.dropbox.com/s/edas2l4e7ekbmek/group-tags-bug.txz?dl=0
> I can also mail it on request (it is about 4MiB)
For the record, it is better to simply post minimal init.el and
"group-tags-bug.org", both as plain text, in the message.
Regards,
--
Nicolas Goaziou
[O] how to suppress extra newline between paragraphs in export?
Hello!
I've got a question I hope you might be able to answer. I'm trying to
add multi-paragraph item support to plain lists to my ox-jira.el
package. c.f. https://github.com/stig/ox-jira.el/issues/17
The issue I have is that I want to replace the blank line between
paragraphs in list items (which in JIRA ends the list and starts a new
paragraph) with the string =\\=. However, even when instrumenting
paragraph to check if its parent is an item (I'm being simplistic here)
there's a blank line I can't get at.
You can see it in an org document as simple as this, actually:
#+BEGIN_EXAMPLE
fi
fo
#+END_EXAMPLE
Then do =M-x pp-eval-expression RET (org-element-parse-buffer) RET=
The output is:
#+BEGIN_EXAMPLE
(org-data nil
(section
(:begin 1 :end 7 :contents-begin 1 :contents-end 7 :post-blank 0
:post-affiliated 1 :parent #0)
(paragraph
(:begin 1 :end 5 :contents-begin 1 :contents-end 4 :post-blank 1
:post-affiliated 1 :parent #1)
#("fi\n" 0 3
(:parent #2)))
(paragraph
(:begin 5 :end 7 :contents-begin 5 :contents-end 7 :post-blank 0
:post-affiliated 5 :parent #1)
#("fo" 0 2
(:parent #2)
#+END_EXAMPLE
However, if you actually generate the output (for ascii, for example) you get:
#+BEGIN_EXAMPLE
fi
fo
#+END_EXAMPLE
So there's an extra newline before =fo= that no transpose functions are
responsible for, as far as I can see. Is it possible to get at this
somehow?
Alternatively, do anyone have suggestions for how to support
multi-paragraph list items?
Stig
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
Hello, John Kitchin writes: > Set default in `org-babel-default-header-args:emacs-lisp'. Add an > optional argument to the eval function. Thanks for the patch. Some comments follow. > +*** Default lexical evaluation of emacs-lisp src blocks > +Emacs-lisp src blocks in babel are now evaluated using lexical scoping. > There is a new header to control this behavior. > + > +The default results in an eval with lexical scoping. > +:lexical yes > + > +This turns lexical scoping off in the eval (the former behavior). > +:lexical no > + > +This uses the lexical environment with x=42 in the eval. > +:lexical '((x . 42)) According to the Elisp manual: The value of LEXICAL can also be a non-empty alist specifying a particular "lexical environment" for lexical bindings; however, this feature is only useful for specialized purposes, such as in Emacs Lisp debuggers. *Note Lexical Binding::. I'm not opposed to it, but is there any reason to include the opportunity to specify an alist here? > +(defvar org-babel-default-header-args:emacs-lisp > + '((:lexical . "yes")) > + "Default arguments for evaluating an emacs-lisp source block. > + > +:lexical is \"yes\" by default and causes src blocks to be eval'd > +using lexical scoping. It can also be an alist mapping symbols to > +their value. It is used as the optional LEXICAL argument to > +`eval'.") You need to separate sentences with two spaces. You also need to add (defconst org-babel-header-args:emacs-lisp). See for example `org-babel-header-args:R'. > (defun org-babel-expand-body:emacs-lisp (body params) >"Expand BODY according to PARAMS, return the expanded body." > @@ -51,13 +57,18 @@ > (defun org-babel-execute:emacs-lisp (body params) >"Execute a block of emacs-lisp code with Babel." >(save-window-excursion > -(let ((result > - (eval (read (format (if (member "output" > - (cdr (assoc :result-params > params))) > - "(with-output-to-string %s)" > - "(progn %s)") > - (org-babel-expand-body:emacs-lisp > -body params)) > +(let* ((lexical (cdr (assoc :lexical params))) Nitpick: (cdr (assq :lexical params)) > +(result > + (eval (read (format (if (member "output" > + (cdr (assoc :result-params params))) Nitpick, while you're at it: (cdr (assq :result-params params)) > + "(with-output-to-string %s)" > + "(progn %s)") > + (org-babel-expand-body:emacs-lisp > + body params))) > + > + (if (listp lexical) > + lexical > + (string= "yes" lexical) There is no support for t. I think we should allow both :lexical t and :lexical yes. Regards, -- Nicolas Goaziou
Re: [O] how to suppress extra newline between paragraphs in export?
Hello, Stig Brautaset writes: > I've got a question I hope you might be able to answer. I'm trying to > add multi-paragraph item support to plain lists to my ox-jira.el > package. c.f. https://github.com/stig/ox-jira.el/issues/17 > > The issue I have is that I want to replace the blank line between > paragraphs in list items (which in JIRA ends the list and starts a new > paragraph) with the string =\\=. However, even when instrumenting > paragraph to check if its parent is an item (I'm being simplistic here) > there's a blank line I can't get at. > > You can see it in an org document as simple as this, actually: > > #+BEGIN_EXAMPLE > fi > > fo > #+END_EXAMPLE [...] >(paragraph > (:begin 1 :end 5 :contents-begin 1 :contents-end 4 :post-blank 1 > :post-affiliated 1 :parent #1) ^^^ blank line [...] > So there's an extra newline before =fo= that no transpose functions are > responsible for, as far as I can see. Is it possible to get at this > somehow? You can set the :post-blank value to 0 using a parse tree filter. See for example `org-md-separate-elements'. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
Thanks for the feedback. I have a few questions below.
On Mon, Apr 18, 2016 at 12:38 PM, Nicolas Goaziou
wrote:
> Hello,
>
> John Kitchin writes:
>
> > Set default in `org-babel-default-header-args:emacs-lisp'. Add an
> > optional argument to the eval function.
>
> Thanks for the patch. Some comments follow.
>
> > +*** Default lexical evaluation of emacs-lisp src blocks
> > +Emacs-lisp src blocks in babel are now evaluated using lexical scoping.
> There is a new header to control this behavior.
> > +
> > +The default results in an eval with lexical scoping.
> > +:lexical yes
> > +
> > +This turns lexical scoping off in the eval (the former behavior).
> > +:lexical no
> > +
> > +This uses the lexical environment with x=42 in the eval.
> > +:lexical '((x . 42))
>
> According to the Elisp manual:
>
> The value of LEXICAL can also be a non-empty alist specifying
> a particular "lexical environment" for lexical bindings; however,
> this feature is only useful for specialized purposes, such as in
> Emacs Lisp debuggers. *Note Lexical Binding::.
>
> I'm not opposed to it, but is there any reason to include the
> opportunity to specify an alist here?
>
I just put it in because it is an option for the eval function, and it was
not difficult to implement. It might be useful for debugging.
>
> > +(defvar org-babel-default-header-args:emacs-lisp
> > + '((:lexical . "yes"))
> > + "Default arguments for evaluating an emacs-lisp source block.
> > +
> > +:lexical is \"yes\" by default and causes src blocks to be eval'd
> > +using lexical scoping. It can also be an alist mapping symbols to
> > +their value. It is used as the optional LEXICAL argument to
> > +`eval'.")
>
> You need to separate sentences with two spaces.
>
no problem.
>
> You also need to add (defconst org-babel-header-args:emacs-lisp). See
> for example `org-babel-header-args:R'.
>
Are you suggesting use defconst instead of defvar? Does it really need all
the things in org-babel-header-args:R? Or just the required default for
lexical?
>
> > (defun org-babel-expand-body:emacs-lisp (body params)
> >"Expand BODY according to PARAMS, return the expanded body."
> > @@ -51,13 +57,18 @@
> > (defun org-babel-execute:emacs-lisp (body params)
> >"Execute a block of emacs-lisp code with Babel."
> >(save-window-excursion
> > -(let ((result
> > - (eval (read (format (if (member "output"
> > - (cdr (assoc :result-params
> params)))
> > - "(with-output-to-string %s)"
> > - "(progn %s)")
> > - (org-babel-expand-body:emacs-lisp
> > -body params))
> > +(let* ((lexical (cdr (assoc :lexical params)))
>
> Nitpick: (cdr (assq :lexical params))
>
no problem.
>
> > +(result
> > + (eval (read (format (if (member "output"
> > + (cdr (assoc :result-params
> params)))
>
> Nitpick, while you're at it: (cdr (assq :result-params params))
>
no problem. Should all the assocs be replaced by assq, or just these ones?
>
> > + "(with-output-to-string %s)"
> > + "(progn %s)")
> > + (org-babel-expand-body:emacs-lisp
> > + body params)))
> > +
> > + (if (listp lexical)
> > + lexical
> > + (string= "yes" lexical)
>
> There is no support for t. I think we should allow both :lexical
> t and :lexical yes.
>
something like (member lexical '("yes" "t"))?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
John Kitchin writes:
> I just put it in because it is an option for the eval function, and it was
> not difficult to implement. It might be useful for debugging.
Fair enough.
> Are you suggesting use defconst instead of defvar? Does it really need all
> the things in org-babel-header-args:R? Or just the required default for
> lexical?
Two variables are needed: `org-babel-default-header-args:emacs-lisp' and
`org-babel-header-args:emacs-lisp'. The latter is used, e.g., in linting
to know what keywords are allowed in an emacs-lisp block and, if
possible, the possible values for it.
> no problem. Should all the assocs be replaced by assq, or just these
> ones?
I usually replace (assoc/member KEYWORD ...) with (assq/memq KEYWORD
...) whenever I modify a S-exp around it. You don't need to change this
for parts you don't alter.
>> > + "(with-output-to-string %s)"
>> > + "(progn %s)")
>> > + (org-babel-expand-body:emacs-lisp
>> > + body params)))
>> > +
>> > + (if (listp lexical)
>> > + lexical
>> > + (string= "yes" lexical)
>>
>> There is no support for t. I think we should allow both :lexical
>> t and :lexical yes.
>>
>
> something like (member lexical '("yes" "t"))?
Honestly, I don't remember how Babel handles parameters. It could also
be '("yes" t) if the latter is recognized as a keyword. You get the
idea :)
Regards,
[O] [PATCH] Make lexical eval default for elisp src blocks
Set default in `org-babel-default-header-args:emacs-lisp'. Add an
optional argument to the eval function.
---
etc/ORG-NEWS | 11 +++
lisp/ob-emacs-lisp.el | 33 -
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6b1d9d5..99241e2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -467,6 +467,17 @@ docstring for more information.
- ~org-latex-format-inlinetask-function~
- ~org-link-search~
** New features
+*** Default lexical evaluation of emacs-lisp src blocks
+Emacs-lisp src blocks in babel are now evaluated using lexical scoping. There
is a new header to control this behavior.
+
+The default results in an eval with lexical scoping.
+:lexical yes
+
+This turns lexical scoping off in the eval (the former behavior).
+:lexical no
+
+This uses the lexical environment with x=42 in the eval.
+:lexical '((x . 42))
*** Behavior of ~org-return~ changed
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 2eb2721..051d2bb 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -28,8 +28,18 @@
;;; Code:
(require 'ob)
-(defvar org-babel-default-header-args:emacs-lisp nil
- "Default arguments for evaluating an emacs-lisp source block.")
+(defconst org-babel-header-args:emacs-lisp
+ '((lexical . ((yes no t nil
+ "emacs-lisp specific header arguments.")
+
+(defvar org-babel-default-header-args:emacs-lisp
+ '((:lexical . "yes"))
+ "Default arguments for evaluating an emacs-lisp source block.
+
+:lexical is \"yes\" by default and causes src blocks to be eval'd
+using lexical scoping. It can also be an alist mapping symbols to
+their value. It is used as the optional LEXICAL argument to
+`eval'.")
(defun org-babel-expand-body:emacs-lisp (body params)
"Expand BODY according to PARAMS, return the expanded body."
@@ -51,13 +61,18 @@
(defun org-babel-execute:emacs-lisp (body params)
"Execute a block of emacs-lisp code with Babel."
(save-window-excursion
-(let ((result
- (eval (read (format (if (member "output"
- (cdr (assoc :result-params params)))
- "(with-output-to-string %s)"
- "(progn %s)")
- (org-babel-expand-body:emacs-lisp
-body params))
+(let* ((lexical (cdr (assq :lexical params)))
+ (result
+ (eval (read (format (if (member "output"
+ (cdr (assq :result-params params)))
+ "(with-output-to-string %s)"
+ "(progn %s)")
+ (org-babel-expand-body:emacs-lisp
+body params)))
+
+ (if (listp lexical)
+ lexical
+ (member lexical '("yes" "t"))
(org-babel-result-cond (cdr (assoc :result-params params))
(let ((print-level nil)
(print-length nil))
--
2.4.4
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
thanks. I think I have addressed these in a new patch I just submitted.
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Mon, Apr 18, 2016 at 1:41 PM, Nicolas Goaziou
wrote:
> John Kitchin writes:
>
> > I just put it in because it is an option for the eval function, and it
> was
> > not difficult to implement. It might be useful for debugging.
>
> Fair enough.
>
> > Are you suggesting use defconst instead of defvar? Does it really need
> all
> > the things in org-babel-header-args:R? Or just the required default for
> > lexical?
>
> Two variables are needed: `org-babel-default-header-args:emacs-lisp' and
> `org-babel-header-args:emacs-lisp'. The latter is used, e.g., in linting
> to know what keywords are allowed in an emacs-lisp block and, if
> possible, the possible values for it.
>
> > no problem. Should all the assocs be replaced by assq, or just these
> > ones?
>
> I usually replace (assoc/member KEYWORD ...) with (assq/memq KEYWORD
> ...) whenever I modify a S-exp around it. You don't need to change this
> for parts you don't alter.
>
> >> > + "(with-output-to-string %s)"
> >> > + "(progn %s)")
> >> > + (org-babel-expand-body:emacs-lisp
> >> > + body params)))
> >> > +
> >> > + (if (listp lexical)
> >> > + lexical
> >> > + (string= "yes" lexical)
> >>
> >> There is no support for t. I think we should allow both :lexical
> >> t and :lexical yes.
> >>
> >
> > something like (member lexical '("yes" "t"))?
>
> Honestly, I don't remember how Babel handles parameters. It could also
> be '("yes" t) if the latter is recognized as a keyword. You get the
> idea :)
>
> Regards,
>
Re: [O] Bug: group tags defined in org-tag-persistent-alist do not match their subtags [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/jorge/.emacs.d/elpa/org-20160404/)]
> For the record, it is better to simply post minimal init.el and
> "group-tags-bug.org", both as plain text, in the message.
Of course. Sorry for being obtuse. And I took the opportunity to test
that the bug still occurs in org-20160418.
File group-tags-bug.org:
---
* Dummy
** Human :mammal:
---
File init.el:
---
;; Added by Package.el. This must come before configurations of
;; installed packages. Don't delete this line. If you don't want it,
;; just comment it out by adding a semicolon to the start of the line.
;; You may delete these explanatory comments.
(package-initialize)
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(org-tag-persistent-alist
(quote
((:startgroup)
("animal" . 97)
(:grouptags)
("mammal" . 109)
(:endgroup)
(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
)
---
Re: [O] Bug: Repeated candidate tags in org-set-tags-command interface [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/jorge/.emacs.d/elpa/org-20160404/)]
On 12 April 2016 at 17:35, Nicolas Goaziou wrote:
> Could you send it by mail? You can remove the copy of ~/.emacs.d/elpa.
As you requested in the other e-mail, here are the files inline:
File repeated-tags-bug-trigger.org:
--
* Dummy Headline :dummy:
--
File init.el:
--
;; Added by Package.el. This must come before configurations of
;; installed packages. Don't delete this line. If you don't want it,
;; just comment it out by adding a semicolon to the start of the line.
;; You may delete these explanatory comments.
(package-initialize)
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(org-tag-persistent-alist (quote (("dummy" . 100)
(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
)
--
Re: [O] Bug: group tags defined in org-tag-persistent-alist do not match their subtags [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/jorge/.emacs.d/elpa/org-20160404/)]
Jorge writes: >> For the record, it is better to simply post minimal init.el and >> "group-tags-bug.org", both as plain text, in the message. > Of course. Sorry for being obtuse. And I took the opportunity to test > that the bug still occurs in org-20160418. The bug was fixed in master, i.e., development branch. It means the fix will not appear on ELPA before Org 9.0 is released. Regards,
Re: [O] Bug: Repeated candidate tags in org-set-tags-command interface [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/jorge/.emacs.d/elpa/org-20160404/)]
Hello,
Jorge writes:
> On 12 April 2016 at 17:35, Nicolas Goaziou wrote:
>> Could you send it by mail? You can remove the copy of ~/.emacs.d/elpa.
>
> As you requested in the other e-mail, here are the files inline:
>
> File repeated-tags-bug-trigger.org:
> --
> * Dummy Headline :dummy:
> --
>
> File init.el:
> --
[...]
> (custom-set-variables
> ;; custom-set-variables was added by Custom.
> ;; If you edit it by hand, you could mess it up, so be careful.
> ;; Your init file should contain only one such instance.
> ;; If there is more than one, they won't work right.
> '(org-tag-persistent-alist (quote (("dummy" . 100)
Fixed in maint. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Bug: group tags defined in org-tag-persistent-alist do not match their subtags [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/jorge/.emacs.d/elpa/org-20160404/)]
OK. Thank you very much for improving Org! Regards On 18 April 2016 at 20:21, Nicolas Goaziou wrote: > Jorge writes: > >>> For the record, it is better to simply post minimal init.el and >>> "group-tags-bug.org", both as plain text, in the message. >> Of course. Sorry for being obtuse. And I took the opportunity to test >> that the bug still occurs in org-20160418. > > The bug was fixed in master, i.e., development branch. It means the fix > will not appear on ELPA before Org 9.0 is released. > > Regards, -- - I am Brazilian. I apologize for possibly bad English and I welcome corrections. - Please adopt free formats like PDF, ODF, LaTeX, Vorbis, Opus, WebM and 7z. - Free software for Android: https://f-droid.org/
Re: [O] Exporting Org markup unrendered to html
Hi Michael, That is very cool! Thanks for sharing. I can imagine integrating that with org-habits somehow. You might consider putting the lisp files on GitHub somewhere.
