kaobook tex template integration to a org file to make self-contained, portable?

[Zenny]

Hi,

References of interest:
1. https://github.com/fmarotta/kaobook
2. https://github.com/asilata/emacsconf2021

Can anyone guide me how to get a self-contained and portable template that
executes kaobook tex templates (see 1) to create an org-file that resembles
with the instance in 2 above?

I tried the best I can by adding the kaobook.cls and kaobook.sty files
inside `~/texmf/tex/latex/kaobook/` folder and specified 'kaobook' in the
`#+latex_class: kaobook` but it failed to produce the desired look of pdf
similar to
https://github.com/fmarotta/kaobook/blob/master/example_and_documentation.pdf
withing the same examples directory!

Any input appreciated!

Cheers and have a nice week,
/z

Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files

[Jakob Schöttl]

Am 01.08.23 um 13:27 Ihor Radchenko:

Jakob Schöttl  writes:


The structure of the org file is attached. I tried for two hours to
provide a minimal example org file but – like randomly – when I shorten
the file radically or remove fields from the colmunview it works. I
can't figure out what exactly makes org mode struggling.

Even if I delete all content in the file where lines do not start with
regex /^\*/ or /^:[a-zA-Z]/, the inserted table is incomplete.

Can someone help to debug this further?

It is hard to help much here without more details.
You may have to debug `org-dblock-write:columnview'.

What is your version of Org? Have you tried the latest dev version?
Latest release?

Thanks Ihor for your reply. I just checked, on NixOS latest stable, I 
still have emacs 28.2 and org mode 9.5.


I also noticed that org-dblock-write:columnview modifies the buffer and 
adds a lot of trailing whitespace to property lines, headings, and also 
normal lines.


I'll try to reproduce it on latest org mode...

- Jakob

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Rationale for this patch: the treatment of blank lines in
> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
> environment, both the one that includes LaTeX and the one provided by
> the `verse' package as a replacement for the former.
> ...
> So, after this patch:
>
> • Any blank line before and/or after the content is removed;
>
> • One or more blank lines between stanzas are exported as a single blank
>   line, leaving the previous final verse without the linebreak mark
>   `\\';
>
> • When verse numbering is enabled via the `:lines' attribute (for the
>   `verse' package), the last verses of each stanza are marked with
>   `\\!', according to the verse package syntax (this was not necessary
>   with the previous behavior).

I see nothing that would prevent merging this patch.
However, I believe that removing blank lines before/after content is
something we may want to do in other built-in backends as well. WDYT?

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

[Ihor Radchenko]

Jens Schmidt  writes:

> Documented that in the Org manual, added tests, looks good.  Please
> check.

Thanks!
Two minor comments.

>  - 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 operator there are =!== and =/==.

I'd mention which operator is "equality" and "inequality" to avoid
ambiguity:

As a synonym for the equality operator ===, there is also ; =!== and
=/== are synonyms of inequality operator =<>=.

> -   (let* ((gv (pcase (upcase (match-string 5 term))
> +   (let* (;; Convert property name to an Elisp
> +  ;; accessor for that property (aka. as
> +  ;; getter value?).

Is there any specific reason why you put question mark in the comment here?

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

Re: kaobook tex template integration to a org file to make self-contained, portable?

[Christian Moe]

Hi,

For starters, have you added the kaobook document class to the variable
org-latex-classes? (If yes, ignore the rest of this message, if not, do
so and see what happens.)

This is needed to tell Org how to set the document class and what commands
are used for sections. See the manual 13.10.2 and 13.10.3,
[[info:org#LaTeX specific export settings]] and [[info:org#LaTeX header
and sectioning]], and look up the docstring for org-latex-classes if you
need help.

E.g., in .emacs I have this for Tufte-Latex:

(add-to-list 'org-latex-classes
 '("tufte-handout" "\\documentclass[11pt,a4paper]{tufte-handout}"
   ("\\section{%s}" . "\\section*{%s}")
   ("\\subsection{%s}" . "\\subsection*{%s}")))

(add-to-list 'org-latex-classes
 '("tufte-book" "\\documentclass[11pt,a5paper,nols]{tufte-book}"
   ("\\part{%s}" . "\\part*{%s}")
   ("\\section{%s}" . "\\section*{%s}")
   ("\\subsection{%s}" . "\\subsection*{%s}")
   ("\\paragraph{%s}" . "\\paragraph*{%s}")))

Yours,
Christian


Zenny writes:

> Hi,
>
> References of interest:
> 1. https://github.com/fmarotta/kaobook
> 2. https://github.com/asilata/emacsconf2021
>
> Can anyone guide me how to get a self-contained and portable template that
> executes kaobook tex templates (see 1) to create an org-file that resembles
> with the instance in 2 above?
>
> I tried the best I can by adding the kaobook.cls and kaobook.sty files
> inside `~/texmf/tex/latex/kaobook/` folder and specified 'kaobook' in the
> `#+latex_class: kaobook` but it failed to produce the desired look of pdf
> similar to
> https://github.com/fmarotta/kaobook/blob/master/example_and_documentation.pdf
> withing the same examples directory!
>
> Any input appreciated!
>
> Cheers and have a nice week,
> /z

Re: [BUG] Geiser fails to start REPL on Emacs 26

[Ihor Radchenko]

"Jose A. Ortega Ruiz"  writes:

> Hi.  Thanks for the heads up. I've upped the requirement in Geiser 0.29.1
> to Emacs 27.1.

Thanks!
I am thus disabling ob-scheme tests for Emacs <27.1.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=168ba7e6c
Fixed, on bugfix.

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

> Ihor Radchenko  writes:
>
>> May it be enough to drop --quick in Emacs call from publish.sh instead
>> of manually adding system-installed Emacs packages?
>
> Indeed.  Please go ahead: experimental commits won't hurt much.

Done.
https://git.sr.ht/~bzg/worg/commit/01f6d31a

>> May we just set #+PROPERTY: header-args :eval no-export across
>> examples?
>
> Sure, please go ahead as you see fit!

Done.
https://git.sr.ht/~bzg/worg/commit/8370cbd7

A number of code blocks never evaluated even in the past. In particular,
for org-contrib/babel/foo-doc.org files. I have enabled evaluation for
the files where we already load ob-foo, but not for others. To keep
status quo. But we may consider not evaluating anything in there and
instead relying upon the original results present in the .org sources.
At the end, WORG publishing is not our CI test pipeline.

I already had to work around some ESS bug to make things publish with
Emacs 29:
https://git.sr.ht/~bzg/worg/commit/4976d418

And I can see that it is not all yet. There is some major change in the
latest ESS that is causing ob-R to fail (see our latest R session test
failures in sr.ht CI). It is also preventing publishing because Org
attempts to evaluate some R code blocks, fails, and gives up.

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

Thanks for the fixes!

Ihor Radchenko  writes:

> And I can see that it is not all yet. There is some major change in the
> latest ESS that is causing ob-R to fail (see our latest R session test
> failures in sr.ht CI). It is also preventing publishing because Org
> attempts to evaluate some R code blocks, fails, and gives up.

Yes.  I hope other Org/ESS/R users on this list will help fixing these
documentation issues on WORG.

-- 
 Bastien Guerry

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Juan Manuel Macías]

Ihor Radchenko writes:

>> Rationale for this patch: the treatment of blank lines in
>> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
>> environment, both the one that includes LaTeX and the one provided by
>> the `verse' package as a replacement for the former.
>> ...
>> So, after this patch:
>>
>> • Any blank line before and/or after the content is removed;
>>
>> • One or more blank lines between stanzas are exported as a single blank
>>   line, leaving the previous final verse without the linebreak mark
>>   `\\';
>>
>> • When verse numbering is enabled via the `:lines' attribute (for the
>>   `verse' package), the last verses of each stanza are marked with
>>   `\\!', according to the verse package syntax (this was not necessary
>>   with the previous behavior).
>
> I see nothing that would prevent merging this patch.
> However, I believe that removing blank lines before/after content is
> something we may want to do in other built-in backends as well. WDYT?

I think you're right. My impression is that the blank lines before/after
content is not a desired feature, but rather a consequence of
substituting line breaks to create the space between stanzas. I think
the space before/after is better removed because it doesn't make sense
and adds unnecessary direct formatting[1]. Maybe it could be changed to
`(org-trim contents t) in all cases, like in this patch?

[1] However, the horizontal 'verbatim' space that can be added before
each line/verse seems like a great feature to me, since verses can also
be indented arbitrarily. This block it's a gem, and it has some really
cool features, not just to quote poetry.

Best regards,

Juan Manuel 

Re: org-agenda queries for absent properties

[Jens Schmidt]

On 2023-08-07  13:53, Ihor Radchenko wrote:

Thanks for reviewing.


  - 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 operator there are =!== and =/==.


I'd mention which operator is "equality" and "inequality" to avoid
ambiguity:

As a synonym for the equality operator ===, there is also ; =!== and
=/== are synonyms of inequality operator =<>=.


Done.


- (let* ((gv (pcase (upcase (match-string 5 term))
+ (let* (;; Convert property name to an Elisp
+;; accessor for that property (aka. as
+;; getter value?).

>
> Is there any specific reason why you put question mark in the comment
> here?

I was trying to decipher and document the acronyms used for the
let-bindings in that `let*' sexp.  I think I got them right but was
unsure about the "gv".  Removed the question mark, let's just assume
that "gv" means "getter value" and be done with it.

Updated patch attached.From 6e98356dfaf3466288398ff4ecee7fd147c32a20 Mon Sep 17 00:00:00 2001
From: Jens Schmidt 
Date: Sun, 6 Aug 2023 16:38:04 +0200
Subject: [PATCH] org-make-tags-matcher: Add starred property operators, fix
 quoting

* lisp/org.el (org-make-tags-matcher): Add starred property operators.
Recognize additional operators "==", "!=", "/=".  Clean up and
document match term parsing.  Remove needless and buggy unquoting of
minus characters in property and tag names.
(org-op-to-function): Recognize additional inequality operator "/=".

* doc/org-manual.org (Matching tags and properties): Add documentation
on starred and additional operators.  Document allowed characters in
property names and handling of minus characters in property names.

* testing/lisp/test-org.el (test-org/map-entries): Add tests for
starred and additional operators.  Add tests for property names
containing minus characters.

* etc/ORG-NEWS: (~org-tags-view~ supports more property operators):
Add announcement on starred and additional operators.

Link: https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de
---
 doc/org-manual.org   |  35 +++-
 etc/ORG-NEWS |  10 +++-
 lisp/org.el  | 120 ---
 testing/lisp/test-org.el |  64 -
 4 files changed, 192 insertions(+), 37 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..dc9f552e5 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9246,16 +9246,18 @@ 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 a synonym for the equality operator ===, there is also
+  ; =!== and =/== are synonyms of the inequality operator =<>=.
 
 - If the comparison value is enclosed in double-quotes, a string
   comparison is done, and the same operators are allowed.
@@ -9273,6 +9275,13 @@ The type of comparison depends on how the comparison value is written:
   is performed, with === meaning that the regexp matches the property
   value, and =<>= meaning that it does not match.
 
+- All operators may be optionally followed by an asterisk =*=, like in
+  =<*=, =!=*=, etc.  Such /starred operators/ work like their regular,
+  unstarred counterparts except that they match only headlines where
+  the tested property is actually present.  This is most useful for
+  search terms that logically exclude results, like the inequality
+  operator.
+
 So the search string in the example finds entries tagged =work= but
 not =boss=, which also have a priority value =A=, a =Coffee= property
 with the value =unlimited=, an =EFFORT= property that is numerically
@@ -9280,6 +9289,28 @@ smaller than 2, a =With= property that is matched by the regular
 expression =Sarah\|Denny=, and that are scheduled on or after October
 11, 2008.
 
+Note that the test on the =EFFORT= property uses operator =<*=, so
+that the search result will include only entries that actually have an
+=EFFORT= property defined and with numerical value smaller than 2.
+With the regular =<= operator, the search would handle entries without
+an =EFFORT= property as having a zero effort and would include them in
+the result as well.
+
+Currently, you can use only property names including alpha

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[WANG Yicheng]

Hi!

I just tried that out. As I mentioned 
here:https://lists.gnu.org/archive/html/emacs-orgmode/2023-08/msg00092.html, I 
found that, when using the dvisvgm option for exporting TeX snippets to HTML, 
the displayed math enclosed by \[…\] is not rendered as equation block, while 
math environments enclosed by \begin{…} \end{…} are rendered correctly.

Also, the org-latex-preview also rendered (deliberately put) inline \[…\] as 
inline images.

I guess it could be caused by org-latex-math-environments-re. Could you add 
support to recognize \[…\] also as equations? Thank you.

Regards,
ywangmy

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> This is convincing.
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding
convention first.  When the breaking change is a side-effect of fixing
a bug, it is unavoidable.

-- 
 Bastien

[BUG] Fontification of scheme code blocks

[Ihor Radchenko]

We have recently got WORG build failures because running scheme-mode
spawns an interactive prompt to select Scheme implementation.

This happens when Org export attempts to fontify scheme source blocks,
and calling major mode (scheme-mode) expects user interaction -
something we do not anticipate.

The failure is https://builds.sr.ht/~bzg/job/1036834

There are two issues here:

1. Potentially with scheme configuration in WORG build, where geiser is
   not fully configured.

2. More generally with our fontification code in ox-html and also in
   org-src - we may need to handle similar scenarios somehow. For
   example, by detecting interactivity attempts and aborting
   fontfication. Not sure if it is technically doable though.

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

Re: Add a Chinese version to index.org of orgmode.org

[Ihor Radchenko]

lux  writes:

> Hi
>   To facilitate Chinese users' understanding of Org Mode, I have
> translated index.org into Simplified Chinese. Please review it.

Thanks!
However, we already have another, more complete translation pending.
See https://list.orgmode.org/orgmode/sdvzg71zzor@netyu.xyz/

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