Re: org table proposal: merge and split cells in org-tables

[Ihor Radchenko]

Max Nikulin  writes:

> I believe that tables in Org are already too complicated due to the 
> spreadsheet feature.

They are, but merging cells is widely demanded. If we can come up with
some reasonable extension of Org syntax, it will be a benefit for the
whole Org community.

> However those who are brave enough to add cells 
> spanning columns and rows may take some inspiration from 
> reStructuredText, in particular horizontal lines marked by "+===+===+"

These are the table.el Emacs tables we already support (partially).
Uwe's proposal is supporting table.el more fully, but it will be
incompatible (if taken as is) with the current Org table syntax.

We can learn from the design, but cannot just blindly re-use it.

> Besides "grid" tables there are "simple" tables without vertical lines.

That's similar to the ASCIIDoctor tables as I read it in the link.
I do not think that it is a good option to move away from the visual
table style employed in Org.

> Perhaps it better to implement new table features as src blocks for some 
> new language and a dedicated Emacs mode. In the case of success such 
> proof of concept may be merged into Org core.

That's what our table.el integration does. But it is not enough.

Some features are only present in native Org tables and some features
are only present in table.el tables. We will end up needing to extend
either of the table syntaxes to obtain full Org table functionality.

Then, it is better to extend native Org tables rather than replacing the
existing table syntax with third party.

> My impression is that Org tables quickly become hardly maintainable when 
> their complexity is above some quite low threshold. E.g. automatic 
> recalculation works only for first #+tblfm: line. It requires some 
> efforts to figure out association of particular formula with cell spans.

I'd say that the problem is mostly with org-table.el which heavily
relies on direct regexp matching. If we generalize things using parser,
it should become easier to maintain even with merge cells.

> Merge cells add more complexity to formula ranges. Some protocol should 
> be defined to allow source blocks to generate extended cells.

Agree. And such protocol will improve maintainability even if
implemented without extended cells. Either way, it is a good idea to
refactor org-table.el

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

Re: Line breaks and brackets in LaTeX export

[Ihor Radchenko]

Max Nikulin  writes:

>>> I still believe that
>>>
>>>   something\\[0pt]%__ORG_EXPORT__
>>>
>>> is quite safe to remove (depending on the following character) and
>>> unlikely harmful if remained for some reason.
>> 
>> What about the side effect you mentioned in a previous email?
>> 
>>>TeX reads
>>>
>>>"a% comment
>>>   b"
>>>
>>>as "ab", dropping newline and starting spaces.
>
> Unlike in Org, in TeX "a\\b" still contains a line break. Besides exotic 
> packages and user setups it should just work. After all, during normal 
> operation all "%__ORG_EXPORT__" should be stripped by a filter. They are 
> just marks where a decision is necessary whether to retain "[0pt]" or to 
> remove it.

Thanks for the clarification.

So, we can

1. Change org-latex-line-break-safe to "[0pt]%__ORG_EXPORT__",
   making it unique to distinguish Org-generated line breaks.
2. Establish a regexp criterion when it is safe to strip
   "[0pt]%__ORG_EXPORT__" from the page break (I am still unsure what
   will be the most reliable criteria here). If not safe, we just strip
   the "%__ORG_EXPORT__" part.
3. Write a filter that replaces the above from final output.
   Note: If we go __ORG_EXPORT__ way, it might be safe to leave the
   filter on by default as long as we can find a really robust criteria
   on when it is safe to drop [0pt] part.

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

Re: Single story around subtree export and footnotes, several issues

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> - 1st issue
>
> I use 'emacs -Q' 
>
>GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
>  3.24.30, cairo version 1.17.4) of 2021-08-07
>Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)
>
> and visit the file with 'C-x C-f'.
>
> I export the subtree with 'C-c C-e C-s l o' on the "subtree to be
> exported" headline and get the dreadful
>
>Wrong type argument: consp, nil

Thanks for reporting and for the detailed reproducer!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3e010d81dcabafcdd97199b8122491a74ad9cbed

> - 4th issue
>
> I quit emacs, restart it with 'emacs -Q', do 'M-x
> toggle-debug-on-error', revisit the original file and export the
> subtree again.
>
> (I get a Backtrace which is about 21000 characters so I ommit it so
> far.)
>
> But the buffer is narrowed; I only see:
>   
>2nd call to footnote 1[fn:1]
>call to footnote 2[fn:2]
>[fn:2] footnote 2 body
>
> - 5th issue
>
> After widening it with 'C-x n w', I apparently see my original file,
> but if I do 'C-x s', and answer 'y' to the following question
> (debug3.org is the name of my file):
>
>Save file /home/cochard/Org/debug3.org? (y, n, !, ., q, C-r, C-f, d or C-h)
>
> then, using for example 'cat debug3.org' from a terminal, I can see
> that the last two lines of the file, i.e.,
>
>* COMMENT commented headline
>nothing
>
> have disapeared.

This is because the error terminated export process in the middle of it.
Org export uses a temporary buffer copy during export. That buffer is cleaned
up to remove commented headings, and whatever parts of the original
buffer that should not be exported. When, exporting subtree, the buffer
may also be narrowed.

You should not know this when things do not err in the middle, which is
now fixed.

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

Re: [BUG] ob-doc-maxima.org and ob-maxima.el

[Ihor Radchenko]

Leo Butler  writes:

> I believe the attached patch fixes all the problems that you saw with
> the previous versions.

Thanks!
Applied onto master.
https://git.sr.ht/~bzg/worg/commit/c1440ba5f98634adf08209631d305c1814fb7f9a

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

Re: Clarification on :results file vs. :results graphics file (was: [BUG] ob-doc-maxima.org and ob-maxima.el)

[Ihor Radchenko]

Ihor Radchenko  writes:

> (Note: I'd say "nothing is written to the disk" is a bit misleading
> here. I am attaching a patch with clarification)

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f5c89ba5f91a876ecbcc940e849adbb16fe2

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

Re: BUG: org-lint does not agree with ox-latex and org-element-at-point

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:


> == begin of "include-myself.org" file 
> ...
> However, org-lint complains that in line 3 there is a
> "Non-existent file argument in INCLUDE keyword".

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

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

Re: BUG: org-lint does not agree with ox-latex and org-element-at-point

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> Hello,
>
> == begin of "include-myself.org" file 
> 
> #+caption: BUG: org-lint does not agree with ox-latex and 
> org-element-at-point
> #+name: make-me-float
> #+include: "include-myself.org" src org :lines "1-3"
> == end of "include-myself.org" file 
> ==

Duplicate of 
https://orgmode.org/list/ceef41267fcb44cdcbd7986f599bf...@posteo.net

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

Re: Docstrings and literate programming (good practices?)

[Samuel Wales]

On 11/4/22, Ihor Radchenko  wrote:
> 1. We need to convert from Elisp docstring format to Org markup

not sure what is needed here as it is just a brainstorm.  but i have a
manual i am loath to copy docstrings into when they are already in the
code.  i could adumbrate a bit i the manual but i alreadyu do that
initially in the docstrings.

first line is a good schelling point for this. b ut you are right
there is no standard i am awre of for anything more thn that.

> 2. More importantly, User manual is something to be written as a
>coherent text; not an agglomeration of docstring. (Yes, I am aware of
>the fact that it is not always the case in practice; But we should
>not encourage the current situation)

agreed, it is for a oherent text.  the docstrings wuold be in a
section like "Commands you might like to run in this mode".  Or so.
and have key bidings.

they are not the whole manual.

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


-- 
The Kafka Pandemic

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

Re: Org 9.6-pre and Bash sessions

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Applied onto main changing the commit summary to "org-babel: ...".
> This change will affect all the babel backends that use
> `org-babel-eval'.

That makes sense.  Thank you for the correction!

> A small note: If stderr does not contain a trailing newline, it will
> be displayed as
>
> Stderr output with no trailing newline[ Babel evaluation exited with
> code 1 ]
>
> One may argue that it is ugly.  On the other hand, adding an extra
> newline will make stderr with and without the newline
> indistinguishable.

Ugly but correct.  Besides, virtually every shell does the same, so
every "civilized" program ends its output with a newline.  Also, it
makes me happy that we have this important behavior fixed in tests!

Thank you for all your help!

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

[PATCH] Re: Update Org to MathJax 3

[Rudolf Adamkovič]

Rudolf Adamkovič  writes:

> I will resurrect the thread when I have something to show.

All right, I have finished the second version of the patch.

What do you think?

Rudy

>From aee823f34498cccd6c08bcedb177c82d5de40269 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Fri, 7 Oct 2022 15:03:48 +0200
Subject: [PATCH] ox-html: Update from MathJax 2 to MathJax 3+
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox-html.el (
org-html-mathjax-options,
org-html-mathjax-template,
org-html--build-mathjax-config
): Update to MathJax 3 while maintaining compatibility with MathJax 2.
All legacy options get converted automatically, except for the 'path'
option which must now point to MathJax 3 or later and not MathJax 2.
* testing/lisp/test-ox-html.el (
ox-html/mathjax-path-none,
ox-html/mathjax-path-default,
ox-html/mathjax-path-custom,
ox-html/mathjax-path-in-buffer,
ox-html/mathjax-options-default,
ox-html/mathjax-options-custom,
ox-html/mathjax-options-in-buffer,
ox-html/mathjax-legacy-scale-default,
ox-html/mathjax-legacy-scale-custom,
ox-html/mathjax-legacy-scale-in-buffer,
ox-html/mathjax-legacy-scale-message,
ox-html/mathjax-legacy-scale-message-in-buffer,
ox-html/mathjax-legacy-scale-ignore,
ox-html/mathjax-legacy-autonumber-ams,
ox-html/mathjax-legacy-autonumber-ams-in-buffer,
ox-html/mathjax-legacy-autonumber-none,
ox-html/mathjax-legacy-autonumber-none-in-buffer,
ox-html/mathjax-legacy-autonumber-all,
ox-html/mathjax-legacy-autonumber-all-in-buffer,
ox-html/mathjax-legacy-autonumber-message,
ox-html/mathjax-legacy-autonumber-message-in-buffer,
ox-html/mathjax-legacy-font-tex,
ox-html/mathjax-legacy-font-tex-in-buffer,
ox-html/mathjax-legacy-font-stix-web,
ox-html/mathjax-legacy-font-stix-web-in-buffer,
ox-html/mathjax-legacy-font-asana-math,
ox-html/mathjax-legacy-font-asana-math-in-buffer,
ox-html/mathjax-legacy-font-neo-euler,
ox-html/mathjax-legacy-font-neo-euler-in-buffer,
ox-html/mathjax-legacy-font-gyre-pagella,
ox-html/mathjax-legacy-font-gyre-pagella-in-buffer,
ox-html/mathjax-legacy-font-gyre-termes,
ox-html/mathjax-legacy-font-gyre-termes-in-buffer,
ox-html/mathjax-legacy-font-latin-modern,
ox-html/mathjax-legacy-font-latin-modern-in-buffer,
ox-html/mathjax-legacy-line-breaks-true,
ox-html/mathjax-legacy-line-breaks-true-in-buffer,
ox-html/mathjax-legacy-line-breaks-false,
ox-html/mathjax-legacy-line-breaks-false-in-buffer,
ox-html/mathjax-legacy-line-breaks-message,
ox-html/mathjax-legacy-line-breaks-message-in-buffer): Test MathJax.

Reported-by: Rudolf Adamkovič 
Link: https://list.orgmode.org/orgmode/m2a667n4ax@me.com/
---
 etc/ORG-NEWS |  25 ++
 lisp/ox-html.el  | 247 +---
 testing/lisp/test-ox-html.el | 762 +++
 3 files changed, 968 insertions(+), 66 deletions(-)
 create mode 100644 testing/lisp/test-ox-html.el

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b542da34b..7ad17bd70 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -139,6 +139,31 @@ rely on the details of visibility state implementation in
 backend.  From now on, using =outline-*= functions is strongly
 discouraged when working with Org files.
 
+*** HTML export uses MathJax 3+ instead of MathJax 2
+
+Org 9.6 uses MathJax 3, a ground-up rewrite of MathJax 2 released
+in 2019.  The new version brings modularity, better and faster
+rendering, improved LaTeX support, and more.
+
+For more information about new features, see:
+
+https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html
+https://docs.mathjax.org/en/latest/upgrading/whats-new-3.1.html
+https://docs.mathjax.org/en/latest/upgrading/whats-new-3.2.html
+
+For instance, one can typeset calculus with the built-in =physics=
+package or chemistry with the built-in =mhchem= package, like in
+LaTeX.
+
+During the export, Org automatically converts all legacy MathJax 2
+options to the corresponding MathJax 3+ options, except for the =path=
+which must now point to a file containing MathJax version 3 or later.
+
+Further, if you need to use a non-default =font= or =linebreaks= (now
+=overflow=), then the =path= must point to MathJax 4 or later.
+
+See the updated =org-html-mathjax-options= for more details.
+
 ** New features
 *** Clock table can now produce quarterly reports
 
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index cad06aebf..9436623e0 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1166,72 +1166,116 @@ See `format-time-string' for more information on its components."
  Template :: Mathjax
 
 (defcustom org-html-mathjax-options
-  '((path "https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML; )
-(scale "100")
+  '((path "https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js;)
+(scale 1.0)
 (align "center")
-(font "TeX")
-(linebreaks "false")
-(autonumber "AMS")
+(font "mathjax-modern")
+(overflow "overflow")
+(tags "ams")
 

Single story around subtree export and footnotes, several issues

[Alain . Cochard]

Hello.

I have this file:

   #+STARTUP: fnlocal 
   * headline 1 
   1st call to footnote 1[fn:1]
   [fn:1] footnote 1 body
   * subtree to be exported
   2nd call to footnote 1[fn:1]
   call to footnote 2[fn:2]
   [fn:2] footnote 2 body
   * COMMENT commented headline
   nothing


- 1st issue

I use 'emacs -Q' 

   GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
 3.24.30, cairo version 1.17.4) of 2021-08-07
   Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)

and visit the file with 'C-x C-f'.

I export the subtree with 'C-c C-e C-s l o' on the "subtree to be
exported" headline and get the dreadful

   Wrong type argument: consp, nil

- 2nd issue

If I delete the 1st line (#+STARTUP: fnlocal) and export the subtree
again, it gives the same error message, but, if I save the file with
'C-x C-s', revisit it with 'C-x C-v ' and export the subtree
again, then I get a pdf which is as initially expected, in particular
with the line '2nd call to footnote 1^1 call to footnote 2^2' and both
footnotes.

- 3rd issue
  
I quit emacs, restart it with 'emacs -Q' and revisit the original
file.

I delete the two lines with '[fn:2]', and export the subtree again; I
get the pdf file I expect with "2nd call to footnote 1^1" and the
footnote.

- 4th issue

I quit emacs, restart it with 'emacs -Q', do 'M-x
toggle-debug-on-error', revisit the original file and export the
subtree again.

(I get a Backtrace which is about 21000 characters so I ommit it so
far.)

But the buffer is narrowed; I only see:
  
   2nd call to footnote 1[fn:1]
   call to footnote 2[fn:2]
   [fn:2] footnote 2 body

- 5th issue

After widening it with 'C-x n w', I apparently see my original file,
but if I do 'C-x s', and answer 'y' to the following question
(debug3.org is the name of my file):

   Save file /home/cochard/Org/debug3.org? (y, n, !, ., q, C-r, C-f, d or C-h)

then, using for example 'cat debug3.org' from a terminal, I can see
that the last two lines of the file, i.e.,

   * COMMENT commented headline
   nothing

have disapeared.


Nothing makes sense for me. Thanks in advance for any explanation.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [BUG] ob-doc-maxima.org and ob-maxima.el

[Leo Butler]

On Fri, Nov 04 2022, Ihor Radchenko  wrote:

>> +#+RESULTS: 3d-maxima
>> +[[https://orgmode.org/worg/org-contrib/babel/languages/images/maxima-3d.png]]
>> +
>
> I am a bit confused here. Did you hand-craft the results?

I did, based on what I see in ob-doc-octave.org. In the present patch
(attached), I have left the results alone.

>   
>> -#+NAME: solve-maxima
>> +#+NAME: tex-maxima
>>  #+HEADER: :exports results
>>  #+BEGIN_SRC maxima :results raw
>>tex(exp(-x)/x);
>>  #+END_SRC
>
> Please make #+RESULTS a separate paragraph. It may otherwise not be
> correctly recognized.

Ok, I have done this in the attached patch.

>
> Let's move the ob-maxima changes and discussion about graphics to a
> separate thread.

Ok.

I believe the attached patch fixes all the problems that you saw with
the previous versions.

Leo

From a4db0ed4af22e43e817ebca110872e7ee5222c2d Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Fri, 4 Nov 2022 15:23:27 -0500
Subject: [PATCH] org-contrib/babel/languages/ob-doc-maxima.org: correct docs

* include the results of test-maxima and solve-maxima examples;
* correct the :results header of graphics example;
* rename the tex example to tex-maxima and include the results;
* add an empty line before each #+results: as suggested by Ihor.

Ref: https://list.orgmode.org/87k04b5qyf.fsf@localhost/T/#t
---
 org-contrib/babel/languages/ob-doc-maxima.org | 32 +++
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-maxima.org b/org-contrib/babel/languages/ob-doc-maxima.org
index 810c9ef4..a6b403dc 100644
--- a/org-contrib/babel/languages/ob-doc-maxima.org
+++ b/org-contrib/babel/languages/ob-doc-maxima.org
@@ -111,7 +111,9 @@ powers of 12, where the powers are passed with a variable.
   print(12^x);
 #+end_src
 
-#+results: test-maxima
+HTML export of the result:
+
+#+RESULTS: test-maxima
 : 26.06280316745402
 
 ** Solver
@@ -137,6 +139,14 @@ Of course, =maxima= is more than a calculator.
   print(solution);
 #+end_src
 
+HTML export of the result:
+
+#+RESULTS: solve-maxima
+: solve: solution:
+: x = - 4
+:  x = 4
+: [%t1, %t2] 
+
 ** 3D plots
 With =gnuplot= installed (4.0 or higher), 3D graphics are possible.
 This example is from [[http://maxima.sourceforge.net/maxima-gnuplot.html][a tutorial on the maxima/gnuplot interface]].
@@ -145,7 +155,7 @@ This example is from [[http://maxima.sourceforge.net/maxima-gnuplot.html][a tuto
 ,#+name: 3d-maxima
 ,#+header: :file images/maxima-3d.png
 ,#+header: :exports results
-,#+header: :results graphics
+,#+header: :results file graphics
 ,#+begin_src maxima 
   programmode: false;
   plot3d(atan(-x^2+y^3/4),[x,-4,4],[y,-4,4],[grid,50,50],[gnuplot_pm3d,true]);
@@ -154,35 +164,43 @@ This example is from [[http://maxima.sourceforge.net/maxima-gnuplot.html][a tuto
 
 #+name: 3d-maxima
 #+header: :file images/maxima-3d.png
-#+header: :results graphics
 #+header: :exports results
+#+header: :results file graphics
 #+begin_src maxima 
   programmode: false;
   plot3d(atan(-x^2+y^3/4),[x,-4,4],[y,-4,4],[grid,50,50],[gnuplot_pm3d,true]);
 #+end_src
 
-#+results: 3d-maxima
+HTML export of the Maxima code block result:
+
+#+RESULTS: 3d-maxima
 [[file:images/maxima-3d.png]]
 
+
 ** Inline Display of Maxima LaTeX Output
   [[http://maxima.sourceforge.net/][Maxima]] code can be evaluated and displayed inline in Org mode
   through babel [fn:1] as in the example below, based on RS initial
   example.
 
 #+begin_example
-,#+NAME: solve-maxima
-,#+HEADER: :exports none
+,#+NAME: tex-maxima
+,#+HEADER: :exports results
 ,#+BEGIN_SRC maxima :results raw
   tex(exp(-x)/x);
 ,#+END_SRC
 #+end_example
 
-#+NAME: solve-maxima
+#+NAME: tex-maxima
 #+HEADER: :exports results
 #+BEGIN_SRC maxima :results raw
   tex(exp(-x)/x);
 #+END_SRC
 
+HTML export of the result:
+
+#+RESULTS: tex-maxima
+$${{e^ {- x }}\over{x}}$$
+
 *** Toggle inline display of latex code
 Latex code in org mode can be displayed inline by 'C-c C-x
 C-l'. To remove the inline display 'C-c C-c' is used. This is
-- 
2.35.1

[PATCH] * lisp/org.el: (org-get-indirect-buffer) Allow indirect base buffers

[Adam Porter]

Hi,

The attached patch improves the function org-get-indirect-buffer, fixing 
a bug, clarifying the code, and adding a docstring.


Thanks,
AdamFrom 8e70024cae3f4569d6a0c86a0e4d8079126fe9e5 Mon Sep 17 00:00:00 2001
From: Adam Porter 
Date: Fri, 4 Nov 2022 14:52:58 -0500
Subject: [PATCH] * lisp/org.el: (org-get-indirect-buffer) Allow indirect base
 buffers

Previously, calling this function on an indirect buffer would fail,
preventing the user from making a new indirect buffer based on an
indirect buffer (e.g. imagine the user makes an indirect buffer for a
large subtree, then wants to make another one for a subtree of that).
Now, the base buffer of the buffer is used, when applicable.

Also, the function is partially rewritten to be clearer, and a
docstring and a FIXME are added.
---
 lisp/org.el | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d8708f8f2..3b67040f7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6160,25 +6160,32 @@ frame is not changed."
 (run-hook-with-args 'org-cycle-hook 'all)
 (and (window-live-p cwin) (select-window cwin
 
-(defun org-get-indirect-buffer ( buffer heading)
-  (setq buffer (or buffer (current-buffer)))
-  (let ((n 1) (base (buffer-name buffer)) bname)
-(while (buffer-live-p
-	(get-buffer
-	 (setq bname
-		   (concat base "-"
-			   (if heading (concat heading "-" (number-to-string n))
-			 (number-to-string n))
-  (setq n (1+ n)))
+(cl-defun org-get-indirect-buffer ( (buffer (current-buffer)) heading)
+  "Return an indirect buffer based on BUFFER.
+If HEADING, prepend it to the name of the new buffer."
+  (let* ((base-buffer (or (buffer-base-buffer buffer) buffer))
+ (suffix-prefix (if heading
+(concat heading "-")
+  ""))
+ (buffer-name (cl-loop for n from 1 to 100
+   for suffix = (format "%s%s" suffix-prefix n)
+   for name = (format "%s-%s"
+  (buffer-name base-buffer)
+  suffix)
+   while (buffer-live-p (get-buffer name))
+   finally return name)))
 (condition-case nil
-(let ((indirect-buffer (make-indirect-buffer buffer bname 'clone)))
+(let ((indirect-buffer (make-indirect-buffer base-buffer buffer-name 'clone)))
   ;; Decouple folding state.  We need to do it manually since
   ;; `make-indirect-buffer' does not run
   ;; `clone-indirect-buffer-hook'.
   (org-fold-core-decouple-indirect-buffer-folds)
   ;; Return the buffer.
   indirect-buffer)
-  (error (make-indirect-buffer buffer bname)
+  ;; FIXME: Explain why this `condition-case' is necessary.  Why
+  ;; could an error be signaled with the CLONE argument non-nil,
+  ;; and why would trying again without CLONE solve the problem?
+  (error (make-indirect-buffer base-buffer buffer-name)
 
 (defun org-set-frame-title (title)
   "Set the title of the current frame to the string TITLE."
-- 
2.34.0

Re: Clarification on :results file vs. :results graphics file

[Leo Butler]

On Fri, Nov 04 2022, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
 @@ -145,7 +151,7 @@ This example is from 
 [[http://maxima.sourceforge.net/maxima-gnuplot.html][a tuto
  ,#+name: 3d-maxima
  ,#+header: :file images/maxima-3d.png
  ,#+header: :exports results
 -,#+header: :results graphics
 +,#+header: :results graphics file
>>>
>>> Using graphics together with file does not make sense.
>>
>> Ok. But I am not sure the code agrees with you. In ob-core.el,
>>  ...
>>
>> Is it, in your opinion, ob-maxima's responsibility to add "graphics" to
>> :result-params when :results file is specified?
>
> No.

Thank you for correcting yourself and me. I had arrived at the same
conclusion and was going to retract that `patch' to ob-maxima.el.

Leo

BUG: org-lint does not agree with ox-latex and org-element-at-point

[gerard . vermeulen]

Hello,

== begin of "include-myself.org" file 

#+caption: BUG: org-lint does not agree with ox-latex and 
org-element-at-point

#+name: make-me-float
#+include: "include-myself.org" src org :lines "1-3"
== end of "include-myself.org" file 
==


Writing the three lines between the == ... == markers to new file named
"include-myself.org" and opening+exporting this file to LaTeX does
what I expect: it produces a float listing the first 2 lines with a 
caption.


The result of execution M-: org-element-at point RET with point on
any of those lines looks also OK to me.

However, org-lint complains that in line 3 there is a
"Non-existent file argument in INCLUDE keyword".

Best regards -- Gerard

Package: Org mode version 9.6-pre ( @ 
/Users/vermeulen/.emacs.d/elpa/org-9.6pre0.20221104.24838/)

BUG: org-lint does not agree with ox-latex and org-element-at-point

[gerard . vermeulen]

Hello,

== begin of "include-myself.org" file 

#+caption: BUG: org-lint does not agree with ox-latex and 
org-element-at-point

#+name: make-me-float
#+include: "include-myself.org" src org :lines "1-3"
== end of "include-myself.org" file 
==


Writing the three lines between the == ... == markers to new file named
"include-myself.org" and opening+exporting this file to LaTeX does
what I expect: it produces a float listing the first 2 lines with a 
caption.


The result of execution M-: org-element-at point RET with point on
any of those lines looks also OK to me.

However, org-lint complains that in line 3 there is a
"Non-existent file argument in INCLUDE keyword".

Best regards -- Gerard

Package: Org mode version 9.6-pre ( @ 
/Users/vermeulen/.emacs.d/elpa/org-9.6pre0.20221104.24838/)

Re: Can I have the hourly set in Agenda in different way?

[Renato Pontefice]

Thank you,
I’ve already searched somethings about Agenda and I’ve found a “new world”! Now 
I will go deeply to it!

Thank you again!

Renato

> Il giorno 4 nov 2022, alle ore 15:14, Ihor Radchenko  ha 
> scritto:
> 
> Renato Pontefice  writes:
> 
>> Can you send me some link to that info? Or some name I can look for?
> 
> C-h v org-agenda-time-grid 
> 
> This is a general pattern to ask information about variables and
> commands:
> 
> - C-h v variable-name  :: (h)elp for (v)ariable
> - C-h f function-name  :: (h)elp for (f)unction
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: @string abbreviation in bib file not honored in (basic) org-cite

[Joost Kremers]

On Thu, Nov 03 2022, Ihor Radchenko wrote:
> The rules are in 
> https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
>
> Shuguang Sun contributed TINYCHANGE (no need for copyright assignment;
>though he contributed ~15LOC and it is on the edge)
> Martin R. Albrecht also contributed TINYCHANGE
> Alex Branham -- TINYCHANGE
> aikrahguzar -- TINYCHANGE
> András Simonyi has copyright assignment (see
>   https://orgmode.org/worg/contributors.html)
> And you have the copyright assignment

How did you determine this, if I may ask? aikrahguzar's contribution at first
sight seems more involved, though I admit part of those changes is stuff being
moved around.

> I see no obstacles to go for ELPA, unless you have strong reasons to
> avoid asking copyright assignment for future contributors.

No, I don't have reasons to avoid that.

-- 
Joost Kremers
Life has its moments

Re: Can I have the hourly set in Agenda in different way?

[Ihor Radchenko]

Renato Pontefice  writes:

> Can you send me some link to that info? Or some name I can look for?

C-h v org-agenda-time-grid 

This is a general pattern to ask information about variables and
commands:

- C-h v variable-name  :: (h)elp for (v)ariable
- C-h f function-name  :: (h)elp for (f)unction

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

Re: How to center an image directly in org-mode (without exporting)

[Cletip Cletip]

Thanks you for your answer,
thanks for the tips, I will see that in detail.

Le ven. 4 nov. 2022 à 05:53, Ihor Radchenko  a écrit :

> Cletip Cletip  writes:
>
> > My problem is quite simple to understand: when I activate
> > "org-toggle-inline-images", I would like my images to be centered.
> Indeed,
> > I tried this in a org-file
> >
> > #+ATTR_ORG: :width 800 :center t
> >
> > [[file:images/anImage.png]]
> >
> >
> > But it obviously doesn't work.
>
> AFAIK, there is no easy way to do this, especially if you want the
> centering to be preserved on resize.
>
> > Does anyone have a tip?
> >
> > (I'm thinking of creating a function that, each time the size of the
> window
> > changes, readjusts the number of spaces to put so that my image is
> > centered. It's not a very clean solution, but could it work?)
>
> What you are thinking is probably the only sane way. Though you do not
> have to insert actual spaces. May instead use display property. See
> 40.16.3 Pixel Specification for Spaces section of Elisp manual.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Can I have the hourly set in Agenda in different way?

[Renato Pontefice]

Can you send me some link to that info? Or some name I can look for?

Thank you

Renato

> Il giorno 4 nov 2022, alle ore 14:27, Ihor Radchenko  ha 
> scritto:
> 
> Renato Pontefice  writes:
> 
>>  renato: 18:00 yoga  
>>  19:00.. "
>>  20:00.. 
>> 
>> Or a similar way where I have the slot  18 - 19:30 occupied by the event 
>> I’ve signed on my .org.
>> Not like the firs image where I see 18:00 - 19:30 yoga and then the line  
>> 18:00.. 
> 
> I think you need to customize `org-agenda-time-grid'. In particular,
> "remove-match" option.
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Can I have the hourly set in Agenda in different way?

[Ihor Radchenko]

Renato Pontefice  writes:

>   renato: 18:00 yoga  
>   19:00.. "
>   20:00.. 
>
> Or a similar way where I have the slot  18 - 19:30 occupied by the event I’ve 
> signed on my .org.
> Not like the firs image where I see 18:00 - 19:30 yoga and then the line  
>  18:00.. 

I think you need to customize `org-agenda-time-grid'. In particular,
"remove-match" option.

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

Can I have the hourly set in Agenda in different way?

[Renato Pontefice]

I try to explain my self.
On my Agenda, I have this view:

Friday  4 November 2022
  renato:  8:00.. cili 
   8:00.. 
  10:00.. 
  12:00.. 
  13:43.. now - - - - - - - - - - - - - - - - - - - - - - - - -
  14:00.. 
  16:00.. 
  renato: 18:00-19:30  yoga  
  18:00.. 
  20:00.. 

I’m Wondering if could it be possible to have a situation like this:


Friday  4 November 2022
  renato:  8:00.. cili 
   8:00.. 
  10:00.. 
  12:00.. 
  13:43.. now - - - - - - - - - - - - - - - - - - - - - - - - -
  14:00.. 
  16:00.. 
  renato: 18:00 yoga  
  19:00.. "
  20:00.. 

Or a similar way where I have the slot  18 - 19:30 occupied by the event I’ve 
signed on my .org.
Not like the firs image where I see 18:00 - 19:30 yoga and then the line  
 18:00.. 
  20:00.. 

I hope to have  explained what I would

Thank you

Renato

Re: [PATCH] org.el: Warning for unsupported markers in `org-set-emphasis-alist'

[Max Nikulin]

On 04/11/2022 13:53, Ihor Radchenko wrote:


I have reviewed the patch, and I'd like to suggest a new version with the
following changes:


Great! I have not tried your patch in action, but I do not see 
substantial changes.



1. Use `set-default-toplevel-value' instead of `set' that might be
quirky in some scenarios.


Almost certainly it is an improvement. Docs in the Emacs repo have been 
updated, but the published variant still suggests `set-default' 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Definitions.html



2. Use `warn' instead of `message' as more alarming.


I do not mind.


3. Remove verbatim in ("=" org-verbatim verbatim), ("~" org-code
verbatim), and the :type spec.  AFAIU, they are unused. But can you
please double-check?


It seems, before the following commit, verbatim was used to suppress 
flyspell, but now "~" and "=" are hardcoded.


9fb2e047d 2016-12-08 09:44:26 +0100 Nicolas Goaziou: Split `org-emph-re' 
and `org-verbatim-re'


I think, verbatim option should not be removed from `defcustom' :type 
just now. For some users it might cause fallback to raw lisp value in 
easy customization UI. Perhaps another warning should be added to the 
`org-set-emphasis-alist' validator and the option should be labeled as 
unused in the :type definition.

Re: Docstrings and literate programming (good practices?)

[Max Nikulin]

On 04/11/2022 10:03, Samuel Wales wrote:


for example, you have a body of non-literate elisp code, and you have
a manual.  it could be redundant to describe commands and what they do
and their options, if the docstrings are good.


There is Sphinx in Python world that allows to combine guide pages with 
API docs extracted from source files: classes, functions, variables, 
modules (files). Some introduction and API reference may work well. I 
tried it, but without going deeper I did not manage to achieve the same 
quality as I saw for some packages at readthedocs.

https://www.sphinx-doc.org/en/master/

What I miss in texinfo is a feature similar to Intersphinx
https://www.sphinx-doc.org/en/master/usage/quickstart.html#intersphinx
To generate external references in HTML pages, an index file may be 
downloaded. As a result anchors in docs or function names are linked to 
proper files, anchors are formatted with section names as their description.


https://docs.python.org likely uses another tool, but the approach is 
often the same: general description and docstrings.


I think, Org manual published on the web site would benefit from links 
to HTML API reference generated from docstrings.


P.S. Pages generated by doxygen may be convenient as well. It is nice to 
have details related to functions and classes linked from overview, 
design description, a guide how this API should be used. Of course, it 
works only if such pages are written and added to doxygen config.

Re: How to align all tables at once?

[Ihor Radchenko]

Jean Louis  writes:

> Then I look in the code by searching for variable
> `org-startup-align-all-tables', and I find this within `define-derived-mode':
>
>   (unless org-inhibit-startup
> (org-unmodified
>  (when org-startup-with-beamer-mode (org-beamer-mode))
>  (when (or org-startup-align-all-tables org-startup-shrink-all-tables)
>(org-table-map-tables
>   (cond ((and org-startup-align-all-tables
>   org-startup-shrink-all-tables)
>  (lambda () (org-table-align) (org-table-shrink)))
> (org-startup-align-all-tables #'org-table-align)
> (t #'org-table-shrink))
>   t))
>
> And I think such larger definitions shall rather be split into smaller
> useful functions.

You are, indeed, right. Patches welcome :)

>> Babel also auto-aligns tables in results.
>
> Would it be possible to put Org as Babel source, so that I have Org
> table inside of Babel and cause Babel to render automatically on the
> end of buffer rendering and invocation of org derived mode?

Yes.

#+begin_src org :results replace
| this | is | table |
|1 |  2 | 3 |
| laskjdlsakjdsaldjk ||   |
#+end_src

#+RESULTS[9f13490e4a64c55f86c49e2839d6c1b34f234a9e]:
| this   | is | table |
| 1  |  2 | 3 |
| laskjdlsakjdsaldjk ||   |


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

Re: Docstrings and literate programming (good practices?)

[Ihor Radchenko]

Samuel Wales  writes:

> why not include the docstrings of all commands in some nice format in
> the .org manual via some mechanism?
>
> would that be a good practice?  seems useful abstractly.

There are two problems:
1. We need to convert from Elisp docstring format to Org markup
2. More importantly, User manual is something to be written as a
   coherent text; not an agglomeration of docstring. (Yes, I am aware of
   the fact that it is not always the case in practice; But we should
   not encourage the current situation)

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

Re: Docstrings and literate programming (good practices?)

[tomas]

On Fri, Nov 04, 2022 at 12:13:30AM -0700, Samuel Wales wrote:
> my dry sensibilities say don't write ht same thing in the manual that
> is well written in the docstring.  idk the issues however, other than
> that once you do it in two places murphy's law says they will get out
> of sync.

Absolutely. I can well imagine docstrings going into a reference.

> but surely an extractor could look for an interactive spec and things
> like htat could subset the functions and text.

My complaints were not so much about the extractors themselves as
about the kind of docs that tend to be made with them.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Docstrings and literate programming (good practices?)

[tomas]

On Fri, Nov 04, 2022 at 07:39:04AM +0100, Marcin Borkowski wrote:
> 
> On 2022-11-04, at 06:45, to...@tuxteam.de wrote:

[...]

> > Ah. Javadoc and their descendants. I tend to call that "illiterate
> > programming"...
> 
> I spat my tea. :-)  Thanks, that's a nice one!

Sorry to hear that ;-P

> Though this _may_ work in some cases.  For example, imagine you divide
> your package into two files – one with user-facing commands and another
> one with internal functions.  If you order the former one carefully, the
> "extract docstrings" might actually work as a documentation.

Yes, of course it's just a tool; but that kind of tool all too often
seduces people to switch to auto-pilot.

How many Doxygen docs have I had which tell me that function so-and-
so takes an int as third argument? I can see that by inspecting the
source! As a bonus, I don't get that much optical fluff and don't
have to go to the browser to look at it.

> Still, a "normal" documentation seems a better (even if more
> time-consuming) options.

Yes, it takes work.

> Also, such docstring-based documentation is still better than none.

That depends on how much work goes into the docstring. This:

  /* add 2 to x */
  x += 2;

is the typical quality you get when you're writing the docs while
waist-deep in the code. If you want good docs, you have to take a
step back and try to put yourself into the mind of someone else
(i.e. "forget" for a moment all the implicit knowledge you have
about that code you've been intimate with for weeks, perhaps for
years). That's not easy :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: org table proposal: merge and split cells in org-tables

[Max Nikulin]

I believe that tables in Org are already too complicated due to the 
spreadsheet feature. However those who are brave enough to add cells 
spanning columns and rows may take some inspiration from 
reStructuredText, in particular horizontal lines marked by "+===+===+"


https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#tables

Grid tables are described with a visual grid made up of the characters "-", "=", "|", and "+". The hyphen 
("-") is used for horizontal lines (row separators). The equals sign ("=") may be used to separate optional header rows from the table body 
(not supported by the Emacs table mode). The vertical bar ("|") is used for vertical lines (column separators). The plus sign ("+") is used 
for intersections of horizontal and vertical lines. Example:

+++--+--+
| Header row, column 1   | Header 2   | Header 3 | Header 4 |
| (header rows optional) ||  |  |
+++==+==+
| body row 1, column 1   | column 2   | column 3 | column 4 |
+++--+--+
| body row 2 | Cells may span columns.  |
+++-+
| body row 3 | Cells may  | - Table cells   |
++ span rows. | - contain   |
| body row 4 || - body elements.|
+++-+


RST tables have a feature making hard to implement autoalignment. If 
come cell have "|" with offset in respect to lines above and below then

it is a regular character.

Besides "grid" tables there are "simple" tables without vertical lines.

Perhaps it better to implement new table features as src blocks for some 
new language and a dedicated Emacs mode. In the case of success such 
proof of concept may be merged into Org core.


My impression is that Org tables quickly become hardly maintainable when 
their complexity is above some quite low threshold. E.g. automatic 
recalculation works only for first #+tblfm: line. It requires some 
efforts to figure out association of particular formula with cell spans.


Merge cells add more complexity to formula ranges. Some protocol should 
be defined to allow source blocks to generate extended cells.

Re: BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Ihor Radchenko]

Michael Dauer  writes:

> It's this fixed? How can I track myself?

I think it is, as a side effect of
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9987451252fa64af65d0a0a014f41812f4402c02

I was mainly waiting for Timothy to chime in, but there was a second bug 
report...

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

[PATCH] Re: Link-words with spaces, allowed or not?

[Ihor Radchenko]

Ihor Radchenko  writes:

> We may allow something like
> #+LINK: "this is a link with spaces" http://replacement

See the attached patch allowing the above syntax in #+LINK keywords.

>From 0b81f2d4cc9f6dd5f8d38f9a6550387c93b15435 Mon Sep 17 00:00:00 2001
Message-Id: <0b81f2d4cc9f6dd5f8d38f9a6550387c93b15435.1667546163.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Fri, 4 Nov 2022 15:14:44 +0800
Subject: [PATCH] org: Allow spaces in #+LINK abbreviation definitions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org.el (org-set-regexps-and-options): Allow spaces when
defining link abbreviations via #+LINK keyword.
* testing/lisp/test-org-element.el (test-org-element/link-parser): Add
a new test.
* doc/org-manual.org (Link Abbreviations): Add example demonstrating
link abbreviation with spaces.

Reported-by: Rudolf Adamkovič 
Link: https://orgmode.org/list/87zgf7zujc.fsf@localhost
---
 doc/org-manual.org   | 3 +++
 lisp/org.el  | 6 +-
 testing/lisp/test-org-element.el | 9 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index dc2fc57cd..47710466a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3652,8 +3652,11 @@ ** Link Abbreviations
 #+begin_example
 ,#+LINK: bugzilla  https://10.1.2.9/bugzilla/show_bug.cgi?id=
 ,#+LINK: duckduckgo https://duckduckgo.com/?q=%s
+,#+LINK: "Nu Html Checker" https://validator.w3.org/nu/?doc=%h
 #+end_example
 
+The abbreviations containing spaces must be quoted.
+
 In-buffer completion (see [[*Completion]]) can be used after =[= to
 complete link abbreviations.  You may also define a Lisp function that
 implements special (e.g., completion) support for inserting such a
diff --git a/lisp/org.el b/lisp/org.el
index d8708f8f2..0036b189a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4184,7 +4184,11 @@ (defun org-set-regexps-and-options ( tags-only)
 	   (delq nil
 		 (mapcar
 		  (lambda (value)
-			(and (string-match "\\`\\(\\S-+\\)[ \t]+\\(.+\\)" value)
+			(and (or
+  ;; "abbrev with spaces" spec
+  (string-match "\\`\"\\(.+[^\\]\\)\"[ \t]+\\(.+\\)" value)
+  ;; abbrev spec
+  (string-match "\\`\\(\\S-+\\)[ \t]+\\(.+\\)" value))
 			 (cons (match-string-no-properties 1 value)
    (match-string-no-properties 2 value
 		  (cdr (assoc "LINK" alist))
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index eb5b95e86..78a735efe 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2007,6 +2007,15 @@ (ert-deftest test-org-element/link-parser ()
 	(progn (org-mode-restart)
 		   (goto-char (1- (point-max)))
 		   (org-element-property :type (org-element-context))
+  ;; Link abbreviation with spaces.
+  (should
+   (equal "https"
+  (org-test-with-temp-text
+  "#+LINK: \"Nu Html Checker\" https://validator.w3.org/nu/?doc=%h
+  [[Nu Html Checker:test]]"
+	(progn (org-mode-restart)
+		   (goto-char (1- (point-max)))
+		   (org-element-property :type (org-element-context))
   ;; Link abbreviation in a secondary string.
   (should
(equal "https"
-- 
2.35.1


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

Re: Docstrings and literate programming (good practices?)

[Samuel Wales]

my dry sensibilities say don't write ht same thing in the manual that
is well written in the docstring.  idk the issues however, other than
that once you do it in two places murphy's law says they will get out
of sync.

but surely an extractor could look for an interactive spec and things
like htat could subset the functions and text.

On 11/3/22, Marcin Borkowski  wrote:
>
> On 2022-11-04, at 06:45, to...@tuxteam.de wrote:
>
>> On Thu, Nov 03, 2022 at 08:03:05PM -0700, Samuel Wales wrote:
>>> i wonder if emacs or org has what you might call semi-literate or
>>> etaretil docstring functions?
>>>
>>> for example, you have a body of non-literate elisp code, and you have
>>> a manual.  it could be redundant to describe commands and what they do
>>> and their options, if the docstrings are good.
>>>
>>> why not include the docstrings of all commands in some nice format in
>>> the .org manual via some mechanism?
>>
>> Ah. Javadoc and their descendants. I tend to call that "illiterate
>> programming"...
>
> I spat my tea. :-)  Thanks, that's a nice one!
>
> Though this _may_ work in some cases.  For example, imagine you divide
> your package into two files – one with user-facing commands and another
> one with internal functions.  If you order the former one carefully, the
> "extract docstrings" might actually work as a documentation.
>
> Still, a "normal" documentation seems a better (even if more
> time-consuming) options.
>
> Also, such docstring-based documentation is still better than none.
>
> Best,
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>


-- 
The Kafka Pandemic

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

Re: BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Michael Dauer]

It's this fixed? How can I track myself?

Ihor Radchenko  schrieb am Mo., 17. Okt. 2022, 15:11:

> Michael Dauer  writes:
>
> > Org mode version 9.5.5 (9.5.5-geeae6e
> >
> > #+CALL: test1()
> >
> > #+RESULTS:
> > : 1
> >
> > #+CALL: test2()
> >
> > Fails with: Format specifier doesn’t match argument type
> >
> > * Test
> > #+name: test1
> > #+begin_src elisp
> > 1
> > #+end_src
> > #+NAME: test2
> > #+begin_src elisp
> > (org-sbe "test1")
> > #+end_src
>
> Thanks for reporting.
> Confirmed.
>
> Timothy, it is caused by your
>
> 392ccbbf5d450ad47cd5952ed2f4ef35e454648e
> Author: TEC 
> ob-core: Display position of executed babel blocks
>
> (nth 5 info) is nil in the above scenario.
>
> Could you please take a look?
>
> I can "fix" this by using "%S" formatter, but maybe we can do better?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [PATCH] org.el: Warning for unsupported markers in `org-set-emphasis-alist'

[Ihor Radchenko]

Max Nikulin  writes:

> On 21/11/2021 17:01, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> My draft version is attached. Ihor, thank you for inspiration. Feel free
>>> to improve it. I hope, it makes problem more apparent to user who tries
>>> to customize markers.
>
> A patch is attached. I have dropped changes in documentation since I am 
> not the author of them.

Sorry for the late reply.

I have reviewed the patch, and I'd like to suggest a new version with the
following changes:
1. Use `set-default-toplevel-value' instead of `set' that might be
   quirky in some scenarios.
2. Use `warn' instead of `message' as more alarming.
3. Remove verbatim in ("=" org-verbatim verbatim), ("~" org-code
   verbatim), and the :type spec.  AFAIU, they are unused. But can you
   please double-check?

>From 919fc426f298755886f6f3df22ce9670a7cf67c6 Mon Sep 17 00:00:00 2001
Message-Id: <919fc426f298755886f6f3df22ce9670a7cf67c6.1667544252.git.yanta...@posteo.net>
From: Max Nikulin 
Date: Mon, 22 Nov 2021 23:56:15 +0700
Subject: [PATCH v3] org.el: Warn about unsupported markers in
 `org-set-emphasis-alist'

* lisp/org.el (org-emphasis-alist, org-set-emphasis-alist): Change
custom variable type definition and add :set parameter to warn users
that non-standard marker characters are ignored.  Remove unused third
list entry from the default value.

Attempts to introduce new markers have been discussed enough times to
add some code that should prevent wasting of time.

Unfortunately there is no way to issue warning for e.g. `setq'.

Link: https://orgmode.org/list/878rxoa6lk.fsf@localhost
---
 lisp/org.el | 50 ++
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d8708f8f2..43be34daf 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3628,12 +3628,31 @@ (defvar org-emphasis-regexp-components
 
 You need to reload Org or to restart Emacs after setting this.")
 
+(defun org-set-emphasis-alist (var value)
+  "Set VAR (`org-emphasis-alist') to VALUE.
+Warn user that Org syntax can not be extended with new emphasis
+markers if such attempt is detected.  The function is intended for
+:set argument of `defcustom'."
+  (set-default-toplevel-value var value)
+  (let ((unsupported
+	 (delq nil
+	   (mapcar
+(lambda (entry)
+  (let ((marker (car entry)))
+(unless (member marker '("*" "/" "_" "=" "~" "+")) marker)))
+value
+(when unsupported
+  (warn "Unsupported markup characters '%s' detected in `%s'"
+	(mapconcat #'identity unsupported " ")
+	(symbol-name var
+  value)
+
 (defcustom org-emphasis-alist
   '(("*" bold)
 ("/" italic)
 ("_" underline)
-("=" org-verbatim verbatim)
-("~" org-code verbatim)
+("=" org-verbatim)
+("~" org-code)
 ("+" (:strike-through t)))
   "Alist of characters and faces to emphasize text.
 Text starting and ending with a special character will be emphasized,
@@ -3641,18 +3660,33 @@ (defcustom org-emphasis-alist
 marker characters and the face to be used by font-lock for highlighting
 in Org buffers.
 
+Do not change the characters and do not add new ones to use custom
+markers for existing styles or to introduce new styles.  Org syntax is
+not meant to be configurable and such modifications will not work with
+export.
+
 You need to reload Org or to restart Emacs after customizing this."
   :group 'org-appearance
   :set 'org-set-emph-re
   :version "24.4"
   :package-version '(Org . "8.0")
+  :set #'org-set-emphasis-alist
   :type '(repeat
-	  (list
-	   (string :tag "Marker character")
-	   (choice
-	(face :tag "Font-lock-face")
-	(plist :tag "Face property list"))
-	   (option (const verbatim)
+  (group
+   (choice
+:tag "Marker"
+(const :tag "*Bold*" "*")
+(const :tag "/Italic/" "/")
+(const :tag "_Underline_" "_")
+(const :tag "+Strike-through+" "+")
+(const :tag "=Verbatim=" "=")
+(const :tag "~Code~" "~")
+;; To warn users that it does not work.
+(string :tag "Unsupported ignored character"))
+   (choice
+:tag "Font"
+(face :tag "Face")
+(plist :tag "Property list")
 
 (defvar org-protecting-blocks '("src" "example" "export")
   "Blocks that contain text that is quoted, i.e. not processed as Org syntax.
-- 
2.35.1


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

Re: Docstrings and literate programming (good practices?)

[Marcin Borkowski]

On 2022-11-04, at 06:45, to...@tuxteam.de wrote:

> On Thu, Nov 03, 2022 at 08:03:05PM -0700, Samuel Wales wrote:
>> i wonder if emacs or org has what you might call semi-literate or
>> etaretil docstring functions?
>> 
>> for example, you have a body of non-literate elisp code, and you have
>> a manual.  it could be redundant to describe commands and what they do
>> and their options, if the docstrings are good.
>> 
>> why not include the docstrings of all commands in some nice format in
>> the .org manual via some mechanism?
>
> Ah. Javadoc and their descendants. I tend to call that "illiterate
> programming"...

I spat my tea. :-)  Thanks, that's a nice one!

Though this _may_ work in some cases.  For example, imagine you divide
your package into two files – one with user-facing commands and another
one with internal functions.  If you order the former one carefully, the
"extract docstrings" might actually work as a documentation.

Still, a "normal" documentation seems a better (even if more
time-consuming) options.

Also, such docstring-based documentation is still better than none.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: How to align all tables at once?

[Jean Louis]

* Ihor Radchenko  [2022-11-04 07:50]:
> Jean Louis  writes:
> 
> > I am using Org mode for presentation and would like to use it's tables
> > for presentation only.
> >
> > In particular I need the function org-table-align to align the table
> > in presentation mode.
> 
> I am not sure if I understand your use-case, but you may consider
> looking at 3.2 Column Width and Alignment section of the manual.

Yes, I look inside.

My use case is that Org buffer is used for presentation purpose, it is
not a file, it is generated buffer. This means tables cannot be
aligned before, but after, as the Org buffer does not exist before, it
exists only after rendering.

Then I look in the code by searching for variable
`org-startup-align-all-tables', and I find this within `define-derived-mode':

  (unless org-inhibit-startup
(org-unmodified
 (when org-startup-with-beamer-mode (org-beamer-mode))
 (when (or org-startup-align-all-tables org-startup-shrink-all-tables)
   (org-table-map-tables
(cond ((and org-startup-align-all-tables
org-startup-shrink-all-tables)
   (lambda () (org-table-align) (org-table-shrink)))
  (org-startup-align-all-tables #'org-table-align)
  (t #'org-table-shrink))
t))

And I think such larger definitions shall rather be split into smaller
useful functions.

For myself I have made this, which I need to additonally invoke via M-x then it 
works:

(defun rcd-org-table-align-all ()
  (interactive)
  (read-only-mode 0)
  (org-table-map-tables
   (lambda () (org-table-align) (org-table-shrink))
   t)
  (read-only-mode 1))

> #+STARTUP: align
> will align all the tables when opening an Org file.

And in this case I would like it on the end initialization, not
before. But problem is temporarily solved for Org mode by using M-x
rcd-org-table-align-all as my presentation buffer is in read only mode.

Org has nicer table in its source. Asciidoctor does not have, but then
Asciidoctor renders better PDF tables. So I am now using both
versions, Org and Asciidoctor.

⟦ (ignore (setq my-total 0)) ⟧
⟦ (ignore (defun my-add (n) (setq my-total (+ my-total n)) 
   (format "UGX %s" n))) ⟧

== Monthly Expenses

[cols="4,>1"]
|===
| Description  | Value   

| Communications and Reporting Officer I/C | ⟦ (my-add 60) ⟧ 
| Prospecting Staff member | ⟦ (my-add 45) ⟧ 
| Prospecting Staff member | ⟦ (my-add 45) ⟧ 
| Food for workers on project  | ⟦ (my-add 90) ⟧ 
| Transport Expenses   | ⟦ (my-add 100) ⟧
| Rental   | ⟦ (my-add 30) ⟧ 
| 500 Prospecting Checks with mapping  | ⟦ (my-add (pct-plus 500 .30)) ⟧
>| *TOTAL*:| *⟦ (format "UGX %s" my-total) 
>⟧*
|===

> Babel also auto-aligns tables in results.

Would it be possible to put Org as Babel source, so that I have Org
table inside of Babel and cause Babel to render automatically on the
end of buffer rendering and invocation of org derived mode?

-- 
Jean

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

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