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

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> $-based economy employs 25$-like prices.

Gotcha!  I think I am fully convinced now.  :)

Rudy
-- 
"Mathematics takes us still further from what is human into the region
of absolute necessity, to which not only the actual world, but every
possible world, must conform."
-- Bertrand Russell, 1902

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

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

[ParetoOptimalDev]

I forgot to mention you can also set the prompt as well to something
simple like `:set prompt "> "`.

> Ihor Radchenko  writes:
>
>> Part of the problem is that haskell-mode appears to use non-standard
>> prompt:
>>
>> 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:
>
> GHCi, version 9.0.2: https://www.haskell.org/ghc/  :? for help
> ghci> ghci> :set prompt-cont ""
> ghci> :{
> let { x = 2
> ; y = 3
> }
> in x*y
> :}
> 6
> ghci> 

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

[ParetoOptimalDev]

Ihor Radchenko  writes:

> Part of the problem is that haskell-mode appears to use non-standard
> prompt:
>
> 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:

GHCi, version 9.0.2: https://www.haskell.org/ghc/  :? for help
ghci> ghci> :set prompt-cont ""
ghci> :{
let { x = 2
; y = 3
}
in x*y
:}
6
ghci> 

Re: [PATCH] Async evaluation in ob-shell

[Matt]

  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.

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

[Bastien Guerry]

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.

-- 
 Bastien Guerry

Re: [ANN] Looking for new maintainers for ox-html.el

[Bastien Guerry]

Ihor Radchenko  writes:

> "Dr. Arne Babenhauserheide"  writes:
>
>> Ihor Radchenko  writes:
>>
>>> I have been informed that our current ox-html maintainer will no longer
>>> able to perform his duties in full extent.
>
> [ This was actually not accurate - TEC, the current ox-html maintainer,
>   is still around. However, he was recently focusing on developing new
>   features for ox-html and other parts of Org. So, we can still use help
>   from another maintainer with bug fixes. ]

Yes, it's always good to have more than one maintainer.

>>> We thus need volunteers to help maintaining Org HTML export library -
>>> lisp/ox-html.el
>>
>> I depend on ox-html for my personal website. I would be glad to help.
>
> Thanks for volunteering!
> Upon Bastien's confirmation, you can follow
> https://orgmode.org/worg/org-maintenance.html#maintainer-role and create
> an account with write access to Org git sources.

I confirm Arne's FSF records are in order.

Thanks for your help!

-- 
 Bastien Guerry

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

[Matt]

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

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

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. 
 

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

[Matt]

  On Thu, 23 Mar 2023 07:12:29 -0400  Christopher M. Miles  wrote --- 
 
 > #+begin_src bash :session "*ob-shell-bash*" :async t
 > sleep 30
 > echo "hello, world"
 > #+end_src
 > 
 > #+RESULTS[(2023-03-23 19:14:15) 23f9ad130f7a1268e21821c6baaea2b057c70d3e]:
 > : org_babel_sh_prompt> hello, world
 > 
 > Still got a prompt. Is this intended? I think the output should be kept 
 > clean because the result
 > output might be used as input for other source blocks as data.

I absolutely agree.  This is a bug.  

It should be an easy fix on my end but, in case there are details I'm 
overlooking, this specific example can use the following workaround:

#+begin_src bash :session "*ob-shell-bash*" :async t
sleep 30 && echo "hello, world"
#+end_src

To explain what's going on...

#+begin_longwinded_explanation
Shell output is filtered for prompts which should be removed before inserting 
the results.  The issue is that the filter assumes the prompt starts at the 
beginning of the line.  When sleep is called, it returns nothing and the next 
prompt appears on the same line:

sh-5.1$ PROMPT_COMMAND=;PS1="org_babel_sh_prompt> ";PS2=
org_babel_sh_prompt> echo 
'ob_comint_async_shell_start_770d9c8f-deda-4359-aee9-a433a75a5e0d'
echo "1"
sleep 3
echo "2"
echo 'ob_comint_async_shell_end_770d9c8f-deda-4359-aee9-a433a75a5e0d'
ob_comint_async_shell_start_770d9c8f-deda-4359-aee9-a433a75a5e0d
org_babel_sh_prompt> 1
org_babel_sh_prompt> org_babel_sh_prompt> 2
org_babel_sh_prompt> 
ob_comint_async_shell_end_770d9c8f-deda-4359-aee9-a433a75a5e0d

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))
 
 (defun org-babel-sh-evaluate (session body  params stdin cmdline)
   "Pass BODY to the Shell process in BUFFER.
#+end_longwinded_explanation

Ability to add logo to HTML export

[Vladimir Alexiev]

Some projects have a logo, which one may want to add to the beginning of a
HTML document.
Eg like this (before authors and Title):
[image: image.png]

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

And also this in my org setup:

(put 'org-html-preamble 'safe-local-variable 'stringp)

I looked at

(org-export-define-backend 'html
  :options-alist
(:html-preamble nil "html-preamble" org-html-preamble)

and the help for org-export-options-alist:
this word "html-preamble" corresponds to:

OPTION is a string that could be found in an #+OPTIONS: line.

So I tried this, but it had no effect"

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

Minor note: normally, I distribute the standard variables between preamble
and postamble as follows:

(setq
 org-html-preamble-format '(("en" "Author: %a (%e)
Date: %d"))
 org-html-postamble t   ; was 'auto which inserts author,
date: but I want those in preamble
 org-html-postamble-format  '(("en" "Exported by %c
%v"))
)

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Christopher M. Miles]

This is an acceptable solution for large width image. I propose this RFC too.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [PATCH] Make predicates non-interactive

[Max Nikulin]

On 23/03/2023 11:22, Aaron L. Zeng wrote:

+++ b/lisp/org.el

...

@@ -15475,7 +15474,6 @@ If Org mode thinks that point is actually inside
  an embedded LaTeX environment, return t when the environment is math
  or let `texmathp' do its job otherwise.
  `\\[org-cdlatex-mode-map]'"
-  (interactive)
(cond
 ((not (derived-mode-p 'org-mode)) (apply orig-fun args))
 ((eq this-command 'cdlatex-math-symbol)


Might it be source of problems since `texmathp' is declared as 
interactive and the purpose of this function is to be around advice? 
Likely it is a false alarm since the functions have no interactive 
arguments.

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[General discussions about Org-mode.]

Small nit, in case you are about to install it.

> +It the actual width is too wide, limit it according to
> +~org-image-max-width~.

"It" -> "If".

--
Best,


RY

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

[Ihor Radchenko]

Samuel Wales  writes:

> when org-export-with-tasks is set to nil, tasks will not be exported,
> but non-task entries will.
>
> you can make non-exported todo items and notes about your exported text.
>
> * REF this is the top level of the subtree
> *** NOTE this is just a note and should not be exported
> *** but this i want to export of course
>
> you can specify other values for the variable that have a similar
> effect.  let's use nil for this example.
>
> this is highly useful, but in my case, there is an unintended
> consequence.   the REF todo kw prevents anything from being exported,
> for subtree or region export.  not exporting is not a useful behavior.
> 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.

You can set org-export-with-tasks to '("REF"). It will make Org export
REF todo keywords, but not other todo keywords.

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

Re: org-ctags land grab

[Max Nikulin]

On 23/03/2023 17:49, Ihor Radchenko wrote:

Nick Dokos writes:


It is off until org-ctags is loaded. *When* it is loaded, it runs
`(org-ctags-enable)' and the behavior changes.


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.


Notice *incompatible*.

On 23/03/2023 17:49, Ihor Radchenko wrote:

Nick Dokos writes:

As you see, `help--load-prefixes' loads `org-ctags'.

...

This sounds like Emacs bug.


I would say that it sounds like a fix for
https://debbugs.gnu.org/60085
`help-enable-autoload' is not fully obeyed

See also:

Max Nikulin to emacs-orgmode… Re: Does variable 'org-goto-interface' 
exist? Wed, 14 Dec 2022 21:20:07 +0700. 
https://lists.orgmode.org/6dd5a4fe-b99b-73a9-26dd-bb522ff1b...@gmail.com



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.

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

[RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Ihor Radchenko]

Alexis Gallagher  writes:

>   •   the image is automatically resized to maintain aspect ratio and 
> fit horizontally with a civilized margin, so that I can resize my emacs 
> window without the image disappearing or swamping the other content. 

We cannot automatically resize images in Elisp. At least, I know no good
way to do it reliably.

But we can try to improve the defaults for wide images.

See the tentative patch.

>From 180e322c2c79ea88d87f908299a5c0e69c47a7b2 Mon Sep 17 00:00:00 2001
Message-Id: <180e322c2c79ea88d87f908299a5c0e69c47a7b2.1679581960.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 23 Mar 2023 15:31:33 +0100
Subject: [PATCH] lisp/org.el: Allow limiting inline image width

* lisp/org.el (org-image-max-width): New custom variable controlling
max inline image width.
(org--create-inline-image): Use the new variable.
* doc/org-manual.org (Images):
* etc/ORG-NEWS (New customization ~org-image-max-width~ limiting the
displayed inline image width): Document the new variable.
---
 doc/org-manual.org | 20 +---
 etc/ORG-NEWS   | 15 +++
 lisp/org.el| 29 -
 3 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 37fd3df14..3d729bdf6 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11495,14 +11495,19 @@ ** Images
 
 
   #+vindex: org-image-actual-width
+  #+vindex: org-image-max-width
   #+cindex: @samp{ORG-IMAGE-ACTUAL-WIDTH}, property
   By default, Org mode displays inline images according to their
-  actual width.  You can customize the displayed image width using
+  actual width, but no wider than ~fill-column~ characters.
+
+  You can customize the displayed image width using
   ~org-image-actual-width~ variable (globally) or
   =ORG-IMAGE-ACTUAL-WIDTH= property (subtree-level)[fn:: The width can
   be customized in Emacs >= 24.1, built with imagemagick support.].
   Their value can be the following:
   - (default) Non-nil, use the actual width of images when inlining them.
+It the actual width is too wide, limit it according to
+~org-image-max-width~.
   - When set to a number, use imagemagick (when available) to set the
 image's width to this value.
   - When set to a number in a list, try to get the width from any
@@ -11512,8 +11517,17 @@ ** Images
 #+end_example
 and fall back on that number if none is found.
   - When set to nil, try to get the width from an =#+ATTR.*= keyword
-and fall back on the original width if none is found.
-
+and fall back on the original width or ~org-image-max-width~ if
+none is found.
+
+  ~org-image-max-width~ limits the maximum displayed image width, but
+  only when the image width is not set explicitly.  Possible maximum
+  width can be set to:
+  - (default) ~fill-column~, limit width to ~fill-column~ number of
+characters.
+  - ~window~, limit width to current window width.
+  - integer number, limit width that specified number of pixels.
+  - nil, do not limit the width.
 
 #+vindex: org-cycle-inline-images-display
 Inline images can also be displayed when cycling the folding state.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4d45e6507..2611cc570 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -24,6 +24,21 @@ consider [[https://gitlab.com/jackkamm/ob-python-mode-mode][ob-python-mode-mode]
 has been ported to.
 
 ** New and changed options
+*** New customization ~org-image-max-width~ limiting the displayed inline image width
+
+New custom variable ~org-image-max-width~ limits the maximum inline
+image width, but only when the inline image width is not explicitly
+set via ~org-image-actual-width~, =ORG-IMAGE-ACTUAL-WIDTH= property,
+or =#+ATTR*= keyword.
+
+By default, when ~org-image-actual-width~ is set to t,
+~org-image-max-width~ takes effect.  Its default value is set to
+~fill-column~, limiting the image previews to ~fill-column~ number of
+characters.
+
+To fall back to previous defaults, where the inline image width is not
+constrained, set ~org-image-max-width~ to nil.
+
 *** New ~org-cite-natbib-export-bibliography~ option defining fallback bibliography style
 
 ~natbib~ citation export processor now uses
diff --git a/lisp/org.el b/lisp/org.el
index 20e6ea6d9..43d659536 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15096,6 +15096,24 @@ (defcustom org-image-actual-width t
 	  (list :tag "Use #+ATTR* or a number of pixels" (integer))
 	  (const :tag "Use #+ATTR* or don't resize" nil)))
 
+(defcustom org-image-max-width 'fill-column
+  "When non-nil, limit the displayed image width.
+This setting only takes effect when `org-image-actual-width' is set to
+t or when #+ATTR* is set to t.
+
+Possible values:
+- `fill-column' :: limit width to `fill-column'
+- `window'  :: limit width to window width
+- number:: limit width to number in pixels
+- nil :: do not limit image width"
+  :group 'org-appearance
+  :package-version '(Org . "9.7")

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

[Daniel Kraus]

Ihor Radchenko  writes:

>> Or rather something like:
>>
>> (defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
>>   "Evaluate EXPANDED code block using cider.
>> When CLJS-P is non-nil, use a cljs connection instead of clj.
>> The PARAMS from Babel are not used in this function."
>
> I like the second variant better.

Thanks.
I pushed the fix.

Cheers,
  Daniel

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

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Thank you so much for taking the time to explain the problem to me; I
> now understand it much better!  That said, if the heuristic is
>
>$  ...MATH...  $- 
>
> then `$3 or =$5' to `$3-$5' would not cause any troubles, right?  What
> common, real-world use-case would trigger problems with this simple
> heuristic?

$-based economy employs 25$-like prices.

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

Re: [PATCH] Make predicates non-interactive

[Ihor Radchenko]

"Aaron L. Zeng"  writes:

> Predicates like `org-first-sibling-p' are no use when called
> interactively, and should not appear in the M-x prompt.
>
> TINYCHANGE
> ---
>  lisp/org.el | 3 ---
>  1 file changed, 3 deletions(-)

Thanks!
Applied, onto main. I added appropriate CHANGELOG entries to the commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=04087be6b

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

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

[Ihor Radchenko]

Daniel Kraus  writes:

> Ihor Radchenko  writes:
>
>> Now, the docstring appears to be a bit confusing:
>>
>> (defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
>>   "Evaluate EXPANDED code block with PARAMS using cider.
>> When CLJS-P is non-nil, use a cljs connection instead of clj."
>>
>> It would be useful to mention that PARAMS argument is unused.
>
> Should I go with your initial suggestion and just replace it with _?
> Like
>
> (defun ob-clojure-eval-with-cider (expanded _  cljs-p)
>   "Evaluate EXPANDED code block using cider.
> When CLJS-P is non-nil, use a cljs connection instead of clj."
>
> But then someone will maybe wonder why there is unused argument?
>
> Or rather something like:
>
> (defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
>   "Evaluate EXPANDED code block using cider.
> When CLJS-P is non-nil, use a cljs connection instead of clj.
> The PARAMS from Babel are not used in this function."

I like the second variant better.

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

> diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
> index 9e7b45a89..eab8ea935 100644
> --- a/lisp/ob-shell.el
> +++ b/lisp/ob-shell.el
> @@ -269,12 +269,22 @@ var of the same value."
>   (set-marker comint-last-output-start (point))
>   (get-buffer (current-buffer)))
>  
> +(defconst ob-shell-async-indicator "echo 'ob_comint_async_shell_%s_%s'"
> +  "Session output delimiter template.
> +See `org-babel-comint-async-indicator'.")
> ...

I see that you pushed this onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f7aa8c19f5170dbf09538686fb569f9b60acbd6c
May you also document this new feature in ORG-NEWS and in
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: [PATCH] org-user-idle-seconds: Add support for logind

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> From 1cc887d1378839c3322c93ebb5a524499b8d3073 Mon Sep 17 00:00:00 2001
> From: Nathaniel Nicandro 
> Date: Wed, 22 Mar 2023 14:54:57 -0500
> Subject: [PATCH] lisp/org-clock.el: Add support for logind

Thanks!
Applied, onto main. I added a changelog entry for ORG-NEWS.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=693df6fd9

I also updated our FSF copyright status records.
https://git.sr.ht/~bzg/worg/commit/dd4222ac

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

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

[Daniel Kraus]

Ihor Radchenko  writes:

> Now, the docstring appears to be a bit confusing:
>
> (defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
>   "Evaluate EXPANDED code block with PARAMS using cider.
> When CLJS-P is non-nil, use a cljs connection instead of clj."
>
> It would be useful to mention that PARAMS argument is unused.

Should I go with your initial suggestion and just replace it with _?
Like

(defun ob-clojure-eval-with-cider (expanded _  cljs-p)
  "Evaluate EXPANDED code block using cider.
When CLJS-P is non-nil, use a cljs connection instead of clj."

But then someone will maybe wonder why there is unused argument?

Or rather something like:

(defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
  "Evaluate EXPANDED code block using cider.
When CLJS-P is non-nil, use a cljs connection instead of clj.
The PARAMS from Babel are not used in this function."


Writing good docstrings is hard :D

Cheers,
  Daniel

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

[Christopher M. Miles]

Matt  writes:

>   On Wed, 22 Mar 2023 23:25:50 -0400  Christopher M. Miles  wrote --- 
>  > 
>  > The ob-shell async result output contains the shell prompt. I think it
>  > should not be captured.
>  > 
>  > #+begin_src shell :session "test2" :async t
>  > sleep 30
>  > echo "hello, world"
>  > #+end_src
>  > 
>  > #+RESULTS[(2023-03-23 11:19:22) 461ed5de684f6e619890709175ec73e80b67b2d6]:
>  > : bash-5.2$ hello, world
>
> Thanks for reporting this.
>
> Try using for the babel language whatever shell the variable 
> `shell-file-name' gives.  For example, if `shell-file-name' is /bin/bash, do 
> this:
>
> #+begin_src bash :session "test2" :async t
> sleep 1
> echo "hello, world"
> #+end_src
>
> Is there a reason you're using "shell" instead of one of the shells listed in 
> `org-babel-shell-names'?

Using language identities like bellowing:

#+begin_src sh :session "*ob-shell*" :async t
sleep 30
echo "hello, world"
#+end_src

#+RESULTS[(2023-03-23 19:14:12) dd777a237986481833c08eb5eceac717576eddb7]:
: org_babel_sh_prompt> hello, world

#+begin_src bash :session "*ob-shell-bash*" :async t
sleep 30
echo "hello, world"
#+end_src

#+RESULTS[(2023-03-23 19:14:15) 23f9ad130f7a1268e21821c6baaea2b057c70d3e]:
: org_babel_sh_prompt> hello, world

#+begin_src zsh :session "*ob-shell-zsh*" :async t
sleep 30
echo "hello, world"
#+end_src

#+RESULTS[(2023-03-23 19:14:17) 2bb44d96c2e482a90c5a89bdde0b64d0319663a1]:
: % 

 
:  
: % 

 
:  
: hello, world
: % 

 
:  

Still got a prompt. Is this intended? I think the output should be kept clean 
because the result
output might be used as input for other source blocks as data.

Maybe error in my Org babel settings? Bellowing is my system and variable 
values:

#+begin_src emacs-lisp
system-type
#+end_src

#+RESULTS[(2023-03-23 19:27:13) 7df8395169a77d83cb6a5a6efc2223d412813efa]:
: darwin

#+begin_src emacs-lisp
shell-file-name
#+end_src

#+RESULTS[(2023-03-23 19:26:33) e6fed18a9a543dd6320385ee715d9ee68b464a04]:
: /opt/homebrew/bin/bash

#+begin_src emacs-lisp
org-babel-sh-prompt
#+end_src

#+RESULTS[(2023-03-23 19:30:12) f6efc29dba5be2171eba0a25abec19908fb1c6be]:
: org_babel_sh_prompt> 

#+begin_src emacs-lisp
org-babel-shell-names
#+end_src

#+RESULTS[(2023-03-23 19:27:27) 360d6d35db3eb48deb664349eed34b7541923ca2]:
| sh | bash | zsh | fish | csh | ash | dash | ksh | mksh | posh |

#+begin_src emacs-lisp :results pp
org-babel-shell-set-prompt-commands
#+end_src

#+RESULTS[(2023-03-23 19:27:44) 910fbbafc6fea4a1846f5a31f8b7dd102eca4928]:
: (("fish" . "function fish_prompt\necho \"%s\"\nend")
:  ("csh" . "set prompt=\"%s\"\nset prompt2=\"\"")
:  ("posh" . "function prompt { \"%s\" }")
:  (t . "PROMPT_COMMAND=;PS1=\"%s\";PS2="))

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

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:

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

>From d6881c39c91beabdc0bfb29d6dc8a81202a84e40 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Thu, 23 Mar 2023 12:20:19 +0100
Subject: [PATCH] org-agenda: Rename sorting "priority" to "urgency"

* lisp/org-habit.el (org-habit-get-priority): Rename to
`org-habit-get-urgency'.
* lisp/org-compat.el (org-habit-get-priority): Obsolete the old name.
* lisp/org-agenda.el (org-agenda-sorting-strategy):
* lisp/org-agenda.el (org-search-view):
(org-agenda-get-todos):
(org-agenda-get-timestamps):
(org-agenda-get-progress):
(org-agenda-get-deadlines):
(org-agenda-get-scheduled):
(org-agenda-get-blocks):
(org-entries-lessp): Alter priority-up and priority-down sorting
strategies to only sort by actual priority.  Rename the previous
composite sorting rank to urgency, corresponding to the new urgency-up
and urgency-down sorting strategies.  Store the new rank in 'urgency
text property.  Update the docstrings accordingly.  Use `urgency-down'
in place of `priority-down' in the default sorting strategy.
(org-set-sorting-strategy): Use `urgency-down' in place of
`priority-down'.
* etc/ORG-NEWS ("Priority" used to sort items in agenda is renamed to
"urgency"): Document the change.
* doc/org-manual.org (Sorting of agenda items): Update manual using
"urgency" term in place of confusing "priority".

Thanks to Samuel Wales for the idea how to fix the inconsistency.

Reported-by: Jonas Olofsson 
Link: https://orgmode.org/list/26396316-1201-4d88-9d81-c87ddda88...@apple.com
---
 doc/org-manual.org | 16 +--
 etc/ORG-NEWS   | 15 ++
 lisp/org-agenda.el | 72 +-
 lisp/org-compat.el |  2 ++
 lisp/org-habit.el  |  4 +--
 5 files changed, 73 insertions(+), 36 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 37fd3df14..ff06694a8 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9419,16 +9419,16 @@ *** Sorting of agenda items
   time-of-day specification.  These entries are shown at the beginning
   of the list, as a /schedule/ for the day.  After that, items remain
   grouped in categories, in the sequence given by ~org-agenda-files~.
-  Within each category, items are sorted by priority (see
-  [[*Priorities]]), which is composed of the base priority (2000 for
-  priority =A=, 1000 for =B=, and 0 for =C=), plus additional
-  increments for overdue scheduled or deadline items.
+  Within each category, items are sorted by urgency, which is composed
+  of the base priority (see [[*Priorities]]; 2000 for priority =A=, 1000
+  for =B=, and 0 for =C=), plus additional increments for overdue
+  scheduled or deadline items.
 
 - For the TODO list, items remain in the order of categories, but
-  within each category, sorting takes place according to priority (see
-  [[*Priorities]]).  The priority used for sorting derives from the
-  priority cookie, with additions depending on how close an item is to
-  its due or scheduled date.
+  within each category, sorting takes place according to urgency.  The
+  urgency used for sorting derives from the priority cookie, with
+  additions depending on how close an item is to its due or scheduled
+  date.
 
 - For tags matches, items are not sorted at all, but just appear in
   the sequence in which they are found in the agenda files.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4ca13af17..2b055a76a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,21 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** "Priority" used to sort items in agenda is renamed to "urgency"
+
+Previously, ~priority-up~ and ~priority-down~ in
+~org-agenda-sorting-strategy~ used a composite rank depending on
+item's priority (=[#A]=, =[#B]=, =[#C]=, etc) and overdue time to
+order agenda items (see "11.4.3 Sorting of agenda items" section of
+Org manual).
+
+Now, this composite rank is renamed to =urgency= and the relevant
+sorting strategies are renamed to ~urgency-up~ and ~urgency-down~.
+~priority-up~ and ~priority-down~ sort by item's priority only.
+
+Users relying on the previous composite ranking should adjust their
+agenda sorting settings.
+
 *** =python-mode.el (MELPA)= support in =ob-python.el= is removed
 
 =python-mode.el= support has been removed from =ob-python.el=.  The
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 892d88a77..263f242d4 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -85,7 +85,7 @@ (declare-function org-habit-insert-consistency-graphs
 		  "org-habit" ( line))
 (declare-function org-is-habit-p "org-habit" ( pom))
 (declare-function org-habit-parse-todo "org-habit" ( pom))
-(declare-function org-habit-get-priority "org-habit" (habit  

Re: org-ctags land grab

[Ihor Radchenko]

Nick Dokos  writes:

>> It is off by default.
>
> It is off until org-ctags is loaded. *When* it is loaded, it runs
> `(org-ctags-enable)' and the behavior changes.

Sure. This is not by itself a big deal. A number of Elisp libraries,
including built-in Emacs libraries are loaded with side effects.

> Now I'm not loading it explicitly, but nevertheless, *somebody* does
> because it goes ahead and mucks with my `org-open-link-functions'.

If somebody is loading org-ctags explicitly, it is their choice to use
this library. Instructions how to modify its behaviour are in the top
comment, including instructions how to deal with modified link opening.

> Debugger entered--setting org-open-link-functions to (org-ctags-find-tag): 
>   debug--implement-debug-watch(org-open-link-functions (org-ctags-find-tag) 
> set nil)
>   set-default(org-open-link-functions (org-ctags-find-tag))
>   add-hook(org-open-link-functions org-ctags-find-tag t)
>   org-ctags-enable()
>   byte-code("\300 \210\301\302!\207" [org-ctags-enable provide org-ctags] 2)
>   load("org-ctags" noerror nomessage)
>   help--load-prefixes((("org-" "ox-latex" "ox" "org-src" "org-refile" 
> "org-protocol" "org-plot" "org-pcomplete" "org-mouse" "org-macs" "org-list" 
> "org-keys" "org-habit" "org-faces" "org-ctags" ...
> ...
> As you see, `help--load-prefixes' loads `org-ctags'. If you look at
> the `help-definition-prefixes' radix tree, `org-ctags' is subsumed
> under the `org-' prefix, so any lookup with that prefix will end up
> loading it (and therefore enabling it). The reason it does not happen
> in 28.2 is that it is only under the `org-ctags` prefix.

This sounds like Emacs bug.
Note that you can disable this behaviour by setting
`help-enable-completion-autoload' and/or `help-enable-autoload'.

> It seems to me that `org-ctags' should be registered under the
> `org-ctags' prefix only, just like in 28.2 (the registration is in
> `org-loaddefs.el' but I don't know how it ends up there. I guess
> `org-fixup.el' is doing it, but I didn't chase it any further).

We did nothing to change how autoloads are being generated. However,
newer Emacs uses a different autoloading system.

> I also think that loading `org-ctags' should not automatically enable
> it: it should require the user to explicitly run `org-ctags-enable' to
> do that. That way, if there is a mechanism that loads it
> surreptitiously, it wouldn't cause the confusion that it causes
> now. That would require documentation changes, but it would avoid
> unpleasant surprises, and preserve some toes even if users load it
> accidentally. Eventually, it might be nice to provide a disabling
> function as well, although the workaround in the SE post works well
> enough for now. Maybe the thing to do is to turn it into a proper
> minor mode.

Yes and no. It will indeed avoid this unpleasant surprise, but it will
create an unpleasant surprise for users who do use org-ctags, which is
the problem.

Note that we discussed loading side effects in
https://list.orgmode.org/orgmode/tn4ql0$bu2$1...@ciao.gmane.io/

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

Bruno Barbier  writes:

> +(ert-deftest ob-haskell/let-multilines-1 ()
> +  "Local definitions on multiple lines."
> +  :expected-result :failed
> +  (should (equal 6 (test-ob-haskell-ghci "" "
> +:{
> + let { x=2
> + ; y=3
> + }
> + in x*y
> +:}
> +"

Part of the problem is that haskell-mode appears to use non-standard
prompt:

comint-prompt-regexp: ^[[:alnum:].*_() |λ]*> \|^λ?>
Output: ghci| ghci| ghci| ghci| ghci| 6

Note "|".

We may want to either report this upstream or modify
`org-babel-interpret-haskell' further where it extends
`comint-prompt-regexp'.

> +(ert-deftest ob-haskell/ghci-info ()
> +  "The ghci meta command ':info' ."
> +  (should (equal "repeat :: a -> [a]-- Defined in ‘GHC.List’"
> + (test-ob-haskell-ghci ":results output" ":info repeat"

On my system, the output contains different number of spaces in
"[a]-- ". It appears to be system-dependent. Looks like test's
fault.

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

Re: Friendly exchange of thoughts: citations and LaTeX

[Fraga, Eric]

Pedro,

maybe start by showing an example of where \jobname does not work with
org while working with LaTeX directly?  I have never used this LaTeX
command and know nothing about it.

Secondly, what is the problem with bibliography file names being
expanded?

eric
-- 
: Eric S Fraga, with org release_9.6.1-224-g8ae8a8 in Emacs 30.0.50