LaTeX preview between #+begin_equation/#+end_equation

[Marc Nieper-Wißkirchen]

Hi,

I have a code block outputting mathematical LaTeX code as a result:

#+BEGIN_SRC ... :wrap equation*

#+END_SRC

The result looks like

#+RESULTS:
#+begin_equation*

#+end_equation*

As  does not contain the surrounding
\begin{equation*}/\end{equation*}, I added the :wrap keyword.

Export to LaTeX works fine, but LaTeX preview in Org does not.  This
only works when I replace (by hand) #+begin_equation*/#+end_equation*
by \begin{equation*}/\end{equation*}.  Can I achieve this with wrap?
Or is there a way to make #+begin_equation*/#+end_equation* work with
the preview? Is the latter otherwise equivalent?

Thanks,

Marc

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

[Matt]

  On Fri, 16 Dec 2022 12:41:45 -0500  Ihor Radchenko  wrote --- 
 > We really need more tests.

I'm working on giving ob-shell a little bit of love.  I wrote the worg 
documentation for it earlier this year.  I tried to include examples of all 
coded functionality, including previously undocumented features.  I think the 
examples would make for good tests since they document the present and expected 
behavior.  Currently, though, I'm refactoring the ob-shell tests to remove 
dependency on ob-shell-test.org and to stop the suite from littering.  After 
that, I intend to incorporate the worg examples as tests.  I'd like to adopt 
ob-shell, life permitting.  Sadly, I'm not confident I'm able to commit to that 
right now.  So, if I can get the FSF paperwork cleared, hopefully, I can make 
little contributions here and there.  

I've included patches of what I've been doing.   They're not ready for actual 
submission yet, both in quality and legality.  However, I'm including them for 
feedback, to make sure I'm not getting way off base.  Overall, I'd *really* 
like to implement async for ob-shell similar to ob-python.  However, I feel 
like it'd be more responsible and respectful to clean up the tests and code a 
little first before proposing such a big change (looking at you, 
org-babel-shell-initialize).

Can someone please assist me with the FSF paperwork off list?

0001-Remove-mixed-tabs-and-spaces.patch
Description: Binary data


0002-Split-test-ob-shell-dont-error-on-empty-results.patch
Description: Binary data


0003-Refactor-test-ob-shell-session.patch
Description: Binary data


0004-Refactor-ob-shell-generic-uses-no-arrays.patch
Description: Binary data


0005-Refactor-ob-shell-bash-uses-arrays.patch
Description: Binary data


0006-Refactor-ob-shell-generic-uses-no-assoc-arrays.patch
Description: Binary data


0007-Refactor-ob-shell-bash-uses-assoc-arrays.patch
Description: Binary data

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

[Marc Nieper-Wißkirchen]

I have been talking to jao (from geiser).  The following version of
ob-scheme.el signals an error when executing Scheme code blocks.
Besides two function declarations, the only change is in the function
org-babel-scheme-execute-with-geiser.

;;; ob-scheme.el --- Babel Functions for Scheme  -*- lexical-binding: t; -*-

;; Copyright (C) 2010-2022 Free Software Foundation, Inc.

;; Authors: Eric Schulte
;;Michael Gauland
;; Keywords: literate programming, reproducible research, scheme
;; URL: https://orgmode.org

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see .

;;; Commentary:

;; Now working with SBCL for both session and external evaluation.
;;
;; This certainly isn't optimally robust, but it seems to be working
;; for the basic use cases.

;;; Requirements:

;; - a working scheme implementation
;;   (e.g. guile https://www.gnu.org/software/guile/guile.html)
;;
;; - for session based evaluation geiser is required, which is available from
;;   ELPA.

;;; Code:

(require 'org-macs)
(org-assert-version)

(require 'ob)
(require 'geiser nil t)
(require 'geiser-impl nil t)
(defvar geiser-repl--repl) ; Defined in geiser-repl.el
(defvar geiser-impl--implementation)   ; Defined in geiser-impl.el
(defvar geiser-scheme-implementation)  ; Defined in geiser-impl.el
(defvar geiser-default-implementation) ; Defined in geiser-impl.el
(defvar geiser-active-implementations) ; Defined in geiser-impl.el
(defvar geiser-debug-show-debug-p) ; Defined in geiser-debug.el
(defvar geiser-debug-jump-to-debug-p)  ; Defined in geiser-debug.el
(defvar geiser-repl-use-other-window)  ; Defined in geiser-repl.el
(defvar geiser-repl-window-allow-split); Defined in geiser-repl.el

(declare-function run-geiser "ext:geiser-repl" (impl))
(declare-function geiser "ext:geiser-repl" (impl))
(declare-function geiser-mode "ext:geiser-mode" ())
(declare-function geiser-eval-region "ext:geiser-mode"
  (start end  and-go raw nomsg))
(declare-function geiser-eval-region/wait "ext:geiser-mode"
  (start end  timeout))
(declare-function geiser-repl-exit "ext:geiser-repl" ( arg))
(declare-function geiser-eval--retort-output "ext:geiser-eval" (ret))
(declare-function geiser-eval--retort-result-str "ext:geiser-eval" (ret prefix))
(declare-function geiser-eval--retort-error "ext:geiser-eval" (ret))
(declare-function geiser-eval--retort-error-msg "ext:geiser-eval" (err))

(defcustom org-babel-scheme-null-to 'hline
  "Replace `null' and empty lists in scheme tables with this before returning."
  :group 'org-babel
  :version "26.1"
  :package-version '(Org . "9.1")
  :type 'symbol)

(defvar org-babel-default-header-args:scheme '()
  "Default header arguments for scheme code blocks.")

(defun org-babel-expand-body:scheme (body params)
  "Expand BODY according to PARAMS, return the expanded body."
  (let ((vars (org-babel--get-vars params))
(prepends (cdr (assq :prologue params)))
(postpends (cdr (assq :epilogue params
(concat (and prepends (concat prepends "\n"))
(if (null vars) body
  (format "(let (%s)\n%s\n)"
  (mapconcat
   (lambda (var)
 (format "%S" (print `(,(car var) ',(cdr var)
   vars
   "\n  ")
  body))
(and postpends (concat "\n" postpends)


(defvar org-babel-scheme-repl-map (make-hash-table :test #'equal)
  "Map of scheme sessions to session names.")

(defun org-babel-scheme-cleanse-repl-map ()
  "Remove dead buffers from the REPL map."
  (maphash
   (lambda (x y) (unless (buffer-name y) (remhash x org-babel-scheme-repl-map)))
   org-babel-scheme-repl-map))

(defun org-babel-scheme-get-session-buffer (session-name)
  "Look up the scheme buffer for a session; return nil if it doesn't exist."
  (org-babel-scheme-cleanse-repl-map) ; Prune dead sessions
  (gethash session-name org-babel-scheme-repl-map))

(defun org-babel-scheme-set-session-buffer (session-name buffer)
  "Record the scheme buffer used for a given session."
  (puthash session-name buffer org-babel-scheme-repl-map))

(defun org-babel-scheme-get-buffer-impl (buffer)
  "Return the scheme implementation geiser associates with the buffer."
  (with-current-buffer (set-buffer buffer)
geiser-impl--implementation))

(defun org-babel-scheme-get-repl (impl name)
  "Switch to a scheme REPL, creating it 

[PATCH] oc-basic.el: Fix wrong type for the editors field when parsing JSON.

[Hugo Cisneros]

I use org-cite with a JSON bibliography and noticed a bug when an entry only has
an "editors" field but no "authors" field. The function
`org-cite-basic—get-author' correctly falls back to using the editors instead of
the authors, but `org-cite-basic--parse-json’ stringifies only the "authors"
field and not the "editors." This creates an error when other functions assume
they got a string from `org-cite-basic—get-author'. The patch fixes the issue by
applying the same transformation to both "authors" and "editors".

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.





oc-basic.el.patch
Description: Binary data


Hugo Cisneros

Bug? Error in HTML export of links with search options

[Daniel Fleischer]

Org offers the ability to run a search inside a link, see (org) Search
Options. E.g. [[File.c::100]] to get to line 100 in File.c. When
exporting this to HTML I get the following error:

org-export-data: Unable to resolve link: "‘recenter’ing a window that does 
not display current-buffer."

Also when having links of the form [[File.clj::defn]] where `defn' is a
search string.

Main 04d2cc59.

-- 
Daniel Fleischer

Re: Problems with C-c C-e file.org

[Jean Louis]

* andre duarte bueno  [2022-12-18 12:30]:
> 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 problem is solved with my package RCD Org Export, see video
demonstration here:

https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-20-19:33:59.ogv

You may let me know what type of Org exports you need and I will make
sure that my Emacs Lisp package supports it. It is non-blocking and
allows mouse usage.

More about it:

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

-- 
Jean

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

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

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

[Christian Moe]

Denis Maier writes:

> Am 19.12.2022 um 23:20 schrieb 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
>
> I'd say both options are certainly useful. A filtering DSL is surely
> the more user friendly option, but allowing lambda expressions would
> probably be quicker to implement, and it would also allow for
> predicates not anticipated by DSL designers.
>
> Best,
> Denis

Arbitrary sexps would give us more flexibility. Alternately, one could
achieve more or less the same by letting :filter collect any additional
arguments and pass them as  to the user's predicate function,
something like:

  #+PRINT_BIBLIOGRAPHY: :filter bibitem-lang-p nb nn no :type article

(This perhaps makes for cleaner solutions. And it is perhaps slightly
better from a security viewpoint: I hope for a bright future of
collaborative authoring in Org, so I'm wary of proliferating ways to
execute arbitrary elisp that a user might not notice. But we do have
such ways already, and it's possible to abuse the above solution as
well, so I don't know.)

Alternatively, I think there is a case for adding a user-friendly
:language property to the print_bibliography keyword. On my bookshelf it
vies with primary/secondary sources as the most common criterion for
separate bibliographies.

I was going to say that this is the only extension I can think of that
is needed beside :(not)(csl)type and :(not)keyword, but of course people
are sooner or later going to want easy-to-use properties to filter by
author, publication date ranges, and probably other criteria I cannot
think of right now, so it's a strategic decision for the maintainer(s)
if you want to go that way. :-)

Yours,
Christian

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

[Timothy]

Hi András,

> Yes, on the other hand, we will have to be very careful with regard to
> security if we choose this route, treating filters basically as elisp
> source code blocks.

Mmm, next year I’d like to try to track down and manage all of the “surprise
elisp execution” that happens with Org files, so having something basic for
simple use cases could be nice.

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 .

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

[András Simonyi]

On Tue, 20 Dec 2022 at 09:22, Denis Maier  wrote:

> allowing lambda expressions would
> probably be quicker to implement, and it would also allow for predicates
> not anticipated by DSL designers.

Yes, on the other hand, we will have to be very careful with regard to
security if we choose this route, treating filters basically as elisp
source code blocks.

András

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

[Denis Maier]

Am 19.12.2022 um 23:20 schrieb 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


I'd say both options are certainly useful. A filtering DSL is surely the 
more user friendly option, but allowing lambda expressions would 
probably be quicker to implement, and it would also allow for predicates 
not anticipated by DSL designers.


Best,
Denis