Re: [O] data loss : org-mode 9 deletes encrypted entries if no pass is provided
Completing myself, > fxiny writes: > >> old 8.2.10 left the entry unencrypted but untouched >> 9 deletes if the pass provided is none : a plain double pressed enter >> >> atm i'm running 9.0.3 >> same problem with 0.1 and 0.2 >> >> emacs version 25.1.90.1 >> >> to reproduce : unencrypt , modify , save >> no pass but press enter twice > > Could you provide an ECM? Never mind. Fixed. Thank you. Regards,
Re: [O] Bug: org-publish-get-project-from-filename raises (wrong-type-argument sequencep any)
>> Perhaps, `org-publish-get-project-from-filename' can be rewritten >> without `catch' and `throw' using `cl-some' or `seq-some'. This is not a >> bug. But, it might help improve readability of the logic. > > Done. Nice. Looks good. > Note that `seq-some' is not an option since we support Emacs 24.3 > and onwards. Yeah, I guessed. signature.asc Description: PGP signature
Re: [O] Referring to an Org Babel variable in the invocation arguments to another Org Babel code block
Hi Nicolas,
I tried "c", and it gives me:
>>> c <<<
as the result.
I would like it to use the _variable_ "c", not the literal string.
So the result should be ">>> test <<<"
I've also cleaned up the Org I made (something went wrong when I pasted
it before, it missed an #+END_SRC)
Thanks!
#+NAME: block-1
#+BEGIN_SRC shell :var x="X"
echo ">>>" $x "<<<" #+END_SRC
#+END_SRC
#+BEGIN_SRC shell :var c="test" y=block-1("c")
echo $y
#+END_SRC
#+RESULTS:
: >>> c <<<
On 12/29/2016 03:49 PM, Nicolas Goaziou wrote:
>> #+NAME: block-1 #+BEGIN_SRC shell :var x="X" echo ">>>" $x "<<<"
>> #+END_SRC #+BEGIN_SRC shell :var c="test" y=block-1(c) echo $y
>> #+END_SRC #+RESULTS: : >>> $c <<<
Re: [O] Referring to an Org Babel variable in the invocation arguments to another Org Babel code block
On Sun, 1 Jan 2017, Zack Piper wrote: Hi Nicolas, I tried "c", and it gives me: c <<< as the result. I would like it to use the _variable_ "c", not the literal string. So the result should be ">>> test <<<" You mean you want to use the `name' of one `:var name=assign' argument in the `assign' part of another --- something like what `let*' does in lisp. But you simply cannot do that. `(info "(org) var")' tells us what you can do: #+BEGIN_QUOTE The following syntax is used to pass arguments to `src' code blocks using the `:var' header argument. :var name=assign The `assign' is a literal value, such as a string `"string"', a number `9', a reference to a table, a list, a literal example, another code block (with or without arguments), or the results from evaluating a code block. #+END_QUOTE The `name' of one argument is none of these (regardless of its effect when the body of the src block is executed, which BTW depends on the src block language). There are other approaches that might serve a purpose in babel src blocks like that served by `let*' in lisp: - putting variables in a table (possibly invoking `org-sbe' in a formula) and then referencing table cells - writing other src blocks to handle the preliminary processing and referncing them - writing an elisp src block that does those preliminaries (perhaps using `org-babel-ref-resolve' to call other src blocks), then builds a string specifying a call to your shell src block and calls it using `org-babel-ref-resolve'. - using a noweb reference that executes another src block (or blocks). - setting property values and referencing them You might have better luck getting guidance on a useful approach by trying to describe what you want to accomplish. HTH, Chuck
Re: [O] [PATCH] Update ob-ruby for inf-ruby 2.5
Hello, Rick Frankel writes: > inf-ruby (melpa stable) has recently been updated to v2.5. The library has > been significantly re-factored, and `run-ruby` no longer accepts `nil` has > the command name. The following patch updates ob-ruby so that it continues > to work w/ inf-ruby v2.5. It should still (untested) work with the previous > version (2.4). I applied it to maint branch. Thank you. Regards, -- Nicolas Goaziou
Re: [O] speeding up Babel Gnuplot
Babel Gnuplot can be further accelerated. A table is converted to a temporary file readable by Gnuplot. I found two issues in this process: 1. the temporary file is generated twice, 2. the generation is quadratic. I have not provided a committable patch because I am not happy with myfixes. Of course there is no hurry in fixing that because large tables do not happen so often. -- 1. Temporary generated twice Because org-babel-gnuplot-process-vars is called twice. There is no obvious fix. Here is a dirty patch. It caches the name of the temporary file in the 'param' list. #+BEGIN_SRC elisp (defun org-babel-gnuplot-process-vars (params) "Extract variables from PARAMS and process the variables. Dumps all vectors into files and returns an association list of variable names and the related value to be used in the gnuplot code." (let ((*org-babel-gnuplot-missing* (cdr (assq :missing params (mapcar (lambda (pair) (cons (car pair) ;; variable name (let ((val (cdr pair))) ;; variable value (if (not (listp val)) val (let ((temp-file (org-babel-temp-file "gnuplot-")) (first (car val))) (setcdr pair temp-file) ;; <-- caching here (org-babel-gnuplot-table-to-data (if (or (listp first) (symbolp first)) val (mapcar 'list val)) temp-file params)) (org-babel--get-vars params #+END_SRC -- 2. Quadratic behavior The spot is at ox.el::5119(the lambda in org-export-table-row-number). This lambda is called a number of times equal to the square of thesize of the table being plotted. For a 2000 rows table, this is 2000x2000 = four millions times. The cache a few lines before does nothelp because each row is visited only once. I don't know how to fix that. Hereafter is a quick-and-dirty patch to turn the behavior into a linear one (lambda called 2000 timesinstead). The cache is pre-filled upon creation with a single call to org-element-map. So instead of calling org-element-map for each row (forcing it to go through all previous rows over and over), it iscalled only once. #+BEGIN_SRC elisp (defun prefill-cache (table cache info) (let ((number 0)) (org-element-map ;; <--- called once here table 'table-row (lambda (row) (if (eq (org-element-property :type row) 'standard) (progn (puthash row number cache) (cl-incf number info ))) (defun org-export-table-row-number (table-row info) "Return TABLE-ROW number. INFO is a plist used as a communication channel. Return value is zero-based and ignores separators. The function returns nil for special columns and separators." (let* ((cache (or (plist-get info :table-row-number-cache) (let ((table (make-hash-table :test #'eq))) (plist-put info :table-row-number-cache table) (prefill-cache (org-export-get-parent-table table-row) table info) table))) (cached (gethash table-row cache 'no-cache))) (if (not (eq cached 'no-cache)) cached (puthash table-row (and (eq (org-element-property :type table-row) 'standard) (not (org-export-table-row-is-special-p table-row info)) (let ((number 0)) (org-element-map ;; <--- called many times here (org-export-get-parent-table table-row) 'table-row (lambda (row) (cond ((eq row table-row) number) ((eq (org-element-property :type row) 'standard) (cl-incf number) nil))) info 'first-match))) cache #+END_SRC -- 3. Test case First generate a 2000 rows table: #+BEGIN_SRC elisp :results none (goto-char (point-max)) (insert "#+name: data\n") (let ((i 2000)) (while (> i 0) (goto-char (point-max)) (insert (format "| %4s |\n" i)) (setq i (1- i #+END_SRC Then run Babel Gnuplot: #+BEGIN_SRC gnuplot :var data=data :file x.svg :session none :term svg plot data #+END_SRC
[O] org-agenda-filter-effort and "invalid face reference"
Hello, I'm having trouble using org-agenda-filter-by-effort on existing agendas in orgmode 9.0.3 in GNU Emacs 25.1.1 ([x86_64-w64-mingw32] of 2016-09-17). Each time I attempt to use org-agenda-filter-by-effort, I type "_" and then "=" and I select the one-digit index of the effort estimate I want--in my case, I select "3" which corresponds to "0:30". Instead of seeing only those orgmode TODO headings that have an effort property of "0:30" in the agenda buffer as I would expect, all the TODO headings disappear. However, every other type of filter on the agenda buffer seems to work. I can easily filter by category and tag. I have attempted this with my configuration and without any custom configuration at all and always gotten the same result. Although no errors occur (at least none that M-x toggle-debug-on-error pick up) the *Messages* buffer provides some feedback: "Invalid face reference: org-agenda-filter-effort [2 times]". I've tried searching for information about the "invalid face reference" message and orgmode. I've found a few discussions on the orgmode listserv, one of them that occurred recently (November 4, 2016). However, the version of orgmode in this most recent discussion is 8.3 and I'm using orgmode 9.0.3. And it appears that the patch described has already been applied. I also inspected org-agenda.el for the changes and they appear to be there (although I'm not a very experienced elisp programmer or debugger). [O] [PATCH] org-agenda.el Correct :inherit on org-agenda-fontify-priorit https://lists.gnu.org/archive/html/emacs-orgmode/2016-11/msg00057.html [O] `invalid face reference nil` caused by `org-agenda-fontify-propertie https://lists.gnu.org/archive/html/emacs-orgmode/2015-05/msg00116.html [O] Bug: Priority #B in Agenda causes invalid face reference [8.2.1 (8.2 https://lists.gnu.org/archive/html/emacs-orgmode/2013-10/msg00870.html I've attempted to reproduce the problem in Emacs 25.1.1 and orgmode 9.0.3 without any configuration and still experienced the same problem. To reproduce the problem I think you'd only need to create an org file, add an entry with a TODO heading, and then assign an effort estimate that corresponds to the array of allowed values (see description of org-agenda-filter-by-effort http://bit.ly/2iF4o68). After that, you'd need to create an agenda by entering "C-c a" (org-agenda) and "t" (List all TODO entries). I'm at a loss as to what steps to attempt next to troubleshoot this. I've seen an intriguing discussion on Stack Exchange about "font lock studio" but I couldn't get it to work. I'd appreciate any tips you might have on how to proceed. Thanks and Happy New Year to all my fellow org-mode users! Will
Re: [O] speeding up Babel Gnuplot
Hello, Thierry Banel writes: > Babel Gnuplot can be further accelerated. A table is converted to a > temporary file readable by Gnuplot. I found two issues in this process: > 1. the temporary file is generated twice, > 2. the generation is quadratic. > > I have not provided a committable patch because I am not happy with myfixes. > > Of course there is no hurry in fixing that because large tables do not > happen so often. > > -- > > 1. Temporary generated twice > Because org-babel-gnuplot-process-vars is called twice. > > There is no obvious fix. Here is a dirty patch. It caches the name of > the temporary file in the 'param' list. This may not be an issue if `orgtbl-to-generic' is sufficiently fast. > 2. Quadratic behavior > The spot is at ox.el::5119(the lambda in org-export-table-row-number). > > This lambda is called a number of times equal to the square of thesize > of the table being plotted. For a 2000 rows table, this is > 2000x2000 = four millions times. The cache a few lines before does > nothelp because each row is visited only once. Fixed. Thank you. I also optimized a bit more `orgtbl-to-generic'. Hopefully, Babel Gnuplot should be responsive again of large tables. Regards, -- Nicolas Goaziou
