org-beamer: Insert \framebreak between blocks

[yaxp]

Adding  a framebreak between blocks does not work.


```

#+latex_class: beamer
#+options: H:1

# [snip]

* Example :B_frame:
:PROPERTIES:
:BEAMER_opt: allowframebreaks
:BEAMER_env: frame
:END:
** This should be on frame 1
- Some text

#+LATEX: \framebreak

** This should be on frame 2
- Some text

```


Exporting this to PDF and examining the resulting file reveals that the 
\framebreak is inserted before the \end{block}.



```

% [snip]

\begin{frame}[allowframebreaks]{Example}
\begin{block}{This should be on frame 1}
\begin{itemize}
\item Some text
\framebreak % This is the offending line
\end{itemize}
\end{block}
\begin{block}{This should be on frame 2}
\begin{itemize}
\item Some text
\end{itemize}
\end{block}
\end{frame}

% [snip]

```


How do I not have this?I want the two blocks to be on different frames.


Manually fixing the .tex file fixes the issue but I don't want to do 
that for large files.



Fixed .tex file included for completion:

```

% [snip]

\begin{block}{This should be on frame 1}
\begin{itemize}
\item Some text

% ^1

\end{itemize}
\end{block}
\framebreak % Moved this line from ^1.
\begin{block}{This should be on frame 2}
\begin{itemize}
\item Some text
\end{itemize}
\end{block}

% [snip]
```

--
(yaxp me) => t

Re: Org-beamer: Have text overflows continue onto another frame

[yaxp]

That does everything I needed.


Thank you :D

On 24/10/23 19:55, Fraga, Eric wrote:

and there is some customization possible for continuation frames:

https://tex.stackexchange.com/questions/295854/how-to-edit-behaviour-of-frame-titles-during-frame-break-in-beamer

(and maybe more: still searching)


--
Yax - Former child.

[PATCH] ox-ascii.el: Consistently add brackets around links (was: Re: [RFC][PATCH] Allow to export to ascii custom link types as notes)

[Max Nikulin]

On 24/10/2023 17:40, Ihor Radchenko wrote:

Max Nikulin writes:

 [Org mode] ()
man
 man (http://man.he.net/?topic=man=all)

[...]

Should be [man] ()


Side note: it should be either just "man(1)" or "man(8)" without any URL 
for plain text export, but it is another story.



internal
 heading (See section 1)

[...]

Hmm.. I do see a problem now. To be consistent, it should be

[heading] (See section 1)


See the attached patch.

After:

--- 8< ---
web
  [Org mode] ()
man
  [man] ()
internal
  [heading] (See section 1)


1 Heading
═
--- >8 ---

Before:

--- 8< ---
web
  [Org mode] ()
man
  man (http://man.he.net/?topic=man=all)
internal
  heading (See section 1)


1 Heading
═
--- >8 ---

I would consider

--- 8< ---
web
  Org mode 
man
  man 
internal
  heading (See section 1)


1 Heading
═
--- >8 ---

but inconsistency is worse anyway.From 3434fdf9b1669304ed2051c89554efc9922c5feb Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 24 Oct 2023 21:45:36 +0700
Subject: [PATCH] ox-ascii.el: Consistently add brackets around links

* lisp/ox-ascii.el (org-ascii-link): Add square brackets around
description of fuzzy links when they are exported inline.
* lisp/ol-docview.el (org-docview-export):
* lisp/ox-ascii.el (org-ascii-link): Export links with square brackets
around description and angle brackets around path.

This make export of links inline (when `org-ascii-links-to-notes' is
nil) consistent with "http:" links: "[DESC] ()".

I would drop brackets for "http:" and similar links instead
("DESC ()" or even "DESC "), but any case I prefer
consistency.

Ihor Radchenko to emacs-orgmode. Re: [RFC][PATCH] Allow to export to
ascii custom link types as notes. Tue, 24 Oct 2023 10:40:41 +.

---
 lisp/ol-docview.el | 2 +-
 lisp/ol-man.el | 2 +-
 lisp/ox-ascii.el   | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lisp/ol-docview.el b/lisp/ol-docview.el
index bb9b34a17..bcb26520b 100644
--- a/lisp/ol-docview.el
+++ b/lisp/ol-docview.el
@@ -67,7 +67,7 @@ (defun org-docview-export (link description backend _info)
   (cond
((eq backend 'html) (format "%s" path desc))
((eq backend 'latex) (format "\\href{%s}{%s}" path desc))
-   ((eq backend 'ascii) (format "%s (%s)" desc path))
+   ((eq backend 'ascii) (format "[%s] (<%s>)" desc path))
(t path)
 
 (defun org-docview-open (link _)
diff --git a/lisp/ol-man.el b/lisp/ol-man.el
index abe79086a..645a6108e 100644
--- a/lisp/ol-man.el
+++ b/lisp/ol-man.el
@@ -91,7 +91,7 @@ (defun org-man-export (link description backend)
  ((eq backend 'html) (format "%s" path desc))
  ((eq backend 'latex) (format "\\href{%s}{%s}" path desc))
  ((eq backend 'texinfo) (format "@uref{%s,%s}" path desc))
- ((eq backend 'ascii) (format "%s (%s)" desc path))
+ ((eq backend 'ascii) (format "[%s] (<%s>)" desc path))
  ((eq backend 'md) (format "[%s](%s)" desc path))
  (t path
 
diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index 110bb4601..ae4273489 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -1607,9 +1607,9 @@ (defun org-ascii-link (link desc info)
 	  ((guard desc)
 	   (if (plist-get info :ascii-links-to-notes)
 	   (format "[%s]" desc)
-	 (concat desc
-		 (format " (%s)"
-			 (org-ascii--describe-datum destination info)
+	 (format "[%s] (%s)"
+ desc
+		 (org-ascii--describe-datum destination info
 	  ;; External file.
 	  (`plain-text destination)
 	  (`headline
-- 
2.39.2

Best practice for writing and debugging shell source blocks?

[Tim Landscheidt]

Hi,

inspired by "Literate DevOps"
(https://howardism.org/Technical/Emacs/literate-devops.html),
I want to document some "stuff" in an Org file with the goal
to be able to replay the steps done in the future so that I
can either recreate the same "product" or variations there-
of.

My actual topic involves (inter alia) containers, but for
simplicity, let us assume that I want to document the se-
quence of shell commands:

| $ mktemp
| /tmp/tmp.gSffc4XtQ0
| $ echo a >> /tmp/tmp.gSffc4XtQ0
| $ echo b >> /tmp/tmp.gSffc4XtQ0
| $ fgrep -x a /tmp/tmp.gSffc4XtQ0
| a
| $

In other words: An "entity" is created and its identifier
shown, this entity is then referenced by this identifier,
changed and queried.

If I put the shell commands in one source block each:

| #+NAME: create-temporary-file
| #+BEGIN_SRC sh
| mktemp
| #+END_SRC

| #+BEGIN_SRC sh :var tmpfile=create-temporary-file
| echo a >> $tmpfile
| #+END_SRC

| #+BEGIN_SRC sh :var tmpfile=create-temporary-file
| echo b >> $tmpfile
| #+END_SRC

| #+BEGIN_SRC sh :var tmpfile=create-temporary-file
| fgrep -x a $tmpfile
| #+END_SRC

and then evaluate the last source block, it calls the source
block create-temporary-file, then searches the (empty) file
and fails, i. e. the second and third source blocks are not
evaluated at all.  (Dealing with failing shell commands is
another headache—thankfully, the trick at
https://emacs.stackexchange.com/questions/59875/org-src-block-does-not-return-any-output
(provide header arguments :prologue "exec 2>&1" and
:epilogue ":") works reasonably well.)

Adding more to the confusion, if I manually evaluate the
first source block (create-temporary-file), it produces for
example:

| #+RESULTS: create-temporary-file
| : /tmp/tmp.lOKZtyJ124

If I then evaluate the last source block (again), the first
code block gets called, but its (different) result gets only
passed to the last source block and used there, while the
"#+RESULTS" section stays the same.

The same thing happens if I add ":session my-test" to all
source blocks, except that I get an additional buffer
"my-test" with the content:

| mktemp
| sh-5.2$ echo 'org_babel_sh_eoe'
| /tmp/tmp.e19GfJsH7w
| sh-5.2$ org_babel_sh_eoe
| sh-5.2$ tmpfile='/tmp/tmp.e19GfJsH7w'
| sh-5.2$ fgrep -x a $tmpfile
| sh-5.2$ echo 'org_babel_sh_eoe'
| org_babel_sh_eoe
| sh-5.2$

where the "mixed" output of "mktemp" and "echo
'org_babel_sh_eoe'" does not necessarily instill confidence
to run commands that are destructive in nature.

So what is The Right Way™ to document sequences of shell
commands so that they are evaluated in sequence, being able
to refer to the output of previous commands?  Are there any
obvious collections of examples that I missed?

TIA,
Tim

Re: Org-beamer: Have text overflows continue onto another frame

[Fraga, Eric]

and there is some customization possible for continuation frames:

https://tex.stackexchange.com/questions/295854/how-to-edit-behaviour-of-frame-titles-during-frame-break-in-beamer

(and maybe more: still searching)

-- 
: Eric S Fraga, with org release_9.6.7-661-g34ee6f in Emacs 30.0.50

Re: Colons in :var header arguments

[Stefano Ghirlanda]

Thanks, and sorry for the slow reply! I was wondering if it would be
more intuitive to try to resolve the reference in the same file before
looking in other files. I think this would make little practical
difference as I think files named sec, tab, eq and fig are rare
(although I often use fig for a figure directory, I wonder what
happens then). But looking externally first is more compatible with
current behavior, so maybe that should have priority.

Thanks again for considering.

On Sat, Oct 21, 2023 at 3:11 AM Ihor Radchenko  wrote:
>
> Stefano Ghirlanda  writes:
>
> > I have run into an inconvenience in that colons in :var header
> > arguments to source blocks are invariably interpreted as referring to
> > another file. However, I use cleveref in LaTeX export (via org-ref) to
> > automatically format references using labels like tab:data, and in
> > these cases :var data=tab:data gives a reference not found because tab
> > is interpreted as a filename.
>
> I agree that it is a problem.
> Attaching tentative patch that will make Org babel fall back to
> searching in current file when FILE in FILE:REF does not exist.
>
> It is technically a breaking change. If this is affecting someone's
> workflow, please chime in.
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



-- 
Stefano Ghirlanda
CTO, DataWorks - https://dataworks.consulting
Guest Professor - Stockholm University Centre for Cultural Evolution

Re: Org-beamer: Have text overflows continue onto another frame

[yaxp]

That works, thank you. The default titling scheme will have to suffice 
for now then methinks.


On 24/10/23 18:47, Fraga, Eric wrote:

On Tuesday, 24 Oct 2023 at 17:56, yaxp wrote:

How do I have overflowing text continue on a new frame? Ideally, in a
way that lets me also customize the title of this new frame

You can easily do the former by adding

:BEAMER_opt: allowframebreaks

to the PROPERTIES for any frame that needs to overflow unto subsequent
frames.  By default, the new frames have I, II, III, ... appended to
their title.  I am not sure if that behaviour can be customised,
however.


--
Yax - Former child.

Re: Org-beamer: Have text overflows continue onto another frame

[Fraga, Eric]

On Tuesday, 24 Oct 2023 at 17:56, yaxp wrote:
> How do I have overflowing text continue on a new frame? Ideally, in a
> way that lets me also customize the title of this new frame

You can easily do the former by adding

:BEAMER_opt: allowframebreaks

to the PROPERTIES for any frame that needs to overflow unto subsequent
frames.  By default, the new frames have I, II, III, ... appended to
their title.  I am not sure if that behaviour can be customised,
however.

-- 
: Eric S Fraga, with org release_9.6.6-418-g294a4d in Emacs 30.0.50

Org-beamer: Have text overflows continue onto another frame

[yaxp]

How do I have overflowing text continue on a new frame? Ideally, in a 
way that lets me also customize the title of this new frame


Sample org file below.


#+title: Beamer Test
#+LANGUAGE: en
#+options: H:1 toc:nil
#+latex_class: beamer
#+columns: %45ITEM %10BEAMER_env(Env) %10BEAMER_act(Act) 
%4BEAMER_col(Col) %8BEAMER_opt(Opt)

#+beamer_theme: default

* Example :B_frame:
:PROPERTIES:
:BEAMER_env: frame
:END:
- Export this file a pdf
- Lot's of text there is a lot of text here wowowowow so much text. The 
text just keeps on going oo
- Lot's of text there is a lot of text here wowowowow so much text. The 
text just keeps on going oo
- Lot's of text there is a lot of text here wowowowow so much text. The 
text just keeps on going oo
- Lot's of text there is a lot of text here wowowowow so much text. The 
text just keeps on going oo
- Lot's of text there is a lot of text here wowowowow so much text. The 
text just keeps on going oo
- Lot's of text there is a lot of text here wowowowow so much text. The 
text just keeps on going oo

- The text is different now 
- The text is different now 
- The text is different now 
- The text is different now 
- Everything from here should be on a new frame
  - but where did the text go :(


--
Yax - Former child.

Re: the opposite of the noexport tag

[Uwe Brauer]

> Uwe Brauer  writes:

> I find this part confusing - we first talk about no "export" tags at all
> and then immediately about using with "export" tags. I dropped it in the
> attached patch. Maybe there is a better way to formulate the same?

> In the attached patch, I incorporated your other changes, the grammar
> remarks from Loris, and reworded a bit more.

That looks good to me thanks. I appreciate the sentence 
,
| +  Note that a file without the =export= or the =noexport= tag will
| +  export all its sections.
`


smime.p7s
Description: S/MIME cryptographic signature

Re: [BUG] CI jobs do not appear to be running

[Bastien Guerry]

Ihor Radchenko  writes:

> It does not look like there is any improvement.

Yes, something is wrong with cron. I'll have a look this week-end,
I don't have a stable connection right now.

-- 
 Bastien Guerry

Re: the opposite of the noexport tag

[Ihor Radchenko]

"Loris Bennett"  writes:

>> +  List of tags that will *only* be selected for export.  The default
>
> I find the emphasised 'only' confusing here, since it implies to me
> there the tags might have some other function.  I would find, in analogy
> to the corresponding text regarding exclude tags, the following text
> better:
>
>   List of tags that will be included in the export.

> I assume that 'only' was meant to imply that the list of tags is
> exclusive in the sense that no other tags will be exported.  However,
> talking about an 'exclusive list' the context of what will be included
> in the export is probably not going to be helpful.

What about

  List of tags that will, if present, be selected for export.  The
  default value is ~org-export-select-tags~ =("export")=.  When a tree
  is tagged with =export=, Org selects that tree and its subtrees for
  export, ignoring all the other sections that do not possess the
  =export= tag.

  When selectively exporting files with =export= tags set, Org does
  not export any text that appears before the first headline.

  Note that a file without the =export= tags will export all its
  sections.

> Note that the keywords SELECT_TAGS and EXCLUDE_TAGS are not proper
> antonyms, which might be a possible source of confusion.  I don't know
> how feasible it would be to replace (at least in the sense of an alias),
> these terms with, say,
>
>   EXPORT_INCLUDE_TAGS
>   EXPORT_EXCLUDE_TAGS

They are not exactly antonyms, because there is also the default
behavior with neither export nor noexport tags. With "export" tags,
everything but what is tagged "export" is dropped, including subtrees
without "export" tag.

With "noexport" tags, only the subtrees explicitly tagged "noexport" are
dropped. The subtrees with no "noexport"/"export" tags will still be
exported.

As for EXPORT_... prefix, we do not use it, except in heading
properties. It is by convention.

In any case, I do not see a big problem with the current terminology. It
is to late too change it, unless there is a stronger reason.

>> +  List o tags that will be excluded from export.  The default value is
>
> There is an 'f' missing in
>
>   List o tags

Fixed

New version of the patch attached.

>From 5c6d1741519e02a3b9d2774faf511b0b90a4c788 Mon Sep 17 00:00:00 2001
Message-ID: <5c6d1741519e02a3b9d2774faf511b0b90a4c788.1698145210.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 23 Oct 2023 15:30:42 +0300
Subject: [PATCH v3] * doc/org-manual.org: Improve documentation for
 #+SELECT_TAGS and #+EXCLUDE_TAGS

(Export Settings): Clarify how to define multiple tags per-document.  Reword.

Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
---
 doc/org-manual.org | 38 +++---
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index c0e9c8d7e..85568e7ab 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12053,22 +12053,38 @@ ** Export Settings
 
   #+cindex: @samp{SELECT_TAGS}, keyword
   #+vindex: org-export-select-tags
-  The default value is =("export")=.  When a tree is tagged with
-  =export= (~org-export-select-tags~), Org selects that tree and its
-  subtrees for export.  Org excludes trees with =noexport= tags, see
-  below.  When selectively exporting files with =export= tags set, Org
-  does not export any text that appears before the first headline.
+  List of tags that will, if present, be selected for export.  The
+  default value is ~org-export-select-tags~ =("export")=.  When a tree
+  is tagged with =export=, Org selects that tree and its subtrees for
+  export, ignoring all the other sections that do not possess the
+  =export= tag.
+
+  When selectively exporting files with =export= tags set, Org does
+  not export any text that appears before the first headline.
+
+  Note that a file without the =export= tags will export all its
+  sections.
+
+  To select non-default tags for export, customize
+  ~org-export-select-tags~ (globally) or add =#+SELECT_TAGS: tag1
+  tag2= to the document.
 
 - =EXCLUDE_TAGS= ::
 
   #+cindex: @samp{EXCLUDE_TAGS}, keyword
   #+vindex: org-export-exclude-tags
-  The default value is =("noexport")=.  When a tree is tagged with
-  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
-  its subtrees from export.  Entries tagged with =noexport= are
-  unconditionally excluded from the export, even if they have an
-  =export= tag.  Even if a subtree is not exported, Org executes any
-  code blocks contained there.
+  List of tags that will be excluded from export.  The default value is
+  ~org-export-exclude-tags~ =("noexport")=.  When a tree is tagged
+  with =noexport=, Org excludes that tree and its subtrees from
+  export.
+
+  Entries tagged with =noexport= are unconditionally excluded from the
+  export, even if they have an =export= tag.  Even if a subtree is not
+  exported, Org executes any code blocks contained there.
+
+  To select 

Re: [RFC][PATCH] Allow to export to ascii custom link types as notes

[Ihor Radchenko]

Max Nikulin  writes:

> However "cond form will work without changes" is not clear for me. 
> `org-export-custom-protocol-maybe' is called twice and depending on 
> context the result should be either "[description]" inline or 
> "[description] path" for note, so the code around 
> `org-export-custom-protocol-maybe' has to be changed.

I see.
What about (1) passing link object to custom protocol, (2) making
`org-ascii-make-link-with-note' marking the link object to be recorded
in notes; (3) modifying `org-ascii--describe-links' to check for the
recorded mark before the `cond' clause (org-export-custom-protocol-maybe...).

>>> [Org mode] ()
>>> man
>>> man (http://man.he.net/?topic=man=all)
>> 
>> This is probably a bug in ol-man.
>
> Which one? Absence of square brackets? Absence of angle brackets? Both?

Should be [man] ()

>>> internal
>>> heading (See section 1)
>> 
>> I see no problem here - internal links are special, and it makes sense to
>> drop angle brackets, unlike external web links that are often marked
>> with angle brackets in the wild.
>
> Due to absence of square brackets around "heading" it should be treated 
> differently from e.g. http links.

Hmm.. I do see a problem now. To be consistent, it should be

[heading] (See section 1)

By "special" I meant URL/path part.

> ... It is the reason why I added a regexp 
> to detect if a caller added square brackets:
>
>>> +   (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
>>> +   anchor
>>> +(format "[%s]" anchor))

I still fail to see how it is related to the problem at hand: "Allow to
export to ascii custom link types as notes". We had this problem for
non-custom links in the past and we still have it. It should be solved
separately.

> I do not like repetitions in the current code.

Me either. But let's address them separately. Otherwise, it is very hard
to keep track of the discussion.

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

Re: the opposite of the noexport tag

[Loris Bennett]

Ihor Radchenko  writes:

> Uwe Brauer  writes:
>
>>> Uwe Brauer  writes:
 I recommend then to clarify this is in the manual: the expression in the 
 manual is 
 `("export")'
>>
>>> What about the attached patch?
>>
>> I added some lines, and run rediff and I hoper therefore the modified patch 
>> is ok.
>>
>>
>> Feel free to use it
>> +  This tag is useful, if the =export= tag is not used on other sections.
>> +  When a tree is tagged
>> +  with =noexport=, Org excludes that tree and its subtrees from
>> +  export.  
>
> I find this part confusing - we first talk about no "export" tags at all
> and then immediately about using with "export" tags. I dropped it in the
> attached patch. Maybe there is a better way to formulate the same?
>
> In the attached patch, I incorporated your other changes, the grammar
> remarks from Loris, and reworded a bit more.
>
> From c82ec6139269cfc5dabf0e2e4d3601143843c782 Mon Sep 17 00:00:00 2001
> Message-ID: 
> 
> From: Ihor Radchenko 
> Date: Mon, 23 Oct 2023 15:30:42 +0300
> Subject: [PATCH v2] * doc/org-manual.org: Improve documentation for
>  #+SELECT_TAGS and #+EXCLUDE_TAGS
>
> (Export Settings): Clarify how to define multiple tags per-document.  Reword.
>
> Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
> ---
>  doc/org-manual.org | 38 +++---
>  1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index c0e9c8d7e..7e4553668 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -12053,22 +12053,38 @@ ** Export Settings
>  
>#+cindex: @samp{SELECT_TAGS}, keyword
>#+vindex: org-export-select-tags
> -  The default value is =("export")=.  When a tree is tagged with
> -  =export= (~org-export-select-tags~), Org selects that tree and its
> -  subtrees for export.  Org excludes trees with =noexport= tags, see
> -  below.  When selectively exporting files with =export= tags set, Org
> -  does not export any text that appears before the first headline.
> +  List of tags that will *only* be selected for export.  The default

I find the emphasised 'only' confusing here, since it implies to me
there the tags might have some other function.  I would find, in analogy
to the corresponding text regarding exclude tags, the following text
better:

  List of tags that will be included in the export.

I assume that 'only' was meant to imply that the list of tags is
exclusive in the sense that no other tags will be exported.  However,
talking about an 'exclusive list' the context of what will be included
in the export is probably not going to be helpful.

Note that the keywords SELECT_TAGS and EXCLUDE_TAGS are not proper
antonyms, which might be a possible source of confusion.  I don't know
how feasible it would be to replace (at least in the sense of an alias),
these terms with, say,

  EXPORT_INCLUDE_TAGS
  EXPORT_EXCLUDE_TAGS

> +  value is ~org-export-select-tags~ =("export")=.  When a tree is
> +  tagged with =export=, Org selects that tree and its subtrees for
> +  export, ignoring all the other sections that do not possess the
> +  =export= tag.
> +
> +  When selectively exporting files with =export= tags set, Org does
> +  not export any text that appears before the first headline.
> +
> +  Note that a file without the =export= or the =noexport= tag will
> +  export all its sections.
> +
> +  To select non-default tags for export, customize
> +  ~org-export-select-tags~ (globally) or add =#+SELECT_TAGS: tag1
> +  tag2= to the document.
>  
>  - =EXCLUDE_TAGS= ::
>  
>#+cindex: @samp{EXCLUDE_TAGS}, keyword
>#+vindex: org-export-exclude-tags
> -  The default value is =("noexport")=.  When a tree is tagged with
> -  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
> -  its subtrees from export.  Entries tagged with =noexport= are
> -  unconditionally excluded from the export, even if they have an
> -  =export= tag.  Even if a subtree is not exported, Org executes any
> -  code blocks contained there.
> +  List o tags that will be excluded from export.  The default value is

There is an 'f' missing in

  List o tags

(or an apostrophe in Pirate English).

> +  ~org-export-exclude-tags~ =("noexport")=.  When a tree is tagged
> +  with =noexport=, Org excludes that tree and its subtrees from
> +  export.
> +
> +  Entries tagged with =noexport= are unconditionally excluded from the
> +  export, even if they have an =export= tag.  Even if a subtree is not
> +  exported, Org executes any code blocks contained there.
> +
> +  To select non-default tags for the exclusion, customize
> +  ~org-export-exclude-tags~ (globally) or add =#+EXCLUDE_TAGS: tag1
> +  tag2= to the document.
>  
>  - =TITLE= ::
>  
> -- 
> 2.42.0
-- 
This signature is currently under constuction.

Re: org-ditaa woes

[Ihor Radchenko]

Florin Boariu  writes:

> I can offer to try my luck with writing a patch for ob-ditaa.el, but
> I'm not knowledgeable enough (or have enough time on my hands) to
> actually keep maintaining it :-p

Writing a patch is also welcome.

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

Re: No-description <> links

[Ihor Radchenko]

Max Nikulin  writes:

>> The main problem is how to properly design
>> this - the current approach is that individual backends decide. And we
>> have no control over third-party backends...
>
> If it were possible to customize fuzzy links through 
> `org-link-parameters' then Rudolf would be able to easily try if 
> proposed changes are feasible and to debug them in real life cases 
> before adding them to Org code.

I am afraid that supporting `org-link-parameters' for built-in link
types is much harder to implement compared to addressing the <>
description problem.

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

Re: org-ditaa woes

[Florin Boariu]

Hello,


I hope, a couple of workarounds are still possible.

1. Get java command by adding bash -x (or /usr/bin/bash, or 
"/usr/bin/env bash")


   flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
   /tmp/foo.txt -o /tmp/foo.png

- set `org-babel-ditaa-java-cmd' to something like
   "flatpak-spawn --host toolbox run /usr/bin/java",
- set `org-ditaa-jar-path' to path to ditaa.jar reported by the 
command above,


There are a lot of assumptions baked into this one, for starters: that
I can actually do "java -jar $PATH_REPORTED_BY_COMMAND.jar" actually
works.

It doesn't:

sh-5.1$ flatpak-spawn --host toolbox run java -jar /usr/share/java/ditaa.jar
Error: Unable to initialize main class 
org.stathissideris.ascii2image.core.CommandLineConverter
Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/cli/ParseException

路

- add other options to either `org-babel-header-args:ditaa' :java 
property or to `org-babel-ditaa-java-cmd'
- perhaps add /usr/bin/env JAVA_HOME=... and other required 
environment variables before java binary.


...and now I, despite not being a Java developer, need to figure out
how to debug the execution of a program I didn't develop (in a
language I'm not familiar with), and for which a perfectly functional
script was _already_ delivered by my distribution in the form of
"/usr/bin/ditaa" ;-)

What actually _does_ work (and what I'm currently indeed using as a
workaround) is download my own copy of ditaa.jar from their website,
put it under ~/.local/share/ditaa/ditaa.jar, and set
'org-ditaa-jar-path' to that specific value.

This still leaves me with the necessity to download a package through
a side channel which already exists in my distribution as a pacakge,
but at least I don't need to get into the bowels of Java to run it.


2.
- set `org-babel-ditaa-java-cmd' to
 "flatpak-spawn --host toolbox run /usr/bin/ditaa".
- set `org-ditaa-jar-option' to empty string.
- Call of `shell-quote-argument' makes it impossible to set 
`org-ditaa-jar-path' to empty string, so set the following variables 
to some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added 
through :java babel header argument):

 + `org-ditaa-jar-path'
 + `org-ditaa-eps-jar-path'


I'm not sure whether I had thought of that (-Dfile.encoding is not
recognized by recent ditaa, BTW, I think they have a new option for
that). I think I had, but got stuck at "set org-ditaa-jar-option to
empty string" :-D  IIRD it threw an error (the one you said it would),
and that's where I stopped investigating.

I agree that it should be possible to call ditaa executable directly. 
Perhaps it is not possible because for a long time ditaa.jar was a 
part of Org mode repository (there were a lot of messages against 
dropping of jar files from the repository).


I'm not sure having the .jar in the repository would even help in my
case, unless the Emacs Flatpak specifically also shipped with a Java
runtime. (And I think we agree that this shouldn't happen -- Emacs is
a perfectly usable OS in its own right, no need for Java on top ;-) ).
Because otherwise the .jar would be inside the Flatpak, and the
runtime would be somewhere else from where it couldn't access the .jar.


It seems, nobody is ready to take responsibility and to become
maintainer of ob-ditaa.el while active users have no ability to
install ditaa as a package, so they anyway have to download .jar from
upstream.


I can offer to try my luck with writing a patch for ob-ditaa.el, but
I'm not knowledgeable enough (or have enough time on my hands) to
actually keep maintaining it :-p

I find it tedious to add "flatpak-spawn ..." to every tool used by 
Emacs. Who is the publisher of the flatpak? I would expect a directory 
with symlinks named ditaa, java, git, gcc, cpp, etc to a script line


#!/bin/sh
exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"

(or "$(basename "$0")")

mounted to flatpak runtime and added to $PATH. Perhaps another 
approach exist and it should be discussed with the packager and Emacs 
developers.


It's a double-edged sword. Not every Flatpak distribution actually has
a Toolbox infrastructure, too... (Flatpak didn't get invented with, or
for, Fedora Silverblue; it was around for a long time before that. But
Toolbox did.) So for most, "flatpak-spawn --host $CMD" would be the
way to go, not "...toolbox run $CMD". And even in Toolbox systems,
there can be more than one toolbox, so some might want to run
"...toolbox run -c gcc-devel $CMD ...", where "gcc-devel" is a
specific toolbox for GCC development.

But with regards to the Emacs Flatpak: gcc, cpp and gitare part of it:

sh-5.1$ which git
/usr/bin/git
sh-5.1$ which gcc
/usr/bin/gcc
sh-5.1$

(I'm guessing they're actually part of the underlying SDK -- Flatpaks
apparently are a kind of "layered system", where specific applications
can build upon the same support).

But Java and Ditaa aren't:

sh-5.1$ which java
which: no java in 

Re: [BUG] org-element--cache Cached element is incorrect (ox-hugo) [9.6.10 (release_9.6.10 @ /home/gk/.emacs.d/lib/org/lisp/)]

[Ihor Radchenko]

George Kettleborough  writes:

> I've been having a problem where some of my exports get truncated
> randomly at the end. I haven't been able to figure out the exact
> problem, but by bisecting org-mode I found the problem appears in
> 072ddbc9 which sets `org-element--cache-self-verify' to t. By setting
> this back to nil manually the truncation goes away, but the warning then
> appears.
>
> Interestingly I can only reproduce this when running emacs in batch
> mode, not in regular mode.
>
> I know ox-hugo and caching has come up before, but I don't think this
> was the same problem as before.

Thanks for reporting!
Do you happen to have a reproducer?
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: [BUG] code block side effects differences between "results: none" and "results: silent" [9.6.9 ( @ /home/jet/.config/emacs/elpa/org-9.6.9/)]

[Ihor Radchenko]

Jeff Trull  writes:

> In the following code block, a propertized (inverse video) before-string
> overlay appears when "results: none" is used, but the property is absent
> (the overlay text appears normal) when "results:silent" is used:
>
> # with ":results none" it works as expected - inverse video Foo appears
> # with ":results silent" the string appears normally
> #+begin_src emacs-lisp :results none
>   (let ((buf (generate-new-buffer "side-effect-demo")))
>   (with-current-buffer buf
> (let ((ov (make-overlay 0 (point
>   (overlay-put ov 'before-string (propertize "Foo" 'face
> '(:inverse-video t))
> #+end_src

Fixed, on bugfix.
Thanks for reporting!
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=84fa57ad1

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

Re: the opposite of the noexport tag

[Ihor Radchenko]

Uwe Brauer  writes:

>> Uwe Brauer  writes:
>>> I recommend then to clarify this is in the manual: the expression in the 
>>> manual is 
>>> `("export")'
>
>> What about the attached patch?
>
> I added some lines, and run rediff and I hoper therefore the modified patch 
> is ok.
>
>
> Feel free to use it
> +  This tag is useful, if the =export= tag is not used on other sections.
> +  When a tree is tagged
> +  with =noexport=, Org excludes that tree and its subtrees from
> +  export.  

I find this part confusing - we first talk about no "export" tags at all
and then immediately about using with "export" tags. I dropped it in the
attached patch. Maybe there is a better way to formulate the same?

In the attached patch, I incorporated your other changes, the grammar
remarks from Loris, and reworded a bit more.

>From c82ec6139269cfc5dabf0e2e4d3601143843c782 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Mon, 23 Oct 2023 15:30:42 +0300
Subject: [PATCH v2] * doc/org-manual.org: Improve documentation for
 #+SELECT_TAGS and #+EXCLUDE_TAGS

(Export Settings): Clarify how to define multiple tags per-document.  Reword.

Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
---
 doc/org-manual.org | 38 +++---
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index c0e9c8d7e..7e4553668 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12053,22 +12053,38 @@ ** Export Settings
 
   #+cindex: @samp{SELECT_TAGS}, keyword
   #+vindex: org-export-select-tags
-  The default value is =("export")=.  When a tree is tagged with
-  =export= (~org-export-select-tags~), Org selects that tree and its
-  subtrees for export.  Org excludes trees with =noexport= tags, see
-  below.  When selectively exporting files with =export= tags set, Org
-  does not export any text that appears before the first headline.
+  List of tags that will *only* be selected for export.  The default
+  value is ~org-export-select-tags~ =("export")=.  When a tree is
+  tagged with =export=, Org selects that tree and its subtrees for
+  export, ignoring all the other sections that do not possess the
+  =export= tag.
+
+  When selectively exporting files with =export= tags set, Org does
+  not export any text that appears before the first headline.
+
+  Note that a file without the =export= or the =noexport= tag will
+  export all its sections.
+
+  To select non-default tags for export, customize
+  ~org-export-select-tags~ (globally) or add =#+SELECT_TAGS: tag1
+  tag2= to the document.
 
 - =EXCLUDE_TAGS= ::
 
   #+cindex: @samp{EXCLUDE_TAGS}, keyword
   #+vindex: org-export-exclude-tags
-  The default value is =("noexport")=.  When a tree is tagged with
-  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
-  its subtrees from export.  Entries tagged with =noexport= are
-  unconditionally excluded from the export, even if they have an
-  =export= tag.  Even if a subtree is not exported, Org executes any
-  code blocks contained there.
+  List o tags that will be excluded from export.  The default value is
+  ~org-export-exclude-tags~ =("noexport")=.  When a tree is tagged
+  with =noexport=, Org excludes that tree and its subtrees from
+  export.
+
+  Entries tagged with =noexport= are unconditionally excluded from the
+  export, even if they have an =export= tag.  Even if a subtree is not
+  exported, Org executes any code blocks contained there.
+
+  To select non-default tags for the exclusion, customize
+  ~org-export-exclude-tags~ (globally) or add =#+EXCLUDE_TAGS: tag1
+  tag2= to the document.
 
 - =TITLE= ::
 
-- 
2.42.0



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

Re: [BUG] CI jobs do not appear to be running

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Still nothing, even though I did not address some recent
>> failures, like "FAILED ob-octave/session-multiline".
>
> I've pushed a fix, it should be okay now.
>
> I've also updated the script which mirrors the main Org repository to
> GitHub and Sourcehut, things are kept in sync every 3 hours.

It does not look like there is any improvement.

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

Re: No-description <> links

[Max Nikulin]

On 23/10/2023 15:15, Ihor Radchenko wrote:

I wonder, why not export [[link]] to <> as "link" by default, if
no description is given, as is the case with URLs, Elisp, and the
like?

Yes, something like that.

The main problem is how to properly design
this - the current approach is that individual backends decide. And we
have no control over third-party backends...


If it were possible to customize fuzzy links through 
`org-link-parameters' then Rudolf would be able to easily try if 
proposed changes are feasible and to debug them in real life cases 
before adding them to Org code.

Re: [RFC][PATCH] Allow to export to ascii custom link types as notes

[Max Nikulin]

On 23/10/2023 19:09, Ihor Radchenko wrote:

Max Nikulin writes:

Then, `org-ascii-make-link-with-note' may as well receive and modify
INFO plist. This way, ((org-export-custom-protocol-maybe link desc 'ascii info))
cond form will work without changes as `org-ascii-make-link-with-note`
will do all the necessary processing.


Adding INFO argument is a bit more burden for users, but, I think, it is 
acceptable.


However "cond form will work without changes" is not clear for me. 
`org-export-custom-protocol-maybe' is called twice and depending on 
context the result should be either "[description]" inline or 
"[description] path" for note, so the code around 
`org-export-custom-protocol-maybe' has to be changed.



angle and square brackets inconsistency

--- 8< ---
# (require 'ol-man)
# (setq org-ascii-links-to-notes nil)

- web :: [[http://orgmode.org][Org mode]]
- man :: [[man:man][man]]
- internal :: [[Heading][heading]]

* Heading
--- >8 ---
--- 8< ---
web
[Org mode] ()
man
man (http://man.he.net/?topic=man=all)


This is probably a bug in ol-man.


Which one? Absence of square brackets? Absence of angle brackets? Both?


internal
heading (See section 1)


I see no problem here - internal links are special, and it makes sense to
drop angle brackets, unlike external web links that are often marked
with angle brackets in the wild.


Due to absence of square brackets around "heading" it should be treated 
differently from e.g. http links. It is the reason why I added a regexp 
to detect if a caller added square brackets:



+   (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
+   anchor
+(format "[%s]" anchor))


I do not like repetitions in the current code.

Re: org-ditaa woes

[Max Nikulin]

On 23/10/2023 18:18, Florin Boariu wrote:


sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa /tmp/foo.txt 
-o /tmp/foo.png


thanks


I really _need_ to generically execute a command.


I hope, a couple of workarounds are still possible.

1. Get java command by adding bash -x (or /usr/bin/bash, or 
"/usr/bin/env bash")


flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
/tmp/foo.txt -o /tmp/foo.png

- set `org-babel-ditaa-java-cmd' to something like
"flatpak-spawn --host toolbox run /usr/bin/java",
- set `org-ditaa-jar-path' to path to ditaa.jar reported by the command 
above,
- add other options to either `org-babel-header-args:ditaa' :java 
property or to `org-babel-ditaa-java-cmd'
- perhaps add /usr/bin/env JAVA_HOME=... and other required environment 
variables before java binary.



2.
- set `org-babel-ditaa-java-cmd' to
  "flatpak-spawn --host toolbox run /usr/bin/ditaa".
- set `org-ditaa-jar-option' to empty string.
- Call of `shell-quote-argument' makes it impossible to set 
`org-ditaa-jar-path' to empty string, so set the following variables to 
some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added 
through :java babel header argument):

  + `org-ditaa-jar-path'
  + `org-ditaa-eps-jar-path'


I agree that it should be possible to call ditaa executable directly. 
Perhaps it is not possible because for a long time ditaa.jar was a part 
of Org mode repository (there were a lot of messages against dropping of 
jar files from the repository). It seems, nobody is ready to take 
responsibility and to become maintainer of ob-ditaa.el while active 
users have no ability to install ditaa as a package, so they anyway have 
to download .jar from upstream.


I find it tedious to add "flatpak-spawn ..." to every tool used by 
Emacs. Who is the publisher of the flatpak? I would expect a directory 
with symlinks named ditaa, java, git, gcc, cpp, etc to a script line


#!/bin/sh
exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"

(or "$(basename "$0")")

mounted to flatpak runtime and added to $PATH. Perhaps another approach 
exist and it should be discussed with the packager and Emacs developers.

Re: Feature request: export form feed as page break

[Marvin Gülker]

Am Sonntag, dem 22. Oktober 2023 schrieb Jambunathan K:
> I am the original author of ox-odt.el.
>
> The page break feature is available as part of
> https://github.com/kjambunathan/org-mode-ox-odt

I took a look at 
https://github.com/kjambunathan/org-mode-ox-odt/blob/master/notes/SNIPPETS.org#improve-support-for-pagebreaks
and indeed, there is a page break feature, but it seems to be exclusive
to this backend. I would prefer it if the page break feature was part of
org’s actual markup and thus work with all backends, including LaTeX,
without backend-specific markup.

> This is a fork of the ODT exporter in Emacs Orgmode.

I heard of it before; for now I think I want to stick with upstream org.
I do keep an eye on this fork in case I need one of its exclusive
features. Since from a technical point, I am mostly writing pretty
boring pure text documents, it worked out until now mostly.

  -MG

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<