Re: Bug: clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Jeff Trull]

Yes, I can make it work now - but only after reloading it at least one time
from disk.

When I type it in for the first time, it doesn't work. I have to save, then
(revert-buffer).
In other words, in a fresh buffer, paste all the above, then hit C-c C-c on
the BEGIN line.
The global properties don't work. You can save the file, and it still
doesn't work. Only after
reading it from disk (either with revert-buffer or loading it for the first
time) does it work.

Also, if you change the value (say, from 150 to 210) the old value persists
until you
reload the file. Even saving the file doesn't help.

On Mon, Oct 17, 2022 at 9:48 PM Ihor Radchenko  wrote:

> Jeff Trull  writes:
>
> > I just confirmed that it is still doing this (Emacs 28.2, org 9.5.5). The
> > result looks the same as before:
> >
> > #+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
> > :inherit-props t
> > #+CAPTION: Clock summary at [2022-10-17 Mon 16:50]
> > ...
> > Note that the first column next to "Sub 1A" is empty.
>
> Do note that :inherit-props t must be on the same line with #+BEGIN
>
> > Can you send the result of evaluating the clocktable in your config?
>
> #+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
> :inherit-props t
> #+CAPTION: Clock summary at [2022-10-18 Tue 12:47]
> | HOURLY_RATE | Headline   | Time |  |
> |-++--+--|
> | | *Total time* | *2h 30min* |  |
> |-++--+--|
> | 150 | Top 1  | 1h 0min  |  |
> | 150 | \_  Sub 1A |  | 1h 0min  |
> | 110 | Top 2  | 1h 30min |  |
> | 110 | \_  Sub 2A |  | 1h 0min  |
> |  90 | \_  Sub 2B |  | 0h 30min |
> #+END:
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: navigate to next radio target?

[Ihor Radchenko]

kevinbanjo  writes:

> Is there a function to move the cursor to the next or previous radio target?
>
> I'd like to bind that to a key.
>
> I'm talking about moving to the link to the target, not the target itself.

I do not think that there is such function. But you can use
org-target-link-regexp variable and do regexp search.

(defun my/next-target-link ()
"Go to next target link in buffer."
 (interactive)
 (re-search-forward org-target-link-regexp))

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

Re: [BUG] Org mode does not recognize the last character "_" in URL link

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> When URL has a character "_" at the end, Org mode can't fontify the URL
> link correctly.
>
> For example:
>
> https://www.twitter.com/example_

Plain links are tricky. There is no definitive regexp to catch all
possible links. We use heuristics.

If you see anything we can improve in org-link-make-regexps, patches are
welcome.

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

Re: PATCH: Re: Reading the parameters of a special-block

[Ihor Radchenko]

Bruno Barbier  writes:

> My understanding is that the parameters line is just ignored for special
> blocks.
>
> I wrote and used a patch a while ago to fix this; it was on my todo list
> to clean it up and submit it to org. Now looks like a good time.
>
> My patch adds a `:parameters-line' property to org elements that are
> special blocks, storing the PARAMETERS line as a string. See attached
> patch.
>
> Could this be added to org ?

I am in favour of it.

The property name could be simply :parameters. Just like in src blocks
(see org-element-src-block-parser).

> -  (type (progn (looking-at "[ \t]*#\\+BEGIN_\\(\\S-+\\)")
> -   (match-string-no-properties 1
> +  (type (progn (looking-at "[ \t]*#\\+BEGIN_\\(\\S-+\\)[ \t]*\\(.*\\)[ 
> \t]*$")
> +   (match-string-no-properties 1)))
> +  (parameters-line (match-string-no-properties 2))
> +  )
>  (if (not (save-excursion
>  (re-search-forward
>   (format "^[ \t]*#\\+END_%s[ \t]*$" (regexp-quote type))
> @@ -1898,6 +1901,7 @@ (defun org-element-special-block-parser (limit 
> affiliated)
>   (list 'special-block
> (nconc
>  (list :type type
> +  :parameters-line parameters-line

We probably want something like

:parameters (and (org-string-nw-p parameters) (org-trim parameters))

Just as in org-element-src-block-parser.

> -  (let ((block-type (org-element-property :type special-block)))
> -(format "#+begin_%s\n%s#+end_%s" block-type contents block-type)))
> +  (let ((block-type (org-element-property :type special-block))
> + (block-parameters-line (org-element-property :parameters-line 
> special-block))
> + )

No dangling ")" please.

> +(format "#+begin_%s%s%s\n%s#+end_%s" block-type
> +(if (string= "" block-parameters-line) "" " ") 
> block-parameters-line
> +contents block-type)))

We will not need to test against ="" with my above comment incorporated.
  
> @@ -2425,7 +2425,13 @@ (ert-deftest test-org-element/special-block-parser ()
>;; Handle non-empty blank line at the end of buffer.
>(should
> (org-test-with-temp-text "#+BEGIN_SPECIAL\nC\n#+END_SPECIAL\n "
> - (= (org-element-property :end (org-element-at-point)) (point-max)
> + (= (org-element-property :end (org-element-at-point)) (point-max
> +  ;; Parse the parameter line if any
> +  (should
> +   (org-test-with-temp-text "#+BEGIN_SPECIAL* s p :w 3\nC\n#+END_SPECIAL*"
> + (equal "s p :w 3"
> + (org-element-property :parameters-line (org-element-at-point))

May also test against empty parameters and space-only parameters.

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

Re: Bug: clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Ihor Radchenko]

Jeff Trull  writes:

> I just confirmed that it is still doing this (Emacs 28.2, org 9.5.5). The
> result looks the same as before:
>
> #+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
> :inherit-props t
> #+CAPTION: Clock summary at [2022-10-17 Mon 16:50]
> ...
> Note that the first column next to "Sub 1A" is empty.

Do note that :inherit-props t must be on the same line with #+BEGIN

> Can you send the result of evaluating the clocktable in your config?

#+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE") 
:inherit-props t
#+CAPTION: Clock summary at [2022-10-18 Tue 12:47]
| HOURLY_RATE | Headline   | Time |  |
|-++--+--|
| | *Total time* | *2h 30min* |  |
|-++--+--|
| 150 | Top 1  | 1h 0min  |  |
| 150 | \_  Sub 1A |  | 1h 0min  |
| 110 | Top 2  | 1h 30min |  |
| 110 | \_  Sub 2A |  | 1h 0min  |
|  90 | \_  Sub 2B |  | 0h 30min |
#+END:


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

Re: Problems running ob-julia tests (testing/test-ob-julia.el)

[Ihor Radchenko]

[CCing the maintainer]

Ihor Radchenko  writes:

> Christian Köstlin  writes:
>
>> I am trying to run the ob-julia tests but `make test` is prompting me
>> for a project folder. Has anybody the tests (or the ob-julia setup) in
>> a working state? (Simple ob-julia evaluations (without session) do
>> work for me).
>
> Some more data.
>
> I just tried to run test-ob-julia/colnames-yes-header-argument
> interactively and the test fails. Trying to execute example source block
> raises the following error:
>
> ERROR: syntax: cannot juxtapose string literal

Pedro, could you please take a look

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

Re: Problems running ob-julia tests (testing/test-ob-julia.el)

[Ihor Radchenko]

Christian Köstlin  writes:

> I am trying to run the ob-julia tests but `make test` is prompting me
> for a project folder. Has anybody the tests (or the ob-julia setup) in
> a working state? (Simple ob-julia evaluations (without session) do
> work for me).

Some more data.

I just tried to run test-ob-julia/colnames-yes-header-argument
interactively and the test fails. Trying to execute example source block
raises the following error:

ERROR: syntax: cannot juxtapose string literal
Stacktrace:
 [1] top-level scope
   @ none:1
munmap_chunk(): invalid pointer

signal (6): Aborted
in expression starting at none:0
unknown function (ip: 0x7f151f86beac)
raise at /lib64/libc.so.6 (unknown line)
abort at /lib64/libc.so.6 (unknown line)
unknown function (ip: 0x7f151f8601d6)
unknown function (ip: 0x7f151f875c3b)
unknown function (ip: 0x7f151f875e5b)
free at /lib64/libc.so.6 (unknown line)
close_unit_1 at /workspace/srcdir/gcc-7.1.0/libgfortran/io/unit.c:778
close_units at /workspace/srcdir/gcc-7.1.0/libgfortran/io/unit.c:831
unknown function (ip: 0x7f151fe87c82)
unknown function (ip: 0x7f151f822407)
exit at /lib64/libc.so.6 (unknown line)
main at julia (unknown line)
unknown function (ip: 0x7f151f80b34b)
__libc_start_main at /lib64/libc.so.6 (unknown line)
unknown function (ip: 0x400808)
Allocations: 1619791 (Pool: 1618747; Big: 1044); GC: 2


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

Re: Line breaks and brackets in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Assuming that there is currently no alternative to the non-selective
> solution, and that, as you say, the presence of brackets may be more
> common than I initially expected, if I had to choose between \empty and
> [0pt], I would say that [0pt] is the safest, as it is an expected
> argument to \\ and equals the default space. I can't think of any
> unexpected results from this, but of course, it also depends on there
> being no package redefining \\ with another argument structure on its
> own. I think it would be a bad idea for a package developer, but LaTeX
> (and the LaTeX packages) is horribly unpredictable.

It is easy to change \\\empty constant to \\[0pt] if necessary. I have
no objection either way. Though I do not feel like we are in rush. I'd
like to hear from ox-latex maintainer.

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

Re: Line breaks and brackets in LaTeX export

[Ihor Radchenko]

Max Nikulin  writes:

> Selectively adding some workaround require complete reimplementation of 
> exporters. I have some curiosity concerning pandoc approach, but I am 
> unsure if I will reserve some time to read its code.

Maybe or maybe not. We have org-export-get-next-element and a number of
exporters doing something special for the first/last object inside a
container. So, an alternative workaround might be possible. But
certainly more complex and fragile.

> An idea how to avoid complete redesign: at first add something like
> %__ORG_PROTECT_NEWLINE__
> after each \\, later at an optimizing pass remove the comment if next 
> line does not start from a star or a square bracket, otherwise use some 
> workaround, e.g. "{[}". \relax may be suitable as well (in the beginning 
> of rows, not after \\).

I am not sure if it is a good idea. It may interfere with export filters.

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

[RFC PATCH] Re: [bug] Macro in citation not expanded

[Ihor Radchenko]

M. ‘quintus’ Gülker  writes:

>> It sounds reasonable to allow macros inside citation references.
>> Maybe we also want to allow other things. Maybe simply allow all objects
>> but other citations, line-breaks, and table-cells?
>
> I have no strong opinion on this. I certainly do not need tables inside
> citations. If it is easy to just permit everything except what you
> named, I would say just allow it. Maybe someone has use for it. Maybe
> footnotes inside [cite:] construct should also not be allowed, at least
> for footnote-based styles.

See the attached WIP patch.
Note that I also removed link as our tests explicitly test against
having links inside citation references.

However, I can see how links can be useful in prefix/suffix...
I am wondering what was the rationale behind disallowing so many objects
inside citation references.

>From aa3fac7248aa1201bbf92d492dcd5c79f8d0a544 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 18 Oct 2022 12:22:56 +0800
Subject: [PATCH] org-element: Allow more objects inside citations
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-element.el (org-element-object-restrictions): Allow all but
citation, citation-reference, line-break, table-cell, link and
footnote-reference objects inside citations.

Reported-by: M. ‘quintus’ Gülker 
Link: https://orgmode.org/list/87tu425pla@guelker.eu
---
 lisp/org-element.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 7b26e877e..7aac00087 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -401,10 +401,14 @@ (defconst org-element-object-restrictions
 			 subscript superscript underline verbatim))
 	 (standard-set
 	  (remq 'citation-reference (remq 'table-cell org-element-all-objects)))
-	 (standard-set-no-line-break (remq 'line-break standard-set)))
+	 (standard-set-no-line-break (remq 'line-break standard-set))
+ (standard-set-for-citations (seq-difference
+  standard-set-no-line-break
+  '( citation citation-reference
+ footnote-reference link
 `((bold ,@standard-set)
   (citation citation-reference)
-  (citation-reference ,@minimal-set)
+  (citation-reference ,@standard-set-for-citations)
   (footnote-reference ,@standard-set)
   (headline ,@standard-set-no-line-break)
   (inlinetask ,@standard-set-no-line-break)
-- 
2.35.1


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

Re: Option that prevents Org to add \lstset{language=⟨language⟩,...} when code blocks are exported to LaTeX

[Ihor Radchenko]

Denis Bitouzé  writes:

> here is a feature request about the LaTeX export.
>
> With ~(setq org-latex-listings t)~, code blocks such as:
>
>   ┌
>   │ #+BEGIN_SRC ⟨language⟩ :exports code
>   │ ...
>   │ #+END_SRC
>   └
>
> are exported to LaTeX into:
>
>   ┌
>   │ \lstset{language=⟨language⟩,label= ,caption= ,captionpos=b,numbers=none}
>   │ \begin{lstlisting}
>   │ ...
>   │ \end{lstlisting}
>   └
>
> But the:
>
>   ┌
>   │ \lstset{language=⟨language⟩,label= ,caption= ,captionpos=b,numbers=none}
>   └
>
> systematically added before each of the ~lstlisting~ LaTeX environments
> is not always desirable and let me explain why.

Confirmed.
Is there a way to apply \lstset locally for the environment?

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

Re: Possible bug in `org-subtree--get-subtree-options`?

[Ihor Radchenko]

Kaushal Modi  writes:

> Today I was debugging something where a subtree export wasn't recognizing
> the EXPORT_OPTIONS property set in that subtree.
>
> MWE:
>
> =
> * Top level
> ** Allow broken links, but mark them
> :PROPERTIES:
> :EXPORT_FILE_NAME: allow-broken-links-but-mark-them
> :EXPORT_OPTIONS: broken-links:mark
> :END:
> =
>
> 1. Move cursor to BOL of "** Allow broken links, but mark them" line.
> 2. M-: (org-export--get-subtree-options)
>
> Output:
>
> (:title (#("Top level" 0 9 (:parent #1
>
> Issue: Point is already on a heading, but it is jumping to the parent
> heading and returning that heading's properties.
>
> Debugging through how the export options got parsed in subtree exports, I
> reached the `org-export--get-subtree-options' function and this line in
> there:
>
> ;;
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox.el#n1425
> (if (org-at-heading-p) (org-up-heading-safe) (org-back-to-heading t))
>
> It looks like the if condition actions are swapped here.

Not really swapped. A simple (org-back-to-heading t) will probably be
enough. See the attached patch.

However, I am concerned that one of the tests is actually assuming that
current subtree in the below example includes "Heading".

* Heading
** Child
** Child

>From e2c1dc3955eb54cee7ce137d548c687e378f4c8a Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 18 Oct 2022 12:07:37 +0800
Subject: [PATCH] org-export--get-subtree-options: Do not jump to parent
 subtree

* lisp/ox.el: Never jump to parent heading even when point is at an
existing heading.
* testing/lisp/test-ox.el (test-org-export/get-subtree-options): Fix
test assuming that current subtree may include parent.

Reported-by: Kaushal Modi 
Link: https://orgmode.org/list/cafyqvy3mxi4drts+w-ax7bfelvujqh4dodeypy3hygrrume...@mail.gmail.com
---
 lisp/ox.el  | 2 +-
 testing/lisp/test-ox.el | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 92f6010a0..9f44ec3ef 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -1434,7 +1434,7 @@ (defun org-export--get-subtree-options ( backend)
   ;; property is the keyword with "EXPORT_" appended to it.
   (org-with-wide-buffer
;; Make sure point is at a heading.
-   (if (org-at-heading-p) (org-up-heading-safe) (org-back-to-heading t))
+   (org-back-to-heading t)
(let ((plist
 	  ;; EXPORT_OPTIONS are parsed in a non-standard way.  Take
 	  ;; care of them right from the start.
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 42867919b..0d39160b6 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -388,7 +388,7 @@ (ert-deftest test-org-export/get-subtree-options ()
 	(plist-get (org-export-get-environment nil t) :date
   ;; Still grab correct options when section above is empty.
   (should
-   (equal '("H1")
+   (equal '("H12")
 	  (org-test-with-temp-text "* H1\n** H11\n** H12"
 	(plist-get (org-export-get-environment nil t) :title
   ;; More than one property can refer to the same node property.
-- 
2.35.1


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

[BUG] Org mode does not recognize the last character "_" in URL link

[Christopher M. Miles]

When URL has a character "_" at the end, Org mode can't fontify the URL
link correctly.

For example:

https://www.twitter.com/example_

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [PATCH] org-agenda: fix `org-agenda-new-marker`

[Ihor Radchenko]

Hu Lucius  writes:

> In some cases, `org-agenda-buffer` is killed while the symbol itself
> is still non-nil. `org-agena-new-marker` and anything that calls it would
> end in a message of "Selecting deleted buffer".
>
> This commit simply added an additional test that
>
> (buffer-live-p org-agenda-buffer)
>
> should also be true.
>
> P.S. I've sent another patch with the same subject a few days earlier.
> But that contains an error. Please dismiss that one.

For record, an alternative patch has been applied in the other thread.
See 
https://orgmode.org/list/cacdpnmhofumo4sjer_pcox5z5sodkvn-uw29aaydl8v-ioi...@mail.gmail.com

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

Re: org-agenda-tag-filter-preset: maybe a recent bug?

[Liu Hui]

Hi Garjola,

The preset of filter is not supposed to be used with individual
command. The docstring of 'org-agenda-tag-filter-preset' says:

> The preset filter is a global property of the entire agenda view. In
> a block agenda, it will not work reliably to define a filter for one
> of the individual blocks. You need to set it in the global options
> and expect it to be applied to the entire view.

So you just need to preset the filter in the global options, e.g.

  ;; multi-block view
  ("W" "Work Daily Action List"
   ((agenda ""))
   ((org-agenda-tag-filter-preset
 (quote
  ("+work")

or

  ("W" "Work Daily Action List"
   agenda ""
   ((org-agenda-tag-filter-preset
 (quote
  ("+work")

Re: Bug: clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Jeff Trull]

I just confirmed that it is still doing this (Emacs 28.2, org 9.5.5). The
result looks the same as before:

#+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
:inherit-props t
#+CAPTION: Clock summary at [2022-10-17 Mon 16:50]
| HOURLY_RATE | Headline |   Time |  |
|-+--++--|
| | *Total time* | *2:30* |  |
|-+--++--|
| | Top 1|   1:00 |  |
| | \_  Sub 1A   || 1:00 |
| 110 | Top 2|   1:30 |  |
| 110 | \_  Sub 2A   || 1:00 |
|  90 | \_  Sub 2B   || 0:30 |
#+END:

Note that the first column next to "Sub 1A" is empty.

Can you send the result of evaluating the clocktable in your config?

Thanks,
Jeff


On Sun, Oct 16, 2022 at 4:00 AM Ihor Radchenko  wrote:

> Jeff Trull  writes:
>
> > :inherit-props seems to not consider global properties.
> >
> > Testcase:
>
> I am unable to reproduce on the latest main.
> The inherited properties are displayed as expected on my side.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Org-mode syntax as a tool-independent MIME type (was: Shower thought: submit an IETF RFC to register Org as a MIME type)

[Karl Voit]

Hi,

* TEC  wrote:
>
> I'm still hoping for that discussion :P
>
> To the Org community, if you have thoughts on this - please share them
> :)

For reasons explained in my Orgdown-related articles[1] I would
propose to use this chance to introduce a different term for the
Org-mode lightweight markup language in contrast to the Org-mode
Elisp implementation in order to push the syntax in a tool-agnostic
way. We should not think only of GNU Emacs because there is a
rising number of tools that do support text files in Org-mode
syntax[2] which is also a huge advantage for users of GNU Emacs:
collaboration, public awareness of the syntax, more tool support,
...

I proposed the term Orgdown for the Org-mode syntax and also
proposed various levels in order to provide sub-sets of Org-mode
syntax[3] that are realistic to implement with finite effort. Using
those OD-levels to come up with a formal definition (EBNF?) might
play perfectly well with different parameters of the MIME type[4].

In my opinion, this would be a huge step forward for the whole
ecosystem that supports the same Org-mode syntax.

If we do not keep the MIME type independent from the GNU Emacs
Org-mode implementation, the overall use would be much smaller in
the long run.

Let's use that to establish a broad base for this great lightweight
markup language syntax!


[1] 
https://karl-voit.at/2021/11/27/orgdown/
https://emacsconf.org/2021/talks/org-outside/
https://gitlab.com/publicvoit/orgdown
https://karl-voit.at/2021/12/02/Orgdown-feedback/

[2]
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org

[3]
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org

[4] https://gitlab.com/publicvoit/orgdown/-/issues/8

-- 
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Problems running ob-julia tests (testing/test-ob-julia.el)

[Christian Köstlin]

Dear org-mode wizards,

I am trying to run the ob-julia tests but `make test` is prompting me
for a project folder. Has anybody the tests (or the ob-julia setup) in
a working state? (Simple ob-julia evaluations (without session) do
work for me).

Kind regards,
Christian

PATCH: Re: Reading the parameters of a special-block

[Bruno Barbier]

Damien Cassou  writes:

> Hi,
>
> in Worg's description of Org's syntax, there is a section about "greater
> blocks" [1]. The syntax is
>
> #+begin_NAME PARAMETERS
> CONTENTS
> #+end_NAME
>
> There is then a "PARAMETERS" optional string attached to special
> blocks. Unfortunately, in the special-block transcoder I'm writing, I
> have no clue how to access the parameters. I can't find any parameters
> function in org that would be related.
>
> What is the best way to access the parameters of a special-block?

My understanding is that the parameters line is just ignored for special
blocks.

I wrote and used a patch a while ago to fix this; it was on my todo list
to clean it up and submit it to org. Now looks like a good time.

My patch adds a `:parameters-line' property to org elements that are
special blocks, storing the PARAMETERS line as a string. See attached
patch.

Could this be added to org ?

Bruno


>From a57412351a21cecf0a83264139cc99bcc77f1093 Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Mon, 17 Oct 2022 20:19:02 +0200
Subject: [PATCH] lisp/org-element: Add a parameters-line property to special
 blocks

Add a property `parameters-line' to special blocks, to store the
PARAMETERS as a string.

* lisp/org-element.el (org-element-special-block-parser): Parse
PARAMETERS and set the property `:parameters-line'.

(org-element-special-block-interpreter): Interpret the new property
`:parameters-line'.

*
testing/lisp/test-org-element.el (test-org-element/special-block-parser):
Update to test parsing the block PARAMETERS.

(test-org-element/special-block-interpreter-with-params): New test.
---
 lisp/org-element.el  | 20 ++--
 testing/lisp/test-org-element.el | 16 +++-
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 7b26e877e..23751ad30 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1868,13 +1868,16 @@ (defun org-element-special-block-parser (limit affiliated)
 their value.
 
 Return a list whose CAR is `special-block' and CDR is a plist
-containing `:type', `:begin', `:end', `:contents-begin',
-`:contents-end', `:post-blank' and `:post-affiliated' keywords.
+containing `:type', `:parameters-line', `:begin', `:end',
+`:contents-begin', `:contents-end', `:post-blank' and
+`:post-affiliated' keywords.
 
 Assume point is at the beginning of the block."
   (let* ((case-fold-search t)
-	 (type (progn (looking-at "[ \t]*#\\+BEGIN_\\(\\S-+\\)")
-		  (match-string-no-properties 1
+	 (type (progn (looking-at "[ \t]*#\\+BEGIN_\\(\\S-+\\)[ \t]*\\(.*\\)[ \t]*$")
+		  (match-string-no-properties 1)))
+	 (parameters-line (match-string-no-properties 2))
+	 )
 (if (not (save-excursion
 	   (re-search-forward
 		(format "^[ \t]*#\\+END_%s[ \t]*$" (regexp-quote type))
@@ -1898,6 +1901,7 @@ (defun org-element-special-block-parser (limit affiliated)
 	(list 'special-block
 		  (nconc
 		   (list :type type
+			 :parameters-line parameters-line
 			 :begin begin
 			 :end end
 			 :contents-begin contents-begin
@@ -1909,8 +1913,12 @@ (defun org-element-special-block-parser (limit affiliated)
 (defun org-element-special-block-interpreter (special-block contents)
   "Interpret SPECIAL-BLOCK element as Org syntax.
 CONTENTS is the contents of the element."
-  (let ((block-type (org-element-property :type special-block)))
-(format "#+begin_%s\n%s#+end_%s" block-type contents block-type)))
+  (let ((block-type (org-element-property :type special-block))
+	(block-parameters-line (org-element-property :parameters-line special-block))
+	)
+(format "#+begin_%s%s%s\n%s#+end_%s" block-type
+(if (string= "" block-parameters-line) "" " ") block-parameters-line
+contents block-type)))
 
 
 
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 187cadf7a..396c329b7 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2425,7 +2425,13 @@ (ert-deftest test-org-element/special-block-parser ()
   ;; Handle non-empty blank line at the end of buffer.
   (should
(org-test-with-temp-text "#+BEGIN_SPECIAL\nC\n#+END_SPECIAL\n "
- (= (org-element-property :end (org-element-at-point)) (point-max)
+ (= (org-element-property :end (org-element-at-point)) (point-max
+  ;; Parse the parameter line if any
+  (should
+   (org-test-with-temp-text "#+BEGIN_SPECIAL* s p :w 3\nC\n#+END_SPECIAL*"
+ (equal "s p :w 3"
+	(org-element-property :parameters-line (org-element-at-point))
+
 
 
  Src Block
@@ -2791,6 +2797,14 @@ (ert-deftest test-org-element/dynamic-block-interpreter ()
 	   "#+BEGIN: myblock :parameter value1\nTest\n#+END:")
 	  "#+begin: myblock :parameter value1\nTest\n#+end:\n")))
 
+(ert-deftest test-org-element/special-block-interpreter-with-params ()
+  "Test special block interpreter."
+  (should
+   (equal (org-test-parse-and-interpret
+	   "#+BEGIN_special 

Re: Need for dedicated kinds of paragraphs

[Damien Cassou]

Hi all,

thank you very much for your answers:

Sébastien Miquel  writes:
> I think special blocks are a good fit for this purpose.
"Fraga, Eric"  writes:
> Have you tried /special blocks/, as in […]

following this idea (also suggested by yantar92 on IRC) I tried this
approach but failed because of:
https://lists.gnu.org/archive/html/emacs-orgmode/2022-10/msg00565.html

I could have introduced several kinds of boxes instead of just one with
parameters but I felt that was a bit heavyweight.

Ihor Radchenko  writes:
> Note that #+BOX is not a valid affiliated keyword. Only keywords from
> org-element-affiliated-keywords + #+ATTR_X keywords are considered
> affiliated.

that's also what I understood after reading the code some more.

> Something like
>
> #+ATTR_BACKEND: :style attention
> This text will appear with a red background

Max Nikulin  writes:
> If you have derived your export backend from ox-odt then you may use
> something like
> 
> #+attr_odt: :type attention
> or perhaps even
> #+attr_linuxmag: :type attention


This is exactly what I finally decided to use.

Thank you very much all of you!

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: Best android app

[Juan Manuel Macías]

Max Nikulin writes:

> On 16/10/2022 06:01, Juan Manuel Macías wrote:
>> ypuntot writes:
>> 
>>> https://easyorgmode.com/
>> Proprietary license. This should not be recommended here
>> (https://easyorgmode.com/terms).
>
> I did not expected that this topic would become so hot.

I didn't expect that either. And, since this response of mine has,
directly or indirectly, sparked a lengthy subsequent discussion, I think
I must apologize if my tone here may have sounded rude or impolite,
which was not my intention. It was a late hour, I was tired and English
is not my first language. So I opted for a minimal expression to remind
a user that the application he mentioned (in good faith) was proprietary
software. Probably, as I wrote it, the text gives the impression that I
was reprimanding this user. As I say, it was not my intention and
therefore I apologize for not having expressed it correctly.

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Max Nikulin writes:

> On 17/10/2022 22:01, Juan Manuel Macías wrote:
>> \documentclass{article}
>> \usepackage{tabularray}
>
> LaTeX I have installed is too old for this package. It is marked as
> "Experimental LaTeX3", so I am unsure, maybe you have found a bug in
> this package.
> https://ctan.org/pkg/tabularray

As I said, I don't use this package. Once I wanted to start using it,
because it has many interesting features, but I gave up on it because
this package does not (at the moment) have support for the CMYK color
space (necessary for print publication) with the xcolors package.

Maybe it's a bug, but the situation is that compiling the copied
examples as they are in the package manual, the result is correct (as it
is also shown in the manual); but adding an unexpected element (an
\empty on the last line) produces a bad result. Since you can't test the
package, I've taken this screenshot:

https://i.imgur.com/jkSHUMP.png

I think there is a tabularray user on the list, Vikas Rawal. In fact, I
also remember that I provided a patch so that he could use this package
in Org
(https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=duabb28ncsv...@mail.gmail.com/).
I've cc'd him in case he wants to join the discussion.

> You believe that an issue with brackets is extremely rare. It may be
> true for humanitarian texts. For some users it may be a constant
> source of pain e.g. in the case of interval notation as [a,b]. I have
> already mentioned tables generated by code blocks, not typed directly.
> I can not say that I often need to export my notes, but I was afraid
> that I will be bitten by this bug because I may try to put dates close
> to left margin:
>
> - Something\\
>   [2022-10-17 Mon]
>
> By default dates wrapped into \textit, but it may be customized to
> just "%s".
>
> Selectively adding some workaround require complete reimplementation
> of exporters. I have some curiosity concerning pandoc approach, but I
> am unsure if I will reserve some time to read its code.

I see. If the selective solution is going to involve rewriting the
exporters, I find that it is unaffordable in the present circumstances.
It's a shame, because pandoc's solution seems ideal to me. What I
couldn't say is how pandoc does it and if it does it whenever expected,
because I use very little pandoc.

> I found \empty when I was looking for an approach with minimal
> overhead. I expect that e.g. \\[0pt] may have higher performance
> penalty since it is expanded to several commands. When the idea with
> "\\\relax" failed I was choosing between "\\{}" and "\\\empty". I
> decided that the latter minimizes risk to add spurious space.

Assuming that there is currently no alternative to the non-selective
solution, and that, as you say, the presence of brackets may be more
common than I initially expected, if I had to choose between \empty and
[0pt], I would say that [0pt] is the safest, as it is an expected
argument to \\ and equals the default space. I can't think of any
unexpected results from this, but of course, it also depends on there
being no package redefining \\ with another argument structure on its
own. I think it would be a bad idea for a package developer, but LaTeX
(and the LaTeX packages) is horribly unpredictable.

Best regards,

Juan Manuel 

Re: Best android app

[Max Nikulin]

On 16/10/2022 06:01, Juan Manuel Macías wrote:

ypuntot writes:


https://easyorgmode.com/


Proprietary license. This should not be recommended here
(https://easyorgmode.com/terms).


I did not expected that this topic would become so hot.

Let's ignore that easyorg does not run on Android and concentrate on 
proprietary vs. free app.


I believe that in such cases a helpful answer gently pushing users to 
free software should be like: "Application P is a proprietary one. There 
are F and G apps that have close set of features and superior for tasks 
like T and D." Though such reply is almost impossible if discussion of P 
is aggressively discouraged and sharing discussion summary on a web site 
is prohibited because a web page may be associated with a GNU project. 
Without mention of P the phrase becomes significantly less convincing, 
it may give impression that people suggesting F and G are completely 
unaware of what P really is.


I do not think that intention was to promote the particular app using a 
GNU mail list, so my perception is that reaction without offering a free 
alternative was harsh. It would be acceptable in the case more delay to 
see that nobody can post a better answer.


I am unsure what is more strange, purism close in its degree to 
absurdity or partial measures like wiping mentions of proprietary 
software without removing of complete section

info "(org) Org Mobile" https://orgmode.org/manual/Org-Mobile.html
so that only a half of solution is really described. I would expect more 
healthy balance.


P.S. Juan Manuel, from my point of view, your message suggesting running 
emacs in termux is one of 2 helpful suggestions in this thread. Perhaps 
the topic starter is seeking for a UI suitable for touch screen rather 
than complete set of features, but due to lack of details we do not know it.


I have not tried any Org related application on Android, so I can not 
suggest anything. I had a hope to learn something new from this topic.

navigate to next radio target?

[kevinbanjo]

Hi everyone:

Is there a function to move the cursor to the next or previous radio target?

I'd like to bind that to a key.

I'm talking about moving to the link to the target, not the target itself.

TIA,
-Kevin

Re: [bug] Macro in citation not expanded

[M . ‘quintus’ Gülker]

Am Sonntag, dem 16. Oktober 2022 schrieb Ihor Radchenko:
> Only bold, code, entity, italic, latex-fragment, strike-through,
> subscript, superscript, underline, and verbatim objects are allowed
> inside citations.
> This is hard-coded inside `org-element-object-restrictions'.

This is a bit unfortunate, because I like to use macros for inserting
semantic formatting which is not part of org’s syntax. In the example
given in my OP, I use it to mark up names with small caps. The exact
example given includes a short note by me talking about the cited author
a little further. Another example where I need this is when I cite some
statement made in an interview, which may come out as something like:

[cite:{{{name(Interviewee)}}} in @interviewer p. 5]

Indirect statements by persons mentioned in news articles are another
example where I would use such a construct.

I define the `name' macro in such a way that it will format
`Interviewee` in the same way as the citation style formats the author
name for @interviewer, ensuring uniformness in the created footnote.

I also use the very same `name' macro inside the actual article text, so
that uniform formatting is guaranteed there as well.

> It sounds reasonable to allow macros inside citation references.
> Maybe we also want to allow other things. Maybe simply allow all objects
> but other citations, line-breaks, and table-cells?

I have no strong opinion on this. I certainly do not need tables inside
citations. If it is easy to just permit everything except what you
named, I would say just allow it. Maybe someone has use for it. Maybe
footnotes inside [cite:] construct should also not be allowed, at least
for footnote-based styles.

  -quintus

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

org-agenda-tag-filter-preset: maybe a recent bug?

[Garjola Dindi]

Hi,

I use ~org-agenda-tag-filter-preset~ in custom commands to generate
views like this:

,
| ("W" "Work Daily Action List"
|  ((agenda ""
|   ((org-agenda-span 1)
|(org-agenda-sorting-strategy
| (quote
|  ((agenda category-up tag-up time-up
|(org-agenda-tag-filter-preset
| (quote
|  ("+work")))
|(org-deadline-warning-days 7
|  nil nil)
`

I am usually following the ~main~ branch that I update once a week and
this kind of custom command stopped working about one week ago (October
8).

The agenda view is generated, but the filter is not applied. 

I did not change anything in my configuration. I have checked and it
works if I use the ~bugfix~ branch.

I was wondering if some of the changes recently made to solve a bug with
sticky agendas caused the issue. But if nobody else noticed anything, I
may have a misunderstanding in my way of defining the custom command
that was revealed by recent bugfixes?

Thanks for your help.

Garjola

-- 

Re: Line breaks and brackets in LaTeX export

[Max Nikulin]

On 17/10/2022 22:01, Juan Manuel Macías wrote:


\documentclass{article}
\usepackage{tabularray}


LaTeX I have installed is too old for this package. It is marked as 
"Experimental LaTeX3", so I am unsure, maybe you have found a bug in 
this package.

https://ctan.org/pkg/tabularray

You believe that an issue with brackets is extremely rare. It may be 
true for humanitarian texts. For some users it may be a constant source 
of pain e.g. in the case of interval notation as [a,b]. I have already 
mentioned tables generated by code blocks, not typed directly. I can not 
say that I often need to export my notes, but I was afraid that I will 
be bitten by this bug because I may try to put dates close to left margin:


- Something\\
  [2022-10-17 Mon]

By default dates wrapped into \textit, but it may be customized to just 
"%s".


Selectively adding some workaround require complete reimplementation of 
exporters. I have some curiosity concerning pandoc approach, but I am 
unsure if I will reserve some time to read its code.


An idea how to avoid complete redesign: at first add something like
   %__ORG_PROTECT_NEWLINE__
after each \\, later at an optimizing pass remove the comment if next 
line does not start from a star or a square bracket, otherwise use some 
workaround, e.g. "{[}". \relax may be suitable as well (in the beginning 
of rows, not after \\).


I do not like approach with a custom command. It is effectively the same 
as adding \empty but \\ may be redefined by some packages, so I strongly 
prefer to keep \\ in exported markup. Redefining of \\ is a way to new 
issues. I do not feel firm ground with a command that will expand to \\. 
I am afraid that \\ may still consume following "[" unless \empty or its 
equivalent is added after it. I am completely unsure concerning 
tabularray parser that does not rely on TeX primitives.


I found \empty when I was looking for an approach with minimal overhead. 
I expect that e.g. \\[0pt] may have higher performance penalty since it 
is expanded to several commands. When the idea with "\\\relax" failed I 
was choosing between "\\{}" and "\\\empty". I decided that the latter 
minimizes risk to add spurious space.


Some problems:

I do not see a way to add some LaTeX code between table lines.

Semi-verbatim environment may be a source of new bugs. They may be 
rather selective in respect to what they consider a command and what is 
passed as raw text. tabularray perhaps is similar in this sense.

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Juan Manuel Macías writes:

> So, in the current situation, we can ask ourselves: is
> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
> ...?

I think I've found a case where \empty 'everywhere' can produce unexpected
results. I don't know if I'm missing something, because I've never used
this package, but taking a couple of random examples from the tabularray
documentation, you can see it, compiling the following snippet (by the
way, putting \\[0pt] instead of \\\empty the result is correct). Here in
both cases the problem is in the last \empty:

\documentclass{article}
\usepackage{tabularray}

\begin{document}

\section{Normal}

\begin{tblr}{lccr}
\hline
Alpha & Beta & Gamma & Delta \\
\hline
Epsilon & Zeta & Eta & Theta \\
\hline
Iota & Kappa & Lambda & Mu\\
\hline
\end{tblr}

\section{With `empty'}

\begin{tblr}{lccr}
\hline
Alpha & Beta & Gamma & Delta \\\empty
\hline
Epsilon & Zeta & Eta & Theta \\\empty
\hline
Iota & Kappa & Lambda & Mu\\\empty
\hline
\end{tblr}

\section{Normal}

\begin{tblr}[m]{hlines}
Alpha & Beta & Gamma \\
Epsilon & Zeta & Eta\\
Iota & Kappa & Lambda\\
\end{tblr}

\section{With `empty'}

\begin{tblr}[m]{hlines}
Alpha & Beta & Gamma \\\empty
Epsilon & Zeta & Eta\\\empty
Iota & Kappa & Lambda \\\empty
\end{tblr}

Re: [ANN] We are now regularily testing Org main branch against Emacs 26, 27, 28

[Kaushal Modi]

On Sun, Oct 16, 2022 at 2:04 AM Bastien  wrote:

> Hi all,
>
> thanks to joint efforts by Christian Köstlin and Ihor, we are running
> the Org test suite from the Org main branch against Emacs 26, 27, 28.
>

It's great to hear this. Thank you, Christian and Ihor!

Re: Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)

[Max Nikulin]

On 16/10/2022 23:33, Juan Manuel Macías wrote:

Max Nikulin writes:


I am surprised that \vspace is added instead of empty line between
stanzas.


First of all, I'm afraid that in my previous post I mixed up two
different issues: the verse block bug and my personal opinions about the
new added constant. I should have separated these topics, sorry.


It was me who raised issues with verse exporter in discussion of newline 
commands. I was impressed by hard to read elisp code and its result.



I answer here what you comment about the verse blocks and later I will
open a different thread for the other issue.


I am trying to read with enough attention this discussion, for a while I 
have a couple of remarks specific to poetry.



with the stanzaskip \length. I remember that I commented on this anomaly
here on the list, a long time ago, but I can't find the original
message...


https://list.orgmode.org/87k0tjasty@posteo.net/
Juan Manuel Macías. [Small suggestion] on exporting verse blocks to 
LaTeX and vertical spaces. Tue, 15 Dec 2020 18:21:13 +0100


https://list.orgmode.org/?q=verse+vspace


In my init I have redefined the verse block like this, so that there is
a white line between stanzas, not \vspace


Do you still have real problems with current main HEAD state after 
adjusting patterns in your code?



(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
   vwidth


I have not verified it, but since I am not aware of a group wrapping 
this fragment, I suspect that :versewidth may have global effect, not 
limited to the current environment. Org variant of the function is 
rather close at this point.

Re: Org 9.5 broke the rendering of my SVG images

[Timothy]

Hi Chris,

> Would the HTML  tag be appropriate in this case?

Adding an option to switch between object/img would be best, and I’ll do so in
the near future, I’m just currently sorting out the test deployment of the 2022
Emacs Survey.

All the best,
Timothy

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

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-17 16:18]:
> Jean Louis  writes:
> 
> > However, IMHO and according to principles of free software, such as
> > not to steer users towards non-free software, then no links to
> > proprietary software shall be added from Org website pages, as Org is
> > part of Emacs which is part of GNU fully free operating system
> > distributions.
> 
> WORG is not the Org website. WORG is the community website.
> We deliberately use less strict rules to encourage contributions to
> WORG.

I am sorry, but in the subject above mentioned by me, what exactly do
you find so strict? Is it the fact not to reference to free sofware?

>From my side, I do not mind how some people categorize their website,
IMHO orgmode.org is one website for me, you may have many categories
and many pages, and categories and pages may be managed by X number of
people. Because it is on the same domain, I do not think that one
should reference proprietary software from WORG pages, and justify it
by saying how it is category "you name it", because Org is part of GNU
free software project.

Imagine if GNU.org domain would have category where they reference
non-free software applications comparing them as good or bad one. That
would not fly. But GNU.org website may mention some proprietary
software, and will not give references to such (not that I know).

In that spirit shall be every GNU software.

I present my opinion only. Not the opinion of GNU project.

> The Org website is only https://git.sr.ht/~bzg/orgweb which is
> strictly abiding the FSF rules.

GNU and FSF are not same. I speak of GNU.

-- 
Jean

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

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

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-17 15:06]:
> So, we may link to non-free software, but only for the purposes other
> than encouraging to use it. This is a tricky distinction to master
> though. In your interpretation that we are going to promote using that
> non-free software, you are right. But I viewed the discussion
> differently. [The reality is probably that it was too early to conclude
> about where the discussion will go; and it deviated towards FSF
> philosophy :) ]

IMHO, all GNU mailing lists are there under the free software
philosophy subject.

I fully understand the feeling when some people like me start
nagging. That is because me I have not get expectations that there is
proprietary software referenced for Org.

-- 
Jean

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

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

Re: Org 9.5 broke the rendering of my SVG images

[Chris Clark]

Would the HTML  tag be appropriate in this case?

For example, here's a tiny example of using the  tag with an external
CSS stylesheet: https://plnkr.co/edit/i8RFDW?preview


On Fri, Oct 14, 2022 at 4:32 AM Ihor Radchenko  wrote:

> Alexandre Duret-Lutz  writes:
>
> > In Org 9.5, SVG images started being exported by the HTML exporter as
> >  rather than .
> >
> > The patch causing that was
> >   https://list.orgmode.org/87k0pemj6d@gmail.com/T/
> > with two arguments:
> > 1)  do not have an alt attribute
> > 2)  will not render some SVG file correctly if it has no viewBox
> >(I'm assuming that the issue shown in that message is a missing
> viewBox).
> >
> > The reason I've noticed this change is that it broke my web pages.  On
> > my pages, I use SVG to display many automata, and they all share a
> > common stylesheet.  That stylesheet is not inlined into the SVG, rather,
> > it is a separate file included in the SVG files with
> >   
> > so that the browser only need to download it once.
> >
> > Infortunately,  does not allow external stylesheets to be
> > processed, so my stylesheets are now ignored.  Note that one can also
> > build SVG images that include other SVG images, or SVG images that have
> > animations that start when you hover on some elements.  All those
> > usages would break with .
> >
> > I've seen that very issue was discussed back in 2016
> > https://list.orgmode.org/871t2iq353@iki.fi/T/
> > where Christian Moe pointed out exactly this:
> >
> >> (2) You can also do other things with  that you cannot with
> >> , like manipulating the SVG with Javascript and styling it with
> >> an external stylesheet (linked from the SVG, not the web page).
> >
> > So in the interest of allowing users to build documents where SVG
> > files are not static, self-contained images, it seems to me that Org
> > probably needs some way to specify whether SVG images should be
> > exported as  or  (or maybe even inlined).
>
> Confirmed.
> This is clearly a regression and should be fixed.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-17 15:52]:
> Jean Louis  writes:
> 
> >> Having said that, my judgment may be still poor. I'd be happy to hear
> >> that I am wrong from Jean.
> >
> > Sorry I am lost, I have no idea to what the above refers. 
> 
> I was referring to my previous statement that
> "WRT the Org apps, we are discussing things, and you are trying to put
> stop on this discussion. I find it a bit too aggressive."

Alright, though I cannot imagine me having characteristic of an enemy
or being eager to fight. Sorry, I can't understand sensitivity for
nothing.


--
Jean

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

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

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-17 14:56]:
> Mostly in order to identify what we can improve in Org to remove the
> temptation to use that proprietary software. Fear to _not_ hear about why
> the proprietary software was even listed was the main motivator of my
> reply to your message.

Your above English is too hard for me.

But I picked up "listed" and "proprietary".

IMHO there is no reason to list proprietary software on GNU mailing
lists for purpose of comparison; unless there is serious intention to
make new free software that provides similar features.

-- 
Jean

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

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

Re: Best android app

[Ihor Radchenko]

Jean Louis  writes:

> However, IMHO and according to principles of free software, such as
> not to steer users towards non-free software, then no links to
> proprietary software shall be added from Org website pages, as Org is
> part of Emacs which is part of GNU fully free operating system
> distributions.

WORG is not the Org website. WORG is the community website.
We deliberately use less strict rules to encourage contributions to
WORG.

The Org website is only https://git.sr.ht/~bzg/orgweb which is strictly
abiding the FSF rules.

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

Re: BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Ihor Radchenko]

Michael Dauer  writes:

> Org mode version 9.5.5 (9.5.5-geeae6e
>
> #+CALL: test1()
>
> #+RESULTS:
> : 1
>
> #+CALL: test2()
>
> Fails with: Format specifier doesn’t match argument type
>
> * Test
> #+name: test1
> #+begin_src elisp
> 1
> #+end_src
> #+NAME: test2
> #+begin_src elisp
> (org-sbe "test1")
> #+end_src

Thanks for reporting.
Confirmed.

Timothy, it is caused by your

392ccbbf5d450ad47cd5952ed2f4ef35e454648e
Author: TEC 
ob-core: Display position of executed babel blocks

(nth 5 info) is nil in the above scenario. 

Could you please take a look?

I can "fix" this by using "%S" formatter, but maybe we can do better?

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

Re: [BUG] org-fold-hide-entry hide the first subtree under a heading if the heading has no content [9.5.5 (9.5.5-gcb1359 @ /home/user/meow-emacs/straight/build/org/)]

[Ihor Radchenko]

k_fore...@outlook.com writes:

> Hello everyone, I found if you org-fold-hide-entry on a heading without
> content but with subtrees, the first subtree will be folded, for
> example (>|< meas cursor):
>
> * H>| ** subheading1
> ** subheading2
>
> if you press TAB on the above text, it will be:
>
> * H>| ** subheading2

Thanks for reporting!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4b9aef20d8d7f2d2ce2457b7844effbf1223a35a

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

Re: Best android app

[Ihor Radchenko]

Jean Louis  writes:

>> Having said that, my judgment may be still poor. I'd be happy to hear
>> that I am wrong from Jean.
>
> Sorry I am lost, I have no idea to what the above refers. 

I was referring to my previous statement that
"WRT the Org apps, we are discussing things, and you are trying to put
stop on this discussion. I find it a bit too aggressive."

You have already replied to it.

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

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-16 18:02]:
> Clarification: I was actually referring to Jean's email. (I did not look
> at the sender and just now realized that you are not Jean)
> 
> Having said that, my judgment may be still poor. I'd be happy to hear
> that I am wrong from Jean.

Sorry I am lost, I have no idea to what the above refers. 

--
Jean

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

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

Re: Best android app

[Jean Louis]

* Max Nikulin  [2022-10-16 19:10]:
> On 16/10/2022 14:32, Jean Louis wrote:
> > * Max Nikulin [2022-10-16 08:28]:
> > > I do not have strong opinion concerning proprietary application.
> > > Requirements for worg section as driven by user content are not so strict 
> > > as
> > > for the main part of the Org site that must adhere to FSF rules. Perhaps 
> > > it
> > > is possible to separate non-free software by some discouraging
> > > disclaimer.
> > 
> > If I am not mistaken, you propose or initiate discussing how to list
> > proprietary software on some websites.
> 
> You are mistaken. I do not care if such discussion will happen. However I do
> not mind to have a peer reviewed list somewhere. It may be helpful to figure
> out what features and what workflows have not covered by free
> software yet.

Of course it is helpful to write free software that implements some
useful features found elsewhere.

Though for that, we can't steer users to review non-free software as
that means to let them give up on their freedom.

Many features may be discussed without running non-free sofware. And
in same cases one has to run non-free software to write free software.

I find it unfortunate that some people create proprietary software
that uses Org files.

However, IMHO and according to principles of free software, such as
not to steer users towards non-free software, then no links to
proprietary software shall be added from Org website pages, as Org is
part of Emacs which is part of GNU fully free operating system
distributions.

See: https://www.gnu.org/distros/free-system-distribution-guidelines.html

-- 
Jean

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

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

[PATCH] Re: [BUG] Make org-html-htmlize-output-type safe [9.5.2 (release_9.5.2-9-g7ba24c @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> In some of my notes, I have the following line:
>
> # -*- org-html-htmlize-output-type: nil -*-
>
> Every time I open such a file, Emacs wants me to confirm that doing so
> poses no security risk.  Could we perhaps make this variable safe?

Can be done. Like in the attached patch.
However, note that Emacs will still want about buffer-local setting if
ox-html is not loaded.

The same will happen with any other "safe" variable defined in Org
libraries that are not loaded by default.

I am wondering if we should add autoload cookies to such variables.

>From 5779ce5f5a05aa4e4f76d85eae1c1e324a77dea2 Mon Sep 17 00:00:00 2001
Message-Id: <5779ce5f5a05aa4e4f76d85eae1c1e324a77dea2.1666010682.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 17 Oct 2022 20:43:59 +0800
Subject: [PATCH] org-html-htmlize-output-type: Mark safe as buffer-local
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox-html.el (org-html-htmlize-output-type): This variable is
safe to set buffer-locally as a symbol.

Reported-by: Rudolf Adamkovič 
Link: https://orgmode.org/list/m28ruxklo5@me.com
---
 lisp/ox-html.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index cad06aebf..c34711d1e 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -897,7 +897,8 @@ (defcustom org-html-htmlize-output-type 'inline-css
 in all modes you want.  Then, use the command
 `\\[org-html-htmlize-generate-css]' to extract class definitions."
   :group 'org-export-html
-  :type '(choice (const css) (const inline-css) (const nil)))
+  :type '(choice (const css) (const inline-css) (const nil))
+  :safe #'symbolp)
 
 (defcustom org-html-htmlize-font-prefix "org-"
   "The prefix for CSS class names for htmlize font specifications."
-- 
2.35.1


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

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> I haven't seen any publication rule that prevents using valid LaTeX
> commands like this. Do you have concrete examples? If not, one could
> argue that any auto-generated output could break some imaginary rule.

No, I don't have any concrete example. But it is one thing to use a
valid LaTeX command and another to use it unnecessarily. It's like
putting \vspace{0pt} between each paragraph.

> I am also wondering how LaTeX documents generated from LyX or TeXmacs
> look like. Are they not using some obvious machine-generated constructs?

I don't know, because I haven't seen them. But I'd bet (at the risk of
losing the bet) that none of those machine-generated constructs produce
anything as unnecessary as Org's present solution. The situation now
becomes the following:

Pandoc: selective solution. In specific cases it returns {[}...{]}

Org: non-selective solution = ugly LaTeX code.

>> Anyway. As for the compilation, it is highly unlikely that \empty will
>> cause any unexpected error. But LaTeX and its over 6000 packages is
>> unpredictable. It also seemed unlikely that \relax would cause any
>> problems, and catching up on the last discussion, it had to be replaced
>> by \empty because it returned an error just before \hline. \relax is one
>> of the recommended solutions from LaTeX, because it tells LaTeX that the
>> previous macro has finished expanding, but it is recommended keeping in
>> mind that the user will apply it only when needed, not everywhere. And
>> before \hline it doesn't make sense because there will never be an
>> '\\[...]' error. So, in the current situation, we can ask ourselves: is
>> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
>> ...?
>
> My answer is: "\\" is 100% not universally safe. Simply because we have
> that bug report with [ ... ] items in tables.
> So, anything with no concrete counter-example is better as long as we
> are reasonably sure that we are not breaking LaTeX conventions.

As I said, this is a known LaTeX problem that occurs in a rare case, for
which there is a known solution (or several), which should be applied in
the specific case. And Org already provides the necessary tools to apply
it.

>> The only thing I can think of, for a non-selective solution like the
>> current one, is the following: if \\ has an optional argument that must
>> be a length, then let's give it, but with a value of zero: \\[0pt], which
>> is equivalent to putting the value by default (zero) explicitly.
>
> This has been proposed and then rejected by Max in
> https://list.orgmode.org/orgmode/ti5tdb$rd2$1...@ciao.gmane.io/ and he
> concluded that some side effects are present when using \\[0pt]:
>
> Max>   \\[0pt]
> Max> 
> Max> causes insertion of some code for negative vertical skip (of zero height 
> Max> this case). It should not be really harmful, but I would avoid this

I would like to see some concrete example where this solution was
problematic. \\[0pt] is exactly the same as \\ (as for the effects).
Redundant but valid.

bug#50218: 28.0.50; org-babel-tangle-file tangles code blocks starting with #+begin_src :tangle no

[Ihor Radchenko]

Tassilo Neubauer  writes:

> Here are the steps that led to code blocks being tangled I did not 
> expect to:
>
> emacs -Q
> C-x C-h: ~/org-roam/example.org
> content of example.org (excluding "):
> "
> #+begin_src emacs-lisp
> (setq some-emacs-lisp-variable t)
> #+end_src
>
> #+begin_src :tangle no
> ;;This line should not be in the elisp code
> #+end_src
> "
>
> open scratch buffer through menu.
> type into scratch buffer:
> (org-bable-tangle-file "/home/tassilo/org-roam/example.org"
> "/home/tassilo/org-roam/example.el")
> M-x:emacs-lisp-mode
> Select (with mouse) the above line and evaluate region through menu.
> I see in the minibuffer: "Tangled 2 code blocks from example.org"
> After typing C-h C-f: ~/org-roam/example.el
> I see the file content of "example.el" (excluding "):
> "
> (setq some-emacs-lisp-variable t)
>
> ;;This line should not be in the elisp code
>
> "

Well. I can see why you did not expect this, but the real cause is a
typo in your code block.

#+begin_src :tangle no
;;This line should not be in the elisp code
#+end_src

is viewed by Org mode as src block written in ":tangle" programming
language :) That's because you forgot to put language in the block and
Org takes the first word after #+begin_src and the language name.

This block does not have :tangle attribute and thus "example.el"
supplied in your function call is being used :)

On Org side, we may catch such scenarios in org-lint.
M-x org-lint currently reports no problem with the above block.

Not urgent fix. Patches are welcome :)

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

Re: Best android app

[Ihor Radchenko]

Jean Louis  writes:

> Yes, it is common sense that in GNU project we do not steer users
> towards proprietary systems.
>
> This means that in GNU software, mailing lists and chat, and websites,
> we do not point to proprietary systems as non-free programs are
> injustice, and we shall not bring users to position to give up their
> freedom.
>
> Applying the Free Software Criteria - GNU Project - Free Software Foundation:
> https://www.gnu.org/philosophy/applying-free-sw-criteria.en.html
>
> People are free to discuss anything, but as it is GNU project, those
> who are aware may ask and wonder why is proprietary software endorsed
> or referenced on GNU mailing lists.

I am mostly using https://www.gnu.org/prep/standards/standards.html as a
reference here:

>> You should not refer to AT’s web site if that recommends AT’s
>> non-free software packages; you should not refer to a page p that
>> links to AT’s site presenting it as a place to get some non-free
>> program, because that part of the page p itself recommends and
>> legitimizes the non-free program.
>> 
>> However, if p contains a link to AT’s web site for some other
>> purpose (such as long-distance telephone service), that is no reason
>> you should not link to p.

So, we may link to non-free software, but only for the purposes other
than encouraging to use it. This is a tricky distinction to master
though. In your interpretation that we are going to promote using that
non-free software, you are right. But I viewed the discussion
differently. [The reality is probably that it was too early to conclude
about where the discussion will go; and it deviated towards FSF
philosophy :) ]

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

Re: Best android app

[Ihor Radchenko]

Jean Louis  writes:

>> WRT the Org apps, we are discussing things, and you are
>> trying to put stop on this discussion. I find it a bit too
>> aggressive.
>
> Don't feel bad for that. That was nothing personal. Nobody minds who
> uses privately non-free software. Though why discuss or list
> proprietary software on GNU mailing lists which is meant for creation
> of fully free operating systems?!

Mostly in order to identify what we can improve in Org to remove the
temptation to use that proprietary software. Fear to _not_ hear about why
the proprietary software was even listed was the main motivator of my
reply to your message.

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

Re: Line breaks and brackets in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> I see no issue with defcustom in general, but can you explain what
>> practical problems it is going to solve? I am not talking about
>> aesthetics of the exported LaTeX.
>
> In my opinion it is not so much a question of aesthetics as of (let's
> say) a certain conformity with what a LaTeX document should be. I think,
> for example, in the case of a user who must submit his/her work in LaTeX
> format to a publication, following the rules of that publication. It is
> one thing for a LaTeX document to compile without error and quite
> another for a LaTeX document to be or not to be formed according to good
> practice. Would there be a problem sharing LaTeX documents with
> unnecessary commands like \empty after all occurrences of \\?

I haven't seen any publication rule that prevents using valid LaTeX
commands like this. Do you have concrete examples? If not, one could
argue that any auto-generated output could break some imaginary rule.

I am also wondering how LaTeX documents generated from LyX or TeXmacs
look like. Are they not using some obvious machine-generated constructs?

> Anyway. As for the compilation, it is highly unlikely that \empty will
> cause any unexpected error. But LaTeX and its over 6000 packages is
> unpredictable. It also seemed unlikely that \relax would cause any
> problems, and catching up on the last discussion, it had to be replaced
> by \empty because it returned an error just before \hline. \relax is one
> of the recommended solutions from LaTeX, because it tells LaTeX that the
> previous macro has finished expanding, but it is recommended keeping in
> mind that the user will apply it only when needed, not everywhere. And
> before \hline it doesn't make sense because there will never be an
> '\\[...]' error. So, in the current situation, we can ask ourselves: is
> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
> ...?

My answer is: "\\" is 100% not universally safe. Simply because we have
that bug report with [ ... ] items in tables.
So, anything with no concrete counter-example is better as long as we
are reasonably sure that we are not breaking LaTeX conventions.

> The only thing I can think of, for a non-selective solution like the
> current one, is the following: if \\ has an optional argument that must
> be a length, then let's give it, but with a value of zero: \\[0pt], which
> is equivalent to putting the value by default (zero) explicitly.

This has been proposed and then rejected by Max in
https://list.orgmode.org/orgmode/ti5tdb$rd2$1...@ciao.gmane.io/ and he
concluded that some side effects are present when using \\[0pt]:

Max>   \\[0pt]
Max> 
Max> causes insertion of some code for negative vertical skip (of zero height 
Max> this case). It should not be really harmful, but I would avoid this hack.

> What I've done in this code is redefine \\ so that if the next character
> is a [ or a * it doesn't do anything. To use the macro with the old
> behavior, you would have to use the new macros \oldbreak and \oldbreakt
> (this one for tables):
>
> @@latex:\oldbreak@@
> @@latex:[1em]@@

It means that LaTeX packages that redefine \\ may be affected. I'd
prefer to avoid such side effects.

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

Re: Need for dedicated kinds of paragraphs

[Max Nikulin]

On 17/10/2022 13:52, Damien Cassou wrote:


 #+BOX: attention
 This text will appear with a red background


If you have derived your export backend from ox-odt then you may use 
something like

#+attr_odt: :type attention
or perhaps even
#+attr_linuxmag: :type attention


Does that make sense? Do you have a better suggestion?


I see that you have tried special blocks. Unfortunately I do not see 
anything related to parameters in the `org-element-special-block-parser' 
`org-element-special-block-interpreter' pair.

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-16 12:25]:
> Jean Louis  writes:
> 
> > If I am not mistaken, you propose or initiate discussing how to list
> > proprietary software on some websites.
> >
> > GNU mailing lists are not for such discussions. GNU is project is
> > there to foster full free software. 
> 
> Do you know where this rule is documented?

It is everywhere in GNU project, Org mode is part of Emacs and GNU
project.

In GNU project nobody is concerned if you, me or who uses free
software privately, that is not matter of GNU project as it is private
matter.

We create fully free operating systems. We do not intrude in privacy
of people.

Yes, it is common sense that in GNU project we do not steer users
towards proprietary systems.

This means that in GNU software, mailing lists and chat, and websites,
we do not point to proprietary systems as non-free programs are
injustice, and we shall not bring users to position to give up their
freedom.

Applying the Free Software Criteria - GNU Project - Free Software Foundation:
https://www.gnu.org/philosophy/applying-free-sw-criteria.en.html

People are free to discuss anything, but as it is GNU project, those
who are aware may ask and wonder why is proprietary software endorsed
or referenced on GNU mailing lists.

--
Jean

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

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

Re: Best android app

[Jean Louis]

* Ihor Radchenko  [2022-10-16 16:04]:
> > Documented or undocumented, it's common sense. This is a mailing list of
> > the GNU project, and it is hoped that this list will not recommend the
> > use of unethical software that does not comply with the GNU philosophy.
> 
> Discussing and recommending are two different things.
> 
> Consider Windows. We do not recommend it. Yet, we do support it, and we
> do discuss it.

This is because Emacs run on Windows, like many other free
software. That does not make Windows legitimate for use.

> WRT the Org apps, we are discussing things, and you are
> trying to put stop on this discussion. I find it a bit too
> aggressive.

Don't feel bad for that. That was nothing personal. Nobody minds who
uses privately non-free software. Though why discuss or list
proprietary software on GNU mailing lists which is meant for creation
of fully free operating systems?!

--
Jean

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

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

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> I see no issue with defcustom in general, but can you explain what
> practical problems it is going to solve? I am not talking about
> aesthetics of the exported LaTeX.

In my opinion it is not so much a question of aesthetics as of (let's
say) a certain conformity with what a LaTeX document should be. I think,
for example, in the case of a user who must submit his/her work in LaTeX
format to a publication, following the rules of that publication. It is
one thing for a LaTeX document to compile without error and quite
another for a LaTeX document to be or not to be formed according to good
practice. Would there be a problem sharing LaTeX documents with
unnecessary commands like \empty after all occurrences of \\?

Anyway. As for the compilation, it is highly unlikely that \empty will
cause any unexpected error. But LaTeX and its over 6000 packages is
unpredictable. It also seemed unlikely that \relax would cause any
problems, and catching up on the last discussion, it had to be replaced
by \empty because it returned an error just before \hline. \relax is one
of the recommended solutions from LaTeX, because it tells LaTeX that the
previous macro has finished expanding, but it is recommended keeping in
mind that the user will apply it only when needed, not everywhere. And
before \hline it doesn't make sense because there will never be an
'\\[...]' error. So, in the current situation, we can ask ourselves: is
\empty everywhere safe? Everything points to yes. Can we be 100% sure?
...?

The only thing I can think of, for a non-selective solution like the
current one, is the following: if \\ has an optional argument that must
be a length, then let's give it, but with a value of zero: \\[0pt], which
is equivalent to putting the value by default (zero) explicitly.

>> This is an example I came up with of how it could be fixed selectively
>> in LaTeX (big, big caveat: it's just a proof of concept and likely to
>> produce errors in other contexts. I think if a LaTeX package to fix this
>> isn't already out, it is either because the problem is very rare and the
>> solution for particular cases is known, or because there are drawbacks
>> inherent to LaTeX that I can't figure out right now):
>>
>> \makeatletter
>>
>> \def\my@protectlbrack{
>>   \@ifnextchar{[}{\relax}{}
>>   \@ifnextchar{*}{\relax}{}
>> }
>>
>> \let\old@break\\
>> \def\\{%
>>   \old@break\my@protectlbrack}
>>
>> %% for tables
>>
>> \let\old@tabularcr\@tabularcr
>> \def\@tabularcr{%
>>   \old@tabularcr\my@protectlbrack}
>>
>> % for use the old commands
>>
>> \newcommand\oldbreak{\old@break}
>> \newcommand\oldbreakt{\old@tabularcr}
>>
>> \makeatother
>>
>> \begin{document}
>>
>> lorem\\
>> [ipsum]
>>
>> lorem\\
>> *ipsum
>>
>> \begin{tabular}{}
>> a & a & a & a \\
>> [a] & a & a & a \\
>> *a & a & a & a \\
>> \end{tabular}
>>
>>
>> \end{document}
>
> Won't it make it impossible to use
> @@latex:\\@@
> @@latex:[1em]@@
>
> deliberately?

What I've done in this code is redefine \\ so that if the next character
is a [ or a * it doesn't do anything. To use the macro with the old
behavior, you would have to use the new macros \oldbreak and \oldbreakt
(this one for tables):

@@latex:\oldbreak@@
@@latex:[1em]@@

Anyway, like I said, it's a proof of concept. In the tests I've done it
works very well, but on a large scale I can't be sure of the results.

Best regards,

Juan Manuel 

Re: Need for dedicated kinds of paragraphs

[Ihor Radchenko]

Damien Cassou  writes:

> I'm not sure what kind of markup to use nor how to transcode that
> markup. I tried with:
>
> #+BOX: attention
> This text will appear with a red background
>
> Does that make sense? Do you have a better suggestion?

Note that #+BOX is not a valid affiliated keyword. Only keywords from
org-element-affiliated-keywords + #+ATTR_X keywords are considered
affiliated.

So, you example is actually parsed as




not as



In addition to special blocks suggested by others, a natural way to
customize paragraph export is using #+ATTR_YOURBACKEND keywords.

Something like

#+ATTR_BACKEND: :style attention
This text will appear with a red background

Then, you can use

(plist-get (org-export-read-attribute :attr_backend paragraph-element)
   :style)
   
from inside the paragraph transcoder.

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

BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Michael Dauer]

Org mode version 9.5.5 (9.5.5-geeae6e

#+CALL: test1()

#+RESULTS:
: 1

#+CALL: test2()

Fails with: Format specifier doesn’t match argument type

* Test
#+name: test1
#+begin_src elisp
1
#+end_src
#+NAME: test2
#+begin_src elisp
(org-sbe "test1")
#+end_src

Re: [PATCH] Add light argument to org-babel-lob-get-info

[Ihor Radchenko]

Ferdinand Pieper  writes:

> Similar to ~org-babel-get-src-block-info~ it is sometimes useful to disable 
> evaluation of lisp parameters when getting the info of a lob call. This patch 
> adds an argument for that.
>
> Better name for the argument could be ~no-eval~, but I decided to stick with 
> the naming in ~org-babel-get-src-block-info~. To be completely consistent 
> with ~org-babel-get-src-block-info~ the argument order could be swapped, but 
> this would break existing function calls. 
>
> What do you think?

I see no problem with this addition.

I'd prefer to change LIGHT to NO-EVAL, including in
org-babel-get-src-block-info. Changing argument name in function does
not affect its caller in any way. Just need to update the function body
and docstring carefully.

NO-EVAL is already used by org-babel-parse-header-arguments and
org-babel-params-from-properties.

May I know if you are proposing this for a specific purpose?

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

Re: Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)

[Ihor Radchenko]

Juan Manuel Macías  writes:

> The solution of adding \relax or \empty is a good one. The problem is
> when it is applied massively and indiscriminately, bearing in mind that
> it is to prevent a problem that is, frankly, very rare. \empty is
> unlikely to have any side effects, but still, I don't like Org making
> these decisions for me and adding LaTeX code that I didn't ask for, in
> form or quantity. Isn't it possible to be more selective, like Pandoc
> does (I think), and add what needs to be added only when the problem is
> present? I don't know if the Pandoc thing has already been mentioned in
> past discussions, because these days I haven't been paying attention to
> the list.
>
> In any case, I would prefer: a) a selective solution; and if a) is not
> possible, at least b) a defcustom.

I tried to add the safe version of page break everywhere where there is
a risk of a page break followed by square brackets.

The key point: A valid Org file must be exported to a valid LaTeX file.

If you know a selective solution, patches are welcome. (I am also CCing
Daniel).

I see no issue with defcustom in general, but can you explain what
practical problems it is going to solve? I am not talking about
aesthetics of the exported LaTeX.

> This is an example I came up with of how it could be fixed selectively
> in LaTeX (big, big caveat: it's just a proof of concept and likely to
> produce errors in other contexts. I think if a LaTeX package to fix this
> isn't already out, it is either because the problem is very rare and the
> solution for particular cases is known, or because there are drawbacks
> inherent to LaTeX that I can't figure out right now):
>
> \makeatletter
>
> \def\my@protectlbrack{
>   \@ifnextchar{[}{\relax}{}
>   \@ifnextchar{*}{\relax}{}
> }
>
> \let\old@break\\
> \def\\{%
>   \old@break\my@protectlbrack}
>
> %% for tables
>
> \let\old@tabularcr\@tabularcr
> \def\@tabularcr{%
>   \old@tabularcr\my@protectlbrack}
>
> % for use the old commands
>
> \newcommand\oldbreak{\old@break}
> \newcommand\oldbreakt{\old@tabularcr}
>
> \makeatother
>
> \begin{document}
>
> lorem\\
> [ipsum]
>
> lorem\\
> *ipsum
>
> \begin{tabular}{}
> a & a & a & a \\
> [a] & a & a & a \\
> *a & a & a & a \\
> \end{tabular}
>
>
> \end{document}

Won't it make it impossible to use
@@latex:\\@@
@@latex:[1em]@@

deliberately?

Note that we may also replace \\\empty with a single custom command. It
will look a bit cleaner. Not sure if it is any different from your
approach.

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

Re: Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Yes, you're right: that \vspace is the normal behavior of the block when
> exporting to LaTeX, and it is certainly not quite correct. In LaTeX,
> both the out-of-the-box verse environment and the one provided by the
> 'verse' package (which, typographically speaking, is the correct way to
> represent verses in LaTeX) do not add a \vspace between stanzas. In the
> LaTeX input the separation between stanzas is expressed by an (at least)
> empty line. In fact, that space can be controlled by the verse package
> with the stanzaskip \length. I remember that I commented on this anomaly
> here on the list, a long time ago, but I can't find the original
> message...

I checked git log and the current approach for verse export dates back
to initial versions of ox-latex. I am pretty sure that it should be
improved.

> In my init I have redefined the verse block like this, so that there is
> a white line between stanzas, not \vspace (I have also added some things
> for the verse package, so that the numbering of verses is not broken).
> So your example would produce a white line under \begin{verse}, not the
> current \vspace, which would be irrelevant to LaTeX. But this is only a
> hack:

Could you provide a patch?

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

Re: [BUG] columnview cannot deal with more than 100 headings [N/A (N/A @ /home/oub/emacs/site-lisp/packages/org/)]

[Ihor Radchenko]

Uwe Brauer  writes:

> BTW, you send me some time ago (the <2022-07-30>) a patch that allowed
> edit-comment-blk: support COMMENT blocks
>
> Is this now in master/main? It is very convenient for my workflow
>
> For you convenience I attach the patch below

I have applied the patch and replied in the thread.
It is on main.

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

Reading the parameters of a special-block

[Damien Cassou]

Hi,

in Worg's description of Org's syntax, there is a section about "greater
blocks" [1]. The syntax is

#+begin_NAME PARAMETERS
CONTENTS
#+end_NAME

There is then a "PARAMETERS" optional string attached to special
blocks. Unfortunately, in the special-block transcoder I'm writing, I
have no clue how to access the parameters. I can't find any parameters
function in org that would be related.

What is the best way to access the parameters of a special-block?

[1] https://orgmode.org/worg/dev/org-syntax.html#Greater_Blocks

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: Org 9.6-pre and Bash sessions

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> :
> : > > hello
>
> on the subsequent runs.
>
> Better than the new version but still wrong. :)

And this is what drove me crazy during debugging. I do not understand
the logic of all that ob-comint code.

I have identified that the hang happens because Org does not change PS2
prompt. Just PS1. But fixing this would yield to

: org_babel_sh_prompt> org_babel_sh_prompt> hello

Then, I tried to see how the original code works. And it does not
:facepalm:

I asked emacs-devel
https://yhetil.org/emacs-devel/87y1tgqhmc.fsf@localhost/T/#u

No clue how to read the script output programatically in comint buffer. 

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

Re: Need for dedicated kinds of paragraphs

[Fraga, Eric]

Hi Damien,

On Monday, 17 Oct 2022 at 08:52, Damien Cassou wrote:
> I'm not sure what kind of markup to use nor how to transcode that
> markup. I tried with:

Have you tried /special blocks/, as in

#+begin_attention
This text will appear with a red backround.
#+end_attention

?  In LaTeX and HTML, this exports in such a way that the paragraph is
within a special environment (LaTeX) or class (HTML).  I'm not sure how
it exports to ODT but it may provide the basis for what you want.

-- 
: Eric S Fraga, with org release_9.5.5-840-g52be6f in Emacs 29.0.50

Re: bizarre: checkbox in properties, counting does not work with subheadings

[Ihor Radchenko]

Uwe Brauer  writes:

> #+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :hlines 1 :indent nil  
> :format "%5TODO(Status) %5Nr(Nr) %5Comp1(Comp1){X/} %5Comp2(Comp2){X/}"
> | Status | Nr | Comp1 | Comp2 |
> |++---+---|
> ||| [3/4] | [3/4] |
> | DONE   |  1 | [X]   | [X]   |
> | TODO   |  2 | [X]   | [X]   |
> | DONE   |  3 | [ ]   | [X]   |
> | WAIT   |  4 | [X]   | [ ]   |
> #+END:
>
>
> #+end_src
>
> Everything is as expected, now I will lower the level of the first and
> last subheaders and the statistics of the checkbox turns nuts:

Confirmed.
The culprit is org-columns--compute-spec.
I do not fully understand how it works, but it feels like your scenario
breaks some implicit assumption in the function.

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

[BUG] Exporting non-existent citations in oc-basic [9.6-pre (release_9.5.5-989-gd972cf @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Hi,

Consider the following Org file:


[cite:@key]
#+print_bibliography:
That’s it!

@key is not in the default bibliography and the bibliography processor is set 
to basic

Open the file and execute C-c C-e t U (export to ascii)

An error is thrown and export fails when attempting to print the
bibliography.

It does not matter if default bibliography actually contains anything.
Just that the key is not valid.

Can someone using citations often confirm?


Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.16.0)
 of 2022-10-13
Package: Org mode version 9.6-pre (release_9.5.5-989-gd972cf @
 /home/yantar92/.emacs.d/straight/build/org/)

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

Re: Need for dedicated kinds of paragraphs

[Sébastien Miquel]

Hi,

Damien Cassou writes:

I'm implementing an odt-based exporter for a French magazine named
GNU/Linux Magazine.  This magazine defines several kinds of boxes, which
are small paragraphs of a certain type among "Default", "Attention",
"Warning" and "PAO". When published, the magazine will change the
background of these boxes depending on the type (e.g., using red color
for warning boxes).

I'm not sure what kind of markup to use nor how to transcode that
markup. I tried with:

 #+BOX: attention
 This text will appear with a red background

Does that make sense? Do you have a better suggestion?


I think special blocks are a good fit for this purpose.

--
Sébastien Miquel

Need for dedicated kinds of paragraphs

[Damien Cassou]

Hi,

I'm implementing an odt-based exporter for a French magazine named
GNU/Linux Magazine.  This magazine defines several kinds of boxes, which
are small paragraphs of a certain type among "Default", "Attention",
"Warning" and "PAO". When published, the magazine will change the
background of these boxes depending on the type (e.g., using red color
for warning boxes).

I'm not sure what kind of markup to use nor how to transcode that
markup. I tried with:

#+BOX: attention
This text will appear with a red background

Does that make sense? Do you have a better suggestion?

>From Worg's org-syntax.html file [1], I understand that this is an
"affiliated keyword" and that it must be declared in
`org-element-affiliated-keywords' but this variable is a `defconst' so
I'm reluctant to change it in my exporter.

I have an `ox-linuxmag--paragraph' transcoder for the `paragraph' type
but I don't know how to get the value of the "BOX" keyword.

Do you have any suggestion?

If I have a look at how org-odt transcodes paragraphs, I see this
function:

(defun org-odt-paragraph (paragraph contents info)
  "Transcode a PARAGRAPH element from Org to ODT.
CONTENTS is the contents of the paragraph, as a string.  INFO is
the plist used as a communication channel."
  (org-odt--format-paragraph
   paragraph contents info
   (or (org-element-property :style paragraph) "Text_20_body")
   "OrgCenter"
   "Quotations"))

Could I use the :style property? What would the markup be like to make
that work?

Thank you so much for Org!

[1] https://orgmode.org/worg/dev/org-syntax.html#Affiliated_Keywords

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill