Re: R session error (org-babel)

[William Denton]

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: noweb-start and noweb-end header args

[termux]

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:

Here's another possible syntax we could use:

:noweb  [wrap-start] [wrap-end]

#+name: message
#+begin_src elisp
  "Firewall is now in safe mode."
#+end_src

#+name: firewall-safe-mode
#+begin_src sh :noweb yes
  echo <>
#+end_src

#+name: firewall
#+begin_src sh :noweb yes <<< >>>
  safe_mode () {
  echo "Error encountered, switching to safe mode."
  <<>>
  exit 1
  }
#+end_src

#+begin_src sh :noweb yes ":-) " " (-:" :tangle "test.sh"
  # Setup firewall
  :-) firewall (-:

  # Do other things
#+end_src

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 4dcfbd3b0..f60b4be12 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -194,15 +194,20 @@ This string must include a \"%s\" which will be replaced by the results."
   :package-version '(Org . "9.1")
   :safe #'booleanp)
 
-(defun org-babel-noweb-wrap ( regexp)
+(defun org-babel-noweb-wrap ( regexp info)
   "Return regexp matching a Noweb reference.
 
 Match any reference, or only those matching REGEXP, if non-nil.
 
 When matching, reference is stored in match group 1."
-  (concat (regexp-quote org-babel-noweb-wrap-start)
-	  (or regexp "\\([^ \t\n]\\(?:.*?[^ \t\n]\\)?\\)")
-	  (regexp-quote org-babel-noweb-wrap-end)))
+  (let ((noweb (mapcar
+(lambda (token)
+  (if (stringp token) token (symbol-name token)))
+(org-babel-read
+ (format "'(%s)" (cdr (assq :noweb (nth 2 info
+(concat (regexp-quote (or (nth 1 noweb) org-babel-noweb-wrap-start))
+	(or regexp "\\([^ \t\n]\\(?:.*?[^ \t\n]\\)?\\)")
+	(regexp-quote (or (nth 2 noweb) org-babel-noweb-wrap-end)
 
 (defvar org-babel-src-name-regexp
   "^[ \t]*#\\+name:[ \t]*"
@@ -3116,7 +3121,7 @@ block but are passed literally to the \"example-block\"."
   (not (equal (cdr v) "no"))
 	 (noweb-re (format "\\(.*?\\)\\(%s\\)"
 			   (with-current-buffer parent-buffer
-			 (org-babel-noweb-wrap)
+			 (org-babel-noweb-wrap nil info)
 (unless (equal (cons parent-buffer
  (with-current-buffer parent-buffer
(buffer-chars-modified-tick)))

Re: Provide sane default for the @direntry

[Stefan Monnier]

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


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

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

diff --git a/lisp/org/ox-texinfo.el b/lisp/org/ox-texinfo.el
index 84313645e6e..b3b94511d50 100644
--- a/lisp/org/ox-texinfo.el
+++ b/lisp/org/ox-texinfo.el
@@ -147,12 +147,10 @@ org-texinfo-coding-system
   "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 @@ org-texinfo-classes
 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 @@ org-texinfo-format-headline-function
 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 @@ org-texinfo-node-description-column
   "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 @@ org-texinfo-table-scientific-notation
 \(i.e. \"%stimes10^{%s}\").
 
 When nil, no transformation is made."
-  :group 'org-export-texinfo
   :type '(choice
 	  (string :tag "Format string")
 	  (const :tag "No formatting" nil)))
@@ -297,7 +286,6 @@ org-texinfo-table-default-markup
 \"@samp\".
 
 It can be overridden locally using the \":indic\" attribute."
-  :group 'org-export-texinfo
   :type 'string
   :version "26.1"
   :package-version '(Org . "9.1")
@@ -323,7 +311,6 @@ org-texinfo-text-markup-alist
 
 When no association is found for a given markup, text is returned
 as-is."
-  :group 'org-export-texinfo
   :version "26.1"
   :package-version '(Org . "9.1")
   :type 'alist
@@ -341,7 +328,6 @@ org-texinfo-format-drawer-function
 The function should return the string to be exported.
 
 The default function simply returns the value of CONTENTS."
-  :group 'org-export-texinfo
   :version "24.4"
   :package-version '(Org . "8.2")
   :type 'function)
@@ -361,7 +347,6 @@ org-texinfo-format-inlinetask-function
   CONTENTS  the contents of the inlinetask, as a string.
 
 The function should return the string to be exported."
-  :group 'org-export-texinfo
   :type 'function)
 
  LaTeX
@@ -374,7 +359,6 @@ org-texinfo-with-latex
 respectively.  Alternatively, when set to `detect', the exporter
 does so only if the installed version of Texinfo supports the
 necessary commands."
-  :group 'org-export-texinfo
   :package-version '(Org . "9.6")
   :type '(choice
   (const :tag "Detect" detect)
@@ -391,7 +375,6 @@ org-texinfo-compact-itemx
 transcoded to `@itemx'.  See info node `(org)Plain lists in
 Texinfo export' for how to enable this for individual lists."
   :package-version '(Org . "9.6")
-  :group 'org-export-texinfo
   :type 'boolean
   :safe t)
 
@@ -406,7 +389,6 @@ org-texinfo-info-process
 base name (i.e. without directory and extension parts), %o by the
 base directory of the file and %O by the absolute file name of
 the output file."
-  :group 'org-export-texinfo
   :version "26.1"
   :package-version '(Org . "9.1")
   :type '(repeat :tag "Shell command sequence"
@@ -416,8 +398,8 @@ 

noweb-start and noweb-end header args

[Amy Grinn]

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-safe-mode
#+begin_src sh
  echo "Firewall is now in safe mode."
#+end_src

#+name: firewall
#+begin_src sh  :noweb yes :noweb-start <<< :noweb-end >>>
  safe_mode () {
  echo "Error encountered, switching to safe mode."
  <<>>
  exit 1
  }

  setup-firewall || safe_mode
#+end_src

#+begin_src sh :noweb yes :noweb-start ":-) " :noweb-end " (-:" :tangle 
"test.sh"
  # Setup firewall
  :-) firewall (-:

  # Do other things
#+end_src


Here is a simple way to implement this feature.

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 4dcfbd3b0..0be19ff06 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -194,15 +194,17 @@ This string must include a \"%s\" which will be replaced by the results."
   :package-version '(Org . "9.1")
   :safe #'booleanp)
 
-(defun org-babel-noweb-wrap ( regexp)
+(defun org-babel-noweb-wrap ( regexp info)
   "Return regexp matching a Noweb reference.
 
 Match any reference, or only those matching REGEXP, if non-nil.
 
 When matching, reference is stored in match group 1."
-  (concat (regexp-quote org-babel-noweb-wrap-start)
+  (concat (regexp-quote (or (cdr (assq :noweb-start (nth 2 info)))
+org-babel-noweb-wrap-start))
 	  (or regexp "\\([^ \t\n]\\(?:.*?[^ \t\n]\\)?\\)")
-	  (regexp-quote org-babel-noweb-wrap-end)))
+	  (regexp-quote (or (cdr (assq :noweb-end (nth 2 info)))
+org-babel-noweb-wrap-end
 
 (defvar org-babel-src-name-regexp
   "^[ \t]*#\\+name:[ \t]*"
@@ -3116,7 +3118,7 @@ block but are passed literally to the \"example-block\"."
   (not (equal (cdr v) "no"))
 	 (noweb-re (format "\\(.*?\\)\\(%s\\)"
 			   (with-current-buffer parent-buffer
-			 (org-babel-noweb-wrap)
+			 (org-babel-noweb-wrap nil info)
 (unless (equal (cons parent-buffer
  (with-current-buffer parent-buffer
(buffer-chars-modified-tick)))

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

[Fabian Brosda]

Hi,

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

Linking to the exact spot on github:
https://github.com/bzg/org-mode/blob/main/lisp/org-mobile.el#L473

Would be great, if someone could fix this. All other uses of
expand-file-name in there seem to be fine.

Best regards

Fabian

Emacs  : GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.40, 
cairo version 1.18.0)
Package: Org mode version 9.6.20 ( @ /home/fb/.config/emacs/elpa/org-9.6.20/)

R session error (org-babel)

[Esteban Venialgo]

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:

#+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. The lisp error log is bellow:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  org-babel-R-initiate-session("test" ((:colname-names) (:rowname-names) 
(:result-params "silent" "replace") (:result-type . value) (:results . 
"silent") (:exports . "code") (:session . "test") (:tangle . "no") (:hlines . 
"no") (:noweb . "no") (:cache . "no")))
  org-babel-execute:R("A = 1" ((:colname-names) (:rowname-names) 
(:result-params "silent" "replace") (:result-type . value) (:results . 
"silent") (:exports . "code") (:session . "test") (:tangle . "no") (:hlines . 
"no") (:noweb . "no") (:cache . "no")))
  org-babel-execute-src-block(nil ("R" "A = 1" ((:colname-names) 
(:rowname-names) (:result-params "silent" "replace") (:result-type . value) 
(:results . "silent") (:exports . "code") (:cache . "no") (:noweb . "no") 
(:hlines . "no") (:tangle . "no") (:session . "test")) "" nil 1 "(ref:%s)"))
  org-babel-exp-results(("R" "A = 1" ((:colname-names) (:rowname-names) 
(:result-params "replace") (:result-type . value) (:results . "replace") 
(:exports . "code") (:session . "test") (:tangle . "no") (:hlines . "no") 
(:noweb . "no") (:cache . "no")) "" nil 1 "(ref:%s)") block silent)
  #f(compiled-function (info type) #)(("R" "A = 1" 
((:colname-names) (:rowname-names) (:result-params "replace") (:result-type . 
value) (:results . "replace") (:exports . "code") (:session . "test") (:tangle 
. "no") (:hlines . "no") (:noweb . "no") (:cache . "no")) "" nil 1 "(ref:%s)") 
block)
  org-babel-exp-do-export(("R" "A = 1" ((:colname-names) (:rowname-names) 
(:result-params "replace") (:result-type . value) (:results . "replace") 
(:exports . "code") (:session . "test") (:tangle . "no") (:hlines . "no") 
(:noweb . "no") (:cache . "no")) "" nil 1 "(ref:%s)") block nil)
  org-babel-exp-src-block((src-block (:language "R" :switches nil :parameters 
":session test" :begin 1 :end 47 :number-lines nil :preserve-indent nil 
:retain-labels t :use-labels t :label-fmt nil :value "  A = 1\n" :post-blank 0 
:post-affiliated 1 :mode top-comment :granularity element :cached t :parent 
(section (:begin 1 :end 47 :contents-begin 1 :contents-end 47 :robust-begin 1 
:robust-end 45 :post-blank 0 :post-affiliated 1 :mode first-section 
:granularity element :cached t :parent (org-data (:begin 1 :contents-begin 1 
:contents-end 47 :end 47 :robust-begin 3 :robust-end 45 :post-blank 0 
:post-affiliated 1 :path "/home/esteban/test.org" :mode org-data :CATEGORY 
"test" :cached t)))
  org-babel-exp-process-buffer()
  org-export-as(latex nil nil nil (:output-file "test.tex"))
  org-export-to-file(latex "test.tex" nil nil nil nil nil org-latex-compile)
  org-latex-export-to-pdf(nil nil nil nil)
  org-export-dispatch(nil)
  funcall-interactively(org-export-dispatch nil)
  call-interactively(org-export-dispatch record nil)
  command-execute(org-export-dispatch record)
  counsel-M-x-action("org-export-dispatch")
  ivy-call()
  ivy-read("M-x " [ess-create-temp-buffer table--measure-max-width 
vc-src-responsible-p calendar-forward-week tramp-sudoedit-file-name-handler 
tramp-completion-handle-file-name-all-completions Set\ Slice 
make-mode-line-mouse-map table-source-caption-history Reduce\ To:\ to\ Cc: 
ido-prev-match help-follow-symbol ess-long+replacement 
japanese-hiragana-two-byte gnus-article-nndoc-name 
org-export-before-processing-functions rng-parse-validate-file 
senator-eldoc-use-color speedbar-file-regexp ess-keyword-face 
org-table--descriptor-line Rnw-mode message-expand-name-databases 
info--manual-names 0 nnoo-map-functions gnus-try-warping-via-registry 
compilation-error-list displ-string *table--cell-kill-paragraph 
:odt-styles-file vc-annotate all-packs org-table-get-range vc-bzr-shelve-menu 
rng-match-infer-start-tag-namespace 0 org-agenda-regexp-filter-preset 
gnus-summary-limit-to-marks org-agenda-menu-show-matcher hs-toggle-hiding 0 
article-fill-long-lines smime-buffer-as-string-region org-get-org-file 
check-declare Info-breadcrumbs counsel--async-filter bibtex-text-in-string ! 
...] :predicate #f(compiled-function (sym) #) 
:require-match t :history counsel-M-x-history :action counsel-M-x-action 
:keymap (keymap (67108908 . counsel--info-lookup-symbol) (67108910 . 
counsel-find-symbol)) :initial-input nil :caller counsel-M-x)
  counsel-M-x()
  funcall-interactively(counsel-M-x)
  call-interactively(counsel-M-x nil nil)
  command-execute(counsel-M-x)
  
Thanks for your help, tetumetal

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

[Juan Manuel Macías]

Max Nikulin  escribió:

> If some type is used through the document multiple times then it is 
> better to avoid style="font-variant:small-caps" and use a CSS class 
> instead. Even for LaTeX it may be better to define a dedicated command 
> to be closer to semantic markup.
>
> Moreover different decorations may be used in LaTeX and HTML. Some type 
> may be typed in small caps in LaTeX, but in HTML it may use regular font 
> and some color.

The "global attribute" concept implies that there should be (ideally)
the same result in all possible backends (naturally, if the output is
plain text, :color doesn't make much sense). Global attributes are a
quick and easy (for the user) way to create direct formatting, analogous
to the LaTeX commands \textcolor, \textsc, etc. Its casual use is the
most recommended, in my opinion. Let's imagine that a user wants to
color segments of text, in the same color, for LaTeX and odt, and does
not want to bother with predefined styles or macros in odt and LaTeX
respectively.

If a segment of text must have a different appearance, for example, in
LaTeX (small caps) and HTML (red color), you can put:

&_[:html style="color:red;" :prelatex \scshape{}]{text}

And if one wants to have more robust control, for example because many
text segments must have a certain treatment in HTML, odt or LaTeX,
styles, classes and macros can always be defined in the output format.
Additionally, there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.

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.

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

smallcaps: Re: Experimental public branch for inline special blocks

[Max Nikulin]

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

│ Caesar's famous quote: ![:smallcaps t :color blue]{Alea iacta est}
==> LaTeX:
│ Caesar's famous quote: 
{\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
== HTML:
│ Caesar's famous quote: Alea iacta est


I am in doubts if smallcaps should be hardcoded. From my point of view, 
current implementation is unnecessary rigid. In this particular example 
:smallcaps is an ad-hoc property. I would expect its usage through an 
alias definition, e.g.


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

If some type is used through the document multiple times then it is 
better to avoid style="font-variant:small-caps" and use a CSS class 
instead. Even for LaTeX it may be better to define a dedicated command 
to be closer to semantic markup.


Moreover different decorations may be used in LaTeX and HTML. Some type 
may be typed in small caps in LaTeX, but in HTML it may use regular font 
and some color.


Perhaps an e.g. user-configurable and extensible alist of types with 
per-backend properties should be used instead.


A portion of wisdom how to represent small caps for each export backend 
may be handy, but accessing it should be more flexible.

Re: [FR] multiple column view definition

[Slawomir Grochowski]

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

#+BEGIN: columnview :hlines 1
|A | A column |
|--+--|
| 2024 |  |
#+END:

When and run `org-columns' on that heading it will display column view
using :COLUMNS: definition from bottom. ':COLUMNS:  %ITEM(A) %TEST(A column)'. 
The definition on top ':COLUMNS:  %ITEM(B) %TEST(B column)' is ignored. 

The function to get the :COLUMN: definition to display is (org-entry-get nil 
"COLUMNS" t).

Based on that behavior I made a simple function:

(defun org-columns-switch-columns ()
  (interactive)
  (save-excursion
(org-columns-goto-top-level)
(re-search-forward ":COLUMNS:")
(org-metadown)
(org-columns)))

So it's just to move :COLUMNS: definition from top to bottom. And run
`org-columns'. It works fine. 

The problem is when I want to modify the :COLUMNS: definition.
In e.g.  

* 2024
:PROPERTIES:
:COLUMNS:  %ITEM(B) %TEST(B column)
:COLUMNS:  %ITEM(A) %TEST(A column)
:END:

It will display ':COLUMNS:  %ITEM(A) %TEST(A column)'

#+BEGIN: columnview :hlines 1
|A | A column |
|--+--|
| 2024 |  (put cursor here and run org-columns-delete) |
#+END:

It will modify the ':COLUMNS:  %ITEM(B) %TEST(B column)'. 
So :COLUMNS: definition from top not from bottom. 

The function to modify :COLUMNS: definition is (org-entry-put nil "COLUMNS" 
fmt).
So this is the problem.

So in my opinion (org-entry-put nil "COLUMNS" fmt) should modify the
:COLUMNS: definition from bottom (the last one) not from top (the first one).  

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

-- 
Slawomir Grochowski

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

[Suhail Singh]

Suhail Singh  writes:

> ... due to the similarity with "inline code blocks" (cf. "code
> blocks") as well as "special blocks".

.. due to the /relation/ with "inline code blocks" (cf. "code blocks")
as well as "special blocks".

> But if it were to, I do hope the names of other similar syntactic
> terms are similarly updated.

But if it were to, I do hope the names of other /related/ syntactic
terms are similarly updated.

-- 
Suhail

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

[Suhail Singh]

Ihor Radchenko  writes:

> In my mind, "fragment" implies no nesting.

FWIW, in the mind of this Org mode user as well.

> But the point of the "inline special blocks" is to allow nesting as
> needed.

Yes, exactly!  As "inline code blocks" are to "code blocks" so too are
"inline special blocks" to "special blocks".

I generally try and abstain from bike-shedding, but as a data point, the
intent of "inline special blocks" was quite clear to me based on the
name alone.  This was, in no small part, due to the similarity with
"inline code blocks" (cf. "code blocks") as well as "special blocks".

I hope the name of this "syntactic object", when incorporated into Org
mode, doesn't change.  But if it were to, I do hope the names of other
similar syntactic terms are similarly updated.

-- 
Suhail

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

[Juan Manuel Macías]

Max Nikulin writes:

> Special blocks are really block-level elements. I see similarity,
> however with a better term we could avoid "inline" specifier. I think,
> the new beast may serve in some cases currently handled by macros.
> LaTeX snippets are named "fragments" in the manual.
>
> Custom fragment?

I think "custom" is an important part of defining the new object. Unlike
other elements/objects, such as emphasis marks, this one does not add
any (let's say) "logical or semantic" information. I mean, emphasis
marks (to continue with the example) are useful when reading an Org
document as it is. But the new object is rather a segment of text that
must be exported in a certain way to LaTeX, odt, HTML, etc. Something
like "{some text}" does not provide any information to the reader,
but rather to the exporters and the output format. So, how about
something like:

- Custom Export Fragment

- Custom Export Span

- Custom Export "Whatever"

- ...

?

(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).

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

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Ihor Radchenko]

Stefan  writes:

> since this patch was applied, there are now two functions in 
> `org-store-link-functions` that feel responsible for id links from some 
> buffers: the new `org-id-store-link-maybe` and `org-contacts-link-store`.
>
> This results in a prompt asking which one to use, which happens many times, 
> e.g., when exporting agendas with org-contacts stuff in them.
>
> Not sure how to improve/avoid that, though. 

Org mode does not add the two functions there. It is likely something
inside your config.

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

[mahmood sheikh]

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.

On Sat, Feb 17, 2024 at 7:44 PM Ihor Radchenko  wrote:
>
> [ Adding Org list back to CC; please use Reply All or wide reply to keep
>   the discussion public ]
>
> mahmood sheikh  writes:
>
> > consider the following block
> > ```
> > #+begin_solution
> > #+begin_src sql
> >   SELECT
> > CONCAT(c.first_name, ' ', c.family_name) AS name, c.customer_id,
> > ...
> > #+end_solution
> > ```
> > the src block isnt fontified by org because it is inside another block
>
> ... which is just a bug in the Org fontification code.
> If you try M-: (org-element-at-point) , you will see that Org does
> recognize the code block.
>
> So ...
>
> > can you point me in the right direction of getting org mode to recognize
> > nested blocks,
>
> Org already recognizes nested blocks using Org element parser. See
> https://orgmode.org/worg/dev/org-element-api.html
>
> > ... like code highlighting for src blocks that are within
> > another special block?
>
> See https://list.orgmode.org/87ee7c9quk.fsf@localhost/
> This is something we are working in.
> To get parser-aware fontification locally, you can use a function
> MATCHER (as in font-lock-keywords docstring) and invoke
> `org-element-at-point' there to check context.
>
> > ... and getting org-element-map to iterate through both
> > a parent and its child blocks all the same?
>
> May you elaborate? `org-element-map' iterates through everything,
> including nested parent and child blocks. What did you try?
>
> > could modifying `org-block-regexp` to be a recursive regex be of help?
>
> Sorry, but it is hard to see how this is related to `org-element-map'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Stefan]

Hi,

since this patch was applied, there are now two functions in 
`org-store-link-functions` that feel responsible for id links from some 
buffers: the new `org-id-store-link-maybe` and `org-contacts-link-store`.

This results in a prompt asking which one to use, which happens many times, 
e.g., when exporting agendas with org-contacts stuff in them.

Not sure how to improve/avoid that, though. 

Best,
 Stefan

Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien  writes:
>
>> Adding [BLOG] or [TIP] in the subject prefix allows for such messages
>> to be referenced on https://tracker.orgmode.org/news (along with [ANN]
>> messages). 
>>
>> It will then be possible to include these posts in the orgmode.org
>> homepage, using e.g. https://tracker.orgmode.org/news.rss.
>>
>> This is experimental, let's see if this helps spread the word about
>> useful blogs.
>
> I am looking at https://tracker.orgmode.org/news and I feel that mixing
> blog/tip entries with important announcements may not be very good idea.
> May we put the blogs into a separate tab, leaving announcements stand
> out?

Yes, this is a possibility.

> Also, I do not see
> https://list.orgmode.org/877cihmr45@posteo.net/T/#u listed.
> May it be because in "[tip] Export to PDF with latexmk 'continuous
> preview' option", "tip" is lowercase?

This should not be case-sensitive - I will check when I have some free
time.

-- 
 Bastien Guerry

Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix

[Ihor Radchenko]

Bastien  writes:

> Adding [BLOG] or [TIP] in the subject prefix allows for such messages
> to be referenced on https://tracker.orgmode.org/news (along with [ANN]
> messages). 
>
> It will then be possible to include these posts in the orgmode.org
> homepage, using e.g. https://tracker.orgmode.org/news.rss.
>
> This is experimental, let's see if this helps spread the word about
> useful blogs.

I am looking at https://tracker.orgmode.org/news and I feel that mixing
blog/tip entries with important announcements may not be very good idea.
May we put the blogs into a separate tab, leaving announcements stand
out?

Also, I do not see
https://list.orgmode.org/877cihmr45@posteo.net/T/#u listed.
May it be because in "[tip] Export to PDF with latexmk 'continuous
preview' option", "tip" is lowercase?

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

[Ihor Radchenko]

Stefan Monnier  writes:

> The "* DIRTITLE: (FILENAME)." syntax is Texinfo's syntax, and currently the
> Org user needs to know that syntax and abide by it (even though it's
> not well defined nor well documented, IME).  My change mostly makes it
> unnecessary for the user to know that syntax because ox-texinfo already
> knows the FILENAME, so it only needs the DIRTITLE.

If it is not well-documented, we may as well help users by explaining a
bit in a footnote in the Org manual.

> The new code supports the "* DIRTITLE: (FILENAME)." syntax mostly for
> backward compatibility, tho it can also be useful in corner cases such
> as when the final filename will be different than the one ox-texinfo
> knows about.
>
> Not sure how to adjust the text to clarify that, without including
> a discussion of the "* DIRTITLE: (FILENAME)." and how things used to be,
> and how the filename is controlled.

... then we can also include this discussion in a footnote and put the
new syntax into the main visible part of the manual.

> The old(current) situation is arguably worse because it doesn't even
> document the syntax that needs to be used.

Agree.

>>>  - =TEXINFO_DIR_DESC= ::
>>>  
>>>#+cindex: @samp{TEXINFO_DIR_DESC}, keyword
>>>The directory description of the document.
>>> +  Defaults to the title of the document.
>>
>> I'd also add that it should be a short sentence.
>
> Not sure if it needs to be a sentence, but yes, it should usually be
> short tho I don't think there's a technical need for it, so I think the
> "defaults to the title" should be a good enough hint about the kind of
> length expected.

Also ok. I do not have a strong opinion here - referring to title is
also clear enough for me; I am just not sure if it is clear enough for
all the readers of the manual.

>>>  (:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t)
>>> +;; FIXME: The naming of these options is unsatisfactory:
>>> +;; TEXINFO_DIR_DESC corresponds (and defaults) to the document's
>>> +;; title, whereas TEXINFO_DIR_TITLE corresponds (and defaults) to
>>> +;; its filename.
>> What about TEXINFO_DIR_NAME + TECINFO_DIR_DESC?
>
> Fine by me, yes.

I can add it after we finalize your patch.
Or you can do it as a part of the patch, if you are willing to.
(Just make sure that old keyword name is supported for backwards-compatibility)

>>> +   (dirtitle
>>> + (cond
>>> +  ((and dt
>>> +(or (string-match "\\`\\* \\(.*?\\)\\(\\.\\)?\\'" dt)
>>> +(string-match "\\`\\(.*(.*)\\)\\(\\.\\)?\\'" dt)))
>>> +   ;; `dt' is already "complete".
>>> +   (format "* %s." (match-string 1 dt)))
>>> +  ((and dt (not (equal dt file)))
>>> +   (format "* %s: (%s)." dt file))
>>
>> It would be nice to add a comment saying that dt values like
>> "Foo (filename)" are already captured by the previous cond clause.
>
> I don't understand what you mean by that.

I had a hard time understanding why the second clause of `cond' never
matches things like "Foo (filename)" - the test (equal dt file) looks
suspicious from the first glance; until I spend some time parsing the
above regexps.

So, I am asking you to add code comment explaining why (equal dt file)
is sufficient.

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

[Ihor Radchenko]

"Slawomir Grochowski"  writes:

>:COLUMNS:  %40ITEM(item) %OMEGA-3-1000(omega 3){+} 
> %MULTIVITAMIN(multivitamin){+}
>:COLUMNS:  ...
>:COLUMNS:  ...
> ...
> Because the code for the view is 'reading' the last :COLUMNS: definition with
> function (org-entry-get nil "COLUMNS" t).
>
> But is 'changing' the first :COLUMNS: definition with function 
> (org-entry-put nil "COLUMNS" fmt).
>
> However, this is a bit of an inconsistency. This 'hack' could work
> without any problems.  If the read and write behavior of property :COLUMNS: 
> were
> predictable, same.
>
> Do you have any idea how to solve this problem?

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?

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

Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

[Max Nikulin]

On 25/02/2024 17:41, Max Nikulin wrote:

Max Nikulin writes:



So `shell-quote-argument' is necessary and quotes around %i must be
stripped similar to %s in mailcap entries in `org-open-file'.

...

Please, revert the commit that added a misleading recommendation.

...
It should be more reliable to pass fragment to command stdin. It can be 
done if %i is missed in `org-latex-to-html-convert-command'.


I have realized that there is `org-latex-to-mathml-convert-command' 
introduced a decade earlier and affected by the same issue with possible 
leak of formula to shell command. Even if there are reasons against 
obsoleting `org-latex-to-html-convert-command' in favor of 
`org-latex-to-mathml-convert-command', both user options should be 
handled by the same function.


I am unsure if it is an intended feature that when an org file is opened 
from a remote location like /ssh:... then 
`org-latex-to-html-convert-command' is executed on the remote host. It 
makes implementation of stdin more tricky. Ideally, it should be 
configurable where the command is executed: where emacs is running, 
where the document resides, or even with specific `default-directory'.


Double quotes are recommended around %i for ODT export
(info "(org) LaTeX math snippets")
https://orgmode.org/manual/LaTeX-math-snippets.html
and it should be fixed as well.

It seems --preload=siunitx.sty should be recommended any more for latexml:
https://github.com/brucemiller/LaTeXML/issues/2268
Problem width loading expl3-code.tex

Perhaps at least some cases may be handled by pandoc
https://list.orgmode.org/CAEPTPEzvx5ZhY5qrCJnFtAC_NpPC9d1a-Q=ye+xntrpximp...@mail.gmail.com/
David Lukeš. Using pandoc to convert LaTeX math to MathML
Tue, 1 Mar 2022 15:59:36 +0100

Unfortunately I am not familiar with MathML enough to evaluate that 
there are no caveats with pandoc.

Re: [BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]

[Ihor Radchenko]

Philip Kaludercic  writes:

> The issue is rather, I don't see the warning at all anymore ("cannot
> reproduce reliably" in the sense of might randomly occur at some point
> again).

If you see it again in future, you may add
(setq org-element--cache-self-verify 'backtrace)
to your config.
Then, Org mode will record diagnostics and add it to the warning message
if such message appear again. You can then share that diagnostics, so
that we can understand what is wrong.

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

Re: [BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]

[Philip Kaludercic]

Ihor Radchenko  writes:

> Philip Kaludercic  writes:
>
>>> Thanks for reporting!
>>> Does the error persist if you upgrade Org mode to the latest 9.6.20
>>> version? If yes, what about the development version?
>>
>> Sorry, I cannot really reproduce the bug in any reliable way.
>
> Even if you cannot reproduce reliably, it is not a problem. Org mode has
> a way to enable recording diagnostics info (via
> org-element--cache-self-verify). But that only makes sense if we know
> for sure that the bug is present on the latest development version of
> Org mode.
>
> So, I just need to know if you keep seeing problems after upgrading to
> the latest main.
>
> If you have no time or interest diagnosing the bug and the warnings keep
> appearing, you may disable cache in your config by customizing
> org-element-use-cache.

The issue is rather, I don't see the warning at all anymore ("cannot
reproduce reliably" in the sense of might randomly occur at some point
again).

-- 
Philip Kaludercic on peregrine

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

[Ihor Radchenko]

Max Nikulin  writes:

> Special blocks are really block-level elements. I see similarity, 
> however with a better term we could avoid "inline" specifier. I think, 
> the new beast may serve in some cases currently handled by macros. LaTeX 
> snippets are named "fragments" in the manual.
>
> Custom fragment?

Not sure if I like it. In my mind, "fragment" implies no nesting. But
the point of the "inline special blocks" is to allow nesting as needed.

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

Re: [BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]

[Ihor Radchenko]

Philip Kaludercic  writes:

>> Thanks for reporting!
>> Does the error persist if you upgrade Org mode to the latest 9.6.20
>> version? If yes, what about the development version?
>
> Sorry, I cannot really reproduce the bug in any reliable way.

Even if you cannot reproduce reliably, it is not a problem. Org mode has
a way to enable recording diagnostics info (via
org-element--cache-self-verify). But that only makes sense if we know
for sure that the bug is present on the latest development version of
Org mode.

So, I just need to know if you keep seeing problems after upgrading to
the latest main.

If you have no time or interest diagnosing the bug and the warnings keep
appearing, you may disable cache in your config by customizing
org-element-use-cache.

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

[Max Nikulin]

On 05/03/2024 00:49, Juan Manuel Macías wrote:

Ihor Radchenko writes:

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.


Custom span?

I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.


Special blocks are really block-level elements. I see similarity, 
however with a better term we could avoid "inline" specifier. I think, 
the new beast may serve in some cases currently handled by macros. LaTeX 
snippets are named "fragments" in the manual.


Custom fragment?

Re: [BUG] unfolding headlines with :extend face keyword & background broke after 2da622cad [9.7 (9.7-??-8ac99c33f @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

[Ihor Radchenko]

StrawberryTea  writes:

> Hi, using the following test case with Emacs -Q:
> ...
> The most recent fix for the bug in 2da622cad seems to have made things
> worse. Now sometimes the background of the headline is not extended and
> other times we still have the trailing background color where it's not
> supposed to. It's definitely a lot worse when the file is started up
> folded because the issue seems to be specifically related with unfolding
> a heading with subheadings.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1151c614b

Maybe I even did not break the other cases :)
(We may need proper tests for this feature)

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