Re: How to put a string produced by an Elisp form in an Org source block in the Org file?

[Marcin Borkowski]

On 2023-08-05, at 11:49, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>> Thanks a lot, that works!  (Apart from the issue with lines beginning
>> with a star, possibly preceded by whitespace, which are "escaped" with
>> a comma - but that is a known thing in Org, and I can easily circumvent
>> it.)
>
> May you elaborate why you consider this a bug?

I wouldn't call it a bug per se.  If my chart looks like this:

|
*
|*
| *
+--*-

it is displayed in Org example block as

|
,*
|*
| *
+--*-

If I change the character to `#' (which does not have a special meaning
to Org like the asterisk), I get the correct

|
#
|#
| #
+--#-

Sorry for the misunderstanding.  I'm not sure how to word it better,
though...

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Maintenance status of individual Org libraries

[Bastien Guerry]

Ihor Radchenko  writes:

> Should we try to make a call for maintenance at least for some of these
> libraries?

Definitely.  We should probably prioritize files in this list, then
ask on this list *and* on the web.

Let's make sure we propose this as something fun to do, not a chore.

How do you want to proceed?

-- 
 Bastien

Re: svg file from tikz picture

[Bastien Guerry]

Akira Kyle  writes:

> It's been five years since I initially wrote this patch and two years
> since I started my assignment processes 

More precisely: I'll double-check with the FSF legal team that having
your name in the FSF copyright registers means that you can contribute
to Emacs and Org-mode. Probably your university disclaimer was enough.

-- 
 Bastien Guerry

Re: svg file from tikz picture

[Bastien Guerry]

Hi Akira,

Akira Kyle  writes:

> I have been informed that this document my university has
> provided is queued with the FSF legal team for eventual review.

Thanks for your answer.

I suggest we take this off-list and try to sort it out with the FSF
legal team directly.

-- 
 Bastien Guerry

Re: [PATCH] org-manual: Add references to LaTeX docs

[David Masterson]

Minor change below.

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> I think begin.html is a good starting point.  Mentioning 'texdoc latex'
>> is also simple (and more LaTeX specific) and most likely to work.  You
>> could include a parenthetical note that, if it doesn't work, try the
>> URL.  After that, new users can dig through the documentation.
>
> See the attached tentative patch.
>
> From 659d79484fcd280b0ec8d57282588386aa626b21 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <659d79484fcd280b0ec8d57282588386aa626b21.1691049428.git.yanta...@posteo.net>
> From: Ihor Radchenko 
> Date: Thu, 3 Aug 2023 10:56:07 +0300
> Subject: [PATCH] doc/org-manual.org: Refer to LaTeX docs for general
>  terminology
>
> * doc/org-manual.org (LaTeX Export): Add links to online and offline
> LaTeX docs.
> (Quoting LaTeX code): Clarify that direct LaTeX can be used for
> fine-tuning.
>
> Link: 
> https://orgmode.org/list/sj0pr03mb5455b2712fa85ba945dff441a2...@sj0pr03mb5455.namprd03.prod.outlook.com
> ---
>  doc/org-manual.org | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index 16fbb268f..c3a4e47bc 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -13703,6 +13703,13 @@ ** LaTeX Export
>  blank lines in the Org document.  That's because LaTeX itself depends
>  on blank lines to tell apart syntactical elements, such as paragraphs.
>  
> +The following sections expect users to be familiar with common LaTeX
> +terminology.  You may refer to https://tug.org/begin.html to get
> +familiar with LaTeX basics.  Users with LaTeX installed may also run
> +=texinfo latex= from terminal to open LaTeX introduction [fn:: The

I think you meant '=texdoc latex=' here.

> +command will open PDF file, which is also available for download from

Oh, also 'open a PDF file'.

> +http://mirrors.ctan.org/info/latex-doc-ptr/latex-doc-ptr.pdf]
> +
>  *** LaTeX/PDF export commands
>  :PROPERTIES:
>  :DESCRIPTION: For producing @LaTeX{} and PDF documents.
> @@ -13979,9 +13986,10 @@ *** Quoting LaTeX code
>  :DESCRIPTION: Incorporating literal @LaTeX{} code.
>  :END:
>  
> -The LaTeX export backend can insert any arbitrary LaTeX code, see
> -[[*Embedded LaTeX]].  There are three ways to embed such code in the Org
> -file and they all use different quoting syntax.
> +When the available LaTeX export customizations are not sufficient to
> +fine-tune the desired output, it is possible to insert any arbitrary
> +LaTeX code (see [[*Embedded LaTeX]]).  There are three ways to embed such
> +code in the Org file and they all use different quoting syntax.
>  
>  #+cindex: inline, in @LaTeX{} export
>  Inserting in-line quoted with @ symbols:
> -- 
> 2.41.0

Everything else looks good.

-- 
David Masterson

Re: [PATCH] ob-sqlite: Use a transient in-memory database by default

[Rudolf Adamkovič]

Max Nikulin  writes:

> On 05/08/2023 05:57, Rudolf Adamkovič wrote:
>> +*** Make ~ob-sqlite~ use in-database by default
>
> "use in-memory database"

Oops!  Fixed.

>> +SQLite source blocks with no ~:db~ argument now execute against a
>> +transient in-memory database by default.
>
> I am unsure, but perhaps it would be more clear to say that the default 
> value of the header argument has changed and it is possible to omit 
> setting :db per-block or as a header argument. It should give a hint how 
> to revert this change in local configuration if somebody wish it.

Please see the attached Patch 0001A.

> Feel free to just ignore the following. Perhaps to get *really* default 
> behavior ob-sqlite should not check :db value and should not pass it to 
> the command in the case of nil.

This is a good idea!  Please see the attached
alternative Patch 0001B.

> As a result the command spits a warning.

It does?

Rudy
>From 144bd75183a9185786248d9404ddeee4b93ed30f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Wed, 3 May 2023 14:59:03 +0200
Subject: [PATCH] ob-sqlite: Use a transient in-memory database by default

* etc/ORG-NEWS (New features): Add a news entry.
* lisp/ob-sqlite.el (org-babel-default-header-args:sqlite): Default
':db' to ":memory:".
* testing/lisp/test-ob-sqlite.el (ob-sqlite/in-file): Test the old behavior.
* testing/lisp/test-ob-sqlite.el (ob-sqlite/in-memory): Test the new behavior.
---
 etc/ORG-NEWS   |  8 
 lisp/ob-sqlite.el  |  2 +-
 testing/lisp/test-ob-sqlite.el | 36 --
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4f16eda24..569ec651b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -489,6 +489,14 @@ Final hooks are added to the following commands:
 
 The prefix arguments are passed to ~org-insert-todo-heading~.
 
+*** Make ~ob-sqlite~ use in-memory databases by default
+
+The ~:db~ header argument of ~sqlite~ source blocks now defaults to
+~":memory:"~ which stands for a temporary in-memory database.  As a
+result, ~sqlite~ source blocks are usable out of the box, with no
+header arguments, matching the behavior and practicality of the
+official ~sqlite3~ shell.
+
 *** Add support for ~logind~ idle time in ~org-user-idle-seconds~
 
 When Emacs is built with =dbus= support and
diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 526b73ebd..75ef50913 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -39,7 +39,7 @@
 (declare-function orgtbl-to-csv "org-table" (table params))
 (declare-function org-table-to-lisp "org-table" ( txt))
 
-(defvar org-babel-default-header-args:sqlite '())
+(defvar org-babel-default-header-args:sqlite '((:db . ":memory:")))
 
 (defvar org-babel-header-args:sqlite
   '((db. :any)
diff --git a/testing/lisp/test-ob-sqlite.el b/testing/lisp/test-ob-sqlite.el
index 72d75c9b7..621a11b0b 100644
--- a/testing/lisp/test-ob-sqlite.el
+++ b/testing/lisp/test-ob-sqlite.el
@@ -39,8 +39,40 @@
   .import $tb TestTable
   select * from TestTable;
 #+end_src"
-	(org-babel-next-src-block)
-	(org-babel-execute-src-block)
+	   (org-babel-next-src-block)
+	   (org-babel-execute-src-block)
+
+(ert-deftest ob-sqlite/in-memory ()
+  "Test in-memory temporariness."
+  (should
+   (equal 0
+  (progn
+(org-test-with-temp-text
+	 "#+BEGIN_SRC sqlite
+PRAGMA user_version = 1;
+#+END_SRC"
+	 (org-babel-execute-src-block))
+(org-test-with-temp-text
+	 "#+BEGIN_SRC sqlite
+PRAGMA user_version;
+#+END_SRC"
+	 (org-babel-execute-src-block))
+
+(ert-deftest ob-sqlite/in-file ()
+  "Test in-file permanency."
+  (should
+   (equal 1
+  (let ((file (org-babel-temp-file "test" ".sqlite")))
+(org-test-with-temp-text
+	 (format "#+BEGIN_SRC sqlite :db %s
+PRAGMA user_version = 1;
+#+END_SRC" file)
+	 (org-babel-execute-src-block))
+(org-test-with-temp-text
+	 (format "#+BEGIN_SRC sqlite :db %s
+PRAGMA user_version;
+#+END_SRC" file)
+	 (org-babel-execute-src-block))
 
 (provide 'test-ob-sqlite)
 ;;; test-ob-sqlite.el ends here
-- 
2.37.1 (Apple Git-137.1)

>From 34f28236366affb510bfdb70a3577e765d9e0abb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Wed, 3 May 2023 14:59:03 +0200
Subject: [PATCH] ob-sqlite: Use a transient in-memory database by default

* etc/ORG-NEWS (New features): Add a news entry.
* lisp/ob-sqlite.el (org-babel-execute:sqlite): Default ':db' to
":memory:" instead of throwing an error.
* testing/lisp/test-ob-sqlite.el (ob-sqlite/in-file): Test the old behavior.
* testing/lisp/test-ob-sqlite.el (ob-sqlite/in-memory): Test the new behavior.
---
 etc/ORG-NEWS   |  8 
 lisp/ob-sqlite.el  |  3 +--
 testing/lisp/test-ob-sqlite.el | 36 --
 3 files changed, 43 insertions(+), 4 deletions(-)

diff --git 

Re: [ANN] lisp/ob-tangle-sync.el

[Mehmet Tekman]

Hello

> #+begin_src lang :tangle yes foo no bar baz "foo bar"
> should yield
> '("yes" "foo" "no" "bar" "baz" #("foo bar" 0 7 (org-babel-quote t)))
> We will allow using quotes to include whitespace.

> In such scenarios, we still capture this unknown value.
> This is useful for some third-party backends that extend standard header
> args with new possible values.

Okay, I will definitely need to refactor my patches then, but I'm
quite happy with the state of my current patch branch, so it will
be an additional patch instead of a brand new set of patches
I think.

Best,
M

[Help] org-capture: How to capitalize the text entered from the "nth prompt"

[Maske]

Hi

Could it be possible, in org-capture, to capitalize the text entered 
from a previous prompt?



Example:

I have this part of an org-capture template:


* %^{CLIENT} _%^{Project}_ /%^{Description}/
:PROPERTIES:
:DIR: z:/! 2023/%\\1-%\\2-%\\3
:END:


I would like to know if it is possible to “capitalize” the used data 
that I entered before. For example, instead of this:


** Client _Project Number_ /Project description/
:PROPERTIES:
:DIR: z:/! 2023/Client-Project Number-Project description
:END:


Could it be possible to get this? (The 3rd line is “capitalized”):

** Client _Project Number_ /Project description/
:PROPERTIES:
:DIR: z:/! 2023/CLIENT-PROJECT NUMBER-PROJECT DESCRIPTION
:END:


Best regards

Re: svg file from tikz picture

[Akira Kyle]

On Sat, Aug 05, 2023 at 07:29 PM, Bastien Guerry  
wrote:



Ihor Radchenko  writes:


Akira, may I know if you managed to clear the FSF paperwork?


I've just checked and Akira's is a registered FSF contributor 
since

last may.


Unfortunately I was informed that I am only allowed to make 
"small" contributions. I wasn't given any explicit metric of what 
qualifies as a "small" contribution, but was informed that patches 
such as this one are okay for me to contribute.


This is due to my university being unwilling to sign the FSF 
copyright disclaimer without involvement from their legal team 
(although they did sign a standard letter they have saying the 
would never claim copyright over emacs, but that disclaimer does 
not name me personally). I have been informed that this document 
my university has provided is queued with the FSF legal team for 
eventual review.


It's been five years since I initially wrote this patch and two 
years since I started my assignment processes so I haven't really 
had the time or motivation to get this patch into a merge-able 
state. I still use this code quite regularly myself so I'll 
probably get around to working on it again and some point in the 
future.


Akira

Re: Worg: issue with org-tools page

[Bastien Guerry]

Ihor Radchenko  writes:

> So, there is still a problem with ESS installation.
> We may need to update the build manifest yet more.
> Probably "elpa-ess" is installed into some weird place, out of
> load-path.

I added the load-path for ess, this seems to work.

I also added the gnuplot dependency in the build manifest, hopefully
this fixes the last error I've seen.

-- 
 Bastien Guerry

Re: svg file from tikz picture

[Bastien Guerry]

Ihor Radchenko  writes:

> Akira, may I know if you managed to clear the FSF paperwork?

I've just checked and Akira's is a registered FSF contributor since
last may.

-- 
 Bastien Guerry

Re: Issue with dvisvgm Option for Exporting TeX Snippets to HTML

[yc wang]

Understood, I'm currently trying it out. Maybe I'll post later in that thread.

> On Aug 5, 2023, at 22:26, Ihor Radchenko  wrote:
> 
> yc wang  writes:
> 
>> ... Just wondering, will these LaTeX preview changes also be integrated into 
>> HTML publishing? There are many common SVG-related functionalities like 
>> automatic alignment and scaling, equation labeling and positioning, etc.
> 
> By default, HTML export uses MathJax to render LaTeX fragments.
> If MathJax is not used (see org-html-with-latex), preview system is
> utilized to generate formula images.
> 
> Timothy knows more about the details as he tweaked this code in his WIP patch.
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Roshan Shariff]

Hi Ihor,

On Sat, 5 Aug 2023 at 04:23, Ihor Radchenko  wrote:
> First, minor one: please put two spaces between sentences in the commit
> message. It is our convention.
> `file-name-concat' is only available since Emacs 28.
> Please use `org-file-name-concat'.

Thanks for the feedback! I'm attaching a new version of the patch that
improves the commit message and avoids the use of file-name-concat.

> The PROCESS argument can, for example, be `org-latex-pdf-process', which
> promises that "%f in the command will be replaced by the relative file
> name" (see the docstring).

The patch now converts the source to a relative path if it is
absolute. Note that, according to the documentation of
file-relative-name, the path will still be absolute on Microsoft
Windows if the source and the current directory have different drive
letters; this is probably unavoidable. I have also updated the
docstring to clarify which paths are supposed to be relative and which
are absolute.

By the way, I forgot to mention that I ran into this bug while testing
tecosaur's latex-preview patch set on macOS. When running
org-latex-export-to-pdf on an Org file in ~/Dropbox, I got a warning
message about the preamble precompilation failing because it couldn't
find a temporary .tex file in /var. With this patch applied, the PDF
export completes without warnings.

Regards,
Roshan
From 6e1f120818582695da9018f256b00c87104a Mon Sep 17 00:00:00 2001
From: Roshan Shariff 
Date: Fri, 4 Aug 2023 22:10:25 -0600
Subject: [PATCH v2] org-macs: Fix incorrect use of relative paths in
 org-compile-file

* org-macs.el (org-compile-file, org-compile-file-commands): Resolve
symlinks in default-directory before computing relative source path

Commit 5a8a1d4ff [1] changed org-compile-file to use
`file-relative-name` for the SOURCE argument.  This was intended to
fix bug [2] by expanding ~ directories, like a shell.  Unfortunately,
this breaks when DEFAULT-DIRECTORY is a symlink and SOURCE has an
absolute path.

For example, on macOS Ventura, ~/Dropbox is a symlink to
~/Library/CloudStorage/Dropbox.  Suppose DEFAULT-DIRECTORY is
/Users/username/Dropbox and SOURCE is /var/tmp/test.org, so its
relative path is ../../../var/tmp/test.org.  But the working directory
of a compilation process is actually ~/Library/CloudStorage/Dropbox,
relative to which the source path resolves to
/Users/username/var/tmp/test.org.  The process thus cannot find the
source file.

This commit changes `org-compile-file` and its helper function
`org-compile-file-commands` to resolve symlinks in DEFAULT-DIRECTORY
before computing the relative path of SOURCE.  If SOURCE is already
relative, it is used as-is.  The absolute path is processed by
`expand-file-name`, avoiding bug [1].

[1] https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a8a1d4ff
[2] https://orgmode.org/list/25528.42190.53674.62...@gargle.gargle.howl
---
 lisp/org-macs.el | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index e102f01c3..dc5dbeab5 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1607,15 +1607,18 @@ When PROCESS is a list of commands, optional argument LOG-BUF can
 be set to a buffer or a buffer name.  `shell-command' then uses
 it for output."
   (let* ((commands (org-compile-file-commands source process ext spec err-msg))
- (output (expand-file-name (concat (file-name-base source) "." ext)
-   (file-name-directory source)))
+ (output (concat (file-name-sans-extension source) "." ext))
+ (relname (if (file-name-absolute-p source)
+(let ((pwd (file-truename default-directory)))
+  (file-relative-name source pwd))
+  source))
  (log-buf (and log-buf (get-buffer-create log-buf)))
  (time (file-attribute-modification-time (file-attributes output
 (save-window-excursion
   (dolist (command commands)
 (cond
  ((functionp command)
-  (funcall command (shell-quote-argument (file-relative-name source
+  (funcall command (shell-quote-argument relname)))
  ((stringp command) (shell-command command log-buf)
 ;; Check for process failure.  Output file is expected to be
 ;; located in the same directory as SOURCE.
@@ -1649,33 +1652,35 @@ the SOURCE file.
 
 If PROCESS is a list of commands, each of them is called using
 `shell-command'.  By default, in each command, %b, %f, %F, %o and
-%O are replaced with, respectively, SOURCE base name, name, full
-name, directory and absolute output file name.  It is possible,
-however, to use more place-holders by specifying them in optional
-argument SPEC, as an alist following the pattern
+%O are replaced with, respectively, SOURCE base name, relative
+file name, absolute file name, relative directory and absolute
+output file name.  It is possible, 

Re: Issue with dvisvgm Option for Exporting TeX Snippets to HTML

[Ihor Radchenko]

yc wang  writes:

> ... Just wondering, will these LaTeX preview changes also be integrated into 
> HTML publishing? There are many common SVG-related functionalities like 
> automatic alignment and scaling, equation labeling and positioning, etc.

By default, HTML export uses MathJax to render LaTeX fragments.
If MathJax is not used (see org-html-with-latex), preview system is
utilized to generate formula images.

Timothy knows more about the details as he tweaked this code in his WIP patch.

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

Re: Issue with dvisvgm Option for Exporting TeX Snippets to HTML

[yc wang]

Thank you for the information.
It's really impressive. Just wondering, will these LaTeX preview changes also 
be integrated into HTML publishing? There are many common SVG-related 
functionalities like automatic alignment and scaling, equation labeling and 
positioning, etc.

Sincerely,
ywangmy

> On Aug 5, 2023, at 21:09, Ihor Radchenko  wrote:
> 
> yc wang  writes:
> 
>> ... When I enable the dvisvgm option for exporting TeX snippets, I noticed 
>> that the displayed math environment enclosed in \[…\] is not recognized as 
>> "equations," similar to other math environments like 
>> \begin{align*}...\end{align*}, which are placed in a “equation-container” 
>> div tag in HTML. Instead, the generated SVG is simply inserted as an image 
>> like inline math enclosed in \(…\), leading to formatting disorders.
> 
> We are doing major changes in our LaTeX preview code.
> See https://orgmode.org/list/87lek2up0w@tec.tecosaur.net
> You may consider waiting until they are complete or trying the
> experimental code.
> 
> CCing Timothy, the maintainer behind the new preview implementation.
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [patch] Fix inner smart quotes in French

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> And it looks like at least on of the test conditions is not trivial to
>> fix without knowing French. May you or somebody familiar with French
>> punctuation take a look?
>
> I'm afraid I'm not very familiar with the syntax and usage of tests, so
> I have to study that part. I've been looking at
> `test-org-export/activate-smart-quotes', and I have a question: does it
> only include tests for English and French cases?

Yes, currently.

> First level quotes for French are «» with spaces, and second level ones
> (if I'm not mistaken) should be “”, without spaces (my patch fix).
> Therefore, I understand that a line like:
>
>(equal '( "« outer « inner » outer »")
>
> should it be changed like this
>
>(equal '( "« outer “inner” outer »")
>
> ?

That was exactly the piece of information I was missing.
I have no notion of "inner" quotes being different from "outer" in the
languages I am familiar with.

I now managed to fix the tests.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e4f127437

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

Re: Issue with dvisvgm Option for Exporting TeX Snippets to HTML

[Ihor Radchenko]

yc wang  writes:

> ... When I enable the dvisvgm option for exporting TeX snippets, I noticed 
> that the displayed math environment enclosed in \[…\] is not recognized as 
> "equations," similar to other math environments like 
> \begin{align*}...\end{align*}, which are placed in a “equation-container” div 
> tag in HTML. Instead, the generated SVG is simply inserted as an image like 
> inline math enclosed in \(…\), leading to formatting disorders.

We are doing major changes in our LaTeX preview code.
See https://orgmode.org/list/87lek2up0w@tec.tecosaur.net
You may consider waiting until they are complete or trying the
experimental code.

CCing Timothy, the maintainer behind the new preview implementation.

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

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin  writes:

> I was trying to modify publish.sh to collect errors up to a reasonable 
> number, a draft is attached. It can be improved further to save list of 
> failures to some file, so final step of .build.yml may be to check 
> whether this file is empty and to send a notification otherwise.
>
> Currently it just prints summary of failures. When allowed failures 
> count is exceeded, it fails immediately.
>
> ./publish.sh --maxfail 32

I am not sure why it would be useful to limit the number of errors to
anything other than 0/infinity.

Note that I just pushed an alternative (but very similar) change in
https://git.sr.ht/~bzg/worg/commit/b38a1f08

If you think that my commit can be improved, feel free to do it.

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

Re: Worg: issue with org-tools page

[Max Nikulin]

On 31/07/2023 23:41, Ihor Radchenko wrote:

Max Nikulin writes:


I hope, there is a better way to address the issue with failure
notifications.


That sounds too complex.
I think we can simply add an extra "check" task to
https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
It will run after "upload", re-exporting files, but not ignoring errors
this time.


I was trying to modify publish.sh to collect errors up to a reasonable 
number, a draft is attached. It can be improved further to save list of 
failures to some file, so final step of .build.yml may be to check 
whether this file is empty and to send a notification otherwise.


Currently it just prints summary of failures. When allowed failures 
count is exceeded, it fails immediately.


./publish.sh --maxfail 32
...
org-release-notes.org: Could not find plantuml.jar at 
/usr/share/plantuml/plantuml.jar

org-faq.org: Could not find ditaa.jar at /usr/bin/ditaa
org-blog-wiki.org: Unable to resolve link: 
"[https://github.com/kaushalmodi/ox-hugo/tree/master/test/site/content-org;

library-of-babel.org: Symbol’s function definition is void: fib
org-tutorials/images-and-xhtml-export.org: Unable to resolve link: 
"worg/images/orgmode/org-mode-unicorn.png"

org-tools/index.org: Cannot open load file: No such file or directory, ess
org-contrib/babel/intro.org: Could not find ditaa.jar at /usr/bin/ditaa
org-contrib/babel/languages/ob-doc-scheme.org: Symbol’s value as 
variable is void: geiser-default-implementation
org-contrib/babel/languages/ob-doc-ditaa.org: Could not find ditaa.jar 
at /usr/bin/ditaa
org-contrib/babel/languages/ob-doc-LaTeX.org: Cannot open load file: No 
such file or directory, ess
org-contrib/babel/examples/org-check.org: Symbol’s value as variable is 
void: org-latex-to-pdf-process
org-contrib/babel/examples/lob-table-operations.org: Symbol’s function 
definition is void: flet

org-contrib/babel/examples/foo.org: Inline error: list result cannot be used
org-contrib/babel/examples/drift.org: Could not find ditaa.jar at 
/usr/bin/ditaa
org-contrib/babel/examples/data-collection-analysis.org: Cannot open 
load file: No such file or directory, ess
org-contrib/babel/examples/ascii.org: Cannot open load file: No such 
file or directory, ess
org-contrib/babel/examples/Rpackage.org: Cannot open load file: No such 
file or directory, ess




publish.sh
Description: application/shellscript

Re: Emacs 29.1, org-agenda and SCHEDULED entries

[Ihor Radchenko]

Christian Barthel  writes:

> while upgrading from emacs 28.1 to 29.1, my org-agenda stopped working.
> The message in the echo area was:
>
> --8<---cut here---start->8---
> Search failed: "\\]+\\)>"
> --8<---cut here---end--->8---
>
> The search seemed to fail in an old org file:
>
> --8<---cut here---start->8---
>   * someentry
> SCHEDULED: [2017-12-12 Tue 17:42]
> --8<---cut here---end--->8---
>
> Not sure why I've used an inactive timestamp there but it shouldn't
> be a problem I guess?

It is exactly the problem.
Inactive timestamps are not allowed in SCHEDULED/DEADLINE.

> Was/Is that change on purpose? (I haven't seen anything in the
> ChangeLog)

Only internals changed. Previously, agenda used a dumb regexp search
using this failing regexp (and skipped your problematic entry
completely). Now, we first query parser cache, which considers your
"someentry" as :scheduled. But agenda expects scheduled items to use
active timestamps all the time, causing the error.

We should update the parser to treat such malformed SCHEDULED/DEADLINE
lines as ordinary paragraphs and report them in org-lint.

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

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Bastien Guerry  writes:

>> What about the other approach I proposed?
>> (where we export skipping errors first, upload, and then re-export,
>> catching all errors this time just to trigger an email to notify about
>> the failure).
>
> Yes, let's do this.

Ok. I added a new --debug command line argument to publish.sh and a new
"check" task that will generate non-zero exit code yet uploading the
successfully exported pages.

https://git.sr.ht/~bzg/worg/commit/b38a1f08
https://git.sr.ht/~bzg/worg/commit/f049752b

... And we are (hopefully) done with a side line of the original bug
report.

The original problem was
Cannot open load file: No such file or directory, ess

So, there is still a problem with ESS installation.
We may need to update the build manifest yet more.
Probably "elpa-ess" is installed into some weird place, out of
load-path.

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

Re: org-agenda queries for absent properties

[Jens Schmidt]

On 2023-08-02  08:45, Ihor Radchenko wrote:

> `rx' would be great.
> But even adding comments like in your example would be an improvement.

Since the future of this code snippet seems to be uncertain I went for
comments only.

And I thought I was pretty much done when I noticed at least one major
issues in the existing code, so I decided to go with a prerelease first
plus some notes and questions.

So there will be a follow up to the attached patch, and I leave it to
you whether you give it already a review or not.  But I'd ask you for
your opinion on the following notes, where the first few should be
uncritical:

- I used "\(?NUM: ... \)" constructs to explicitly number the subres.
  Hope this is OK w.r.t. style and backward-compatibility.

- I fixed the operator-matching subre to also include `==', `!=', `/='
  but exclude `<<' and the like which currently give void-function
  errors.

- I did not fix some "a[^b]*b"-style subres to use non-greedy variants
  since these are strictly speaking not identical.  Even though newline
  characters shouldn't play a big role here ...

- I likewise did not fix the number-matching subre allowing for numbers
  like "1.2.3" to keep things short at least there.  `string-to-number'
  silently takes care of these, even if an exponent gets lost that way.

But from here it gets more intersting:

- The code uses subre "-" in property names to (supposedly) allow
  for inclusion of minus characters in property names, which (probably)
  could be confused with term negation.

- It also unquotes these minus characters for {tag regexps}:

(tag (save-match-data
   (replace-regexp-in-string
"-" "-" (match-string 2 term

  But it never unquotes them in property names.  That missing unquoting
  could be easily amended, but:

- The other issue is: Why do we need "-" for both property names and
  {tag regexps}?  This forces us to do queries like:

{[a\\-z]}|foo\\-bar="baz"

  where in my opinion

{[a\-z]}|foo\-bar="baz"

  should be sufficient.

- Even more, IMO one could do away completely with the minus-quoting and
  unquoting, since the overall regexp should allow for unambiguously
  matching minus characters both

  + in {tag regexps} (because of "{[^}]+}" gobbling them) and

  + in property names (because a property name must always be followed
by some operator)

  *without* them getting confused with term negation.

  Or do I miss something here?  A cursory test with sth like

+foo-bar="xxx"-patchday=202302

  seems to work fine.

- However, removing the unquoting of {tag regexps} would be a breaking
  change.  Even though I doubt anybody has ever used it, the more it is
  not mentioned in the documentation.

> I had this in mind for a wile, but I am still hoping that we can
> eventually (when it is added to Emacs) rely upon peg.el for parsing.

Given the fact that we have to discuss issues like those above, I
heartily agree.

> https://yhetil.org/emacs-devel/875yvtbbn3@ericabrahamsen.net/

Arthouse thread: Interesting plot, surprising sidelines, not everything
comprehensible, (unfortunately) open end.
From 1765e91d2f7875b321703afe34e32754a022bef4 Mon Sep 17 00:00:00 2001
From: Jens Schmidt 
Date: Thu, 3 Aug 2023 22:34:56 +0200
Subject: [PATCH] org-make-tags-matcher: Add starred property operators, more
 operator synonyms

* lisp/org.el (org-make-tags-matcher): Add starred property operators.
Recognize additional operators "==", "!=", "/=".  Clean up and
document match term parsing.
(org-op-to-function): Recognize additional inequality operator "/=".

* doc/org-manual.org (Matching tags and properties):
* etc/ORG-NEWS: (~org-tags-view~ supports more property operators):
* testing/lisp/test-org.el (test-org/map-entries): Add documentation,
announcement, and tests on starred and additional operators.
---
 doc/org-manual.org   | 20 -
 etc/ORG-NEWS | 10 -
 lisp/org.el  | 96 +---
 testing/lisp/test-org.el | 33 ++
 4 files changed, 130 insertions(+), 29 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 16fbb268f..27051fbfc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9246,16 +9246,25 @@ When matching properties, a number of different operators can be used
 to test the value of a property.  Here is a complex example:
 
 #+begin_example
-+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
++work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<*2
  +With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
 #+end_example
 
+#+cindex: operator, for property search
 #+texinfo: @noindent
 The type of comparison depends on how the comparison value is written:
 
 - If the comparison value is a plain number, a numerical comparison is
   done, and the allowed operators are =<=, ===, =>=, =<==, =>==, and
-  =<>=.
+  =<>=.  As synonym for the equality operator there is also , as
+  synonyms for the inequality 

Re: [patch] Fix inner smart quotes in French

[Juan Manuel Macías]

Hi, Ihor,

Ihor Radchenko writes:

> Welcome back :)

thanks! :-)

>> In the meantime, I'm submitting this patch with a fix for second-level
>> French `smart quotes': the correct quotes should be “” (without spaces,
>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>> wrong...).
>
> The patch does not update the tests. So, we now have
> FAILED   644/1151  test-org-export/activate-smart-quotes
>
> And it looks like at least on of the test conditions is not trivial to
> fix without knowing French. May you or somebody familiar with French
> punctuation take a look?

I'm afraid I'm not very familiar with the syntax and usage of tests, so
I have to study that part. I've been looking at
`test-org-export/activate-smart-quotes', and I have a question: does it
only include tests for English and French cases?

First level quotes for French are «» with spaces, and second level ones
(if I'm not mistaken) should be “”, without spaces (my patch fix).
Therefore, I understand that a line like:

   (equal '( "« outer « inner » outer »")

should it be changed like this

   (equal '( "« outer “inner” outer »")

?

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Issue with dvisvgm Option for Exporting TeX Snippets to HTML

[yc wang]

Dear Community,

I hope this letter finds you well. My name is ywangmy, and I am an avid user of 
org-export for exporting TeX snippets to HTML. First and foremost, I want to 
extend my appreciation for the hard work and dedication put forth by the 
developers to create such a valuable tool.

I am writing to bring to your attention a particular issue that I encountered. 
When I enable the dvisvgm option for exporting TeX snippets, I noticed that the 
displayed math environment enclosed in \[…\] is not recognized as "equations," 
similar to other math environments like \begin{align*}...\end{align*}, which 
are placed in a “equation-container” div tag in HTML. Instead, the generated 
SVG is simply inserted as an image like inline math enclosed in \(…\), leading 
to formatting disorders.

I kindly request the esteemed developers to consider modifying the 
org-html--math-environment-p function(if my tracking of the exporting utility 
is accurate) accordingly. By ensuring that the dvisvgm option (or any other 
options that insert TeX snippets as images) treats the displayed math 
environment as "equations," it would substantially improve the formatting and 
overall user experience when exporting TeX snippets to HTML.

Thank you for your attention, and I look forward to your valuable contributions 
to this matter.

Sincerely,
ywangmy

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Ihor Radchenko]

Roshan Shariff  writes:

> * org-macs.el (org-compile-file, org-compile-file-commands): Avoid
> converting the source path to be relative to the default-directory,
> which breaks for absolute source paths when the current directory is a
> symlink.
>
> Commit 5a8a1d4ff [1] changed org-compile-file to use
> `file-relative-name` for the source argument. This was intended to fix
> bug [2] by expanding ~ directories in the source path, like a shell.

Thanks for the report and for providing a detailed explanation with a
patch!

I have a few comments.

First, minor one: please put two spaces between sentences in the commit
message. It is our convention.

> - (output (expand-file-name (concat (file-name-base source) "." ext)
> -   (file-name-directory source)))
> + (output (file-name-concat (file-name-directory source)
> +   (concat (file-name-base source) "." ext)))

`file-name-concat' is only available since Emacs 28.
Please use `org-file-name-concat'.

> -  (?f . ,(shell-quote-argument relative-name))
> +  (?f . ,(shell-quote-argument source))

This will break user expectations.
The PROCESS argument can, for example, be `org-latex-pdf-process', which
promises that "%f in the command will be replaced by the relative file
name" (see the docstring).

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

Re: How to put a string produced by an Elisp form in an Org source block in the Org file?

[Ihor Radchenko]

Marcin Borkowski  writes:

> Thanks a lot, that works!  (Apart from the issue with lines beginning
> with a star, possibly preceded by whitespace, which are "escaped" with
> a comma - but that is a known thing in Org, and I can easily circumvent
> it.)

May you elaborate why you consider this a bug?

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

Re: Maintenance status of individual Org libraries

[Ihor Radchenko]

Ihor Radchenko  writes:

> Should we try to make a call for maintenance at least for some of these
> libraries?

Ping!

Re: svg file from tikz picture

[Ihor Radchenko]

Bastien Guerry  writes:

>>> The last message I received from them was over a month ago and my 
>>> last follow up email to them was ten days ago.
>>
>> Bastien, may you follow up with Craig about the status?
>
> I don't see the FSF copyright assignment status for
> ak...@akirakyle.com - please CC me if you write to Craig again so I
> can follow up directly there.

It has been a while since the last email in this thread.
Akira, may I know if you managed to clear the FSF paperwork?

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

Re: [ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Ihor Radchenko]

Ihor Radchenko  writes:

> We thus need volunteers to help maintaining Org LaTeX export library -
> lisp/ox-latex.el

This is a very late followup...

Leo Butler, Eric Fraga, and Pedro Andres Aranda Gutierrez previously
expressed an interest in maintaining lisp/ox-latex.el.

If you are still into it, please submit a patch adding yourself to
;; Maintainer: line in lisp/ox-latex.el.

Bastien can then help you with getting write access to Org repo.

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

Re: For your consideration: Extending org-info-js with additional hooks

[Ihor Radchenko]

"David O'Toole"  writes:

> Ok, I will get started on this :)

Hi,

It has been a while since the last email in this thread.
May I know if you are still interested in taking over the maintenance of
org-info-js?

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

Re: [ANN] Looking for new maintainers for ox-html.el

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> I depend on ox-html for my personal website. I would be glad to help.

Arne, sorry for the very late reply.
If you are still willing to help with the maintenance, may you please
submit a patch adding yourself to ;; Maintainer: line in
lisp/ox-html.el?

Bastien can then help you with getting write access to Org repo.

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

Re: How to put a string produced by an Elisp form in an Org source block in the Org file?

[Marcin Borkowski]

On 2023-08-04, at 22:20, Marcin Borkowski  wrote:

> On 2023-08-04, at 10:03, Ihor Radchenko  wrote:
>
>> Marcin Borkowski  writes:
>>
>>> I have an Elisp form in an Org source block, returning a (multi-line)
>>> string.  I'd like to put that string into the same Org buffer.  I tried
>>> `:results raw', but the string contains `|' characters, so Org treats
>>> its as a table and tries to format it as such, which is not what I want.
>>>
>>> How to do that?
>>
>> Maybe :wrap example?
>
> Thanks a lot, that works!  (Apart from the issue with lines beginning
> with a star, possibly preceded by whitespace, which are "escaped" with
> a comma - but that is a known thing in Org, and I can easily circumvent
> it.)
>
> BTW, that means that my blog post for this weekend (about plotting
> charts from Org tables, all within Org mode and using ASCII art) is
> basically almost ready!

And here it is:
https://mbork.pl/2023-08-05_Plotting_ASCII_art_charts_from_Org_mode_tables

Thanks again!

-- 
Marcin Borkowski
http://mbork.pl

Re: [PATCH] ob-sqlite: Use a transient in-memory database by default

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> P.S. #1: This is my first contribution to the
> WORG, and I am not sure if the patch is OK.
> I do ever not plan to contribute to the WORG,
> as I am not a fan of the idea and think that
> all built-in backends (and more!) should be
> documented in the Org manual.

See https://orgmode.org/list/87lefgi58c.fsf@localhost

> P.S. #2: The Table of Contents (TOC) on the
> WORG is "jumpy" on Safari.  In fact, it has
> always been problematic for me, in one way or
> another.  Why cannot TOC be included at the
> beginning of the document, like in standard
> Org exports?  Org and Emacs manuals, with no
> "smart" side bars, get it right, IMO.

See https://orgmode.org/list/87cz7ubnxb.fsf...@gnu.org

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

Re: Worg: issue with org-tools page

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> I am not sure.
> We now got exactly the concern Max raised: New commits do not update
> WORG as long as even a single WORG page is broken:
> https://builds.sr.ht/~bzg/job/1035051

Mh, yes, I reverted this change.

> What about the other approach I proposed?
> (where we export skipping errors first, upload, and then re-export,
> catching all errors this time just to trigger an email to notify about
> the failure).

Yes, let's do this.

-- 
 Bastien Guerry

Re: [ANN] lisp/ob-tangle-sync.el

[Ihor Radchenko]

Mehmet Tekman  writes:

> * Under vanilla `org-babel-merge-params', any number of :tangle header
>   values are permitted and concatenated together.
>
>   e.g 4:
>   __
>   ´
> (should  ;; 4.
> override-document-and-parent-header-with-local-tfile-and-action
>  (equal '(:tangle "randomfile sync")
> (org-test-with-temp-text
> "\
>   #+PROPERTY: header-args :tangle /tmp/default_tangle.txt
>   * Four
>   :PROPERTIES:
>   :header-args: :tangle \"newfile.txt\" import
>   :END:
>   ** A
>   #+begin_src conf :tangle randomfile sync
>   #+end_src"
>   (test-ob/get-src-block-property :tangle
>   `---
>
>   This result of "randomfile sync" for the :tangle header is seen as
>   valid but it shouldn't, should it? Tangle can only take one value,
>   so the action of `:any` should also just output one value?
>
>   From the docstring text:
>
>   > Symbol `:any' in the value list implies that any value is allowed.
>
>   It's not clear to me if this means that `:any' or `:any :any` or
>   `":any :any"` is permitted.
>
>   In my rewrite, I very much take the `:any` or `":any :any"` single
>   value interpretation when merging the headers together.

It is not possible to distinguish between `:any' and `:any any' without
reading the user's mind :)
So, we can choose arbitrarily.

Since the previous version of the code used split-string and
unconditionally split the arguments at whitespace, I am inclined to
prefer `:any :any' over greedy version.

So,

#+begin_src lang :tangle yes foo no bar baz "foo bar"

should yield

'("yes" "foo" "no" "bar" "baz" #("foo bar" 0 7 (org-babel-quote t)))

We will allow using quotes to include whitespace.

> * Sometimes the value of another header is caught in the value of
>   another
>
>   e.g 8: "wrap" is caught in the output of `:results' despite it not being
>  a valid results keyword in `org-babel-common-header-args-w-values'.
>
>__
>   ´
> (should  ;; 8. test-results-and-exports
>  (equal '(:results "wrap file replace" :exports "code")
> (org-test-with-temp-text
> "\
>   * Eight
>   #+begin_src sh :results file wrap
>   #+end_src"
>   (test-ob/get-src-block-property '(:results :exports)
> (should  ;; 9. do-not-tangle-this-block --
>   `---
>
>   This test results in "true" for both my rewrite, and the vanilla
>   function, but I'm not sure how accurate or value this is.

This is basically a question about what to do when user supplies
incorrect value of a header arg.

In such scenarios, we still capture this unknown value.
This is useful for some third-party backends that extend standard header
args with new possible values.

Hope the above makes sense.

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

Emacs 29.1, org-agenda and SCHEDULED entries

[Christian Barthel]

Hi,

while upgrading from emacs 28.1 to 29.1, my org-agenda stopped working.
The message in the echo area was:

--8<---cut here---start->8---
Search failed: "\\]+\\)>"
--8<---cut here---end--->8---

The search seemed to fail in an old org file:

--8<---cut here---start->8---
  * someentry
SCHEDULED: [2017-12-12 Tue 17:42]
--8<---cut here---end--->8---

Not sure why I've used an inactive timestamp there but it shouldn't
be a problem I guess?

As a workaround, I have updated the `org-schedule-time-regexp` to
match the brackets as well:

--8<---cut here---start->8---
(setq org-scheduled-time-regexp
  (concat "\\<" org-scheduled-string " *[[<]\\([^]>]+\\)[]>]"))
--8<---cut here---end--->8---

With that new regexp, my agenda loads again without errors but
I do wonder:


Was/Is that change on purpose? (I haven't seen anything in the
ChangeLog)

-- 
Christian Barthel

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> I am attaching tentative patch that will revert demoting errors to
>> messages. However, I do not fully understand the purpose of the original
>> `condition-case' code in the publish.sh. Bastien?
>
> Applied.  I'm aware it only fixes part of the issue at hand, but I
> believe this is already better.

I am not sure.
We now got exactly the concern Max raised: New commits do not update
WORG as long as even a single WORG page is broken:
https://builds.sr.ht/~bzg/job/1035051

What about the other approach I proposed?
(where we export skipping errors first, upload, and then re-export,
catching all errors this time just to trigger an email to notify about
the failure).

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

Re: [patch] Fix inner smart quotes in French

[Ihor Radchenko]

Juan Manuel Macías  writes:

> These last months I have been disconnected from the list for family
> reasons. Now, trying to catch up with the news on the list and pending
> things that I left here :-).

Welcome back :)

> In the meantime, I'm submitting this patch with a fix for second-level
> French `smart quotes': the correct quotes should be “” (without spaces,
> as in Spanish or Greek) (please, some francophone correct me, if I'm
> wrong...).

The patch does not update the tests. So, we now have
FAILED   644/1151  test-org-export/activate-smart-quotes

And it looks like at least on of the test conditions is not trivial to
fix without knowing French. May you or somebody familiar with French
punctuation take a look?

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