Re: Extraneous blank lines in when attempting to export org tables

[Rohit Patnaik]

> This is because ox-md adds a blank line between almost every element,
> including table-rows (which ox-md does not care about).

> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=85aafac41

Thanks for fixing this. I completely forgot that my export code is a derived
backend from ox-md. Maybe, I should make it a standalone backend (or derive
directly from ox-html, like ox-md does), to avoid further mysterious issues.

Rohit

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Jack Kamm]

Matt  writes:

> The challenge I've found with Babel is figuring out how to make the changes.  
> My current approach is to address bugs and to make changes that move us 
> toward something like the ob-blub implementation.  I wonder if it might help 
> to discuss the core ideas and use a minimal reference implementation that 
> serves as a guide for the actual changes we make.
>
> Curious to hear other people's thoughts!

I don't remember the details, but my past self [1] thought it would be
good to find a way to replace `process-file' with `make-process' in
`org-babel--shell-command-on-region' or `org-babel-eval', and it seems
you are thinking along those lines with `my-org-babel-eval-async'. Hope
you're able to make progress on this and get the improvements into
ob-eval.el eventually.

[1] https://list.orgmode.org/871rczg7bi@gmail.com/#t

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Jack Kamm]

Bruno Barbier  writes:

> I'm not using it with official org backends (yet).  I'm using it with
> several custom backends that I'm working on.  One of the backend
> delegate the block executions to emacs subprocesses: so I have a kind of
> asynchronous executions for free for any language, including elisp
> itself.

For sessions, wouldn't running in a subprocess prevent the user from
directly interacting with the REPL outside of Org? If so, that's a
problem. Org-babel sessions need to play nicely with inferior Python,
inferior ESS, and other interactive comint modes.

> So, here we go.  You'll find attach a set of patchs.  It works for me with
> Emacsc 30.50 and 9.7-pre (from today).

I suggest to keep these patches on a public branch somewhere, see:
https://orgmode.org/worg/org-contribute.html#patches

  "When discussing important changes, it is sometimes not so useful to
  send long and/or numerous patches.
  
  In this case, you can maintain your changes on a public branch of a
  public clone of Org and send a link to the diff between your changes
  and the latest Org commit that sits in your clone."

I tried running your example on emacs29 using

  emacs -q -L  /path/to/org-mode/lisp my-async-tests.org

but it fails with the error below. Also "make" gives a bunch of
compilation warnings (which I've put at the bottom).

> +You need to load:
> +   #+begin_src elisp :results silent
> +   (load-file "my-async-tests.el")
> +   #+end_src

This raises the following error in *Org-Babel Error Output*

  void-variable
  (org-elib-async-process)
  [ Babel evaluation exited with code 127 ]

All the subsequent blocks don't work because of that, for example:

> +A simple execution:
> +#+begin_src bash
> +  date
> +#+end_src

yields:

  org-babel-execute-src-block: No org-babel-execute function for bash: 
my-shell-babel-schedule!

Finally here are the warnings when running "make":

Compiling single /home/jack/src/org-mode/2024-02-brubar-async/lisp/ob-core.el...

In org-babel--async-feedbacks:
ob-core.el:851:2: Warning: docstring has wrong usage of unescaped single quotes 
(use \= or different quoting)
ob-core.el:871:9: Warning: Unused lexical variable `result-indent'
ob-core.el:906:18: Warning: Unused lexical variable `header'

Compiling single 
/home/jack/src/org-mode/2024-02-brubar-async/lisp/org-elib-async.el...

In toplevel form:
org-elib-async.el:52:11: Warning: reference to free variable 
‘org-elib-async-process’
org-elib-async.el:52:43: Warning: reference to free variable ‘’
org-elib-async.el:52:48: Warning: reference to free variable ‘input’
org-elib-async.el:52:54: Warning: reference to free variable ‘callback’
org-elib-async.el:78:29: Warning: reference to free variable ‘command’
org-elib-async.el:127:9: Warning: Variable ‘last-elapsed’ left uninitialized

In org-elib-async-wait-condition:
org-elib-async.el:137:12: Warning: ‘signal’ called with 3 arguments, but 
accepts only 2

In end of data:
org-elib-async.el:262:16: Warning: the function ‘org-id-uuid’ is not known to 
be defined.
org-elib-async.el:52:35: Warning: the function ‘command’ is not known to be 
defined.
org-elib-async.el:52:2: Warning: the function ‘cl-defun’ might not be defined 
at runtime.

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Matt]

  On Fri, 16 Feb 2024 18:52:22 +0100  Bruno Barbier 

 > Sorry for the late reply.  Cleaning the code took me longer than expected.

No need to apologize, we're all volunteers here :)

 > Feedbacks, corrections, critiques, etc are most welcome!

Thank you for sharing!

If I understand correctly, there are several independent topics the code 
addresses:

| topic| manner addressed   |
|--+|
| execution status | using overlays to communicate execution status |
| locating results | using overlays to locate results   |
| blocking | making all execution asynchronous  |
|--+|

I suggest these be discussed in separate threads.

 > > The use of the overlay is a really cool idea!
 > >
 > > I hesitate to say that's a good way to convey success or failure.  If a 
 > > process failed, I want to see the output which tells me why so that I can 
 > > correct it.  Or, I might actually want the failure output.  Maybe I want 
 > > to literally demonstrate what a code failure looks like.  Maybe I want to 
 > > use that output in another block.  For example, shell blocks have multiple 
 > > output types.  A shell process may return standard output/error or a 
 > > failure code.  The result of the failure may trigger something else.
 > 
 > I'm not sure I fully understand what you mean. The API just assumes the 
 > backend returns the outcome: either success or failure, where failure means 
 > "no result" (the previous result, if it exists, is even preserved in the 
 > document).  The backend is free to transform a failure into a success to 
 > make that result available though.

You can disregard my hesitation on this point.  I had not run your code yet and 
had misunderstood how it worked.

Since this thread is dedicated to blocking, let me share my thoughts on that 
subject.

 > To execute Python blocks, using the proposed async API:
 > 
 >- I've (re)implemented the "asynchronous with session" case 
 > (copying/pasting the relevant part from ob-python).
 >
 >- The "synchronous case" is just artificially blocking the user until the 
 > asynchronous result is known (which looks incredibly tricky to implement if 
 > even possible...).
 >
 >- The "no session" case is just about creating a new unique session and 
 > throwing it away immediately.

This is an interesting idea, feeding all processes through the same mechanism.

Executing a shell block requires starting a 
[[https://www.gnu.org/software/emacs/manual/html_node/elisp/Processes.html][process]].

Processes are synchronous or asynchronous.

Three primitives exist in Emacs for making processes:

1. make-process (asynchronous)
2. call-process (synchronous)
3. call-process-region (synchronous)

There exist several convenience wrappers for these.  AFAIK, everything reduces 
to these three primitives.  For example, =async-shell-command= runs 
=call-process= and prevents blocking by appending a "&" to the command which 
tells the shell to run the command in the background and return control to the 
terminal.  This background-foreground distinction is called "job control".

Output from a process typically goes to a buffer.  This may be changed and 
instead handle output with a filter function.  =call-process= has an option to 
directly send output to a file.

Subprocesses inherent the =default-directory= and the environment from Emacs.  
The environment may be changed using =process-environment=.

There are two types of asynchronous connections: "pty" ("pseudoterminal") and 
"pipe".  The main difference is that "pty" provides a terminal-like connection 
which allows for things like job control (=C-c=, =C-z=, etc.).

In my previous message, I divided evaluation into 4 types:

  - non-persistent vs. persistent 
  - synchronous vs. asynchronous

I find the approach of feeding everything through, fundamentally, 
=make-process= interesting because if we make a chart of the 4 types, we see 
some ambiguities:

|  | non-persistent | persistent   |
|--++--|
| synchronous  | call-process   | ???  |
|--++--|
| asynchronous | ???| make-process |
|--++--|

To make a non-persistent asynchronous process, the first thing that comes to 
mind is =async-shell-command=.  However, as the code shows, another option is 
to use =make-process= and throw away the state (the process buffer).

I'm not sure how we could make a persistent, synchronous process.  Persistence 
is achieved, currently, by a process buffer.  Is there another way persistence 
may be achieved?  Of course, this ignores whether a persistent, synchronous 
process is even desirable.  Given reliable asynchronous execution with 
persistence, I can't think of reason why 

[BUG] org :extend property bugfix does not work [9.7 (9.7-??-388ba5b @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

[StrawberryTea]

In the following Org file which I have copypasted verbatim, the current
workaround for bug#65896 made in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=793cdbea68ae9f6eb4270315df6ff3419c3d8c20
does not work. After putting some print statements in the code, it seems
that the issue is in the unfolding part of the code. The
(org-fold-core-get-regions :from from :to to :specs spec) does not give
the correct regions when there are nested headings. We would need to
replace this with code that gets all the visible folded regions in the
region we are unfolding.

Copy-pasted Org mode file:

#+title: (Infty, 2) Reading Group
#+ROAM_TAGS: "Quasicategories"

* [2020-09-11 Fri] Links passed around in today's meeting
:PROPERTIES:
:CREATED_TIME: [2020-09-12 Sat 11:10]
:END:

** [[https://arxiv.org/abs/2006.07997][Internal enriched categories]]
:PROPERTIES:
:CREATED_TIME: [2020-09-12 Sat 11:11]
:END:

** [[https://www.i2m.univ-amu.fr/perso/dimitri.ara/files/qcatsup.pdf][Higher 
quasi-categories vs higher Rezk spaces]]
:PROPERTIES:
:CREATED_TIME: [2020-09-12 Sat 11:12]
:END:

** [[https://arxiv.org/pdf/1712.06469.pdf][∞-operads as analytic monads]]
:PROPERTIES:
:CREATED_TIME: [2020-09-12 Sat 11:13]
:END:

** [[https://arxiv.org/pdf/2002.01037.pdf][On lax transformations, adjunctions, 
and monads in (∞,2)-categories]]
:PROPERTIES:
:CREATED_TIME: [2020-09-12 Sat 11:14]
:END:

** [[https://acmbl.github.io/straight_slides.pdf][A modular proof of the 
straightening theorem]]
:PROPERTIES:
:CREATED_TIME: [2020-09-20 Sun 13:20]
:END:

* [2020-09-18 Fri 14:29] Links passed around
:PROPERTIES:
:CREATED_TIME: [2020-09-18 Fri 14:29]
:END:

** [[https://arxiv.org/abs/1502.06526][Twisted TQFTs]]
:PROPERTIES:
:CREATED_TIME: [2020-09-18 Fri 14:29]
:END:

** [[https://arxiv.org/pdf/2003.11757.pdf][Lax Gray tensor product for 
2-categories]]
:PROPERTIES:
:CREATED_TIME: [2020-09-18 Fri 14:30]
:END:

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0)
 of 2024-02-17
Package: Org mode version 9.7 (9.7-??-388ba5b @ 
/home/st/.config/emacs/.local/straight/build-30.0.50/org/)

current state:
==
(setq
 org-todo-keyword-faces '(("[-]" . +org-todo-active) ("STRT" . 
+org-todo-active) ("[?]" . +org-todo-onhold) ("WAIT" . +org-todo-onhold)
  ("HOLD" . +org-todo-onhold) ("PROJ" . 
+org-todo-project) ("NO" . +org-todo-cancel) ("KILL" . +org-todo-cancel))
 org-src-window-setup 'other-window
 org-persist-directory "/home/st/.config/emacs/.local/cache/org/persist/"
 org-directory "~/org/"
 org-startup-folded nil
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-id-locations-file "/home/st/org/.orgids"
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-archive-subtree-save-file-p t
 org-archive-location "~/org/.archive/%s::"
 org-modules '(ol-bibtex)
 org-num-skip-tags '("noexport" "nonum")
 org-clock-history-length 20
 org-entities-user '(("flat" "\\flat" nil "" "" "266D" "♭") ("sharp" "\\sharp" 
nil "" "" "266F" "♯"))
 org-msg-options "html-postamble:nil H:5 num:nil ^:{} toc:nil author:nil 
email:nil tex:dvipng"
 org-msg-default-alternatives '((new utf-8 html) (reply-to-text utf-8) 
(reply-to-html utf-8 html))
 org-roam-capture-new-node-hook '(org-roam-capture--insert-captured-ref-h)
 org-roam-directory "/home/st/org/roam/"
 org-archive-hook '(cae-multi-org-archive-push-changes-h 
org-attach-archive-delete-maybe)
 org-ascii-format-drawer-function #[771 ".\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-link-translation-function 'toc-org-unhrefify
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-link-elisp-confirm-function nil
 org-babel-after-execute-hook '(+org-redisplay-inline-images-in-babel-result-h)
 org-confirm-shell-link-function 'yes-or-no-p
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-roam-ref-annotation-function 'org-roam-ref-read--annotation
 org-agenda-skip-unavailable-files t
 org-agenda-span 10
 org-roam-log-setup-hook '(org-roam--register-completion-functions-h)
 org-ai-openai-api-token "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"
 org-latex-classes '(("beamer" "\\documentclass[presentation]{beamer}" 
("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}") 
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
 ("article" "\\documentclass[11pt]{article}" 
("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}") 
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
  ("\\paragraph{%s}" . "\\paragraph*{%s}") 
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
 ("report" "\\documentclass[11pt]{report}" ("\\part{%s}" . 
"\\part*{%s}") ("\\chapter{%s}" . "\\chapter*{%s}")
  ("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" 
. "\\subsection*{%s}")
  ("\\subsubsection{%s}" . 

Re: #6 [[bbb:OrgMeetup]] on Wed, Feb 14, 19:00 UTC+3

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> The email you are replying to has been submitted on January 30, two
> weeks before Feb 14.

Oopsie!  My apologies for the noise, Ihor.

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."
--- Albert Einstein, 1879-1955

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

Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

[Martin Edström]

Here you go!

Tests passed (14 SKIPPED), compiled fine.  I've made no prior
contributions and this changes 5 lines. I'm ok if you want to rephrase
it in any way.

Martin

On Sun, 18 Feb 2024 at 19:56, Martin Edström  wrote:
>
> I will try to do a patch, thanks for the link. Stay tuned.
>
> On Sun, Feb 18, 2024 at 15:06 Ihor Radchenko  wrote:
>>
>> Martin Edström  writes:
>>
>> > I've just been struggling with my custom setting for
>> > `org-latex-to-html-convert-command` outputting many math snippets
>> > wrong. The fault was mine: I didn't correctly shell-quote the input.
>> > I propose to add a warning in the docstring, because many people will
>> > trip the same problem.
>>
>> > The thing is that double-quotes don't work in shell commands.  I had
>> > \"%i\", but it should've been '%i':
>>
>> Would you be interested to submit a patch?
>> See https://orgmode.org/worg/org-contribute.html#first-patch
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
From d3b1b0a3cc4deac7ac47f446fb0bf27f61169ac4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Edstr=C3=B6m?= 
Date: Sun, 18 Feb 2024 20:29:48 +0100
Subject: [PATCH] lisp/org.el: Enhance a docstring

* org.el (org-latex-to-html-convert-command): Add a note in the
docstring about proper shell-quoting.

It can trip you up because wrongly quoted input still works with some
math snippets, so the command may work during testing but not later
when you have different math snippets in play.

TINYCHANGE
---
 lisp/org.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 947037559..6b2ebf9ac 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3275,7 +3275,11 @@ Replace format-specifiers in the command as noted below and use
 %i: The LaTeX fragment to be converted.
 
 For example, this could be used with LaTeXML as
-\"latexmlc \\='literal:%i\\=' --profile=math --preload=siunitx.sty 2>/dev/null\"."
+\"latexmlc \\='literal:%i\\=' --profile=math --preload=siunitx.sty 2>/dev/null\".
+
+Since this is a shell-command, remember to use single-quotes
+around \\='%i\\=', not double-quotes!  Else a math fragment such
+as \"$y = 200$\" gets butchered into only \" = 200\"."
   :group 'org-latex
   :package-version '(Org . "9.4")
   :type '(choice
-- 
2.40.1

Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

[Martin Edström]

I will try to do a patch, thanks for the link. Stay tuned.

On Sun, Feb 18, 2024 at 15:06 Ihor Radchenko  wrote:

> Martin Edström  writes:
>
> > I've just been struggling with my custom setting for
> > `org-latex-to-html-convert-command` outputting many math snippets
> > wrong. The fault was mine: I didn't correctly shell-quote the input.
> > I propose to add a warning in the docstring, because many people will
> > trip the same problem.
>
> > The thing is that double-quotes don't work in shell commands.  I had
> > \"%i\", but it should've been '%i':
>
> Would you be interested to submit a patch?
> See https://orgmode.org/worg/org-contribute.html#first-patch
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [FR] org-num-mode inverse defaults

[Maske]

Hi, Ihor

My config, not working yet, everything is numbered with org-num-mode:

(setq org-num-skip-unnumbered 't)

(setq org-use-property-inheritance '("UNNUMBERED"))

(setq org-global-properties '(("DIR" . "data/") ("UNNUMBERED" . "t")))


Maske


On 15/10/2023 14:40, Ihor Radchenko wrote:

Maske  writes:


  From the first day, I liked org-num-mode, but I think that its default
which numbers all headlines could be problematic.

Right now it only has the options to exclude headlines from being
numbered, so it could be necessary to modify a big amount of headlines,
for numbering just a tree.

I think it would be helpful to have a "positive" way to numbering
headlines, for example "NUMBERED" keyword, while all the other headlines
stay unnumbered.

You can simply set UNNUMBERED property to t for the whole document via
#+PROPERTY keyword or by customizing `org-global-properties'. Then, the
headings that should be numbered should have their UNNUMBERED set to nil.

Re: old pkg fstree stopped working

[Ihor Radchenko]

Uwe Brauer  writes:

> #+begin_fstree: /home/oub/ALLES/HGs/HG-CVS-Formular :non-recursive t
>
> #+end_fstree:
>
> Still does not work
>
> But 
>
> #+BEGIN_FSTREE: /home/oub/ALLES/HGs/HG-CVS-Formular :non-recursive t
>
> #+END_FSTREE:
>
> Does, strange! Anyhow!

You have non-standard value of `case-fold-search' somehow. It should be
t normally and should not be changed by users in practice.

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

Re: old pkg fstree stopped working

[Uwe Brauer]

> Uwe Brauer  writes:

> Is you see "can't do anything useful here", it most likely means that
> you did not load the package.

> http://www.burtzlaff.de/org-fstree/org-fstree.el has (add-hook
> 'org-ctrl-c-ctrl-c-hook 'org-fstree-apply-maybe)
> which should make things work, unless you somehow do not load the
> package.

> When I tried on my side, things work, except that I had to change
> "reduce" calls to "cl-reduce" - "reduce" name alias has been deprecated
> and removed Emacs 27.

> I am attaching the modified working version of the package.

> ;;; org-fstree.el --- include a filesystem subtree into an org file


Thanks very much!


I realized that now I had a problem of capitals and not capitals letter so

#+begin_fstree: /home/oub/ALLES/HGs/HG-CVS-Formular :non-recursive t

#+end_fstree:

Still does not work

But 

#+BEGIN_FSTREE: /home/oub/ALLES/HGs/HG-CVS-Formular :non-recursive t

#+END_FSTREE:

Does, strange! Anyhow!

Regards


Uwe 

-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 



smime.p7s
Description: S/MIME cryptographic signature

footnotes & #+STARTUP:

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

For various reasons I've recently changed my theme from a home-made one to 
'naquadah' which seems to have some problem in that it forces all footnotes 
into the bottom of the file. How can I revert it back to my wanted inline, of 
this
  format `[fn:3]` and then just above the next heading `[fn:3] lorem ipso 
ductem.` I've tried setting this `#+startup: fninline` but it only allows this 
`[fn:450:Blind Io]`.

Second question, is it possible to 'nest' startups like below but into just one 
line, please?

=
#+startup: showeverything
#+startup: fninline
#+startup: fnadjust
#+startup: noinlineimages
=

This is also on 'Org mode version 9.7-pre (release_9.6.18-1207-gea487b @ 
/home/boudiccas/git/org-mode/lisp/)' and a brand new emacs, freshly built this 
morning.
  
Thanks
  Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 12.4, fluxbox 1.3.7, emacs 30.0.50, org 9.7-pre 
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmXSL/gdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1uMthAAsmNoAWDOXcxP/hNS
u+y0ifxuYIPWsDMqVZFZl48+ly3eWfEAkZOEPe5YIx3Rb24xyUGhx+YRugEeaySA
rZIiW2xv0Rt67bjjaMz7kgOGUoeWj+5kzWPJKG/JuuWsgNWqbFyI4Dc9iLIP5esr
+RrA3EUPuJSRMlxpmwyuL4LX9nvEhTbhA4b7u3YTZmpH74cE+t0jYu4ewfjyxP68
wkkyZN97kKHodHN1wIW3xd26ppH7Rac5Pd704C22f6IexylknY3RZ99AEEWP38It
n7ESehkS9ZVWykzRxoUkMWPqh5yEpwPMh0+FLweC7l5XCukz60VgU4WynPCjkcYj
Sj3Dp3waJCQds7FPzKkaxVbPp/36RQn+Elyww4L1ZFj1Czgjc2SAZW8NJWAMHxU7
g4ZUQFesNjpyDL91mOoi3OQRke/eEoVPgpo7Rjer0cdKA5oDGxs5huB1VA5+A7wV
clo/nDGTxQlU8/TYUx84RA5DXC2vGxeJj0UidCA8OPmN9T+B/rFGN6aU7In494/x
OyPj/JZz9QskwWNIDlQGtKFLvtxPRo1BFRXf7ZmeXBivXU0CtYVG1mCfBu5Adhl6
T8DRqVAoEMgWaAjpH7S01z7+XzQMXUuNu+WMDo0/ljlpdX4AZeCUp9oIdy+PUZ0B
0kDPpsGEEWXL2jSNTOcR3aBqlGc=
=HXRJ
-END PGP SIGNATURE-

Re: old pkg fstree stopped working

[Ihor Radchenko]

Uwe Brauer  writes:

> I using a pretty old package called org-fstree
> 
>
> All it requires, after loading it of course, is  to have in an org file the 
> lines
> --8<---cut here---start->8---
>
> #+begin_fstree: /home/oub/ALLES/HGs/HG-CVS-Formular :non-recursive t
>
> #+end_fstree:
> --8<---cut here---end--->8---
> ...
>
> However not any longer when I now hit C-c C-c org tells me:
> can't do anything useful here.
>
>
> I updated org-mode recently could that be the reason? I have changed my emacs 
> version lately.

Is you see "can't do anything useful here", it most likely means that
you did not load the package.

http://www.burtzlaff.de/org-fstree/org-fstree.el has (add-hook
'org-ctrl-c-ctrl-c-hook 'org-fstree-apply-maybe)
which should make things work, unless you somehow do not load the
package.

When I tried on my side, things work, except that I had to change
"reduce" calls to "cl-reduce" - "reduce" name alias has been deprecated
and removed Emacs 27.

I am attaching the modified working version of the package.
;;; org-fstree.el --- include a filesystem subtree into an org file


;; Copyright 2009 Andreas Burtzlaff
;;
;; Author: Andreas Burtzlaff < andreas at burtz[REMOVE]laff dot de >
;; Version: 0.4
;; Keywords: org-mode filesystem tree
;; X-URL: 
;;
;; This file is not part of GNU Emacs.
;;
;; This program 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 2, or (at
;; your option) any later version.
;;
;; This program 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 this program; if not, write to the Free Software
;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

;;; Commentary:

;; org-fstree inserts the filesystem subtree for a given directory.
;; Each file/directory is formatted as a headline, provides links back 
;; to all headlines that are associated with it (by containing links to the 
file) 
;; and is assigned their tags.
;;
;; Installation:
;;   - put this file into your load-path 
;;   - insert "(require 'org-fstree)" into ~/.emacs
;;
;; Usage:
;;   - enter a line containing "#+BEGIN_FSTREE: " into an org buffer, 
;; where  is the directory, that is to be inserted.
;;   - while the cursor is in the line mentioned, press "C-c C-c"
;;
;; Options:
;;   Specify options in the form:
;;   "#+BEGIN_FSTREE:  :  : 
  ...
;;   Options are:
;; - :non-recursive t , to suppress recursion into directories
;; - :exclude-regexp-name  , exclude file/directory 
names matching either 
;;  of the given regexp 
expressions
;;   Examples: 
;; :exclude-regexp-name (".*\\.pdf$" ".*\\.zip$"), excludes 
files/directories ending with either ".pdf" or ".zip"
;; :exclude-regexp-name ("^\\.git$") , excludes files/directories named 
".git"
;;
;; - :exclude-regexp-fullpath , same as 
:exclude-regexp-name but matches absolute path to file/directory
;; - :relative-links t , generates relative instead of absolute links
;; - :show-only-matches t , only files that are being linked to show up
;; - :dynamic-update t , [EXPERIMENTAL] dynamically update a subtree on 
visibility cycling.
;; - :links-as-properties t, sets the links as properties Link1, Link2,... 
for use in column view [Does not work with dynamic-update!]
;;
;; Limitations and warnings:
;;
;;   - when triggering an update (by pressing "C-c C-c" while in the line 
mentioned above)
;; the COMPLETE REGION BETWEEN "#+BEGIN_FSTREE" AND "#+END_FSTREE" IS 
REPLACED.
;;   - speed  
;; 
;; Code:

(provide 'org-fstree)

(require 'org)

(defun org-fstree-generate (dir level options)
  (interactive)
  ;;  (message "org-fstree-generate") ;; DEBUG
  (if (file-directory-p dir)
  (let (
(non-recursive (plist-get options :non-recursive))
(exclude-regexp-name-list (plist-get options :exclude-regexp-name))
(exclude-regexp-fullpath-list (plist-get options 
:exclude-regexp-fullpath))
(links-as-properties (plist-get options :links-as-properties))
(dynamic-update (plist-get options :dynamic-update))
(fullFileNames (directory-files dir 1 nil nil) )
(fileNames (directory-files dir nil nil nil) )
fileName
fullFileName
currentHeadline
orgHeadlineInfo
curTags
curPos
(linksList nil)
(retString "")
)
(while fileNames
  

Re: Extraneous blank lines in when attempting to export org tables

[Ihor Radchenko]

"Rohit Patnaik"  writes:

> I'm currently working on an exporter that will allow org-mode to export to
> PMWiki markdown (https://github.com/quanticle/ox-pmwiki/), and I'm running 
> into
> a problem when writing the export code to handle tables. When exporting table
> rows, I'm getting extraneous blank lines between table rows.
> ...
> The contents of each cell are formatted correctly, but there's an additional
> newline between the two rows. How do I prevent this newline from being added?

This is because ox-md adds a blank line between almost every element,
including table-rows (which ox-md does not care about).

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=85aafac41

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

Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

[Ihor Radchenko]

Martin Edström  writes:

> I've just been struggling with my custom setting for
> `org-latex-to-html-convert-command` outputting many math snippets
> wrong. The fault was mine: I didn't correctly shell-quote the input.
> I propose to add a warning in the docstring, because many people will
> trip the same problem.

> The thing is that double-quotes don't work in shell commands.  I had
> \"%i\", but it should've been '%i':

Would you be interested to submit a patch?
See https://orgmode.org/worg/org-contribute.html#first-patch

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

Re: (jit-lock-function 1) signaled (error "Stack overflow in regexp matcher")

[Ihor Radchenko]

William Denton  writes:

> On Thursday, February 15th, 2024 at 15:40, William Denton 
>  wrote:
>
>> I am having a problem I've never seen before: Org can't handle anything more 
>> in a large file I have!
>> 
>> This file is where I keep my notes day to day for work, with headings for 
>> months and days and categories of work, with a lot of notes and clocking in 
>> and out. It has about 10,000 lines and is about 550K in size.
>
> Update: moving the 600-line clock table in that file to another file fixed 
> the problem.  (In that new file, it generates its clock table from the 
> clocking in the remote file, the old one.)

It means that Org gives Emacs too complex regexp somewhere.
There is no easy way to fix such issues without having a reproducer and
trying to play around with the problematic regexp.
Emacs regexp engine has some rough edges when regexps get complex.

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

Re: [BUG] ox-odt messes with auto-mode-alist [9.7-pre (release_9.6.11-1090-g76468c.dirty @ /home/viz/lib/emacs/straight/build/org/)]

[Ihor Radchenko]

Visuwesh  writes:

> ox-odt.el contains the following lines at the end of file:
>
> ;;; Library Initializations
>
> (dolist (desc org-odt-file-extensions)
>   ;; Let Emacs open all OpenDocument files in archive mode.
>   (add-to-list 'auto-mode-alist
>(cons (concat  "\\." (car desc) "\\'") 'archive-mode)))

These lines are no longer there on the latest main.
Canceled.

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

Re: [patch] Add two new header args to LaTeX block

[Juan Manuel Macías]

Ihor Radchenko writes:

>> In any case, if the org-create-formula-image method is going to stay, I
>> think it is fine as it is (except for extending the allowed file formats
>> to more extensions, and not only .png). I also believe that the :process
>> argument is sufficient for the user to control the value of
>> org-latex-pdf-process or org-preview-latex-default-process, as
>> appropriate.
>
> My concern about your patch is that it creates even more divergence
> between different branches of code in `org-babel-execute:latex'.
> With the new proposed features only available to some code branches,
> `org-babel-execute:latex' will just become more messy and harder to
> maintain.
>
> I'd prefer to refactor `org-babel-execute:latex' first, before adding
> new header arguments.

org-create-formula-image inserts LaTeX code:

...
(with-temp-file texfile
  (insert latex-header)
  (insert "\n\\begin{document}\n"
  "\\definecolor{fg}{rgb}{" fg "}%\n"
  (if bg
  (concat "\\definecolor{bg}{rgb}{" bg "}%\n"
  "\n\\pagecolor{bg}%\n")
"")
  "\n{\\color{fg}\n"
  string
  "\n}\n"
  "\n\\end{document}\n"))
...

that, /in principle/, would make it incompatible with the :standalone
argument (in my patch), which allows writing all LaTeX code from scratch
in the block content.

Anyway, it is true that org-babel-execute:latex has grown in a somewhat
irregular way. For example, I don't quite understand why the simple
output to PDF and the conversion to an image with :imagemagick live in
the same conditional:

(or (string= "pdf" extension) imagemagick)

I would propose three main branches in this function:

- A PDF branch, using org-format-latex-header with its valid options,
  and other sub-branches with conversion from the PDF, for example, the
  use of :imagemagick. Or you could even think of any possible
  conversion process using a hypothetical :pdf-postprocess

- A branch for orf-create-formula-image

- a third branch to export to html, with org-babel-latex-htlatex.

Having three clearly differentiated branches would make the code easier
to maintain.

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: [BUG] ox-texinfo can't export example blocks [9.6.9 (release_9.6.9 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

pva-outd...@yandex.ru writes:

> It seems that in ox-texinfo.el the `string-match-p' is used instead of
> `string-equal' (here is my patch):

`string-match-p' is used there on purpose to mark lisp, emacs-lisp, and
even elisp blocks with @lisp Texinfo markup.
See 
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040lisp

> ... the
> :language property is nil for #+BEGIN_EXAMPLE ... #+END_EXAMPLE blocks.

`org-texinfo-src-block', which you modified in your patch, has nothing
to do with example blocks. It only handles exporting src blocks
(#+begin_src .. #+end_src).

Example blocks are exported using @example Texinfo markup.
See 
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040example
Example blocks have no notion of language in Texinfo.

> Without this fix I can't export my `.org' files to `.texi' format ...

Please describe your problem in more details. What do you mean by "can't
export"? See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: [PATCH] org-bibtex-yank: Allow to populate existing item

[Ihor Radchenko]

Martin Kampas  writes:

> The attached patch allows to use org-bibtex-yank to 
> populate an existing item instead of creating a new one, 
> aligning its behavior with org-bibtex-create.

Thanks!

> Subject: [PATCH] org-bibtex-yank: Allow to populate existing item
>
> Align with org-bibtex-create.

Please quote like `org-bibtex-create'. Here and in the rest of the
commit message. See https://orgmode.org/worg/org-contribute.html#orgfabdc17

> * lisp/ol-bibtex.el (org-bibtex-write): New optional argument nonew,
>   similar to the existing nonew argument of org-bibtex-create
> * lisp/ol-bibtex.el (org-bibtex-yank): New optional argument nonew,
>   similar to the existing nonew argument of org-bibtex-create

When adding new arguments, we need to announce the change in
etc/ORG_NEWS file. Also, in `org-bibtex-yank', you did not only add an
optional argument, but also modified its behavior with prefix argument.
Changes in prefix arguments should also be announced - they directly
affect all the users.

> -(defun org-bibtex-write ( noindent)
> +(defun org-bibtex-write ( noindent nonew)
>"Insert a heading built from the first element of `org-bibtex-entries'.
>  When optional argument NOINDENT is non-nil, do not indent the properties
> -drawer."
> +drawer. If NONEW is t, add data to the headline of the entry at point."

In the code, you do not check for t, but for non-nil. So, please say
"non-nil" in the docstring as well.

Also, I'd prefer a more descriptive name, like update-heading. nonew is
ambiguous - it can be interpreted in several ways.

> -(defun org-bibtex-yank ()
> -  "If kill ring holds a bibtex entry yank it as an Org headline."
> -  (interactive)
> -  (let (entry)
> +(defun org-bibtex-yank ( nonew)

> +  "If kill ring holds a bibtex entry yank it as an Org headline.
> +If nonew is t, add data to the headline of the entry at point."

Same here. And please upcase NONEW to indicate that it is a function argument.
Also, document that NONEW is interpreted as interactive prefix argument:

   When called with non-nil prefix argument NONEW, add data to the headline
   of the entry at point.

> +  (interactive "P")
> +  (let (entry
> +(noindent nonew))

Why do you bind noindent here?

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

Re: [patch] Add two new header args to LaTeX block

[Ihor Radchenko]

Juan Manuel Macías  writes:

> It is true that the "org-create-formula-image" method is much more
> complete. But, IMHO, I think it's a method focused on the buffer (rather
> than the block) or previewing LaTeX code in the buffer.

What do you mean? `org-create-formula-image' is passed a string of LaTeX
code. Note that `org-create-formula-image' is also used in HTML export.

> ... In the case of
> the LaTeX block, I think the :imagemagick method is simpler. It depends
> on two simple processes: imagemagick and org-latex-pdf-process and
> parameters such as the width or height of the generated image, the
> density in dpi, etc. can be easily applied, via arguments.

ob-latex does not have to expose all the possible toggles
`org-latex-pdf-process' has.

> ... In the case
> of the other method, in addition to the value of
> org-preview-latex-default-process, there is that of
> org-format-latex-options. There are, in short, many parameters that are
> perfect for a file or an Emacs session but for a simple block I find
> overhelming.

We can fix the parameters we do not want to expose.

> In any case, if the org-create-formula-image method is going to stay, I
> think it is fine as it is (except for extending the allowed file formats
> to more extensions, and not only .png). I also believe that the :process
> argument is sufficient for the user to control the value of
> org-latex-pdf-process or org-preview-latex-default-process, as
> appropriate.

My concern about your patch is that it creates even more divergence
between different branches of code in `org-babel-execute:latex'.
With the new proposed features only available to some code branches,
`org-babel-execute:latex' will just become more messy and harder to
maintain.

I'd prefer to refactor `org-babel-execute:latex' first, before adding
new header arguments.

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

Re: [BUG] Prompt appears in async shell results

[Matt]

  On Mon, 05 Feb 2024 15:00:18 +0100  Ihor Radchenko  wrote --- 
 
 > Yes. The right fix would be extracting the filter from
 > `org-babel-comint-with-output' and re-using it.

This message documents my progress so that I may switch focus to Bruno's 
patches in "Asynchronous blocks for everything" attention 
(https://list.orgmode.org/65cfa0d8.050a0220.cb569.c...@mx.google.com/T/#u).

Attached is a failed attempt at extracting the filter in 
=org-babel-comint-with-output=.  It tries to extract the filter more-or-less 
directly:

1. take the filter code from =org-babel-comint-with-output= and put it
into a separate function, =org-babel-comint-process-output-filter=

2. call =org-babel-comint-process-output-filter= from
=org-babel-comint-with-output= and =org-babel-comint-async-filter=

The unmodified =org-babel-comint-with-output= has a comment that says, "Filter 
out prompts".  This is misleading.  The filter code does two things: removes 
prompts *and* removes echoed input.

The problem is the filter which removes echoes uses the body of the source 
block.  It's unclear how to give =org-babel-comint-async-filter= the block 
body.  =org-babel-comint-async-filter= is a =comint-output-filter-function= 
which receives a single input, "a string containing the text as originally 
inserted" in the comint buffer.

Thoughts:

- Split prompt filtering and input echoing into two filters
  + this seems to imply a =-hook= or =-functions= type implementation
  + where could input echo filter go?  Where has access to the block body?
-  creating a generic prompt filter duplicates =ob-shell-async-chunk-callback= 
or, more fundamentally, =org-babel-comint-async-chunk-callback=
- What would it take to consolidate output filtering?  In addition to prompt 
filtering and input echo filtering, ob-shell filters the 
=org-babel-sh-eoe-indicator=.  I'm sure there's other filtering that happens on 
block output.  Wouldn't it be nice if that were in a single place, like right 
before results are inserted?

Please feel free to provide feedback and suggestions.

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode


v01-refactor-filter.diff
Description: Binary data