Re: Mention outli, and h speed-key

[JD Smith]

> 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.  

Re: svg file from tikz picture

[Akira Kyle]

On Mon, Nov 14, 2022 at 05:52 AM, Ihor Radchenko 
 wrote:



Have you had a chance to look into my comments?


Sorry for the really slow replies, I do intend to follow up on 
this at some point.


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.

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]

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 

Re: orgmode website contributions to translations? -- Was: It's possible, to translate the org-mode website into Spanish?

[General discussions about Org-mode.]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> The main issue with non-English translations is maintenance. As you
>> noticed, English and non-English pages are already out of sync.
>
> Anyone willing to help with orgmode.org website can get access to the
> https://git.sr.ht/~bzg/orgweb repository and help with translations too.
>
> Just let me know!   And thanks in advance.

I can help translate to zh_CN occasionally, seeing that the repo is not
updated too frequently.  Although I might need some pointers on how to
start a new translation, and how sourcehut works. :)

Also, does this need a copyright assignment?  FTR, I am still waiting
for a counter-signature from FSF on Emacs.

--
Best,


RY

Re: [PATCH] ox-texinfo: Fix invalid syntax in Texinfo version detection code

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>>> All right, I added the 'require' to both files.  Better?
>>
>> Thanks!
>> Applied, onto bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=99c8ed09f
>
> The tests are failing on older Emacs.
> https://builds.sr.ht/~bzg/job/942040
> https://builds.sr.ht/~bzg/job/942041

I finally managed to fix the tests.
See
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix=4c01eba265edfb910e926c5559aca5bf7d7a3650

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

Re: Mention outli, and h speed-key

[Jean Louis]

* JD Smith  [2023-03-10 07:03]:
> One speed key I added to outli I really miss in org, so I added it:
> 
> (if-let ((pos (cl-position '("Outline Visibility") org-speed-commands :test 
> #'equal)))
>   (cl-pushnew '("h" . outline-hide-sublevels) (nthcdr (1+ pos) 
> org-speed-commands)))
> 
> Basically h=outline-hide-sublevels.  This allows you to quickly
> collapse the entire tree to the level [h]ere.  It’s a wonderful,
> fast compromise between the ease of Shift-Tab and org’s more
> targeted folding capabilities.

It is more visible, but I am trying to understand what o you consider
better then outline-minor-mode

-- 
Jean

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

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

Re: Ability to add logo to HTML export

[Ihor Radchenko]

Vladimir Alexiev  writes:

> But then C-c C-e h h complains: "org-export--parse-option-keyword: End of
> file during parsing".

Please update Org mode.

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

Re: feature request: easy embedding of images

[Ihor Radchenko]

Alexis Gallagher  writes:

>   •   you can still scroll the window one line height unit at a time, 
> without the entire image being scrolled as if it were one giant line, 
> breaking scrolling, as seems to happen on my emacs (version 28.x on Linux)

Emacs will actually scroll partially when the image is taller than
window height. But not otherwise.
Changing this is not trivial.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62048#17

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

[FR] Make org-occur highlights always visible, even upon folding (was: Bug or expected behavior? org-sparse-tree visibility toggling)

[Ihor Radchenko]

Cassio Koshikumo  writes:

> Hm. It makes sense that TAB is not affected... Somehow I hadn't really
> considered that.
>
> What I expected to happen (and now I realize it was not a justified
> expectation) was to have the visibility of the sparse-tree kept while
> tabbing. So I could expand a tree, then collapse it again, all the
> while keeping the sparse-tree "filter" applied. But I guess it doesn't
> make much sense.
>
> Well, I guess I could leave it as a suggestion for new functionality,
> but I don't even know if it's feasible.

It is not very hard to do, actually. See the attached patch.

However, I am not sure if it is something of interest for other Org
users.

If there is more support, I can convert the patch into proper new Org
feature, adding customization and necessary ORG-NEWS announcement.

>From d3e8d0a9fc235b025f005158cc51f21e5e2ec8ee Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Fri, 24 Mar 2023 13:10:37 +0100
Subject: [PATCH] org-highlight-new-match: Make highlights always visible

* lisp/org.el (org-highlight-new-match): Make highlights always
visible, even upon folding.
---
 lisp/org.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 20e6ea6d9..1834eadbc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10762,10 +10762,15 @@ (defun org-occur-next-match ( n _reset)
 
 (defun org-highlight-new-match (beg end)
   "Highlight from BEG to END and mark the highlight is an occur headline."
-  (let ((ov (make-overlay beg end)))
+  (let ((ov (make-overlay beg end))
+(ov-line (make-overlay
+  (org-with-point-at beg (max (point-min) (1- (pos-bol
+  (org-with-point-at end (pos-eol)
 (overlay-put ov 'face 'secondary-selection)
 (overlay-put ov 'org-type 'org-occur)
-(push ov org-occur-highlights)))
+(overlay-put ov-line 'invisible 'org-occur)
+(push ov org-occur-highlights)
+(push ov-line org-occur-highlights)))
 
 (defun org-remove-occur-highlights ( _beg _end noremove)
   "Remove the occur highlights from the buffer.
-- 
2.39.1


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

Re: Ability to add logo to HTML export

[Vladimir Alexiev]

#+OPTIONS: html-preamble:"Author: %a(%e)Date: %d"

C-c happily says "Local setup has been refreshed"

But then C-c C-e h h complains: "org-export--parse-option-keyword: End of
file during parsing".
I don't see any problem in the string; evaluating it in *scratch* returns
it just fine.
But I think  org-export--parse-option-keyword uses some limited reader...

Re: orgmode website contributions to translations? -- Was: It's possible, to translate the org-mode website into Spanish?

[Ihor Radchenko]

Ruijie Yu  writes:

> I can help translate to zh_CN occasionally, seeing that the repo is not
> updated too frequently.  Although I might need some pointers on how to
> start a new translation, and how sourcehut works. :)

Just clone the repo from https://git.sr.ht/~bzg/orgweb and send patches
to this mailing list as usual. See
https://orgmode.org/worg/org-contribute.html

> Also, does this need a copyright assignment?  FTR, I am still waiting
> for a counter-signature from FSF on Emacs.

AFAIK, yes. For the official Org page (not WORG), we require FSF
copyright assignment.

Note that FSF should usually reply within 5 working days. If not, you
follow up once, wait another 5 working days, and then let us know - we
can push them stronger.

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

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/)]

[Ihor Radchenko]

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 

Re: [SUGGESTION] ob-shell async result output should not contains shell prompt

[Ihor Radchenko]

Matt  writes:

> Changing the `ob-shell-async-chunk-callback' like this will fix it:
>
> @@ -276,7 +276,7 @@ See `org-babel-comint-async-indicator'.")
>  (defun ob-shell-async-chunk-callback (string)
>"Filter applied to results before insertion.
>  See `org-babel-comint-async-chunk-callback'."
> -  (replace-regexp-in-string comint-prompt-regexp "" string))
> +  (replace-regexp-in-string (concat (regexp-quote org-babel-sh-prompt) " *") 
> "" string))

This is trying to replicate what `org-babel-comint-with-output' does
already and is stumbling upon the same edge cases.

May you instead factor out the filtering code from
`org-babel-comint-with-output' and reuse it in ob-shell?

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

Re: [PATCH] Async evaluation in ob-shell

[Ihor Radchenko]

Matt  writes:

>   On Thu, 23 Mar 2023 07:48:44 -0400  Ihor Radchenko  wrote --- 
>  > May you also document this new feature in ORG-NEWS and in
>  > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html ?
>
> Done.

A small note on the WORG page: it may be more natural to use :async yes
rather than :async t. Both are viable - in fact, anything other than
:async no and :async none will be treated as "t".

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

Re: Ability to add logo to HTML export

[Ihor Radchenko]

Vladimir Alexiev  writes:

> Right now I have to resort to a bad kludge to do that: a local variable in
> the org file:
>
> #+comment: -*- org-html-preamble: "Author:
> %a(%e)Date: %d src='./img/SemBSDD-Logo-400px.png'/>" -*-

If you have good ideas how to improve `org-html--build-pre/postamble',
patches welcome.

> So I tried this, but it had no effect"
>
> #+OPTION: html-preamble: "Author: %a(%e) class='date'>Date: %d"

OPTION_S_ and you cannot have space after html-preamble: _

Try

#+OPTIONS: html-preamble:"Author: %a(%e)Date: %d"

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

Re: [fr] allow overriding the likely unintended consequence of org-export-with-tasks

[Ihor Radchenko]

Samuel Wales  writes:

> i wrote: "i would prefer the top level of the subtree to be exported
> in all cases, because i have asked org to export.  it does not matter
> what kw it is set to or what the variable is set to."
> ...
> as for ref [or blank] i do not want to have to keep or temporarily set
> a todo kw, or lack of one, at the top level, merely to allow
> exporting.  this would be requiring me to maintain a keyword that i do
> not want there in the outiine, OR a keyword that i do not want ther
> ein the variable, both of which could have various consequences both
> semantic and user-comprehension-oriented.

I see.

> i find that having the feature apply also on the top level heading is
> 1] pointless, because there is no point in exporting nothing, and 2]
> unexpected/surprising because you just SAID to export the subtree!,
> and 3] unintended for similar reasons.

Sometimes, there is point exporting nothing. In particular, for batch
exports. Also, nothing is too strong term. You will still have global
(empty) template being exported.

In other words, always exporting top-level heading is not always a good
idea.

> in case anybody wants the no-op, making it optional to export the top
> level heding would be copacetic.

One can modify

;; Ignore tasks, if specified by `:with-tasks' property.
(and todo
 (or (not with-tasks)
 (and (memq with-tasks '(todo done))
  (not (eq todo-type with-tasks)))
 (and (consp with-tasks) (not (member todo with-tasks)

condition in `org-export--skip-p' to take into account yet another
customization.

Patches welcome.

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

[Christopher M. Miles]

At first, thanks for this long parsing and explanation.

Matt  writes:

>  > Matt m...@excalamus.com> writes:
>  >
>  > > Is there a reason you're using "shell" instead of one of the shells 
> listed in `org-babel-shell-names'?
>
> I'm still curious why you're using "shell".  I want to know if it's something 
> you're using for a specific reason.  There's no wrong answer!
>
> I ask because I have an agenda: as far as I can tell, "shell" as a Babel 
> language is a historical accident.  
>
> #+begin_longwinded_explanation
> Originally, ob-shell.el was called ob-sh.el.  The main function was called 
> `org-babel-execute:sh' and only /usr/bin/env sh was supported.  Over time it 
> became clear that to support other shells, the "sh" name shouldn't be used 
> for the package or the main function.  That is, 'sh' refers to a specific 
> binary and, if other binaries such as bash, dash, csh, etc. were to be 
> supported, it would be misleading for the Babel language to refer to a 
> specific shell, 'sh'.  So, the terminology was changed to something more 
> general, "shell".  The package was renamed to "ob-shell.el", the "namespace" 
> updated to "shell" (for example, `org-babel-execute:shell'), and the package 
> load call changed from (sh . t) to (shell . t).  This officially happened 
> with Org 8.2 (ORG-NEWS noted the change in commit 
> 1a9adcb6d34bcbdff45445c827ed99dbf0b8, Tue Jan 21 09:52:31 2014).  I think 
> this gave people the (understandable) impression that "shell" was a valid 
> Babel language, in addition to those listed in `org-babel-shell-names'.  
>
> And this is where the accident happened: "shell" as a Babel language only 
> **happens**to work.  The Babel framework looks for a function prototype like 
> "org-babel-execute:".  When ob-sh.el was changed to ob-shell.el, 
> the function `org-babel-execute:sh' became `org-babel-execute:shell'.   A 
> call like follows is perfectly legal as far as the Babel framework is 
> concerned:
>
> #+begin_src shell
> echo "hello, world"
> #+end_src
>
> When such a block is run, Babel looks for a function called 
> `org-babel-execute:shell'. Running the
> block prior to Org 8.2 should have failed because no 
> `org-babel-execute:shell' function existed. The
> name change happened to source Fri Dec 13 09:52:05 2013 in commit
> 7a6c0e35415c4a173d101336029262f3a09abb91. After the name change, the function 
> existed and a block
> using "shell" would execute!

Yes, I originally use "sh" too. But at some time point, I saw an article
somewhere, then I switched to "shell". I forget the specific reason
already.

> The "shell" language specifier, as far as I can tell, was never really 
> intentionally supported.
> Instead, it just happened to work. It happened to work because, as far back 
> as the first
> org-babel-sh.el commit, the process buffer is created using the `shell' 
> function. I don't know the
> history of `shell', but presently the documentation says,
>
> Program used comes from variable ‘explicit-shell-file-name’,
>  or (if that is nil) from the ESHELL environment variable,
>  or (if that is nil) from ‘shell-file-name’.
>
> That is, the `shell' command falls back to `shell-file-name'. I assume that 
> `shell' has always had
> that, or a similar, fallback. The `shell-file-name' is a direct path to an 
> executable. This means
> that when "shell" is used for the language, `shell-file-name' is called and 
> **any** startup script,
> such as .bash_profile or .bashrc, is called. The prompt could be set to 
> **anything** and Emacs will
> never know, and can never know, what the prompt is without the user 
> explicitly informing Emacs.
>
> Aside from the code change which allowed "shell" to work, "official" support 
> of "shell" comes from
> Org manual commit 9d072ad67517875069f913315d762c9bb1e9c3ec, Sun Dec 17 
> 11:06:05 2017 (for example,
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.org?id=f7aa8c19f5170dbf09538686fb569f9b60acbd6c#n18410).
> This appears unconnected with the code change. The addition to the manual 
> happened 4 years after the
> code name change and none of the commit messages around the time of code 
> change suggest that "shell"
> was intended to work as a language. In fact, I found this email from Eric 
> Schulte (creator of Babel
> and maintainer at the time of the code change) which suggests that "shell" is 
> in fact not supported
> or intented as a language 
> (https://lists.gnu.org/archive/html/emacs-orgmode/2013-12/msg00294.html):
>
> In response to the statement,
>
> "a coworker used "#+BEGIN_SRC shell" where he should have written 
> "#+BEGIN_SRC sh"
>
> Eric says,
>
> "[The suggested work around] would protect against this particular error"
>
> #+end_longwinded_explanation
>
> Regardless of whether "shell" was intended to work as a Babel language, the 
> fact remains that it
> does work and that it's been advertised in the manual (at least) for 6 years. 
> What are the pros and
> cons of 

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

[Ihor Radchenko]

Ihor Radchenko  writes:

> We can try the attached patch. Yet another edge case in comint, it
> appears.

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

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a8a516ba330fe8c435334030ffbe371b8c80c877
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=866ed1a3c5c37cad243085f9a8fa904970e4d614

Further, I tried to incorporate Pareto's suggestion about secondary
prompt and cleaned up the original GHCi tests.

With the attached set of patches (first one is Bruno's original patch),
I get all the tests reliably passing, except the tests left as
:expected-result failed.

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.

The first category of tests fails because `org-babel-interpret-haskell'
simply cannot distinguish between :results value and :results output.
Someone familiar with GHC should handle this problem. For example, by
wrapping :results output code in such a way that output is discarded in
the GHCi comint buffer.

The second category of tests fails because haskell-mode uses a fixed
"*haskell*" comint buffer name. As I suggested in another message, a
viable approach could be renaming the original "*haskell*" buffer to
something else in `org-babel-haskell-initiate-session'. Again, someone
more familiar with haskell-mode should judge if such option is truly
viable.

>From 1273b5b415fa420e718645452bc75bc7a9407af5 Mon Sep 17 00:00:00 2001
Message-Id: <1273b5b415fa420e718645452bc75bc7a9407af5.1679653723.git.yanta...@posteo.net>
From: Bruno BARBIER 
Date: Fri, 18 Nov 2022 20:14:20 +0100
Subject: [PATCH 1/4] 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 ( 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 

Re: orgmode website contributions to translations? -- Was: It's possible, to translate the org-mode website into Spanish?

[General discussions about Org-mode.]

Ihor Radchenko  writes:

> Ruijie Yu  writes:
>
>> I can help translate to zh_CN occasionally, seeing that the repo is not
>> updated too frequently.  Although I might need some pointers on how to
>> start a new translation, and how sourcehut works. :)
>
> Just clone the repo from https://git.sr.ht/~bzg/orgweb and send patches
> to this mailing list as usual. See
> https://orgmode.org/worg/org-contribute.html
>
>> Also, does this need a copyright assignment?  FTR, I am still waiting
>> for a counter-signature from FSF on Emacs.
>
> AFAIK, yes. For the official Org page (not WORG), we require FSF
> copyright assignment.
>
> Note that FSF should usually reply within 5 working days. If not, you
> follow up once, wait another 5 working days, and then let us know - we
> can push them stronger.

Thanks, now I have cloned the repo locally.

While reading the files, there is one immediate issue I have found: on
current orgweb master (feed1160), line 153 of /index.org has a broken
link on how to contribute to worg.  Similarly, /ja/index.org has the
same broken link, whereas /fr/index.org has a different paragraph in its
place so no broken links there.

--
Best,


RY

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

[Ihor Radchenko]

ParetoOptimalDev  writes:

>> comint-prompt-regexp: ^[[:alnum:].*_() |λ]*> \|^λ?>
>> Output: ghci| ghci| ghci| ghci| ghci| 6
>>
>> Note "|".
>
> You can fix this by sending `set :prompt-cont ""`. Here is a
> demonstration:

I think you meant `:set prompt-cont ""`.

It is a good idea, thanks!
We use similar approach in ob-shell.

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

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

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]

thank you for that.  surely now fewer users will be confused.

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

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.


On 3/23/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> perhaps we could have 2 names: one for the priority cookie setting and
>> one for whatever the agenda does.
>
> This is a good idea. Thanks!
>
> See the attached fix making use of Samuel's suggestion.
>
>


-- 
The Kafka Pandemic

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

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]

[feel free to ignore those suggestions as surely there are better
alterntives, and urgency is still good.]

On 3/23/23, Samuel Wales  wrote:
> thank you for that.  surely now fewer users will be confused.
>
> 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
>
> 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.
>
>
> On 3/23/23, Ihor Radchenko  wrote:
>> Samuel Wales  writes:
>>
>>> perhaps we could have 2 names: one for the priority cookie setting and
>>> one for whatever the agenda does.
>>
>> This is a good idea. Thanks!
>>
>> See the attached fix making use of Samuel's suggestion.
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

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

Re: [fr] allow overriding the likely unintended consequence of org-export-with-tasks

[Samuel Wales]

On 3/23/23, Ihor Radchenko  wrote:
> You can set org-export-with-tasks to '("REF"). It will make Org export
> REF todo keywords, but not other todo keywords.

this is true, but not relevant to my request.  it won't as a practical
matter work around or solve the problem.

i wrote: "i would prefer the top level of the subtree to be exported
in all cases, because i have asked org to export.  it does not matter
what kw it is set to or what the variable is set to."

of course, my request could be optional if desired, but agian it is
not useful to ask to export something and get a no-op.

as for ref [or blank] i do not want to have to keep or temporarily set
a todo kw, or lack of one, at the top level, merely to allow
exporting.  this would be requiring me to maintain a keyword that i do
not want there in the outiine, OR a keyword that i do not want ther
ein the variable, both of which could have various consequences both
semantic and user-comprehension-oriented.

i find that having the feature apply also on the top level heading is
1] pointless, because there is no point in exporting nothing, and 2]
unexpected/surprising because you just SAID to export the subtree!,
and 3] unintended for similar reasons.

in case anybody wants the no-op, making it optional to export the top
level heding would be copacetic.

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