Re: Basic citations: should default citation style have a name and style code?

[William Denton]

On Sunday, January 14th, 2024 at 00:08, William Denton 
 wrote:

> While we're talking about citations, I'm stuck on something else. If I run 
> "C-c C-x @" to insert a citation into a file, I'm shown a list of 
> bibliography entries and I can go up and down and hit RET on any I chose. 
> That works well. But---the prompt says, "Key (empty input exits)." What makes 
> empty input? I can't figure it out. I've never seen that phrase before. I 
> can't make it exit properly---I either keep adding citations or C-g or DEL 
> cancels it---so I can't make the function work. If anyone knows, I can try 
> making a patch to make it clearer.

As so often happens, a few minutes after sending an email I think I found the 
answer: it's seems to be a problem with the completion mechanism Ivy.

https://stackoverflow.com/q/77489325/854346

I ran "emacs -Q" and I see how it works there, with RET closing things off, 
which makes sense.  

Last year I looked at Vertico and thought about trying it out, but since 
everything was working fine, I didn't.  Now I've found a reason, I guess.  Ah, 
Emacs!

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: Basic citations: should default citation style have a name and style code?

[William Denton]

On Saturday, January 13th, 2024 at 14:03, Ihor Radchenko  
wrote:

> I tried to clarify about the default style and #+cite_export keyword in
> the manual:
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56f6d8d1a
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=83f17091e

Thanks!  That helps.  

While we're talking about citations, I'm stuck on something else.  If I run 
"C-c C-x @" to insert a citation into a file, I'm shown a list of bibliography 
entries and I can go up and down and hit RET on any I chose.  That works well.  
But---the prompt says, "Key (empty input exits)."  What makes empty input?  I 
can't figure it out.  I've never seen that phrase before.  I can't make it exit 
properly---I either keep adding citations or C-g or DEL cancels it---so I can't 
make the function work.  If anyone knows, I can try making a patch to make it 
clearer.

Thanks,

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada


> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 
> Support Org development at https://liberapay.com/org-mode,
> 
> or support my work at https://liberapay.com/yantar92

Re: Diary sexp and comparing dates, agenda

[David Rogers]

Ihor Radchenko  writes:


David Rogers  writes:

This setup seems to work so far. Does it look reasonable to 
you?


Yes, but I may not be a reliable judge. I do not have a lot of 
practical
experience with diary sexps other than when people report Org 
mode bugs :)


Since it looks not-stupid to you, and it gives the right answer, 
and if there WAS a mistake the risk of injuring anyone is . . . 
rather low :) , I'm declaring it good enough.


--
Thanks again
David

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>> In such scenario, we may technically violate what users ask us to do:
>>>
>>> #+begin_verse
>>> I really want newline here\\
>>> #+end_verse
>>
>> I'm not sure if users asked for that specifically.
>> ...
>> This does not:
>>
>>  #+begin_verse
>>  I really want newline here\\
>>  #+end_verse
>
> I am not sure.
> What about
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
>
> This must not be indented.

If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
that is, within a paragraph. At the end of an environment like verse
(\end{verse}) you are forced to enter vertical mode, and a new paragraph
starts. Doing something like this, for example, adds a new paragraph
after the environment:

\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
  Lorem ipsum dolor\\
\end{verse}
\lipsum[1]
\end{document}

Even this one produces the same result:

\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
  Lorem ipsum dolor\\
\end{verse}\lipsum[1]
\end{document}

If one wants, for example, that after a verse environment there is no
vertical space or indentation, the only way to do it is by modifying, globally 
or
locally (with another environment) the space after the environment and
adding a \noindent to the following paragraph:

\documentclass{article}
\usepackage{lipsum}
\setlength\partopsep{-\topsep}\addtolength\partopsep{0pt}
\begin{document}
\begin{verse}
  Lorem ipsum dolor\\
\end{verse}
\noindent\lipsum[1]
\end{document}

(taking into account that within the verse environment there is also a
left indentation that would also have to be modified).

Therefore, I think that whether or not a verse environment ends with \\ is
irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
some reason that escapes me, the space after the environment is altered.

Best regards,

Juan Manuel 

Re: [PATCH] org-babel-demarcate-block: split using element API

[gerard . vermeulen]

On 13.01.2024 16:17, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:


Attached you'll find a new patch addressing all you issues.


Thanks!
I tried to run make test, and I am getting
   FAILED  test-ob/demarcate-block  ((should (string= region-text
(org-trim (nth 1 info :form (string= "mark this line as region"
"") :value nil :explanation (arrays-of-different-length 24 0 "mark
this line as region" "" first-mismatch-at 0))


I have improved a regexp used to mark a region in this sub-test
improving the robustness of the code.
Furthermore, I have replaced all occurrences of (set-mark (point))
with (set-mark-command nil), but I doubt that this is the reason.

Nevertheless, I feel I need to point out the limitation of this 
particular

test case.

Prerequisites:
#+begin_src emacs-lisp :results silent
(setopt org-adapt-indentation t
org-edit-src-content-indentation 2
org-src-preserve-indentation nil)
#+end_src

When I mark really the line containing "mark this line as region"
C-u C-C C-v C-d works nicely (done in the sub-test).
** 10 stars with region between two lines
   #+header: :var b="also seen"
   #+begin_src any-language -i -n :var a="seen"
 to upper block
 mark this line as region
 to lower block
   #+end_src

but C-u C-c C-v C-d after marking ' this line as ' produces this:
** 10 stars with region between two lines
   #+header: :var b="also seen"
   #+begin_src any-language -i -n :var a="seen"
 to upper block
 mark
   #+end_src
**
   #+header: :var b="also seen"
   #+begin_src any-language -i -n :var a="seen"
 this line as
   #+end_src
**
   #+header: :var b="also seen"
   #+begin_src any-language -i -n :var a="seen"
region
 to lower block
   #+end_src

The text after (mark) and (point) is misaligned.
I tend to mark regions in a way that is compatible with the patch,
but some users won't (maybe they are willing to adapt).

Patch attached.

Regards -- Gerard


0001-org-babel-demarcate-block-split-using-element-API.patch
Description: Binary data

Re: Diary sexp and comparing dates, agenda

[Ihor Radchenko]

David Rogers  writes:

> This setup seems to work so far. Does it look reasonable to you?

Yes, but I may not be a reliable judge. I do not have a lot of practical
experience with diary sexps other than when people report Org mode bugs :)

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

Re: Basic citations: should default citation style have a name and style code?

[Ihor Radchenko]

Ihor Radchenko  writes:

>> "Most scholarly works have citations and a bibliography or reference 
>> section," wrote a computer scientist [cite:@friends].
>
>> As far as I can tell, there's nothing that can be done to the first
>> citation object to make it use the "default" style.  The
>> document-level setting makes a new default, and because the original
>> "default" has no name or style code, there's no way to get at it.
>
> You can just use [cite/nil:@friends].

I tried to clarify about the default style and #+cite_export keyword in
the manual:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56f6d8d1a
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=83f17091e

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> In such scenario, we may technically violate what users ask us to do:
>>
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I'm not sure if users asked for that specifically.
> ...
> This does not:
>
>  #+begin_verse
>  I really want newline here\\
>  #+end_verse

I am not sure.
What about

#+begin_verse
I really want newline here\\
#+end_verse
This must not be indented.

(Just trying to come up with valid uses of newline at the end of
LaTeX environment)

Although, the above causes Org export to fail...
\begin{verse}
This is test\\[0pt]\\[0pt]
\end{verse}
Paragraph.


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

Re: ob-shell: proposal to remove "posh"

[Ihor Radchenko]

Matt  writes:

> There was discussion about different shells, Eric asked for others, "posh" 
> was mentioned as "specially for POSIX compatibility checks", and then a 
> "posh" was added to ob-shell.el by Eric (fb09863f).
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fb09863fbb35bf15bcf78262b6e31b8b8b8617e7
>
> Around that time are a few stack exchange answers suggesting to use posh, the 
> "Policy-compliant Ordinary SHell", to test for posix compliance.  Debian 
> distributed it by saying, "using posh as your /bin/sh may reveal breakage."  
> It seems that posh was used to check for POSIX compliance.  It's still 
> available on Debian.
> https://unix.stackexchange.com/questions/48786/how-can-i-test-for-posix-compliance-of-shell-scripts
> https://web.archive.org/web/20130930231522/https://packages.debian.org/sid/posh
> https://packages.debian.org/sid/posh

It is also still available on Gentoo.

> ** No one uses the "Policy-compliant Ordinary SHell"
> The change on August 26, 2022 should have caused a breaking error for someone 
> using the "Policy-compliant Ordinary SHell."  The prompt for "posh" in 
> "org-babel-shell-set-prompt-commands" is valid PowerShell syntax (AFAIKT) and 
> invalid bash/dash syntax:
>
> function prompt { "org_babel_sh_prompt> " }
>
> It's not clear to me what this would do in the "Policy-compliant Ordinary 
> SHell."  In Bash, functions are defined using a form like:
>
> function fname [()] compound-command [ redirections ]

Simply because I struggled to find what is "posh" at the time I wrote that
code. I only found some obscure page (on the web!) saying the posh might
be PowerShell.
My commit a35d16368 did not intend to introduce anything new.

It turns out that we never supported PowerShell and never announced such
support. So we do not really need to support PowerShell.

> * My stance
> The unfortunate reality is we "support" PowerShell currently.  We have code 
> explicitly to handle PowerShell.  Changing that could, technically, break 
> someone's workflow.

We do not. It was just my mistake trying to figure out what is "posh".
Since posh is POSIX-compliant, generic PS1/PS2 variables should work, and we
do not need a special entry in `org-babel-shell-set-prompt-commands' -
we can remove "posh" record from there.

I'd rather keep the value in `org-babel-shell-names' though. It should
do no harm.

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

Re: Tableofcontents

[Tory S. Anderson]

I was unaware of latexmk; installing now! Thanks! sad that the original problem 
is not helped by it, though.

Ihor Radchenko  writes:

> web...@toryanderson.com (Tory S. Anderson) writes:
>
>> I don't run the cutting-edge org, but I often have to run my export twice to 
>> get things like page numbers correct. Maybe it's not ideal, but if you run 
>> the export a second time does it change the result?
>
> When available, Org mode uses latexmk, which takes care about running
> LaTeX as many times as necessary.
>
> In this particular case, latexmk is used. The problem is with LaTeX
> throwing critical errors. Critical enough to not produce pdf in one of
> the iterations.

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>> the last line would cause a problem? If not, I might send a patch in the
>> next few days. (I'm afraid that going back to abusing
>> replace-regexp-in-string. I can't think of any other more elegant
>> solution...).
>
> In such scenario, we may technically violate what users ask us to do:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse

I'm not sure if users asked for that specifically.

You want a new line when there is a new line.

This makes sense:

 #+begin_verse
 I really want newline here\\
 blah...
 #+end_verse

This does not:

 #+begin_verse
 I really want newline here\\
 #+end_verse

For LaTeX it is the same as this:

 #+begin_verse
 I really want newline here
 #+end_verse

But this specifically alters the expected result in LaTeX, modifying the
space after the environment:

 #+begin_verse
 I really want newline here\\[0pt]
 #+end_verse

What is the cause? I don't know. But it happens.

Best regards,

Juan Manuel 

Re: Tableofcontents

[Horst Leps]

Ihor Radchenko schrieb:

You're right. I deleted all unnecessary latex header entries from the 
orgmode file and then a complete table of contents was created. I have 
to rebuild the latex header.


Thanks.

Horst

Horst Leps  writes:


Running 'pdflatex -interaction nonstopmode  -recorder  "orgmode.tex"'


I can see a number of errors, likely originating from incorrect ox-latex
configurations for custom packages (or #+LATEX_HEADER lines in the org
file) and incorrect usage of some latex environments in the Org file.

I am not sure why you started seeing this recently, but something is
clearly off about the file you are trying to export.

Re: [PATCH] org-babel-demarcate-block: split using element API

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> Attached you'll find a new patch addressing all you issues.

Thanks!
I tried to run make test, and I am getting
   FAILED  test-ob/demarcate-block  ((should (string= region-text (org-trim 
(nth 1 info :form (string= "mark this line as region" "") :value nil 
:explanation (arrays-of-different-length 24 0 "mark this line as region" "" 
first-mismatch-at 0))

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Can anyone think of a possible scenario where removing the '\\[0pt]' in
> the last line would cause a problem? If not, I might send a patch in the
> next few days. (I'm afraid that going back to abusing
> replace-regexp-in-string. I can't think of any other more elegant
> solution...).

In such scenario, we may technically violate what users ask us to do:

#+begin_verse
I really want newline here\\
#+end_verse

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

Re: [PATCH] org-babel-demarcate-block: split using element API

[gerard . vermeulen]

Attached you'll find a new patch addressing all you issues.

I have integrated our discussion leading to
https://list.orgmode.org/87ply6nyue.fsf@localhost/
Please feel free to add the line

Co-authored-by: Ihor Radchenko 

to the commit message.  I think you should.

On 09.01.2024 15:49, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:


Attached you'll find a new patch fixing the three wrong lines in the
previous
and now the ERT test checks also for `user-error's.


Thanks!

2. Your patch does not create space between the src blocks, unlike 
what

   we have on main.
   I think that you need to (1) create a single blank lines between
   blocks (set :post-blank property to 1); (2) keep the number blank
   lines after the last block the same as in the initial block (copy
the
   :post-blank property and assign it to the last inserted src 
block).


   For C-u argument, do not do anything special - just keep the
original
   :post-blank as is. It is the closest to what we have on main.



The previous version of the patch had
+(insert (if arg (concat stars "\n") ""))
and now it has
+(insert (if arg (concat stars "\n") "\n"))
I prefer this over setting the :post-blank property because it is
simpler.


Yet, it will lead to large spacing between src blocks in the following
scenario:


#+begin_src emacs-lisp
  "This is test"
  "This is test2"
  "This is test3"
#+end_src






Paragraph.




I have used the :post-blank property to fix it.  The result is now:

#+begin_src emacs-lisp
  "This is test"
#+end_src

#+begin_src emacs-lisp
  "This is test2"
  "This is test3"
#+end_src






Paragraph.


Here is also a redone comparison between main and patch:

--- begin comparison main and patch
#+begin_src emacs-lisp :results silent
(setopt org-adapt-indentation t
org-edit-src-content-indentation 2
org-src-preserve-indentation nil))
#+end_src

* main
 C-u C-x C-v C-d
 #+CAPTION: caption.
 #+NAME: name.
 #+BEGIN_SRC emacs-lisp
   above
   ;; region
   below
 #+END_SRC
becomes
 C-u C-x C-v C-d
 #+CAPTION: caption.
 #+NAME: name.
 #+BEGIN_SRC emacs-lisp
   above

   #+END_SRC

   #+BEGIN_SRC emacs-lisp
   ;; region
   #+END_SRC

   #+BEGIN_SRC emacs-lisp
   below
 #+END_SRC
pitfall

* patch
 C-u C-x C-v C-d
 #+CAPTION: caption.
 #+NAME: name.
 #+BEGIN_SRC emacs-lisp
   above
   ;; region
   below
 #+END_SRC
becomes
 C-u C-x C-v C-d
 #+caption: caption.
 #+name: name.
 #+begin_src emacs-lisp
   above
 #+end_src

 #+begin_src emacs-lisp
   ;; region
 #+end_src

 #+begin_src emacs-lisp

   below
 #+end_src
pitfall
--- end comparison main and patch



Also, your new version of the patch will completely misbehave because 
of

setting mark. Please, use `region-beginning' and `region-end' instead.
Setting and checking mark is not to be done in Elisp - it only make
sense when transient-mark-mode is enabled.


Done. See below.


* Adding a user option for properties to set to nil in 
org-element-copy.


This may be overkill, but something like:

#+begin_src emacs-lisp :results nil :tangle no
(defcustom org-babel-demarcate-block-delete '(:caption :name)
   "List of things to delete from blocks below the upper block when
splitting blocks by demarcation.  Possible things are `:caption' to
delete \"#+CAPTION:\" keywords, `:header' to delete \"#+HEADER:\"
keywords, `:name' to delete \"#+NAME:\" keywords, and `switches'
to delete e.g. \"-i +n 10\" from the \"#+BEGIN_SRC\" line."
   :group 'org-babel
   :package-version '(Org . "9.7")
   :type '(set :tag "Things to delete when splitting blocks by
demarcation"
   (const :caption)
   (const :header)
   (const :name)
   (const :switches))
   :initialize #'custom-initialize-default
   :set (lambda (sym val)
  (set-default sym val)))
#+end_src


That would make sense. Although, we do not have to limit the possible
options to just what you listed. Arbitrary affiliated keywords might
also be excluded. For example, #+ATTR_HTML keyword is stored in src
block object as :attr_html.


I prefer to postpone work on this idea.



+  ;; To simplify the (unless ... (user-error ...)).
+  (unless (org-region-active-p) (set-mark (point)))


Setting mark causes issue in my above example.


+  ;; Test mark to be more specific than "Not at a block".
+  (unless (and (>= (point) body-beg) (<= (mark) body-end))
+(user-error "Select within the source block body to split 
it"))


Here, it is better to use `region-beginning', `point', and 
`region-end'.

`region-beginning', unlike mark and point, is guaranteed to be _before_
`region-end'. Mark may be before point, in contrast.

You can write something like

Re: [BUG] org-table-eval-formula mishandles semicolons in formulas [9.7-pre (release_9.6.14-1019-g5092ec @ /home/nick/src/emacs/org/org-mode/lisp/)]

[Ihor Radchenko]

Nick Dokos  writes:

> `org-table-eval-formula' interprets *any* semicolon in a formula as the
> beginning of a format specifier. So if the formula contains a literal
> semicolon that is not a format specifier
>
> #+TBLFM: $3='(concat "COMMENT ON public.layout_forms." $1 " IS " (rc-sq 
> $2) ";")
>
> The problem is that `org-table-eval-formula' decides that the semicolon
> is the beginning of a format specifier very early in the function and
> splits off the "specifier" from the rest of the formula, leading to
> errors when the truncated formula is evaluated later.

Confirmed.
Important.

> ThHere is a semi-reasonable workaround in that the regexp matches the
> *last* semicolon, so we can add a semicolon at the end of the formula,
> specifying an empty format, but the formula is not truncated any longer.
> If it is decided that the code must not be changed, then maybe the
> workaround could be added to the documentation (perhaps as a footnote to
> section "Emacs Lisp forms as formulas").
>
> This was reported by user `vfclists' on Emacs SE:
> 
> https://emacs.stackexchange.com/questions/80062/is-it-because-this-org-table-formula-contains-double-quotes-it-doesnt-work

We should eventually fix this bug. I do not think that we should add
workarounds into the manual.

The problem is that org-table.el code is fragile. A proper fix would
require rewriting formula parsing code to something more reliable.

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

Re: Moving to the next heading does not always work

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> REPRODUCTION STEPS:
> ...
> ACTUAL:
>
>   The cursor moves to the end of file.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c41a89676

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

Re: Tableofcontents

[Ihor Radchenko]

web...@toryanderson.com (Tory S. Anderson) writes:

> I don't run the cutting-edge org, but I often have to run my export twice to 
> get things like page numbers correct. Maybe it's not ideal, but if you run 
> the export a second time does it change the result?

When available, Org mode uses latexmk, which takes care about running
LaTeX as many times as necessary.

In this particular case, latexmk is used. The problem is with LaTeX
throwing critical errors. Critical enough to not produce pdf in one of
the iterations.

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

Re: AW: AW: Tableofcontents

[Ihor Radchenko]

Horst Leps  writes:

> Running 'pdflatex -interaction nonstopmode  -recorder  "orgmode.tex"'
> 

I can see a number of errors, likely originating from incorrect ox-latex
configurations for custom packages (or #+LATEX_HEADER lines in the org
file) and incorrect usage of some latex environments in the Org file.

I am not sure why you started seeing this recently, but something is
clearly off about the file you are trying to export.

> This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Homebrew) 
> (preloaded format=pdflatex)
> restricted \write18 enabled.
> entering extended mode
> ...
> ! LaTeX Error: Option clash for package babel.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.21 \usepackage
> {alphabeta}
> ...
> ! LaTeX Error: Option clash for package url.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.29 \usepackage
> {etoolbox}
> ...
> ! LaTeX Error: Unknown option `scrheadings' for package `scrlayer-scrpage'.
> ...
> Package hyperref Warning: Option `pagecolor' is not available anymore.

> ...
> ! Undefined control sequence.
> l.75 \toprule
>
> ! Undefined control sequence.
>  \midrule
>
> l.77 \midrule
>
> ! Undefined control sequence.
>  \bottomrule
>
> l.79 \bottomrule
>
>
> ! LaTeX Error: Environment latex undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.83 \begin{latex}
>
>
> ! LaTeX Error: Environment stylePi undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.84 \begin{stylePi}
>
>
> ! LaTeX Error: \begin{document} ended by \end{latex}.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.90 \end{latex}
>

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

Re: ob-shell: proposal to remove "posh"

[Matt]

  On Thu, 11 Jan 2024 21:30:59 +0100  Matt  wrote --- 

 > The change on August 26, 2022 should have caused a breaking error for 
 > someone using the "Policy-compliant Ordinary SHell."  The prompt for "posh" 
 > in "org-babel-shell-set-prompt-commands" is valid PowerShell syntax (AFAIKT) 
 > and invalid bash/dash syntax:
 > 
 > function prompt { "org_babel_sh_prompt> " }
 > 
 > It's not clear to me what this would do in the "Policy-compliant Ordinary 
 > SHell." 

It would cause an error.

I was able to build the "Policy-compliant Ordinary SHell" on Guix using:

#+begin_src guile
(use-modules (guix packages)
 (guix download)
 (guix build-system gnu)
 (gnu packages autotools)
 (gnu packages perl)
 ((guix licenses) #:prefix license:))

(define-public posh
  (package
(name "posh")
(version "0.14.1")
(source (origin
  (method url-fetch)
  (uri (string-append
"https://salsa.debian.org/clint/posh/-/archive/debian/;
version "/posh-debian-" version ".tar.gz"))
  (sha256
   (base32
"070xnn996cjnc5yzp5819y36sgfikkrplhri4kx5r36h1fmp641d"
(native-inputs (list autoconf automake perl))
(build-system gnu-build-system)
(home-page "https://salsa.debian.org/clint/posh;)
(synopsis "Policy-compliant Ordinary SHell")
(description
 "Policy-compliant Ordinary SHell
posh is a stripped-down version of pdksh that aims for compliance with
Debian's policy, and few extra features.")
(license (list license:gpl2+

posh
#+end_src

The result is:

ahab@pequod /gnu/store/64wiqdp9lqjgsz0jg1v1sq2b3afincrb-posh-0.14.1/bin$ ./posh
$ function prompt { "org_babel_sh_prompt> " }
./posh: function: not found

This is expected because "function" is not a keyword in the "Policy-compliant 
Ordinary SHell."  According to the man page:

#+begin_quote
name () command

  Defines the function name. See Functions below. Note that redirections
  specified after a function definition are performed whenever the
  function is executed, not when the function definition is executed.

-- https://manpages.debian.org/bookworm/posh/posh.1.en.html
#+end_quote

So, yes, indeed, commit a35d1636 introduced a breaking change for the 
"Policy-compliant Ordinary SHell."

--
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