Timeline for Why is org-table-calc-current-TBLFM throwing Wrong type argument: integer-or-marker-p Error?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 23, 2022 at 11:36 | comment | added | duthen | You're right. I was confusing with the french lisp dialect le_lisp, in which interpreted code is quite dynamic and, unless specified, code is compiled lexically and make variables "disappear" (unreachable by "eval", for example). | |
| Sep 19, 2022 at 15:36 | comment | added | db48x | Compiled code has the same semantics as interpreted code, so it wouldn’t change anything. In fact, he was probably using compiled code all along, since Emacs ships with all the elisp files compiled. However, you are correct that this kind of problem is hard to understand. Early programming languages (such as the first Lisp!) were all dynamically scoped, but it took only a few years for lexical scope to be invented and recognized as superior. Virtually all languages designed since then have only had lexical scope. Emacs Lisp is odd because it started with dynamic and implemented lexical later. | |
| Sep 19, 2022 at 10:39 | comment | added | duthen |
Maybe using a compiled version of "org-table.el" would solve the problem, but I think that it's a bug. A function like org-table-calc-current-TBLFM which calls org-table-recalculate which, in some way, calls the emacs-lisp interpreter should protect its internal variables (like formula, s,e, etc.) to avoid this kind of beyond understanding problem!
|
|
| Oct 28, 2016 at 16:27 | vote | accept | Melioratus | ||
| Oct 28, 2016 at 14:55 | history | answered | db48x | CC BY-SA 3.0 |