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

[Peter Mao]

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.

The following three code blocks demonstrate the problem.  I have
bisected the problem, finding 06373a64 as the first bad commit.  I tried
to reproduce the problem on Emacs 28.2, but this commit of Org won't
compile on Emacs 28.2 for me.

#+begin_src elisp :results none
  (org-babel-do-load-languages 'org-babel-load-languages '((python . t)))
  (setq-local org-confirm-babel-evaluate nil)
#+end_src

#+begin_src python :results output
  print("Running first, this one issues a warning but competes
successfully.")
  exit()
#+end_src

#+begin_src python :results output
  print("Running second, this one hangs until user enters C-g.")
  print("None of the code executes.")
  exit()
#+end_src



Emacs  : GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
 of 2023-07-31
Package: Org mode version 9.5.4 (release_9.5.4-763-g06373a @
/home/peterm/emacs/org-mode/lisp/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
   org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
 org-cycle-optimize-window-after-visibility-change)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
  [add-hook change-major-mode-hook org-fold-show-all append
   local]
  5]
#[0 "\300\301\302\303\304$\207"
  [add-hook change-major-mode-hook org-babel-show-result-all
   append local]
  5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-babel-load-languages '((python . t))
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el")
 ("elisp" . "el"))
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
 org-babel-speed-command-activate)
 org-fold-core-isearch-open-function 'org-fold--isearch-reveal
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
 org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
  ("id" :follow org-id-open)
  ("eww" :follow org-eww-open :store org-eww-store-link)
  ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
  ("mhe" :follow org-mhe-open :store org-mhe-store-link)
  ("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
  ("info" :follow org-info-open :export org-info-export
:store org-info-store-link :insert-description
org-info-description-as-command)
  ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
  ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
  ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
  ("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
  ("w3m" :store org-w3m-store-link)
  ("doi" :follow org-link-doi-open :export
org-link-doi-export)
  ("file+sys") ("file+emacs")
  ("shell" :follow org-link--open-shell)
  ("news" :follow
#[514 "\301\300\302 Q \"\207"
 ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("mailto" :follow
#[514 "\301\300\302 Q \"\207"
 ["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("https" :follow
#[514 "\301\300\302 Q \"\207"
 ["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("http" :follow
#[514 "\301\300\302 Q \"\207"
 ["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
  ("ftp" :follow
#[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"]
 6 "\n\n(fn URL ARG)"]
)
  ("help" :follow org-link--open-help :store
org-link--store-help)
  ("file" :complete 

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

[spookygostee]

Bastien Guerry  writes:
> …
> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
> a heading would fit 90% of what is expected from inline tasks in the
> example you gave.
> …
There is functionality for a `:noexport:'  tag already built in. Do you intend 
`:noheadingexport:'  to apply only to the top level of the tree it is applied 
to? If so, that would probably not play nicely with tag inheritance.

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

[spookygostee]

Russell Adams  writes:

> On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote:
>> Russell Adams  writes:
>>
>> >> What do you mean?
>> >
>> > I think Markdown has different levels?
>>
>> Do you mean # title vs. ## title?
>
> 
>
> look at the alternate syntax where they under line with different symbols.
>
>> > Has there ever been a reason to diversify the heading syntax to allow
>> > levels or changes in visibility?
>> >
>> > ** TODO
>> >
>> > `=' TODO Inline item under todo
>> >
>> > — DONE something else?
>> >
>> > ### TODO invis to all except interactive editing
>>
>> That’s even more features. I feel confused about what you are trying to
>> convey.
>
> It is, but it’s just brainstorming along the lines of needing an
> inline task syntax.
>
> We have a solid heading syntax, with one or more asterisks followed by
> keywords and heading metadata. Given we’re talking about adding more
> flags in the metadata, I’m just asking if we should consider
> alternatives to just asterisks to help indicate differences.
>
> An inline task exempt from folding should be eye catching to
> differentiate it from other headings. Perhaps something other than
> asterisks is appropriate?
>
> ——
> Russell Adamsrlad...@adamsinfoserv.com
> 

As someone who only uses orgmode, I personally find the logical distinction 
between inline and normal headings not compelling enough to justify adding new 
syntax besides asterisks. Frequently I hear orgmode’s extremely simple syntax 
lauded in comparison to something like markdown. Just some thoughts.

–shortcut

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

[Samuel Wales]

another idea, at the cost of 3 dumb messages in a row  there are
annotation packages.  i wonder if integration of those is relevant.

On 8/24/23, Samuel Wales  wrote:
> [p.s.  not saying this will satisfy ardent users, just bringing up the
> idea in case it is of use.]
>
>
> On 8/24/23, Samuel Wales  wrote:
>> iiuc bastien brought up the use of a no export this heading tag as an
>> alternative to inline tasks.  we have much or all of this capability
>> in faq.
>>
>> i was thinking the same thing.  perhaps many use cases could have
>> inline tasks as siblings below the document heading, and undesired
>> headers could be just not exported.
>>
>> i was also wondering if links and/or some type of transclusion could
>> also obviate inline tasks.  the formerly-inline task would contain a
>> link to a target above the paragraph.  c-c c-c on that location would
>> take you back to the task.
>>
>>
>> On 8/24/23, Max Nikulin  wrote:
>>> On 24/08/2023 19:21, Ihor Radchenko wrote:
 As I described, I often want inlinetasks to be exported and to be
 displayed in my agenda/sparse tree views
>>>
>>> It sounds like that if agenda had hooks allowing to gather either
>>> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
>>> custom blocks then ** END would not be necessary.
>>>
>>>
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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

[Samuel Wales]

[p.s.  not saying this will satisfy ardent users, just bringing up the
idea in case it is of use.]


On 8/24/23, Samuel Wales  wrote:
> iiuc bastien brought up the use of a no export this heading tag as an
> alternative to inline tasks.  we have much or all of this capability
> in faq.
>
> i was thinking the same thing.  perhaps many use cases could have
> inline tasks as siblings below the document heading, and undesired
> headers could be just not exported.
>
> i was also wondering if links and/or some type of transclusion could
> also obviate inline tasks.  the formerly-inline task would contain a
> link to a target above the paragraph.  c-c c-c on that location would
> take you back to the task.
>
>
> On 8/24/23, Max Nikulin  wrote:
>> On 24/08/2023 19:21, Ihor Radchenko wrote:
>>> As I described, I often want inlinetasks to be exported and to be
>>> displayed in my agenda/sparse tree views
>>
>> It sounds like that if agenda had hooks allowing to gather either
>> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
>> custom blocks then ** END would not be necessary.
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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

[Samuel Wales]

iiuc bastien brought up the use of a no export this heading tag as an
alternative to inline tasks.  we have much or all of this capability
in faq.

i was thinking the same thing.  perhaps many use cases could have
inline tasks as siblings below the document heading, and undesired
headers could be just not exported.

i was also wondering if links and/or some type of transclusion could
also obviate inline tasks.  the formerly-inline task would contain a
link to a target above the paragraph.  c-c c-c on that location would
take you back to the task.


On 8/24/23, Max Nikulin  wrote:
> On 24/08/2023 19:21, Ihor Radchenko wrote:
>> As I described, I often want inlinetasks to be exported and to be
>> displayed in my agenda/sparse tree views
>
> It sounds like that if agenda had hooks allowing to gather either
> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
> custom blocks then ** END would not be necessary.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Unclear where ob-spice.el is being maintained

[Jonas Bernoulli]

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

Re: Clarification on blank lines following list items

[Tom Alexander]

Thanks!

-- 
Tom Alexander

On Tue, Aug 22, 2023, at 4:26 AM, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
>
>>> I am seeing dual-ownership of the post-blank in the examples below, but at 
>>> the same time if I put a plain-list inside a footnote definition, the 
>>> footnote definition ends up with sole custody of the post-blank.
>>
>> It is a bug in the list parser.
>
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=53c9d91d3
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [MAINTENANCE] Org orphanage?

[Bastien Guerry]

Jonas Bernoulli  writes:

> Please make your "membership" public at
> https://github.com/orgs/emacsorphanage/people.

Done, thanks!

-- 
 Bastien Guerry

Re: [MAINTENANCE] Org orphanage?

[Jonas Bernoulli]

Thanks for offering to help out Corwin!

>> Speaking for myself, I can help:
>> [...]
>> - review the bonafides (experience/involvement and, via Eli/SM,
>> assignment status ) for prospective adopting maintainers
>
> Not sure about emacsorphanage side, but for things we decide to manage
> on sr.ht, we can all discuss new maintainers on this mailing list. The
> maintenance requests should also go here.

The orphanage is often first brought up in the package's issue tracker,
or on Melpa's issue tracker.  Sometimes I bring it up, sometimes a user
of a package makes us aware of a stale package.

In general that makes sense, but for Org-related packages this mailing
list makes more sense (not least because it is read by people interested
in Org, i.e., potential future maintainers).

>> - assign permissions
>> - move repos
>> - apply well tested patches to orphaned packages
>
> I think you can participate in issue discussion for the existing
> orphaned packages first. (The problem is that you do not have a record
> contributing to Emacs/Org mode. I can only see two trivial commits
> 64d211179db and a70a3449417 in Emacs)

I only want to give far reaching permissions to people who have
maintained larger Emacs-related projects for a long time.

It's great that you are volunteering to do some work, but I am not
looking for more people to manage the whole project, just individual
packages.

If you are interested in that kind of work looked through the list of
orphaned packages for something that interests you and then offer to
maintain that.

>> - apply well tested patches to orphaned packages

If you see any pull-requests that you consider suitable for merge but
haven't gotten any response from any of the maintainers of the orphanage
or the volunteer who maintains the respective package, then feel free to
ping @emacsorphanage/core.

>> Irrespective of whether worg curators should help with this (or some
>> other vols, or just the org maintainers, or...), I think it would make
>> sense to document these "responsibilities" (and the detail of the
>> plans made in this thread, in general), along with the whos and hows.
>
> +1

I'll try collecting existing resources and maybe write some new ones,
but I have a lot on my plate, so this will likely take a while.

Re: org-cite: how to force a reparsing of the .bib file

[Leo Butler]

On Thu, Aug 24 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> Does the attached patch fix the problem?
>>
>> ...
>> To avoid an unneeded setq, I applied the patch:
>>
>>   (dolist (file (mapcar #'file-truename 
>> (org-cite-list-bibliography-files)))
>
> This would create an extra list and increase GC pressure. So, I prefer setq.
>
>> This caused the bibtex file to be re-parsed when I changed it.
>
> Thanks for testing!
> Applied.
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3c3db7b33

Thanks, Ihor.
Leo

Re: [MAINTENANCE] Org orphanage?

[Jonas Bernoulli]

Bastien Guerry  writes:

> Sounds good to me too, I'm "bzg" on GitHub.  Thanks!

Invitation sent.

Please make your "membership" public at
https://github.com/orgs/emacsorphanage/people.

Welcome!
:D

[BUG] When calling org-tree-to-indirect-buffer: (wrong-type-argument listp org-fold-outline) in org-fold-core-get-folding-spec-from-alias [9.6.6 (release_9.6.6 @ /gnu/store/c7vqk20kf6zw73klr8bacnh0gqa

[Adam Porter]

Hi,

Since upgrading to Emacs 29.1 and Org 9.6.6, I am getting an error when
opening a bookmark to an Org subtree buffer created with burly.el.  When
opening the bookmark, burly calls org-tree-to-indirect-buffer to make a
new indirect buffer showing the subtree in question.  This worked fine
in Emacs 28 and the previous Org version I was using, 9.5.something,
IIRC.  Now I get this error (please see the attached backtrace, which is 
abbreviated, and some functions were re-evaluated so as to be interpreted).


FWIW, I also tried setting org-fold-core-style to overlays and
restarting Emacs, but the error still happens, although with a different
symbol in place of org-fold-outline.

Thanks for your work on Org.

AdamDebugger entered--Lisp error: (wrong-type-argument listp org-fold-outline)
  car(org-fold-outline)
  alist-get(org-fold-outline ((:alias . org-link) (org-link . org-link) (:alias 
. org-link-description) (org-link-description . org-link-description) 
(property-drawer . org-fold-drawer) (drawer . org-fold-drawer) (:alias . 
org-fold-drawer) (org-fold-drawer . org-fold-drawer) (verse-block . 
org-fold-block) (src-block . org-fold-block) (special-block . org-fold-block) 
(quote-block . org-fold-block) (export-block . org-fold-block) (example-block . 
org-fold-block) (dynamic-block . org-fold-block) (comment-block . 
org-fold-block) (center-block . org-fold-block) (block . org-fold-block) 
(:alias . org-fold-block) (org-fold-block . org-fold-block) (plain-list . 
org-fold-outline) (inlinetask . org-fold-outline) (outline . org-fold-outline) 
(heading . org-fold-outline) (headline . org-fold-outline) (:alias . 
org-fold-outline) (org-fold-outline . org-fold-outline)))
  org-fold-core-get-folding-spec-from-alias(org-fold-outline)
  org-fold-core--property-symbol-get-create(org-fold-outline)
  org-fold-core-decouple-indirect-buffer-folds()
  org-get-indirect-buffer(# #("Meetings / Sessions" 0 19 
(fontified nil line-prefix "" wrap-prefix #("* " 0 2 (face org-indent)
  #()
  apply(# nil)
  org-tree-to-indirect-buffer()
  (cond (indirect (org-tree-to-indirect-buffer)) (narrowed (progn 
(org-narrow-to-subtree) (goto-char (org-find-olp (read point-olp) 
'this-buffer)
  (progn (widen) (if heading-pos (goto-char heading-pos) (goto-char 
(string-to-number pos))) (cond (indirect (org-tree-to-indirect-buffer)) 
(narrowed (progn (org-narrow-to-subtree) (goto-char (org-find-olp (read 
point-olp) 'this-buffer) (if (and heading-pos relative-pos) (progn 
(forward-char (string-to-number relative-pos (current-buffer))
  (let* ((heading-pos (if top-olp (progn (org-find-olp (read top-olp) 
'this-buffer) (progn (widen) (if heading-pos (goto-char heading-pos) 
(goto-char (string-to-number pos))) (cond (indirect 
(org-tree-to-indirect-buffer)) (narrowed (progn (org-narrow-to-subtree) 
(goto-char (org-find-olp (read point-olp) 'this-buffer) (if (and 
heading-pos relative-pos) (progn (forward-char (string-to-number 
relative-pos (current-buffer)))
  (let ((pos x2699) (indirect x2700) (narrowed x2701) (top-olp x2702) 
(point-olp x2703) (relative-pos x2704)) (let* ((heading-pos (if top-olp (progn 
(org-find-olp (read top-olp) 'this-buffer) (progn (widen) (if heading-pos 
(goto-char heading-pos) (goto-char (string-to-number pos))) (cond (indirect 
(org-tree-to-indirect-buffer)) (narrowed (progn (org-narrow-to-subtree) 
(goto-char (org-find-olp ... ...) (if (and heading-pos relative-pos) (progn 
(forward-char (string-to-number relative-pos (current-buffer
  (let* ((x2699 (map-elt query "pos")) (x2700 (map-elt query "indirect")) 
(x2701 (map-elt query "narrowed")) (x2702 (map-elt query "top-olp")) (x2703 
(map-elt query "point-olp")) (x2704 (map-elt query "relative-pos"))) (let ((pos 
x2699) (indirect x2700) (narrowed x2701) (top-olp x2702) (point-olp x2703) 
(relative-pos x2704)) (let* ((heading-pos (if top-olp (progn (org-find-olp ... 
...) (progn (widen) (if heading-pos (goto-char heading-pos) (goto-char 
(string-to-number pos))) (cond (indirect (org-tree-to-indirect-buffer)) 
(narrowed (progn (org-narrow-to-subtree) (goto-char ... (if (and 
heading-pos relative-pos) (progn (forward-char (string-to-number 
relative-pos (current-buffer)
  (progn (ignore (mapp query)) (let* ((x2699 (map-elt query "pos")) (x2700 
(map-elt query "indirect")) (x2701 (map-elt query "narrowed")) (x2702 (map-elt 
query "top-olp")) (x2703 (map-elt query "point-olp")) (x2704 (map-elt query 
"relative-pos"))) (let ((pos x2699) (indirect x2700) (narrowed x2701) (top-olp 
x2702) (point-olp x2703) (relative-pos x2704)) (let* ((heading-pos (if top-olp 
(progn ... (progn (widen) (if heading-pos (goto-char heading-pos) 
(goto-char (string-to-number pos))) (cond (indirect 
(org-tree-to-indirect-buffer)) (narrowed (progn ... ...))) (if (and heading-pos 
relative-pos) (progn (forward-char ...))) (current-buffer))
  (progn (fset 'alist-get vnew) (progn (ignore (mapp query)) (let* ((x2699 
(map-elt 

[BUG] org-cite-insert fails to open json format bibliographies that contain entries for books with editors but no authors [9.6.6 (release_9.6.6 @ /snap/emacs/current/usr/share/emacs/29.1/lisp/org/)]

[Margaret Patterson]

Since upgrading to emacs 29.1 org-cite-insert no longer copes with 
bibliography files in json format where there is an entry for a book 
that has only editors and no author.


Expected behaviour:
Running org-cite-insert opens the bibliography file and allows me to 
search for a citation and insert it in the org file I’m editing.


Actual behaviour:
Running org-cite-insert fails to open the bibliography file with the 
following error:


org-cite-basic--key-completion-table: Wrong type argument: stringp, 
(((family . "Asimov") (given . "Isaac")) ((family . "Greenberg") (given 
. "Martin H.")))


(The exact error alters depending on the contents of the entry it fails on.)

Reproducing:
Attached are two bibliography files, citation-test-only-editor.json and 
citation-test-author.json, the first of which has a single entry of a 
book with two editors and no author, the second has the same book but 
I’ve changed one editor to an author.  Create an org file with 
“#+bibliography: citation-test-only-editor.json” or “#+bibliography: 
citation-test-author.json” at the top, and try running org-cite-insert.


Notes:
- The problem persists with emacs -Q.
- It is not a problem if I export my bibliography as a .bib file, just 
when it’s a .json file.

- It worked as I expected in emacs 28.2.
- Other parts of using org-cite seem to be unaffected but I haven’t 
exhaustively tested – I have just noted that manually typing in the 
citation and exporting the org file with a #+print_bibliography: line 
worked as expected and fontifying manually entered citations with 
org-cite-csl-activate works as expected.


Best wishes,
Margaret Patterson.

Emacs  : GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20, cairo version 1.16.0)

 of 2023-08-04
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/snap/emacs/current/usr/share/emacs/29.1/lisp/org/)


citation-test-author.json
Description: application/json


citation-test-only-editor.json
Description: application/json

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

[Max Nikulin]

On 24/08/2023 19:21, Ihor Radchenko wrote:

As I described, I often want inlinetasks to be exported and to be
displayed in my agenda/sparse tree views


It sounds like that if agenda had hooks allowing to gather either 
:inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask 
custom blocks then ** END would not be necessary.

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote:
> > Regressions are not the end of the world. Org does too much and grew
> > very fast, which is not sustainable.
>
> But they should not be taken lightly either.
> https://bzg.fr/en/the-software-maintainers-pledge/

I wouldn't recommend taking them lightly, but I think "never" is too
strong a word.

Org's grown so much and so fast, and has limited maintainer time. If
the choice is between keeping Org up to date in Emacs and working,
versus a problem feature, then it's appropriate to remove problems for
the health of the core.

Let's not remove on a whim.


--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[Bastien Guerry]

Ihor Radchenko  writes:

> org-inlinetask.el cannot exist outside Org core without all the extra
> support for inlinetasks across Org codebase.

I'm aware of this.

> So, what you are suggesting will completely remove inlinetasks
> feature.

I suggest removing the support for inline tasks *as they are designed
today*, yes.  I suggest reassessing the real problem we are trying to
solve here, and see if we can come up with an approach that does not
complexify Org's core syntax too much.

E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
a heading would fit 90% of what is expected from inline tasks in the
example you gave.

> Yup. That's why I think that we need to make inlinetasks have distinct
> syntax.

I'm reluctant to supercharge Org's core syntax for this feature.
I may be wrong, but I'd love to see if inline tasks are widely used,
and if so, for what specific purpose.  Again, if the core feature is
to prevent some headings from being exported, then other approaches
can be explored.

-- 
 Bastien Guerry

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
>
> >> What do you mean?
> >
> > I think Markdown has different levels?
>
> Do you mean # title vs. ## title?

https://www.markdownguide.org/basic-syntax

look at the alternate syntax where they under line with different symbols.

> > Has there ever been a reason to diversify the heading syntax to allow
> > levels or changes in visibility?
> >
> > ** TODO
> >
> > === TODO Inline item under todo
> >
> > --- DONE something else?
> >
> > ### TODO invis to all except interactive editing
>
> That's even more features. I feel confused about what you are trying to
> convey.

It is, but it's just brainstorming along the lines of needing an
inline task syntax.

We have a solid heading syntax, with one or more asterisks followed by
keywords and heading metadata. Given we're talking about adding more
flags in the metadata, I'm just asking if we should consider
alternatives to just asterisks to help indicate differences.

An inline task exempt from folding should be eye catching to
differentiate it from other headings. Perhaps something other than
asterisks is appropriate?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[tomas]

On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote:
>  writes:
> 
> >>
> >><...>
> >
> > Ah... it would be nice if Org could "go up one level",
> > wouldn't it?
> 
> What do you mean?

Not proposing to change anything, Org is what it is. Org's "sections"
are somewhat stepchildren, since the primary structure is the heading.

As a consequence, you "close" a section by "opening" a new one; if
you start a subsection, you can't end it "going back" to the enclosing
section: express this in Org:

  
this is some text in the main section
More text


(FWIW I cop out of this by declaring that a section name of - means
"going up" like so:

  * Main Section
this is some text in the main section
More text
  ** A Subsection
 Some text therein
  * -
Now we are "back" in the main section

(Note that here, the "-" gets one star, i.e. the level we are going
back to: this way, most things work as they should; and it is not
too hard to hack exporters to do the right thing :)

Back to the case in question: Someone proposed intercalating a
subsection instead of using an inline task, which would work
if there were a way of "closing" that subsection; otherwise the
idea messes with the document structure.

Cheers
-- 
t


signature.asc
Description: PGP signature

Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH] refactor org-babel-lilypond-compile-lilyfile

[No Wayman]

The attached patch:

- Improves the compilation message. (The target is the file, not 
 LilyPond itself).
- Refactors the body of the function to remove the many 
 nondescript arg-n local variables.
- Removes the optional TEST parameter, which is unused and better 
 served through debugging tools.  



>From 5765891b9de22260454d2cee8365c14841d0d744 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 24 Aug 2023 09:32:27 -0400
Subject: [PATCH] lisp/ob-lilypond.el: refactor
 org-babel-lilypond-compile-lilyfile

* ob-lilypond.el (org-babel-lilypond-compile-lilyfile):
Correct compilation message.
Remove superfluous local variables.
Remove unused ad-hoc debugging TEST parameter.
---
 lisp/ob-lilypond.el | 32 +---
 1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 8b2bd231f..92cd59685 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -247,27 +247,21 @@ org-babel-lilypond-execute-tangled-ly
 	(org-babel-lilypond-attempt-to-open-pdf org-babel-lilypond-temp-file)
 	(org-babel-lilypond-attempt-to-play-midi org-babel-lilypond-temp-file)
 
-(defun org-babel-lilypond-compile-lilyfile (file-name  test)
+(defun org-babel-lilypond-compile-lilyfile (file-name)
   "Compile lilypond file and check for compile errors.
 FILE-NAME is full path to lilypond (.ly) file."
-  (message "Compiling LilyPond...")
-  (let ((arg-1 org-babel-lilypond-ly-command) ;program
-;; (arg-2 nil);infile
-(arg-3 "*lilypond*")   ;buffer
-	(arg-4 t)  ;display
-	(arg-5 (if org-babel-lilypond-gen-png  "--png"  "")) ;
-	(arg-6 (if org-babel-lilypond-gen-html "--html" ""))
-(arg-7 (if org-babel-lilypond-gen-pdf "--pdf" ""))
-(arg-8 (if org-babel-lilypond-use-eps  "-dbackend=eps" ""))
-(arg-9 (if org-babel-lilypond-gen-svg  "-dbackend=svg" ""))
-(arg-10 (concat "--output=" (file-name-sans-extension file-name)))
-(arg-11 file-name))
-(if test
-`(,arg-1 ,nil ,arg-3 ,arg-4 ,arg-5 ,arg-6 ;; arg-2
- ,arg-7 ,arg-8 ,arg-9 ,arg-10 ,arg-11)
-  (call-process
-   arg-1 nil arg-3 arg-4 arg-5 arg-6 ;; arg-2
-   arg-7 arg-8 arg-9 arg-10 arg-11
+  (message "Compiling %s..." file-name)
+  (let ((args
+ (delq nil (list
+(and org-babel-lilypond-gen-png  "--png")
+(and org-babel-lilypond-gen-html "--html")
+(and org-babel-lilypond-gen-pdf  "--pdf")
+(and org-babel-lilypond-use-eps  "-dbackend=eps")
+(and org-babel-lilypond-gen-svg  "-dbackend=svg")
+(concat "--output=" (file-name-sans-extension file-name))
+file-name
+(apply #'call-process org-babel-lilypond-ly-command nil
+   "*lilypond*" 'display args)))
 
 (defun org-babel-lilypond-check-for-compile-error (file-name  test)
   "Check for compile error.
-- 
2.41.0

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
>
> >> * [#inline] Inlinetask
> >> * [#inline] END
> >
> > I think the multiline aspect is where the concept breaks down.
> >
> > "I want a special invisible heading inside the content of a heading,
> > that also supports optional multiline contents". Sounds horrible to code.
>
> It is not. The horrible part is that we rely on some things working
> magically without special account for inlinetask existance. Otherwise,
> it is just a matter of extra cond.

So then, refinement?

> > Given limited maintainer time, culling bad features is a fact of life.
>
> _I_ actively use inlinetasks. And it is not a bad feature by itself. The
> current syntax is bad, yes. And the current state with inlinetasks being
> optional feature.
>
> > My recommendation is cut it out, until someone with more time can make
> > a rational and compelling case for a clean syntax that isn't a huge
> > special case or write a separate module.
>
> Is there any hurry to delete things? If we still keep a new syntax open
> for discussion, I see no reason to remove anything.

Certainly no hurry. Just expressing my opinion. You know the code much
better than I, I'm just trying to defend maintainer time from extra
work.

Maybe start a new email thread for a RFC regarding a potential
replacement inline task syntax that would be cleaner for the code,
parser, and easier to maintain?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[Ihor Radchenko]

Russell Adams  writes:

>> It will. And it will also break some of my workflows :(
>
> I think that's unfortunate, but perhaps it would improve the health of
> the codebase?

Removing most features would improve health of the codebase. Like
getting rid of agenda with its horrible code. But it does not mean that
we should do it.

>> > Could we normalize the code if some of the features were enabled in a
>> > cookie/flag on a heading?
>>
>> We would need to put more special cases. Which has pros and cons,
>> actually. The downside is more special cases. The upside is that most of
>> inlinetask bugs are originating from the same code handling both
>> inlinetasks and headings without accounting for their differences.
>
> It sounds like the code would be cleaner in a single place using a cookie.

The cleanest would be something that does not match `org-outline-regexp-bol'.
Then, we will avoid all the possible confusion between tasks and inlinetasks.

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

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

[Ihor Radchenko]

Russell Adams  writes:

>> What do you mean?
>
> I think Markdown has different levels?

Do you mean # title vs. ## title?

> Has there ever been a reason to diversify the heading syntax to allow
> levels or changes in visibility?
>
> ** TODO
>
> === TODO Inline item under todo
>
> --- DONE something else?
>
> ### TODO invis to all except interactive editing

That's even more features. I feel confused about what you are trying to
convey.

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

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:36:39PM +, Ihor Radchenko wrote:
> > And that's part of the confusion: inline tasks _look like_ normal
> > tasks while behaving differently.
>
> Yup. That's why I think that we need to make inlinetasks have distinct
> syntax.

Do we have a concrete summary of individual features that inline tasks
have?

I'm hearing exempt from folding, and support for drawers/heading
items.

What else?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[Ihor Radchenko]

Russell Adams  writes:

>> * [#inline] Inlinetask
>> * [#inline] END
>
> I think the multiline aspect is where the concept breaks down.
>
> "I want a special invisible heading inside the content of a heading,
> that also supports optional multiline contents". Sounds horrible to code.

It is not. The horrible part is that we rely on some things working
magically without special account for inlinetask existance. Otherwise,
it is just a matter of extra cond.

>> Because it will be feature regression.
>> And it will not be possible with a custom plugin without significant
>> changes in how all the headline editing commands, agenda, sparse trees,
>> etc work - they all assume very specific heading syntax.
>
> Regressions are not the end of the world. Org does too much and grew
> very fast, which is not sustainable.

But they should not be taken lightly either.
https://bzg.fr/en/the-software-maintainers-pledge/

> Given limited maintainer time, culling bad features is a fact of life.

_I_ actively use inlinetasks. And it is not a bad feature by itself. The
current syntax is bad, yes. And the current state with inlinetasks being
optional feature.

> My recommendation is cut it out, until someone with more time can make
> a rational and compelling case for a clean syntax that isn't a huge
> special case or write a separate module.

Is there any hurry to delete things? If we still keep a new syntax open
for discussion, I see no reason to remove anything.

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

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:33:01PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
>
> > I hear "we have a bunch of extra complex code for an ill defined
> > special case". Org's designed around headings, and this special case
> > was a hack to abuse the threshold for heading detection to support a
> > nonstandard heading.
>
> It was a hack to reduce the amount of special cases in the existing
> code.
>
> > Sometimes there are features we just can't support.
> >
> > Would removing inline tasks in core clean up anything?
>
> It will. And it will also break some of my workflows :(

I think that's unfortunate, but perhaps it would improve the health of
the codebase?

> > Could we normalize the code if some of the features were enabled in a
> > cookie/flag on a heading?
>
> We would need to put more special cases. Which has pros and cons,
> actually. The downside is more special cases. The upside is that most of
> inlinetask bugs are originating from the same code handling both
> inlinetasks and headings without accounting for their differences.

It sounds like the code would be cleaner in a single place using a cookie.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote:
>  writes:
>
> >>
> >><...>
> >
> > Ah... it would be nice if Org could "go up one level",
> > wouldn't it?
>
> What do you mean?

I think Markdown has different levels?

It is interesting to think that Org has only one kind of heading:

** ...

Has there ever been a reason to diversify the heading syntax to allow
levels or changes in visibility?

** TODO

=== TODO Inline item under todo

--- DONE something else?

### TODO invis to all except interactive editing




--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[Ihor Radchenko]

Bastien Guerry  writes:

>> I do not think that it would be possible. In order to support
>> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
>> modify the internals. I see no way around that.
>
> Maybe we are miscommunicating: my suggestion is to _remove_
> lisp/org-inlinetask.el from Org's core.

org-inlinetask.el cannot exist outside Org core without all the extra
support for inlinetasks across Org codebase.

So, what you are suggesting will completely remove inlinetasks feature.

>> Too many aspects of Org are designed for one specific heading syntax.
>> Even modifying inlinetask *... syntax will likely require adding
>> more special support where things "magically" work for now because
>> inlinetasks often look the same as headings.
>
> And that's part of the confusion: inline tasks _look like_ normal
> tasks while behaving differently.

Yup. That's why I think that we need to make inlinetasks have distinct
syntax.

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

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

[Ihor Radchenko]

Russell Adams  writes:

> I hear "we have a bunch of extra complex code for an ill defined
> special case". Org's designed around headings, and this special case
> was a hack to abuse the threshold for heading detection to support a
> nonstandard heading.

It was a hack to reduce the amount of special cases in the existing
code.

> Sometimes there are features we just can't support.
>
> Would removing inline tasks in core clean up anything?

It will. And it will also break some of my workflows :(

> Could we normalize the code if some of the features were enabled in a
> cookie/flag on a heading?

We would need to put more special cases. Which has pros and cons,
actually. The downside is more special cases. The upside is that most of
inlinetask bugs are originating from the same code handling both
inlinetasks and headings without accounting for their differences.

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

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

[Ihor Radchenko]

 writes:

>>
>><...>
>
> Ah... it would be nice if Org could "go up one level",
> wouldn't it?

What do you mean?

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

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

[tomas]

On Thu, Aug 24, 2023 at 02:36:31PM +0200, Bastien Guerry wrote:
> Ihor Radchenko  writes:
> 
> > ** Section X
> >
> > 
> >
> > 
> > <...>
> > 
> > <...>
> > 
> > <...>
> >
> > *** TODO Task for paragraph N
> >
> > Then, if I jump to the TODO, for example, from agenda view, I still need
> > to somehow find  location, which is awkward when the
> > section has multiple screens of text.
> 
> And what about this?
> 
>** Section X
>
>
>
>
><...>
>
>*** TODO Task for paragraph N
>
>
><...>
>
><...>

Ah... it would be nice if Org could "go up one level",
wouldn't it?

;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[Russell Adams]

On Thu, Aug 24, 2023 at 01:04:10PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
> We might. Adding gazillion of stars is not conceptually different from
> adding a spacial cookie.

True. Just cleaner.

> The only extra thing required is some way to mark inlinetask ending,
> because we must be able to continue the containing section below
> inlinetask:
>
> * [#inline] Inlinetask
> * [#inline] END

I think the multiline aspect is where the concept breaks down.

"I want a special invisible heading inside the content of a heading,
that also supports optional multiline contents". Sounds horrible to code.

> > Shouldn't this be excluded from core and supplied by someone's custom
> > plugin if they want this ability? Org-mode should focus on the
> > headings and their data, and if you need to hack in some extra syntax
> > perhaps Org doesn't need to concern itself.
>
> Because it will be feature regression.
> And it will not be possible with a custom plugin without significant
> changes in how all the headline editing commands, agenda, sparse trees,
> etc work - they all assume very specific heading syntax.

Regressions are not the end of the world. Org does too much and grew
very fast, which is not sustainable.

There were other mails in this thread that agreed this might be an ill
conceived feature hack.

Given limited maintainer time, culling bad features is a fact of life.

My recommendation is cut it out, until someone with more time can make
a rational and compelling case for a clean syntax that isn't a huge
special case or write a separate module.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH]: fix ob-lilypond docstrings

[No Wayman]

Ihor Radchenko  writes:


No Wayman  writes:


The attached patch satisfies all but two checkdoc warnings.
I left those two for someone more familiar with the package.


Thanks!


Subject: [PATCH] * lisp/ob-lilypond.el: satisfy checkdoc


_S_atisfy.


(org-babel-lilypond-compile-post-tangle): fix docstring
(org-babel-lilypond-display-pdf-post-tangle): fix docstring
(org-babel-lilypond-play-midi-post-tangle): fix docstring
(org-babel-execute:lilypond): fix docstring
(org-babel-lilypond-tangle): fix docstring
(org-babel-lilypond-process-basic): fix docstring
(org-babel-lilypond-parse-line-num): fix docstring
(org-babel-lilypond-set-header-args): fix docstring


It is enough to say "Fix docstring" just for the last line and 
leave all

other : ... empty.


Fixed in attached patch.


 (defun org-babel-lilypond-set-header-args (mode)
-  "Set org-babel-default-header-args:lilypond
-dependent on ORG-BABEL-LILYPOND-ARRANGE-MODE."
+  "Set lilypond babel header args from 
ORG-BABEL-LILYPOND-ARRANGE-MODE."


What is ORG-BABEL-LILYPOND-ARRANGE-MODE?


Looks like it's a variable that would be better served by a 
minor-mode.


#+begin_src emacs-lisp
(defvar org-babel-lilypond-arrange-mode nil
 "Non-nil turns Arrange mode on.
In Arrange mode the following settings are altered from default:
:tangle yes,:noweb yes
:results silent :comments yes.
In addition lilypond block execution causes tangling of all 
lilypond

blocks.")
#+end_src

A minor mode would also obviate the need for 
`org-babel-lilypond-toggle-arrange-mode'.

Let's do that in a separate patch.

>From 2acc8e219011040d76e0faa0a6f642ace480f2df Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 24 Aug 2023 08:20:22 -0400
Subject: [PATCH] * lisp/ob-lilypond.el: Satisfy checkdoc

(org-babel-lilypond-compile-post-tangle):
(org-babel-lilypond-display-pdf-post-tangle):
(org-babel-lilypond-play-midi-post-tangle):
(org-babel-execute:lilypond):
(org-babel-lilypond-tangle):
(org-babel-lilypond-process-basic):
(org-babel-lilypond-parse-line-num):
(org-babel-lilypond-set-header-args):
Fix docstring
---
 lisp/ob-lilypond.el | 37 -
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 8b2bd231f..b6ee91f58 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -58,23 +58,13 @@ ob-lilypond-header-args
 See `org-babel-lilypond-set-header-args'.")
 
 (defvar org-babel-lilypond-compile-post-tangle t
-  "Following the org-babel-tangle (C-c C-v t) command,
-org-babel-lilypond-compile-post-tangle determines whether ob-lilypond should
-automatically attempt to compile the resultant tangled file.
-If the value is nil, no automated compilation takes place.
-Default value is t.")
+  "When non-nil, compile tangled file after `org-babel-tangle'.")
 
 (defvar org-babel-lilypond-display-pdf-post-tangle t
-  "Following a successful LilyPond compilation
-org-babel-lilypond-display-pdf-post-tangle determines whether to automate the
-drawing / redrawing of the resultant pdf.  If the value is nil,
-the pdf is not automatically redrawn.  Default value is t.")
+  "When non-nil, display pdf after successful LilyPond compilation.")
 
 (defvar org-babel-lilypond-play-midi-post-tangle t
-  "Following a successful LilyPond compilation
-org-babel-lilypond-play-midi-post-tangle determines whether to automate the
-playing of the resultant midi file.  If the value is nil,
-the midi file is not automatically played.  Default value is t")
+  "When non-nil, play midi file after successful LilyPond compilation.")
 
 (defvar org-babel-lilypond-ly-command ""
   "Command to execute lilypond on your system.
@@ -155,20 +145,17 @@ org-babel-expand-body:lilypond
 body))
 
 (defun org-babel-execute:lilypond (body params)
-  "This function is called by `org-babel-execute-src-block'.
-Depending on whether we are in arrange mode either:
-1. Attempt to execute lilypond block according to header settings
-  (This is the default basic mode)
-2. Tangle all lilypond blocks and process the result (arrange mode)"
+  "Execute lilypond src blcok according to arragne mode.
+See `org-babel-execute-src-block' for BODY and PARAMS.
+When in arrange mode, tangle all blocks and process the result.
+Otherwise, execute block according to header settings."
   (org-babel-lilypond-set-header-args org-babel-lilypond-arrange-mode)
   (if org-babel-lilypond-arrange-mode
   (org-babel-lilypond-tangle)
 (org-babel-lilypond-process-basic body params)))
 
 (defun org-babel-lilypond-tangle ()
-  "ob-lilypond specific tangle, attempts to invoke
-=ly-execute-tangled-ly= if tangle is successful.  Also passes
-specific arguments to =org-babel-tangle=."
+  "Tangle lilypond blocks, then `org-babel-liypond-execute-tangled-ly'."
   (interactive)
   (if (org-babel-tangle nil "yes" "lilypond")
   (org-babel-lilypond-execute-tangled-ly) nil))
@@ -190,7 +177,8 @@ org-babel-lilypond-paper-settings
 They are needed for mixing music 

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

[Bastien Guerry]

Ihor Radchenko  writes:

>> I see.  So not only inline tasks are ugly syntactic-wise, but they
>> also have a specific behavior when exporting.  All this pleas for an
>> external module, not for something we support in Org's core IMHO.
>
> I do not think that it would be possible. In order to support
> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
> modify the internals. I see no way around that.

Maybe we are miscommunicating: my suggestion is to _remove_
lisp/org-inlinetask.el from Org's core.

> Too many aspects of Org are designed for one specific heading syntax.
> Even modifying inlinetask *... syntax will likely require adding
> more special support where things "magically" work for now because
> inlinetasks often look the same as headings.

And that's part of the confusion: inline tasks _look like_ normal
tasks while behaving differently.

-- 
 Bastien Guerry

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

[Russell Adams]

On Thu, Aug 24, 2023 at 12:56:01PM +, Ihor Radchenko wrote:
> Bastien Guerry  writes:
>
> > Ihor Radchenko  writes:
> >
> >> This will break export and folding.
> >> Also, I often simply archive inlinetasks once they are done. The above
> >> will archive too much.
> >
> > I see.  So not only inline tasks are ugly syntactic-wise, but they
> > also have a specific behavior when exporting.  All this pleas for an
> > external module, not for something we support in Org's core IMHO.
>
> I do not think that it would be possible. In order to support
> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
> modify the internals. I see no way around that.
>
> Too many aspects of Org are designed for one specific heading syntax.
> Even modifying inlinetask *... syntax will likely require adding
> more special support where things "magically" work for now because
> inlinetasks often look the same as headings.

I hear "we have a bunch of extra complex code for an ill defined
special case". Org's designed around headings, and this special case
was a hack to abuse the threshold for heading detection to support a
nonstandard heading.

Sometimes there are features we just can't support.

Would removing inline tasks in core clean up anything?

Could we normalize the code if some of the features were enabled in a
cookie/flag on a heading?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

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

[Ihor Radchenko]

Russell Adams  writes:

> So just to be clear, we want a method to make a heading with all the
> features of headings, but that isn't a heading or treated like a
> heading?

> Isn't the key feature that the inline task is a heading except it is
> exempt from the folding logic (ie: sparse tree)?

> Why can't we do this with a flag or cookie in a heading? We already
> have priority cookies.

We might. Adding gazillion of stars is not conceptually different from
adding a spacial cookie.

The only extra thing required is some way to mark inlinetask ending,
because we must be able to continue the containing section below
inlinetask:

* [#inline] Inlinetask
* [#inline] END

> Shouldn't this be excluded from core and supplied by someone's custom
> plugin if they want this ability? Org-mode should focus on the
> headings and their data, and if you need to hack in some extra syntax
> perhaps Org doesn't need to concern itself.

Because it will be feature regression.
And it will not be possible with a custom plugin without significant
changes in how all the headline editing commands, agenda, sparse trees,
etc work - they all assume very specific heading syntax.

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

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

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> This will break export and folding.
>> Also, I often simply archive inlinetasks once they are done. The above
>> will archive too much.
>
> I see.  So not only inline tasks are ugly syntactic-wise, but they
> also have a specific behavior when exporting.  All this pleas for an
> external module, not for something we support in Org's core IMHO.

I do not think that it would be possible. In order to support
inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
modify the internals. I see no way around that.

Too many aspects of Org are designed for one specific heading syntax.
Even modifying inlinetask *... syntax will likely require adding
more special support where things "magically" work for now because
inlinetasks often look the same as headings.

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

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

[Russell Adams]

On Thu, Aug 24, 2023 at 12:40:50PM +, Ihor Radchenko wrote:
> Bastien Guerry  writes:
> This will break export and folding.
> Also, I often simply archive inlinetasks once they are done. The above
> will archive too much.

So just to be clear, we want a method to make a heading with all the
features of headings, but that isn't a heading or treated like a
heading?

Isn't the key feature that the inline task is a heading except it is
exempt from the folding logic (ie: sparse tree)?

Why can't we do this with a flag or cookie in a heading? We already
have priority cookies.

If the inline task also doesn't impact the tree structure of the
parent heading, that's an even taller order. That's where plain lists
are OK, they just lack the extra functionality of a heading (ie: drawers).

I don't see any solution that isn't really hacky.

Shouldn't this be excluded from core and supplied by someone's custom
plugin if they want this ability? Org-mode should focus on the
headings and their data, and if you need to hack in some extra syntax
perhaps Org doesn't need to concern itself.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Jens Schmidt]

On 2023-08-24  14:24, Ihor Radchenko wrote:
> Jens Schmidt  writes:
> 
>> Would you mind if I added a test that explicitly and with some nice
>> error message tests for that condition?  I.e. if some unwary user
>> strips off trailing whitespace in test-org.el, that test would fail
>> with a reasonable message.
> 
> There is no universal rule when and when not to add trailing spaces in
> the tests.

Not sure what you mean by that, but some tests rely on trailing spaces
and fail when these are not present.  An explicit test on that would
make the issue more visible.  See below for what I mean.  The only (?)
downside is that this catches such errors in test-org.el only, and not
in all the other tests, many of which also contain (on purpose or
inadvertently) trailing whitespace:

[org-mode]$ grep -l $'[ \t]$' testing/lisp/*
testing/lisp/test-ob-C.el
testing/lisp/test-ob-R.el
testing/lisp/test-ob-fortran.el
testing/lisp/test-org-agenda.el
testing/lisp/test-org-element.el
testing/lisp/test-org-fold.el
testing/lisp/test-org-footnote.el
testing/lisp/test-org.el



diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index e33f500a3..e49c2f957 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -9363,6 +9363,16 @@ two
(string-match-p "\\`Invalid format.*%2" 
err-text))
 err)
 
+

+;;; Meta-test on Trailing Whitespace not Being Deleted
+
+(ert-deftest test-org/trailing-whitespace-deleted ()
+"Ensure trailing whitespace did not get deleted in this file."
+  (should
+   (equal "Do not delete trailing whitespace --> 
+   in this file."
+  "Do not delete trailing whitespace --> \n   in this file.")))
+
 (provide 'test-org)
 
 ;;; test-org.el ends here


If the blank after the arrow gets removed, this test fails as:


Test test-org/trailing-whitespace-deleted condition:
(ert-test-failed
 ((should
   (equal "Do not delete trailing whitespace -->
   in this file." "Do not delete trailing whitespace --> 
   in this file."))
  :form
  (equal "Do not delete trailing whitespace -->
   in this file." "Do not delete trailing whitespace --> 
   in this file.")
  :value nil :explanation
  (arrays-of-different-length 62 63 "Do not delete trailing whitespace -->
   in this file." "Do not delete trailing whitespace --> 
   in this file." first-mismatch-at 37)))
   FAILED  1068/1095  test-org/trailing-whitespace-deleted (0.000193 sec)

[...]

1 unexpected results:
   FAILED  test-org/trailing-whitespace-deleted

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

[Bastien Guerry]

Ihor Radchenko  writes:

> This will break export and folding.
> Also, I often simply archive inlinetasks once they are done. The above
> will archive too much.

I see.  So not only inline tasks are ugly syntactic-wise, but they
also have a specific behavior when exporting.  All this pleas for an
external module, not for something we support in Org's core IMHO.

-- 
 Bastien Guerry

Re: Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH]: fix ob-lilypond docstrings

[Ihor Radchenko]

No Wayman  writes:

> The attached patch satisfies all but two checkdoc warnings.
> I left those two for someone more familiar with the package.

Thanks!

> Subject: [PATCH] * lisp/ob-lilypond.el: satisfy checkdoc

_S_atisfy.

> (org-babel-lilypond-compile-post-tangle): fix docstring
> (org-babel-lilypond-display-pdf-post-tangle): fix docstring
> (org-babel-lilypond-play-midi-post-tangle): fix docstring
> (org-babel-execute:lilypond): fix docstring
> (org-babel-lilypond-tangle): fix docstring
> (org-babel-lilypond-process-basic): fix docstring
> (org-babel-lilypond-parse-line-num): fix docstring
> (org-babel-lilypond-set-header-args): fix docstring

It is enough to say "Fix docstring" just for the last line and leave all
other : ... empty.

>  (defun org-babel-lilypond-set-header-args (mode)
> -  "Set org-babel-default-header-args:lilypond
> -dependent on ORG-BABEL-LILYPOND-ARRANGE-MODE."
> +  "Set lilypond babel header args from ORG-BABEL-LILYPOND-ARRANGE-MODE."

What is ORG-BABEL-LILYPOND-ARRANGE-MODE?

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

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

[Ihor Radchenko]

Bastien Guerry  writes:

>> Then, if I jump to the TODO, for example, from agenda view, I still need
>> to somehow find  location, which is awkward when the
>> section has multiple screens of text.
>
> And what about this?
>
>** Section X
>
>
>
>
><...>
>
>*** TODO Task for paragraph N
>
>
><...>
>
><...>

This will break export and folding.
Also, I often simply archive inlinetasks once they are done. The above
will archive too much.

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

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

[Bastien Guerry]

Ihor Radchenko  writes:

> ** Section X
>
> 
>
> 
> <...>
> 
> <...>
> 
> <...>
>
> *** TODO Task for paragraph N
>
> Then, if I jump to the TODO, for example, from agenda view, I still need
> to somehow find  location, which is awkward when the
> section has multiple screens of text.

And what about this?

   ** Section X
   
   
   
   
   <...>
   
   *** TODO Task for paragraph N
   
   
   <...>
   
   <...>
   
-- 
 Bastien Guerry

Re: [BUG] Failing tests for ob-clojure

[Daniel Kraus]

Hi!

Ihor Radchenko  writes:

> I am now going through all the babel tests that are disabled by default.
>
> ob-clojure tests appear to be completely broken:
>
> 1. (org-test-for-executable "cider") assertion is strange as cider
>package does not have any executable.
>
> 2. All the tests seems to assert that ob-clojure supports sessions,
>while it does not seem to be the case.

Unfortunately you're right and I would even say we can completely
remove `test-ob-clojure.el`.
There seems to be only tests for session support which currently
doesn't exist anymore and another one which tests plain tangle
and is not really Clojure specific.

I would love to write new tests but as I just started a new job
and got a new baby at the same time, I don't think I'll find the
time for it the next 3-4 month :(

Thanks,
  Daniel

Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH]: fix ob-lilypond docstrings

[No Wayman]

The attached patch satisfies all but two checkdoc warnings.
I left those two for someone more familiar with the package.

>From ecd5fe22458db64d86650a1a7a1e697d9ccff020 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 24 Aug 2023 08:20:22 -0400
Subject: [PATCH] * lisp/ob-lilypond.el: satisfy checkdoc

(org-babel-lilypond-compile-post-tangle): fix docstring
(org-babel-lilypond-display-pdf-post-tangle): fix docstring
(org-babel-lilypond-play-midi-post-tangle): fix docstring
(org-babel-execute:lilypond): fix docstring
(org-babel-lilypond-tangle): fix docstring
(org-babel-lilypond-process-basic): fix docstring
(org-babel-lilypond-parse-line-num): fix docstring
(org-babel-lilypond-set-header-args): fix docstring
---
 lisp/ob-lilypond.el | 37 -
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 8b2bd231f..47ad0a25d 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -58,23 +58,13 @@ ob-lilypond-header-args
 See `org-babel-lilypond-set-header-args'.")
 
 (defvar org-babel-lilypond-compile-post-tangle t
-  "Following the org-babel-tangle (C-c C-v t) command,
-org-babel-lilypond-compile-post-tangle determines whether ob-lilypond should
-automatically attempt to compile the resultant tangled file.
-If the value is nil, no automated compilation takes place.
-Default value is t.")
+  "When non-nil, compile tangled file after `org-babel-tangle'.")
 
 (defvar org-babel-lilypond-display-pdf-post-tangle t
-  "Following a successful LilyPond compilation
-org-babel-lilypond-display-pdf-post-tangle determines whether to automate the
-drawing / redrawing of the resultant pdf.  If the value is nil,
-the pdf is not automatically redrawn.  Default value is t.")
+  "When non-nil, display pdf after successful LilyPond compilation.")
 
 (defvar org-babel-lilypond-play-midi-post-tangle t
-  "Following a successful LilyPond compilation
-org-babel-lilypond-play-midi-post-tangle determines whether to automate the
-playing of the resultant midi file.  If the value is nil,
-the midi file is not automatically played.  Default value is t")
+  "When non-nil, play midi file after successful LilyPond compilation.")
 
 (defvar org-babel-lilypond-ly-command ""
   "Command to execute lilypond on your system.
@@ -155,20 +145,17 @@ org-babel-expand-body:lilypond
 body))
 
 (defun org-babel-execute:lilypond (body params)
-  "This function is called by `org-babel-execute-src-block'.
-Depending on whether we are in arrange mode either:
-1. Attempt to execute lilypond block according to header settings
-  (This is the default basic mode)
-2. Tangle all lilypond blocks and process the result (arrange mode)"
+  "Execute lilypond src blcok according to arragne mode.
+See `org-babel-execute-src-block' for BODY and PARAMS.
+When in arrange mode, tangle all blocks and process the result.
+Otherwise, execute block according to header settings."
   (org-babel-lilypond-set-header-args org-babel-lilypond-arrange-mode)
   (if org-babel-lilypond-arrange-mode
   (org-babel-lilypond-tangle)
 (org-babel-lilypond-process-basic body params)))
 
 (defun org-babel-lilypond-tangle ()
-  "ob-lilypond specific tangle, attempts to invoke
-=ly-execute-tangled-ly= if tangle is successful.  Also passes
-specific arguments to =org-babel-tangle=."
+  "Tangle lilypond blocks, then `org-babel-liypond-execute-tangled-ly'."
   (interactive)
   (if (org-babel-tangle nil "yes" "lilypond")
   (org-babel-lilypond-execute-tangled-ly) nil))
@@ -190,7 +177,8 @@ org-babel-lilypond-paper-settings
 They are needed for mixing music and text in basic-mode.")
 
 (defun org-babel-lilypond-process-basic (body params)
-  "Execute a lilypond block in basic mode."
+  "Execute a lilypond block in basic mode.
+See `org-babel-execute-src-block' for BODY and PARAMS."
   (let* ((out-file (cdr (assq :file params)))
  (file-type (file-name-extension out-file))
 	 (cmdline (or (cdr (assq :cmdline params))
@@ -308,7 +296,7 @@ org-babel-lilypond-mark-error-line
   (goto-char temp
 
 (defun org-babel-lilypond-parse-line-num ( buffer)
-  "Extract error line number."
+  "Extract error line number in BUFFER or `current-buffer'."
   (when buffer (set-buffer buffer))
   (let ((start
  (and (search-backward ":" nil t)
@@ -441,8 +429,7 @@ org-babel-lilypond-get-header-args
  ob-lilypond-header-args)))
 
 (defun org-babel-lilypond-set-header-args (mode)
-  "Set org-babel-default-header-args:lilypond
-dependent on ORG-BABEL-LILYPOND-ARRANGE-MODE."
+  "Set lilypond babel header args from ORG-BABEL-LILYPOND-ARRANGE-MODE."
   (setq org-babel-default-header-args:lilypond
 (org-babel-lilypond-get-header-args mode)))
 
-- 
2.41.0

Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Ihor Radchenko]

Ihor Radchenko  writes:

> What we can do is setting `delete-trailing-lines' to nil in tests - via
> directory-local variable.

Never mind. This will not affect deleting empty lines that are not
at the end of buffer.

Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Ihor Radchenko]

Jens Schmidt  writes:

> Would you mind if I added a test that explicitly and with some nice
> error message tests for that condition?  I.e. if some unwary user
> strips off trailing whitespace in test-org.el, that test would fail
> with a reasonable message.

There is no universal rule when and when not to add trailing spaces in
the tests.

What we can do is setting `delete-trailing-lines' to nil in tests - via
directory-local variable.

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

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

[Ihor Radchenko]

Russell Adams  writes:

> * Item
>
> Wubba lubba ding dong.
>
> # TODO fix this to pig latin
>
> Arff!!
>
> * Other stuff
>
>
> Doesn't this really come down to a use case for having headings which
> are excluded from operations like comments are?

Nope. As I described, I often want inlinetasks to be exported and to be
displayed in my agenda/sparse tree views:

1. On export, I will see

1 Item
══

  Wubba lubba ding dong.

  ━━
  TODO fix this to pig latin
  ━━
  Arff!!


2 Other staff
═

2. I can also use the inlinetask normally, scheduling it, adding notes
   to it, etc

> Could we treat #'s as inline headings? Not sure how that'd handle
> drawers.

#'s are excluded from export unconditionally. Also, more complex
 inlinetasks may contain normal Org markup and elements, which make no
 sense in comments.

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

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

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> The benefit is that I do not need to search for that "paragraph N" when
>> I want to work on the task. I simply jump to the task location and can
>> immediately see the paragraph it refers to.
>
> But this would be the same with a non-inlined task, right?

No. For non-inlined task, I'd have to put the task somewhere far away
from the paragraph text:

** Section X




<...>

<...>

<...>

*** TODO Task for paragraph N

Then, if I jump to the TODO, for example, from agenda view, I still need
to somehow find  location, which is awkward when the
section has multiple screens of text.

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

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

[Russell Adams]

On Thu, Aug 24, 2023 at 11:44:29AM +, Ihor Radchenko wrote:
> Bastien Guerry  writes:
>
> >> * TODO Consider explaining more about X
> >> 
> >>
> >> <...>
> >>
> >> Then, I can easily review the manuscript status using sparse tree or
> >> agenda view.
> >
> > I see -- but what is the real benefit of inline tasks here over normal
> > tasks?  I understand that  should not be considered as
> > the details for a task, but rather its "target", but inline task does
> > not seem to add much here.
>
> The benefit is that I do not need to search for that "paragraph N" when
> I want to work on the task. I simply jump to the task location and can
> immediately see the paragraph it refers to.
>
> Also, pdf export of such inlinetask will nicely mark the TODO item in
> the manuscript draft, so that I can print things, and still see what
> should be done in that particular location of the manuscript.

Interesting. I often will use comments when I need to update things in
a document to be exported.

* Item

Wubba lubba ding dong.

# TODO fix this to pig latin

Arff!!

* Other stuff


Doesn't this really come down to a use case for having headings which
are excluded from operations like comments are?

Could we treat #'s as inline headings? Not sure how that'd handle
drawers.



--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: C-RET and empty lines

[Max Nikulin]

On 22/08/2023 16:52, Ihor Radchenko wrote:

Max Nikulin writes:

Yes, it is intentional. Org follows the blank lines of the current
heading when you press C-RET, by default.

This behaviour is customizable. See `org-blank-before-new-entry'.


Thank you for explanation. Frankly speaking, I missed an option "do not 
try to be smart (do not make decisions on hidden content because the 
previous heading is folded)" that just adds "\n*" with appropriate 
number of asterisks. I will try ('heading . t).

Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Jens Schmidt]

On 2023-08-24  13:41, Ihor Radchenko wrote:
> Jens Schmidt  writes:
> 
>> Seems the insert-heading-issue is still struggling, this time during
>> a "make check" @ d5ee33fed8dd80d3f9f9811d86a73827fde80780 using Emacs 29:
>> ...
>>FAILED   998/1094  test-org/insert-heading (0.018306 sec) at 
>> ../lisp/test-org.el:1845
> 
> I cannot reproduce on my system. Using Emacs 29.
> Our CI tests are also not failing.

Not a bug, my bad:  I keep forgetting about `delete-trailing-whitespace'
on my `before-save-hook'.

Would you mind if I added a test that explicitly and with some nice
error message tests for that condition?  I.e. if some unwary user
strips off trailing whitespace in test-org.el, that test would fail
with a reasonable message.

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

[Bastien Guerry]

Ihor Radchenko  writes:

> The benefit is that I do not need to search for that "paragraph N" when
> I want to work on the task. I simply jump to the task location and can
> immediately see the paragraph it refers to.

But this would be the same with a non-inlined task, right?

> Also, pdf export of such inlinetask will nicely mark the TODO item in
> the manuscript draft, so that I can print things, and still see what
> should be done in that particular location of the manuscript.

Yes, I see.

-- 
 Bastien Guerry

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

[Ihor Radchenko]

Bastien Guerry  writes:

>> * TODO Consider explaining more about X
>> 
>>
>> <...>
>>
>> Then, I can easily review the manuscript status using sparse tree or
>> agenda view.
>
> I see -- but what is the real benefit of inline tasks here over normal
> tasks?  I understand that  should not be considered as
> the details for a task, but rather its "target", but inline task does
> not seem to add much here.

The benefit is that I do not need to search for that "paragraph N" when
I want to work on the task. I simply jump to the task location and can
immediately see the paragraph it refers to.

Also, pdf export of such inlinetask will nicely mark the TODO item in
the manuscript draft, so that I can print things, and still see what
should be done in that particular location of the manuscript.

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

Re: [BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Ihor Radchenko]

Jens Schmidt  writes:

> Seems the insert-heading-issue is still struggling, this time during
> a "make check" @ d5ee33fed8dd80d3f9f9811d86a73827fde80780 using Emacs 29:
> ...
>FAILED   998/1094  test-org/insert-heading (0.018306 sec) at 
> ../lisp/test-org.el:1845

I cannot reproduce on my system. Using Emacs 29.
Our CI tests are also not failing.

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

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

[Bastien Guerry]

Ihor Radchenko  writes:

> My personal use case is when using Org for authoring long texts.
> I often leave inline tasks around the specific paragraph I need to
> revise in future:
>
> * Section XX
> 
>
> 
>
> <...>
>
> * TODO Consider explaining more about X
> 
>
> <...>
>
> Then, I can easily review the manuscript status using sparse tree or
> agenda view.

I see -- but what is the real benefit of inline tasks here over normal
tasks?  I understand that  should not be considered as
the details for a task, but rather its "target", but inline task does
not seem to add much here.

-- 
 Bastien Guerry

Re: [patch] Fix inner smart quotes in French

[Bastien Guerry]

Ihor Radchenko  writes:

> Agree. We can factor out the language names into a separate constant and
> then use that constant as a source of "canonical" language names in
> :type definitions of defcustom. Then, we can turn all the other
> dictionary variables into defcustoms.

Yes, sounds good!

-- 
 Bastien Guerry

[BUG] "make check" reports a failure on test-org/insert-heading @ d5ee33f (this time with Emacs 29)

[Jens Schmidt]

Seems the insert-heading-issue is still struggling, this time during
a "make check" @ d5ee33fed8dd80d3f9f9811d86a73827fde80780 using Emacs 29:

Test test-org/insert-heading condition:
(ert-test-failed
 ((should
   (equal "* 1\n** 1.1\n** 1.2\n*\n* 2"
  (org-test-with-temp-text "* 1\n** 1.1\n** 1.2\n* 2" ... 
...)))
  :form
  (equal "* 1\n** 1.1\n** 1.2\n*\n* 2"
 #("* 1\n** 1.1\n** 1.2\n* \n* 2" 0 2
   (face org-level-1)
   2 3
   (face org-level-1)
   4 5
   (face org-level-2)
   5 7
   (face org-level-2)
   7 10
   (face org-level-2)
   11 12
   (face org-level-2)
   12 14
   (face org-level-2)
   14 17
   (face org-level-2)
   21 23
   (face org-level-1)
   23 24
   (face org-level-1)))
  :value nil :explanation
  (arrays-of-different-length 23 24 "* 1\n** 1.1\n** 1.2\n*\n* 2"
  #("* 1\n** 1.1\n** 1.2\n* \n* 2" 0 2
(face org-level-1)
2 3
(face org-level-1)
4 5
(face org-level-2)
5 7
(face org-level-2)
7 10
(face org-level-2)
11 12
(face org-level-2)
12 14
(face org-level-2)
14 17
(face org-level-2)
21 23
(face org-level-1)
23 24
(face org-level-1))
  first-mismatch-at 19)))
   FAILED   998/1094  test-org/insert-heading (0.018306 sec) at 
../lisp/test-org.el:1845

Re: [BUG] Compilation warnings when making main @ d5ee33fed8dd80d3f9f9811d86a73827fde80780

[Ihor Radchenko]

Jens Schmidt  writes:

>>> In org-element--properties-mapc:
>>> org-element-ast.el:628:25:Warning: ‘not’ called with 3 args, but requires 1
>>> org-element-ast.el:628:30:Warning: reference to free variable ‘eq’
>> 
>> I also saw them. They do not make any sense. And they do not appear in
>> Emacs 29.
>
> Sorry for the hassle, I have been indeed using the wrong Emacs here.

Emacs 28 is not wrong. And even Emacs 27 - the oldest Emacs version we
still support.

There were several more spurious warnings there that I had to explicitly
suppress for old Emacs. However, this particular one appears to be
caused by Emacs <29 bug - even adding `with-no-warnings' around the code
in question does not make these two warnings disappear.

Handled.

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

Re: [BUG] Compilation warnings when making main @ d5ee33fed8dd80d3f9f9811d86a73827fde80780

[Jens Schmidt]

On 2023-08-24  13:18, Ihor Radchenko wrote:
> Jens Schmidt  writes:
> 
>> Compiling /home/jschmidt/work/org-mode/lisp/org-element-ast.el...
>>
>> In org-element--properties-mapc:
>> org-element-ast.el:628:25:Warning: ‘not’ called with 3 args, but requires 1
>> org-element-ast.el:628:30:Warning: reference to free variable ‘eq’
> 
> I also saw them. They do not make any sense. And they do not appear in
> Emacs 29.

Sorry for the hassle, I have been indeed using the wrong Emacs here.

Re: [BUG] Compilation warnings when making main @ d5ee33fed8dd80d3f9f9811d86a73827fde80780

[Ihor Radchenko]

Jens Schmidt  writes:

> Compiling /home/jschmidt/work/org-mode/lisp/org-element-ast.el...
>
> In org-element--properties-mapc:
> org-element-ast.el:628:25:Warning: ‘not’ called with 3 args, but requires 1
> org-element-ast.el:628:30:Warning: reference to free variable ‘eq’

I also saw them. They do not make any sense. And they do not appear in
Emacs 29.

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

[BUG] Compilation warnings when making main @ d5ee33fed8dd80d3f9f9811d86a73827fde80780

[Jens Schmidt]

Compiling /home/jschmidt/work/org-mode/lisp/org-cycle.el...
Compiling /home/jschmidt/work/org-mode/lisp/org-datetree.el...
Compiling /home/jschmidt/work/org-mode/lisp/org-duration.el...
Compiling /home/jschmidt/work/org-mode/lisp/org-element-ast.el...

In org-element--properties-mapc:
org-element-ast.el:628:25:Warning: ‘not’ called with 3 args, but requires 1
org-element-ast.el:628:30:Warning: reference to free variable ‘eq’
Compiling /home/jschmidt/work/org-mode/lisp/org-element.el...
Compiling /home/jschmidt/work/org-mode/lisp/org-entities.el...
Compiling /home/jschmidt/work/org-mode/lisp/org-faces.el...
Compiling /home/jschmidt/work/org-mode/lisp/org-feed.el...

[BUG] Failing tests for ob-clojure

[Ihor Radchenko]

Hi,

I am now going through all the babel tests that are disabled by default.

ob-clojure tests appear to be completely broken:

1. (org-test-for-executable "cider") assertion is strange as cider
   package does not have any executable.

2. All the tests seems to assert that ob-clojure supports sessions,
   while it does not seem to be the case.

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

[Jens Schmidt]

On 2023-08-24  09:32, Ihor Radchenko wrote:
> Jens Schmidt  writes:

>> Some obvious choice would be a simpler single backslash
>>
>>   (B) "\-" => "-"
> 
> I prefer (B). And we will need to allow escaping of the "\" itself. Like
> \\.

OK.  Since backslash is not used yet in the rest of the regexp, (B)
should be rather edge-case-free.  So the corresponding subre to match
property names would look like

  \(?5:\(?:[[:alnum:]]+\|\\[^[:space:]]\)+\)

IOW, backslash quotes everything except whitespace, which by definition
cannot be part of a property name.

Will start on this, but with tests and documentation this might take
some time.

Re: Programmable deadline repeater

[Ihor Radchenko]

gus...@riseup.net writes:

> Is it possible to configure a TODO item with a repeating deadline or
> schedule to use a function to set the new timestamp when completed,
> instead of just increasing of a fixed number of hours, days, weeks,
> etc.?

See `org-todo-repeat-hook'.

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

Re: plantuml tikz format support

[Ihor Radchenko]

Nan JunJie  writes:

> I'd like to add a patch to support plantuml tikz format. We can use it
> like this:
>
> #+begin_src plantuml :file file.tikz
> ...
> #+end_src
>
> #+results:
> [[file.tikz]]
>
> So that file.tikz will be treat as tikz picture and input.

Thanks!
This looks reasonable. May you also update etc/ORG-NEWS and
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html
page, documenting the changes. The Worg page source live in
https://git.sr.ht/~bzg/worg

Another possibility could be supporting :results latex header argument
and output a latex export block.

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

Re: [BUG] HTML export locale problem [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

em...@supporter.mailer.me writes:

>  Today I was exporting my org file to HTML and I have run into an issue 
>  with #+LANGUAGE. 
>  I have set it to to "pl" and the Table of Contents name has changed, but 
>  the figure names did not. 
>  
>  Can somebody guide me on how could I fix it? 

This is because we do not have all the terms translated to Polish.
I invite you to look into `org-export-dictionary' variable and submit a
patch with the missing translations. Or just an email, listing Polish
names for untranslated terms.

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

Re: [BUG] emergency exit [9.6.6 (release_9.6.6 @ /opt/homebrew/Cellar/emacs-mac/emacs-29.1-mac-10.0/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Jay Dixit  writes:

> ⛔ Warning (org-element-cache): org-element--cache: Got empty parent while
> parsing. Please report it to Org mode mailing list (M-x
> org-submit-bug-report).
>  Backtrace:
> nil

May you update Org to the latest stable Org 9.6.8 version and let us
know if the error persists?

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

Re: [BUG] org-element--cache: Org parser error (error "rx '**' range error") [9.7 (9.7-??-d6f3aed7b @ /Users/fbartik/.config/emacs/.local/straight/build-29.1/org/)]

[Ihor Radchenko]

fb--- via "General discussions about Org-mode." 
writes:

> I'm very new to Emacs and org and I'm running into this issue when I 
> start Emacs from scratch and reload my last session.
>
> The error I get looks like this and there are multiples on each start:
>
> Warning (org-element-cache): org-element--cache: Org parser error in 
> config.el::5943. Resetting.
>   The error was: (error "rx '**' range error")
>   Backtrace:
> nil
>
> I'm sure there are issues with my configuration, which is pasted below.  
> This is because I'm using the Doom Emacs framework as well as snippets 
> of other users' configurations.

This error usually happens when something is trying to call Org API in
non-Org buffer. For example, https://github.com/nobiot/md-roam is known
to do this.

May you M-x toggle-debug-on-error, trigger the error, and then share the
backtrace that will be displayed?

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

Re: How to solve "Warning (emacs): Please update the LaTeX src-block-backend to listings"

[Ihor Radchenko]

Guillaume MULLER  writes:

> I'm trying to create a code block with some latex code to be interpreted 
> inside. I only knew lstlistings until now. Page 
> https://orgmode.org/manual/Source-blocks-in-LaTeX-export.html lists Engraved 
> and Minted as possible backend. 
> https://list.orgmode.org/87wnf1z1w8@gmail.com/T/ also lists verbatim.
>
> So from what I understand, of the message "Warning (emacs): Please update the 
> LaTeX src-block-backend to listings", is that the default backend is not 
> lstlistings and that there is a variable somewhere that should be set to 
> lstlistings.

Yes. `org-latex-src-block-backend'.
I now updated the warning to be more explicit.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=85c94ecfc

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

Jens Schmidt  writes:

>> When "TAG1-TAG2" is an actual tag name with dash, we may allow escaping.
>
> But I'd like to clarify that.  From the Org syntax
>
>   https://orgmode.org/worg/org-syntax.html#Headings
>
> I understood that tag names cannot contain minus characters,
> and `org-tag-re' does not match any, either.  So we are talking
> about property names only, right?

You are right.

> Then the question is what quoting scheme to use for property
> names.  The previous one used before my commit f689eb4
>
>   (A) "\\-" => "-"
>
> never has been documented and never has been working properly,
> since the *matching* of these was done on *prop* names, but
> the *unescaping* on *tag* names.  So we are basically free to
> come up with something new.
>
> Some obvious choice would be a simpler single backslash
>
>   (B) "\-" => "-"

I prefer (B). And we will need to allow escaping of the "\" itself. Like
\\.

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

Jens Schmidt  writes:

> Yet another edge-case: In the Org syntax definition a property
> name is really delimited by a "colon-whitespace" sequence.  This
> takes out the ambiguity whether a property name is defined
> non-greedily
>
>   :[^[:space:]]+?:
>
> or greedily
>
>   :[^[:space:]]+:
>
> I'm too lazy right now to think about the consequences, but I
> hope this makes a difference only for really weird property
> matches, like this:
>
>   :foo:=1+:bar:=2

Thus, -1 to this idea with ":" delimiter. If possible, we should avoid
edge cases. Otherwise, we are getting rid of the edge case with "-" by
introducing yet another edge case.

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

Re: org-cite: how to force a reparsing of the .bib file

[Ihor Radchenko]

Leo Butler  writes:

>> Does the attached patch fix the problem?
>
> ...
> To avoid an unneeded setq, I applied the patch:
>
>   (dolist (file (mapcar #'file-truename 
> (org-cite-list-bibliography-files)))

This would create an extra list and increase GC pressure. So, I prefer setq.

> This caused the bibtex file to be re-parsed when I changed it.

Thanks for testing!
Applied.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3c3db7b33

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

Re: [PATCH] Fix docstring of `org-at-timestamp-p'

[Ihor Radchenko]

Liu Hui  writes:

> I find that the doc string of `org-at-timestamp-p' about match groups
> is not consistent with the behavior. The doc string says
>
> ...
> but for timestamps like <2023-08-23 Wed>, (when (org-at-timestamp-p)
> (match-string 2)) will return the year 2023 instead of the month. This
> patch corrects the group numbers.

Thanks!
Applied, onto bugfix, adding slightly more details to the commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=973e50c83

The docstring did not correspond to the actual match data since group
info was added there. So, no actual regression in the code occurred.
Pure bug in the docstring. That's why bugfix.

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

[BUG] org-element--cache: Org parser error (error "rx '**' range error") [9.7 (9.7-??-d6f3aed7b @ /Users/fbartik/.config/emacs/.local/straight/build-29.1/org/)]

[General discussions about Org-mode.]

Hi,

I'm very new to Emacs and org and I'm running into this issue when I 
start Emacs from scratch and reload my last session.


The error I get looks like this and there are multiples on each start:

Warning (org-element-cache): org-element--cache: Org parser error in 
config.el::5943. Resetting.

 The error was: (error "rx '**' range error")
 Backtrace:
nil

I'm sure there are issues with my configuration, which is pasted below.  
This is because I'm using the Doom Emacs framework as well as snippets 
of other users' configurations.


Thanks for any advice,
Franta Bartik

Emacs  : GNU Emacs 29.1 (build 2, x86_64-apple-darwin22.6.0, NS 
appkit-2299.70 Version 13.5 (Build 22G74))

 of 2023-08-10
Package: Org mode version 9.7 (9.7-??-d6f3aed7b @ 
/Users/fbartik/.config/emacs/.local/straight/build-29.1/org/)


current state:
==
(setq
 org-link-elisp-confirm-function nil
 org-directory "~/syncthing/org/"
 org-after-todo-state-change-hook '(log-todo-next-creation-date)
 org-after-refile-insert-hook '(save-buffer)
 org-indirect-buffer-display 'current-window
 org-roam-db-gc-threshold 2305843009213693951
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-log-done 'time
 org-roam-mode-hook '(+org-roam-detach-magit-section-mode-map-h 
turn-on-visual-line-mode)

 org-agenda-custom-commands '(("g" "Get Things Done (GTD)"
   ((agenda ""
 ((org-agenda-skip-function
   '(org-agenda-skip-entry-if 
'deadline))

  (org-deadline-warning-days 0))
 )
(todo "NEXT"
 ((org-agenda-skip-function
   '(org-agenda-skip-entry-if 
'deadline))
  (org-agenda-prefix-format "  %i %-12:c 
[%e] ")
  (org-agenda-overriding-header 
"\nTasks\n"))

 )
(agenda nil
 ((org-agenda-entry-types '(:deadline))
  (org-agenda-format-date "") 
(org-deadline-warning-days 7)

  (org-agenda-skip-function
   '(org-agenda-skip-entry-if 'notregexp 
"\\* NEXT"))
  (org-agenda-overriding-header 
"\nDeadlines"))

 )
(tags-todo "inbox"
 ((org-agenda-prefix-format "  %?-12t% 
s")
  (org-agenda-overriding-header 
"\nInbox\n"))

 )
(tags "CLOSED>=\"\""
 ((org-agenda-overriding-header 
"\nCompleted today\n")))

)
   )
  )
 org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h
 +org-init-attachments-h +org-init-babel-h 
+org-init-babel-lazy-loader-h

 +org-init-capture-defaults-h +org-init-capture-frame-h
 +org-init-custom-links-h +org-init-export-h 
+org-init-habit-h
 +org-init-hacks-h +org-init-keybinds-h 
+org-init-popup-rules-h

 +org-init-smartparens-h +org-init-roam-h)
 org-startup-folded nil
 org-babel-after-execute-hook 
'(+org-redisplay-inline-images-in-babel-result-h)

 org-link-abbrev-alist '(("doomdir" . "/Users/fbartik/.config/doom/%s")
 ("emacsdir" . 
"/Users/fbartik/.config/emacs/%s")
 ("doom-repo" . 
"https://github.com/doomemacs/doomemacs/%s;)
 ("wolfram" . 
"https://wolframalpha.com/input/?i=%s;)
 ("wikipedia" . 
"https://en.wikipedia.org/wiki/%s;)

 ("duckduckgo" . "https://duckduckgo.com/?q=%s;)
 ("gmap" . "https://maps.google.com/maps?q=%s;)
 ("gimages" . "https://google.com/images?q=%s;)
 ("google" . "https://google.com/search?q=;)
 ("youtube" . "https://youtube.com/watch?v=%s;)
 ("github" . "https://github.com/%s;))
 org-agenda-files '("~/git/organised-exchange/exchange.org"
"/Users/fbartik/syncthing/org/inbox.org"
"/Users/fbartik/syncthing/org/agenda.org"
"/Users/fbartik/syncthing/org/projects.org"
"/Users/fbartik/syncthing/org/work.org")
 org-capture-templates '(("i" "Inbox" entry (file 
"~/syncthing/org/inbox.org")

  "* TODO %?\n/Entered on/ %U")
 ("s" "Slipbox" entry (file 
"~/syncthing/org/org-roam/inbox.org")

  "* %?\n/Entered on/ %U")
   

Programmable deadline repeater

[gustek]

Good day,

Is it possible to configure a TODO item with a repeating deadline or
schedule to use a function to set the new timestamp when completed,
instead of just increasing of a fixed number of hours, days, weeks,
etc.?

Regards,
Gustek

plantuml tikz format support

[Nan JunJie]

I'd like to add a patch to support plantuml tikz format. We can use it
like this:

#+begin_src plantuml :file file.tikz
...
#+end_src

#+results:
[[file.tikz]]

So that file.tikz will be treat as tikz picture and input.

Here the patch:

>From c97e5f421202ac2bfd16174c2d4be4059b0aa4c8 Mon Sep 17 00:00:00 2001
From: Nan Jun Jie 
Date: Wed, 23 Aug 2023 20:23:40 +0800
Subject: [PATCH] Add plantuml tikz tex support

Via the use of plantuml -tlatex:nopreamble option, tikz tex can be
\input in the export latex, so that it will be compiled as tikz
picture, just like the png or svg format.
---
 lisp/ob-plantuml.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index 3202c6e41..b5cc9322e 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -143,6 +143,7 @@ This function is called by `org-babel-execute-src-block'."
("eps" '("-teps"))
("pdf" '("-tpdf"))
("tex" '("-tlatex"))
+   ("tikz" '("-tlatex:nopreamble"))
("vdx" '("-tvdx"))
("xmi" '("-txmi"))
("scxml" '("-tscxml"))
-- 
2.40.1



-- 
 ∧ ∧︵
ミ^ō^ミ灬)～
https://nanjj.github.io

[BUG] HTML export locale problem [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[emacs]

Hello everyone, 
 
 Today I was exporting my org file to HTML and I have run into an issue 
 with #+LANGUAGE. 
 I have set it to to "pl" and the Table of Contents name has changed, but 
 the figure names did not. 
 
 Can somebody guide me on how could I fix it? 
 
 Kind regards 
Emacs User

 Info: 
 Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.17.8)
 Package: Org mode version 9.6.6 (release_9.6.6 @ 
/usr/share/emacs/29.1/lisp/org/)