Emacs slow-down

2024-03-06 Thread Pedro Andres Aranda Gutierrez
Hi

is it just me, or have other people also noticed hiccups when editing org
files with org-mode (main from savannah). The moment I revert to the
org-mode shipped with emacs master, editing returns to normal (and fluid).

Would it make sense to take a closer look at this?

Best, /PA
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet


Re: R session error (org-babel)

2024-03-06 Thread William Denton
On Wednesday, March 6th, 2024 at 05:56, Esteban Venialgo  
wrote:

> I tried the =emacs -Q=, and still get the same problem. Before exporting the 
> code, I ran this lisp from the scratch pad:
> 
> ;; enable language support for R
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((R . t)
> (shell . t)
> (latex . t)
> (emacs-lisp . nil)))

Hmm! It does work for me.  I'm on Ubuntu 22.04, running Emacs and Org from the 
development tree (so 30.0.50 and 9.7-pre).

I ran =emacs -Q= (and also =make repro= from in the Org source tree, which is 
another useful tool for testing), and executed these lines in a scratch buffer:

# -
(org-babel-do-load-languages 'org-babel-load-languages '(
 (R . t)
 (shell . t)
 ))
(add-to-list 'load-path "~/.emacs.d/elpa/ess-20240229.2054") 
(require 'ess-r-mode)
# -

We're the same up to ESS.  (I had to check the version number on ESS to get the 
path right, but that's the latest release installed.)  Looking back, did you 
not mention using ESS?  I've never used R in Emacs without it.  If you weren't 
using ESS, what happens if you install it and use it? 

Just for the sake of documentation: then I made an r.org file with the snippet 
and ran it, and it worked:

# 
#+begin_src R :session test
  A <- 1
#+end_src
#


Cheers,

Bill

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



[BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

2024-03-06 Thread Paul Stansell
Hello,

It seems that using ":var d=data" breaks ":colnames yes" in the header of
an R code block.

In the example below the first code block uses ":colnames yes" and gives
the correct output, the second code block uses ":var d=data" to read the
data in the table (although it read the header as data), and the third code
uses both ":colnames yes" and ":var d=data" but gives the error "Wrong type
argument: sequencep, hline".

Thanks,

Paul

# = Start example =
#+name: data
|+|
|  x |  y |
|+|
| 111.89 |  88.37 |
| 392.12 | 297.33 |
|+|

This code block works as expected.
#+begin_src R --no-save --no-restore :colnames yes
  data.frame(x=1, y=2)
#+end_src

#+RESULTS:
| x | y |
|---+---|
| 1 | 2 |


This code block shows that the data in the table can be read (although
the table header is read as data).
#+begin_src R --no-save --no-restore :var d=data
  d
#+end_src

#+RESULTS:
|  x |  y |
| 111.89 |  88.37 |
| 392.12 | 297.33 |


However, using both ":colnames yes" and ":var d=data" together gives
an error "Wrong type argument: sequencep, hline"
#+begin_src R --no-save --no-restore :colnames yes :var d=data
  data.frame(x=1, y=2)
#+end_src
# = End example =



Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
 of 2023-08-16, modified by Debian
Package: Org mode version 9.7-pre (release_9.6.10-881-g595a32 @
/home/ps/.emacs.d_Kubuntu-23.04/org-mode-git/lisp/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-startup-folded t
 org-id-link-to-org-use-id t
 org-mode-hook '((closure
  (org-agenda-skip-regexp org-fold-core-style
org-table1-hline-regexp
   org-table-tab-recognizes-table\.el
org-table-dataline-regexp
   org-table-any-border-regexp
org-agenda-restriction-lock-overlay
   org-agenda-overriding-restriction org-agenda-diary-file
   org-complex-heading-regexp calendar-mode-map t)
  nil (setq imenu-create-index-function
'org-imenu-get-tree))
 (closure
  (org--rds reftex-docstruct-symbol org-attach-method
   org--single-lines-list-is-paragraph
org-element-greater-elements
   org-agenda-restrict-end org-agenda-restrict-begin
org-agenda-restrict
   visual-fill-column-width org-clock-history
org-agenda-current-date
   org-with-time org-defdecode org-def
org-read-date-inactive org-ans2
   org-ans1 org-columns-current-fmt-compiled
org-clock-current-task
   org-clock-effort org-agenda-skip-function
org-agenda-skip-comment-trees
   org-agenda-archives-mode org-end-time-was-given
org-time-was-given
   org-log-note-extra org-log-note-purpose
org-log-post-message
   org-last-inserted-timestamp org-last-changed-timestamp
   org-entry-property-inherited-from org-state
   org-agenda-headline-snapshot-before-repeat
org-agenda-buffer-name
   org-agenda-start-on-weekday org-agenda-buffer-tmp-name
   org-priority-regexp org-mode-abbrev-table
org-element-cache-persistent
   org-element-cache-version buffer-face-mode-face
org-tbl-menu org-org-menu
   org-struct-menu org-entities org-last-state
org-id-track-globally
   org-clock-start-time texmathp-why remember-data-file
   org-agenda-tags-todo-honor-ignore-options
calc-embedded-open-mode
   calc-embedded-open-formula calc-embedded-close-formula
   align-mode-rules-list org-emphasis-alist
org-emphasis-regexp-components
   org-export-registered-backends org-modules crm-separator
   org-babel-load-languages org-id-overriding-file-name
   org-indent-indentation-per-level
org-element--timestamp-regexp
   org-element-cache-map-continue-from
org-element-paragraph-separate
   org-agenda-buffer-name org-inlinetask-min-level t)
  nil (add-hook 'change-major-mode-hook 'org-fold-show-all
'append 'local))
 (closure
  (org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no
   org-babel-tangle-uncomment-comments org-src-lang-modes
   

Re: noweb-start and noweb-end header args

2024-03-06 Thread Amy Grinn
Amy Grinn  writes:

> Ihor Radchenko  writes:
>
>> Amy Grinn  writes:
>>
>>> I would like to add support for setting 'org-babel-noweb-wrap-start and
>>> 'org-babel-noweb-wrap-end for each src block individually
>>
>> May you please explain the use case when changing the default values
>> is useful?
>
> Of course!  Changing the default values can be useful to prevent syntax
> highlighting errors in a specific language.  In the example I gave, <<<
> and >>> aren't recognized as the beginning of a heredoc in a shell
> script the way <> would be.

To expand on this, some major modes can fundamentally conflict with the
default noweb syntax.  Here is a valid shell script *and* a valid noweb
reference to a block named EOF:

cat <> file.txt
Hello
EOF

I hope this helps explain why the wrap-start and wrap-end options were
necessary to include more than a decade ago.  In terms of actually using
them, it's a bit cumbersome, especially in Org mode buffers that use
multiple languages.

The second diff I sent (under the termux handle, accidentally) is my
preferred solution (:noweb yes <<< >>>).  This would avoid the need for
new header arguments to be introduced while maintaining backwards
compatibility.  It also feels natural to specify the two options
together: I can't think of a good reason to only need to specify the
wrap-end option.



Re: To avoid zero width space: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Juan Manuel Macías
Max Nikulin writes:

> However to produce clean export result  elements should not be
> added if no attributes are specified. My expectation is
>
> "
> Example of intraword markup
> "

With the latest commit now the anonymous variant without attributes
simply returns the content (in LaTeX, HTML and odt). You can try:

&_{/lorem/}&_{*ipsum*}&_{_dolor_}

==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}

==> HTML loremipsumdolor

==> ODT loremipsumdolor


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía




[BUG] ob-shell async incorrect table and value results

2024-03-06 Thread Matt
#+name: sync table
#+begin_src sh :session *test* :results table
echo "hello world"
#+end_src

#+RESULTS:
| hello world |

#+name: async table
#+begin_src sh :session *test* :results table :async t
echo "hello world"
#+end_src

#+RESULTS:
: hello world

#+name: sync value
#+begin_src sh :session *test* :results value
echo "hello world"
#+end_src

#+RESULTS:
: 0

#+name: async value
#+begin_src sh :session *test* :results value :async t
echo "hello world"
#+end_src

#+RESULTS:
: hello world
: 0

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode





Re: To avoid zero width space: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Juan Manuel Macías
Max Nikulin writes:

> However to produce clean export result  elements should not be
> added if no attributes are specified. My expectation is
>
> "
> Example of intraword markup
> "

It seems like a good idea to me. Currently, in LaTeX:

&_{lorem ipsum dolor} ==> LaTeX ==> lorem ipsum dolor

It can also be extended to html, odt and the rest of the backends.

That is, by default, the anonymous variant without attributes simply
returns the content.

Another possibility (with the current implementation):

#+options: inline-special-block-aliases:(("b" :html-tag "b")("i" :html-tag "i"))

{intra}{word}

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía



Bug: file names capitalised when using gnuplot [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

2024-03-06 Thread Paul Stansell
Hello,

A bug occurs when plotting data from an Org table using Gnuplot.  An
example is given below.  In the first code block the plot is produced as
expected, but in the second code block (where I have changed a lowercase
"c" to an uppercase "C") gnuplot tries to plot data from a
non-existent file name that consists of all uppercase letters.

Thanks,

Paul

# = Start example =
#+name: data
|+|
|  x |  y |
|+|
| 111.89 |  88.37 |
| 392.12 | 297.33 |
|+|

This code block works.  It tries to read the data from
"/tmp/babel-stable-462/gnuplot--633772447824105179", which exists.
#+begin_src gnuplot :var c=data :results silent
  reset session
  plot "$c" u 1:2
#+end_src

This code block does not work.  It tries to read the data from
"/TMP/BABEL-STABLE-462/GNUPLOT-2096937058546578295", which does not
exist.
#+begin_src gnuplot :var C=data :results silent
  reset session
  plot "$C" u 1:2
#+end_src
# = End example =



current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-id-link-to-org-use-id t
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-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-clock-persist 'history
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-clock-history-length 28
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-file-apps '((auto-mode . emacs) ("\\.odt\\'" . "libreoffice %s")
 ("\\.docx\\'" . "libreoffice %s") ("\\.xlsx\\'" .
"libreoffice %s")
 ("\\.png\\'" . "xv %s") ("\\.jpg\\'" . "xv %s")
("\\.jpeg\\'" . "xv %s")
 ("\\.webp\\'" . "xv %s") ("\\.pdf\\'" . "okular \"%s\"")
 ("\\.xoj" . "xournal %s") ("\\.xopp" . "xournalpp %s"))
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-hide-leading-stars t
 org-babel-load-languages '((R . t) (emacs-lisp . t) (gnuplot . t) (octave
. t) (python . t)
(fortran . t) (sql . t) (ditaa . t) (dot . t)
(shell . t))
 org-log-done 'time
 org-highlight-latex-and-related '(latex)
 org-occur-hook '(org-first-headline-recenter)
 org-log-into-drawer t
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-todo-keywords '((sequence "TODO(t!)" "MAYBE(m!)" "STARTED(s!)"
"WAITING(w@/!)" "|"
  "DONE(d)" "INFO(i!)" "CANCELLED(c@)" "UNFINISHED(u@)"
"ABANDONED(a@)")
 )
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-babel-tangle-lang-exts '(("fortran" . "F90") ("python" . "py")
("emacs-lisp" . "el")
  ("elisp" . "el"))
 org-format-latex-options '(:foreground "Yellow" :background default :scale
1.2
:html-foreground "Black" :html-background
"Transparent"
:html-scale 1.07 :matchers ("begin" "$1" "$"
"$$" "\\(" "\\["))
 org-clock-display-default-range 'untilnow
 org-confirm-shell-link-function 'yes-or-no-p
 org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
   ("eww" :follow eww :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)
   ("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)
  

To avoid zero width space: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Max Nikulin

On 02/03/2024 03:34, Juan Manuel Macías wrote:


Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:




The new feature is promising as an alternative for U+200B zero width 
space as an escape character (info "(org) Escape Character"). It may 
adjusted to allow really plain text markup instead of a character 
invisible by default:


(org-export-string-as "Example of &_{*intra*}&_{/word/} markup"
  'html
  '(:export-options (body-only)))
"
Example of intraword markup
"

However to produce clean export result  elements should not be 
added if no attributes are specified. My expectation is


"
Example of intraword markup
"

Earlier discussions:

- Denis Maier. Org-syntax: Intra-word markup. Thu, 2 Dec 2021 11:50:32 
+0100. 
https://list.orgmode.org/4897bc60-b74f-ccfd-e13e-9b89a1194...@mailbox.org
- Juan Manuel Macías. On zero width spaces and Org syntax. Fri, 03 Dec 
2021 12:48:16 +. https://list.orgmode.org/87ilw5yhv3@posteo.net
- Vincent Belaïche. RE: [RFC] Creole-style / Support for 
**emphasis**__within__**a word** Mon, 24 Jan 2022 10:50:10 +. 
https://list.orgmode.org/paxpr06mb809350c21e7c75a2a110c52984...@paxpr06mb8093.eurprd06.prod.outlook.com






Re: noweb-start and noweb-end header args

2024-03-06 Thread Amy Grinn
Ihor Radchenko  writes:

> Amy Grinn  writes:
>
>> How much does org mode modify the fontification for an indirect buffer?
>> Without having looked into it, I assume not much or at all.
>> ... I think
>> that approach could be more complex, especially when dealing with a
>> theoretically infinite number of major modes.
>
> Org mode does not _currently_ modify the code. But that's actually wrong
> - things like escaped ,* or indentation sometimes also stay on the way
> and produce incorrect fontification. So, rewriting the fontification of
> src blocks to cleanup the code before fontification is long due.
> noweb references is just another manifestation of this problem.

I think we're talking past each other a little.  I'm not talking about
changing the text content of a src block, I'm talking about modifying
the syntax table of a major mode such as sh-mode to ignore or handle
<> syntax in an "edit-special" buffer.  That was my
interpretation of your suggestion of using fontification to solve this
issue.  And if that's the case, I foresee a lot of edge cases for
modifying the display of major modes.

>> Both solutions could be implemented at the same time.  We could build on
>> the existing functionality of the wrap-end and wrap-start variables
>> while also looking at ways to modify the syntax highlighting without
>> user intervention.
>
> I am not in favor of adding features that aim to serve as workarounds to
> Org mode.

This discussion is not about whether to allow users to modify noweb
syntax.  That feature is already a part of Org, well documented, and
utilized.  The feature request I'm making is to allow that modification
to be done on a per-block level.



Re: smallcaps: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Juan Manuel Macías
Max Nikulin writes:

> OK, just consider it as my dissenting opinion. I believe that it should
> be possible for the same Org document
>
>#+options: inline-special-block-aliases:(("definition" :smallcaps t))
>
>{Example} or &_[:smallcaps t]{ad-hoc}
>
> to export it as
>
>Example
>or ad-hoc
>
> or as
>
>Example
>or ad-hoc
>
> by adjusting of global settings. The former one be suitable for a CMS
> that does not allow user CSS and the latter one is preferable for a site
> under full user control and having CSS
>
>.definition, .small-capps { font-variant: small-caps; }

With the current implementation this:

#+options: inline-special-block-aliases:(("definition" :smallcaps t))

{Example}

produces:

Example

:smallcaps simply adds a (say) direct formatting layer. I am not a fan
of any form of direct formatting. But, as I already said, I think that
these types of global attributes can be useful for users who do not want
to bother with predefining styles, classes or commands in
odt/html/LaTeX, or because they do not know how to do it. They simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).

I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
necessary, but perhaps other users think differently.

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía



Re: Provide sane default for the @direntry

2024-03-06 Thread Stefan Monnier
> The patches are against Emacs git repository, not against Org mode. May
> your please port them?

See attached.

>> Subject: [PATCH 1/2] * lisp/org/ox-texinfo.el: Remove redundant `:group`s
> By our convention, we drop leading * in the first line of the commit message.

Done.

>> * lisp/org/ox-texinfo.el (texinfo): Add entry for TEXINFO_DIR_NAME.
>> (org-texinfo-template): Use sane defaults for `@direntry` and `@dircategory`.
>> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.
> * etc/ORG-NEWS changelog entry is missing.

Hmm... did know you needed them.

>> +- =TEXINFO_DIR_NAME= ::
>> +
>> +  #+cindex: @samp{TEXINFO_DIR_NAME}, keyword
>> +  The directory name of the document.
>> +  This is the short name under which the ~m~ command will find your
>> +  manual in the main Info directory.  It defaults to the base name of
>> +  the Texinfo file.
>> +
>> +  The full form of the Texinfo entry is ~* DIRNAME: NODE.~ where ~NODE~
>> +  is usually just ~(FILENAME)~.  Normally this option only provides the
>> +  ~DIRNAME~ part, but if you need more control, it can also be the full
>> +  entry (recognized by the presence of parentheses or a leading ~* ~).
>>  
>>  - =TEXINFO_DIR_TITLE= ::
>>  
>>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
>> -  The directory title of the document.
>> +  Old and obsolete name of the =TEXINFO_DIR_NAME= option.
>
> We can simply remove TEXINFO_DIR_TITLE from the manual.

Fair enough.

> Also, please update "Info directory file" section. In particular,
> references to TEXINFO_DIR_TITLE.

Indeed, thanks for spotting this.

>> +(dn (or (plist-get info :texinfo-dirname)
>> +(plist-get info :texinfo-dirtitle))) ;Obsolete name.
>> +;; Strip any terminating `.' from `dn'.
>> +(dn (if (string-match "\\.\\'" dn) (substring dn 0 -1) dn))
>
> `string-match' will throw an error when both :texinfo-dirname and
> :texinfo-dirtitle records are not provided (nil).

Duh!


Stefan
>From ae03b9fa16599eae15a13167d7158266640e76fc Mon Sep 17 00:00:00 2001
From: Stefan Monnier 
Date: Tue, 5 Mar 2024 14:11:19 -0500
Subject: [PATCH 1/2] lisp/ox-texinfo.el: Remove redundant `:group`s

---
 lisp/ox-texinfo.el | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index bd01effaa6..ef46dafff2 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -147,12 +147,10 @@
   "Default document encoding for Texinfo output.
 
 If nil it will default to `buffer-file-coding-system'."
-  :group 'org-export-texinfo
   :type 'coding-system)
 
 (defcustom org-texinfo-default-class "info"
   "The default Texinfo class."
-  :group 'org-export-texinfo
   :type '(string :tag "Texinfo class"))
 
 (defcustom org-texinfo-classes
@@ -205,7 +203,6 @@ The sectioning structure of the class is given by the elements
 following the header string.  For each sectioning level, a number
 of strings is specified.  A %s formatter is mandatory in each
 section string and will be replaced by the title of the section."
-  :group 'org-export-texinfo
   :version "27.1"
   :package-version '(Org . "9.2")
   :type '(repeat
@@ -233,7 +230,6 @@ TEXT  the main headline text (string).
 TAGS  the tags as a list of strings (list of strings or nil).
 
 The function result will be used in the section format string."
-  :group 'org-export-texinfo
   :type 'function
   :version "26.1"
   :package-version '(Org . "8.3"))
@@ -244,38 +240,32 @@ The function result will be used in the section format string."
   "Column at which to start the description in the node listings.
 If a node title is greater than this length, the description will
 be placed after the end of the title."
-  :group 'org-export-texinfo
   :type 'integer)
 
  Timestamps
 
 (defcustom org-texinfo-active-timestamp-format "@emph{%s}"
   "A printf format string to be applied to active timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-inactive-timestamp-format "@emph{%s}"
   "A printf format string to be applied to inactive timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
 (defcustom org-texinfo-diary-timestamp-format "@emph{%s}"
   "A printf format string to be applied to diary timestamps."
-  :group 'org-export-texinfo
   :type 'string)
 
  Links
 
 (defcustom org-texinfo-link-with-unknown-path-format "@indicateurl{%s}"
   "Format string for links with unknown path type."
-  :group 'org-export-texinfo
   :type 'string)
 
  Tables
 
 (defcustom org-texinfo-tables-verbatim nil
   "When non-nil, tables are exported verbatim."
-  :group 'org-export-texinfo
   :type 'boolean)
 
 (defcustom org-texinfo-table-scientific-notation nil
@@ -285,7 +275,6 @@ The format should have \"%s\" twice, for mantissa and exponent
 \(i.e. \"%stimes10^{%s}\").
 
 When nil, no transformation is made."
-  :group 'org-export-texinfo
   :type '(choice
 	  (string :tag "Format string")
 	  (const 

cannot export asynchronously because of org-fold-core--update-buffer-folds

2024-03-06 Thread Alan Schmitt
Hello,

I’m trying to export a file asynchronously to beamer/pdf, and I have a
strange error. Here is the contents of the *Org Export Process* buffer:

Debugger entered--Lisp error: (void-function org-fold-core--update-buffer-folds)
  org-fold-core--update-buffer-folds()
  #f(compiled-function () #)()
  funcall(#f(compiled-function () #))
  (progn nil (progn (setq kill-emacs-hook nil) (setq 
org-babel-confirm-evaluate-answer-no t)) (require 'ox) (funcall 
'#f(compiled-function () #)) 
(restore-buffer-modified-p nil) (print (let ((output (org-export-as 'beamer nil 
nil nil '(:output-file "slides.tex" (let ((temp-buffer (generate-new-buffer 
" *temp*" t))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect 
(progn (insert output) (if ... nil ...) (let ... ...)) (and (buffer-name 
temp-buffer) (kill-buffer temp-buffer) (or (condition-case nil (progn 
(funcall 'org-latex-compile "slides.tex")) (error nil)) "slides.tex"
  (unwind-protect (progn nil (progn (setq kill-emacs-hook nil) (setq 
org-babel-confirm-evaluate-answer-no t)) (require 'ox) (funcall 
'#f(compiled-function () #)) 
(restore-buffer-modified-p nil) (print (let ((output (org-export-as 'beamer nil 
nil nil '...))) (let ((temp-buffer (generate-new-buffer " *temp*" t))) 
(save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn ... ... 
...) (and ... ... (or (condition-case nil (progn (funcall ... 
"slides.tex")) (error nil)) "slides.tex" (and (buffer-name temp-buffer) 
(kill-buffer temp-buffer)))
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn nil 
(progn (setq kill-emacs-hook nil) (setq org-babel-confirm-evaluate-answer-no 
t)) (require 'ox) (funcall '#f(compiled-function () #)) (restore-buffer-modified-p nil) (print (let ((output 
(org-export-as ... nil nil nil ...))) (let ((temp-buffer ...)) 
(save-current-buffer (set-buffer temp-buffer) (unwind-protect ... ...))) (or 
(condition-case nil (progn ...) (error nil)) "slides.tex" (and (buffer-name 
temp-buffer) (kill-buffer temp-buffer
  (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current-buffer 
(set-buffer temp-buffer) (unwind-protect (progn nil (progn (setq 
kill-emacs-hook nil) (setq org-babel-confirm-evaluate-answer-no t)) (require 
'ox) (funcall '#f(compiled-function () #)) 
(restore-buffer-modified-p nil) (print (let ((output ...)) (let (...) 
(save-current-buffer ... ...)) (or (condition-case nil ... ...) 
"slides.tex" (and (buffer-name temp-buffer) (kill-buffer temp-buffer)
  
load-with-code-conversion("/private/var/folders/p6/3p2365qn1dx08q33rqwnr2hh00..."
 "/private/var/folders/p6/3p2365qn1dx08q33rqwnr2hh00..." nil t)
  command-line-1(("-l" "/Users/schmitta/work/skeletons/research/talks/Effe..." 
"-l" "/var/folders/p6/3p2365qn1dx08q33rqwnr2hhgn/T/o..."))
  command-line()
  normal-top-level()

To make sure I have a reproducible export, I set
org-export-async-init-file to a file with the following contents:

;;; export-init.el --- description -*- lexical-binding: t; -*-

;;; Commentary:

;;; Code:

(setq-default indent-tabs-mode nil)
(setq debug-on-error t)

(require 'ox-latex)

(add-to-list 'org-latex-classes
 '("my-beamer"
   "\\documentclass\[presentation,aspectratio=169\]\{beamer\}
[NO-DEFAULT-PACKAGES]"
   ("\\section\{%s\}" . "\\section*\{%s\}")
   ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
   ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))

(require 'ox-beamer)

(setq org-latex-listings 'minted)

(setq org-latex-pdf-process
  '("latexmk -pdflatex='%latex --shell-escape -8bit' -pdf -quiet %f"))

(setq org-export-async-debug t)

(provide 'export-init)
;;; export-init.el ends here


I assume the problem is that there is a version mismatch between the org
I’m using to start the export and the org in the async process, but I do
not understand how they would interact. In particular, I don’t
understand why there is a mention of byte-compiled code in the error
trace.

If it matters, the emacs with which I’m initializing the export with is
started with the --init-directory option.

How can I track where this error comes from?

Thanks,

Alan


signature.asc
Description: PGP signature


Re: noweb-start and noweb-end header args

2024-03-06 Thread Ihor Radchenko
Amy Grinn  writes:

>> This sounds like XY problem then.
>> If the real problem you want to solve is fontification, we may instead
>> adjust Org mode fontification of source blocks to exclude noweb
>> references.
>
> I see a problem with multiple possible solutions, some more involved
> than others.  The org-babel-noweb-wrap-* variables are already
> customizeable and, in researching a solution to this problem, I have
> found users who set these variables on a file or directory-local level
> already.

Yup. And most of these customizations are aiming to solve the
fontification problem. If we did not have the problem to start with,
re-defining the noweb wrap syntax would be unnecessary in many cases.

> How much does org mode modify the fontification for an indirect buffer?
> Without having looked into it, I assume not much or at all.
> ... I think
> that approach could be more complex, especially when dealing with a
> theoretically infinite number of major modes.

Org mode does not _currently_ modify the code. But that's actually wrong
- things like escaped ,* or indentation sometimes also stay on the way
and produce incorrect fontification. So, rewriting the fontification of
src blocks to cleanup the code before fontification is long due.
noweb references is just another manifestation of this problem.

> Both solutions could be implemented at the same time.  We could build on
> the existing functionality of the wrap-end and wrap-start variables
> while also looking at ways to modify the syntax highlighting without
> user intervention.

I am not in favor of adding features that aim to serve as workarounds to
Org mode.

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



Re: Feature request: IDs for everything

2024-03-06 Thread Tor Erlend Fjelde
Oh, that's great news! Will be very useful; thanks Ihor!

Unfortunately life has come in the way so I haven't had the chance to pursue 
this further at the moment.

All the best,
Tor

On Wed, 06/03/2024, Ihor Radchenko  wrote:

> Tor Erlend Fjelde  writes:
>
>>> As an alternative option, we had a proposal that extends id: links to
>>> have a search option:
>>>
>>>  [[id:::search-string]]
>> ...
>> Indeed; I was actually about to have a go at implementing this because
>> I thought this would be the quickest way of adding support for referencing
>> blocks in something like org-roam. But this does seem like a sub-optimal
>> solution vs. just adding support for more general IDs, and so I thought
>> it would be better to see if that could be done first (hence I'm here).
>
> FYI, we added [[id:::search-string]] links to the latest development
> version of Org mode. This new feature does not cover global ids for
> non-headings though.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



Re: noweb-start and noweb-end header args

2024-03-06 Thread Amy Grinn
Ihor Radchenko  writes:

> Amy Grinn  writes:
>
 #+name: firewall
 #+begin_src sh  :noweb yes :noweb-start <<< :noweb-end >>>
>>>
>>> May you please explain the use case when changing the default values
>>> is useful?
>>
>> Of course!  Changing the default values can be useful to prevent syntax
>> highlighting errors in a specific language.  In the example I gave, <<<
>> and >>> aren't recognized as the beginning of a heredoc in a shell
>> script the way <> would be.
>
> This sounds like XY problem then.
> If the real problem you want to solve is fontification, we may instead
> adjust Org mode fontification of source blocks to exclude noweb
> references.

I see a problem with multiple possible solutions, some more involved
than others.  The org-babel-noweb-wrap-* variables are already
customizeable and, in researching a solution to this problem, I have
found users who set these variables on a file or directory-local level
already.

How much does org mode modify the fontification for an indirect buffer?
Without having looked into it, I assume not much or at all.  I think
that approach could be more complex, especially when dealing with a
theoretically infinite number of major modes.

Both solutions could be implemented at the same time.  We could build on
the existing functionality of the wrap-end and wrap-start variables
while also looking at ways to modify the syntax highlighting without
user intervention.



Re: Feature request: IDs for everything

2024-03-06 Thread Ihor Radchenko
Tor Erlend Fjelde  writes:

>> As an alternative option, we had a proposal that extends id: links to
>> have a search option:
>>
>>  [[id:::search-string]]
> ...
> Indeed; I was actually about to have a go at implementing this because
> I thought this would be the quickest way of adding support for referencing
> blocks in something like org-roam. But this does seem like a sub-optimal
> solution vs. just adding support for more general IDs, and so I thought
> it would be better to see if that could be done first (hence I'm here).

FYI, we added [[id:::search-string]] links to the latest development
version of Org mode. This new feature does not cover global ids for
non-headings though.

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



Re: noweb-start and noweb-end header args

2024-03-06 Thread Ihor Radchenko
Amy Grinn  writes:

>>> #+name: firewall
>>> #+begin_src sh  :noweb yes :noweb-start <<< :noweb-end >>>
>>
>> May you please explain the use case when changing the default values
>> is useful?
>
> Of course!  Changing the default values can be useful to prevent syntax
> highlighting errors in a specific language.  In the example I gave, <<<
> and >>> aren't recognized as the beginning of a heredoc in a shell
> script the way <> would be.

This sounds like XY problem then.
If the real problem you want to solve is fontification, we may instead
adjust Org mode fontification of source blocks to exclude noweb
references.

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



Re: noweb-start and noweb-end header args

2024-03-06 Thread Amy Grinn
Ihor Radchenko  writes:

> Amy Grinn  writes:
>
>> I would like to add support for setting 'org-babel-noweb-wrap-start and
>> 'org-babel-noweb-wrap-end for each src block individually using the
>> header args :noweb-start and :noweb-end:
>> ...
>> #+name: firewall
>> #+begin_src sh  :noweb yes :noweb-start <<< :noweb-end >>>
>
> May you please explain the use case when changing the default values
> is useful?

Of course!  Changing the default values can be useful to prevent syntax
highlighting errors in a specific language.  In the example I gave, <<<
and >>> aren't recognized as the beginning of a heredoc in a shell
script the way <> would be.



Re: noweb-start and noweb-end header args

2024-03-06 Thread Ihor Radchenko
Amy Grinn  writes:

> I would like to add support for setting 'org-babel-noweb-wrap-start and
> 'org-babel-noweb-wrap-end for each src block individually using the
> header args :noweb-start and :noweb-end:
> ...
> #+name: firewall
> #+begin_src sh  :noweb yes :noweb-start <<< :noweb-end >>>

May you please explain the use case when changing the default values is useful?

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



Re: Provide sane default for the @direntry

2024-03-06 Thread Ihor Radchenko
Stefan Monnier  writes:

> New version of the patch, which I believe address your comments.

Thanks!
The patches are against Emacs git repository, not against Org mode. May
your please port them?
See some more minor comments inline.

> Subject: [PATCH 1/2] * lisp/org/ox-texinfo.el: Remove redundant `:group`s

By our convention, we drop leading * in the first line of the commit message.

> ...
> * lisp/org/ox-texinfo.el (texinfo): Add entry for TEXINFO_DIR_NAME.
> (org-texinfo-template): Use sane defaults for `@direntry` and `@dircategory`.
>
> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.

* etc/ORG-NEWS changelog entry is missing.

> +- =TEXINFO_DIR_NAME= ::
> +
> +  #+cindex: @samp{TEXINFO_DIR_NAME}, keyword
> +  The directory name of the document.
> +  This is the short name under which the ~m~ command will find your
> +  manual in the main Info directory.  It defaults to the base name of
> +  the Texinfo file.
> +
> +  The full form of the Texinfo entry is ~* DIRNAME: NODE.~ where ~NODE~
> +  is usually just ~(FILENAME)~.  Normally this option only provides the
> +  ~DIRNAME~ part, but if you need more control, it can also be the full
> +  entry (recognized by the presence of parentheses or a leading ~* ~).
>  
>  - =TEXINFO_DIR_TITLE= ::
>  
>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
> -  The directory title of the document.
> +  Old and obsolete name of the =TEXINFO_DIR_NAME= option.

We can simply remove TEXINFO_DIR_TITLE from the manual.

Also, please update "Info directory file" section. In particular,
references to TEXINFO_DIR_TITLE.
  
> + (dn (or (plist-get info :texinfo-dirname)
> + (plist-get info :texinfo-dirtitle))) ;Obsolete name.
> + ;; Strip any terminating `.' from `dn'.
> + (dn (if (string-match "\\.\\'" dn) (substring dn 0 -1) dn))

`string-match' will throw an error when both :texinfo-dirname and
:texinfo-dirtitle records are not provided (nil).

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



Re: R session error (org-babel)

2024-03-06 Thread Esteban Venialgo
hi Bill,

I tried the =emacs -Q=, and still get the same problem. Before exporting the 
code, I ran this lisp from the scratch pad:

;; enable language support for R
(org-babel-do-load-languages
 'org-babel-load-languages
 '((R . t)
   (shell . t)
   (latex . t)
   (emacs-lisp . nil)))

(setq load-path '("~/.emacs.d/lisp/" "/etc/emacs" "/usr/share/emacs/site-lisp" 
"/usr/share/emacs/site-lisp/auctex" "/usr/share/emacs/site-lisp/auto-complete" 
"/usr/share/emacs/site-lisp/color-theme" 
"/usr/share/emacs/site-lisp/company-mode" "/usr/share/emacs/site-lisp/counsel" 
"/usr/share/emacs/site-lisp/dictionary" "/usr/share/emacs/site-lisp/elpy" 
"/usr/share/emacs/site-lisp/ess" 
"/usr/share/emacs/site-lisp/highlight-indentation" 
"/usr/share/emacs/site-lisp/ivy" "/usr/share/emacs/site-lisp/lua-mode" 
"/usr/share/emacs/site-lisp/matlab" "/usr/share/emacs/site-lisp/org-mode" 
"/usr/share/emacs/site-lisp/popup" "/usr/share/emacs/site-lisp/python-mode" 
"/usr/share/emacs/site-lisp/pyvenv" "/usr/share/emacs/site-lisp/s" 
"/usr/share/emacs/site-lisp/site-gentoo.d" "/usr/share/emacs/site-lisp/swiper" 
"/usr/share/emacs/site-lisp/which-key" "/usr/share/emacs/site-lisp/xclip" 
"/usr/share/emacs/site-lisp/yasnippet" 
"/usr/share/emacs/site-lisp/color-theme/themes" "/usr/share/emacs/29.2/lisp" 
"/usr/share/emacs/29.2/lisp/vc" "/usr/share/emacs/29.2/lisp/use-package" 
"/usr/share/emacs/29.2/lisp/url" "/usr/share/emacs/29.2/lisp/textmodes" 
"/usr/share/emacs/29.2/lisp/progmodes" "/usr/share/emacs/29.2/lisp/play" 
"/usr/share/emacs/29.2/lisp/org" "/usr/share/emacs/29.2/lisp/nxml" 
"/usr/share/emacs/29.2/lisp/net" "/usr/share/emacs/29.2/lisp/mh-e" 
"/usr/share/emacs/29.2/lisp/mail" "/usr/share/emacs/29.2/lisp/leim" 
"/usr/share/emacs/29.2/lisp/language" 
"/usr/share/emacs/29.2/lisp/international" "/usr/share/emacs/29.2/lisp/image" 
"/usr/share/emacs/29.2/lisp/gnus" "/usr/share/emacs/29.2/lisp/eshell" 
"/usr/share/emacs/29.2/lisp/erc" "/usr/share/emacs/29.2/lisp/emulation" 
"/usr/share/emacs/29.2/lisp/emacs-lisp" "/usr/share/emacs/29.2/lisp/cedet" 
"/usr/share/emacs/29.2/lisp/calendar" "/usr/share/emacs/29.2/lisp/calc" 
"/usr/share/emacs/29.2/lisp/obsolete"))

btw, what emacs version are you using? and OS? Also, when you exported the 
code, did you set up org-babel-load-languages to run R?

My system details are:
Gentoo Linux
I tried GNU Emacs 29.2 and 28.2
org-mode version 9.6.17

   Thanks for your help, 





On 2024-03-06 06:21:10, William Denton wrote:
> On Tuesday, March 5th, 2024 at 09:12, Esteban Venialgo  
> wrote:
> 
> > I'm a newbie with org-babel, but I think I'm facing a bug for R code 
> > execution. Basically, I have a simple code for testing:
> > 
> > #+begin_src R :session test
> > A = 1
> > #+end_src
> > 
> > I get a lisp error when I try to export this code to latex. Also, if I 
> > remove the session name "test", the code will run in the second attempt. 
> > I'm using Emacs version 28.2 and org-mode version 9.6.17.
> 
> I can't help understand the error message, but I did try the R sample and 
> have no problem running it and exporting it.  I suspect it might be something 
> about your local setup.  Could you try starting with =emacs -Q= and loading 
> in Org and enough else to run the R snippet?  How to get started with that is 
> here:
> 
> https://orgmode.org/manual/Feedback.html
> 
> It doesn't cover getting R working, but we can help with that.  I can look 
> for a snippet of code if you need one.
> 
> Cheers,
> 
> Bill
> 
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
> 
> 



Re: smallcaps: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Max Nikulin

On 06/03/2024 00:28, Juan Manuel Macías wrote:

Max Nikulin escribió:
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.


OK, just consider it as my dissenting opinion. I believe that it should 
be possible for the same Org document


  #+options: inline-special-block-aliases:(("definition" :smallcaps t))

  {Example} or &_[:smallcaps t]{ad-hoc}

to export it as

  Example
  or ad-hoc

or as

  Example
  or ad-hoc

by adjusting of global settings. The former one be suitable for a CMS 
that does not allow user CSS and the latter one is preferable for a site 
under full user control and having CSS


  .definition, .small-capps { font-variant: small-caps; }




Re: naming: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Ihor Radchenko
Max Nikulin  writes:

>> Custom inline markup.
>
> "Markup" is something abstract to my taste. I would prefer something 
> related to concrete instances of such objects.

IMHO, the whole point of the discussed construct is exactly being abstract
and multi-purpose.

> Decorators sometimes stressed as "inline decorators"?

I dislike "decorators" because it is not a term we use anywhere in Org
mode. I'd prefer to reuse an existing term, if at all possible.

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



Re: [FR] multiple column view definition

2024-03-06 Thread Ihor Radchenko
Slawomir Grochowski  writes:

>> It looks like you are asking for a way to choose between multiple column
>> specs when building column view. And that you have a very specific idea
>> how to implement it. However, the details of the idea are elusive to me.
>> May you elaborate?
>
> Sure.
>
> We have two COLUMNS definition:
>
> * 2024
> :PROPERTIES:
> :COLUMNS:  %ITEM(B) %TEST(B column)
> :COLUMNS:  %ITEM(A) %TEST(A column)
> :END:

This is ambiguous in Org mode property syntax. You cannot specify
property multiple times like this. No wonder you are getting undefined
and unexpected behaviour.

> ...
> Or maybe someone has a better idea how to implement the functionality
> 'multiple column view definition'? 

What you might do is hack `org-columns-get-format' to not default to
`org-columns-default-format', but instead ask user about the column
format to be used. For example, you can utilize
`org-property-get-allowed-values' and prompt user about the column
format to choose. Then, COLUMNS_ALL property may store multiple allowed
formats like:

* 2024
:PROPERTIES:
:COLUMNS_ALL:  "%ITEM(B) %TEST(B column)"
:COLUMNS_ALL+:  "%ITEM(A) %TEST(A column)"
:END:

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



Re: naming: Re: Experimental public branch for inline special blocks

2024-03-06 Thread Max Nikulin

On 05/03/2024 00:29, Ihor Radchenko wrote:

Max Nikulin writes:


Does anybody have an idea of a better name for a feature? Maybe
something like inline custom objects, snippets. "Objects" are used to
describe syntax, but not used in the manual though.


Custom inline markup.


"Markup" is something abstract to my taste. I would prefer something 
related to concrete instances of such objects.


Decorators sometimes stressed as "inline decorators"?





Re: org id link to arbitrary place in an org file

2024-03-06 Thread Ihor Radchenko
Samuel Wales  writes:

> i know we talked about something like this recently, perhaps related
> to inline tasks, perhaps not.  apologies redundancy.
>
> i'd like to have an org-id link to a place in a different file.  a
> paragraph or even more arbitrary.
>
> is this possible with current org technology?  [i think recent
> discussion did not mention id markers.]

On the latest main, after adding search option support for ID links, it
should be possible to link to named places in arbitrary Org file.

For example, one can link to a paragraph like

:PROPERTIES:
:ID:   3824e050-801e-422a-9312-6628f4153941
:END:

#+name: paragraph-name
This is a paragraph.

The link will be

[[id:3824e050-801e-422a-9312-6628f4153941::paragraph-name]]

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



Re: R session error (org-babel)

2024-03-06 Thread Ihor Radchenko
Esteban Venialgo  writes:

> hi Org-people,
>
> I'm a newbie with org-babel, but I think I'm facing a bug for R code 
> execution. Basically, I have a simple code for testing:
> ...
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   org-babel-R-initiate-session...

As William pointed, it does look like some mis-configuration of ESS.
However, I am concerned about the obscurity of the error.
May you try testing with the latest development version of Org mode? (I
do hope that the error is less cryptic there)

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



Re: [BUG] org-mobile: Arguments of expand-file-name are flipped [9.6.20 ( @ /home/fb/.config/emacs/elpa/org-9.6.20/)]

2024-03-06 Thread Ihor Radchenko
Fabian Brosda  writes:

> just a very small issue I found, as I was wondering, why the agendas
> file was included in the index, although it did not exist.
>
> The problem is in org-mobile.el in Line 473, as the arguments to
> expand-file-name are in the wrong order:
>
> (when (file-exists-p (expand-file-name
>   org-mobile-directory "agendas.org"))
>

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

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



Re: nested blocks in org

2024-03-06 Thread Ihor Radchenko
mahmood sheikh  writes:

> with the given minimal example:
> ```
> #+begin_parent
> #+begin_child
> #+end_child
> #+end_parent
> ```
> the code
> ```lisp
> (org-block-map (lambda () (message "elem: %s" (org-element-at-point
> ```
> goes through only the parent element and doesnt run the lambda on the
> child block
> the docstring of org-block-map says it iterates through src blocks but
> it also goes through special blocks, albeit not nested ones, i
> might've confused it for org-element-map as im not sure about the
> later functions behavior.

This is a bug in `org-block-map'.

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