Re: Bash results broken?

[Matt]

  On Mon, 19 Dec 2022 19:44:12 -0500  Rudolf Adamkovič  wrote --- 
 > Ihor Radchenko yanta...@posteo.net> writes:
 > 
 > > Fixed on bugfix.
 > 
 > I can confirm that the fix works.  Thank you!

I can confirm it works, too, for the 1 2 3 example.  However, it puts double 
quotes around text:

#+BEGIN_SRC sh :results list
echo hello
echo world
echo !
#+END_SRC

#+RESULTS:
- "hello"
- "world"
- "!"

I was working on other ob-shell related stuff and my Emacs got into a mixed 
state where =ob-shell/results-list= was defined, but the fix wasn't (or wasn't 
loaded).  I fixed the failing test before I saw this thread and Ihor's fix.  
The way I solved it was to wrap either =org-babel-import-elisp-from-file= or 
=org-babel-sh-evaluate= like,

(mapcar #'car (org-babel-import-elisp-from-file tmp-file))

or 

(mapcar #'car  (org-babel-sh-evaluate session full-body params stdin cmdline))

Doing this (without Ihor's fix in place) returns:

#+BEGIN_SRC sh :results list
echo "hello"
echo "world"
echo "!"
#+END_SRC

#+RESULTS:
- hello
- world
- !

The underlying issue, so far as I understand it, is that 
=org-babel-import-elisp-from-file= returns a list-of-lists.  For example, ((1) 
(2) (3)) or (("hello") ("world") ("!")).  I thought it appropriate to flatten 
it out to (1 2 3) or ("hello" "world" "!").

Independently from how I addressed the bug, I feel it raises an important 
question: how should :results list handle text/strings? 

I'm not sure which approach is more "appropriate".   If I echo a string without 
quotes, as I did in the first example, should it return a list that's got 
quotes?  The hello world example is a little contrived–it's good practice to 
use double-quotes.  I think a more realistic use case would be listing a 
directory.  In that case, I'd probably want the list of items to be unquoted:

Original:

#+BEGIN_SRC sh :results list
ls /home/ahab/.emacs.d/straight/repos/org/testing/lisp/ | head -n 3
#+END_SRC

#+RESULTS:
- ("test-ob-awk.el")
- ("test-ob-C.el")
- ("test-ob-clojure.el")

Ihor solution:

#+BEGIN_SRC sh :results list
ls /home/ahab/.emacs.d/straight/repos/org/testing/lisp/ | head -n 3
#+END_SRC

#+RESULTS:
- "test-ob-awk.el"
- "test-ob-C.el"
- "test-ob-clojure.el"

MAPCAR solution:

#+BEGIN_SRC sh :results list
ls /home/ahab/.emacs.d/straight/repos/org/testing/lisp/ | head -n 3
#+END_SRC

#+RESULTS:
- test-ob-awk.el
- test-ob-C.el
- test-ob-clojure.el

For :results list, the manual says, "Interpret the results as an Org list.  If 
the result is a single value, create a list of one element".  I don't find that 
clarifies what would be best.

Thoughts?

Re: Radio links work only in small numbers

[Timothy]

Hi All,

> It’s not like we cannot fix this by splitting the regexp manually into
> prefix tree.
>
> The question is performance though.

For reference, I ran into this issue with Org Glossary, and did exactly this:
see .

I sort all the strings being matched with `string<' and then create clumps of 
~800
terms and then search with the constructed regex for each clump in turn.

Obviously this has a performance impact, but it seems to work well enough, and
working slower is clearly better than not working at all.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

[PATCH] Fix missing null check for tangle links during export

[Tom Gillespie]

Hi,
   Here is a patch that fixes broken tangling during export. I don't have a
simple reproduction, but was able to run git bisect to find the originating
commit. The commit text explains the issue in detail. Best,
Tom
From 0b4e35453874db0acf046e46c571cdef5f39f59a Mon Sep 17 00:00:00 2001
From: Tom Gillespie 
Date: Mon, 19 Dec 2022 21:25:02 -0500
Subject: [PATCH] Fix missing null check for tangle links during export

* lisp/ob-tangle.el (org-babel-tangle--unbracketed-link): Add the let
bound variable l to the and statement to prevent l from being passed
to `string-match' in the event that it is nil.

When tangling nested noweb blocks during export it is possible for the
results of `org-store-link' to return nil.  This commit ensures that
the value returned for l is only passed to `string-match' when it is
non-nil, avoiding a `wrong-type-argument' (stringp nil) error.

Handling of comments and nesting of babel blocks is known to have
issues.  The bug is from 8a781d35dc68f20fa2a5546c98ba3d9b77ee3cda
where new code was introduced to obtain the value for bare which was
not present in early code.  I'm guessing that the bug appears now
because `string-match' is called on l (aka link) at a point in time
when it was never previously called and it was thus masked because in
the old version it was impossible to call `string-match' when `link'
was nil because another variable was always nil, masking the issue.
---
 lisp/ob-tangle.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index bd17bda32..fd6b6f3b9 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -500,7 +500,8 @@ The PARAMS are the 3rd element of the info for the same src block."
  (cl-letf (((symbol-function 'org-store-link-functions)
 (lambda () nil)))
(org-store-link nil
- (bare (and (string-match org-link-bracket-re l)
+ (bare (and l
+(string-match org-link-bracket-re l)
 (match-string 1 l
 (when bare
   (if (and org-babel-tangle-use-relative-file-links
-- 
2.38.2

Re: Radio links work only in small numbers

[Rudolf Adamkovič]

Max Nikulin  writes:

> On 14/12/2022 06:10, Rudolf Adamkovič wrote:
>> 
>> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
>> that I may as well ask Org to make links for me.  So, I replaced all the
>> ~4000 headings in my notes with radio <<>>.  However, Org now
>> errors out with "Regular expression too big".
>
> I think, you are abusing the feature. Too light markup requires too 
> heavy processing. What about <> and explicit [[target]]?

For context, I started using radio links back when I started studying
biology, and they helped me tremendously.  However, as I learned more,
Org "gave up".  Personally, I would not call taking some more notes
"abusing the feature", especially given the fact that the manual says
nothing about the limitation, and it stopped working pretty quickly.

That said, two days ago, I split my notebook into smaller files, so
radio links will not work for me anymore!

[1]: https://orgmode.org/manual/Radio-Targets.html
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

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

Re: Bash results broken?

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Fixed on bugfix.

I can confirm that the fix works.  Thank you!

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

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

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

[Rudolf Adamkovič]

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 use Scheme and Geiser heavily at work, albeit not via Org.)

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] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tom Gillespie]

One more correction. The source of the issue is that the two values in the
list need to be different, one for the message and one for the actual test.
Best,
Tom

(list "emacs-lisp" cell
  '((:eval . yes)) nil (format "%S" cell)
  nil nil)

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

[Tom Gillespie]

By the way, while we're on bugfixes. I just noticed that (format "%S" cell)
is being used to create the fake body for info. This is incorrect because
cell is already a string at this point and this makes the behavior
inconsistent with the rest of org babel as a result. Fix below. Best,
Tom


The fix is to pass

(list "emacs-lisp" cell
  '((:eval . yes)) nil cell
  nil nil)

Re: Org-cite (oc-csl) tip: Filtering bibliography for language

[András Simonyi]

... I've forgotten to add that another (probably more user friendly)
option would be to design and implement some kind of  filtering DSL.

András

On Mon, 19 Dec 2022 at 23:05, András Simonyi  wrote:
>
> Dear All,
>
> On Mon, 19 Dec 2022 at 15:49, Christian Moe  wrote:
>
> > Refinements welcome. I'm especially wondering what would be an elegant
> > way to generalize this for more languages without defining a predicate
> > for each language (given that we cannot pass the language as an
> > additional argument in the print_bibliography line).
>
> Thanks for describing this usage! As for the problem of generalizing
> to more languages, one relatively simple solution would be to allow
> arbitrary sexps as filters. Then one could write something like
>
> #+print_bibliography: :filter (lambda (item) (bibitem-has-language item 
> "en")))
>
> Would this type of extension be helpful? One (not necessarily
> important)  consequence would be that filters of this type would be
> obviously unusable with the biblatex exporter.
>
> best wishes,
> András

Re: Org-cite (oc-csl) tip: Filtering bibliography for language

[András Simonyi]

Dear All,

On Mon, 19 Dec 2022 at 15:49, Christian Moe  wrote:

> Refinements welcome. I'm especially wondering what would be an elegant
> way to generalize this for more languages without defining a predicate
> for each language (given that we cannot pass the language as an
> additional argument in the print_bibliography line).

Thanks for describing this usage! As for the problem of generalizing
to more languages, one relatively simple solution would be to allow
arbitrary sexps as filters. Then one could write something like

#+print_bibliography: :filter (lambda (item) (bibitem-has-language item "en")))

Would this type of extension be helpful? One (not necessarily
important)  consequence would be that filters of this type would be
obviously unusable with the biblatex exporter.

best wishes,
András

Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Jean Louis]

* Ihor Radchenko  [2022-12-18 17:57]:
> andre duarte bueno  writes:
> 
> > When I try to export file.org  using C-c C-e the window with the list of
> > possibilities appears. But it appears incomplete(visualization), so I try
> > to use the mouse to view the other export options and the system is
> > completely blocked. Every mouse click is captured and displayed in the
> > command window. And it doesn't allow you to do anything else. I am forced
> > to cancel the command without completing it.
> > Apparently C-c C-e is capturing all events and not just keyboard
> > events!

That is not first complaint, right? I would say it is obvious that
such interface is not user friendly. 

> This is because we use `read-char-exclusive'.

Don't use what is blocking Emacs. Apart from Org mode I have never
seen a package that blocks Emacs that I cannot even inspect keys.

> Alternative menu designs have been discussed in
> https://list.orgmode.org/orgmode/am9pr09mb497743d21fa1c908392413f496...@am9pr09mb4977.eurprd09.prod.outlook.com/

I did not find anything on that link.

You have the Org menu, right? You can export it from menu, it could be
so simple.

Here is the concept of using Org similar buffers to export Org
buffers:

GNU Emacs package: rcd-org-export.el -- use Org to export Org:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-export-el-use-Org-to-export-Org-76272.html

It is made for you, as concept, as I have already mentioned the
concept before months. 

In general, this is Org mode, so why not use Org mode to export Org
mode?

See the video demonstration:

https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv

Package is made for you Ihor, as a concept of non-blocking export, it
is not functional.

You can now make automatic discovery of export packages and implement
it in Org if you wish. 

As if not, I am sure that I can finish it and have that export working
well for my export backends.

-- 
Jean

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

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

Org-cite (oc-csl) tip: Filtering bibliography for language

[Christian Moe]

Hi,

A tip some of you might find useful:

I wanted to separate sub-bibliographies by language, which is not one of
the out-of-the-box available properties of the PRINT_BIBLIOGRAPHY
keyword.[fn:1] Specifically, I wanted to filter out Norwegian items into
one subbibliography and non-Norwegian ones into another in the same
document.[fn:2]

I found out how to do it with the `PRINT_BIBLIOGRAPHY: :filter
' property, which turns out to be used in the function
citeproc-sb--match-p, where it is applied to a var-value list.

I defined a predicate for Norwegian, bibitem-norwegian-p, that matches a
regexp for various labels for Norwegian[fn:3] against the language
value.

#+begin_src elisp
  (defun bibitem-norwegian-p (vv)
"Returns non-nil (0) if a bibliography item is in
  Norwegian. For use in an org-cite PRINT_BIBLIOGRAPHY filter."
(let ((itemlang (alist-get 'language vv)))
  (and itemlang (string-match "n[obn][r-bo]?" itemlang
#+end_src

Then I could successfully use it as follows:

#+PRINT_BIBLIOGRAPHY: :filter bibitem-norwegian-p

For the list of non-Norwegian items I just needed to define a complementary
function:

#+begin_src elisp
  (defun bibitem-not-norwegian-p (vv)
(not (bibitem-norwegian-p vv)))
#+begin_src elisp

#+PRINT_BIBLIOGRAPHY: :filter bibitem-not-norwegian-p

Adapt as needed for other languages and use cases.

Refinements welcome. I'm especially wondering what would be an elegant
way to generalize this for more languages without defining a predicate
for each language (given that we cannot pass the language as an
additional argument in the print_bibliography line).

* Footnotes

[fn:1] [[info:org#Bibliography options in the ``biblatex'' and ``csl''
export processors]]

[fn:2] For this to work at all, of course, your CSL JSON or BibTeX has
to contain language information on the items; it should, or English
formatting such as title-casing might be applied inappropriately to
non-English items by some styles.

[fn:3] The regexp is complicated because Norwegian is complicated, my
labeling is inconsistent and I want to match at least no, nb, nn, no-NO,
nb-NO, nn-NO, nor, nob, nno, norsk and Norwegian ...



Yours,
Christian