Re: Init.el need just for org-mode?

[tomas]

On Wed, Nov 02, 2022 at 09:15:04PM +0100, Renato Pontefice wrote:
> are You telling that you put more .el files on .emacs.d folder, each one 
> contain some customization of emacs (or org-mode?)
> This is interesting for me.

No. By default, Emacs just loads ~/.emacs.d/init.el /or/ ~/.emacs.

Everything else can be arranged from there. For example, to split
out the custom.el file (where customize writes its stuff), I have
those two lines in my ~/.emacs.d/init.el:

  (setq custom-file "~/.emacs.d/custom.el")
  (load custom-file)

Then, I have a subdirectory of ~/.emacs.d (concretely: ~/.emacs.d/lisp)
where I keep all my local little things I make myself. To be able to
easily load those without always naming the full path, I have in my
~/.emacs.d/init.el:

  (add-to-list 'load-path "~/.emacs.d/lisp")

And so on.

Still I propose you start with an empty init file. Once you find a
thing you /want/ your Emacs to do always at start, you can start
populating your ~/.emacs or ~/.emacs.d/init.el (each approach has
some up- and downsides, but that's not so important: you'll find
out and you'll be able to switch easily).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Maxima code blocks does not work in windows revisited

[Max Nikulin]

On 03/11/2022 03:11, Leo Butler wrote:

On Wed, Nov 02 2022, Max Nikulin wrote:


On 02/11/2022 11:47, Ihor Radchenko wrote:

(for reference, this email is a followup of
https://orgmode.org/list/ca+ikm3wqa33xp4c3pvv+f2a-gn0dbezsdx6vf2crd+37+u6...@mail.gmail.com)


Ihor, you recently applied an alternative patch to Org main
branch. Emacs tree still has ob-maxima.el with single quotes around
batchload.

Nikolay Kudryavtsev. Re: [PATCH] ob-maxima.el: Fix execution on MS
Windows. Thu, 30 Dec 2021 23:54:10 +0300.
https://list.orgmode.org/8cd49b4c-9342-a77f-d665-402c41432...@gmail.com


diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index dba12d7b6..52423db18 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -84,7 +84,7 @@ (defun org-babel-execute:maxima (body params)
(cmd (format "%s --very-quiet -r %s$ %s"
 org-babel-maxima-command
   (shell-quote-argument
-  (format "batchload(%S)" in-file))
+  (format "\"batchload(\\\"%S\\\")\"" in-file))


Notice that code in the message you cited has "%s" and does not have
`shell-quote-argument'. Extra quotes may discard effect of existing
double pass escaping.


Yes, OP should try this solution first. If it fails, then there is
some problem in `shell-quote-argument' that needs to be fixed.


To be clear. I believe that Mati should try the code from the Org "main" 
branch, not the patch Ihor posted in this thread. If I got it correctly, 
Mati currently has some problems with plots, ghostscript, etc.


Is there anything wrong with the following command (I am unsure 
concerning Temp location)? If so, what is the proper escaping for 
cmd.exe+maxima?


(let ((system-type 'ms-dos)
  (org-babel-maxima-command "maxima")
  (in-file "c:\\Temp\\maxima-XX.max")
  (cmdline ""))
  (message
   "%s"
   (format "%s --very-quiet -r %s$ %s"
   org-babel-maxima-command
   (shell-quote-argument
(format "batchload(%S)" in-file))
   cmdline)))

maxima --very-quiet -r "batchload(\"c:\\Temp\\maxima-XX.max\")"$

(there is a trailing space)

[PATCH] Improve Org Babel LaTeX + Inkscape

[Rudolf Adamkovič]

Greetings!

The attached two patches improve Org Babel LaTeX export to SVG using
Inkscape.  See the commit messages for more details.  Thank you.

Rudy

>From 569675be7881d4bdd3a2589491d7ee5396c27314 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Thu, 3 Nov 2022 00:53:01 +0100
Subject: [PATCH 1/2] ob-latex: Export the full area of the drawing

* lisp/ob-latex.el (org-babel-latex-pdf-svg-process): Add the argument
-D (--export-area-drawing) to avoid sub-point cuts on hi-DPI screens,
where Inkscape sometimes cuts off a single physical pixel from the
exported drawing.
---
 lisp/ob-latex.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index a86699e22..c39c9c5d3 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -110,7 +110,7 @@ exporting the literal LaTeX source."
   :type 'function)
 
 (defcustom org-babel-latex-pdf-svg-process
-  "inkscape --pdf-poppler %f -T -l -o %O"
+  "inkscape --pdf-poppler %f -D -T -l -o %O"
   "Command to convert a PDF file to an SVG file."
   :group 'org-babel
   :type 'string)
-- 
2.38.1

>From 126b6b77b0a700740f837f729a0a6050e0837f71 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Thu, 3 Nov 2022 01:05:47 +0100
Subject: [PATCH 2/2] ob-latex: Call Inkscape with descriptive arguments

* lisp/ob-latex.el (org-babel-latex-pdf-svg-process): Use descriptive
arguments, such as '--export-area-drawing' instead of '-D', to
optimize for readability and not brevity (which makes sense for
interactive use, which does not apply here).
---
 lisp/ob-latex.el | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index c39c9c5d3..69124a36c 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -110,7 +110,13 @@ exporting the literal LaTeX source."
   :type 'function)
 
 (defcustom org-babel-latex-pdf-svg-process
-  "inkscape --pdf-poppler %f -D -T -l -o %O"
+  "inkscape \
+--pdf-poppler \
+--export-area-drawing \
+--export-text-to-path \
+--export-plain-svg \
+--export-filename=%O \
+%f"
   "Command to convert a PDF file to an SVG file."
   :group 'org-babel
   :type 'string)
-- 
2.38.1

-- 
"Strange as it may sound, the power of mathematics rests on its evasion
of all unnecessary thought and on its wonderful saving of mental
operations."
-- Ernst Mach, 1838-1916

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

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

[Joost Kremers]

On Sun, Oct 30 2022, Ihor Radchenko wrote:
> May I know if there is any update on the copyright assignment situation?
> If you need any help, we can provide it.

I have signed the form and sent it in, and I have received the counter-signed
form back from the FSF.

Parsebib's Github page mentions 6 contributors, however, and I have no idea if
they all have copyright assignments, or if their contributions are small enough
not to require one.

I could dive into that and see if we need more copyright assignments, or I could
ask for parsebib to be included in non-GNU Elpa, which would probably be faster.
Don't know if you have a preference.

-- 
Joost Kremers
Life has its moments

RE: org-assert-version considered harmful

[Cook, Malcolm]

> > Then, when I occasionally wished to update org, I would
> >
> > `cd ~/.emacs.d/org-mode && git pull && make autoloads && make`
> >
> > Recently I started getting errors invalid-function "org-assert-version".
> >
> > Upon cursory reading of this thread I guessed that I could fix them by 
> > adding a `make clean` to my update mantra.
> 
> It should not be necessary and it does not happen on my side (as you can
> imagine, I re-compile very often).

Perhap's my issue stems from the particular versions of org I was upgrading 
between and/or (earlier) poor management of multiple contending org versions 
(e.g. git head v. melpa v. system).

> 
> Could you provide more details?

At this point, I am not seeking to reproduce the issue, but rather to ensure 
that my current practice is "best" practice, given my aim of staying current 
with head (understanding and accepting that this may bring its own 
instabilities).

So the details I can provide are probably around how I 

protect against multiple contending org versions
obtain and build org sources
load/require/use the built org sources

The very first thing in my init.el is intended to help protect against 
contending org versions:

```
(require 'cl-seq)
(delete (car (cl-member "lisp/org" load-path :test  #'string-match)) 
;; "as extra level of precaution against getting the built-in
;; org-mode, I ensure it never gets loaded" - kudos:
;; 
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00130.html
load-path)
```

If I want to install the latest org from melpa, I never do this from within an 
active emacs session but rather from the (linux) command line as:

```
emacs -Q -batch -eval "(progn (require 'package) (package-initialize)  
(package-refresh-contents) (package-install 'org))"
```

But more often, I strive to stay abreast of developments, and when I see an 
issue I care about discussed as being addressed with a source code change, I go 
get it

```
cd ~/.emacs.d/org-mode && git pull && make clean && make autoloads && make 
PERL5LIB=
```

And then relaunch emacs, where it gets picked up due to:

```
(use-package org ;org-plus-contrib  ; instead of org-mode
  :pin manual 
  :load-path "~/.emacs.d/org-mode/lisp"
...
)
```

... which occurs very early in my init file (just after bootstrapping package 
system and latest use-package).

So, I've got (again) a working strategy.  

I'm really wondering if all this is needlessly complex.

Anyway, thanks for chiming in!

Re: Init.el need just for org-mode?

[Charles Millar]

On 11/2/22 13:31, Renato Pontefice wrote:

I’m sorry for this simply question, but I’m starting using emacs and org-mode 
and I made some confusion.

Init.el

Need just for org -mode? Not for emacs right?

Thank you

Renato

Forgot to mention, and you may already be aware of this,

use

C-h v user-init-file

to find your init.el file

How to set monospace font face for org-agenda calendar?

[Mati]

Hi. I tried to assign monospace font to calendar in org-agenda but it 
looks it uses default face. How I can set it then?

Re: Init.el need just for org-mode?

[Charles Millar]

On 11/2/22 13:31, Renato Pontefice wrote:

I’m sorry for this simply question, but I’m starting using emacs and org-mode 
and I made some confusion.

Init.el

Need just for org -mode? Not for emacs right?


You  may use init.el (or .emacs of .emacs.d/init.el) file for all of 
emacs.not just Org mode.


For instance my init.el includes settings for the display, printer 
selection, what spelling package to use,  and others.


Is also is used to load packages that are not included in the "basic" 
emacs distribution (which contains quite a few).


HTH.

Charlie Millar

Re: Init.el need just for org-mode?

[Renato Pontefice]

are You telling that you put more .el files on .emacs.d folder, each one 
contain some customization of emacs (or org-mode?)
This is interesting for me.

Renato

> Il giorno 2 nov 2022, alle ore 20:24, to...@tuxteam.de ha scritto:
> 
> On Wed, Nov 02, 2022 at 01:36:00PM -0400, Jude DaShiell wrote:
>> .emacs could be used for orgmode as well as init.el.  I have all my
>> orgmode stuff in my .emacs.
>> What I don't yet know are any advantages of using init.el as opposed to
>> .emacs.
> 
> I switched (long ago) from .emacs to init.el. The reason was just
> having one top-level directory (.emacs.d) in my home directory
> where all "the other local emacs-y stuff" goes.
> 
> I also separated custom.el out, to give customize an own file to
> chew on: it's happier this way :-)
> 
> (I have lots of other things in .emacs.d, neatly packaged in different
> little boxes -- oops, there they are, again ;-)
> 
> Cheers
> -- 
> t

Re: Maxima code blocks does not work in windows revisited

[Leo Butler]

On Wed, Nov 02 2022, Max Nikulin  wrote:

> On 02/11/2022 11:47, Ihor Radchenko wrote:
 (for reference, this email is a followup of
 https://orgmode.org/list/ca+ikm3wqa33xp4c3pvv+f2a-gn0dbezsdx6vf2crd+37+u6...@mail.gmail.com)
>
> Ihor, you recently applied an alternative patch to Org main
> branch. Emacs tree still has ob-maxima.el with single quotes around
> batchload.
>
> Nikolay Kudryavtsev. Re: [PATCH] ob-maxima.el: Fix execution on MS
> Windows. Thu, 30 Dec 2021 23:54:10 +0300. 
> https://list.orgmode.org/8cd49b4c-9342-a77f-d665-402c41432...@gmail.com
>
>> diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
>> index dba12d7b6..52423db18 100644
>> --- a/lisp/ob-maxima.el
>> +++ b/lisp/ob-maxima.el
>> @@ -84,7 +84,7 @@ (defun org-babel-execute:maxima (body params)
>>  (cmd (format "%s --very-quiet -r %s$ %s"
>>   org-babel-maxima-command
>>   (shell-quote-argument
>> -  (format "batchload(%S)" in-file))
>> +  (format "\"batchload(\\\"%S\\\")\"" in-file))
>
> Notice that code in the message you cited has "%s" and does not have
> `shell-quote-argument'. Extra quotes may discard effect of existing 
> double pass escaping.

Yes, OP should try this solution first. If it fails, then there is
some problem in `shell-quote-argument' that needs to be fixed.

My 2c.
Leo

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

[Leo Butler]

Hi,

In worg's documentation of ob-maxima.el[fn:1], there are several bugs.


1. In the subsection `Inline Display of Maxima LaTeX Output', the
results are missing. This is because the code block is named
`solve-maxima', the same as in the section `Solver'. Export results in
that output being put in the `Solver' section (I don't know if that
should be considered a bug in Org). On the webpage, the errant output
has been deleted. The correct output in both sections should be
included.

2. In `3D Plots', the header arguments do not result in a link to a
generated file being created on evaluation of the code block. I am
unsure if this is a bug in Org, ob-maxima.el or ob-doc-maxima.org or
what. On reading the description of the =:results graphics=
header[fn:2], it looks like there is blame to go around. Related: in
ob-doc-octave.org, the graphics example only includes a =:results file=
header argument.

The attached patch to ob-doc-maxima.org fixes only the documentation
issues:

1. Present the correct output of code block `solve-maxima'.
2. Add the header argument `file' to the `3d-maxima' example to create a
correct link and graphics file.
3. Rename the tex code block to `tex-maxima' and change the results type
to =latex= to generate correct output.

TIA,
Leo Butler

[fn:1]
https://orgmode.org/worg//org-contrib/babel/languages/ob-doc-maxima.html
[fn:2] (info "(org) Results of Evaluation")

diff --git a/org-contrib/babel/languages/ob-doc-maxima.org b/org-contrib/babel/languages/ob-doc-maxima.org
index 810c9ef4..f1388187 100644
--- a/org-contrib/babel/languages/ob-doc-maxima.org
+++ b/org-contrib/babel/languages/ob-doc-maxima.org
@@ -137,6 +137,12 @@ Of course, =maxima= is more than a calculator.
   print(solution);
 #+end_src
 
+#+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 +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
 ,#+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,14 +160,14 @@ 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 graphics file
 #+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
+#+RESULTS: 3d-maxima
 [[file:images/maxima-3d.png]]
 
 ** Inline Display of Maxima LaTeX Output
@@ -170,19 +176,24 @@ This example is from [[http://maxima.sourceforge.net/maxima-gnuplot.html][a tuto
   example.
 
 #+begin_example
-,#+NAME: solve-maxima
-,#+HEADER: :exports none
-,#+BEGIN_SRC maxima :results raw
+,#+NAME: tex-maxima
+,#+HEADER: :exports results
+,#+BEGIN_SRC maxima :results latex
   tex(exp(-x)/x);
 ,#+END_SRC
 #+end_example
 
-#+NAME: solve-maxima
+#+NAME: tex-maxima
 #+HEADER: :exports results
-#+BEGIN_SRC maxima :results raw
+#+BEGIN_SRC maxima :results latex
   tex(exp(-x)/x);
 #+END_SRC
 
+#+RESULTS: tex-maxima
+#+begin_export latex
+$${{e^ {- x }}\over{x}}$$
+#+end_export
+
 *** 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

Re: Init.el need just for org-mode?

[tomas]

On Wed, Nov 02, 2022 at 06:45:36PM +0100, Renato Pontefice wrote:
> Maybe I’m not so skilled to emacs. I’ve found org-mode that do things that I 
> find useful. I speak about init.el because I think this is the place where I 
> can set some things to do with org-mode, i.e. Can I set deadline to view in 
> emacs without org-mode?I’m simply looking for a good PIM that I can customize 
> with a simple text file…

It's all the same. Emacs looks for an ~/.emacs and for ~/.emacs.d/init.el
They are just two alternatives with slightly different flavour, but the
same function. (But take into account that I have no clue how/where those
things live under Windows).

I'd propose to start with an empty ~/.emacs (or ~/.emacs.d/init.el) and
only put things in there when you are convinced that you need them. Otherwise
you'll never know for sure what they are doing.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Init.el need just for org-mode?

[tomas]

On Wed, Nov 02, 2022 at 01:36:00PM -0400, Jude DaShiell wrote:
> .emacs could be used for orgmode as well as init.el.  I have all my
> orgmode stuff in my .emacs.
> What I don't yet know are any advantages of using init.el as opposed to
> .emacs.

I switched (long ago) from .emacs to init.el. The reason was just
having one top-level directory (.emacs.d) in my home directory
where all "the other local emacs-y stuff" goes.

I also separated custom.el out, to give customize an own file to
chew on: it's happier this way :-)

(I have lots of other things in .emacs.d, neatly packaged in different
little boxes -- oops, there they are, again ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

processing a literal example line by line in a shell source block?

[Greg Minshall]

hi.  i have a text in a named #+begin_example ... #+end_example block.
i would like to process this text line by line in a shell (bash, say)
code block.  but, it appears that the individual lines are not
separated, but passed as one long string to the source block.  (example
below.)

is there a magic incantation i can use to accomplish this?

cheers, Greg

#+name: lbl
#+begin_example
line 1
line 2
#+end_example

#+begin_src bash :var input=lbl :var in2='("first" "second")
  echo ${#input[@]}
  echo ${#in2[@]}
  echo ${input}
#+end_src

#+RESULTS:
|1 |   |  |   |
|2 |   |  |   |
| line | 1 | line | 2 |

Re: [PATCH][oc-csl] Improve reference parsing

[András Simonyi]

Dear All,

On Wed, 2 Nov 2022 at 07:28, Ihor Radchenko  wrote:

> I do not think that CSL limitations are really limiting us.
>
> - Allowing macros will be handled by ox.el itself automatically
> - Export snippets can also be processed without much issue (consider
>   direct LaTeX code)
> - inline-babel-call and inline src blocks may be useful with :exports
>   results when some auto-generation of text is needed. They will also be
>   handled automatically by ob-exp.
> - latex-fragments are either equivalent to direct LaTeX or to inserting
>   an image
> - timestamps could be exported as text, although I do not see any
>   obvious utility of timestamps inside references.

I'm not really familiar with the internals of the Org exporter but,
looking at the ox.el code, macros and babel calls are processed and
resolved before processing citations, so they seemingly have no
bearing on the org-cite-csl--parse-reference function my patch is
concerned with.

> However, oc-csl should not ignore the export processor to support all
> the above. I am not sure why you need a dedicated export processor
> instead of passing the string to current processor (or derivative)
> instead.

> If you really need to mark certain constructs specially for CSL, you can
> create a derived export backend for the current backend and replace the
> transcoders for the object types that must be treated specially.

Other than macros and babel calls, e.g., timestamps, LaTeX  fragments
etc. the problem is that citeproc-el expects and needs the affixes and
locator to be passed in the very limited html-like markup supported by
CSL (see https://www.zotero.org/support/kb/rich_text_bibliography for
a rudimentary description), and, crucially, the assumption is that
everything else is plain text, which, if necessary, will be escaped
according to the target format, i.e., '$' signs are escaped by
citeproc-el's own LaTeX formatter. The reason for this limitation is
that the affixes and especially the locator have to be parsed into
citeproc-el's internal rich-text representation for further processing
according to the used CSL style. (Affixes are only concatenated to
other elements but locators can be the subject of any type of
formatting.)  As a consequence, I think the only real alternatives are
using a custom backend as I do in the current patch or a backend
derived from the plain text Org exporter -- I don't have a strong
preference as to which solution we choose, just went with the
seemingly more minimalist option. (The proper way of dealing with
LaTeX fragments in this context, in particular with LaTeX math
fragments, would be to support those in citeproc-el's internal
representation and markup, which is planned but not implemented yet.)

> > +(defconst org-cite-csl--export-backend
> > +  (org-export-create-backend
> > +   :transcoders
> > +   '((bold . (lambda (_bold contents _info) (format "%s" contents)))
> > + (code . org-cite-csl--element-value)
> > + (entity . (lambda (entity _contents _info)
> > + (format "\\%s" (org-element-property :name entity
>
> Why :name, but not :html?

Good point, thinking about it a bit more, :utf-8 would probably be a
slightly better solution (in keeping with citeproc-el's 'plain text'
requirement), I'will change this when we will have sorted out the
other details.

best wishes,
András

Re: Init.el need just for org-mode?

[Renato Pontefice]

Maybe I’m not so skilled to emacs. I’ve found org-mode that do things that I 
find useful. I speak about init.el because I think this is the place where I 
can set some things to do with org-mode, i.e. Can I set deadline to view in 
emacs without org-mode?I’m simply looking for a good PIM that I can customize 
with a simple text file…

Renato

> Il giorno 2 nov 2022, alle ore 18:36, Jude DaShiell  ha 
> scritto:
> 
> .emacs could be used for orgmode as well as init.el.  I have all my
> orgmode stuff in my .emacs.
> What I don't yet know are any advantages of using init.el as opposed to
> .emacs.
> 
> 
> 
> Jude  "There are four boxes to be used in
> defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> 
> .
> 
> On Wed, 2 Nov 2022, Renato Pontefice wrote:
> 
>> I?m sorry for this simply question, but I?m starting using emacs and 
>> org-mode and I made some confusion.
>> 
>> Init.el
>> 
>> Need just for org -mode? Not for emacs right?
>> 
>> Thank you
>> 
>> Renato
>> 

Re: Init.el need just for org-mode?

[Jude DaShiell]

.emacs could be used for orgmode as well as init.el.  I have all my
orgmode stuff in my .emacs.
What I don't yet know are any advantages of using init.el as opposed to
.emacs.



Jude  "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Wed, 2 Nov 2022, Renato Pontefice wrote:

> I?m sorry for this simply question, but I?m starting using emacs and org-mode 
> and I made some confusion.
>
> Init.el
>
> Need just for org -mode? Not for emacs right?
>
> Thank you
>
> Renato
>

Init.el need just for org-mode?

[Renato Pontefice]

I’m sorry for this simply question, but I’m starting using emacs and org-mode 
and I made some confusion.

Init.el

Need just for org -mode? Not for emacs right?

Thank you

Renato

Re: [PATCH] ob-sql: Respect database param when using dbconnection

[Daniel Kraus]

Ihor Radchenko  writes:

>> Otherwise, the patch itself is not much and I use it daily.
>
> Thanks!
> Applied onto main with minor amendments to the commit message (I added
> "." at the end of the sentences).
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fbbc8b55cf3a39c85f8576321ec560baf4d2331a

Thanks.


> P.S. ob-sql currently have no maintainer. Do you want to volunteer?

Hmm, ob-sql is the the babel module I use most often.
I don't think I'll have enough time to make bigger changes etc,
but from what I know that's not necessary or expected.
I'm certainly willing to look at patches, answer bug reports
and join discussion about ob-sql.

tl;dr you can add me as a maintainer ;)

Cheers,
  Daniel

Re: [BUG] ox-odt file: links are not pointing to the real files (was: [BUG] ox-odt fails for org-id links (e.g., from org-roam v2) [9.5.2 (9.5.2-gfbff08 @ /home/moritz/.emacs.d/elpa/27.2/develop/org-9

[Max Nikulin]

On 02/11/2022 12:04, Ihor Radchenko wrote:

See the attached new version of the patch.


The patch looks reasonable. I have not tried it in action though.


Max Nikulin  writes:

   [[file:file-b.org]]

"../file-b.org" is appropriate default description. I do not expect
"../" here.


I also noticed this, but I feel that it is reasonable. In odt,
"file-b.org" implies a resource inside the odt archive. "../file-b.org"
will highlight that it is an external file.

I'd prefer to leave the "../file" description for now and only do
something when/if we hear from the ox-odt users.


While e.g. EPUB may have multiple content files inside the container, I 
am unaware of similar feature for ODF. E.g. master document is linked to 
other "containers", not to files inside the same container. I consider 
links to resources inside .zip as something really special. I am afraid 
that "../" will cause user confusion like we had in the beginning.

Re: Line breaks and brackets in LaTeX export

[Max Nikulin]

On 02/11/2022 13:46, Ihor Radchenko wrote:

Ihor Radchenko writes:


Should we, instead of using exact "\\[0pt]" string for line breaks,
define a new LaTeX command and then clean it up? This will distinguish
between \\[0pt] added by users explicitly and the ones generated
automatically by Org.


I guess it will not work for that fancy table package we discussed
above.


tabularray package will require \NewTableCommand


Maybe the Max's idea with "\\[0pt]%some comment indicator"?
I am just worried that % does have side effects in LaTeX.


TeX reads

"a% comment
  b"

as "ab", dropping newline and starting spaces. Of course, advanced users 
may redefine category of "%" from comment to something else (regular 
character, command prefix like \, etc.) like it is done inside verbatim 
environment.

Re: Docstrings and literate programming (good practices?)

[Juan Manuel Macías]

Ihor Radchenko writes:

> Can you elaborate about "paragraph is exported as verbatim"?

Sorry for the conciseness in my previous explanation. I meant something
like this:

: foo

is exported to LaTeX as

\begin{verbatim}
foo
\end{verbatim}

(and what i want is for it to be exported as 'normal text').

>> Actually I don't know if it's good practice to do it like this, hence my
>> doubts about how to 'marry' the literate programming concept with
>> languages that support docstring, which, somehow, are largely
>> self-documenting (thanks to the existence of the docstring itself) . The
>> scenario would rather be in long, multi-paragraph docstrings. Then this
>> dilemma comes to me: if I am doing literate programming and I want to
>> explain in detail what the function x does, I write it in the main text
>> as part of the documentation. But also that explanation should be a
>> docstring, in the source file. I understand that the docstring would not
>> appear in the PDF (to avoid redundancy), but I don't know if it would be
>> a good practice either, since the docstring belongs to the code...
>>
>> In short, my dilemma is: how to do good literate programming with a
>> language like Elisp, which is almost self-documenting in its code? (So
>> one can learn a lot about Elisp just by reading the code in the *.el
>> files, without going to the documentation (which is a great strength of
>> Elisp, by the way).
>
> I'd do something like the following:
> 1. Use normal Org text for docstring marked with some kind of block
>container (#+begin_docstring..#+end_docstring) or a dedicated
>headline.
> 2. Extend Org with some fancy links specific to docstring. That way, the
>original document can be read with active links to, say, other
>functions and variables. (I think Doom is using something like this
>for its new docs. Timothy is working on this)
> 3. Those links will be transformed to online documentation links on
>normal export.
> 4. For docstrings, on tangle, the links will be processed via
>`org-export-string-as' with a specialized backend that can escape
>what is needed for the target language docstring and transform Org
>links into whatever the docstring format is used for internal
>docstring references.
> 5. For docstrings, on export, the noweb will generate something like
>"[docstring is detailed in the text]", maybe even with a hyperlink to
>the docstring in text.
>
> Hope it makes sense.   

I like the idea, because of the possibility of being able to use links.
That would also be respectful of the docstring as a legitimate part of
the code (in my approach, removing the docstring during export leaves an
empty line in the code, which is weird). Anyway, I think that with my
approach using org blocks and noweb references, links can also be used,
although more at a user/home-made level, with some export filter, I
suppose, that would convert the noweb reference into a normal link.

By the way, thinking about it, I don't know if a hypothetical header arg
called :docstring would be ok, something like:

#+NAME: foo
#+begin_
blah
#+end_

#+begin_src emacs-lisp :docstring foo
(defun foo ()
(message "hello world"))
#+end_src

And the docstring would be formatted and placed depending on the
language and the code (https://en.wikipedia.org/wiki/Docstring).

I don't know if something like this would make sense; although, thinking
about it, I like your idea of using special links better because it is
more versatile and (I guess) simpler to implement.

Best regards,

Juan Manuel 

Re: Maxima code blocks does not work in windows revisited

[Max Nikulin]

On 02/11/2022 11:47, Ihor Radchenko wrote:

(for reference, this email is a followup of
https://orgmode.org/list/ca+ikm3wqa33xp4c3pvv+f2a-gn0dbezsdx6vf2crd+37+u6...@mail.gmail.com)


Ihor, you recently applied an alternative patch to Org main branch. 
Emacs tree still has ob-maxima.el with single quotes around batchload.


Nikolay Kudryavtsev. Re: [PATCH] ob-maxima.el: Fix execution on MS 
Windows. Thu, 30 Dec 2021 23:54:10 +0300. 
https://list.orgmode.org/8cd49b4c-9342-a77f-d665-402c41432...@gmail.com



diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index dba12d7b6..52423db18 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -84,7 +84,7 @@ (defun org-babel-execute:maxima (body params)
(cmd (format "%s --very-quiet -r %s$ %s"
 org-babel-maxima-command
  (shell-quote-argument
-  (format "batchload(%S)" in-file))
+  (format "\"batchload(\\\"%S\\\")\"" in-file))


Notice that code in the message you cited has "%s" and does not have 
`shell-quote-argument'. Extra quotes may discard effect of existing 
double pass escaping.



  cmdline)))
   (with-temp-file in-file (insert (org-babel-maxima-expand body 
params)))
   (message cmd)


Really robust solution require a dedicated maxima option that allows to 
pass file name as a separated argument instead of a part of expression,

Re: [PATCH] Ignore flaky ob-python tests

[Ihor Radchenko]

Ihor Radchenko  writes:

> Jack Kamm  writes:
>
>> Christian Köstlin  writes:
>>
>>> I think we know of the async problem, and you reported that as well,
>>> so I would expect
>>> if someone is able to fix it, he will also move the tests to "sharp" again.
>>
>> Could you provide some references about the async problem, either how to
>> reproduce it or the underlying cause? I tried searching emacs-orgmode
>> and emacs-devel, but couldn't find a report of the problem.

Also, 
https://lists.sr.ht/~bzg/org-build-failures/%3CCNZYPX9R5ABN.VI1C53TZJSTI%40cirno2%3E

BTW, Christian, failures of tests in the patch are valid failures that
revealed a real problem.
See https://orgmode.org/list/87bkprid1d.fsf@localhost

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

Re: [PATCH] Ignore flaky ob-python tests

[Ihor Radchenko]

Jack Kamm  writes:

> Christian Köstlin  writes:
>
>> I think we know of the async problem, and you reported that as well,
>> so I would expect
>> if someone is able to fix it, he will also move the tests to "sharp" again.
>
> Could you provide some references about the async problem, either how to
> reproduce it or the underlying cause? I tried searching emacs-orgmode
> and emacs-devel, but couldn't find a report of the problem.

https://lists.sr.ht/~bzg/org-build-failures/%3CCNRV9YIXSILF.2AF0TMJG974H4%40cirno%3E


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

Re: [PATCH] Ignore flaky ob-python tests

[Jack Kamm]

Christian Köstlin  writes:

> I think we know of the async problem, and you reported that as well,
> so I would expect
> if someone is able to fix it, he will also move the tests to "sharp" again.

Could you provide some references about the async problem, either how to
reproduce it or the underlying cause? I tried searching emacs-orgmode
and emacs-devel, but couldn't find a report of the problem.

Re: Docstrings and literate programming (good practices?)

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> Why do you need to strip docstring on export?
>
> Thanks for the suggestion. The problem with doing it this way is that
> the paragraph is exported as verbatim, and I want it to be exported as a
> normal part of the text. For example, in a PDF or HTML it would say
> something like:
>
> ---
> This awesome function is for blah blah, and makes blah blah, when blah blah.
>
> [the function code]
> ---

Can you elaborate about "paragraph is exported as verbatim"?

> Actually I don't know if it's good practice to do it like this, hence my
> doubts about how to 'marry' the literate programming concept with
> languages that support docstring, which, somehow, are largely
> self-documenting (thanks to the existence of the docstring itself) . The
> scenario would rather be in long, multi-paragraph docstrings. Then this
> dilemma comes to me: if I am doing literate programming and I want to
> explain in detail what the function x does, I write it in the main text
> as part of the documentation. But also that explanation should be a
> docstring, in the source file. I understand that the docstring would not
> appear in the PDF (to avoid redundancy), but I don't know if it would be
> a good practice either, since the docstring belongs to the code...
>
> In short, my dilemma is: how to do good literate programming with a
> language like Elisp, which is almost self-documenting in its code? (So
> one can learn a lot about Elisp just by reading the code in the *.el
> files, without going to the documentation (which is a great strength of
> Elisp, by the way).

I'd do something like the following:
1. Use normal Org text for docstring marked with some kind of block
   container (#+begin_docstring..#+end_docstring) or a dedicated
   headline.
2. Extend Org with some fancy links specific to docstring. That way, the
   original document can be read with active links to, say, other
   functions and variables. (I think Doom is using something like this
   for its new docs. Timothy is working on this)
3. Those links will be transformed to online documentation links on
   normal export.
4. For docstrings, on tangle, the links will be processed via
   `org-export-string-as' with a specialized backend that can escape
   what is needed for the target language docstring and transform Org
   links into whatever the docstring format is used for internal
   docstring references.
5. For docstrings, on export, the noweb will generate something like
   "[docstring is detailed in the text]", maybe even with a hyperlink to
   the docstring in text.

Hope it makes sense.   

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

[Juan Manuel Macías]

Ihor Radchenko writes:

> Why do you need to strip docstring on export?

Hi Ihor,

Thanks for the suggestion. The problem with doing it this way is that
the paragraph is exported as verbatim, and I want it to be exported as a
normal part of the text. For example, in a PDF or HTML it would say
something like:

---
This awesome function is for blah blah, and makes blah blah, when blah blah.

[the function code]
---

But in the source file, that text would be a docstring, inside the
function code.

Actually I don't know if it's good practice to do it like this, hence my
doubts about how to 'marry' the literate programming concept with
languages that support docstring, which, somehow, are largely
self-documenting (thanks to the existence of the docstring itself) . The
scenario would rather be in long, multi-paragraph docstrings. Then this
dilemma comes to me: if I am doing literate programming and I want to
explain in detail what the function x does, I write it in the main text
as part of the documentation. But also that explanation should be a
docstring, in the source file. I understand that the docstring would not
appear in the PDF (to avoid redundancy), but I don't know if it would be
a good practice either, since the docstring belongs to the code...

In short, my dilemma is: how to do good literate programming with a
language like Elisp, which is almost self-documenting in its code? (So
one can learn a lot about Elisp just by reading the code in the *.el
files, without going to the documentation (which is a great strength of
Elisp, by the way).

Best regards,

Juan Manuel 

Re: Internal linking in org-mode opens tags table

[Ihor Radchenko]

Nathan Furnal  writes:

> I'm using the latest snapshot of org-mode and internal linking seems to fail. 
> When visting an internal link, the tags table is opened instead of simply 
> going to the place in the file which the link points to.
>
> To reproduce, just open an org file:
>
> * Hello
>
> Link to [[*Hello]]

I created a file containing

-
* Hello

Link to [[*Hello]]
-

Then I ran make repro in the main branch of the latest Org

I opened the file

I put the point at the link and pressed C-c C-o.

The point correctly jumps to * Hello heading.

I cannot reproduce the issue.

Can you try to repeat the steps I described?
Also, see https://orgmode.org/manual/Feedback.html#Feedback

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

Internal linking in org-mode opens tags table

[Nathan Furnal]

Hi all,

I'm using the latest snapshot of org-mode and internal linking seems to fail. 
When visting an internal link, the tags table is opened instead of simply going 
to the place in the file which the link points to.

To reproduce, just open an org file:

* Hello

Link to [[*Hello]]


Cheers,

Nathan

Re: [PATCH] Ignore flaky ob-python tests

[Christian Köstlin]

On Wed, Nov 2, 2022 at 7:52 AM Ihor Radchenko  wrote:
>
> Christian Köstlin  writes:
>
> > The new async feature of python seems to be implemented in a way
> > that can break with high CPU load. This patch still runs the 3 tests in
> > question, but does not fail the complete testsuite if any of those fail.
>
> Thanks for the patch, but I'm afraid that it will drive the tests useless.
> After the patch, even if the tests fail for a valid reason, it will not
> be visible upon running make test, AFAIU.
I think we know of the async problem, and you reported that as well,
so I would expect
if someone is able to fix it, he will also move the tests to "sharp" again.
With my patch the tests are still failing but the testsuite continues
to run and returns
with 0 as status code (one can see the failed test though).

> Maybe we can instead provide some variable that can turn-on ignoring
> some problematic tests only during CI tests?
Yes ... that would also be possible e.g. skip the test or test nothing
if it's running on the ci.
(I am talking only about the 3 tests!).

Kind regards,
Christian

Re: [PATCH] ob-maxima.el: Fix execution on MS Windows

[Nikolay Kudryavtsev]

Oh, nice. Thank you.

I was starting to wonder what happened to this.

Re: Docstrings and literate programming (good practices?)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> The first (org-block) for long-form text (like official javadoc), the
> second (just verbatim) for shorter docstrings.

For even shorter docstrings, you can just #+name a paragraph.

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

Re: [BUG] ob-python: async session evaluation does not support python-mode.el [9.6-pre (release_9.5.5-2661-g2d040b.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Jack Kamm]

Hi Ihor,

Ihor Radchenko  writes:

> However, async evaluation fails when org-babel-python-mode is set to
> 'python-mode.

As a stopgap, perhaps Org could issue an error message that async is not
implemented for python-mode.el

I was actually planning to deprecate ob-python support for
python-mode.el, because I don't think it's worth the extra complexity &
burden to support 2 python modes. For users who prefer python-mode, I
think it would be better to have a separate ob-python-mode, perhaps in
org-contrib. There was a related discussion about this [1] a couple
years ago.

However, I never got around to deprecating python-mode support, as I
have been unable to work on ob-python for the last 1.5+ years due to
employment changes and subsequent copyright problems (my employer's
lawyers have some issues with the FSF's form, and I am waiting for the
FSF to review their proposed changes). I was hoping it would be resolved
by now, but it's still pending, and I should be removed as ob-python
maintainer since my hands are tied.

[1] https://list.orgmode.org/87d0a95eyz@bzg.fr/

Re: Docstrings and literate programming (good practices?)

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> Juan Manuel Macías  writes:
>
>> #+NAME: docstring1
>> #+begin_src org :post format-docstring(*this*) :results replace :exports 
>> results :tangle no
>>   Lorem ipsum dolor sit amet.
>>
>>   Consectetuer adipiscing elit. "Donec hendrerit tempor tellus". Donec 
>> pretium posuere
>>   tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. 
>> Cum sociis
>>   natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. 
>> #+end_src
>
> You can also have
>
> #+name: docstring1
> :   Lorem ipsum dolor sit amet.
>
> :
> :   Consectetuer adipiscing elit. "Donec hendrerit tempor tellus". Donec 
> pretium posuere
> :   tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. 
> Cum sociis
> :   natoque penatibus et magnis dis parturient montes, nascetur ridiculus 
> mus. 
>
>> #+begin_src emacs-lisp :noweb strip-export :exports code
>>   (defun foo ()
>><>
>> (message "hello world"))
>> #+end_src

Both of these options look awesome! Thank you for sharing!

The first (org-block) for long-form text (like official javadoc), the
second (just verbatim) for shorter docstrings.

They finally solve a long-standing problem for me.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [O] Maxima code blocks does not work in windows revisited

[Ihor Radchenko]

Mati  writes:

> Ok, I tried this patch, but now when I try to eval maxima code it 
> outputs similar broken table:
>
> | incorrect | syntax: | c | is | not | an | infix | operator |
> | ^    |    |   |   | |    |  | |
>
> Plots have no output as before.

Could you please describe what exactly you tried, what you expected, and
what you got?

My patch should be equivalent to originally proposed, but
I am not exactly sure what you have applied on your side. And I have no
idea which table you are talking about.

See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: [O] Maxima code blocks does not work in windows revisited

[Mati]

Ok, I tried this patch, but now when I try to eval maxima code it 
outputs similar broken table:


| incorrect | syntax: | c | is | not | an | infix | operator |
| ^    |    |   |   | |    |  | |

Plots have no output as before.

To clarify, previous patch worked except plots. And of course I applied 
patch to fresh org repo downloaded with straight.el

Re: Are colons forbidden for TODO keywords?

[Ihor Radchenko]

Tommy Kelly  writes:

> *Am I correct that colons are forbidden for TODO keywords (at very least as
> the last character)? *
> I can't see an explicit prohibition in the manual, or in
> https://orgmode.org/worg/dev/org-syntax.html, but I'm seeing behavior that
> suggests there perhaps should be, as follows.

Colons should be allowed, AFAIK.

> However I've just noticed that the colons do seem to be a problem for smart
> tree construction. For example, if I run 'C-c / T' and provide "DONE:"
> (with colon) as the keyword, no headlines are found, despite there being
> many with that keyword in the relevant file. But if I provide "DONE" (no
> colon)[1] as the keyword, then all of my "DONE:" (with colon) headlines are
> found.

Could you please provide an MWE?
See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: Can someone give an init.el wherein can start customize it?

[Ihor Radchenko]

Renato Pontefice  writes:

> Maybe I think my init.el is too dirty.
> Can someone give me an init.el that I can use as base to customize (if I 
> want) something that can works without correct the old one 

I strongly recommend you to go through some beginner videos explaining
Emacs configuration bit by bit.

For example,
https://www.youtube.com/playlist?list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
https://www.youtube.com/playlist?list=PLVtKhBrRV_ZkPnBtt_TD1Cs9PJlU0IIdE


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

Juan Manuel Macías  writes:

> #+NAME: docstring1
> #+begin_src org :post format-docstring(*this*) :results replace :exports 
> results :tangle no
>   Lorem ipsum dolor sit amet.
>
>   Consectetuer adipiscing elit. "Donec hendrerit tempor tellus". Donec 
> pretium posuere
>   tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. 
> Cum sociis
>   natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. 
> #+end_src

You can also have

#+name: docstring1
:   Lorem ipsum dolor sit amet.
:
:   Consectetuer adipiscing elit. "Donec hendrerit tempor tellus". Donec 
pretium posuere
:   tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. 
Cum sociis
:   natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. 

> #+begin_src emacs-lisp :noweb strip-export :exports code
>   (defun foo ()
><>
> (message "hello world"))
> #+end_src
>
> The only drawback is that with :noweb strip-export an empty line is
> left.

Why do you need to strip docstring on export?

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

Re: [PATCH] Ignore flaky ob-python tests

[Ihor Radchenko]

Christian Köstlin  writes:

> The new async feature of python seems to be implemented in a way
> that can break with high CPU load. This patch still runs the 3 tests in
> question, but does not fail the complete testsuite if any of those fail.

Thanks for the patch, but I'm afraid that it will drive the tests useless.
After the patch, even if the tests fail for a valid reason, it will not
be visible upon running make test, AFAIU.

Maybe we can instead provide some variable that can turn-on ignoring
some problematic tests only during CI tests?

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

Ihor Radchenko  writes:

> Should we, instead of using exact "\\[0pt]" string for line breaks,
> define a new LaTeX command and then clean it up? This will distinguish
> between \\[0pt] added by users explicitly and the ones generated
> automatically by Org.

I guess it will not work for that fancy table package we discussed
above. Maybe the Max's idea with "\\[0pt]%some comment indicator"?
I am just worried that % does have side effects in LaTeX.

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

> Another corner case when "\\[0pt]\n" should not be blindly replaced to 
> "\\\n" (I do not escape "\"). Imagine that you are going to describe 
> this optimizing filter
>
>  >8 
> Optimizing filter will replace
> #+begin_example
> First\\[0pt]
> Second
> #+end_example
> with
> #+begin_example
> First\\
> Second
> #+end_example
>  8< -

This is a strong argument against auto-removing the \\[0pt].
Should we, instead of using exact "\\[0pt]" string for line breaks,
define a new LaTeX command and then clean it up? This will distinguish
between \\[0pt] added by users explicitly and the ones generated
automatically by Org.

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

Are colons forbidden for TODO keywords?

[Tommy Kelly]

*Am I correct that colons are forbidden for TODO keywords (at very least as
the last character)? *
I can't see an explicit prohibition in the manual, or in
https://orgmode.org/worg/dev/org-syntax.html, but I'm seeing behavior that
suggests there perhaps should be, as follows.

So, for vaguely aesthetic reasons, I decided I'd like my TODO keywords to
end in colons. That is: TODO:, INPROGRESS:, DONE:, and so on; instead of
just TODO, INPROGRESS, DONE, etc. And it seemed to work fine. At very least
for things like cycling through sequences, quick selection, color and other
face attributes, and so on, there didn't seem to be any issue.

However I've just noticed that the colons do seem to be a problem for smart
tree construction. For example, if I run 'C-c / T' and provide "DONE:"
(with colon) as the keyword, no headlines are found, despite there being
many with that keyword in the relevant file. But if I provide "DONE" (no
colon)[1] as the keyword, then all of my "DONE:" (with colon) headlines are
found.

As I say, I can't find anything in the documentation saying that colons are
forbidden, but it's beginning to feel like it. Does that sound credible, in
which case does the documentation need a tweak? Or was there no intention
to restrict colon use, in which case is it the sparse tree construction
code that needs tweaked?

thanks,
Thomas

[1] Having first added "DONE" to org-todo-keywords, so as to allow it to be
a valid choice for 'C-c / T'

[DISCUSSION] Unified handling of links between Org files on export (was: export and cross links between files)

[Ihor Radchenko]

Max Nikulin  writes:

> On 01/11/2022 12:48, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> It seems org-id.el should be extended to handle some features common to
>>> all formats such as custom suffix instead of ".org"
>> 
>> Could you please elaborate?
>
> Currently ox-html has an option to replace links to .org files with 
> links to exported .html files. I suppose, this option should be 
> generalized to other export backends. It is up to user to set 
> appropriate target format to get cross links between exported files.

Some export processors (like ox-texinfo) can export to multiple output
formats. A simple defcustom will not cut it because one may want
different link transformations depending on the issued export command.

I am not sure if there is a clean generalized way to implement link
transformations on ox.el level. Individual backends may support this
better.

I guess a possible somewhat generic solution could be adding a new key
to org-export-define-backend and org-export-define-derived-backend.
Specifically for transforming links to other org files.

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

Re: [PATCH][oc-csl] Improve reference parsing

[Ihor Radchenko]

András Simonyi  writes:

> thanks for pointing out the problem!! I've attached a new version of
> the patch, in which the custom exporter backend has an (in many cases
> trivial) translator for all currently allowed objects.

Thanks!

>> And we may add more, as discussed in
>> https://orgmode.org/list/87k04xhhw3.fsf@localhost
>
> I don't think that it would make much sense to add a lot more, with
> the possible exception of links, since citations are at most
> sentence-sized textual units, not to mention the possible
> complications arising for the existing export processors. (What type
> of objects could the various LaTeX-based exporters support without
> complex changes?)  Since CSL has only a few types of formatting
> attributes (font-style, font-variant, font-weight, text-decoration and
> vertical-align), if the set of allowed object is radically expanded
> then it will probably be more reasonable to define a derived backed,
> maybe based on the ascii exporter, but I feel that the current set
> doesn't require this solution.

I do not think that CSL limitations are really limiting us.

- Allowing macros will be handled by ox.el itself automatically
- Export snippets can also be processed without much issue (consider
  direct LaTeX code)
- inline-babel-call and inline src blocks may be useful with :exports
  results when some auto-generation of text is needed. They will also be
  handled automatically by ob-exp.
- latex-fragments are either equivalent to direct LaTeX or to inserting
  an image
- timestamps could be exported as text, although I do not see any
  obvious utility of timestamps inside references.

However, oc-csl should not ignore the export processor to support all
the above. I am not sure why you need a dedicated export processor
instead of passing the string to current processor (or derivative)
instead.

If you really need to mark certain constructs specially for CSL, you can
create a derived export backend for the current backend and replace the
transcoders for the object types that must be treated specially.

> +(defconst org-cite-csl--export-backend
> +  (org-export-create-backend 
> +   :transcoders
> +   '((bold . (lambda (_bold contents _info) (format "%s" contents)))
> + (code . org-cite-csl--element-value)
> + (entity . (lambda (entity _contents _info)
> + (format "\\%s" (org-element-property :name entity

Why :name, but not :html?

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

Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option

[Ihor Radchenko]

Daniel Ziltener  writes:

>> Could you please create a separate patch file and attach it in the
>> reply?
> Sure, here's the patch attached, as generated by "git format-patch 
> origin/main".

Thanks!

I tried to apply your patch and run tests. The new test for
"strip-tangle" is failing on my side.

Also, several small comments about the commit message.

> * lisp/ob-tangle.el (org-babel-tangle-single-block): strip noweb tags
> from block if :noweb has been set to strip-tangle.
> * lisp/ob-core.el (org-babel-common-header-args-w-values): add
> "strip-tangle" as new allowed value.
> * testing/lisp/test-ob-tangle.el (ob-tangle/strip-tangle): add new test
> case for strip-tangle.
> * doc/org-manual.org (Noweb Reference Syntax): adjust documentation for
> the noweb header argument.
> * etc/ORG-NEWS: add entry for new header argument value.

Please start sentences with capital letter.  Also, use "strip-tangle" or
strip-tangle consistently.

> This patch adds the "strip-tangle" option for the :noweb header
> argument. This strips the noweb tags before tangling the block. This can
  ^"  "

We use double space between sentences in commit messages as well. Not
only in the documentation.

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