Re: Unclear where ob-spice.el is being maintained

[Christopher M. Miles]

Jonas Bernoulli  writes:

> In 2022 I changed Melpa to get ob-spice.el from
> https://repo.or.cz/ob-spice.git in response to
> https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.
>
> But org-contrib still contains that file and the README at the new
> location still contains
>
>> This source code is from [[https://github.com/tiagoweber][tiagoweber]].
>
> and
>
>> * Project status
>>
>> I put it in Org-mode contrib/ now.
>
> So... is this now being maintained by Stardiviner, at repo.or.cz,
> or not?
>
> If so, please update the README at the new location and remove the
> library from org-contrib.
>
>  Cheers,
>  Jonas

The new repo https://repo.or.cz/ob-spice.git is maintained by me (stardiviner).

-- 

[ 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

Text markup and TeX-style LaTeX fragments spanning more than three lines

[Tom Alexander]

The documentation for both text markup and TeX-style LaTeX fragments states 
that their contents (CONTENTS for text markup, BODY for TeX-style LaTeX 
fragments) cannot span more than three lines, but I'm not seeing such 
limitation for either in practice. I don't know if this is a documentation 
error or a parser error.

Documentation text markup: 
https://orgmode.org/worg/org-syntax.html#Emphasis_Markers
Documentation LaTeX fragments: 
https://orgmode.org/worg/org-syntax.html#LaTeX_Fragments

Test document text markup:
```
foo *bar
baz* lorem

text *markup
cannot
span* more

than *three
lines.
foo
bar* baz

foo *bar \\
baz \\
lorem \\
ipsum \\
dolar* cat
```

Test document TeX-style LaTeX fragments:
```
$foo
bar
baz
lorem
ipsum
dolar$
```

--
Tom Alexander

Re: Unclear where ob-spice.el is being maintained

[Christopher M. Miles]

Jonas Bernoulli  writes:

> Ihor Radchenko  writes:
>
>> Jonas Bernoulli  writes:
>>
>>> In 2022 I changed Melpa to get ob-spice.el from
>>> https://repo.or.cz/ob-spice.git in response to
>>> https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.
>>
>> The last discussion was back in 2020 
>> https://list.orgmode.org/orgmode/cal1eyul8zzg-fdeedovbvm1cfc8w6ajwfr7cthvgs8owdwj...@mail.gmail.com/
>
> Bastien replied to that mentioning only one of the listed packages,
> which left me wondering "what about the others?".
>
>> However, your reference is 2022.
>> So, unless Christopher has something to say,
>> https://repo.or.cz/ob-spice.git is the last known active maintenance
>> location. The last commit is 2022
>> https://repo.or.cz/ob-spice.git/shortlog, and includes more changes
>> compared to ob-spice version in org-contrib.
>
> I came to the same conclusion but because ob-spice had not been removed
> from org-contrib, I wasn't sure.  Ihor, could you please remove it from
> org-contrib now?

I have already forget whether I taken the ob-spice maintaining task like
other libraries. So I'm not sure about it. I'm not work on this library
currently. From git log history, I'm the last maintainer. If you want to
maintain it or avoid duplicate, you can ask Bastien to remove it.

> Stardiviner, the readme in your repository still claims that the package
> is being maintained in two other locations.  Please remove that outdated
> information.
>

I have not found claimed two other locations in my README. Maybe I
missed out. Can you point out?

-- 

[ 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: [BUG] ob-python hangs on second start [9.5.4 (release_9.5.4-763-g06373a @ ~/emacs/org-mode/lisp/)]

[Peter Mao]

On Sun, Aug 27, 2023 at 2:26 PM Jack Kamm  wrote:

> Ihor Radchenko  writes:
>
> > Confirmed.
> >
> > It looks like `python-shell-first-prompt-hook' does not get triggered
> > in the described scenario with exit() and we enter infinite loop in the
> > code below.
>
> I think `python-shell-first-prompt-hook' is actually still triggered,
> but rather it is `org-babel-comint-wait-for-output' that is hanging
> while waiting for startup. However, we can just replace it with a
> `sleep-for' instead, because we now wait for
> `org-babel-python--initialized' anyways.
>
> See the attached patch. Please let me know if it fixes the problem for
> you.
>

Yes, this fixes the problem for me.  I made the change locally to
release_9.6.6 on emacs 29.1.  I have the expected behavior back. thank you!

Peter

[PATCH] Fix a possibly problematic string comparison

[Rudolf Adamkovič]

* lisp/org-table.el (org-table-make-reference): Replace 'eq' with
'string-empty-p' to resolve "Warning: 'eq' called with literal string
that may never match" issued on every 'make' invocation.
---
 lisp/org-table.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index f5a433c7d..b82749469 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -2864,7 +2864,7 @@ list, `literal' is for the format specifier L."
   (if lispp
  (if (eq lispp 'literal)
  elements
-   (if (and (eq elements "") (not keep-empty))
+   (if (and (string-empty-p elements) (not keep-empty))
""
  (prin1-to-string
   (if numbers (string-to-number elements) elements
-- 
2.41.0

Re: [BUG] ob-python hangs on second start [9.5.4 (release_9.5.4-763-g06373a @ ~/emacs/org-mode/lisp/)]

[Jack Kamm]

Ihor Radchenko  writes:

> Peter Mao  writes:
>
>> Expectation:  When running ob-python code blocks, I should be able to
>> kill the python session in the *Python* buffer and run another code
>> block (or the same one).
>>
>> Problem:  ob-python works fine on the first execution, but after
>> `exit()`ing the python session, it hangs without executing the code.
>> After a `C-g`, the prompt in the *Python* session shows up, but one then
>> has to re-execute the code block, as none of it has run.
>
> Confirmed.
>
> It looks like `python-shell-first-prompt-hook' does not get triggered
> in the described scenario with exit() and we enter infinite loop in the
> code below.

I think `python-shell-first-prompt-hook' is actually still triggered,
but rather it is `org-babel-comint-wait-for-output' that is hanging
while waiting for startup. However, we can just replace it with a
`sleep-for' instead, because we now wait for
`org-babel-python--initialized' anyways.

See the attached patch. Please let me know if it fixes the problem for
you.

>From d5721aa37a399afcd527906e5d9f1b6bce37fdb9 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Sun, 27 Aug 2023 14:13:15 -0700
Subject: [PATCH] ob-python: Fix hanging on second start

See: https://list.orgmode.org/87ttsnh5bx.fsf@localhost/T/#t

* lisp/ob-python.el (org-babel-python-initiate-session-by-key): Switch
from `org-babel-comint-wait-for-output' to `sleep-for' while waiting
for `org-babel-python--initialized', to prevent hanging on restarted
Python process.
* testing/lisp/test-ob-python.el (test-ob-python/session-restart): New
test for restarting ob-python session process.
---
 lisp/ob-python.el  |  2 +-
 testing/lisp/test-ob-python.el | 19 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index b9dab91b4..6b216ce89 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -272,7 +272,7 @@ (defun org-babel-python-initiate-session-by-key ( session)
   ;; multiple prompts during initialization.
   (with-current-buffer py-buffer
 (while (not org-babel-python--initialized)
-  (org-babel-comint-wait-for-output py-buffer)))
+  (sleep-for 0 10)))
   (setq org-babel-python-buffers
 	(cons (cons session py-buffer)
 		  (assq-delete-all session org-babel-python-buffers)))
diff --git a/testing/lisp/test-ob-python.el b/testing/lisp/test-ob-python.el
index 82fbca36e..c11e1d0c2 100644
--- a/testing/lisp/test-ob-python.el
+++ b/testing/lisp/test-ob-python.el
@@ -310,6 +310,25 @@ (ert-deftest test-ob-python/async-local-python-shell ()
 #+end_src"
 (should (org-babel-execute-src-block
 
+(ert-deftest test-ob-python/session-restart ()
+  ;; Disable the test on older Emacs as built-in python.el sometimes
+  ;; fail to initialize session.
+  (skip-unless (version<= "28" emacs-version))
+  (should
+   (equal "success"
+  (progn
+(org-test-with-temp-text "#+begin_src python :session :results output
+print('start')
+#+end_src"
+	 (org-babel-execute-src-block))
+(let ((proc (python-shell-get-process)))
+  (python-shell-send-string "exit()")
+  (while (accept-process-output proc)))
+(org-test-with-temp-text "#+begin_src python :session :results output
+print('success')
+#+end_src"
+	 (org-babel-execute-src-block))
+
 (provide 'test-ob-python)
 
 ;;; test-ob-python.el ends here
-- 
2.41.0

Warning(diary.org_archive): Got element without parent (cache active?: t)

[Gregor Zattler]

Hi org-mode developers, Ihor,

I got these warnings when I followed an id: link
(org-open-at-point) within diary.org

I have no idea why diary.org_archive was opened at that
time.  The following is the complete contents of the
*Warnings* buffer at the moment:

 ■  Warning (org-element-cache): org-element--cache: 
Warning(diary.org_archive): Got element without parent (cache active?: t). 
Please report it to Org mode mailing list (M-x org-submit-bug-report).
(headline (:standard-properties [3412566 3412987 3412644 3412987 0 3412566 
(:title) t nil 3412716 3412985 nil element 3 # nil 
nil nil] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value (9 72) nil] :title [org-element-deferred 
org-element-property-2 (:raw-value) nil] :level 2 :priority nil :tags ("@no") 
:todo-keyword "DONE" :todo-type done :footnote-section-p [org-element-deferred 
org-element--headline-footnote-section-p nil nil] :archivedp 
[org-element-deferred org-element--headline-archivedp nil nil] :commentedp nil 
:ID [org-element-deferred org-element--substring (104 140) nil]))
Backtrace:
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [128 128 nil nil 155 1 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"showeverything\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [108 108 nil nil 128 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"overview\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [93 93 nil nil 108 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"odd\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [72 72 nil nil 93 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"showstars\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [64 64 nil nil 72 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"TAGS\" :value 
\"\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(paragraph (:standard-properties [1 1 1 64 64 0 nil top-comment element 
nil nil nil nil nil # nil nil nil]))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(section (:standard-properties [1 1 1 155 155 0 nil first-section element 
nil nil 1 155 nil # nil nil nil]))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(org-data (:standard-properties [1 1 1 3583853 3583853 0 nil org-data nil 
nil nil 3 3583853 nil # [org-element-deferred 
org-element--get-global-node-properties nil t] nil nil] :path 
\"/home/grfz/org/diary.org_archive\"))"
  org-element-cache diagnostics(diary.org_archive): Nothing in cache. Adding 
org-data: "(org-data (:standard-properties [1 1 1 3583853 3583853 0 nil 
org-data nil nil nil 3 3583853 nil # 
[org-element-deferred org-element--get-global-node-properties nil t] nil nil] 
:path \"/home/grfz/org/diary.org_archive\"))"
 ■  Warning (org-element-cache): org-element--cache: (org-open-at-point) Cached 
element is incorrect in diary.org_archive. (Cache tic up to date: "yes") 
Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:standard-properties [3412566 3412987 3412644 
3412987 0 3412566 (:title) t nil 3412716 3412985 nil element 3 # nil nil nil] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value (9 72) nil] :title [org-element-deferred 
org-element-property-2 (:raw-value) nil] :level 2 :priority nil :tags (\"@no\") 
:todo-keyword \"DONE\" :todo-type done :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil :ID [org-element-deferred org-element--substring (104 140) 
nil]))"
 The real element is: "(headline (:standard-properties [3412566 3412566 3412644 
3412987 3412987 0 (:title) nil nil nil nil 3412646 3412987 3 # [org-element-deferred org-element--headline-deferred nil t] 
nil [org-element-deferred org-element--headline-parent-deferred nil t]] 
:pre-blank 0 :raw-value [org-element-deferred org-element--headline-parse-title 
(t) nil] :title [org-element-deferred org-element--headline-parse-title (t) 
nil] :level [org-element-deferred org-element--headline-parse-title (t) nil] 
:priority [org-element-deferred org-element--headline-parse-title (t) nil] 
:tags [org-element-deferred org-element--headline-parse-title (t) nil] 
:todo-keyword [org-element-deferred org-element--headline-parse-title (t) nil] 
:todo-type [org-element-deferred 

Re: What do you recommend for acronyms in org-mode?

[briangpowell]

Wow, that's a great video Dr. Kitchen; I'll have to find time to take a
deeper dive into your OrgRef software

This question from Mr. Maske is interesting, "...The session load gets too
high, the editor becomes too slow,...etc."

* Suggest making smaller .org files

* Suggest also trying to mix in Abbrev-Mode as a Minor-Mode somehow in the
mode-less Emacs editor--using Abbrev-Mode may speed things up in many
ways--see this for more: https://www.emacswiki.org/emacs/AbbrevMode

** Maybe even extend Dr. Kitchen's Org-Ref software somehow to include
Abbrev-Mode calls--see the software at: https://github.com/jkitchin/org-ref

*** Then your own ~/.abbrev_defs.can be set to your own tastes & evolve
with you...that might speed things up for you

On Sat, Aug 26, 2023 at 9:02 PM Maske  wrote:

> Hi John!
>
> I was using org-ref some time ago, but it seemed to get emacs slower, in
> my low resources PC.
>
> Would you give me some tips to make org-ref lighter?
>
> Best regards
>
> 27 ago 2023 2:33:05 John Kitchin :
>
> You can see how these work in org-ref in this video:
> https://www.youtube.com/watch?v=sebs2vSIEk4=PL0sMmOaE_gs3E0OjExoI7vlCAVygj6S4I=13.
>
>
> On Sat, Aug 26, 2023 at 1:21 PM Maske  wrote:
>
>> I would like to know what do you use for acronyms, glossaries, etc for
>> using inside org-mode? Not for exportation, just to use them inside Emacs.
>>
>> Maybe radio links, or the package org-glossary? org-ref?
>>
>> Best regards
>>
>
>
> --
> John
>
> ---
> Professor John Kitchin (he/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> https://kitchingroup.cheme.cmu.edu
> https://pointbreezepubs.gumroad.com/ pycse bookstore
>
>

Re: [BUG] FAILED test-ob-python/session-multiline

[Jack Kamm]

Ihor Radchenko  writes:

> Jack Kamm  writes:
>
>>>FAILED   376/1256  test-ob-python/session-multiline (0.011955 sec) at 
>>> ../lisp/test-ob-python.el:105
>>
>> Hmmm. Do you have an idea of how long this has been happening, and how
>> frequently it breaks?
>
> For months.
>
>> My first suspicion is the large ob-python commit I pushed on Tuesday:
>>
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=579e8c572345c42ad581d3ddf0f484567d55a787
>
> So, should not be the recent commit.

This one might take some time to fix, since it's hard to reproduce and
I'm not sure the cause of it. But here are 3 different solutions I am
considering now:

1. In addition to printing `org-babel-python-eoe-indicator' after
   execution, we could also print out a "beginning of execution"
   indicator before execution, and then capture the output between the
   beginning and end indicators. This is how the async session
   execution works, and should avoid any possibility of capturing
   prompts.

2. Instead of relying on our own custom `org-babel-python-send-string',
   we could try switching to python.el's
   `python-shell-send-string-no-output', which is probably more
   robust. This would also allow removing the ugly
   `org-babel-python-eoe-indicator' we currently print.

   Downside is that the output would not be echoed into the session
   anymore. To fix that, we could manually insert the captured output
   into the comint session buffer after execution.  Alternatively, we
   could add an argument to `python-shell-send-string-no-output' to
   avoid suppressing output, submit it upstream to python.el, and then
   backport to Org to support older emacs versions.

3. Revisit a series of commits I made in 2020, which was supposed to
   make session evaluation more robust, and was inspired by
   `python-shell-send-string-no-output':
   https://git.sr.ht/~bzg/org-mode/commit/4df12ea39

   However, I had to partially revert that work, due to compatibility
   issue with emacs 26.3:
   https://list.orgmode.org/871rjcan53@kyleam.com/

   I think we no longer support emacs 26.3, so I could potentially
   revisit this now -- but it's been a few years and will take some
   time to refresh my memory about this.

Of these options, Option 1 is the easiest, and the most certain to solve
this bug. Options 2 and 3 are more difficult and riskier, but would have
other benefits if they work: we can remove the ugly
`org-babel-python-eoe-indicator' that is currently printed to the
session, and/or reduce long-term maintenance burden by relying on
python.el's implementation for capturing output.

Re: [BUG] Warning when creating preview

[Ihor Radchenko]

Edgar Lux  writes:

> On Aug 27, 2023 at 1:28 PM, Ihor Radchenko  wrote:
>
 9. M-& make repro REPRO_ARGS="-l /tmp/bug.el /tmp/bug.org"
>
>> Please run this command from terminal.
>> It should spawn a clean Emacs instance with Org version from the repository.
>
> No warning after   C-c C-x C-l(2x)

So, it looks like something with your config.
I recommend https://github.com/Malabarba/elisp-bug-hunter to narrow down
which part of the config is the culprit.

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

Re: [BUG] Warning when creating preview

[Edgar Lux]

On Aug 27, 2023 at 1:28 PM, Ihor Radchenko  wrote:

>>> 9. M-& make repro REPRO_ARGS="-l /tmp/bug.el /tmp/bug.org"

> Please run this command from terminal.
> It should spawn a clean Emacs instance with Org version from the repository.

No warning after   C-c C-x C-l(2x)

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

-- 
Sent with https://mailfence.com  
Secure and private email

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Although, the name "inlinetask" is actually awkward in such use case.
> Something like inlinesection would fit better. Or inlineheading.

Completely agree. I like inlinesection and inlineheading equally.

> And what about drawers? Don't they fit the idea of "detached" element?

But drawers would not serve as a "detached section"... Although they are
certainly very versatile. I usually use drawers to export as small
"containers". And when I don't export them, they are very useful for
temporarily saving all kinds of "things". In Spanish we have the term
"cajón de sastre" (lit.: "a tailor drawer") to refer to something where
you can store everything :-)

As for the inlinetask (or whatever they may be called in the future),
the fact that they are a kind of hybrid between a section (unrelated to
the level hierarchy) and a drawer seems very interesting to me. Apart
from the scenario of the anonymous sections that I mentioned before, I
can think of a few more. For example, something like this:

*** WORKING Complete this :noexport:
DEADLINE: <2023-08-27 dom>
Content 
*** END

And the combination of org-store-link with org-transclusion can also be
interesting.

Or, for example this other example, which is not possible now, but with
some modification in org-mime-org-subtree-htmlize I think it is:

*** TODO Email this 
DEADLINE: <2023-08-27 dom>
:PROPERTIES:
:mail_to:  mail address
:mail_subject: mail subject
:END:
Content
*** END

Well, it's some scattered ideas. In general I think that 
"inlinesection/-heading"
is an element that could be very productive in certain cases, since it
allows to "locally" suspend the (necessary) rigidity of the tree hierarchy.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: ob-lilypond fontification

[Henrik Frisk]

Den sön 27 aug. 2023 kl 09:49 skrev Ihor Radchenko :

> Henrik Frisk  writes:
>
> >> Hmm. Did you customize `org-src-fontify-natively'?
> >>
> >
> > This is what I have:
> >
> > (setq org-confirm-babel-evaluate nil
> >   org-src-fontify-natively t
> >   org-src-tab-acts-natively t)
>
> Then, might be https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63579
> If it is, putting (defvar font-lock-reference-face nil) into your config
> should help; and, ideally, also reporting the bug to lilypond devs.
>

Yes, that did it, thanks!
/Henrik

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

On Saturday, 26 Aug 2023 at 12:30, Ihor Radchenko wrote:
> That will indeed work. But then the todo will not appear in agenda.

Indeed.  Luckily, for me, I don't tend to want the actions within my
long documents to be listed in my agenda. Essentially, I have global
todo items (which appear in my agenda) and document (aka project)
specific ones which I only care about when working on that document
(project).  But...

> I think that a combination of drawers/special blocks + ability to
> assign todos/tags to paragraphs/tables/drawers/etc may give people
> what they usually need when using inlinetasks.

Yes, this capability would give the flexibility people want or need.

-- 
: Eric S Fraga, with org release_9.6.6-412-g2f7b35 in Emacs 30.0.50

Re: [BUG] Warning when creating preview

[Ihor Radchenko]

Edgar Lux  writes:

> On Aug 26, 2023 at 6:28 PM, Ihor Radchenko  wrote:
>
>> Did you see a new Emacs instance at this point?
>
> Nope. I just launched Emacs again (there is another instance running) and 
> copied the command
>
>>> 9. M-& make repro REPRO_ARGS="-l /tmp/bug.el /tmp/bug.org"

Please run this command from terminal.
It should spawn a clean Emacs instance with Org version from the repository.

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

[FR] Aligning paragraphs in lists

[Maske]

Could be used M-right or M-left to align paragraphs which are 
immediately below a list?


In a list, if pressing Enter, the next paragraph is aligned below the 
item of the list:

+ Item 1
  Text indented, belongs to Item 1.

If there are subitems, the text could be needed to be aligned below a 
superior item, and this must be done in a manual way:

+ Item 1
  Text indented, belongs to Item 1.
   - Item 2
 Text indented, belongs to Item 2.
  This paragraph is aligned below Item 1, but I think there is too much 
"friction" to achieve this. And the alignment would be different if the 
bullet was "1)"



Best regards

Re: [BUG] Warning when creating preview

[Edgar Lux]

On Aug 26, 2023 at 6:28 PM, Ihor Radchenko  wrote:

> Did you see a new Emacs instance at this point?

Nope. I just launched Emacs again (there is another instance running) and 
copied the command

>> 9. M-& make repro REPRO_ARGS="-l /tmp/bug.el /tmp/bug.org"

Shell buffer shows
#+begin_example
  make -C doc cleanall;  make -C etc cleanall;  make -C lisp cleanall;
  make[1]: Entering directory '/path/to/org/repo/doc'
  rm -f *.pdf *.html *.info *_letter.tex org-version.inc org-version.tex \
*.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs *.toc \
*.tp *.tps *.vr *.vrs *.log *.ps
  rm -f org.texi orgguide.texi
  rm -fr guide manual
  make[1]: Leaving directory '/path/to/org/repo/doc'
  make[1]: Entering directory '/path/to/org/repo/etc'
  make[1]: Nothing to be done for 'cleanall'.
  make[1]: Leaving directory '/path/to/org/repo/etc'
  make[1]: Entering directory '/path/to/org/repo/lisp'
  rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc
  rm -f *.elc
  make[1]: Leaving directory '/path/to/org/repo/lisp'
  rm -fr /tmp/tmp-orgtest || { \
find /tmp/tmp-orgtest -type d -exec chmod u+w {} + && \
rm -fr /tmp/tmp-orgtest ; \
  }
  find . \( -name \*~ -o -name \*# -o -name .#\* \) -exec rm -f {} +
  find testing mk \( -name \*~ -o -name \*.elc \) -exec rm -f {} +
  make -C lisp autoloads
  make[1]: Entering directory '/path/to/org/repo/lisp'
  rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc
  org-version: 9.7-pre (release_9.6.7-698-g3cbd9f)
  Loading /path/to/org/repo/lisp/org-compat.el (source)...
  Loading /path/to/org/repo/mk/org-fixup.el (source)...
  org-loaddefs: 9.7-pre (release_9.6.7-698-g3cbd9f)
  Loading /path/to/org/repo/lisp/org-compat.el (source)...
  Loading /path/to/org/repo/mk/org-fixup.el (source)...
  make[1]: Leaving directory '/path/to/org/repo/lisp'
#+end_example

-- 
Sent with https://mailfence.com  
Secure and private email

Re: Unclear where ob-spice.el is being maintained

[Jonas Bernoulli]

Ihor Radchenko  writes:

> Jonas Bernoulli  writes:
>
>> In 2022 I changed Melpa to get ob-spice.el from
>> https://repo.or.cz/ob-spice.git in response to
>> https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.
>
> The last discussion was back in 2020 
> https://list.orgmode.org/orgmode/cal1eyul8zzg-fdeedovbvm1cfc8w6ajwfr7cthvgs8owdwj...@mail.gmail.com/

Bastien replied to that mentioning only one of the listed packages,
which left me wondering "what about the others?".

> However, your reference is 2022.
> So, unless Christopher has something to say,
> https://repo.or.cz/ob-spice.git is the last known active maintenance
> location. The last commit is 2022
> https://repo.or.cz/ob-spice.git/shortlog, and includes more changes
> compared to ob-spice version in org-contrib.

I came to the same conclusion but because ob-spice had not been removed
from org-contrib, I wasn't sure.  Ihor, could you please remove it from
org-contrib now?

Stardiviner, the readme in your repository still claims that the package
is being maintained in two other locations.  Please remove that outdated
information.

 Cheers,
 Jonas

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> In other words, it is not the section itself, but other
>> headline/inlinetask features, like todo keywords, tags, planning. Right?
>
> No, it is the section itself (or the concept of "section", with its toys
> in Org, of course) that is important to me in this case...

So, this is a vote in favour of having a separate syntax element.
Although, the name "inlinetask" is actually awkward in such use case.
Something like inlinesection would fit better. Or inlineheading.

And what about drawers? Don't they fit the idea of "detached" element?

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

Re: [BUG] org-up-heading-safe behaves different in v9.7 [9.7 (9.7-??-d6f3aed @ /home/zhaoyiyu/.config/emacs/.local/straight/build-28.1/org/)]

[Ihor Radchenko]

zhaoyiyu  writes:

> When I track down a issue about org-journal, with org v9.7
> I noticed that when execute
> (org-up-heading-safe)
> it's different with org v9.6, which would caused the org-journal issue.
> In detail as follows org file. After execution the cursor position will
> change to
>
>
> File Header                 <-- v9.7, return nil and cursor here
> * heading lv 1 <-- v9.6, return nil and cursor here
> some contents and your prev cursor is here I
>
>...
> Package: Org mode version 9.7 (9.7-??-d6f3aed @ 
> /home/zhaoyiyu/.config/emacs/.local/straight/build-28.1/org/)

Duplicate of 
https://orgmode.org/list/CAG=u__pAT9k_AsRG6cpyPPUt0__5S7o=3a8wwkaijuppugc...@mail.gmail.com
Already fixed.
Handled.

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

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Evgenii Klimov]

Hi Ihor

On August 23, 2023 12:44:32 PM GMT+01:00, Ihor Radchenko  
wrote:
>Ihor Radchenko  writes:
>
>> What about generalizing the idea and providing a way to set Emacs
>> buffer-local variables in the tangled files?
>>
>> Can be something like:
>>
>> #+begin_src elisp :file-locals (lexical-binding t eval (line-number-mode))
>
>Over one month have passed since the last message in this thread.
>
>Evgenii, are you still interested to continue working on this?
>

I am busy for the next month and even after that generalizing the idea would 
take too much effort and time, since I'm not an advanced programmer. So 
probably the answer is no.

Re: ob-lilypond fontification

[Ihor Radchenko]

Henrik Frisk  writes:

>> Hmm. Did you customize `org-src-fontify-natively'?
>>
>
> This is what I have:
>
> (setq org-confirm-babel-evaluate nil
>   org-src-fontify-natively t
>   org-src-tab-acts-natively t)

Then, might be https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63579
If it is, putting (defvar font-lock-reference-face nil) into your config
should help; and, ideally, also reporting the bug to lilypond devs.

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

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Ihor Radchenko]

Samuel Loury  writes:

> IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that
> & and | are forbidden to say anything else than AND and OR and people
> would be ok with that.

Actually, explicit & or | might be an easier way to not worry about
escaping things. Except escaping & or | themselves.
It might be the preferred way to put into the manual.

> IOW, I wonder of the time and effort to deal with optional & is worth
> it. WDYT?

We cannot remove the optionality of &, because doing so will break
existing user setups. But we can certainly change our recommendations in
the manual.

Though pure tag matcher makes more sense with implicit &:
 +tag1-tag2+tag3... vs +tag1&-tag2&+tag3
Especially in the interactive agenda filters.

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

Re: ob-lilypond fontification

[Henrik Frisk]

Den lör 26 aug. 2023 kl 18:23 skrev Ihor Radchenko :

> Henrik Frisk  writes:
>
> >> Is lilypond library is loaded when you open Org file?
> >> What happens if you run C-c ' on an src-block?
> >>
> >
> > That works fine, code is syntax highlighted.
>
> Hmm. Did you customize `org-src-fontify-natively'?
>

This is what I have:

(setq org-confirm-babel-evaluate nil
  org-src-fontify-natively t
  org-src-tab-acts-natively t)

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Samuel Loury]

I have a dumb question.

IIUC, it needs a lot of effort to deal with implicit & correctly. I
initially used it because de manual said it was ok, but I would have
used explicit & if the manual had said so.

I wonder if we could just stop saying that & is optional and have a
simpler parsing. 

IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that
& and | are forbidden to say anything else than AND and OR and people
would be ok with that.

IOW, I wonder of the time and effort to deal with optional & is worth
it. WDYT?

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature