Re: babel default header args as functions

2020-10-14 Thread Matt Huszagh
rey-coyrehourcq  writes:

> I'm unfamilliar with patch by mail but i try to apply your patch to my melpa 
> local org 9.4 version used by doom emacs.
> Patch hang on Hunk #3, i attach the .rej file.

You might need to start from a different org commit. I believe
6a182b690f works. Otherwise, you could fix the merge conflicts (this is
described online, e.g., https://stackoverflow.com/a/16968982/5710525).

Finally, a very crude solution would be to manually apply the changes
yourself if you're not too conversant with git. The git solutions are
better, but since the changes in this patch are minimal it wouldn't take
too long.

I will at some point fix the conflicts myself and send a new patch, but
I'd prefer to wait until it gets the green light to merge so that I
don't have to do it multiple times.

Matt



ob-sql posgresql windows problems

2020-10-14 Thread Neil Cherry

I'm on a Windows 10 System, I'm using ob-sql.el and when I C-c C-c on the src 
block I
get:

'PGPASSWORD' os mpt recognized as an internal or external command.

Example block:

#+name: My queries (Not working - 'PGPASSWORD' is not recognized as an internal 
or external)
#+header: :engine postgresql
#+header: :dbhost pgdb.example.com
#+header: :dbuser user
#+header: :dbpassword password
#+header: :database db
#+begin_src sql
select count(*) from db.pserver
#+end_src

I've tried to use an elisp block to set the SHELL to the correct bash path but 
it
still calls cmd.

Any suggestions to help with debugging.

--
Linux Home Automation Neil Cherry   nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of:  Linux Smart Homes For Dummies



Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-14 Thread 吴锐扬
Hi,

I have org-confirm-babel-evaluate set to t by default. With this, I expect to 
be queried with the execution of every code block or lob call. However, this 
does not happen when exporting lob calls (to latex for example). Here is an 
example:
__

1. Exporting code block (with evaluation)
#+name: foo
#+begin_src emacs-lisp :exports both
  (message "hello world!")
#+end_src

When exporting this to latex, I get queried as expected. And there is no way to 
suppress the query unless I change org-confirm-babel-evaluate to nil.

2. Exporting lob call
#+name: foo
#+begin_src emacs-lisp
  (message "hello world!")
#+end_src

#+call: foo()

When exporting this to latex, I don’t get queried. This seems dangerous to me.
__

I find it hard to explain this inconsistency. If org-confirm-babel-evaluate is 
designed to be a protective layer, then a user might export an org file that 
includes malicious code along with a lob call, while unawarely execute that 
code without being warned. This seems to defeat the purpose of 
org-confirm-babel-evaluate.

As I searched the archive, I found this change was introduced in the following 
thread: https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg00764.html

+ (let (org-confirm-babel-evaluate)
+   (org-babel-execute-src-block nil info))

Do you think this is the intended behavior of org-confirm-babel-evaluate, or am 
I missing something?

Thanks,
Ruiyang




Bug: org-agenda-undo does not work with repeated tasks [9.4]

2020-10-14 Thread Warren Lynn
With org-mode 9.4, if you have a repeated task like this:

* TODO My weekly task
  SCHEDULED: <2020-10-14 Wed +1w>

In daily agenda, if you mark the task done, which will cause the above to
change into:

* TODO My weekly task
  SCHEDULED: <2020-10-21 Wed +1w>
  :PROPERTIES:
  :LAST_REPEAT: [2020-10-14 Wed 11:45]
  :END:
  :LOGBOOK:
  - State "DONE"   from "TODO"   [2020-10-14 Wed 11:45]
  :END:

But then if you run "org-agenda-undo" immediately in the agenda buffer, the
task did not revert back to the original, instead, only the "LOGBOOK" part
is gone, so it becomes this:

* TODO My weekly task
  SCHEDULED: <2020-10-21 Wed +1w>
  :PROPERTIES:
  :LAST_REPEAT: [2020-10-14 Wed 11:45]
  :END:

I don't think that's what people would expect from "org-agenda-undo", so it
seems a bug to me.

This bug is also in orgmode 6.3.7, so likely has been there for a long time.

Thanks for looking into this.

Warren


Re: babel default header args as functions

2020-10-14 Thread rey-coyrehourcq
Hi Matt,

I'm unfamilliar with patch by mail but i try to apply your patch to my melpa 
local org 9.4 version used by doom emacs.
Patch hang on Hunk #3, i attach the .rej file.

patch -p1 < 0001-ob-core.el-Add-ability-to-use-closures-as-default-he.patch

File to patch: ob-core.el
patching file ob-core.el
Hunk #1 succeeded at 467 (offset -6 lines).
Hunk #2 succeeded at 596 (offset -16 lines).
Hunk #3 FAILED at 2745.
Hunk #4 succeeded at 2714 (offset -51 lines).
1 out of 4 hunks FAILED -- saving rejects to file ob-core.el.rej
patch unexpectedly ends in middle of line

Best

Le mercredi 14 octobre 2020 à 07:16 -0700, Matt Huszagh a écrit :
> rey-coyrehourcq  writes:
> 
> > I'm interested by this functionality, do you know if it was merged or i 
> > need to apply patch locally ?
> 
> Hi SR,
> 
> This hasn't been merged yet. I believe it's ready, but we're just
> waiting on a maintainer to apply it upstream. If you're able to apply
> the patch locally and provide feedback that always helps.
> 
> Matt
-- 

Sébastien Rey-Coyrehourcq
Research Engineer UMR IDEES
02.35.14.69.30

{Stronger security for your email, follow EFF tutorial : https://ssd.eff.org/}

--- lisp/ob-core.el
+++ lisp/ob-core.el
@@ -2745,12 +2786,21 @@ parameters when merging lists."
   results-exclusive-groups
   results
   (split-string
-   (if (stringp value) value (eval value t))
+   (if (stringp value)
+   value
+ (if (functionp value)
+	 (funcall value)
+   (eval value t)))
 	  (`(:exports . ,value)
 	   (setq exports (funcall merge
   exports-exclusive-groups
   exports
-  (split-string (or value "")
+  (split-string (or
+		 (if value
+		 (if (functionp value)
+			 (funcall value)
+		   value)
+		   ""))
 	  ;; Regular keywords: any value overwrites the previous one.
 	  (_ (setq params (cons pair (assq-delete-all (car pair) params)))
 ;; Handle `:var' and clear out colnames and rownames for replaced


signature.asc
Description: This is a digitally signed message part


Re: Shower thought: submit an IETF RFC to register Org as a MIME type

2020-10-14 Thread Nicolas Goaziou
Hello,

"Lennart C. Karssen"  writes:

> Wouldn't it be a good idea to standardise on either uppercase or
> lowercase? Limitting the standard to only one of the two case options
> will probably spark a huge debate on which one to choose because one
> side would have to change their behaviour. But at least for the Org code
> that is generated automatically like in the above case of the default
> export template I think choosing a 'preferred' option that is consistent
> with the syntax document and the manual would help.

Org is standardized on lower case. Uppercase is used in the manual as
a poor man's bold, and supported for historical reasons.

Regards,
-- 
Nicolas Goaziou



Re: babel default header args as functions

2020-10-14 Thread Matt Huszagh
rey-coyrehourcq  writes:

> I'm interested by this functionality, do you know if it was merged or i need 
> to apply patch locally ?

Hi SR,

This hasn't been merged yet. I believe it's ready, but we're just
waiting on a maintainer to apply it upstream. If you're able to apply
the patch locally and provide feedback that always helps.

Matt



Is ELPA's installation supposed to be missing script files?

2020-10-14 Thread Guilherme Passos
What the title asks.

I have always used org installed via ELPA's org-plus-contrib, and I have just 
now find out about ditaa. I checked that I was missing it in the elpa 20200921 
version and proceed to update it to 20201012, to no avail.
When comparing to the git repo, I noticed that every file listed under 
"scripts/" (all the non .el files) are missing in the elpa distribution.

Is this intended? This is somewhat strange, given that the installation via 
ELPA is listed first in the website (so seems to be the preferred one).

Thank you very much!
Best wishes,
Guilherme Passos


Re: babel default header args as functions

2020-10-14 Thread rey-coyrehourcq
Hi there,

I'm interested by this functionality, do you know if it was merged or i need to 
apply patch locally ?

Thanks Matt for your work,

Best 
SR

Le mercredi 09 septembre 2020 à 12:33 -0700, Tom Gillespie a écrit :
> Hi Matt,
>Looking good here. Thanks!
> Tom
> 
> On Wed, Sep 9, 2020 at 12:06 PM Matt Huszagh  wrote:
> > Tom Gillespie  writes:
> > 
> > > [...] I have a number of use
> > > cases that I can imagine would benefit greatly from being able to
> > > define a :header-args: :header (lambda () "yay!") property as a
> > > closure (and actually I assumed that it would just work that way if I
> > > tried to do it, clearly not though). I can't tell for sure if the
> > > patch enables this behavior though or whether I would still get a
> > > Wrong type argument error.
> > 
> > This should work. Do you have reason for believing it might not?
> 
> With the patch applied this is working on my end.
> 
> * test header
> :PROPERTIES:
> :header-args:bash: :tangle (lambda () "./from-header.sh")
> :END:
> 
> #+begin_src bash :shebang "#!/usr/bin/env bash"
> echo yes
> #+end_src
> 
> > > [...] Looking
> > > at the patch it seems that it preserves the behavior of performing the
> > > evaluation of the closures at the source block, but I'm not 100% sure.
> > 
> > I'm not sure I completely understand what you mean here. However, the
> > closures are evaluated when point is at the source block, during the
> > source block evaluation, not when the default headers are declared. This
> > allows the closures to use context-dependent functionality (e.g. you can
> > call `org-element-at-point' inside the closure and retrieve whatever
> > information you want). Does this address your concern? Please clarify if
> > I've missed your point.
> 
> Yep, you've got it.
> 
> > > If the default header closures are being evaluated before checking
> > > whether they have been superseded by the headers on a block then that
> > > is incorrect and they should not be evaluated until it is clear that
> > > they are the value of the header for that block and have not been
> > > superseded.
> > 
> > I've fixed my patch (attached) so that now closures are only evaluated
> > when they are used as part of the final set of headers.
> 
> Great.
> 




signature.asc
Description: This is a digitally signed message part


Re: Shower thought: submit an IETF RFC to register Org as a MIME type

2020-10-14 Thread Lennart C. Karssen
Hi all,

On 01-10-2020 05:40, TEC wrote:
> 
> Bastien  writes:
> 
>> If there is absolutely zero burden put on the shoulders of Org's
>> maintainers, then I'm all for it.
> 
> From the look of things, there's just effort in the initial creation.
> 
>>> I think it would serve well the proliferation and
>>> popularization of org-mode.
>>
>> Agreed.
> 
> This is the main reason why I'm a fan of the idea :)
> 
>> Is anyone willing to check that there are no constraints?
> 
> I've read through https://tools.ietf.org/html/rfc6838 and I couldn't see
> any constraints placed on us beyond the initial registration's
> requirements.
> 
> For that, I think a formal syntax specification would be needed. Perhaps
> https://orgmode.org/worg/dev/org-syntax.html will do? It looks complete.


One of the things I have been wondering about with regard to Org syntax
is the use of capital letters vs. lowercase ones for e.g. blocks and
options.

The org-syntax.html document linked above lists blocks as
#+BEGIN_NAME/#+END_NAME, #+KEY: VALUE, #+CALL: VALUE, #+ATTR_BACKEND,
etc. all in uppercase.

On the other hand, the manual states in the introduction: "Keywords and
blocks are written in uppercase to enhance their readability, but you
can use lowercase in your Org files."

At the same time, when I run org-export-dispatch to insert the default
export template (via C-c C-e # default on Org 9.3) I get all #+options,
#+title, etc. lines in lowercase.


Wouldn't it be a good idea to standardise on either uppercase or
lowercase? Limitting the standard to only one of the two case options
will probably spark a huge debate on which one to choose because one
side would have to change their behaviour. But at least for the Org code
that is generated automatically like in the above case of the default
export template I think choosing a 'preferred' option that is consistent
with the syntax document and the manual would help.


Best regards,

Lennart.

> 
> I'm hoping we could then use https://tools.ietf.org/html/rfc7763
> (registration of text/markdown) as a template, where we could just link
> to the syntax specification.
> 
> Perhaps it could be worth putting the syntax spec under the main site as
> something like orgmode.org/syntax-spec.html.
> 
> I've also been considering spinning off the manual into a bit of a
> specification document (e.g. less of a guide / how-to, stripped down to
> just the bare information), so perhaps
> orgmode.org/specification.html#syntax ? I'd really like some second
> opinions.
> 
>> Is anyone willing to move forward with this registration?
> 
> In about two months, I am.
> 
> It looks like creating and draft and then emailing it to
> media-ty...@iana.org would probably be the best approach.
> 
> All the best,
> 
> Timothy.
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



signature.asc
Description: OpenPGP digital signature


Re: org-tables with monetary amounts

2020-10-14 Thread Christian Moe


Hi, Derek,

Very useful, thanks!

Yours,
Christian

Derek Feichtinger writes:

> Hi,
>
> On Mon, Oct 12 2020, Eric S Fraga  wrote:
>
>> On Monday, 12 Oct 2020 at 10:22, Christian Moe wrote:
>>> I think I was thinking about adding mode flags for unit computations,
>>> like in the imagined example above (`$3=$2+$1;u'), similar to what has
>>> been done for duration computations.
>>
>> This would be very useful, actually.  I use embedded calc all the time
>> with units; being able to use some of the same expressions in a table
>> would be highly welcome.
>
> The functions that one can use in calc formulas can be extended using
> the 'defmath' lisp command. I paste here from my notes (not about
> monetary units, but easily adapted):
>
> +++
> Defining a new calc function for unit conversion with defmath
> #+BEGIN_SRC emacs-lisp
> (defmath uconv (expr target-units  pure)
>   (math-convert-units expr target-units pure))
> #+END_SRC
>
> #+RESULTS:
> : calcFunc-uconv
>
> | km | ft   |
> |+--|
> | 2.5 km | 8202.0997 ft |
> #+TBLFM: $2=uconv($1, ft)
>
> Using the units from the table header (if the 3rd arg is given to
> uconv, the output is stripped of the unit):
>
> |  km |ft |
> |-+---|
> | 2.5 | 8202.0997 |
> #+TBLFM: $2 = uconv($1 * @<$1, @<$2, t)
>
> The standard calc function usimplify also works for this use
> case:
>
> |  km |ft |
> |-+---|
> | 2.5 | 8202.0997 |
> #+TBLFM: $2 = usimplify($1 * @<$1 / @<$2)
>
> A lisp equivalent of the above
> #+begin_src elisp
> (calc-eval "usimplify(2.5 km / ft)")
> #+end_src
>
> #+RESULTS:
> : 8202.09973753
>
> Let's define a function that converts to base units
> #+begin_src elisp
>   (defmath ustd (expr) (math-simplify-units (math-to-standard-units expr 
> nil)))
> #+end_src
>
> #+RESULTS:
> : calcFunc-ustd
>
> | distance | time   | speed   | std unit speed   | speed in ft/s|
> |--++-+--+--|
> | 3 km | 2.5 hr | 1.2 km / hr | 0. m / s | 1.0936133 ft / s |
> #+TBLFM: @2$3=$1/$2::@2$4=ustd($3)::@2$5=uconv($-1, ft/s)
>