Bug in sorting headings according to priority

[Zelphir Kaltstahl]

Hello Org-mode users!

I have observed a mini bug over some time now:

When I sort headings in org mode according to their priority (C-c ^ p), 
sometimes the last heading (lowest priority) will not get its own line, but will 
be put in one line with the second last heading, making it no longer a separate 
heading, but part of the second last actual heading.


This behavior depends on how one marks/selects/highlights the headings to be 
sorted. If one highlights the headings from top to bottom, moving the point to 
the next line after the last heading that shall be sorted, then it works without 
merging the last heading and the second last. However, if one does not move the 
point to the next line, then the described behavior occurs.


I have the suspicion, that this is about each heading being defined as 
consisting also of a final newline character and since one does not select that 
as well by moving the point past it, org mode does not consider the last heading 
to be a separate heading, but instead thinks it is part of the second last 
heading. Or perhaps, that it only considers selected text to be sorted, not 
headings that continue after selected text and therefore forgets to include a 
newline for the last heading and if that heading moves around without the 
newline, another heading will be joined on to it on the same line, if any 
heading comes afterwards in the sorted result.


When one highlights from bottom to top (so the other way around!) the same thing 
happens. If one started highlighting on the line below the last heading, then 
the sorting works without merging the last two lines. However, if one starts 
highlighting on the last heading line, then again org mode puts the last heading 
on the line of the second last heading.


Of course this is quite annoying, when one sorts a lot, and one has to always be 
careful how one selects the headings.


Note also, that this only happens, when org mode sorting actually would change 
the order of headings. If the headings are already sorted, then this does not 
happen.


Here is an example document:


* 1
** [#A] 2.1
** [#C] 2.2
** [#B] 2.3


In this document move the cursor:


* 1
** [#A] 2.1
** [#C] 2.2
** [#B] 2.3
   ^
   `--- cursor here


Then select until the start of the first level 2 heading, so that all level 2 
headings are selected.


Then run `org-sort' or press `C-c ^' and then `p'.

The result is:


* 1
** [#A] 2.1
** [#B] 2.3** [#C] 2.2


Instead of:


* 1
** [#A] 2.1
** [#B] 2.3
** [#C] 2.2


This also happens, when I try it in an Emacs started with `emacs -Q'.

In my opinions org-sort should sort without merging headings. It should probably 
consider all text until the end of even a partially selected/highlighted heading 
including the final newline character to avoid this.


 * Emacs version: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
   3.24.37, cairo version 1.16.0)
 * org-mode version: 9.6.7

Please let me know, in case more details are required and how to get them.

Best regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: [PATCH] lisp/ob-scheme.el

[Zelphir Kaltstahl]

On 4/25/23 14:28, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


Subject: [PATCH] org-babel-expand-body:scheme: define header arg vars using
  define

Applied, onto main, adding TINYCHANGE cookie and newline between
variable definitions and body.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d97ba5ba5

You are also now listed as Org contributor, thanks!
https://git.sr.ht/~bzg/worg/commit/eee4cb25


Thank you for taking care of the remaining work!

Best wishes,
Zelphir

--
repositories: https://notabug.org/ZelphirKaltstahl

Re: org mode table alignment issue with CJK characters

[Zelphir Kaltstahl]

On 3/25/23 18:55, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


My settings for org mode regarding fonts/faces are:
...

It may be tricky to get the scaling right sometimes.
I use the following:

;; Credit for the suggestion about `face-font-rescale-alist': @viz:okash.it 
(Matrix)
(push `("Sarasa Mono hc" . ,(/ 16.0 13.0)) face-font-rescale-alist)

An example table I created is aligned perfectly.


Ahhh, thank you! That did it!

I saw some font scaling stuff suggested for other fonts, but thought, that it 
was not necessary for Sarasa.


Just in case I want to use other fonts at some point: How did you (or anyone 
else) derive the 16/13 number? Is there a general way, other than "try numbers 
and see what fits"?


--
repositories: https://notabug.org/ZelphirKaltstahl

Re: [PATCH] lisp/ob-scheme.el

[Zelphir Kaltstahl]

Not sure it meets all formalities. For example it is not clear to me, whether I
should add the "TINYCHANGE" at the bottom of my commit message.

You should, unless you have FSF copyright assignment.
I am not sure what "have FSF copyright assignment" means. I would not mind 
assigning copyright of that patch to FSF, but probably the paperwork would be 
way overblown for such a small change. I will simply add the "TINYCHANGE" then.

--
repositories:https://notabug.org/ZelphirKaltstahl
 From 51b299aa18e882681dd681acb51c9cb1b44f3b4e Mon Sep 17 00:00:00 2001
From: Zelphir Kaltstahl
Date: Sat, 18 Mar 2023 16:06:05 +0100
Subject: [PATCH] lisp/ob-scheme.el:

Please provide a short commit summary, not just the changed file.
See how we do it inhttps://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/

Oh, I thought I had one. Not sure how I lost my commit message title. o.o

This is the kind of stuff, that causes me to procrastinate so much. I know it is 
not your fault and I know there need to be some format regulations in place to 
have a good manageable cooperation when working on a community project. I just 
want to explain, why I am so slow in following up and initially sending the 
patch ; ) Not blaming anyone!



Wrapping binding definitions using `let' can lead to issues with GNU
Guile and potentially other Scheme dialects. GNU Guile will only get
to the body of the let at evaluation time, not at macro expansion
time. If the let form wraps any imports of libraries that define
macros, then those imported macros are seen too late and their
corresponding forms inside the body of the let are not
expanded. Using `define' to define bindings avoids this problem, at
least in GNU Guile.

Please use double space between sentences. Also, it would be helpful to
provide a link to this thread for more context. (The aim of commit
message is a note for future contributors on the reason the change was
made).

Right! I forgot about that one while writing : ) Will do!

+(defun org-babel-expand-header-arg-vars:scheme (vars)

Please use org-babel-scheme-... function name. It is the usual
Elisp convention to prefix the functions as
library-name-inner-function-name.

The exception in org-babel is a set of special functions that must have
certain name pattern. Expanding header args is not one of those special
functions.
Ah, I was not aware of that. Took all naming inspiration from the 
org-babel-expand-body:scheme function name and thought my separate function 
ought to have :scheme suffix : ) Will fix!

+  "Expand :var header arguments given as VARS."
+  (mapconcat
+   (lambda (var)
+ (format "(define %s %S)" (car var) (cdr var)))

Is there any reason why you use %s for variable name? Previously it was
formatted with escapes (using %S).


That was me thinking: "The name of the variable should just be itself, not 
wrapped in double quotes, because in Scheme I cannot create a variable as 
(define "abc" 123)". But maybe I misunderstood %s and %S. I also do not know, 
how elisp's `print' treats its arguments. Will use 2 times %S then.


Or do you mean, that I should be using `print'? I thought using only `format' is 
simpler, so I did not bother with `print' and then `format'. If I choose the 
correct format modifiers, `print' should be unnecessary, right? Or does `print' 
do some magic behind the scenes, that is not expressable using merely format 
modifiers?



Also, previous version quoted the variable value with "'". Why didn't
you do it here?


I am not sure I understand what you are referring to in the previous version. Do 
you mean that `print' quoted variable values with a single quote? Do you mean 
this part of the previous code:


(print `(,(car var) ',(cdr var)))

?


+ (concat (org-babel-expand-header-arg-vars:scheme vars) body))

`mapconcat' you used in `org-babel-expand-header-arg-vars:scheme' does
not add trailing newline, unlike done previously.


Am I not adding a newline? I think I do?:


...

(mapconcat
   (lambda (var)
 (format "(define %S %S)" (car var) (cdr var)))
   vars
   "\n")

...


Is anything else required? Maybe 2 newlines instead? The previous version had a 
number of spaces as well, but since `define' is not creating additional indent 
like `let' should, I leave those away.


Thank you for the feedback!

I have a question or suggestion:

When I save the file in Emacs, my Emacs turns all the tabs in there into spaces. 
Probably my own custom global config's choice about indentation. Could a general 
mode line thing be added to avoid that and nail down the current formatting 
style, so that contributors only need to allow Emacs to run those settings and 
then not need to care about it? Currently the indentation style seems to be a 
mix of tabs and spaces.


(For example the GNU Guix project does a lot of formatting things in their 
files, that configure Emacs, so that the form

Re: org mode table alignment issue with CJK characters

[Zelphir Kaltstahl]

On 3/23/23 15:44, Zelphir Kaltstahl wrote:


Hello org mode users!

I recently looked into getting org mode tables to properly align cell borders 
and table border, when using Chinese characters in them.


I found out, that there is valign mode [1] and was happy with it for a few 
days. But then I opened a document with lots of tables and some of those 
tables bigger than what I had before in other documents. Scrolling inside that 
document became quite laggy. So teeth-gnashingly I deactivated valign mode, 
already suspecting it to be the culprit. And I was right. After deactivating 
it, I could scroll perfectly fine again.


So I returned to the second alternative I had found out about, when searching 
for a solution: Finding a font, which renders Chinese characters at exactly 
double the width of latin/ASCII characters. I found a font named "Sarasa" [2] 
and experimented a bit with setting the font globally, then setting it only 
when opening an org mode buffer. Now it looks like that font does character 
widths almost correctly (see attached screenshot, see slightly wider 4 ASCII 
characters than 2 Chinese characters).


My settings for org mode regarding fonts/faces are:


(add-hook 'org-mode-hook
   (function
(lambda ()
  ;; Only do the following in graphical mode, as it will
  ;; break when using emacs in terminal mode.
  (when (display-graphic-p)
;; Sarasa font is fromhttps://github.com/be5invis/Sarasa-Gothic.
(setq buffer-face-mode-face
  '(:family "Sarasa Mono CL"
:weight normal
:height 110))
(buffer-face-mode)


However, it seems, that now org mode does not align tables correctly, even 
though an ASCII character is half the width of a Chinese character in the 
tables. Org mode seems to add too few or too many spaces, which are displayed 
as spaces of various width.—Is that because of the 1 pixel width difference?


Do I need to look for another font, which does things truly exactly, no 1 
pixel too wide funny business? Maybe someone knows a more exact font?


Ultimately: How can I make tables align correctly?

My Emacs version is: GNU Emacs 28.2

My org mode version is: 9.6.1

[1]: https://github.com/casouri/valign

[2]: https://github.com/be5invis/Sarasa-Gothic


I have tried something else today:

I looked at how the font is rendered in Libre Office. There it seems, that the 
characters align perfectly (see attached screenshot). So maybe this is an Emacs 
in general issue of font rendering, which adds a pixel to ASCII characters or 
takes one away from CJK characters?


--
repositories:https://notabug.org/ZelphirKaltstahl

org mode table alignment issue with CJK characters

[Zelphir Kaltstahl]

Hello org mode users!

I recently looked into getting org mode tables to properly align cell borders 
and table border, when using Chinese characters in them.


I found out, that there is valign mode [1] and was happy with it for a few days. 
But then I opened a document with lots of tables and some of those tables bigger 
than what I had before in other documents. Scrolling inside that document became 
quite laggy. So teeth-gnashingly I deactivated valign mode, already suspecting 
it to be the culprit. And I was right. After deactivating it, I could scroll 
perfectly fine again.


So I returned to the second alternative I had found out about, when searching 
for a solution: Finding a font, which renders Chinese characters at exactly 
double the width of latin/ASCII characters. I found a font named "Sarasa" [2] 
and experimented a bit with setting the font globally, then setting it only when 
opening an org mode buffer. Now it looks like that font does character widths 
almost correctly (see attached screenshot, see slightly wider 4 ASCII characters 
than 2 Chinese characters).


My settings for org mode regarding fonts/faces are:


(add-hook 'org-mode-hook
  (function
   (lambda ()
 ;; Only do the following in graphical mode, as it will
 ;; break when using emacs in terminal mode.
 (when (display-graphic-p)
   ;; Sarasa font is fromhttps://github.com/be5invis/Sarasa-Gothic.
   (setq buffer-face-mode-face
 '(:family "Sarasa Mono CL"
   :weight normal
   :height 110))
   (buffer-face-mode)


However, it seems, that now org mode does not align tables correctly, even 
though an ASCII character is half the width of a Chinese character in the 
tables. Org mode seems to add too few or too many spaces, which are displayed as 
spaces of various width.—Is that because of the 1 pixel width difference?


Do I need to look for another font, which does things truly exactly, no 1 pixel 
too wide funny business? Maybe someone knows a more exact font?


Ultimately: How can I make tables align correctly?

My Emacs version is: GNU Emacs 28.2

My org mode version is: 9.6.1

[1]: https://github.com/casouri/valign

[2]: https://github.com/be5invis/Sarasa-Gothic

--
repositories:https://notabug.org/ZelphirKaltstahl

[PATCH] lisp/ob-scheme.el

[Zelphir Kaltstahl]

On 3/11/23 10:58, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


The issue is not with defining via (define ...) inside a (let ...) in Guile. It
is about importing macros at the time, when the body of the (let ...) is already
evaluated, which is at a later phase than macro expansion. By wrapping inside a
(let ...) org has moved the import to a later phase, which causes the macro
(let-values ...) to not be expanded.

I see.
AFAIK, Elisp does not have this problem.


As far as I know, (defun ...) and (defvar ...) are merely defining functions and
variables, not macros.

Same for defmacro in Elisp.


My point is, that imports are usually global for sessions. But :var decided for
let-wrapping, moving them to a different place. Just like imports are usually
global, I would expect (define ...)s to be global in the session, unless I put
them inside a narrowed scope like a (let ...) myself. The org generated (let
...) is invisible to the user and thus confusing, at least for GNU Guile.

For other Schemes it probably all depends on how their phases of expansion and
evaluation work. I don't know enough about the Scheme standards, to tell,
whether Guile has the correct behavior here or whether there is a correct
behavior defined in the Scheme standards. Maybe someone more knowledgeable can
chime in to comment on that.

When saying Guile I mean scheme. Remember that I am now looking from a
more general perspective of other ob-* libraries.

My conclusion so far is that it is not safe in ob-scheme to use
let-binding. Other ob-* lisp implementations may be OK (at least,
ob-emacs-lisp is OK).

Now, the main question is whether it is safe to use `define' in all the
scheme implementations. If it is, would you be interested in turning
your personal fix into a patch for ob-scheme?


Hi!

I've created a patch, which I will attach to this e-mail.

Not sure it meets all formalities. For example it is not clear to me, whether I 
should add the "TINYCHANGE" at the bottom of my commit message.


Still need to get around to test at least some other Scheme as well, but I guess 
I should get started with the patch, otherwise I will procrastinate or be stuck 
in fear of formalities forever.


Let me know, if this an OK patch or what else needs to be done or what format is 
wrong, if any.


--
repositories: https://notabug.org/ZelphirKaltstahl
From 51b299aa18e882681dd681acb51c9cb1b44f3b4e Mon Sep 17 00:00:00 2001
From: Zelphir Kaltstahl 
Date: Sat, 18 Mar 2023 16:06:05 +0100
Subject: [PATCH] lisp/ob-scheme.el:

* ob-scheme.el (org-babel-expand-body:scheme,
org-babel-expand-header-arg-vars:scheme): Change the way header
argument :var variables are expanded for for Scheme source blocks.  Use
`define' instead of wrapping using `let'.

Wrapping binding definitions using `let' can lead to issues with GNU
Guile and potentially other Scheme dialects. GNU Guile will only get
to the body of the let at evaluation time, not at macro expansion
time. If the let form wraps any imports of libraries that define
macros, then those imported macros are seen too late and their
corresponding forms inside the body of the let are not
expanded. Using `define' to define bindings avoids this problem, at
least in GNU Guile.
---
 lisp/ob-scheme.el | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el
index 9f12f42cb..f837dedd2 100644
--- a/lisp/ob-scheme.el
+++ b/lisp/ob-scheme.el
@@ -79,6 +79,14 @@
 (defvar org-babel-default-header-args:scheme '()
   "Default header arguments for scheme code blocks.")
 
+(defun org-babel-expand-header-arg-vars:scheme (vars)
+  "Expand :var header arguments given as VARS."
+  (mapconcat
+   (lambda (var)
+ (format "(define %s %S)" (car var) (cdr var)))
+   vars
+   "\n"))
+
 (defun org-babel-expand-body:scheme (body params)
   "Expand BODY according to PARAMS, return the expanded body."
   (let ((vars (org-babel--get-vars params))
@@ -86,16 +94,9 @@
 	(postpends (cdr (assq :epilogue params
 (concat (and prepends (concat prepends "\n"))
 	(if (null vars) body
-	  (format "(let (%s)\n%s\n)"
-		  (mapconcat
-		   (lambda (var)
-			 (format "%S" (print `(,(car var) ',(cdr var)
-		   vars
-		   "\n  ")
-		  body))
+	  (concat (org-babel-expand-header-arg-vars:scheme vars) body))
 	(and postpends (concat "\n" postpends)
 
-
 (defvar org-babel-scheme-repl-map (make-hash-table :test #'equal)
   "Map of scheme sessions to session names.")
 
-- 
2.25.1

Re: [BUG] Inconsistent global/local :var assignments in ob-* for lisps and non-lisps (was: org-babel guile source block bug in handling multiple values)

[Zelphir Kaltstahl]

On 3/11/23 10:58, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


The issue is not with defining via (define ...) inside a (let ...) in Guile. It
is about importing macros at the time, when the body of the (let ...) is already
evaluated, which is at a later phase than macro expansion. By wrapping inside a
(let ...) org has moved the import to a later phase, which causes the macro
(let-values ...) to not be expanded.

I see.
AFAIK, Elisp does not have this problem.


As far as I know, (defun ...) and (defvar ...) are merely defining functions and
variables, not macros.

Same for defmacro in Elisp.


My point is, that imports are usually global for sessions. But :var decided for
let-wrapping, moving them to a different place. Just like imports are usually
global, I would expect (define ...)s to be global in the session, unless I put
them inside a narrowed scope like a (let ...) myself. The org generated (let
...) is invisible to the user and thus confusing, at least for GNU Guile.

For other Schemes it probably all depends on how their phases of expansion and
evaluation work. I don't know enough about the Scheme standards, to tell,
whether Guile has the correct behavior here or whether there is a correct
behavior defined in the Scheme standards. Maybe someone more knowledgeable can
chime in to comment on that.

When saying Guile I mean scheme. Remember that I am now looking from a
more general perspective of other ob-* libraries.

My conclusion so far is that it is not safe in ob-scheme to use
let-binding. Other ob-* lisp implementations may be OK (at least,
ob-emacs-lisp is OK).

Now, the main question is whether it is safe to use `define' in all the
scheme implementations. If it is, would you be interested in turning
your personal fix into a patch for ob-scheme?


Sure! Would need to familiarize myself with with process of doing that, but why 
not.

I guess it would be a safer bet to await, whether the patch is what the general 
solution should be. Or would a patch be good to have, regardless of whether the 
official implementation changes or not, so that others can apply it perhaps, 
instead of putting something in their personal init file?


--
repositories: https://notabug.org/ZelphirKaltstahl

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/9/23 14:11, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


OK, to wrap up (ha!), I want to ask:

(q1) What is a rationale, if any, behind the let-wrapping?

It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel, the maintainer of ob-clojure (we have no active
maintainer for ob-scheme now). Maybe, Daniel has some useful insight.


(q2) Any chances of that changing to (define ...)?

This sounds reasonable.


(q3) How could I change my org-mode's code to not  let-wrap, and instead use
(define ...)?

See `org-babel-expand-body:scheme'. You can re-define it for a quick
temporary fix.


Thanks for the hint!

Here is my fix for my init.el:

START
;; Redefine/override org-babel-expand-body:scheme to avoid
;; let-wrapping with :var header args in source blocks.

(defun xiaolong/org-babel-format-vars (vars)
  "Format :var header arguments given as VARS."
  (mapconcat (lambda (var)
   (format "(define %s %S)" (car var) (cdr var)))
 vars
 "\n"))

(eval-after-load "org"
  '(defun org-babel-expand-body:scheme (body params)
 "Expand BODY according to PARAMS, return the expanded body."
 (let ((vars (org-babel--get-vars params))
   (prepends (cdr (assq :prologue params)))
   (postpends (cdr (assq :epilogue params
   (concat (and prepends (concat prepends "\n"))
   (if (null vars)
   body
 (concat (xiaolong/org-babel-format-vars vars) body))
   (and postpends (concat "\n" postpends))
~END~

That was simpler than I expected and the first time I overrode anything of 
org-mode =)


Regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/9/23 14:10, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


START
#+name: python-imports
#+begin_src python :python /usr/bin/python3 :results output replace drawer :var 
x=4
import math

y = math.sqrt(x)
# print(y)
#+end_src

#+name: python-usage
#+begin_src python :python /usr/bin/python3 :return :noweb strip-export 
:results value replace drawer
<>

print("y: {}".format(y))
#+end_src
~END~

Unfortunately, this example does not seem to work at all, but for a different
reason:

It seems that using any Python source block with :var header args via :noweb
does not work, as it then behaves in the way, that it merely pasted the included
source block, without first putting in the :var values into the variables. I get
errors about those :var variables being undefined, of course, since they are on
the included source block, not on the including one:

START: *Org-Babel Error Output*
Traceback (most recent call last):
File "", line 10, in 
File "", line 5, in main
NameError: name 'x' is not defined
[ Babel evaluation exited with code 1 ]
~END~

This is expected. Noweb includes the src block code without altering it.
See 16.11 Noweb Reference Syntax

We may probably clarify this in the manual. Would it be helpful?
I think it would be helpful. I merely tried Python, because it was at hand and 
because I did not find ob-racket in M-x package-list RET and did not have 
another Scheme installed. Cannot say, whether others find the behavior confusing 
or not, but I imagine I would find it helpful, if it was mentioned in the docs.


--
repositories: https://notabug.org/ZelphirKaltstahl

Re: [BUG] Inconsistent global/local :var assignments in ob-* for lisps and non-lisps (was: org-babel guile source block bug in handling multiple values)

[Zelphir Kaltstahl]

On 3/9/23 14:04, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


I am not sure (let ...) is a correct wrapper for noweb included source blocks.
What, if I write a (define ...) in my source block and want to use that source
block via noweb in another source block? Expected behavior I think would be to
be able to access those variables in other source blocks, since they are defined
on a top level in an earlier source block, but if they are wrapped in a (let
...), that would make them only available in the (let ...)? It seems to me, that
the simple wrapping with a (let ...) might not be the right thing to do. Testing
that:

START
#+name: scheme-defs
#+begin_src scheme :eval query-export :noweb strip-export :session myguile 
:results output replace drawer :var x=1 :var y=2
(define a x)
(define b y)
#+end_src

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session myguile 
:results output replace drawer
<>
(simple-format #t "~a ~a\n" a b)
#+end_src
~END~

Indeed, that also does not work.

I just checked ob-C, ob-shell, ob-emacs-lisp, and ob-clojure.
Non-lisps appear to assign the values globally.
In contrast, all the lisp babel backends are using let-bindings.

Considering the existing inconsistency, and the raised bug I'd be in
favor of making variable assignments global in all the lisp babel
backends.

The only possible exception is ob-emacs-lisp. Executing elisp code is
done in current Elisp session and thus using global variable assignments
may be tricky. Unless we juggle with multiple obarrays.


I guess I did never hit this problem earlier, because I "oursourced" my imports
and in imports I do not need any :var header arguments.

I've asked on the Guile IRC channel and something interesting is the case here
(thanks for clearing it up flatwhatson!) and I understand it as follows:

Imports inside (let ...) work. It is just that let-values is a macro and macros
are expanded before execution time. However, Guile gets to the body of the
wrapping (let ...) at execution time. That means, that when Guile gets to
evaluate the body of the let, it does not expand the let-values, because it is
already at execution time and no longer at macro expansion time. The import
might import the let-values form, or might not, but it is already too late to
expand the (let-values ...).

So, apparently using `let' is not universally safe in Guile.
Is it safe in any Scheme? I think that depends on expansion and evaluation 
phases of the Scheme standards (see below).

OK, the question is though, whether org should wrap anything in a (let ...) at
all. During discussion on the Guile IRC, some points against let-wrapping were
brought up:

(1) The presence of a :var header argument currently determines, whether the
code in the source block is wrapped with a (let ...). One argument for that was,
that this way the variables do not leak. But this also decides, whether other
things leak. For example (import ...) or (define ...). Should :var decide,
whether bindings created with (define ...) are visible in other source blocks
including the source block with the :var header arguments? It seems like a
responsibility :var should not have and definitely is unexpected for the user.

This is something Guile-specific. In Elisp, let-binding still allows
`defun' or `defvar'.


The issue is not with defining via (define ...) inside a (let ...) in Guile. It 
is about importing macros at the time, when the body of the (let ...) is already 
evaluated, which is at a later phase than macro expansion. By wrapping inside a 
(let ...) org has moved the import to a later phase, which causes the macro 
(let-values ...) to not be expanded.


As far as I know, (defun ...) and (defvar ...) are merely defining functions and 
variables, not macros.


My point is, that imports are usually global for sessions. But :var decided for 
let-wrapping, moving them to a different place. Just like imports are usually 
global, I would expect (define ...)s to be global in the session, unless I put 
them inside a narrowed scope like a (let ...) myself. The org generated (let 
...) is invisible to the user and thus confusing, at least for GNU Guile.


For other Schemes it probably all depends on how their phases of expansion and 
evaluation work. I don't know enough about the Scheme standards, to tell, 
whether Guile has the correct behavior here or whether there is a correct 
behavior defined in the Scheme standards. Maybe someone more knowledgeable can 
chime in to comment on that.


--
repositories: https://notabug.org/ZelphirKaltstahl

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/8/23 20:38, Bruno Barbier wrote:

Hi Zelphir,

Zelphir Kaltstahl  writes:


On 3/7/23 20:52, Bruno Barbier wrote:
Also thanks for the idea with sessions + separate import source block. I thought
that should work, but apparently that also has the same error, when running for
the first time:

...

Oh, I see. I tested something way simpler :-)

First, one block to open and configure the guile session.

  #+begin_src scheme :session "!guile" :results silent
  (import (except (rnrs base) error vector-map)
   (only (guile)
 lambda*
 λ)
   ;; let-values
   (srfi srfi-11))
  #+end_src

Then, you can get to work and evaluate as many blocks as you like in
that session:

  #+begin_src scheme :session "!guile" :results output replace drawer :var 
x=1 :var y=2
  (let-values ([(a b) (values x y)])
 (simple-format #t "~a ~a\n" a b))
  #+end_src

  #+RESULTS:
  :results:
  1 2
  :end:

Bruno

Hello Bruno and hello mailing list!

I just tested it a little more:

If there is any (import ...) at all in the code block that makes use of the 
(let-values ...), it seems to somehow disturb already imported libraries. For 
example the following also does not work:


START
#+name: scheme-time-imports
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer"
(import
 (except (rnrs base) error vector-map)
 (only (guile)
   lambda*
   λ)
 ;; let-values
 (srfi srfi-11))
#+end_src

#+RESULTS: scheme-time-imports

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer :var x=1 :var y=2
<>
(import (srfi srfi-1))
(let-values ([(a b) (values x y)])
   (simple-format #t "~a ~a\n" a b))
#+end_src
~END~

So that means, even if the import has nothing to do with the actual import which 
would provide the let-values form, it disturbs it.


I am not sure (let ...) is a correct wrapper for noweb included source blocks. 
What, if I write a (define ...) in my source block and want to use that source 
block via noweb in another source block? Expected behavior I think would be to 
be able to access those variables in other source blocks, since they are defined 
on a top level in an earlier source block, but if they are wrapped in a (let 
...), that would make them only available in the (let ...)? It seems to me, that 
the simple wrapping with a (let ...) might not be the right thing to do. Testing 
that:


START
#+name: scheme-defs
#+begin_src scheme :eval query-export :noweb strip-export :session myguile 
:results output replace drawer :var x=1 :var y=2
(define a x)
(define b y)
#+end_src

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session myguile 
:results output replace drawer
<>
(simple-format #t "~a ~a\n" a b)
#+end_src
~END~

Indeed, that also does not work.

I guess I did never hit this problem earlier, because I "oursourced" my imports 
and in imports I do not need any :var header arguments.


I've asked on the Guile IRC channel and something interesting is the case here 
(thanks for clearing it up flatwhatson!) and I understand it as follows:


Imports inside (let ...) work. It is just that let-values is a macro and macros 
are expanded before execution time. However, Guile gets to the body of the 
wrapping (let ...) at execution time. That means, that when Guile gets to 
evaluate the body of the let, it does not expand the let-values, because it is 
already at execution time and no longer at macro expansion time. The import 
might import the let-values form, or might not, but it is already too late to 
expand the (let-values ...).


What is still a bit weird about it is, that in the original example with 
`let-values` I don't get an error about `let-values` not being defined, but only 
about `a` not being defined. And in the example with (define ...) and :var 
above, I get a message about `x` not being defined, instead of `a` not being 
defined.


Probably a good general workaround is to only have imports at the top level, by 
moving them into a source block, which does not have any :var header arguments.


OK, the question is though, whether org should wrap anything in a (let ...) at 
all. During discussion on the Guile IRC, some points against let-wrapping were 
brought up:


(1) The presence of a :var header argument currently determines, whether the 
code in the source block is wrapped with a (let ...). One argument for that was, 
that this way the variables do not leak. But this also decides, whether other 
things leak. For example (import ...) or (define ...). Should :var decide, 
whether bindings created with (define ...) are visible in other source blocks 
including the source block with the :var header arguments? It s

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/7/23 20:52, Bruno Barbier wrote:

Zelphir Kaltstahl  writes:



If org merely wraps in a `let`, it should not notice any of the multiple values
business, because that is something done internally in `let-values`.


The "let", to define the org variables, ends up putting the "import"
inside the scheme expression, like this:

   ;; -*- geiser-scheme-implementation: guile -*-
   (let ((x '1)
 (y '2))
   (import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

   (let-values ([(a b) (values x y)])
  (simple-format #t "~a ~a\n" a b))
   )


which raises an error when evaluated the first time (the second time,
the "import" has already imported the new "let-values" feature
(srfi-11), so, the evaluation works). You can test this manually in a
guile session.

I guess you'll have to use sessions, and do the "import" in a separate
block first.

Bruno


Actually, now that I think about it, the whole problem is gone, when replacing 
the wrapping let with 2 separate (define ...), which I originally thought org 
would do:


START
$ guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define x 1)
scheme@(guile-user)> (define y 2)
scheme@(guile-user)> (import (except (rnrs base) error vector-map)
... (only (guile)
...   lambda*
...   λ)
... ;; let-values
... (srfi srfi-11))
scheme@(guile-user)> (let-values ([(a b) (values x y)])
...   (simple-format #t "~a ~a\n" a b))
1 2
~END~

Or in one input to the REPL:

START
$ guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define x 1)
scheme@(guile-user)> (define y 2)
scheme@(guile-user)> (import (except (rnrs base) error vector-map)
... (only (guile)
...   lambda*
...   λ)
... ;; let-values
... (srfi srfi-11))
scheme@(guile-user)> (let-values ([(a b) (values x y)])
...   (simple-format #t "~a ~a\n" a b))
1 2
~END~

Is there a reason it has to be wrapped in a let, instead of simply define-ing 
the variables?


Regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/7/23 20:52, Bruno Barbier wrote:

Zelphir Kaltstahl  writes:



If org merely wraps in a `let`, it should not notice any of the multiple values
business, because that is something done internally in `let-values`.


The "let", to define the org variables, ends up putting the "import"
inside the scheme expression, like this:

   ;; -*- geiser-scheme-implementation: guile -*-
   (let ((x '1)
 (y '2))
   (import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

   (let-values ([(a b) (values x y)])
  (simple-format #t "~a ~a\n" a b))
   )


which raises an error when evaluated the first time (the second time,
the "import" has already imported the new "let-values" feature
(srfi-11), so, the evaluation works). You can test this manually in a
guile session.

I guess you'll have to use sessions, and do the "import" in a separate
block first.

Bruno


Hello Bruno!

Thank you for that explanation. Behaves exactly like you describe and explains 
things.


I wonder though, whether that let wrapped code should actually cause an error, 
or that is a bug in Guile.


Also thanks for the idea with sessions + separate import source block. I thought 
that should work, but apparently that also has the same error, when running for 
the first time:


START
#+name: scheme-time-imports
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer"
(import
 ;; let-values
 (srfi srfi-11))
#+end_src

#+RESULTS: scheme-time-imports

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer :var x=1 :var y=2
<>
(import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

(let-values ([(a b) (values x y)])
  (simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS: scheme-time
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:
~END~

Regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/7/23 15:36, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


* Multiple values involving =:var= variables

#+begin_src scheme :eval query-export :results output replace drawer :var x=1 
:var y=2
(import (except (rnrs base) error vector-map)
  (only (guile)
lambda*
λ)
  ;; let-values
  (srfi srfi-11))

(let-values ([(a b) (values x y)])
(simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS:
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:

I am not familiar with scheme, but AFAIK all ob-scheme does is wrapping
the code block into (let (...) ,@body) See `org-babel-expand-body:scheme'.

May the problem be with your let-values form?


The problem seems to be associated with returning multiple values, which 
`let-values` is designed to capture. The expression `(values ...)` returns 2 
values and the `(let ([(a b) ]) )` will capture 
those 2 values, binding them to `a` and `b`. The `(let-values ...)` then creates 
a value (or in other scenarios any number of values) in its `` part as a 
result of the whole `let-values` expression. In my case the body performs a 
side-effect of printing something out, which is required to get something as an 
output of the source block.


If org merely wraps in a `let`, it should not notice any of the multiple values 
business, because that is something done internally in `let-values`.


I can run the code in geiser manually without error, but when I run it as a 
source block, I get the error as seen in the example org document of my original 
e-mail.


--
repositories: https://notabug.org/ZelphirKaltstahl

org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

Hello Org users!

I think I found a bug in how org-babel works with at least GNU Guile source 
blocks. I could not reproduce this for example with a racket source block, 
because somehow there is no ob-racket and I think I would need that. I could try 
other Schemes like maybe Chicken, if there is ob-chicken or so available. The 
issue happens on 2 separate machines.


I am not sure on which repository I should open an issue for this specific bug, 
or if perhaps this mailing list is exactly the right place. Feel free to point 
me elsewhere : )


What follows are my notes trying to narrow it down, as an org document.

START
* General

There seems to be an issue with returning multiple values, which result from 
=:var= variables / whose computation involves =:var= variables. Handling 
multiple trivial values like ~1~ or ~2~ seems to work fine.

* Primitive multiple values work

#+begin_src scheme :eval query-export :results output replace drawer
(import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

(let-values ([(a b) (values 1 2)])
  (simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS:
:results:
1 2
:end:

* Multiple values involving =:var= variables

#+begin_src scheme :eval query-export :results output replace drawer :var x=1 
:var y=2
(import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

(let-values ([(a b) (values x y)])
  (simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS:
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:

** Is it about =:var= variables in values?

#+begin_src scheme :eval query-export :results output replace drawer :var x=1 
:var y=2
(import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

(define plus-x
  (λ (num)
(+ num x)))

(define plus-y
  (λ (num)
(+ num y)))

(let-values ([(a b) (values (plus-x 1) (plus-y 2))])
  (simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS:
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:

** Defining and using defined variables

What about defining and using the defined variables instead of the =:var= 
variables directly?

#+begin_src scheme :eval query-export :results output replace drawer :var x=1 
:var y=2
(import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

(define inner-x x)
(define inner-y y)

(define plus-x
  (λ (num)
(+ num inner-x)))

(define plus-y
  (λ (num)
(+ num inner-y)))

(let-values ([(a b) (values (plus-x 1) (plus-y 2))])
  (simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS:
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:

It seems not to work whenever the ~(values ...)~ is not only trivial values, 
but variables or function calls.

* With named :session

Works after running it once with error:

#+begin_src scheme :session mysession :eval query-export :results output 
replace drawer :var x=1 :var y=2
(import (except (rnrs base) error vector-map)
(only (guile)
  lambda*
  λ)
;; let-values
(srfi srfi-11))

(let-values ([(a b) (values x y)])
  (simple-format #t "~a ~a\n" a b))
#+end_src

#+RESULTS:
:results:
1 2
:end:

Seems like it gets stored in the session and then can be used in the second run 
of the source block.
~END~

Versions of things:

+ guile @ =3.0.9=
+ org-mode @ =9.6.1=
+ org-babel @ (integrated into org-mode)
+ geiser-guile @ =0.28.1=

Workarounds:

Of course, I could return lists instead of multiple values and then pattern 
match on them or use separate functions for getting the values separately. 
Downside: Might be more computation and requires changing code just, because for 
using it in org source blocks.


--
repositories:https://notabug.org/ZelphirKaltstahl

Re: Problem with org-babel and geiser

[Zelphir Kaltstahl]

Hello Rudy!

On 3/22/22 21:51, Rudolf Adamkovič wrote:

Zelphir Kaltstahl  writes:

Hello Zelphir!


At some point something changed, I think, […]

In Geiser or in Org?  I use Geiser for work heavily and it works like
magic.  I ask because if the problem resides in Geiser, we could report
a new bug there.

Rudy


Geiser seems to work, if I use /bin/sh with some arguments instead of GNU Bash. 
I am not sure what is going on with that though, because I did not have to do 
that in the past. In org-mode it still does not work. I will have to get into 
the topic again at some point, as I am unsatisfied without having GNU Guile 
source blocks in Org-mode working.

I've successfully used those before in multiple personal or learning projects 
(like 
inhttps://notabug.org/ZelphirKaltstahl/the-little-schemer/src/master/chapter-09-y-combinator/code.org).
 I spent so much time on fixing this problem, that I neglected my actual 
project that I wanted to continue. After 2 or 3 weekends, I left the issue at 
the status in that gitlab issue. I completely blended that one out for now and 
continued by copy pasting into Geiser REPL or using C-c C-r to run regions of 
code. That works at least. But it is less satisfying than doing literate 
programming in org-mode.

If anyone has concrete steps to run, to figure out the problem, I might find the energy to get into the 
matter again. For now I have put it up to "later" / "in the future" / "when some 
update comes" or something like that.

Best regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: Re: Problem with org-babel and geiser

[Zelphir Kaltstahl]

Hello Rudy!

On 3/18/22 17:00, emacs-orgmode-requ...@gnu.org wrote:

Today, I needed to use Scheme with Org (9.5.2-24-g668205), and I found
that the #+RESULTS: always come back empty.  Oh, well!  I use Guile and
have everything configured correctly.  Has anyone merged the patch
discussed in this thread into Org?

Thank you.

Rudy


I've had lots of problems with getting it to work as well and have not solved 
all of them. At some point something changed, I think, which made my setup not 
work correctly any longer. You might be interested in the following issue on gitlab:


https://gitlab.com/emacs-geiser/guile/-/issues/13

I've not followed up further yet.

Best regards,
Zelphir

--
repositories: https://notabug.org/ZelphirKaltstahl

Re: Library of Babel usage of other programming languages than elisp

[Zelphir Kaltstahl]

Hello Arne!

Thanks for that.

Do you happen to have an example, in which you are passing arguments to a 
procedure?

Regards,
Zelphir

On 8/10/21 7:49 AM, Dr. Arne Babenhauserheide wrote:
> Zelphir Kaltstahl  writes:
>
>> I have repeatedly tried to use another programming language than elisp for
>> writing source blocks in org-mode, which I intended to use as functions 
>> inside
>> org-mode spreadsheets. So far without success.
> I’m using scheme in org-mode during export (though not it tables) and
> that works.
>
> call: 
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=ccc9148e78a4#L27
>
> begin_src: 
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=ccc9148e78a4#L137
>
> #+call: generate-char-jetzt()
>
> #+name: generate-char-jetzt
> #+begin_src scheme :exports none :results output raw :prologue "(import (srfi 
> srfi-1)(ice-9 match)(ice-9 receive))(set! *random-state*  
> (random-state-from-platform))\n" :tangle chargen.scm :noweb yes :var 
> kernantriebe=tabelle-grundantriebe :var hautfarbe=tabelle-hautfarbe :var 
> haarfarbe=tabelle-haarfarbe :var augenfarbe=tabelle-augenfarbe :var 
> darstellung1=tabelle-darstellung1 :var darstellung2=tabelle-darstellung2 :var 
> kleidung_oben_maenner=tabelle-kleidung-jetzt-oben-maenner  :var 
> kleidung_unten_maenner=tabelle-kleidung-jetzt-unten-maenner :var 
> kleidung_oben_frauen=tabelle-kleidung-jetzt-oben-frauen  :var 
> kleidung_unten_frauen=tabelle-kleidung-jetzt-unten-frauen :var 
> kleidung_oben_frauen=tabelle-kleidung-jetzt-oben-frauen  :var 
> kleidung_unten_frauen=tabelle-kleidung-jetzt-unten-frauen :var 
> namen=tabelle-namen-fantasy-jetzt :var sex=tabelle-sexualitaet :var 
> stichwort=tabelle-stichwort-jetztzeit
>   (let ()
> {{{chargen-setup}}}
> {{{chargen-generic}}}
> {{{chargen-colors}}}
> {{{chargen-specifics-jetzt}}}
> {{{chargen-print-char}}}
> (chargen-print-char)
>   )
> #+end_src
>
> #+begin_src scheme :noweb-ref chargen-specifics-jetzt
> (define first-names 
>   (map first 
> (map string-split-space 
>   (map third 
> (remove (λ(x)(not (equal? geschlecht (fourth x namen)
> (define last-names (map (λ (x) (string-join (cdr x))) (map 
> string-split-space (map third namen
> (define names (apply append (map (λ (fi) (map (λ(la) (string-join (list 
> fi la))) last-names)) first-names)))
>   ;; (define worte (list->d6alist (second (apply zip zweiworte
>
> #+end_src
>
> Best wishes,
> Arne

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Library of Babel usage of other programming languages than elisp

[Zelphir Kaltstahl]

Hi Greg!

On 8/9/21 5:23 PM, Greg Minshall wrote:
> Zelphir,
>
> actually...
>
> Everybody,
>
> i have an awkwardness about not being clear of the meaning of "Library
> of Babel".  my sense is it a collection of "subroutines".
>
> in my typical use of Org mode for programming, all my code blocks are
> defined in the same .org file, and executed in that file, or tangled to
> external files (normally, scripts).  i do use <> to include bits
> from one part of the same file to the code in another part.  i don't
> know if this means i am using the Library of Babel or not.

I love noweb and literate programming facilities. Have done the same thing
multiple times, especially, when there was some code I want to learn about and
understand or simply explain to my future self. My best example is at:
https://notabug.org/ZelphirKaltstahl/the-little-schemer/src/master/chapter-09-y-combinator/code.org

Big fan of noweb : )

> then, on to...
>
> Zelphir,
>
> i also don't know what is going on.  but, installing geiser,
> geiser-guile, and running your code from the source block, looking at
> the output results, i get an error that might mean something to you?
> see below.  (notice i embedded your call to =org-lob-timediff= at the
> end of your source code.)
>
> in addition to with elisp, i use org src blocks with R, shell scripts,
> awk, etc.  but, never (till now!) with scheme.
>
> hth.  good luck.  i'll be curious what your next steps are.
>
> cheers, Greg
> 
>
> #+HEADER: :var dt1="uninitialized1" dt2="uninitialized2"
> #+name: org-lob-timediff
> #+begin_src scheme :results output
>   (import
>(ice-9 format)
>(srfi srfi-19))
>
>
>   (define org-timestamp->time-utc
> (λ (timestamp-string)
>   (let ([parsed-date (string->date timestamp-string "[~Y-~m-~d ~a 
> ~H:~M]")])
> (date->time-utc parsed-date
>
>
>   (define duration->hours
> (λ (duration)
>   ;; 1h = 60min = 3600s
>   (/ (time-second duration) 3600)))
>
>
>   (define org-lob-timediff
> (λ (org-dt1 org-dt2)
>   ;; formatting float:
>
>   ;; ~@width, decimals, scale, overflowchar, padchar
>
>   ;; ~ placeholder is following
>   ;; @ with sign if negative
>   ;; width: minimum width
>   ;; decimals: minimum number of digits after decimal point
>   ;; scale: ???
>   ;; overflowchar: ???
>   ;; padchar: char to use for padding
>
>   (format #f
>   "~,2f"
>   (number->string
>(exact->inexact
> (duration->hours
>  (time-difference (org-timestamp->time-utc org-dt2)
>   (org-timestamp->time-utc org-dt1
>   (org-lob-timediff "[2021-01-01 Fri 00:00]" "[2021-01-01 Fri 01:45]")
> #+end_src
>
> #+RESULTS: org-lob-timediff
> : ice-9/boot-9.scm:222:17: In procedure map1:
> : Syntax error:
> : unknown file:12:0: definition in expression context, where definitions are 
> not allowed, in form (define org-timestamp->time-utc (λ (timestamp-string) 
> (let ((parsed-date (string->date timestamp-string "[~Y-~m-~d ~a ~H:~M]"))) 
> (date->time-utc parsed-date
> : 
> : Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> : scheme@(guile-user) [1]> 

Hmmm this might be a GNU Guile version difference. I remember something about
definition context changing in something like Guile 3.0.3 or so, allowing
definitions in more places than before. For me this error does not happen, as I
use GNU Guile 3.0.7 currently:

 START 
scheme@(guile-user)> (version)
$6 = "3.0.7"
  END  

Perhaps org-babel for Guile (I think ob-scheme? or ob-guile?) wraps everything
inside another (define ...) and that causes an error with the definition 
context.

What I did notice before is, that the set locale seems to matter for the short
names of weekdays and can lead to an error, but that was on another laptop and
not on this system:

 START 
executing Scheme code block (org-lob-timediff)...

(dt1 '"uninitialized1")

(dt2 '"uninitialized2")

Starting Geiser REPL ... [3 times]
Guile REPL up and running!
Debug REPL. Enter ,q to quit, ,h for help.
=> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure string->date: TIME-ERROR type bad-date-format-string: "[~Y-~m-~d 
~a ~H:~M]"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 
Error during redisplay: (jit-lock-function 315) signaled (wrong-type-argument 
markerp nil)
Code block evaluation complete.
  END  

But that is a Guile thing and nothing to do with LOB and easily fixed.

I began collecting small snippets and facts about whatever I learn about Emacs
in sone repository: https://notabug.org/ZelphirKaltstahl/emacs-usage-guide
. Not much there yet,
but I will add a working example of LOB, if I can 

Re: Library of Babel usage of other programming languages than elisp

[Zelphir Kaltstahl]

The CALL does not work at all for me, not even in the same document, while the
code works just fine in geiser. It results in and empty "#+RESULTS:" being
output below the "#+CALL: ..." and the error in *Messages*.

I did not mention, that I did the lob ingest step as well. Sorry for incomplete
information.

My Emacs version is:

 START 
GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
version 1.16.0)
  END  

And my version of org is:

 START 
Package org is built-in.

 Status: Built-In.
Version: 9.4.4
Summary: Export Framework for Org Mode
Required by: ob-async-20200921.205
Other versions: 9.4.6 (gnu).
  END  

Thank you,
Zelphir

On 8/9/21 5:11 PM, Eric S Fraga wrote:
> On Monday,  9 Aug 2021 at 14:25, Zelphir Kaltstahl wrote:
>> the call in this case can be in the same document. I could copy the
>> code to each document I intend to use it in, without much of a
>> problem. Neater would of course be to have it in a global file,
>> collecting all sorts of snippets/functions.
> Indeed.  I was asking for clarification: does the CALL work when in the
> same document but not otherwise?  For me, I can access awk scripts from
> other documents using LOB with no problem.
>
-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Library of Babel usage of other programming languages than elisp

[Zelphir Kaltstahl]

Hi Eric,

the call in this case can be in the same document. I could copy the code to each
document I intend to use it in, without much of a problem. Neater would of
course be to have it in a global file, collecting all sorts of 
snippets/functions.

Regards,
Zelphir

On 8/9/21 3:34 PM, Eric S Fraga wrote:
> On Monday,  9 Aug 2021 at 12:52, Zelphir Kaltstahl wrote:
>> I have repeatedly tried to use another programming language than elisp
>> for writing source blocks in org-mode, which I intended to use as
>> functions inside org-mode spreadsheets. So far without success.
> I cannot help you directly with this but I can say that I use library of
> babel with awk scripts successfully quite often.  Is the call within the
> same document?  If it is, the issue won't be library of babel support in
> any case, as far as I can tell.
>
-- 
repositories: https://notabug.org/ZelphirKaltstahl

Library of Babel usage of other programming languages than elisp

[Zelphir Kaltstahl]

Hello Org-mode users!

I have repeatedly tried to use another programming language than elisp for
writing source blocks in org-mode, which I intended to use as functions inside
org-mode spreadsheets. So far without success.

Here is my latest attempt:

 START 
#+HEADER: :var dt1="uninitialized1" dt2="uninitialized2"
#+name: org-lob-timediff
#+begin_src scheme
(import
 (ice-9 format)
 (srfi srfi-19))


(define org-timestamp->time-utc
  (λ (timestamp-string)
(let ([parsed-date (string->date timestamp-string "[~Y-~m-~d ~a ~H:~M]")])
  (date->time-utc parsed-date


(define duration->hours
  (λ (duration)
;; 1h = 60min = 3600s
(/ (time-second duration) 3600)))


(define org-lob-timediff
  (λ (org-dt1 org-dt2)
;; formatting float:

;; ~@width, decimals, scale, overflowchar, padchar

;; ~ placeholder is following
;; @ with sign if negative
;; width: minimum width
;; decimals: minimum number of digits after decimal point
;; scale: ???
;; overflowchar: ???
;; padchar: char to use for padding

(format #f
"~,2f"
(number->string
 (exact->inexact
  (duration->hours
   (time-difference (org-timestamp->time-utc org-dt2)
(org-timestamp->time-utc org-dt1
#+end_src

#+CALL: org-lob-timediff(dt1="[2021-01-01 Fri 00:00]", dt2="[2021-01-01 Fri 
01:45]")

#+RESULTS:
  END  

This code works just fine in geiser using GNU Guile:

 START 
scheme@(guile-user)> (org-lob-timediff "[2021-01-01 Fri 00:00]" "[2021-01-01 
Fri 01:45]")
$4 = "1.75"
  END  

However, when I C-c C-c the `CALL` line to actually run the code using library
of babel, as a precursor to using `org-sbe` inside a spreadsheet, it fails! I
see the following in my *Messages* buffer:

 START 
executing Scheme code block...

(dt1 '"[2021-01-01 Fri 00:00]")

(dt2 '"[2021-01-01 Fri 01:45]")

Starting Geiser REPL ... [3 times]
Guile REPL up and running!
Debug REPL. Enter ,q to quit, ,h for help.
=> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: #

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 
Error during redisplay: (jit-lock-function 315) signaled (wrong-type-argument 
markerp nil)
Code block evaluation complete.
  END  

So something obviously is getting confused. `time-second` is not a
syntax-transformer. It is a procedure:

 START 
scheme@(guile-user)> time-second
$5 = #
  END  

Now I have many questions:

+ What am I doing wrong? How comes perfectly valid code does not work in LOB?

+ Can LOB even be used with other languages than Elisp?

+ Almost all examples I see online are elisp only. Perhaps I am trying to do
something, that is impossible with current Org-mode and Library of Babel?

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: org source block execute not working correctly with GNU Guile source block?

[Zelphir Kaltstahl]

Ah, I am sorry, I forgot to include basic information:

Emacs installed via GNU Guix:

GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
version 1.16.0)

Org:

org, 9.3, built-in

On 3/14/21 4:28 PM, Zelphir Kaltstahl wrote:
>
> Hello!
>
> I have an org-mode spreadsheet, in which I calculate durations from timestamps
> like "[2021-03-14 Sun 03:50]" for example. Recently I saw, that using org-sbe
> (org source block execute) in combination with the :var header argument can be
> used to run arbitrary code for calculating values to put as result of
> spreadsheet formulas (on
> https://home.fnal.gov/~neilsen/notebook/orgExamples/org-examples.html
> <https://home.fnal.gov/~neilsen/notebook/orgExamples/org-examples.html>). So I
> went trying it out. The following is some GNU Guile code for calculating time
> differences in hours:
>
> 
> #+NAME: allinone
> #+begin_src scheme :noweb yes :var org-timestamp-1="[2021-01-01 Fri 00:00]", 
> org-timestamp-2="[2021-01-01 Fri 01:00]" :results output drawer replace 
> :exports none
> (import (srfi srfi-19))
>
> (define SECOND 1)
> (define MINUTE (* 60 SECOND))
> (define HOUR (* 60 MINUTE))
>
> (define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")
>
> (define duration->time-utc
>   (λ (duration)
> (make-time time-utc
>(time-nanosecond duration)
>(time-second duration
>
> (define org-timestamp->time-utc
>   (λ (timestamp-string)
> (let ([parsed-date (string->date timestamp-string org-timestamp-format)])
>   (date->time-utc parsed-date
>
> (define org-time-duration
>   (λ (org-timestamp-1 org-timestamp-2)
> (time-difference (org-timestamp->time-utc org-timestamp-2)
>  (org-timestamp->time-utc org-timestamp-1
>
> (define duration->org-timestamp
>   (λ (duration)
> (time-utc->date
>  (duration->time-utc duration)
>  ;; timezone offset, assume all with no offset
>  0)))
>
> (define duration->hours
>   (λ (duration)
> (/ (time-second duration) HOUR)))
>
> (number->string
>  (duration->hours
>   (org-time-duration org-timestamp-1
>  org-timestamp-2)))
> #+end_src
> 
>
> The source block is named "allinone", because I tried previously with :noweb
> yes and referencing other code blocks to be included, but thought that perhaps
> org-sbe does not deal well with :noweb yes, so I wanted to make sure to keep
> everything in one source block.
>
> The variables org-timestamp-1 and org-timestamp-2 are referenced at the bottom
> of the code.
>
> The code runs find in run-guile for example, when I replace the 2 variables
> with the default values of the variables, given in the header argument :var,
> as you can see in this transcript:
>
> 
> GNU Guile 3.0.5
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (import (srfi srfi-19))
>
> (define SECOND 1)
> (define MINUTE (* 60 SECOND))
> (define HOUR (* 60 MINUTE))
>
> (define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")
>
> (define duration->time-utc
>   (λ (duration)
> (make-time time-utc
>(time-nanosecond duration)
>(time-second duration
>
> (define org-timestamp->time-utc
>   (λ (timestamp-string)
> (let ([parsed-date (string->date timestamp-string org-timestamp-format)])
>   (date->time-utc parsed-date
>
> (define org-time-duration
>   (λ (org-timestamp-1 org-timestamp-2)
> (time-difference (org-timestamp->time-utc org-timestamp-2)
>  (org-timestamp->time-utc org-timestamp-1
>
> (define duration->org-timestamp
>   (λ (duration)
> (time-utc->date
>  (duration->time-utc duration)
>  ;; timezone offset, assume all with no offset
>  0)))
>
> (define duration->hours
>   (λ (duration)
> (/ (time-second duration) HOUR)))
> scheme@(guile-user)> (define org-timestamp-1 "[2021-01-01 Fri 00:00]")
> scheme@(guile-user)> (define org-timestamp-2 "[2021-01-01 Fri 01:00]")
> scheme@(guile-user)> (number->string
>  (duration->hours
>   (org-time-duration org-timestamp-1
>  org-timestamp-2)))
> $2 = "1"
> scheme@(guile-user)>
> 
>
> This code assumes, that 

org source block execute not working correctly with GNU Guile source block?

[Zelphir Kaltstahl]

Hello!

I have an org-mode spreadsheet, in which I calculate durations from timestamps
like "[2021-03-14 Sun 03:50]" for example. Recently I saw, that using org-sbe
(org source block execute) in combination with the :var header argument can be
used to run arbitrary code for calculating values to put as result of
spreadsheet formulas (on
https://home.fnal.gov/~neilsen/notebook/orgExamples/org-examples.html
). So I
went trying it out. The following is some GNU Guile code for calculating time
differences in hours:


#+NAME: allinone
#+begin_src scheme :noweb yes :var org-timestamp-1="[2021-01-01 Fri 00:00]", 
org-timestamp-2="[2021-01-01 Fri 01:00]" :results output drawer replace 
:exports none
(import (srfi srfi-19))

(define SECOND 1)
(define MINUTE (* 60 SECOND))
(define HOUR (* 60 MINUTE))

(define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")

(define duration->time-utc
  (λ (duration)
(make-time time-utc
   (time-nanosecond duration)
   (time-second duration

(define org-timestamp->time-utc
  (λ (timestamp-string)
(let ([parsed-date (string->date timestamp-string org-timestamp-format)])
  (date->time-utc parsed-date

(define org-time-duration
  (λ (org-timestamp-1 org-timestamp-2)
(time-difference (org-timestamp->time-utc org-timestamp-2)
 (org-timestamp->time-utc org-timestamp-1

(define duration->org-timestamp
  (λ (duration)
(time-utc->date
 (duration->time-utc duration)
 ;; timezone offset, assume all with no offset
 0)))

(define duration->hours
  (λ (duration)
(/ (time-second duration) HOUR)))

(number->string
 (duration->hours
  (org-time-duration org-timestamp-1
 org-timestamp-2)))
#+end_src


The source block is named "allinone", because I tried previously with :noweb yes
and referencing other code blocks to be included, but thought that perhaps
org-sbe does not deal well with :noweb yes, so I wanted to make sure to keep
everything in one source block.

The variables org-timestamp-1 and org-timestamp-2 are referenced at the bottom
of the code.

The code runs find in run-guile for example, when I replace the 2 variables with
the default values of the variables, given in the header argument :var, as you
can see in this transcript:


GNU Guile 3.0.5
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (import (srfi srfi-19))

(define SECOND 1)
(define MINUTE (* 60 SECOND))
(define HOUR (* 60 MINUTE))

(define org-timestamp-format "[~Y-~m-~d ~a ~H:~M]")

(define duration->time-utc
  (λ (duration)
(make-time time-utc
   (time-nanosecond duration)
   (time-second duration

(define org-timestamp->time-utc
  (λ (timestamp-string)
(let ([parsed-date (string->date timestamp-string org-timestamp-format)])
  (date->time-utc parsed-date

(define org-time-duration
  (λ (org-timestamp-1 org-timestamp-2)
(time-difference (org-timestamp->time-utc org-timestamp-2)
 (org-timestamp->time-utc org-timestamp-1

(define duration->org-timestamp
  (λ (duration)
(time-utc->date
 (duration->time-utc duration)
 ;; timezone offset, assume all with no offset
 0)))

(define duration->hours
  (λ (duration)
(/ (time-second duration) HOUR)))
scheme@(guile-user)> (define org-timestamp-1 "[2021-01-01 Fri 00:00]")
scheme@(guile-user)> (define org-timestamp-2 "[2021-01-01 Fri 01:00]")
scheme@(guile-user)> (number->string
 (duration->hours
  (org-time-duration org-timestamp-1
 org-timestamp-2)))
$2 = "1"
scheme@(guile-user)>


This code assumes, that I have to convert to a string at the end, to make a good
return value for org-mode spreadsheets.

Then I have this table in my document:


|   | timestamp 1| timestamp 2| result |
|---+++|
| # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:55] ||
| # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:50] | nil|
| # | [2021-03-14 Sun 03:50] | [2021-03-14 Sun 03:50] ||
#+TBLFM: $4='(org-sbe "allinone" (org-timestamp-1 $2) (org-timestamp-2 $3))


The one nil is from one time, when I answered "no" to the question, whether I
want to run the associated source block:


Evaluate this emacs-lisp code block on your system? (yes or no)


What is weird is, that it asks about an emacs-lisp code block, while my block is
a scheme block, which is set to GNU Guile on my Emacs.

When I answer "yes" instead, I get an error pasted into my table, destroying its
structure:


|   | timestamp 1| timestamp 2| result 

Re: org-mode export toggle checkboxes

[Zelphir Kaltstahl]

Thanks for that!

Going to try it soon : )

On 12/4/20 7:10 AM, Kyle Meyer wrote:
> Zelphir Kaltstahl writes:
>
>> Hello Emacs and Org-Mode Users,
>>
>> I have a question regarding the export options of org-mode.
>>
>> Is there a way to toggle, whether checkboxes are exported to markdown
>> and plain text (ASCII buffer / file)? I did not find any on
>> https://orgmode.org/manual/Export-Settings.html and so far I tried the
>> following:
> [...]
>
> I'm not aware of an option to control this.  You could accomplish it
> with a filter though:
>
> (defun my/ox-md-ascii-filter-checkboxes (ast backend info)
>   (if (org-export-derived-backend-p backend 'md 'ascii)
>   (org-element-map ast 'item
> (lambda (i)
>   (org-element-put-property i :checkbox nil))
> info)
> ast))
> 
> (add-to-list 'org-export-filter-parse-tree-functions
>  #'my/ox-md-ascii-filter-checkboxes)
>
>
> more details: (info "(org)Advanced Export Configuration")

-- 
repositories: https://notabug.org/ZelphirKaltstahl

org-mode export toggle checkboxes

[Zelphir Kaltstahl]

Hello Emacs and Org-Mode Users,

I have a question regarding the export options of org-mode.

Is there a way to toggle, whether checkboxes are exported to markdown
and plain text (ASCII buffer / file)? I did not find any on
https://orgmode.org/manual/Export-Settings.html and so far I tried the
following:


#+OPTIONS: ^:{} H:10 toc:2
#+STARTUP: content indent align inlineimages hideblocks entitiesplain nologdone 
nologreschedule nologredeadline nologrefile
#+OPTIONS: ^:{}
#+OPTIONS: tags:nil
#+OPTIONS: tasks:nil
#+OPTIONS: toc:nil
#+OPTIONS: H:6
#+OPTIONS: p:nil
#+OPTIONS: pri:nil
#+OPTIONS: prop:nil
#+OPTIONS: todo:nil
#+OPTIONS: stat:nil
#+OPTIONS: |:t
#+OPTIONS: inline:nil


Regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl