Re: [Bug] isearch errors when org-fold-core-style is 'overlays

[Samuel Wales]

more below.

On 12/29/22, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> possibly related: are links still not searchable with iserch without
>> being in reveal mode or similar?  [9.4 here.)
>
> Unrelated.
> The reported issue is related to the new org-fold implementation.

ok didn't men to lower s/n.

tanks for your patience.

>
> The old issue with searching links is known. It is simply because
> isearch does not support searching inside invisible text. And links are
> abbreviated by applying invisible text property to the hidden parts.

>
> You either upgrade or set isearch-invisible to t.


i look forward to it if it is fixed.  fwiw i vaguely thought the issue
was overlays or so, as the default value is 'open.  but it sounds like
you are saying this was fixed in emacs or org.  i do have a vague
inkling that it was fixed in future emacs or org.


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


-- 
The Kafka Pandemic

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

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Matt]

  On Thu, 29 Dec 2022 06:08:59 -0500  Ihor Radchenko  wrote --- 
 
 > Does it mean that you are willing to maintain lisp/ob-shell.el?
 > We usually give write access to the maintainers and regular
 > contributors. AFAIR, you previously contributed to WORG but not to Org
 > core.

 You're correct, I've not contributed to core.  I would love to maintain 
lisp/ob-shell.el.  I'm expecting life changes in the coming months and can't 
anticipate how that will affect my time.  Would it be a problem if I need to 
step down as maintainer for a period?

 > > From: Matt Trzcinski m...@excalamus.com>
 > > 
 > > [fn:1] Session name is a string and not a variable (such as
 > > `session-name').  This is because `org-babel-execute:sh' produces a
 > > type error when the session name is defined with a variable.  The
 > > source of the error appears to be the `params' symbol in
 > > `org-babel-execute:sh'.  `params' does not evaluate as a variable as
 > > expected–it evaluates as a symbol.  However, `org-babel-execute:sh' is
 > > defined within a function factory which makes it difficult to debug.
 > > Hard code the test name for now and refactor it later once
 > > `org-babel-execute:sh` is refactored.
 > 
 > There is nothing wrong here. `org-babel-execute-src-block' takes care
 > about parameter processing making sure that :session value is always a
 > string.
 
Originally the test used "yes" for a comparison string and the shell it ran in. 
  I changed "yes" to be the test name because when it was "yes", I didn't know 
what test had produced it.  However, the problem with the test name being hard 
coded as a string is that if the function name changes, the test string may get 
out of sync.  More on this below.

 > > +;; TODO refactor into macro.  Currently violates (elisp) Coding
 > > +;; Conventions and is hard to debug.
 > >  (defun org-babel-shell-initialize ()
 > >"Define execution functions associated to shell names.
 > 
 > Could you please elaborate? Which particular convention does it violate?
 > What is hard to debug?

(elisp) Coding Conventions says,

"• Constructs that define a function or variable should be macros, not
 functions, and their names should start with ‘define-’.  The macro
 should receive the name to be defined as the first argument.  That
 will help various tools find the definition automatically.  Avoid
 constructing the names in the macro itself, since that would
 confuse these tools."

The `org-babel-shell-initialize' function defines *all* the 
`org-babel-execute:XXX' functions given by `org-babel-shell-names' (sh, bash, 
zsh, etc.).

Because `org-babel-shell-initialize' is a function factory, you can't easily 
examine or modify their definitions.  `C-h f org-babel-execute:sh' jumps to the 
top of lisp/ob-shell.el.  Changing the definition requires reevaluating the 
definition for all the execute functions (or first changing 
`org-babel-shell-names').

This was a problem for me when I wanted to make the session name string for 
`test-ob-shell/session' the test name (mentioned above).  In the test, when I 
replaced the session name string with a variable containing the string, 
`org-babel-execute:sh' failed with a type error.  I couldn't get the variable 
to evaluate (with backquote and comma or otherwise).  Without an explicit 
function definition or a macro to expand, I found it hard to debug/experiment 
with (and so left the test name as a hard coded string).

 > >  (ert-deftest test-ob-shell/dont-insert-spaces-on-expanded-bodies ()
 > >"Expanded shell bodies should not start with a blank line unless
 > > -the body of the tangled block does."
 > > +the strings of the tangled block does."
 > 
 > What does "strings of the tangled block" refer to? The previous variant
 > is a lot more clear for me.

I believe this is a query-replace error. Good catch!

 > > +(ert-deftest test-ob-shell/generic-uses-no-arrays ()
 > > +  "Test generic serialization of array into a single string."
 > > +  (org-test-with-temp-text
 > > +  (test-ob-shell-multiline-string
 > > +   "#+NAME: sample_array"
 > > +   "| one   |"
 > > +   "| two   |"
 > > +   "| three |"
 > 
 > Why do you need `test-ob-shell-multiline-string' here?
 > Can simply type-in the string directly, as the rest of tests do.

I probably don't need it and am happy to remove it.An older version of the 
function was more complex and made sense as a separate function (or so I 
thought).  My aim was to make the test strings easy to read so that it's 
clearer what's being tested (i.e. not write multi-line strings on a single 
line).  I could use concat and add "\n" to the end of each line.  Or, simply 
write out the string-join.  Maybe there's another way to write multi-line 
strings that I'm not aware of in Elisp, maybe something like Python's 
triple-quote?

 > > +(require 'org-test (expand-file-name "../org-test.el"))
 > 
 > I am unsure here. What will happen if you run this file from
 > 

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Berry, Charles]

Bastien et al,

> On Dec 29, 2022, at 8:00 AM, Bastien Guerry  wrote:
> 
> I think it would make sense to convert Elisp lists into R lists
> directly.  Jeremie, would you be okay with this?
> 


Perhaps there are some hiccups. 

The R `data.frame' type is a list with some added attributes. In that list each 
top level element is a *column* in the data.frame.

In the elisp list produced by rendering a table as in `:var mydf=atab', each 
top level element is a sequence containing one *row* of the table `atab'.

So if elisp lists are to be converted to R lists, ob-R will need to know 
whether the list came from a table to decide whether to render top level 
elements as list elements or as data.frame rows.

---

There might be some useful applications for converting org lists to R lists and 
vice versa. But it looks like a significant amount of effort to get it right.

Best,

Chuck
 

Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting

[András Simonyi]

Dear All,

On Thu, 29 Dec 2022 at 11:14, Ihor Radchenko  wrote:
> LGTM!
> Feel free to push upstream.

thanks Ihor, I've pushed the changes to main as commit
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=29103fc60
best wishes,
András

Re: For your consideration: Extending org-info-js with additional hooks

[David O'Toole]

Ok, I will get started on this :)

On Thu, Dec 29, 2022 at 10:38 AM Bastien Guerry  wrote:

> Ihor Radchenko  writes:
>
> > Bastien, since the activity around org-info-js revived after a long
> > delay, should we move the code out of worg into a separate repo?
>
> Yes, definitely.  David, would you like to set up a new repository
> with the code from the org-info-js directory here:
>
> https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js
>
> You can try to excise the directoy while preserving its history,
> although I would not make it mandatory for org-info-js to live in
> a new, separate repository.
>
> Once this is done, we'll see how to remove org-info-js from Worg.
>
> Thanks!
>
> --
>  Bastien
>

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Bastien Guerry  writes:

> I've skimmed through the discussion but I'm not entirely clear about
> the situation.
>
> Has the situation changed between 9.5 and 9.6?  Tom first message
> seems to suggest it did, but etc/ORG-NEWS does not say.

I considered this change as a bugfix. Though it was more user-facing
than I anticipated.

What changed: The prompt previously displayed on code block evaluation
is now also displayed when expanding header arguments:

#+begin_src emacs-lisp :var x = (message "pwned!")
(concat x "foo")
#+end_src

Before Org 9.6:
1. "pwned!" is displayed
2. Query to evaluate code block is displayed

Org 9.6:
1. Query to evaluate (message "pwned!") is displayed
2. If confirmed, it is evaluated
3. Query to evaluate the whole code block is displayed

> Whether it changed or not, what is the problem in 9.6?

The problem is that Org now displays more queries.

> How does the patch solves this problem?

It allows disabling these new queries about lisp evaluation outside
code blocks without disabling code block eval confirmation completely.

I later suggested disabling the queries by default - mimicking the pre
9.6 behaviour yet keeping the ability for concerned users enable the
extra confirmation.

> Is it a temporary change while we wait for a better change?

Yes. Ideally, we need to improve the code evaluation query. It should
allow confirming evaluation in bulk and add some code blocks/files to
whitelist. Similar to `org--confirm-resource-safe'.

> In particular, I'm not sure I understand why this should be added to
> 9.6.1---I'm not opposed to it, I just try to understand.

A concern have been expressed that more queries may annoy users and
drive them towards setting `org-confirm-babel-evaluate' to nil globally.
Upon doing this, the future more flexible security queries may be not
used by such users.

> Also, org-confirm-babel-evaluate-table-cell seems more explicit than
> org-confirm-babel-evaluate-cell.

But it will not be accurate. The query is now displayed upon executing
`org-babel-read' -- cell refers to Elisp code "cell" here. Not to a
table cell.

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Max Nikulin]

On 29/12/2022 22:58, Bastien Guerry wrote:

From: Tom Gillespie
Date: Sat, 10 Dec 2022 12:11:17 -0800
Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom
  variable

...

Has the situation changed between 9.5 and 9.6?


Yes, it has. In 9.6 C-c C-c for

#+begin_src elisp :var v1=(identity #o755) v2=(identity #o444) 
v3=(identity #o600)

  (list v1 v2 v3)
#+end_src

issues 4 queries if elisp code should be executed (3 variables and the 
src block body). In 9.5 variable values evaluated before the single 
prompt (so "no" did not prevent execution of some code).

Re: [MAINTENANCE] Org orphanage?

[Bastien]

Ihor Radchenko  writes:

> Bastien  writes:
>
>> I think it is a very good idea and a natural evolution of org-contrib,
>> thanks for suggesting this.
>> ...
>> We can announce this along with the Org 9.6 release.
>
> So, we now have https://orgmode.org/worg/org-orphanage.html
>
> It is very bare bones.

:)

> We can add the following:
>
> 1. Mention orphanage at https://orgmode.org/worg/org-contribute.html
>Probably, in a visible way, as a div box.

I added a mention early on in the page, but perhaps this can be made
more prominent.

> 2. Add org-contrib

Done.

> 3. Link to orphanage from https://sr.ht/~bzg/org/

Done.

> 4. Maybe add a separate section to updates.orgmode.org

Not done, as updates.orgmode.org will be deprecated soon.

> 5. We can offer to move orphaned repositories to sr.ht under our control
>and mention that we can do minimal maintenance then.

I'm not sure about this.

Another idea is to rename org-contrib to org-orphanage and to offer to
add *.el files there?  This way we make it very obvious that these files
receive minimal maintenance while allowing users to install them through
GNU ELPA.

WDYT?

-- 
 Bastien

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Bastien Guerry]

I think it would make sense to convert Elisp lists into R lists
directly.  Jeremie, would you be okay with this?

Ihor Radchenko  writes:

> Or I may need to put a special clause regarding ob-R into the NEWS
> item.

... that way we don't need such a special clause regarding ob-R.

2 cts,

-- 
 Bastien

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Bastien Guerry]

Ihor Radchenko  writes:

> Tom Gillespie  writes:
>
>> From 4a78e1b5ea98dee569ff690037c661ab5c300194 Mon Sep 17 00:00:00 2001
>> From: Tom Gillespie 
>> Date: Sat, 10 Dec 2022 12:11:17 -0800
>> Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom
>>  variable
>
> Bastien, may you please take a look at this discussion?

I've skimmed through the discussion but I'm not entirely clear about
the situation.

Has the situation changed between 9.5 and 9.6?  Tom first message
seems to suggest it did, but etc/ORG-NEWS does not say.

Whether it changed or not, what is the problem in 9.6?

How does the patch solves this problem?

Is it a temporary change while we wait for a better change?

In particular, I'm not sure I understand why this should be added to
9.6.1---I'm not opposed to it, I just try to understand.

Also, org-confirm-babel-evaluate-table-cell seems more explicit than
org-confirm-babel-evaluate-cell.

Thanks!

-- 
 Bastien

Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting

[Bastien Guerry]

Ihor Radchenko  writes:

> I don't think we have an example.
> Probably, we can create etc/org-news-images folder, set :DIR: property
> in etc/ORG-NEWS to that folder, and then use attachments.

I suggest we don't go in that direction: I'd rather keep etc/ORG-NEWS
as a self-contained file.

Can we use Worg instead for such examples?

> CCing Bastien in case if he has any objections/ideas.

Thanks for adding me in the loop.

-- 
 Bastien

Re: For your consideration: Extending org-info-js with additional hooks

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, since the activity around org-info-js revived after a long
> delay, should we move the code out of worg into a separate repo?

Yes, definitely.  David, would you like to set up a new repository
with the code from the org-info-js directory here:

https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js

You can try to excise the directoy while preserving its history,
although I would not make it mandatory for org-info-js to live in
a new, separate repository.

Once this is done, we'll see how to remove org-info-js from Worg.

Thanks!

-- 
 Bastien

Re: Babel (scheme): Evaluation errors are not shown

[Bastien Guerry]

Hi Rudolf and Ihor,

Ihor Radchenko  writes:

> Rudolf Adamkovič  writes:
>
>> Ihor Radchenko  writes:
>>
>>> Note that we currently have no maintainer for ob-scheme and hence can
>>> only provide very limited support. New features are hard for us
>>> without experience with scheme and geiser.
>>
>> I volunteer to maintain `ob-scheme'.

I just added you as the maintainer of ob-scheme.el.

You are already in the list of FSF-copyrighted contributors on Worg.

Thank you very much!

-- 
 Bastien

Re: org-insert-structure-template

[Ihor Radchenko]

Ihor Radchenko  writes:

> C-c C-x , is actually not available (it is bound to timer).
> I went with C-c C-x s.
>
> See the attached patch.

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5bc5add32

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

Re: [PATCH] Display ?? for missing citations on export (was: [BUG] Exporting non-existent citations in oc-basic [9.6-pre (release_9.5.5-989-gd972cf @ /home/yantar92/.emacs.d/straight/build/org/)])

[Ihor Radchenko]

Ihor Radchenko  writes:

> The problem with error has been solved in another patch.
>
> However, the non-existing keys are exported awkwardly as "(, )".
>
> I suggest approaching the missing citations similar to LaTeX and
> highlight them with ??: (??, ) by default.
>
> See the attached patch.
>
> WDYT?

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fbd08a0d9

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

[PATCH] Throw an error when bibliography field is not properly parsed (was: [PATCH] oc-basic.el: Fix wrong type for the editors field when parsing JSON.)

[Ihor Radchenko]

Ihor Radchenko  writes:

>> As explained in the ChangeLog entry, this points to a more general issue 
>> where
>> `org-cite-basic--get-field' is expected to return nil or a string, but calls
>> `org-cite-basic--get-entry' that may return an association list. I am not 
>> sure
>> how to fix that since it means converting anything that
>> `org-cite-basic--get-entry' may return into a string.
>
> Non-string can only be for JSON bibliographies for fields that are not
> supported. `org-cite-basic--get-field' can probably return nil in such
> scenarios.

I am attaching tentative patch that will make
`org-cite-basic--get-field' throw an error when the filed value is not a
string.

I would appreciate testing.

Best,
Ihor

>From 9fe6284fdc7ceeb0e0aa8e5a58b6828ca415b6b2 Mon Sep 17 00:00:00 2001
Message-Id: <9fe6284fdc7ceeb0e0aa8e5a58b6828ca415b6b2.1672323564.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 29 Dec 2022 17:18:35 +0300
Subject: [PATCH] org-cite-basic--get-field: Throw an error on non-nil field
 values

* lisp/oc-basic.el (org-cite-basic--get-field): Throw an error when
the field value is not a string.  Document the new behavior.

Link: https://orgmode.org/list/87edsnsocj.fsf@localhost
---
 lisp/oc-basic.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index 01e314bfd..8e69db03c 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -332,7 +332,9 @@ (defun org-cite-basic--get-field (field entry-or-key  info raw)
 
 Return value may be nil or a string.  If current export back-end is derived
 from `latex', return a raw string instead, unless optional argument RAW is
-non-nil."
+non-nil.
+
+Throw an error if the field value is non-string and non-nil."
   (let ((value
  (cdr
   (assq field
@@ -343,6 +345,8 @@ (defun org-cite-basic--get-field (field entry-or-key  info raw)
entry-or-key)
   (_
(error "Wrong value for ENTRY-OR-KEY: %S" entry-or-key)))
+(unless (and value (stringp value))
+  (error "Non-string bibliography field value: %S" value))
 (if (and value
  (not raw)
  (org-export-derived-backend-p (plist-get info :back-end) 'latex))
-- 
2.38.1



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

Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

[Bastien]

Ihor Radchenko  writes:

> Marked for future removal in ob-python.el.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=21741a469

Thanks!

-- 
 Bastien

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, could you please check Matt's copyright paperwork record in
> FSF?

Matt's copyright paperwork are OK, I added him as FSF-copyrighted
contributor on Worg.

> Does it mean that you are willing to maintain lisp/ob-shell.el?

Until Matt wants to be the maintainer for ob-shell.el, I suggest Ihor
applies the patches.

> In order for you to get admitted to Emacs group, we will first need to
> reach out to Emacs maintainers authorizing your write access.

Matt, you reached out to the Emacs maintainers and they asked me
whether I should give you write access: I told them to wait until you
confirm you want to the be the ob-shell.el maintainer.  If you don't,
I think sharing patches that another Org maintainer applies is enough.

Thanks!

-- 
 Bastien

Re: [FR] Add support for racket images in org-babel

[Ihor Radchenko]

dalanicolai  writes:

>> You likely need to extend `org-babel-scheme--table-or-string' to
>> understand Image: type.
>>
>
> It looks to me that when `org-babel-execute:scheme` gets executed, then the
> result will not get inserted as a link, as that would require the results
> type 'file', right?
> From the manual , it
> seems to me that using the 'file' type is required to get the result
> inserted as a link.
>
> However, I can not see how the code does the following as explained in the
> manual.
>
> The manual  states
> (under Type/file):
>
>> If ‘file’ header argument is missing, Org generates the base name of the
>> output file from the name of the code block, and its extension from the ‘
>> file-ext’ header argument. In that case, both the name and the extension
>> are mandatory.
>>
> suggesting that a file gets written also when there is no :file header
> argument.

> But from the `and` condition here
> 
> in `org-babel-execute-src-block`, it looks to me that a file is only
> written when a :file argument is provided (via the `with-temp-file` that
> follows within the 'when file ...').
> Anyway, this I only found when trying to find out how the result gets
> formatted as a link.

One can use :results file link without :file header argument.

#+begin_src bash :results file link
echo -n "~/Downloads/wallpaper.png"
#+end_src

#+RESULTS[9c92ca9d7a3cce34ddcc4714ea917225be60e080]:
[[file:/home/yantar92/Downloads/wallpaper.png]]

I now clarified this on main
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b2adb68af

Hope it clarifies how to achieve what you want without advice.

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

Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> I am leaning towards announcing the deprecation in the coming
>> release.
>
> Agreed, let's move forward in this direction for the release.

Marked for future removal in ob-python.el.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=21741a469

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

Re: [Bug] isearch errors when org-fold-core-style is 'overlays

[Ihor Radchenko]

Ihor Radchenko  writes:

> Part of the problem is some undocumented behaviour of isearch.
> I will need to consult Emacs devs before fixing.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60399

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

Re: Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Unfortunately, I do not see an easy solution without hitting parser
> performance. Our general approach is to avoid forward-parsing as much as
> possible with an exception to paired brackets (because Elisp allows
> parsing paired brackets fast using C-level code). However, AFAIK, there
> is no easy way to parse brackets that are not single symbols. "\(" is
> impossible to match using `scan-lists'.

One interesting idea to consider is using PEG (third-party ELPA package).
The above examples with paired parenthesis can be parsed using the
following PEG:

(with-peg-rules
((no-paren (not "\\(") (not "\\)") (any))
 (no-paren-expr (+ no-paren))
 (paren-expr "\\(" (* (or no-paren-expr paren-expr)) "\\)"))
  (peg-run (peg paren-expr)))

PEG is not built-in though, so we cannot use it in Org.

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

Re: ob-shell intentions and paperwork (was Bash results broken?)

[Ihor Radchenko]

Bastien, could you please check Matt's copyright paperwork record in
FSF?

Matt  writes:

>   On Wed, 21 Dec 2022 01:17:50 -0500  Matt  wrote --- 
>
>  > Currently, though, I'm refactoring the ob-shell tests to remove dependency 
> on ob-shell-test.org and to stop the suite from littering. 
>
> Done.  Branched off bugfix, 12e10eb0d, and refactored test-ob-shell.el.  See 
> attached patches.

Better use main for development.
bugfix is for... bugfixes :)

>  >  After that, I intend to incorporate the worg examples as tests.
>
> This is probably a good place for me to pause and get feedback before writing 
> more code. 

Sure. See below.

> I just got the signed paperwork back from Craig and am waiting to be admitted 
> to the Emacs group on Savannah.

Does it mean that you are willing to maintain lisp/ob-shell.el?
We usually give write access to the maintainers and regular
contributors. AFAIR, you previously contributed to WORG but not to Org
core.

In order for you to get admitted to Emacs group, we will first need to
reach out to Emacs maintainers authorizing your write access.

Meanwhile, once Bastien confirms your copyright status, I can apply
patches on your behalf.

> From ecdb71afa00ca137b4faa737393cb027907a7f9f Mon Sep 17 00:00:00 2001
> From: Matt Trzcinski 
> Date: Tue, 20 Dec 2022 13:51:26 -0500
> Subject: [PATCH 01/20] test-ob-shell.el: Remove mixed tabs and spaces
>
> * test-ob-shell.el: Convert tabs to spaces.
>
> Change made under the premise that one or the other is better than
> both.

We generally avoid whitespace-only changes. They tend to generate merge
conflicts. We do whitespace changes alongside with other changes in the
code only - this minimizes merge conflicts.
See https://orgmode.org/list/874jvkz5k8@bzg.fr

>  (ert-deftest test-ob-shell/dont-error-on-empty-results ()
> -  "Was throwing an elisp error when shell blocks threw errors and
> -returned empty results."
> -  (should (null (org-babel-execute:sh "ls NoSuchFileOrDirectory.txt" nil
> +  (should (null (org-babel-execute:sh nil nil

nil BODY argument for `org-babel-execute:sh' is not supported.
Better use explicit empty body: "".

It is also a good idea to add docstrings to the tests for completeness.

> [fn:1] Session name is a string and not a variable (such as
> `session-name').  This is because `org-babel-execute:sh' produces a
> type error when the session name is defined with a variable.  The
> source of the error appears to be the `params' symbol in
> `org-babel-execute:sh'.  `params' does not evaluate as a variable as
> expected–it evaluates as a symbol.  However, `org-babel-execute:sh' is
> defined within a function factory which makes it difficult to debug.
> Hard code the test name for now and refactor it later once
> `org-babel-execute:sh` is refactored.

There is nothing wrong here. `org-babel-execute-src-block' takes care
about parameter processing making sure that :session value is always a
string.

> +;; TODO refactor into macro.  Currently violates (elisp) Coding
> +;; Conventions and is hard to debug.
>  (defun org-babel-shell-initialize ()
>"Define execution functions associated to shell names.

Could you please elaborate? Which particular convention does it violate?
What is hard to debug?

>  (ert-deftest test-ob-shell/dont-insert-spaces-on-expanded-bodies ()
>"Expanded shell bodies should not start with a blank line unless
> -the body of the tangled block does."
> +the strings of the tangled block does."

What does "strings of the tangled block" refer to? The previous variant
is a lot more clear for me.

> +(ert-deftest test-ob-shell/generic-uses-no-arrays ()
> +  "Test generic serialization of array into a single string."
> +  (org-test-with-temp-text
> +  (test-ob-shell-multiline-string
> +   "#+NAME: sample_array"
> +   "| one   |"
> +   "| two   |"
> +   "| three |"

Why do you need `test-ob-shell-multiline-string' here?
Can simply type-in the string directly, as the rest of tests do.

> +(require 'org-test (expand-file-name "../org-test.el"))

I am unsure here. What will happen if you run this file from
default-directory not the same with file location?

Also, the repetitive patches changing names + killing error buffer for
individual tests can be merged into a single patch.

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

Re: Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> (I don't understand why you quoted the part of my message related to
> things which work as expected, though.)

(because I skipped them mentally :])

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

Re: Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Alain . Cochard]

Ihor Radchenko writes on Thu 29 Dec 2022 10:04:

 > This is to be expected because [...]

Thanks for taking the time to explain.

(I don't understand why you quoted the part of my message related to
things which work as expected, though.)

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting

[Ihor Radchenko]

András Simonyi  writes:

> Dear All,
> I have attached a new version of the patch with added ascii "illustrations".
> best wishes,
> András

LGTM!
Feel free to push upstream.

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

Re: Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Version used: release_9.6-149-g554935 
>
> With an org file containing only
>
>#+begin_export latex
>$x \text{foo $y$}$
>
>\(x \text{foo \(y\)}\)
>
>$x \text{foo \(y\)}$
>
>\(x \text{foo $y$}\)
>#+end_export
>
> the pdf generated upon latex export gives as expected, i.e., with 'x'
> and 'y' in mathematical font.

This is to be expected because of how Org parser works.

In particular, $-style math is tricky because Org allows "$" both as
math delimiter and also as standalone symbol. There are trade-offs.

For the \(...\), it is because Org parser does not understand nesting:
it takes first opening \( and match it with the first closing \) - thus
what you observe.

Unfortunately, I do not see an easy solution without hitting parser
performance. Our general approach is to avoid forward-parsing as much as
possible with an exception to paired brackets (because Elisp allows
parsing paired brackets fast using C-level code). However, AFAIK, there
is no easy way to parse brackets that are not single symbols. "\(" is
impossible to match using `scan-lists'.

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

Re: Problem with multi-occur search when restricted to region

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Ihor Radchenko writes on Tue 27 Dec 2022 13:43:
>
>  > Can you try the attached patch?
>
> It did not work with the version I initially used:
>
>release_9.6-149-g554935.dirty
>
> but it works OK with
>
>release_9.6-149-g554935

Fixed on main then. For the next release.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a9c0d4cde

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

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

[Ihor Radchenko]

Ihor Radchenko  writes:

>> There is a race condition between writing the contents of the graphics
>> file to disk and emacs checking the file size. My guess is that this is
>> causing the problem (and that the same failure applies for emacs-2{6,7},
>> since only the emacs-28 reports the exact test failure).
>
> Maybe we can just add several `sleep-for' calls to the test?

I just did this. Let's see if CI errs again.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e5c45358a

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

Re: [Bug] isearch errors when org-fold-core-style is 'overlays

[Ihor Radchenko]

Samuel Wales  writes:

> possibly related: are links still not searchable with iserch without
> being in reveal mode or similar?  [9.4 here.)

Unrelated.
The reported issue is related to the new org-fold implementation.

The old issue with searching links is known. It is simply because
isearch does not support searching inside invisible text. And links are
abbreviated by applying invisible text property to the hidden parts.

You either upgrade or set isearch-invisible to t.

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

org-table: mark a cell

[Uwe Brauer]

Hi

Does anybody know about a way (or a package) that allows me to mark a
cell of table, even if it is multi-line?

Like 

| mark the cell below|
||
| This is text but   |
| more text, and more|
| that is enough.|
| Please mark this cell. |
||
| marks the cell above   |

regards

Uwe Brauer 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/