Re: [External] : Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> (The performance drop was sudden and steep, by the way.)

It is because clocking now calls Org parser API.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3790bf8ea1d070055a989f0b9587948e07877977

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

> I also added a new independent patch, to fix a bug when interpreting a special
> block that has no content, and some tests.
>
> Let me know if I did miss something,
> And thank you for the review!

Thanks! LGTM.

Now, can you also make a patch against https://git.sr.ht/~bzg/worg
adding the new parameter to https://orgmode.org/worg/dev/org-element-api.html?

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

Re: Weird behavior of org-element-object-lex

[Ihor Radchenko]

Damien Cassou  writes:

> here is the beginning of `org-element-object-lex`:
>
>   (defun org-element--object-lex (restriction)
> "Return next object in current buffer or nil.
>   RESTRICTION is a list of object types, as symbols, that should be
>   looked after.  This function assumes that the buffer is narrowed
>   to an appropriate container (e.g., a paragraph)."
> (cond
>  ((memq 'table-cell restriction) (org-element-table-cell-parser))
>  ((memq 'citation-reference restriction)
>   (org-element-citation-reference-parser))
>  (t …)))
>
> From what I understand, if `restriction` includes 'table-cell (or
> 'citation-reference), and if the content isn't a table-cell,
> `org-element--object-lex` will immediately return nil without trying
> other object types.
>
> Is that a bug?

Not really. table-cell and citation-reference do not have a regexp
signature and are handled specially. For these two types of objects,
org-element--object-lex is called only when the parent is a table-row or
citation object. Not very elegant, but it is internal function, and it
works :)

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

Re: Formatting in citation locator

[Ihor Radchenko]

M. ‘quintus’ Gülker  writes:

> Am Mittwoch, dem 19. Oktober 2022 schrieb Ihor Radchenko:
>> It is expected because we do not allow "]" right after markup. You'd
>> need to insert an escape character (zero-width space) to force the
>> italics markup in [Sondervotum /Schluckebier/].
>> See https://orgmode.org/manual/Escape-Character.html.
>
> Thanks for the hint, but it does not work still even if I change the
> line to contain the said zero-width space:
>
> Abweichende Meinung. [cite:@bverfg2010vds p. 373 [Sondervotum 
> /Schluckebier/​],]
>
> The buffer is now fontified as expected, but it does not work when
> exported to HTML:
>
> 1 BVerfGE 125, 260 (373 [Sondervotum /Schluckebier/​])

Confirmed.

> This however I think comes down to the same problem which is described
> at .

No. It is some bug in org-cite-csl--create-structure.
I am CCing the oc-csl maintainer.
András, can 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: Error during PDF export but the PDF file is exported

[Ihor Radchenko]

Pascal Quesseveur  writes:

>>"IR" == Ihor Radchenko  writes:
>
>   IR> I think that creating a temporary file locally is excessive.
>
>   Perhaps, but I couldn't find another way.

I think we are miscommunication. What I wanted to say is that
`current-time' is good enough if we export to local file. The whole
route with creating temporary file and getting its attributes is only
needed in remote directory.

>   IR> You could guard the logic behind `file-remote-p'.
>
>   FMU file-remote-p works onnly when there is a handler on path for
> operation file-remote-p, which is not true in the general
> case. Otherwise that function returns nil.

If file-remote-p does not work, I doubt that we can export to that
directory at all.

>   OTOH it is possible to reserve the creation of a temporary file only
> when the file is not already present.

It is also an option.

-- 
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.
>
> I have an impression that markup generated by children often added using 
> %s to some other construct. I may be wrong.

You are right, but missing subtle detail.
Export transcoders for container elements are called with 3 arguments:
data, contents, and info.

DATA contains the actual AST of the transcoded element, including its
children available via org-element-contents. CONTENTS is the string
representations of the exported children elements. Before CONTENTS is
generated, relevant transcoders are also called for each child of the
DATA.

When transcoding children (e.g. table rows), the sibling rows can always
be accessed using org-export-get-previous-element and
org-export-get-next-element.

>>> 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.
>
> I do not expect negative effect from a comment added at the end of line. 
> Optimizing pass may be performed prior to user filters.

Filters are applied by ox.el immediately after transcoding each element.
See the final expressions in org-export-data. The filters may alter the
exported string, including removing the %__ORG_PROTECT_NEWLINE__ we put
there. Of course, we can warn users about this particular caveat, but I
do not like such design -- it is too fragile.

> As another approach text properties may be used as a communication 
> channel unless they are stripped by ox.

I am not sure what you are referring to. If modifying exported string,
it will suffer from the same problems as your idea with comment.

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

Re: [External] : Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Thank you!  I will take one or more of those steps.

(The performance drop was sudden and steep, by the way.)

On 10/19/22 23:56, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Here you go.

Thanks!
It looks like you have some task with giant years-worth logbook drawer.

You can try to reduce org-element--cache-self-verify-frequency or even
set org-element--cache-self-verify to nil. The latter should be safe if
you haven't seen any Org mode warnings recently.

Re: [External] : Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> Here you go.

Thanks!
It looks like you have some task with giant years-worth logbook drawer.

You can try to reduce org-element--cache-self-verify-frequency or even
set org-element--cache-self-verify to nil. The latter should be safe if
you haven't seen any Org mode warnings recently.

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

Re: [BUG] org-num-mode does not clear previous numbers [9.5.5 (9.5.5-g9ce472 @ /home/user/.config/emacs/straight/build/org/)]

[Ihor Radchenko]

Ruijie Yu via "General discussions about Org-mode."
 writes:

> When I call `(org-num-mode)' from lisp multiple times on a single
> orgmode buffer, I get multiple numberings on each heading.
> Subsequently, when I call `(org-num-mode -1)' or `(org-num--clear)',
> only one layer of numberings are removed.
>
> This behavior is observed at the build below, but should still be
> reproducible in current HEAD (4179d1205ed791254aa21fadf262623bc805595d).

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

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

Re: [BUG] {C-c C-c} updating on a sub-headline checkbox statistics caused upper headline checkbox statistics reset to zero

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Here is a test org content:
>
> #+begin_src org
> ,* 1 headline [0/2]
>
> ,** TODO kk [0/0]
> :LOGBOOK:
> - State "TODO"   from  [2022-08-17 Wed 06:02]
> :END:
>
> ,** first-level headline [0/0]
>
> ,*** TODO second-level headline [2/2]
>
> - [X] item 1
> - [X] item 2
>
> #+end_src
>
> When I press keybinding {C-c C-c} to do checkbox statistics updating on 
> headline "TODO second-level
> headline [2/2]|" (point is |) checkbox statistics, this caused upper headline 
> checkbox statistics
> auto update and reset to zero which is wrong.

I am unable to reproduce on the latest main.
Did you try with emacs -Q?

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

Re: size restriction on columnview?

[Ihor Radchenko]

Uwe Brauer  writes:

> The following columnview will indeed display all the properties of all
> the headings in table form.
>
> #+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :hlines 1 :indent nil  
> :format "%5TODO(Status) %SUMMARY(Sum)  %5NR(Nr) %5ITEM(Stuff) 
> %5RG-Date(R-Date) %5Amount(Amount)  %5User1(User1){X/} %5User2(User2){X/} 
> %5An_Company1(An Company1) %5An_Firm(An Firm) %5Von_Company1(Von Company1) 
> %5Geld_Company1(EUR Company1) %5Von_Firm(Von Firm) %5Geld_Firm(EUR Firm) 
> %5All(All) %5Author(Autor) %5Diff(Diff)"
>
> However when I add *one* property more to the columnview format entry
> then the resulting table will only show around 15 headings (that is the
> table has only 15 rows).
>
> Any comments? I am really puzzled.

The comment is: it does not make sense.
A reproducer would help a lot.

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

Re: [BUG] Mention #+PRINT_BIBLIOGRAPHY in the Org manual

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> I wonder why the Org manual at
>
> https://orgmode.org/manual/Citation-handling.html
>
> does not mention the #+PRINT_BIBLIOGRAPHY keyword.

For record, the manual now contains a dedicated section for printing the
bibliography and additional options that can passed to it.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.org#n17095

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

Re: [PATCH] Fix date in org-latex--format-spec

[Ihor Radchenko]

"Lucas V. R."  writes:

> This is my first time posting here. Sorry in advance if I did something
> wrong.
> I tried customizing org-latex-title-command with a "%D" placeholder but the
> LaTeX was not compiling since this placeholder was being replaced by the
> string
>
> ((latex-fragment (:value \today :begin 1 :end 7 :post-blank 0 :parent #0)))
>
> I could not find this in previous issues and the code in the main branch
> still reproduced this error. The problem seems to be a missing call to
> org-export-data in the function org-latex--format-spec. Perhaps it is not
> necessary but I'm attaching the one-line patch that fixed things for me.
> From ddeaa68f540173a27bc0fddd6f8957b5e6af7ffe Mon Sep 17 00:00:00 2001
> From: "Lucas V. R" 
> Date: Tue, 22 Feb 2022 14:46:45 -0300
> Subject: [PATCH] ox-latex: date should not be a property list

Applied onto main with amendments to the commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a7a579d06acc048c259893839c304f2ef56eab45

Thanks for your contribution!
You will now be listed at https://orgmode.org/worg/contributors.html

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

Re: [BUG] S- Overridden by windmove.el [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]

[Ihor Radchenko]

Yingnan Cui  writes:

> It seems that org-mode's S- is overriden by windmove.el even
> though I'm adding the following configurations according to the org
> manual:
> ```emacs-lisp
> ;; Make windmove work in Org mode:
> (add-hook 'org-shiftup-final-hook 'windmove-up)
> (add-hook 'org-shiftleft-final-hook 'windmove-left)
> (add-hook 'org-shiftdown-final-hook 'windmove-down)
> (add-hook 'org-shiftright-final-hook 'windmove-right)
> ```

Just do not activate windmove-mode.
The above suggestion will directly call windmove without a need in
windmove-mode being active.

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

Re: [BUG] org-capture is not reentrant [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]

[Ihor Radchenko]

Ignacio Casso  writes:

> ... I took a quick look at the code and it
> seems that a global property list is used internally for the capture
> process, which seems to be only initialized at the start of the capture
> process and therefore the inner capture would overwrite it in our
> case. I saw also that the global property list is copied to a buffer
> local property list for the case of starting a new capture process
> before typing C-c C-c in the indirect capture buffer.

Confirmed.

Your understanding is correct. Capture inside capture is not supported
because of the internal capture code design.

> Do you think it would be easy to recycle that code to also have a stack
> of property lists and allow reentrancy? Would yo consider it useful? I
> would, but not really worth it to implement unless it's a low hanging
> fruit. If it is, I'd volunteer to do so (although my elisp-fu may be a
> little bit lacking yet).

It will be definitely useful. We have bugs surfaced from time to time
because of nested captures. However, one will need to check the logic
inside org-capture first and identify how to switch from global
variables holding the capture state to something more robust.

A good first step could be looking through org-capture code and the
functions it calls and supplying comments to places in the code that are
not immediately clear. Such comments would be useful for others as well.

We can also help in the process, if you volunteer.

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

Re: [BUG] new cite: links not allowed at start of org heading [9.5 (9.5-gded97b @ c:/Users/scott/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Scott Otterson  writes:

> If I make a new org heading, and put the cursor just after the space
> following the last heading star, then the citar package won't create a new
> style citation link; if I type C-c b, I get this error message in the
> minibuffer:
>
> user-error: Cannot insert a citation here
>
> The author of citar tells me that this error comes from org, not the citar
> package.
>
> However, if I type a single visible character first, then C-c b works.  In
> other words:
>
> I can do this:
>
> *** A [cite:@Kraskov04EstMutInfKNN]
>
> I can't do this:
>
> *** [cite:@Kraskov04EstMutInfKNN]

Thanks for reporting, and sorry for the late reply.
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3d1f4e0af0d98c57b720b9090e3a28fbffccafdf

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

Re: Babel: command line args in java

[Ihor Radchenko]

Jarmo Hurri  writes:

>   3. If this is desired behaviour, can I write a patch adding a new
>  header argument such as ~cmdargs~ ?

For record, we do support :cmdargs header arg in ob-java.

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

Re: [BUG] Possible Outdated Documentation, Possible Bug. "Can't compile a java block without a classname." Org-babel babel java

[Ihor Radchenko]

uruseiiyatsura  writes:

> [Java Source Code Blocks in Org 
> Mode](https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html) 
> says the following:
>
> "It is not necessary to include the class statement or define a main method. 
> ob-java will wrap a source code block in boilerplate class and main method 
> definitions if they are omitted. If :classname and the class definition in 
> the source code block are both omitted, the class will be named Main."
>
> The following example is provided:
>
> #+begin_src java :results output
> System.out.print("hello, world");
> #+end_src
>
> This returns error "can't compile a java block without a classname." This 
> contradicts the documentation.

Sorry for the late reply.
Your example works just fine on the latest Org.
I cannot reproduce the problem.

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

* Max Nikulin  [2022-10-19 15:53]:
> Better balanced position is necessary otherwise it would be just weakness in
> communication with people who do not care if some software is free.

Then such people have the chance to learn what is free software. Their
weakness is not to know what it is.

> > I find it unfortunate that some people create proprietary software
> > that uses Org files.
> 
> It sounds like you regret about absence of a kind of vendor lock. File
> formats and communication protocols must be free. There are enough examples
> when free software can not be developed due to lack of specifications. Why
> would you expect cooperation from vendors if you wish to have fences at your
> side in similar cases?

Vendor:
https://www.gnu.org/philosophy/words-to-avoid.html#Vendor

You have misunderstood the idea. I have never mentioned "absence of a
kind of vendor lock" or similar.

So let us close that discussion and keep creating free software.


-- 
Jean

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

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

Weird behavior of org-element-object-lex

[Damien Cassou]

Hi,

here is the beginning of `org-element-object-lex`:

  (defun org-element--object-lex (restriction)
"Return next object in current buffer or nil.
  RESTRICTION is a list of object types, as symbols, that should be
  looked after.  This function assumes that the buffer is narrowed
  to an appropriate container (e.g., a paragraph)."
(cond
 ((memq 'table-cell restriction) (org-element-table-cell-parser))
 ((memq 'citation-reference restriction)
  (org-element-citation-reference-parser))
 (t …)))

>From what I understand, if `restriction` includes 'table-cell (or
'citation-reference), and if the content isn't a table-cell,
`org-element--object-lex` will immediately return nil without trying
other object types.

Is that a bug?


-- 
Damien Cassou

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

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

[Bruno Barbier]

Ihor Radchenko  writes:

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

Indeed. Done.


> We probably want something like
>
> :parameters (and (org-string-nw-p parameters) (org-trim parameters))
>
> Just as in org-element-src-block-parser.

Actually, I forgot to raise the question; but, you answered it anyway! ;-)
Done.


>
> No dangling ")" please.

Sorry. Fixed.


>
>> +(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.

For `:parameters', I'm now doing the same as in
`org-element-src-block-interpreter'.


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

I added more tests.

I also added a new independent patch, to fix a bug when interpreting a special
block that has no content, and some tests.

Let me know if I did miss something,
And thank you for the review!


Bruno

>From ca4ab60a11330b97e1fb8c8d2941e383189fd82e Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Wed, 19 Oct 2022 00:37:05 +0200
Subject: [PATCH 1/2] org-element-special-block-interpreter: Fix when no
 content

* lisp/org-element.el (org-element-special-block-interpreter): Use
empty string when content is nil.

*
testing/lisp/test-org-element.el (test-org-element/special-block-interpreter):
Test the case with no content.
---
 lisp/org-element.el  |  2 +-
 testing/lisp/test-org-element.el | 12 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 7b26e877e..ca3b61b49 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1910,7 +1910,7 @@ (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)))
+(format "#+begin_%s\n%s#+end_%s" block-type (or contents "") block-type)))
 
 
 
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 187cadf7a..985108e37 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2425,7 +2425,11 @@ (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
+  ;; When contents is empty, the parsed contents is nil.
+  (should
+   (org-test-with-temp-text "#+BEGIN_SPECIAL\n#+END_SPECIAL"
+ (eq nil (org-element-contents (org-element-at-point))
 
 
  Src Block
@@ -2943,7 +2947,11 @@ (ert-deftest test-org-element/special-block-interpreter ()
   "Test special block interpreter."
   (should (equal (org-test-parse-and-interpret
 		  "#+BEGIN_SPECIAL\nTest\n#+END_SPECIAL")
-		 "#+begin_SPECIAL\nTest\n#+end_SPECIAL\n")))
+		 "#+begin_SPECIAL\nTest\n#+end_SPECIAL\n"))
+  ;; No content
+  (should (equal (org-test-parse-and-interpret
+		  "#+BEGIN_SPECIAL\n#+END_SPECIAL")
+		 "#+begin_SPECIAL\n#+end_SPECIAL\n")))
 
 (ert-deftest test-org-element/babel-call-interpreter ()
   "Test Babel call interpreter."
-- 
2.37.3

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

Add a property `:parameters' 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'.

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

*
testing/lisp/test-org-element.el (test-org-element/special-block-parser):
Add a new test for PARAMETERS.

(test-org-element/special-block-interpreter): Add new tests for PARAMETERS.
---
 lisp/org-element.el  | 19 --
 testing/lisp/test-org-element.el | 33 ++--
 2 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index ca3b61b49..ce6daaef8 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1868,13 +1868,15 @@ (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', `:begin', `:end',
+`:contents-begin', `:contents-end', `:post-blank' and
+`:post-affiliated' keywords.
 
 Assume point is at the 

Re: Haskell code blocks

[Bruno Barbier]

Hi Thomas, Ihor,

I'm not currently using ob-haskell, but I do have a version of GHC.  As
I may use ob-haskell one day, I decided to take a look.

Here are the versions I'm using:
   #+begin_src elisp
 (list (list "emacs" emacs-version)
   (list "org"   org-version)
   (list "ghc"   (string-trim (shell-command-to-string "ghc -V")))
   )
   #+end_src

   #+RESULTS:
   | emacs | 29.0.50 |
   | org   | 9.6-pre |
   | ghc   | The Glorious Glasgow Haskell Compilation System, version 8.10.7 |


The following code block is incorrect:

   #+begin_src haskell :results output
 main :: IO () 
 main = putStrLn  "Hello, World!"
 main
   #+end_src

   #+RESULTS:
   : :2:1-4: error:
   : • Variable not in scope: main :: IO ()
   : • Perhaps you meant ‘min’ (imported from Prelude)
   : Prelude> Hello, World!

The first line tries to evaluate 'main' which doesn't exist (yet).

The following modified block works, using the compiler.

   #+begin_src haskell :compile yes :results output
 main :: IO () 
 main = putStrLn  "Hello, World!"
   #+end_src

   #+RESULTS:
   : Hello, World!


The following works using the interpreter:
   #+begin_src haskell
 let { main :: IO () 
 , main = putStrLn  "Hello, World!"
 }
 main
   #+end_src

   #+RESULTS:
   : Hello, World!

A simpler version, that just print "Hello, World!" works:

   #+begin_src haskell
 putStrLn  "Hello, World!"
   #+end_src

   #+RESULTS:
   : Hello, World!

Just evaluating the string doesn't work!
   #+begin_src haskell
 "Hello world!"
   #+end_src

   #+RESULTS:

as we don't get any result ...

If I understand correctly, it seems to be a bug in ob-haskell;
`org-babel-comint-with-output' shouldn't be instructed to remove the
output if it matches the input, else, it will remove any constant.

Adding a type annotation is enough to make it works:

   #+begin_src haskell
 "Hello world!" :: String
   #+end_src

   #+RESULTS:
   : Hello world!
   
Or fixing `org-babel-interpret-haskell' (see attached patch):
   #+begin_src haskell
 "Hello world!"
   #+end_src

   #+RESULTS:
   : Hello world!

Another example that works too, with or without the patch:
   #+begin_src haskell
 concat ["Hello", ", ", "World", "!"]
   #+end_src

   #+RESULTS:
   : Hello, World!


I've attached the patch that I've used to fix ob-haskell.

Should I submit a patch for ob-haskell ?

Bruno


>From f2e91a62469e84ce1d3036216ae3eca4084f3b94 Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Wed, 19 Oct 2022 19:44:42 +0200
Subject: [PATCH] org-babel-interpret-haskell: Don't remove outputs that match
 inputs

* lisp/ob-haskell.el (org-babel-interpret-haskell): Change the call to
`org-babel-comint-with-output'.
---
 lisp/ob-haskell.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index d195dcf87..99e590bfb 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -136,7 +136,7 @@ (defun org-babel-interpret-haskell (body params)
 	 (comint-preoutput-filter-functions
 	  (cons 'ansi-color-filter-apply comint-preoutput-filter-functions))
  (raw (org-babel-comint-with-output
-		  (session org-babel-haskell-eoe t full-body)
+		  (session org-babel-haskell-eoe nil full-body)
 (insert (org-trim full-body))
 (comint-send-input nil t)
 (insert org-babel-haskell-eoe)
-- 
2.37.3

Re: Formatting in citation locator

[M . ‘quintus’ Gülker]

Am Mittwoch, dem 19. Oktober 2022 schrieb Ihor Radchenko:
> It is expected because we do not allow "]" right after markup. You'd
> need to insert an escape character (zero-width space) to force the
> italics markup in [Sondervotum /Schluckebier/].
> See https://orgmode.org/manual/Escape-Character.html.

Thanks for the hint, but it does not work still even if I change the
line to contain the said zero-width space:

Abweichende Meinung. [cite:@bverfg2010vds p. 373 [Sondervotum 
/Schluckebier/​],]

The buffer is now fontified as expected, but it does not work when
exported to HTML:

1 BVerfGE 125, 260 (373 [Sondervotum /Schluckebier/​])

This however I think comes down to the same problem which is described
at .

  -quintus

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

Re: Error during PDF export but the PDF file is exported

[Pascal Quesseveur]

>"IR" == Ihor Radchenko  writes:

  IR> I think that creating a temporary file locally is excessive.

  Perhaps, but I couldn't find another way.

  IR> You could guard the logic behind `file-remote-p'.

  FMU file-remote-p works onnly when there is a handler on path for
operation file-remote-p, which is not true in the general
case. Otherwise that function returns nil.

  OTOH it is possible to reserve the creation of a temporary file only
when the file is not already present.


-- 
Pascal Quesseveur
pques...@gmail.com

Re: Line breaks and brackets in LaTeX export

[Max Nikulin]

On 18/10/2022 11:39, Ihor Radchenko wrote:

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.


I have an impression that markup generated by children often added using 
%s to some other construct. I may be wrong.



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.


I do not expect negative effect from a comment added at the end of line. 
Optimizing pass may be performed prior to user filters.


As another approach text properties may be used as a communication 
channel unless they are stripped by ox.

Re: Line breaks and brackets in LaTeX export

[Max Nikulin]

For a while I have the following question. Is \\{} have the same
effect on tabularray parser as \\\empty?


Throw an error before \hline.


It is possible to use
 \begin{tblr}[expand=\empty]{rl}
but I would prefer to reserve such feature for a more nobble purpose.


I've had a
first look at tabularray.sty, but I'm not familiar enough with the new
LaTeX 3 syntax and, frankly, I'm lost...


While it is not easy for me to read code LaTeX2e core and packages, I 
should say that I have no guess at all when I am looking at tabularray 
sources. It is a completely different language.


I have started a discussion requesting for a \\-like command without 
optional arguments. Maybe somebody will suggest a better workaround instead.

https://github.com/lvjr/tabularray/discussions/321


I've tried all the packages involved in tables that I can think of
(longtable, siunitx, tabularx, booktabs, array, and I don't know if I
forgot any) and in all of them the \empty solution works fine. It seems
that tabularray is the black sheep here.


I think tabularray is unique with a regexp-based parser. I had a hope 
that new approach does not allow newline between \\ and its arguments, 
but unfortunately compatibility with older code is preserved in this aspect.


From LaTeX companion I remember supertabular as an alternative for 
longtable, but I am unsure if it is alive yet.

RE: R code blocks in org version 9.5

[Cook, Malcolm]

> My R code blocks work fine in org 9.5. When I plot graph using base graphics 
> in session, it works fine. The problem is with lattice graphs. With below 
> header variables, code block works fine.
> 
> #+begin_src R :session *R* :results graphics file :file test.png
> library(lattice)
> print(histogram(rnorm(1)))
> #+end_src
> 
> But this does not work. Emacs hangs.
> 
> #+begin_src R :session *R* :results output graphics file :file test.png
> library(lattice)
> histogram(rnorm(1))
> #+end_src

In my hands, all combinations work with/without the `output` and with/without 
the `print`.

IMO, you should not want to include the print. 

Here is my environment:

Org mode version 9.5.2 (release_9.5.2-9-g7ba24c)

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw3d scroll bars) of 2022-01-19

ESS version 18.10.3snapshot

R
sessionInfo()
R version 4.2.0 (2022-04-22)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /n/apps/CentOS7/install/r-4.2.0/lib64/R/lib/libRblas.so
LAPACK: /n/apps/CentOS7/install/r-4.2.0/lib64/R/lib/libRlapack.so

locale:
[1] C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

other attached packages:
[1] lattice_0.20-45

loaded via a namespace (and not attached):
[1] compiler_4.2.0 grid_4.2.0

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]

OK, got it now, thanks! I confirmed everything you said.

My takeaway is that instead of using global properties as a single property
at the top level,
I should create a top-level properties drawer, which will have immediate
usability.

In the case of my example that would be:

C-u C-c C-x d HOURLY_RATE  150 

and then HOURLY_RATE is immediately usable in my table, without even having
to save the file.

On Mon, Oct 17, 2022 at 11:03 PM Ihor Radchenko  wrote:

> Jeff Trull  writes:
>
> > 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).
> > ...
> > 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.
>
> It is expected and documented.
> See 17.8 Summary of In-Buffer Settings section of the manual.
> Basically, you need to press C-c C-c on the property line to make Org
> refresh the settings.
>
> Alternatively, you can use document property drawer. It is updated
> automatically on the latest development version of Org.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: R code blocks in org version 9.5

[William Denton]

On 19 October 2022, Naresh Gurbuxani wrote:


It seems that org 9.5 has simplified header arguments for R code blocks that 
use grid graphics.

Org 9.4 requires
:results output graphics file

Org 9.5 requires
:results output file

Do other users find the same change?


They both work for me, though I've never put "output" in such a block: I always 
use ":results graphics file".



Bill

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

Re: R code blocks in org version 9.5

[Colin Baxter]

> Naresh Gurbuxani  writes:

> It seems that org 9.5 has simplified header arguments for R code
> blocks that use grid graphics.

> Org 9.4 requires :results output graphics file

> Org 9.5 requires :results output file

> Do other users find the same change?

> Sent from my iPhone

>> On Oct 19, 2022, at 8:59 AM, Naresh Gurbuxani
>>  wrote:
>> 
>> Thanks to your suggestion, I was able to narrow down the problem.
>> 
>> My R code blocks work fine in org 9.5. When I plot graph using
>> base graphics in session, it works fine.  The problem is with
>> lattice graphs. With below header variables, code block works
>> fine.
>> 
>> #+begin_src R :session *R* :results graphics file :file test.png
>> library(lattice) print(histogram(rnorm(1))) #+end_src
>> 
>> But this does not work.  Emacs hangs.
>> 
>> #+begin_src R :session *R* :results output graphics file :file
>> test.png library(lattice) histogram(rnorm(1)) #+end_src
>> 
>> I can simply add print command to my code blocks.  Is there an
>> easier solution?

I'm afraid both your above examples work for me. I'm on emacs-29.0.50
and org-mode version 9.6-pre (release_9.5.5-995-g4b9aef)

Best wishes

Re: R code blocks in org version 9.5

[Naresh Gurbuxani]

It seems that org 9.5 has simplified header arguments for R code blocks that 
use grid graphics.

Org 9.4 requires
:results output graphics file

Org 9.5 requires
:results output file

Do other users find the same change?

Sent from my iPhone

> On Oct 19, 2022, at 8:59 AM, Naresh Gurbuxani  
> wrote:
> 
> Thanks to your suggestion, I was able to narrow down the problem.
> 
> My R code blocks work fine in org 9.5. When I plot graph using base graphics 
> in session, it works fine.  The problem is with lattice graphs. With below 
> header variables, code block works fine.
> 
> #+begin_src R :session *R* :results graphics file :file test.png
> library(lattice)
> print(histogram(rnorm(1)))
> #+end_src
> 
> But this does not work.  Emacs hangs.
> 
> #+begin_src R :session *R* :results output graphics file :file test.png
> library(lattice)
> histogram(rnorm(1))
> #+end_src
> 
> I can simply add print command to my code blocks.  Is there an easier 
> solution?
> 
> Naresh
> 
> Sent from my iPhone
> 
>>> On Oct 18, 2022, at 11:14 PM, William Denton  wrote:
>>> 
>>> On 18 October 2022, Naresh Gurbuxani wrote:
>>> 
>>> Recently I started using org version 9.5 with my init.el that worked well 
>>> for org 9.4
>>> 
>>> In org 9.5, I can run stand-alone R code blocks.  But when I try to run 
>>> them in a session, emacs hangs.
>> 
>> I haven't had any problems like that, and I use R session code blocks pretty 
>> much every day.  Can you narrow it down any?  Does even the most basic 
>> block, just adding 1 + 1, not work?  What about with emacs -Q?
>> 
>> 
>> Bill
>> 
>> --
>> William Denton
>> https://www.miskatonic.org/
>> Librarian, artist and licensed private investigator.
>> Toronto, Canada

Re: R code blocks in org version 9.5

[Naresh Gurbuxani]

Thanks to your suggestion, I was able to narrow down the problem.

My R code blocks work fine in org 9.5. When I plot graph using base graphics in 
session, it works fine.  The problem is with lattice graphs. With below header 
variables, code block works fine.

#+begin_src R :session *R* :results graphics file :file test.png
library(lattice)
print(histogram(rnorm(1)))
#+end_src

But this does not work.  Emacs hangs.

#+begin_src R :session *R* :results output graphics file :file test.png
library(lattice)
histogram(rnorm(1))
#+end_src

I can simply add print command to my code blocks.  Is there an easier solution?

Naresh

Sent from my iPhone

> On Oct 18, 2022, at 11:14 PM, William Denton  wrote:
> 
> On 18 October 2022, Naresh Gurbuxani wrote:
> 
>> Recently I started using org version 9.5 with my init.el that worked well 
>> for org 9.4
>> 
>> In org 9.5, I can run stand-alone R code blocks.  But when I try to run them 
>> in a session, emacs hangs.
> 
> I haven't had any problems like that, and I use R session code blocks pretty 
> much every day.  Can you narrow it down any?  Does even the most basic block, 
> just adding 1 + 1, not work?  What about with emacs -Q?
> 
> 
> Bill
> 
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada

Re: Best android app

[Max Nikulin]

On 17/10/2022 18:54, Jean Louis wrote:


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


I am unsure who has intention to steer users to non-free software. There 
was a message mentioning some application. I assume that the person was 
just unaware of strict rules. It will happen in future as well and I am 
against excessively aggressive reaction.


The person may be already familiar with that non-free apps. We had a 
chance to ask about features missed in free applications and actual 
experience. Perhaps the same tasks may be performed in a bit different 
and less obvious way and no modification of Org and Co is required. 
However you insist that we have to through away such possibilities and 
adding outcome from such conversations to web site is prohibited, so it 
makes it significantly harder to use obtained information in later 
discussions.


Better balanced position is necessary otherwise it would be just 
weakness in communication with people who do not care if some software 
is free.



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


It sounds like you regret about absence of a kind of vendor lock. File 
formats and communication protocols must be free. There are enough 
examples when free software can not be developed due to lack of 
specifications. Why would you expect cooperation from vendors if you 
wish to have fences at your side in similar cases?


It is more productive to consider proprietary apps as feature requests 
and to put efforts into improving of Org suite.

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Juan Manuel Macías writes:

>> For a while I have the following question. Is \\{} have the same
>> effect on tabularray parser as \\\empty?
>
> Throw an error before \hline.

To expand on my answer: \\{} and \\\empty, before \hline, throw the same
error:

--
ERROR: Misplaced \noalign.

--- TeX said ---
\hline ->\noalign 
{\ifnum 0=`}\fi \hrule \@height \arrayrulewidth \futurelet...

l.17 \end
{tblr}
--- HELP ---
>From the .log file...

I expect to see \noalign only after the \cr of
an alignment. Proceed, and I'll ignore this case.
--

Re: Verse block and separations

[Juan Manuel Macías]

Max Nikulin writes:

> I still prefer to avoid replacement of latex newlines back to empty
> string. Though I am really happy with the following code, I expected a
> more concise snippet. Unit tests may found bugs in it.
>
> (let ((contents "\n\n 0  \n\n\na b\nc d e  \n\n\nf g  \n   h i\n\n"))
>   ;; Strip leading newlines.
>   (setq contents
>   (replace-regexp-in-string
>(rx string-start (1+ (0+ blank) ?\n)) ""
>contents 'fixed-case 'literal))
>   ;; Add explicit line breaks and strip trailing spaces.
>   (setq contents
>   (replace-regexp-in-string
>(rx (0+ blank) ?\n
>(optional (group (1+ (0+ blank) ?\n)))
>(optional (group (0+ blank) (not (any blank ?\n)
>(lambda (m)
>  (let ((par (match-string 1 m))
>(next (match-string 2 m)))
>(if next
>(concat (if par "\n\n" "\n")
>next)
>  "")))
>contents 'fixed-case 'literal))
>   ;; Indented lines.
>   (replace-regexp-in-string
>(rx line-start (1+ blank))
>(lambda (m) (format "\\hspace*{%dem}" (length m)))
>contents 'fixed-case 'literal))
>
> Feel free to use it for inspiration during your work on a patch.

OK, thanks a lot. (BTW, I have yet to reply to some interesting things
you mention in this thread about the verse environment).

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Max Nikulin writes:

> Another recipe should be used:
>
> | / | < | > |
> |   | a | b @@latex:\rule[-1em]{0pt}{1em}@@ |
> |   | c | d |
>
> I believe that a more convenient way to override [0pt] to some other
> length for particular row should exist, but I have no idea which
> syntax should be used.

I think this new recipe you propose works fine, although I haven't
done a thorough test yet. In principle, it shouldn't be a problem.

By the way, now I remember that the package verse adds a series of extra
arguments to \\ (p. 6 in the documentation:
https://www.ctan.org/pkg/verse). As a user, the only way I can think of
to add arguments instead of [0pt] or \empty is by using a small export
filter to act on the final output. Perhaps putting something like
!!new-argument!! on the affected row/verse/line to guide the filter.

> As to tabulararray, I still consider it as an experimental package.
> Perhaps I will install a more modern container. I am curious what code
> handles \\[0pt]. Likely I should read docs to get impression related
> to design goals and approaches to implement them. The bug tracker of
> the project looks like an appropriate place to ask a question
> concerning \\ variant safe for dumb exporters.

Keep in mind that tabularray is a latex3 package and, in principle,
everything that is latex3 is here to stay. Certainly, it is a blessing
compared to the classic tabular environments, because it is tremendously
versatile. That is why it already has a significant number of users:
https://tex.stackexchange.com/questions/tagged/tabularray

And Org already provides what is necessary to use its syntax. I've had a
first look at tabularray.sty, but I'm not familiar enough with the new
LaTeX 3 syntax and, frankly, I'm lost...

I've tried all the packages involved in tables that I can think of
(longtable, siunitx, tabularx, booktabs, array, and I don't know if I
forgot any) and in all of them the \empty solution works fine. It seems
that tabularray is the black sheep here.

> For a while I have the following question. Is \\{} have the same
> effect on tabularray parser as \\\empty?

Throw an error before \hline.

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:

   (replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
 "\\(\n\\)+\\([ \t]*\\)+" "\n"
 (replace-regexp-in-string
  "\\([ \t]*\\)?[ \t]*\n" "\n"
  (setq contents
(if lin
(replace-regexp-in-string "\\(\n\\)+\\([ \t]*\n\\)+" 
"!\n\n"
  contents)
  contents)) nil t) nil t) nil t) linreset)


I had a hope, it is possible to do it in a single pass of 
`replace-regexp-in-string', but unfortunately the function does not 
allow to make conditional substitution based on (rx (optional (group 
string-start))) (a bug?).


I still prefer to avoid replacement of latex newlines back to empty 
string. Though I am really happy with the following code, I expected a 
more concise snippet. Unit tests may found bugs in it.


(let ((contents "\n\n 0  \n\n\na b\nc d e  \n\n\nf g  \n   h i\n\n"))
  ;; Strip leading newlines.
  (setq contents
(replace-regexp-in-string
 (rx string-start (1+ (0+ blank) ?\n)) ""
 contents 'fixed-case 'literal))
  ;; Add explicit line breaks and strip trailing spaces.
  (setq contents
(replace-regexp-in-string
 (rx (0+ blank) ?\n
 (optional (group (1+ (0+ blank) ?\n)))
 (optional (group (0+ blank) (not (any blank ?\n)
 (lambda (m)
   (let ((par (match-string 1 m))
 (next (match-string 2 m)))
 (if next
 (concat (if par "\n\n" "\n")
 next)
   "")))
 contents 'fixed-case 'literal))
  ;; Indented lines.
  (replace-regexp-in-string
   (rx line-start (1+ blank))
   (lambda (m) (format "\\hspace*{%dem}" (length m)))
   contents 'fixed-case 'literal))

Feel free to use it for inspiration during your work on a patch.

[BUG] org-num-mode does not clear previous numbers [9.5.5 (9.5.5-g9ce472 @ /home/user/.config/emacs/straight/build/org/)]

[General discussions about Org-mode.]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


When I call `(org-num-mode)' from lisp multiple times on a single
orgmode buffer, I get multiple numberings on each heading.
Subsequently, when I call `(org-num-mode -1)' or `(org-num--clear)',
only one layer of numberings are removed.

This behavior is observed at the build below, but should still be
reproducible in current HEAD (4179d1205ed791254aa21fadf262623bc805595d).

I have also successfully replicated this issue from a `emacs -Q -nw'
environment, using the same orgmode version.  Because of this, I have
removed the "current state" section since they are proven irrelevant.

The offending code is the `cond' construct in `org-num-mode' minor mode
definition, where we are directly resetting `org-num--overlays'.  I
think we should run something like `(org-num--clear)' before the two
`setq''s, so that the previous numbers are cleared.

Alternatively (and probably a bad advice), maybe we could simply not
execute the "enable" branch in `cond' when `org-num--overlays' is
non-nil?

I don't have a full understanding of the role of `org-num--numbering',
so I don't have anything to say about this variable.


Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.17.6)
 of 2022-10-14
Package: Org mode version 9.5.5 (9.5.5-g9ce472 @ 
/home/user/.config/emacs/straight/build/org/)

current state:
==
;; omitted

Re: [BUG] ox-odt fails for org-id links (e.g., from org-roam v2) [9.5.2 (9.5.2-gfbff08 @ /home/moritz/.emacs.d/elpa/27.2/develop/org-9.5.2/)]

[Ihor Radchenko]

Moritz Schäfer  writes:

> Thanks for getting back to me on this.
>
> Here is a minimal example. In org-roam (v2), when having a file/node:

Thanks! An example helps a lot.

Can you try the attached patch against the latest main branch?

>From 4e5c7373115cfeb88fb4392252d682fad8d178a8 Mon Sep 17 00:00:00 2001
Message-Id: <4e5c7373115cfeb88fb4392252d682fad8d178a8.1666175750.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 19 Oct 2022 18:33:44 +0800
Subject: [PATCH] ox-odt: Allow id: links to files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox-odt.el (org-odt-link): Transcode id: links to file property
drawers.

Reported-by: Moritz Schäfer 
Link: https://orgmode.org/list/CA+FVMQDBUwCQHFOWieELaB3=4mh2yba66+npcuqwvvv_1hv...@mail.gmail.com
---
 lisp/ox-odt.el | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 208a39d9d..4ff667640 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -2737,6 +2737,12 @@ (defun org-odt-link (link desc info)
 	   (format "%s"
 		   (org-export-get-reference destination info)
 		   (or desc (org-export-get-ordinal destination info
+  ;; Link to a file, corresponding to string return value of
+  ;; `org-export-resolve-id-link'.
+  (plain-text
+   (format "%s"
+		   destination
+		   (or desc (org-export-get-ordinal destination info
 	  ;; Fuzzy link points to some element (e.g., an inline image,
 	  ;; a math formula or a table).
 	  (otherwise
-- 
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: Error during PDF export but the PDF file is exported

[Ihor Radchenko]

[Adding Org mailing list back to the loop. Someone forgot reply all in
the earlier messages]

Pascal Quesseveur  writes:

>>"IR" == Ihor Radchenko  a écrit :
>
>   IR> No, if there is an error when running LaTeX. No PDF file might be
>   IR> produced in some scenarios. And we need to clearly communicate such
>   IR> scenarios to the user.
>
> Here is a patch to org-macs.el (from Emacs 28.1) that works for me. I
> have checked with files on a server whose current date was behind my
> PC. I also checked with a sync server and with local files.

Thanks!

I think that creating a temporary file locally is excessive. You could
guard the logic behind `file-remote-p'.

Also, can you prepare a proper patch? See
https://orgmode.org/worg/org-contribute.html#first-patch

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

Re: Haskell code blocks

[Ihor Radchenko]

"Thomas S. Dye"  writes:

>> To clarify, it looks like Prelude Emacs is doing something wrong 
>> here.
>> Something that breaks haskell-mode and consequently ob-haskell.
>
> I'm using Spacemacs.  Prelude is a standard module in Haskell.  I 
> thought that might be the source.

Thanks for the extra info!
What happens if you run Haskell repl and check the values of
haskell-prompt-regexp and comint-prompt-regexp in the Haskell repl
buffer?

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

Re: [O] Quoting of noweb references and variable noweb function arguments

[Ihor Radchenko]

Cody Goodman  writes:

> I'm having an issue with quoting noweb functions. Since quote is used to
> signify a variable being passed into the noweb syntax function call I
> cannot put a quote around theno web function call and end up with invalid
> bash.
>#+begin_src sh :noweb yes :var logValUserVar="user2"
> logValUserPass="pass2" jqExpr="[]keys"
>json=<>
>echo $json | jq $jqExpr
>#+end_src

You cannot pass src block variables to noweb. It is currently not supported.

And you cannot pass bash bindings to noweb. Noweb expansion happens
before executing the bash code. It is not possible to know that bash
assignments at that point.

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

Can someone dig the reasons behind emphasis regexp limitations?

[Ihor Radchenko]

Org allows *emphasis* markers to be surrounded by spaces to some markup:
1. Before opening emphasis marker we can have
   space; -('"{
2. After closing emphasis marker we can have
   space; -.,;:!?'")}\[

(see org-element--parse-generic-emphasis)

I keep looking at these rules and remain confused, even though I do
remember that Nicolas stated good reasons for this.

But... Why "[" can be after closing marker and _not_ before opening
marker. It is counter-intuitive. And what about "]"?

Can somebody dig into that mailing list archives and figure out the
reasons why some characters are allowed and some now. I will then put
them into code comments or maybe even into Org syntax spec.

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

Re: Formatting in citation locator

[Ihor Radchenko]

Marvin Gülker  writes:

> The decision contains two dissenting opinions at its end. Now I try to
> cite the first one like this:
>
> #+TITLE: Test
> #+AUTHOR: Test
> #+LANGUAGE: de
> #+cite_export: csl /tmp/juristische-schulung.csl
> #+bibliography: /tmp/test.bib
>
> Abweichende Meinung. [cite:@bverfg2010vds p. 373 [Sondervotum 
> /Schluckebier/],]
> ...
> Exporting this to HTML comes out as:
>
> ¹ BVerfGE 125, 260 (373 [Sondervotum /Schluckebier/])
>
> I would have expected that the word “Schluckebier” – which is the
> dissenting judge’s name – is italicised, but instead the raw markup is
> exported. I want it italicised, because it is common to italicise names
> in German judicial citation styles.
>
> Is this expected behaviour?

It is expected because we do not allow "]" right after markup. You'd
need to insert an escape character (zero-width space) to force the
italics markup in [Sondervotum /Schluckebier/].
See https://orgmode.org/manual/Escape-Character.html.

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

bug#51034: error when doing a time stamp in org with no newline after heading

[Ihor Radchenko]

laslydone  writes:

>   To reproduce:
> 1. emacs -Q
> (setq org-todo-keywords
>'((sequence "REPORT(r!)")))
> 2. M-x eval-buffer 
> 3. C-x b test 
> 4. M-x org-mode 
> 5. * testheading
> 6. C-c C-t r

This issue is no longer present in the latest Org version (main branch).

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

Re: [PATCH] Org Capture Add Tags with org-toggle-tag

[Ihor Radchenko]

Kevin Foley  writes:

> I have a capture template which utilizes %^g to prompt me for a tag to
> add to a headline which already has a tag.  An example to demonstrate
> is:
>
> * TODO %? %^g :foo:
>
> If I call this template and give it "bar" when prompted for a tag, it
> results in (where | is the cursor position):
>
> * TODO | :bar::foo:
>
> And bar is recognized as a tag.
>
> I've been able to resolve this with the attached patch.  However,
> looking at the git history of that code it seems the intent might have
> been to prevent some recursive resolution so I'm not sure if this breaks
> that.
>
> I've realized I could also attach the %^g to :foo: tag in the template
> and things work as expected but if that's the expectation then I think
> it's worth mentioning in the docstring for org-capture-templates.

It sounds logical to me that every %-escape will be replaced with
corresponding text. So, your toggle behaviour would actually be
surprising for me.

If you think that the existing docstring is confusing, could you provide
a patch explaining what is not clear?

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

Re: [PATCH] Unit-test for Please add support for dlangs packagemanager to ob-C.el

[Ihor Radchenko]

tbanelwebmin  writes:

> For unit-testing Dlang, we could mock the «dub» command (compiler+packager). 
> For instance, we could replace it
> by the «cat» Linux command, just while running the unit-test.
>
> But the «cat» command introduces a new dependency on Linux. Is there a 
> portable equivalent for «cat»?

Are you talking about Shell commands? That's probably too dangerous. I
meant Elisp.

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

Re: [BUG] ox-odt fails for org-id links (e.g., from org-roam v2) [9.5.2 (9.5.2-gfbff08 @ /home/moritz/.emacs.d/elpa/27.2/develop/org-9.5.2/)]

[Moritz Schäfer]

Thanks for getting back to me on this.

Here is a minimal example. In org-roam (v2), when having a file/node:

*note_a.org *:




*:PROPERTIES::ID:   3c885843-13ad-4dd8-a57f-de8271403b85:END:#+TITLE:
Note A*



and a second file *note_b.org *:





*:PROPERTIES::ID:   715fdccf-0c40-4bbe-87b0-ae9787c46a1b:END:#+TITLE:
Note B[[id:3c885843-13ad-4dd8-a57f-de8271403b85][Link to Note A]]*



and then run *(org-odt-export-to-odt)* (within the buffer *#note_b.org
*), then I get the aforementioned error:

*OpenDocument export failed: FIXME: Unable to resolve "note_a.org
"*

Hope this helps.

Best,
Moritz

On Tue, 18 Oct 2022 at 09:46, Ihor Radchenko  wrote:

> Moritz Schäfer  writes:
>
> > When exporting an org-file with org-id based links  to odt, I get the
> > error error "FIXME: Unable to resolve ", where  is
> the
> > filename, the org-id-link was pointing to.
> >
> > Org-id links (example below) are the default for org-roam (v2).
> >
> > [[id:5222a0dd-5084-41bd-b61d-21dcb3290187][Note title]]
> >
> > The issue lies within ox-odt.el in the org-odt-link function. There, '
> > destination' takes the value of the file name of the id-link target.
> > Therefore, (org-element-type destination) gets evaluated to 'plain-text,
> > which is not resolvable by 'org-odt-link--infer-description', thus it
> > raises the error.
> >
> > I worked around this issue by adding a check for plain-text, but would
> like
> > to raise this issue here to find proper ideas on how to fix this.
>
> Thanks for reporting, and sorry for the late reply.
> Could you provide an example and steps demonstrating the problem?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 



*Moritz Schäfer**, PhD*
Bioinformatician
Postdoctoral Fellow

Christoph Bock Group



*CeMM*

Research Center for Molecular Medicine
of the Austrian Academy of Sciences

Lazarettgasse 14, AKH BT 25.3
1090 Vienna, Austria

mschae...@cemm.at

www.cemm.at

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

[Christopher M. Miles]

Ihor Radchenko  writes:

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

I have checked out the function `org-link-make-regexps' source code, the
regexp is hard to understand for me. I will study it when I got time to
figure whether I can improve it. Thanks for your hint.

-- 

[ 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

[SOLVED] Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute

[Christopher M. Miles]

Eli Zaretskii  writes:

>> From: Ihor Radchenko 
>> Date: Sun, 2 Oct 2022 18:57:56 +0800
>> Cc: Eli Zaretskii , emacs-de...@gnu.org, emacs-orgmode@gnu.org
>> 
>> 1. find an image file in your system
>> 2. emacs -Q
>> 3. M-: (erase-buffer)
>> 4. Insert "askdjaklsdj lasasd"
>> 5. M-: (require 'org)
>> 6. M-x font-lock-mode
>> 7. M-: (put-text-property (point-min) (point-max) 'face 'org-link)
>> 8.  M-: (put-text-property (point-min) (point-max) 'display (create-image
>> "/path/to/image" nil nil :ascent 'center :max-height 512))
>
> Thanks.
>
> This is because of the ":ascent 'center" part, isn't it?
>
> What would you want Emacs to do instead in this case?

I checked out the docstring of `create-image' have not found related
info about `:ascent'. Today (which is after some days) I review this
problem and searched the `:ascent' in emacs info manual, found this
property explanation. I set it to `:ascent 100` solved the problem. Now
the baseline is at the bottom of image.

Thanks a lot for pointing it out which fixed a big issue of my extension code.

-- 

[ 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] Add light argument to org-babel-lob-get-info

[Ihor Radchenko]

Ferdinand Pieper  writes:

> Ihor Radchenko  writes:
>
>> 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.
>
> I also prefer the NO-EVAL naming. I updated the patch to use no-eval and also 
> added a second patch to rename the light argument of 
> org-babel-get-src-block-info and all its occurrences (I changed the 'light to 
> 'no-eval in all its calls only for consistency and future proofing reasons, 
> altough it is unnecessary right now). Feel free to squash them into one 
> commit. I was not sure wether one or two commits would be preferred.

Thanks!
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bbec9aafee8f0cd022a8e2b782ac1f3f920fdb8f
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e58bd039e3c885cc3a3e6fd422b5a06a9ad1eea4

>> May I know if you are proposing this for a specific purpose?
>
> Thanks for asking. I use it in a function that creates quasi unique names 
> similar to org-babel-temp-file. But instead of random names it uses the 
> source block content and header info to create a unique hash. This makes it 
> very easy to create unique but from call to call consistent filenames in 
> header arguments, when you don't want to worry about the filename, but also 
> don't want to clutter your result directory (especially if its not /tmp) or 
> care about constant filenames, e.g. for linking. Without the no-eval/light 
> argument the hash generation gets stuck in a recursive loop. I attached the 
> functions for reference.
> If there is wider interest in this, these could be added to org either as a 
> variant of org-babel-temp-file or as an extension.

Have you seen org-babel-temp-stable-file?

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

Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> Sometime during the past week I have been surprised by a sudden jump in
> load time when clocking into the first task in the agenda. Today, while
> tracking down that performance change, the problem "disappeared"! The
> first clockin behaved normally.
>
> But! Pressing 'R' in the daily agenda took a long time.
>
> I ran profile-start and then pressed R.
> Here are the cpu and memory reports.
> The memory report seems odd to me.
> Thoughts?
>
> 19250 58% + ...
> 13660 41% + command-execute
> 35 0% + timer-event-handler
>
> 3,754,109,912 99% + command-execute
> 168,717 0% + timer-event-handler
> 19,138 0% + redisplay_internal (C function)
> 0 0% ...

Thanks for reporting.

Could you please run the profiler again and then save the reports to
file using M-x profiler-report-write-profile?

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