Re: [patch] ob-clojure: Fix results output

[Ihor Radchenko]

Ihor Radchenko  writes:

> Feel free to push.

I note that we now have a new compiler warning after your changes:
⛔ Warning (comp): ob-clojure.el:268:45: Warning: Unused lexical argument 
‘params’

May you please take a look?
If the function argument is really unused, replace it with _ in
`ob-clojure-eval-with-cider'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[PATCH] Add tests for ob-haskell (GHCi)

[Bruno Barbier]

Hi all,

I've collected some tests about ob-haskell, using GHCi.

This patch is not ready for final review.  It's a preliminary version.

These tests are about GHCi, and only about GHCi (that's why I named
the file 'test-ob-haskell-ghci.el').


Some tests are revealing bugs; they are flagged with:

:expected-result :failed


All the tests will randomly fail; that is an ob-haskell bug (see
the command 'test-ob-haskell-ghci.el' to make them fail).


Some tests might be questionable, revealing more design choices and/or
backend capabilities than the expected behavior.


Solving the random failure bug should be a priority, in my opinion, as
it makes the testing process unreliable.  Adding support for sessions
would also be a good thing, so that one test doesn't contaminate others.


FTR, here are the tools that I have used:

| emacs-version |  29.0.60 |
| org-version   | main@4cad6c8ea (Mar 16 2023) |
| haskell-mode  | master@20d4e23 (Mar 4  2023) |
| ghci  |9.0.2 |



Bruno

>From c085fac2fcb429f7e643df8e4fff3a4ae1665d07 Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Fri, 18 Nov 2022 20:14:20 +0100
Subject: [PATCH] ob-haskell: Add tests for GHCi

testing/lisp/test-ob-haskell-ghci.el: New file.
---
 testing/lisp/test-ob-haskell-ghci.el | 428 +++
 1 file changed, 428 insertions(+)
 create mode 100644 testing/lisp/test-ob-haskell-ghci.el

diff --git a/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
new file mode 100644
index 0..4b1e4669b
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,428 @@
+;;; test-ob-haskell-ghci.el --- tests for ob-haskell.el GHCi  -*- lexical-binding: t; -*-
+
+;; Copyright (c) 2023  Free Software Foundation, Inc.
+
+;; Authors: Bruno BARBIER 
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see .
+
+;;; Commentary:
+;;
+
+ Useful references
+;;
+;;  - https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html
+
+ FIXME: Random failures
+;;
+;; To increase the chances of failure when running tests, you can use this command line:
+;;
+;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty & done) 2>&1 | grep FAILED
+;;
+
+ Status
+;;
+;; All the tests should succeed (except for random failures); those
+;; flagged with ":expected-result :failed" are known
+;; limitations/bugs.  Tested with (2023-03-18):
+;;
+;; | emacs-version |  29.0.60 |
+;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
+;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
+;; | ghci  |9.0.2 |
+
+
+;;; Code:
+;;
+
+(require 'org-test "../testing/org-test")
+(org-test-for-executable "ghci")
+(unless (featurep 'haskell-mode)
+  (signal 'missing-test-dependency "haskell-mode"))
+
+
+;;; Helpers
+;;
+
+(defun test-ob-haskell-ghci--with-global-session-worker (todo)
+  "See `test-ob-haskell-ghci--with-global-session-worker'."
+  (when (get-buffer "*haskell*")
+(error "A buffer named '*haskell*' exists.  Can't safely test haskell blocks"))
+  (unwind-protect (funcall todo)
+;; Kill the "*haskell*" buffer to not pollute other tests.
+(when-let ((hb (get-buffer "*haskell*")))
+  (with-current-buffer hb
+(let ((kill-buffer-query-functions nil)
+  (kill-buffer-hook nil))
+  (kill-buffer hb))
+
+(defmacro test-ob-haskell-ghci-with-global-session (&rest body)
+  "Eval BODY in a new session, then destroy the session.
+The library ob-haskell doesn't implement session yet.  It will
+always use a buffer named \"*haskell*\".  We kill that buffer
+after the source block execution.  To be safe, we fail if such a
+buffer already exists."
+  `(test-ob-haskell-ghci--with-global-session-worker (lambda () ,@body)))
+
+(defun test-ob-haskell-ghci (args content &optional preamble unprotected)
+  "Execute the code block CONTENT in a new GHCi session; return the result.
+Add ARGS to the code block argument line.  Insert PREAMBLE
+before the code block.  When UNPROTECTED is non-nil, don't control
+which session is used (i.e. don't call
+`test-ob-haskell-ghci--with-global-session-worker')."
+  (when (listp content)
+(setq content (string-join content "\n")))
+  (unless p

Re: Haskell code blocks

[Bruno Barbier]

Hi Ihor,

>> Bruno Barbier  writes:
>>
>>> Sorry, I'm still working on adding a 'test-ob-haskell.el', when I have
>>> some spare time, but I'm unable so far to find tests that I can't
>>> reliably break.

FTR: I've opened a new thread, with a patch containing tests:

   https://lists.gnu.org/archive/html/emacs-orgmode/2023-03/msg00274.html

Bruno.

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Bruno Barbier  writes:

> All the tests will randomly fail; that is an ob-haskell bug (see
> the command 'test-ob-haskell-ghci.el' to make them fail).

First of all, thanks for the patch! Tests are especially welcome.

>From a first look, random failures appear to be related to session
initialization. It appears that ob-haskell is re-using sessions even
if :session is nil (default). And multiple session not allowed?? (I am
looking at `org-babel-haskell-initiate-session', which ignores session
parameter completely).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Ihor Radchenko  writes:

> From a first look, random failures appear to be related to session
> initialization. It appears that ob-haskell is re-using sessions even
> if :session is nil (default). And multiple session not allowed?? (I am
> looking at `org-babel-haskell-initiate-session', which ignores session
> parameter completely).

Lawrence, may you please take a look at this thread?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Bruno Barbier]

Hi Ihor,

Ihor Radchenko  writes:

> From a first look, random failures appear to be related to session
> initialization.

My function 'test-ob-haskell-ghci' should protect against that; it
ensures the "*haskell*" buffer is always new.  From what I understand,
this is an input buffering problem: inputs are not full lines.

> It appears that ob-haskell is re-using sessions even
> if :session is nil (default). And multiple session not allowed?? (I am
> looking at `org-babel-haskell-initiate-session', which ignores session
> parameter completely).

>From what I understood, the buffer "*haskell*" is coming from
haskell-mode. And, to make it work might require some changes there too.

Thanks for having a look,
Let me know,


Bruno


>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [PATCH v2] org-manual.org: $n$-th is not math

[Rudolf Adamkovič]

Max Nikulin  writes:

>> Bummer the dash will not be supported. :(
>
> You had an opportunity to submit an alternative patch fixing regexps.

But why?  We have seen such attempts already, such as

  "[PATCH] Add support for $…$ latex fragments followed by a dash"

The attempts were always rejected.  So, just a "bummer".  :)

Rudy
-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
-- Walter Warwick Sawyer, Mathematician's Delight, 1943

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [PATCH v2] org-manual.org: $n$-th is not math

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> The attempts were always rejected.  So, just a "bummer".  :)

As I said in the linked message, supporting "-" will not solve the basic
issue, which is with the Org syntax not being LaTeX. Intra-word markup,
including $...$, requires workarounds. It is the trade-off we have to
take.

https://list.orgmode.org/87r18t7fc5.fsf@localhost

>>>   The problem with parsing is more than just supporting $i$-th and
>>>   similar. For example, AMS style guide explicitly advises against using
>>>   $i$-th in favour of $i$th [1]:
>>>
>>>   Do not hyphenate “th” expressions: xth, not x-th or xth .
>>>
>>>   We can theoretically make a change to support "-", but then it will be
>>>   logical to support $i$th as well. (If we don't some users will still be
>>>   confused after trying to write $i$th and then not getting the expected
>>>   results). In this question, it would make sense to implement
>>>   all-or-everything approach. Otherwise, confusion (like raised in this
>>>   thread) will be inevitable.
>>>
>>>   However, from point of view of Org mode parser, supporting $i$th is a
>>>   nightmare.  Remember that Org mode is _not_ LaTeX and we have to support
>>>   a lot more frivolous syntax (even in LaTeX, runaway $ is often a source
>>>   of cryptic compilation errors). Currently, we _must_ rely on heuristics
>>>   to determine $$-style latex fragments. I do not know any way to support
>>>   $$ syntax without creating deviations from LaTeX. Extending the
>>>   heuristics will not resolve the underlying ambiguity of $$ syntax, just
>>>   hide it within even more obscure cases.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[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: [PATCH v4] lisp/ob-screen.el: Support ~:var~ header args for babel blocks

[Ken Mankoff]

Hi Max,

On 2023-03-16 at 11:09 -04, Max Nikulin  wrote...
> Ken, you wrote that you have other patches for ob-screen.el. Do you
> plan to sent them?

Here is the other patch. Respect custom screen command.

  -k.

>From ff919de09e020fa053f5727f3b36026a3a773f88 Mon Sep 17 00:00:00 2001
From: "Kenneth D. Mankoff" 
Date: Sun, 26 Feb 2023 17:38:54 -0800
Subject: [PATCH 2/2] ob-screen.el: respect custom screen location

---
 lisp/ob-screen.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-screen.el b/lisp/ob-screen.el
index 6356d84dd..2013cf12d 100644
--- a/lisp/ob-screen.el
+++ b/lisp/ob-screen.el
@@ -98,7 +98,7 @@ In case you want to use a different screen than one selected by your $PATH")
 
 (defun org-babel-screen-session-socketname (session)
   "Check if SESSION exists by parsing output of \"screen -ls\"."
-  (let* ((screen-ls (shell-command-to-string "screen -ls"))
+  (let* ((screen-ls (shell-command-to-string (concat org-babel-screen-location " -ls")))
  (sockets (delq
 		   nil
(mapcar
-- 
2.34.1

Re: [PATCH v2] org-manual.org: $n$-th is not math

[Max Nikulin]

On 19/03/2023 18:08, Rudolf Adamkovič wrote:

Max Nikulin writes:

You had an opportunity to submit an alternative patch fixing regexps.


But why?  We have seen such attempts already, such as

   "[PATCH] Add support for $…$ latex fragments followed by a dash"


I am sorry, I missed that this patch changes the same lines as commits 
mentioned in the comment to my patch. Sébastien Miquel would had more 
chances to convince people if, instead of referencing the thread related 
to deprecation of "$...$", the manual was cited with the commit that 
broke described behavior. So partially it is a communication issue.


I do not have strong opinion if support of $n$th is tightly bound to 
recognizing $n$-th. On the other hand I would not object deprecation of 
"$...$".


Ihor, if https://updates.orgmode.org/ is still maintained, could you, 
please, remove the entry related to this patch and 3 ones for

https://list.orgmode.org/f0597d96-a287-2c48-7897-6b8737c95...@posteo.eu/

Re: Org Table Header bug?

[Ypo]

Hi Ihor.

The heading and first lines of the table:

|---+---+-|
| NPS (~\Oslash_int pulg.) | DN (~\Oslash_int mm) | PP/PE (\Oslash_ext mm) |
|---+---+-|
| 1/8"  | DN 6  | PE 10 / PP 10   |
| 1/4"  | DN 8  | PE 12 / PP 12   |
| 3/8"  | DN 10 | PE 16 / PP 16   |


The \Oslash appears as the Unicode character ⊘ normally.


The \Oslash is not viewed as the Unicode character ⊘ with 
"org-table-header-line-mode". And the first line of the table appears in 
the heading.


https://i.ibb.co/jht3HL0/Captura.png


The \Oslash appears as the Unicode character ⊘, if using the package 
org-table-sticky-header  
wich has the same objective, I think:


"...this package uses the header line to show the table header when it 
is out of sight."


https://i.ibb.co/T8fD3BR/Captura.png


Best regards


El 13/03/2023 a las 12:37, Ihor Radchenko escribió:

Ypo  writes:


When enabled org-table-header-line-mode, the LaTeX symbols in the header
are not fontified.

It would help if you provided a reproducer.

Note that getting this right is a bit tricky. In particular, when table
columns are shrunk.

The function doing the work is `org-table-row-get-visible-string'.
I am wondering if there is a better way to retrieve visible string than
what is done in the function.

Re: [patch] ob-clojure: Fix results output

[Daniel Kraus]

Ihor Radchenko  writes:

> I note that we now have a new compiler warning after your changes:
> ⛔ Warning (comp): ob-clojure.el:268:45: Warning: Unused lexical argument 
> ‘params’
>
> May you please take a look?
> If the function argument is really unused, replace it with _ in
> `ob-clojure-eval-with-cider'.

Ups, sorry.
Before `params` was only used to receive the :target parameter if it's a cljs 
or clj
block. But that's now just a regular parameter to the function.
I fixed it with a _ prefix.

Cheers,
  Daniel

Re: [SUGGESTION] separate ob-clojure.el into Clojure part ob-clojure.el and ClojureScript part ob-clojurescript.el

[Daniel Kraus]

Ihor Radchenko  writes:

> stardiviner  writes:
>
>> For now, ob-clojure.el contains lot of code for ClojureScript. Only some
>> code has same functionality. Like CIDER backend. In the future,
>> ClojureScript part code will increase and different. So I suggest
>> separate them into two source code files.
>>
>> WDYT?

I'm not opposed to it, but I'm also not sure if it's worth it.
Without whitespace and comments, ob-clojure is only 261 LOC and without
having a closer look I would guess we would have to duplicate maybe 150
of those in ob-clojurescript.
It would make the implementation a bit cleaner but at the cost of
code duplication.
I would say we wait until the ClojureScript part really grows bigger
and then do a split if that should ever happen.
I could also see a scenario where we add support for ClojureDart
and/or ClojureCLR to ob-clojure. It would be very simple if they
have a CLI like the JVM Clojure.


> The only downside is that people might need to
> (require 'ob-clojurescript)
> I am thinking if ob-core.el should try to automatically guess the
> correct library to be loaded.

We could just (require 'ob-clojurescript) inside ob-clojure.el ?!

Cheers,
  Daniel

Re: Hyphen after LaTeX fragments

[iemacs]

Hi,

You can write \(n\)-dimensional space.

On Wed, Mar 15, 2023, 02:18 Yuchen Guo  wrote:

> Sometimes I encounter such texts:
>
>One of the useful features of a basis $B$ in an $n$-dimensional space
>
> When entered as-is in Org mode and exported to LaTeX, the string
> "$n$-dimensional" is exported as plain text, as
>
>   One of the useful features of a basis \(B\) in an \$n\$-dimensional space
>
> However, in cases such as "$n$;" and "$n$.", they are correctly exported
> as "\(n\);" and "\(n\).".
>
> Are there any option to treat hypen the same as semicolon or full stop
> in LaTeX exports?
>
> --
> Yuchen Guo
>
>

Friendly exchange of thoughts: citations and LaTeX

[Pedro Andres Aranda Gutierrez]

HI

I just wanted to start a _friendly_ exchange of thought which may end
up in some code related with citations and LaTeX. (sort of my SoC :-)
)

It all starts with the support for the LaTeX '\jobname' macro. It is
quite convenient and I have been using it for a long time now. In the
'old dog don't learn new tricks' mode, I started using it for
citations and it looks like it works in the generated LaTeX code, but
not in the integration with org-cite. I'm thinking about the
possibility of making org-mode accept and treat \jobname correctly.

Having said that, I was also (just a bit) bugged by the fact that
bibliography file names are completely expanded when generating LaTeX.
Couldn't we avoid that for LaTeX export?

 Thoughts?
/PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet