Re: [ANN] Org mode 9.7 is out

[Juergen Fenn]

Am 02.06.24 um 23:17 Uhr schrieb Juergen Fenn:
>>> There is one more thing: My Emacs init time has got slightly longer
>>> since updating to Org 9.7.1 from ~1.9 to 2.273441 seconds. I
>>> re-installed Org and the depending packages, as you recommended
>>> (org-contrib, org-static-blog). No more changes, same setup as before.
>> As it usually goes with the config, it can be anything.
>> Use profiler to reveal the cause.
>>
>> One blind guess could be that Org mode loads more built-in libraries
>> (like yank-media library) now. So, loading might be slower. Not sure
>> about 0.4 seconds slower.
>>
>> In future versions, I have a plan to rework the way Org mode loads,
>> aiming for faster load times among other things. (this is annoyingly
>> difficult task; like 300+-commits-and-no-end-in-sight level annoying)
> No need to worry about that.

I just would like to thank you for reducing init time with

Org mode version 9.7.6 (9.7.6-7a4527 @
/Users/juergenfenn/.emacs.d/elpa/org-9.7.6/)

It is now down to 1.865443 seconds on

GNU Emacs 30.0.60 (build 1, aarch64-apple-darwin23.5.0, NS
appkit-2487.60 Version 14.5 (Build 23F79)) of 2024-06-29

Same configuration here as before.

Regards,
Jürgen.

Re: [BUG] Unexpected behaviour of TAB in table depending on font family [9.6.15 (release_9.6.15 @ /snap/emacs/current/usr/share/emacs/29.4/lisp/org/)]

[Ihor Radchenko]

Giovanni Pavolini  writes:

> I can confirm that in org 9.7.6 the behaviour for the font "Ubuntu" is the
> expected one.

Thanks for the update!
Closing.
Canceled.

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

Re: [BUG] Unexpected behaviour of TAB in table depending on font family [9.6.15 (release_9.6.15 @ /snap/emacs/current/usr/share/emacs/29.4/lisp/org/)]

[Giovanni Pavolini]

Thanks Ihor for your quick response.

I can confirm that in org 9.7.6 the behaviour for the font "Ubuntu" is the
expected one.

On Sat, 29 Jun 2024 at 08:34, Ihor Radchenko  wrote:

> Giovanni Pavolini  writes:
>
> > I wanted to customize my default font by `(custom-set-faces '(default
> > ((t(:family "Ubuntu")`. Then, after `M-x org-table-create` the TAB
> > started creating a cell to the left of the one it should have jumped to
> > (see a video here (webmd video of the screencast):
> >
> https://u.pcloud.link/publink/show?code=XZVXhe0Z2K8AAQBKOwQH7uE7LkNtHYGlHQTy
> > ). The expected behaviour is that TAB only jumps to the next cell,
> > without creating additional ones. The actual behaviour is, depending on
> > the family font used, it does create an additional cell. Not every
> > font causes the unexpected behaviour.
>
> [ Side note: we prefer text descriptions on the mailing lists. Videos,
>   especially uploaded to third-party servers, may disappear after
>   several years, leading to losing access to discussion context. Also,
>   not every reader can access non-text information (consider blind users) ]
>
> From the video the reproducer is the following:
>
> 1. emacs -q
> 2. Create a new Org file
> 3. M-x org-table-create  2x2 
> 4. a TAB table TAB a TAB table
> 5. Observe table filled with "a" and "table" cells
>
> | a | table |
> |---+---|
> | a | table |
>
> 6. M-: (custom-set-faces '(default ((t (:family "Noto Sans CJK HK")
> 7. Move point to the end of buffer
> 8. Repeat steps 3-4
> 9. Observe
>
> | a |   | table |
> |---+---+--|
> |   | a | table |
>
> I was able to reproduce using Org mode version shipped with Emacs 29.
> I was unable to reproduce using the latest Org mode version.
>
> May you please try to upgrade Org mode? Does the problem disappear then?
>
> P.S.
> Attaching the list of working/non-working fonts to keep it available for
> future reference.
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Reference to non-existent variable `header-arguments-alist'

[Ihor Radchenko]

Stefan Kangas  writes:

>>> ./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for
>>
>> It is not referring to a variable, but to ARGUMENTS slot in the INFO
>> list. INFO is expected to have the same format as the return value of
>> `org-babel-get-src-block-info'.
>
> So would something like the below be appropriate?
> ...
>  INFO may provide the values of these header arguments (in the
> -`header-arguments-alist' see the docstring for
> -`org-babel-get-src-block-info'):
> +`header-arguments' alist; see `org-babel-get-src-block-info'):

I do not think so.  `org-babel-get-src-block-info' is not actually
specifying that "arguments" is an alist.  And it never says "header-arguments".
Both this docstring and also `org-babel-get-src-block-info's
need to be updated.

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

Re: Reference to non-existent variable `header-arguments-alist'

[Stefan Kangas]

Ihor Radchenko  writes:

> Stefan Kangas  writes:
>
>> There is a reference to `header-arguments-alist', but I can't find any
>> such variable in the tree.
>>
>> ./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for
>
> It is not referring to a variable, but to ARGUMENTS slot in the INFO
> list. INFO is expected to have the same format as the return value of
> `org-babel-get-src-block-info'.

So would something like the below be appropriate?

diff --git a/lisp/org/ob-core.el b/lisp/org/ob-core.el
index 727ace84463..4b6c3b5e6bd 100644
--- a/lisp/org/ob-core.el
+++ b/lisp/org/ob-core.el
@@ -2514,8 +2514,7 @@ org-babel-insert-result
   allowed for inline source blocks.

 INFO may provide the values of these header arguments (in the
-`header-arguments-alist' see the docstring for
-`org-babel-get-src-block-info'):
+`header-arguments' alist; see `org-babel-get-src-block-info'):

 :file --- the name of the file to which output should be written.

Re: bash source code block: problem after ssh commands

[Max Nikulin]

On 18/11/2023 15:04, Max Nikulin wrote:

On 17/11/2023 17:17, Ihor Radchenko wrote:

I see bash vs. dash difference with public key authorization, so no need 
for password prompts. I have not figured out how to construct an example 
without ssh since this command *may* read stdin, but does not do it in a 
same way as e.g. cat(1).


I expect the following couple of lines simulates ssh behavior fairly 
well (besides maybe macOS with its old GPLv2 bash).


bash -c 'read -t 0.5 -r line; printf "read: %s\n" "$line"'
printf 'printf\n'


cat ssh-script.sh
ssh -p  127.0.0.1 'echo foo>/tmp/foo'
echo done

[...]

dash 
[...]
I am unsure if POSIX specifies exact behavior of shell when commands are 
read from stdin.


It is a bug in dash that should be fixed in next version. Behavior of 
bash is correct despite some users may expect "done" printed.



наб  to d...@vger.kernel.org
[PATCH] input: preadfd: read standard input byte-wise
Tue, 13 Dec 2022 23:17:32 +0100


"dash: Incorrectly slurps script from stdin (POSIX compliance issue)"

And curiously ssh command was involved as well

"Debugging a mystery: ssh causing strange exit codes?"

A citation from POSIX (XCU):


STDIN in /sh - shell, the standard command language interpreter/

When the shell is using standard input and it invokes a command that
also uses standard input, the shell shall ensure that the standard
input file pointer points directly after the command it has read when
the command begins execution. It shall not read ahead in such a manner
that any characters intended to be read by the invoked command are
consumed by the shell (whether interpreted by the shell or not) or
that characters that are not read by the invoked command are not seen
by the shell. When the command expecting to read standard input is
started asynchronously by an interactive shell, it is unspecified
whether characters are read by the command or interpreted by the
shell.


I do not think any script should rely on this behavior, it is better to 
explicitly use "here documents"


cat 
"I'm reading a file line by line and running ssh or ffmpeg, only the 
first line gets processed!"


So either "ssh -n" or "ssh I agree with Ihor that ob-shell should not feed scripts to shell stdin 
(maybe besides the case when it is explicitly requested by the user 
through some header arguments).


It seems, shell sessions

is a different case unrelated to script files.

Re: [PATCH] Ability to specify :html-head as a function

[Nathan Nichols]

Ok, here's a patch. Please let me know if this is acceptable or not.

On Sat, Jun 22, 2024 at 8:33 AM Ihor Radchenko  wrote:

> Nathan Nichols  writes:
>
> >> This looks like a copy-paste of `org-element-normalize-string'.
> >> Why not simply calling `org-element-normalize-string'?
> >
> > I changed it at one point, but then changed it back and didn't realize
> that
> > it was ultimately unchanged.
> > Here's a patch that uses `org-element-normalize-string` instead.
>
> Thanks!
>
> > +(defun org-html-normalize-str-or-fn (input  trailing)
> > +  "If INPUT is a string, it is passed to `org-element-normalize-string'.
>
> Ideally, the first line of the docstring should fully describe what
> function does.
>
> Maybe you can add something like
>
>Normalize INPUT function or string.  Return a string or nil.
>
> > +If INPUT is a function, it is applied to arguments TRAILING, and the
> result is
> > +passed to `org-element-normalize-string'."
> > +  (let ((s (if (functionp input) (format "%s" (apply input trailing))
> input)))
> > +(org-element-normalize-str s)))
>^org-element-normalize-string
>
> TRAILING name is confusing because it is not what one expects to be a
> name of function arguments.  Maybe
>
> (defun org-html-normalize-str-or-fn (input  args)
>
>
> Also, you need to update docstrings and type definitions for
> `org-html-head' and `org-html-head-extra', update the Org manual, and
> announce the new allowed values in etc/ORG-NEWS.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
From 3b3ad45f506c3446fda0d7702913f1badfd20d46 Mon Sep 17 00:00:00 2001
From: Nate Nichols 
Date: Thu, 20 Jun 2024 14:25:35 -0400
Subject: [PATCH] Added ability to specify :html-head as a string or function

---
 etc/ORG-NEWS |  6 ++
 lisp/ox-html.el  | 28 +---
 testing/lisp/test-ox-html.el |  6 ++
 3 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b9f51667d..59aceea02 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -92,7 +92,13 @@ This results in an error such as:
 Runtime error near line 2: attempt to write a readonly database (8)
 [ Babel evaluation exited with code 1 ]
 #+end_example
+*** ~org-html-head~ and ~org-html-head-extra~ can now be specified as functions
 
+Previously, ~org-html-head~ and ~org-html-head-extra~ could only be
+specified directly as strings.  Now, they can be set to functions that
+accept the project p-list and return a string.  This makes it possible
+to dynamically generate the content of the resulting ~~ tag in
+the resulting HTML document.
 
 ** Miscellaneous
 *** Trailing =-= is now allowed in plain links
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d1687cf5a..6119bc82a 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1531,7 +1531,8 @@ style information."
 This variable can contain the full HTML structure to provide a
 style, including the surrounding HTML tags.  You can consider
 including definitions for the following classes: title, todo,
-done, timestamp, timestamp-kwd, tag, target.
+done, timestamp, timestamp-kwd, tag, target.  Can be a string, or
+a function that accepts the project p-list and returns a string.
 
 For example, a valid value would be:
 
@@ -1556,19 +1557,23 @@ or for publication projects using the :html-head property."
   :group 'org-export-html
   :version "24.4"
   :package-version '(Org . "8.0")
-  :type 'string)
+  :type '(choice (string :tag "Literal text to insert")
+ (function :tag "Function evaluating to a string")))
 ;;;###autoload
 (put 'org-html-head 'safe-local-variable 'stringp)
 
 (defcustom org-html-head-extra ""
   "More head information to add in the HTML output.
 
-You can set this on a per-file basis using #+HTML_HEAD_EXTRA:,
-or for publication projects using the :html-head-extra property."
+You can set this on a per-file basis using #+HTML_HEAD_EXTRA:, or
+for publication projects using the :html-head-extra property.
+Can be a string, or a function that accepts the project p-list
+and returns a string."
   :group 'org-export-html
   :version "24.4"
   :package-version '(Org . "8.0")
-  :type 'string)
+  :type '(choice (string :tag "Literal text to insert")
+ (function :tag "Function evaluating to a string")))
 ;;;###autoload
 (put 'org-html-head-extra 'safe-local-variable 'stringp)
 
@@ -2001,6 +2006,15 @@ INFO is a plist used as a communication channel."
 		  org-html-meta-tags))
   ""
 
+(defun org-html-normalize-str-or-fn (input  args)
+  "Normalize INPUT function or string.  Return a string or nil.
+If INPUT is a string, it is passed to
+`org-element-normalize-string'.  If INPUT is a function, it is
+applied to arguments ARGS, and the result is passed to
+`org-element-normalize-string'."

Re: Reference to non-existent variable `header-arguments-alist'

[Ihor Radchenko]

Stefan Kangas  writes:

> There is a reference to `header-arguments-alist', but I can't find any
> such variable in the tree.
>
> ./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for

It is not referring to a variable, but to ARGUMENTS slot in the INFO
list. INFO is expected to have the same format as the return value of
`org-babel-get-src-block-info'.

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

Re: [BUG] Unexpected behaviour of TAB in table depending on font family [9.6.15 (release_9.6.15 @ /snap/emacs/current/usr/share/emacs/29.4/lisp/org/)]

[Ihor Radchenko]

Giovanni Pavolini  writes:

> I wanted to customize my default font by `(custom-set-faces '(default
> ((t(:family "Ubuntu")`. Then, after `M-x org-table-create` the TAB
> started creating a cell to the left of the one it should have jumped to
> (see a video here (webmd video of the screencast):
> https://u.pcloud.link/publink/show?code=XZVXhe0Z2K8AAQBKOwQH7uE7LkNtHYGlHQTy
> ). The expected behaviour is that TAB only jumps to the next cell,
> without creating additional ones. The actual behaviour is, depending on
> the family font used, it does create an additional cell. Not every
> font causes the unexpected behaviour.

[ Side note: we prefer text descriptions on the mailing lists. Videos,
  especially uploaded to third-party servers, may disappear after
  several years, leading to losing access to discussion context. Also,
  not every reader can access non-text information (consider blind users) ]

>From the video the reproducer is the following:

1. emacs -q
2. Create a new Org file
3. M-x org-table-create  2x2 
4. a TAB table TAB a TAB table
5. Observe table filled with "a" and "table" cells

| a | table |
|---+---|
| a | table |

6. M-: (custom-set-faces '(default ((t (:family "Noto Sans CJK HK")
7. Move point to the end of buffer
8. Repeat steps 3-4
9. Observe

| a |   | table |
|---+---+--|
|   | a | table |

I was able to reproduce using Org mode version shipped with Emacs 29.
I was unable to reproduce using the latest Org mode version.

May you please try to upgrade Org mode? Does the problem disappear then?

P.S.
Attaching the list of working/non-working fonts to keep it available for
future reference.



test.org
Description: Lotus Organizer

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

Reference to non-existent variable `header-arguments-alist'

[Stefan Kangas]

There is a reference to `header-arguments-alist', but I can't find any
such variable in the tree.

./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:
>
>> Feedback appreciated!
>
> Thanks for the update!
> ...
>> I've finally implemented a solution to what I've discussed previously,
> ...

It has been a while since the last update in this thread.
Nathaniel, may I know if you are still working on this?

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

Re: [PATCH] initialize org-babel-tangle-lang-exts to nil

[Tom Gillespie]

> More accurate approach would be using (eval-after-load 'ob-tangle
> ...). This is what is being done in WIP branch that addresses many
> similar problems across Org mode:
> https://git.sr.ht/~yantar92/org-mode/log/feature/refactor-deps-v2
> https://git.sr.ht/~yantar92/org-mode/commit/6bcb99413e18324367fa27f8572955d5a92092ce

Got it. Will keep an eye on this. Thanks!
Tom

Re: [PATCH] initialize org-babel-tangle-lang-exts to nil

[Ihor Radchenko]

Tom Gillespie  writes:

>Here is a fix for bad init values for org-babel-tangle-lang-exts.
> Details in the patch commit message.
> ...
> Subject: [PATCH] initialize org-babel-tangle-lang-exts to nil
> ...
> org-bable-tangle-lang-exts should be initialized to nil and not as a
> void variable, if it is not already initialized then this will cause a
> void-variable error immediately when it is used in add-to-list
>
> this corrects the original addition in
> 4a0e5cf88f684db775ccf43dc5edc2e8754a2d92 as well as other files that
> followed the pattern

Thanks for the patch, but it is not a correct way to fix the problem.
`org-babel-tangle-lang-exts' is a custom option defined in
ob-tangle.el. If you define it as a global variable separately, there
will be subtle bugs depending on the order of loading of ob-tangle and
the other files defining the same variable.

Currently, it is expected that babel backends *must* be loaded after
ob-tangle.

More accurate approach would be using (eval-after-load 'ob-tangle
...). This is what is being done in WIP branch that addresses many
similar problems across Org mode:
https://git.sr.ht/~yantar92/org-mode/log/feature/refactor-deps-v2
https://git.sr.ht/~yantar92/org-mode/commit/6bcb99413e18324367fa27f8572955d5a92092ce

Canceled.

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