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

[ParetoOptimalDev]

Ihor Radchenko  writes:

> Note that setting the prompt to non-"", makes little sense - we want to
> remove it anyway. Why do extra work?

Oh, I didn't notice you set the prompt to "". I thought the extra work
you were being done was *because* somewhere else the default was set to
"λ ".

I agree, do whatever is less work and more normalized here.

Re: Mention outli, and h speed-key

[Jean Louis]

* JD Smith  [2023-03-25 05:22]:
> > It is more visible, but I am trying to understand what o you consider 
> > better then outline-minor-mode 
> 
> It sets up headline regexps automatically and consistently, and adds
> configurable styling and org-inspired speed keys on headings.  At
> core it is still outline mode.  Think of it like org-ified
> outshine-light.  

I have tried this in fundamental mode:

>> Ok here

Hello there

>>> And Ok here

Then I was M-x outli-mode and I was thinking headlines will now appear
automatically, but nothing appeared there.

I don't get it though I find it fancy and nice.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

[Bruno Barbier]

Ihor Radchenko  writes:

> I investigated further and now applied a set of patches that improves
> prompt filtering in org-comint.
> ..

Thanks Ihor.

I don't get random failures anymore.  And thanks for fixing the tests
that were incorrect.

Thanks Pareto for mentioning the possibiliy to customize GHCi prompts.



> The remaining tests fall into two categories:
> 1. Tests trying to test :results value vs. :results output in sessions.
> 2. Tests trying to test for multiple sessions not interfering each
>other.

About :results output vs :results value, I decided to use the "it"
variable, i.e. to ask GHCi what was the last value (see [1]).

About sessions, I decided to rename the buffer as you suggested. That's
a partial workaround that should work well enough, until haskell-mode
provides a way to choose the buffer name.

I've updated the tests and the expected results.

Note that I've changed the tests about errors; I'm now expecting
ob-haskell to raise errors. I'm not sure what we should expect to be
consistent with other org babel backends.

I also did some modifications in my initial patch in-place.

Bruno


[1]:https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#the-it-variable

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

testing/lisp/test-ob-haskell-ghci.el: New file.
---
 testing/lisp/test-ob-haskell-ghci.el | 453 +++
 1 file changed, 453 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..aba94d73f
--- /dev/null
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -0,0 +1,453 @@
+;;; 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
+;;  - GHCi manual: https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.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 ( 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  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 

Re: org mode table alignment issue with CJK characters

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> 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"?

I did trial and error. AFAIU, it totally depends on the font's
width-to-height ratios. AFAIK, Emacs tries to make all the fonts have
the same height - leading to horizontal misalignment you observed. The
extra custom scaling will make line height vary for latin-only vs.
latin+CJK lines.

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

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: svg file from tikz picture

[Ihor Radchenko]

Akira Kyle  writes:

>> Do note that FSF should reply within 5 working days.
>> If not, please follow up and wait another 5 working days.
>> They should reply by then, but if still not, let us know - we 
>> will be
>> able to push them further.
>
> The last message I received from them was over a month ago and my 
> last follow up email to them was ten days ago.

Bastien, may you follow up with Craig about the status?

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

Re: svg file from tikz picture

[Akira Kyle]

On Sat, Mar 25, 2023 at 06:13 PM, Ihor Radchenko 
 wrote:



Do note that FSF should reply within 5 working days.
If not, please follow up and wait another 5 working days.
They should reply by then, but if still not, let us know - we 
will be

able to push them further.


The last message I received from them was over a month ago and my 
last follow up email to them was ten days ago.

Re: svg file from tikz picture

[Ihor Radchenko]

Akira Kyle  writes:

> Unfortunately, I'm still waiting for my fsf copyright assignment 
> paperwork to go through, and I think I'm already at my maximum 
> allowed copyright-exempt contributions for emacs.

Do note that FSF should reply within 5 working days.
If not, please follow up and wait another 5 working days.
They should reply by then, but if still not, let us know - we will be
able to push them further.

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

Re: Remove "shell" as a supported Babel language within ob-shell.el (was Re: [SUGGESTION] ob-shell async result output should not contains shell prompt)

[Ihor Radchenko]

Samuel Wales  writes:

> i have a vague memory of having used sh and then we were told to use
> shell.  can we all use begin src sh now?

You can use anything listed in `org-babel-shell-names'.
Also, see https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html

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

Re: org mode table alignment issue with CJK characters

[Ihor Radchenko]

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.


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

[POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Ihor Radchenko]

Max Nikulin  writes:

>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>> including built-in Emacs libraries are loaded with side effects.
>
> It is still violation of conventions:
>
> (info "(elisp) Coding Conventions")
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>> D.1 Emacs Lisp Coding Conventions
>> 
>> Simply loading a package should not change Emacs’s editing behavior.
>> Include a command or commands to enable and disable the feature, or to
>> invoke it.
>> 
>> This convention is mandatory for any file that includes custom
>> definitions. If fixing such a file to follow this convention requires an
>> incompatible change, go ahead and make the incompatible change; don’t
>> postpone it.

This is convincing.
I am then CCing Bastien, as, despite the Elisp convention, following it
will break https://bzg.fr/en/the-software-maintainers-pledge/

>> Note that we discussed loading side effects in
>> https://list.orgmode.org/orgmode/tn4ql0$bu2$1...@ciao.gmane.io/
>
> I have not responded to that thread. My opinion is that besides 
> functions that just loads files and packages there should be 
> counterparts that loads and activates libraries. A proof of concept may 
> be implemented for Org and in the case of success it may be proposed for 
> inclusion into Emacs core.

Maybe. We can do something similar to `unload-feature'. However, it will
still require users to adapt.

Tentative implementation:

(defun enable-feature (feature  filename noerror)
  "Load and enable FEATURE.
FILENAME and NOERROR arguments are the same as in `require'."
  (when (require feature filename noerror)
(let ((enabler-cmd (intern (format "%s-enable-function" feature
  (and (fboundp enabler-cmd) (funcall enabler-cmd)

(defun disable-feature (feature)
  "Disable FEATURE."
  (let ((disabler-cmd (intern (format "%s-disable-function" feature
(and (fboundp disabler-cmd) (funcall disabler-cmd

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

Docstring fixes

[Stephen J. Eglen]

Some small docstring fixes to align with convention in Emacs for
'Non-nil means ...'

Stephen

diff --git a/lisp/org.el b/lisp/org.el
index 4d12084d9..08a6f1a50 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3600,13 +3600,13 @@ following symbols:
   (const :tag "Entities" entities
 
 (defcustom org-hide-emphasis-markers nil
-  "Non-nil mean font-lock should hide the emphasis marker characters."
+  "Non-nil means font-lock should hide the emphasis marker characters."
   :group 'org-appearance
   :type 'boolean
   :safe #'booleanp)
 
 (defcustom org-hide-macro-markers nil
-  "Non-nil mean font-lock should hide the brackets marking macro calls."
+  "Non-nil means font-lock should hide the brackets marking macro calls."
   :group 'org-appearance
   :type 'boolean)
 
@@ -3618,7 +3618,7 @@ When nil, the \\name form remains in the buffer."
   :type 'boolean)
 
 (defcustom org-pretty-entities-include-sub-superscripts t
-  "Non-nil means, pretty entity display includes formatting sub/superscripts."
+  "Non-nil means pretty entity display includes formatting sub/superscripts."
   :group 'org-appearance
   :version "24.1"
   :type 'boolean)

Document org-hide-emphasis-markers

[Stephen J. Eglen]

Here is a small patch to document org-hide-emphasis-markers

Best wishes,

Stephen

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 37fd3df14..50662669e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11005,6 +11005,10 @@ To turn off fontification for marked up text, you can 
set
 ~org-fontify-emphasized-text~ to ~nil~.  To narrow down the list of
 available markup syntax, you can customize ~org-emphasis-alist~.
 
+#+vindex: org-hide-emphasis-markers
+To hide the emphasis markup characters in your buffers, set
+~org-hide-emphasis-markers~ to ~t~.
+
 Sometimes, when marked text also contains the marker character itself,
 the result may be unsettling.  For example,
 

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 formatting will be automatically 
according to their practices.)


Otherwise the diff becomes huge and I 

Re: [BUG] Agenda not sorting by priority THEN todo state (todo state ignored) [9.6.1 (9.6.1-??-fe92a3c @ /Users/polofsson/.emacs.d/.local/straight/build-28.2/org/)]

[Samuel Wales]

it is all ok with me, but not everybody has personal test cases for
sorting sequence, and soembvody might get bitten by a subtle change
like this which pop up every once in a while.  thus the conflated
thing -> 2 names.  the old one could be deprecated or so, i was
thinking.  i get your points though and didn't realize about the
docstroing.  i have no strong opinion on this; just wanted the idea of
disambiguating out there.  as long as 2 things are not conflated
that's good.


On 3/24/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> i find that when 2 things are being conflated, whether in software or
>> in anything else, it is useful to change the name of both of them for
>> maximum clarity, future git searches, etc.
>>
>> thus, perhaps i would suggest somthign like this slight tweak instead.
>>
>>   priority-cookie-up
>>   priority-cookie-and-planning-urgency-up
>
> I do not like the idea of changing both the names. The current change
> will ensure that existing uses of "priority-up"/"priority-down" sorting
> strategies won't be affected too much. Forcing every Org user who
> customized agenda sorting to change the variable values is not
> acceptable.
>
> Note that the patch, despite changing the actual meaning of
> priority-up/down, makes it more conforming with
> `org-agenda-sorting-strategy' docstring. So, this change is, in fact,
> safe.
>
>> if not too verbose.  reasoning: urgency is occasionally considered
>> orthogonal to priority in some philosophies, and some users have
>> :urgent: tags.  so this might eliminate slightly more confusion in
>> principle.
>
> I am neutral wrt "urgency" term. We can use some other.
>
> I do not like the verbosity. Even something like
> "priority-and-urgency-up/down" sounds awkward, IMHO.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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

Re: Remove "shell" as a supported Babel language within ob-shell.el (was Re: [SUGGESTION] ob-shell async result output should not contains shell prompt)

[Samuel Wales]

i have a vague memory of having used sh and then we were told to use
shell.  can we all use begin src sh now?

On 3/24/23, Ihor Radchenko  wrote:
> Matt  writes:
>
>> What benefit does "shell" provide?
>>
>> - The "shell" language allows an arbitrary executable to be run.  This
>> means that shells other than those given in `org-babel-shell-names' can be
>> run.  People using a non-supported shell could still benefit from
>> ob-shell.
>>
>> What downsides does "shell" bring?
>>
>> - "shell" falls back to `shell-file-name' which can be an arbitrary
>> executable.  Whenever I hear "runs an arbitrary executable", my ears perk
>> up and I start to sweat.  There may be security considerations.
>> - If that executable is a shell, then the prompt gets set independently
>> from Emacs.  For the prompt to be filtered from the output, users would
>> need to provide Emacs with the correct regexp.  A recent thread discussed
>> creating a header arg to address this:
>> https://list.orgmode.org/87ttzgeg3w.fsf@localhost/
>> - We would get bug reports about non-supported shells which kind of work,
>> but have issues because they're not supported
>> - Maintence associated with supporting arbitrary (shell) executables
>>
>> As the current maintainer of ob-shell, I'm in favor of removing "shell" as
>> a Babel language.  The cons appear to far outweigh the pros.  However, I'm
>> aware others may have good use for it.  It's been a part of Org for nearly
>> a decade.  I'm sure it's part of people's workflow, especially since it's
>> been in the manual for 6 years.  Are there any pros, cons, use-cases, or
>> considerations I've overlooked?
>
> I would not see arbitrary executable to be such a big deal. At the end,
> if SHELL is set to something fishy, the user is likely in serious
> trouble anyway. SHELL is a part POSIX standard at the end.
>
> Yet, the problem with unsupported shells is indeed real.
> Moreover, "shell" code blocks are currently not portable to different
> environments.
>
> I suggest the following:
> 1. Introduce a new customization `org-babel-default-shell', defaulting
>to (or (executable-find "sh") (executable-find "cmd.exe")).
> 2. Use the value as default shell in "shell" code blocks.
> 3. Document and announce the change.
> 4. Create org-lint checker that will mark "shell" code blocks as not
>desired.
>
> The above steps will ensure minimal breakage for existing uses of
> "shell" blocks. Only users who wrote shell blocks for non-standard shell
> will have to adapt.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com