Re: Special symbols with monospace
Jarmo Hurri wrote: I like to embed pseudocode etc. in example blocks so that it is typeset in monospace when exported. But sometimes I would need special symbols, such as \neq, in pseudocode. What is the easiest way to combine monospace and special symbols? Is there any problem with UTF-8 symbols such as "≠"? I have typed it using Compose / =
Special symbols with monospace
Greetings. I like to embed pseudocode etc. in example blocks so that it is typeset in monospace when exported. But sometimes I would need special symbols, such as \neq, in pseudocode. What is the easiest way to combine monospace and special symbols? Jarmo
Re: babel default header args as functions
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
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
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]
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
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
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
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?
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
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
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
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 &optional 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) >