Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

[Stefan Nobis]

Ihor Radchenko  writes:

> It does not have to be lost. We can adjust the repeater function to
> handle negative dates/months specially, so that

> [2024-05--1 +1m] -> [2024-06--1 +1m]

Hmmm... I do not like, that here the wrong month is displayed. On a
cursory look, it's easy to assume the wrong month. But it is an
interesting option and maybe misreading this only my personal problem
(and "--1" stands out a little bit, so it is recognizable).

> How does it make my example with [2024-05-12 +1m!] any less awkward?

Ups, I misunderstood you. I thought the "+1m!]" looks ugly (and maybe
"+1mx]" is a bit less ugly).

Now I see what you mean. But there are new possibilities! :) Start the
repeater now, but from the next month on always use the last day of
each month. But yes, that's seems to be a quite seldom use-case.

But never mind, I have not thought this all through. Only some random
musings. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

[Stefan Nobis]

Ihor Radchenko  writes:

> +1m! is awkward - what if [2024-05-12 +1m!]?

You are right. I have not really spent time to think about a nice
syntax. But I think it needs to be encoded in the increment part, not
in the date part (because after the first increment, the information
that we want the last day of each month would be lost; and always
using -(mm+1)--1 also seems a bit awkward).

So maybe "+1mx" or some other way to encode "go to last day of next
month" directly into the increment?

-- 
Until the next mail...,
Stefan.

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

[Stefan Nobis]

Ihor Radchenko  writes:

> This is not possible because of how `org-auto-repeat-maybe' is
> designed. When repeater is triggered, the original date in the
> timestamp is replaced with future date. So, we have no access to the
> original date in the timestamp.

And even if we would have access to the original date: It may be
something like the last day of February and from that alone it is not
evident, wether e.g. the 28. of each month should be used or the last
day of month.

Therefore, I think, the only solution to this problem is to have some
kind of special 'last day of month' marker. Maybe something like
"+1m!" or any other way of encoding this "go to the last day of the
next month" directly into the increment specifier.

-- 
Until the next mail...,
Stefan.

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

[Stefan Nobis]

Juan Manuel Macías  writes:

>>> :export "latex+ html+ rest*"

>> "rest" might be a valid backend name.

> I will try to implement the "rest" option.

What about "others" or even ":others" as a placeholder for any not
explicitly mentioned export backend?

Another quick thought crossing my mind: May make "+" the default (so
"latex" means "latex+" and only use a marker char like '*' for
"content only")?

-- 
Until the next mail...,
Stefan.

Re: Experimental public branch for inline special blocks

[Stefan Nobis]

Hi Juan,

first of all: Thank you for your great work. Looks really good.

Just out of curiosity: Why a special syntax for alias expansion?

>From a syntax and user point of view, I think I would prefer a simpler
syntax. So

{text}

would check if an alias is registered and if yes use it. This way it
would be easier to change/add options later on without the need for
changing all the inline-block commands and add a "!" (not a big deal,
just two rather simple replace commands).

But even as it is it's a very nice and welcome extension (at least to
me)!

-- 
Until the next mail...,
Stefan.

Re: New Orgmode LaTex Document Class ?

[Stefan Nobis]

Ihor Radchenko  writes:

> I'd prefer to put some more generic reference. Some info manual or
> good stable URL link that has explanations about kpsewhich and other
> LaTeX basics.

What about

   http://mirrors.ctan.org/info/latex-doc-ptr/latex-doc-ptr.pdf

No direct references to kpsewhich, but I agree, that this is already a
rather specialized tool. But there are pointers to all the entry level
tutorials and resources and also some of the rather often asked for
packages.

-- 
Until the next mail...,
Stefan.

Re: New Orgmode LaTex Document Class ?

[Stefan Nobis]

David Masterson  writes:

> I want to install a resume document class for LaTex

There are the variables org-latex-classes and org-latex-default-class
on the Org side, but that's only about some structural metadata (how
to map Org headline levels to LaTeX structure macros).

To find the new class file you have to put it into a folder where
LaTeX will find it. Org just puts the name of the class into the TeX
file and everything else is up to LaTeX.

Usually, on Unix systems, there is the optional hierarchy $HOME/texmf
where you can store you private, local files. It is a good idea to
mimic the usual TeX directory structure, therefore class and style
files for LaTeX should go into $HOME/texmf/tex/latex (you may add
subdirectories there).

Nowadays it should suffice to just drop your class file there and
everything should work on the LaTeX side.

A quick check whether LaTeX will be able to find the file could be
done with the tool kpsewhich:

kpsewhich myltxclass.cls

This tool uses the same configuration and search algorithms for the
files as the TeX engines. So if kpsewhich finds the file, the engines
should find it too.

One side note: On macOS the default path for the user texmf tree is
$HOME/Library/texmf. On all systems you may find the correct base
directory for the user texmf tree with the command

kpsewhich -var-value TEXMFHOME

Hope this helps.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> Though ideally all the necessary fonts should be provided by
> TeXLive. I am not sure why they are not yet there in 2023.

First problem: Is there any free/libre font out there that has a
really broad and comprehensive coverage of Unicode glyphs? I really
don't know, but from time to time I hear about fonts that I assumed to
have good Unicode coverage that this is not the case (e.g. TeX Gyre).
I think, it is just an enormous amount of work to produce a complete
Unicode font (even more so, if it should look nice).

The other problem: Not everyone does a full installation of TeX Live.
So even if good fonts are available, they are not always installed on
every system (but this part could be mitigated by documentation and/or
error messages and hints).

But I'm no Unicode or font expert (I only need latin letters). I'm
just impressed what is already possible and about all the work done by
volunteers. And sometimes I'm astonished by how much work is still to
do for a complete and smooth Unicode experience. :)

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> AFAIR, the basic problem is that we cannot guarantee that any given
> UTF font is installed.

Yes, indeed. Probably the best route is to make tweaking as easy as
possible. There are still too few (if any) really comprehensive (and
good looking) Unicode fonts available.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

"Dr. Arne Babenhauserheide"  writes:

> Isn’t the speed more relevant for large documents?

I always had the impression that luatex has mostly a rather fixed
overhead. Maybe that's because many of my larger documents make quite
some use of TikZ and most time may be spend there. Therefore I assumed
the fixed overhead does not matter that much for larger documents. But
I did no real benchmarks or performance comparisons and it might
depend of the kind of document and packages used.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> The downside of lualatex is that it is slower:
> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

BTW: One of the discussion points in that thread has been the problem
of default fonts. With pdflatex the default font is CM (Computer
Modern) and if the appropriate packages are installed, you
automatically get cyrillic letters. That's why Max is a fan of this
solution.

With lualatex the default font is LM (Latin Modern; quite similar to
CM, but some metrics differ). And AFAIK LM is still worse in the range
of supported Unicode characters.

But only recently I discovered a package called "fontsetup". And this
package seems to provide a big step towards the goal discussed in the
above mentioned thread: Provide default fonts for most common
situations. The goal of fontsetup is more about easy switching between
different fonts, e.g. with the option "cambria" set everything up such
that the Microsoft Cambria font family is used and fall back to proper
fonts where Cambria has gaps. But that's also something that would be
nice for Org. Maybe we should have a closer look at this (I have no
real world experience with this package, only played a little bit with
it).

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> The downside of lualatex is that it is slower:
> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

Yes, for sure. But I have the impression that newer versions of luatex
have become a bit faster (maybe it's just a subjective impression that
I want to be true, because I don't want to regret the complete switch
to luatex). :)

On the other hand: Luatex is much more flexible and has better support
for modern fonts and modern font render engines.

It depends what one assumes to be the most common use case for Org. If
it's many rather short and simple documents then pdftex should suffice
most of the time and the fast compile speed will matter. If we want to
support as many different situations out of the box, I think luatex
would be the better/easier way - at the cost of slower compilation
speeds.

Another approach: Use pdftex for simple/short documents and make
selection of luatex as backend engine per document as easy as
possible. Additionally, we might try to detect situations in which
luatex would be the better choice (e.g. certain languages). But this
would certainly be more work and lead to more complex code.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

andrés ramírez  writes:

> I have tried the snippet. But It shows just Japanese and the other
> paragraphs are not present on the PDF.

That's quite strange. I just re-tested with emacs -Q (Emacs 28.2 with
integrated Org 9.5.5). It generates the following tex file:

--8<---cut here---start->8---

% Created 2023-07-02 Sun 16:49
% Intended LaTeX compiler: lualatex
\documentclass[11pt]{article}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{luatexja}
\date{}
\title{Doc multi-lingual}
\hypersetup{
 pdftitle={Doc multi-lingual},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 28.2 (Org mode 9.5.5)}, 
 pdflang={Jp}}
\begin{document}

\maketitle

\section*{Español}
\label{sec:orgfec75bb}
Hola
\section*{English}
\label{sec:org36763e7}
Hi
\section*{French}
\label{sec:org8e5a1dd}
Ceci c'est en Français
\section*{Japanese}
\label{sec:org70cd53d}
ダウンロード
\end{document}

--8<---cut here---end--->8---

When I compile this file with lualatex, everything looks as expected
to me. BTW: I'm using TeX Live 2023 with all recent updates.

Also, from the LaTeX perspective I see nothing that should prevent the
latin letters from being shown in the final PDF. Here are the fonts
used:

--8<---cut here---start->8---

% pdffonts foo.pdf
name type  encoding emb sub 
uni object ID
 -  --- --- 
--- -
BRVOXH+LMRoman17-Regular CID Type 0C   Identity-H   yes yes 
yes  8  0
XVVEIR+LMRoman12-BoldCID Type 0C   Identity-H   yes yes 
yes 10  0
HIWCUH+LMRoman10-Regular CID Type 0C   Identity-H   yes yes 
yes 11  0
EPCPZB+HaranoAjiMincho-Regular   CID Type 0C   Identity-H   yes yes 
yes 15  0

--8<---cut here---end--->8---

Maybe there are some other configurations on the Emacs or LaTeX side
on your system that changes some of the defaults?

--
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Hi.

I got curious and it seems if you are willing to use lualatex (which
is, I think, currently the most actively developed engine and nowadays
a really good choice), the following solution should work:

--8<---cut here---start->8---

#+TITLE: Doc multi-lingual
#+options: author:nil email:nil toc:nil num:nil date:nil
#+LATEX_COMPILER: lualatex
#+LANGUAGE: jp
#+LaTeX_Header: \usepackage{luatexja}

* Español
Hola
* English
Hi
* French
Ceci c'est en Français
* Japanese
ダウンロード

--8<---cut here---end--->8---

The crucial parts are using lualatex and loading the package
"luatexja". It seems, that the package luatexja is currently one of
the best options to produce Japanese output and it is actively
developed. There is also quite a bit of documentation (see e.g. with
"texdoc luatexja" on the CLI or https://www.ctan.org/pkg/luatexja).

I have no experience with Japanese output and I'm unable to read
Japanese, so I could not judge the correctness or quality. But the
above approach seems to work quite well and it might be possible to
support this solution from the Org side (because only a single package
has to be loaded). The requirements seem to be OK (roughly TeXlive
2020 or newer). The package automatically sets up required fonts (but
it is still possible to override the default font settings) and even
with the default configuration it is possible to use Japanese fonts
inside math mode.

-- 
Until the next mail...,
Stefan.

Re: [RFC] Refactoring org-element API

[Stefan Nobis]

Hi Ihor,

thank you for all your great work. I did not dive deep into all the
details, but the overview you provided sounds sensible.

One minor nitpick: I would prefer a function like
~org-element-property-1~ to be named e.g. ~org-element-property-lazy~
(or something similar), because the "-1" is just obfuscation to me.

--
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Jean Louis  writes:

> Specifying time zone is not ambiguous as long as you use the TZ
> database for specifications!

That's wrong and you know it. For example

   [2023-10-29 02:30 @Europe/Berlin]

is ambiguous. Period.

And that some examples got a bit off has been quite obvious and has
already been stated. So its not necessary to flog dead horses.

It would also be nice to eventually recognize, that we are talking
about readable syntax for humans, that is sometimes generated,
sometimes manually typed. Most of you comments does not really
resonate with this crucial design goal.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko  writes:

> Note that an alternative is 

>  [2022-11-12 10:30-11:00]
>  [2022-11-12 10:30-11]
>  [2022-11-12 10:30-11:00-11]

> which is much less confusing.

Hmmm... is it? I read a lot different timestamps these days and
currently I'm very careful reading them, especially while considering
syntax details. Therefore I'm reading slowly and only few timestamps
at once.

But real life sometimes get hectic and stressful. And then I might
only throw a glance at timestamps, hoping to get the important details
- surely I will remember all the important details. :) In these cases I
would much prefer a syntax that is a bit less terse like

>  [2022-11-12 10:30 @+02]

So I would vote for Timothys variant.

Considering Timothys other proposal:

>> I like the way that combining these features works, but I do wonder if 
>> perhaps
>> warning when these two bits of information don’t match should be the default
>> behaviour, and the `!' used to specify which of them should be prioritised?

I do not like the semantics.

>> ┌
>> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
>> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07

I read "@+07,!Asia/Singapore" as "use UTC offset +07 but be aware of
time zone Asia/Singapore, from which I got the offset in the first
place".

On the other hand, I read "@+07,Asia/Singapore" as "use UTC offset
+07, which I got from the Asia/Singapore time zone".

So for me a possible warning should go with the "!" variant. In the
case without "!", for me the syntax suggests a more informative
meaning for the time zone name part.

Therefore I would vote for Ihors variant for this part. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

 writes:

> ...which stems from the fact that the very concept of "time zone" is
> somewhat ambiguous, too.

Yes - I think most of us here see that. Therefore I really appreciate
the flexible timestamp format Ihor suggested.

> If you really want to have fun with this (and this thread hasn't
> satisfied your thirst ;-) see [1].

Thanks for the link. Very interesting details that I didn't know
about yet.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko  writes:

> [2023-03-29 02:30 @Europe/Berlin] is special.

I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

 writes:

> 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> it /is/ ambiguous.

As far as I understand the definitions, the point in time "2023-03-23
02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.

A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".
Strictly speaking, this point in time does not exist, because in the
night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00
directly to 03:00 in the time zone Europe/Berlin. Therefore the
/interpretation/ of this timestamp is ambiguous.

The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
02B:30 (02:30 UTC+0100) in this night of switching back from DST to
normal time!

So, in general, only using the time zone name may indeed lead to
ambiguous interpretations of timestamps.

-- 
Until the next mail...,
Stefan.

Re: fontsets

[Stefan Nobis]

Juan Manuel Macías  writes:

> [1] I have to add, by the way, that MatchLowercase is not always a
> panacea.

Hmmm... maybe add optional extra config/output option to the fontset,
like so:

┌
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│  (myfontb ...)
│  ...)
│ ;; Fontsets
│ ((myfontset .
│   ((sans . myfonta)
│(serif . myfontb)
│(mono . myfontc)
│(extra . ((lualatex . "\\defaultfontfeatures{Scale=MatchLowercase}")
│  (html "some CSS...")...))
│...))
│  ...)
└

This way it may be possible to build a fontset library of fonts that
blend well together, including some necessary fine-tuning.

-- 
Until the next mail...,
Stefan.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Stefan Nobis]

Juan Manuel Macías  writes:

> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).

I would vote to activate this by default.

> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)

I would prefer to make it easier to stick with the default fonts. So
only add the font selection commands (including defaultfontfeatures)
when the font variables are non-nil. If no font has been explicitly
chosen, just use the default (in case of lualatex Latin Modern).

For me, it does not matter whether the 'org-latex-fontspec-*'
variables have a default of nil or set to the Free* fonts or something
else. For my configuration, I would set these variable to nil in order
to get the LaTeX default fonts and would like to go with the default
preamble of Org and then add to this on a per document basis.

This way, the whole configuration would be a little more composable, I
think.

-- 
Until the next mail...,
Stefan.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Stefan Nobis]

Ihor Radchenko  writes:

> But can someone check if Free* fonts are available on Windows and
> Mac by default?

I just checked TeXLive (on MacOS, but should be the same on all
systems): The Free* fonts are part of TeXLive as truetype and as
opentype versions (and partly in other formats).

For Windows I remember vaguely that some prefer the MikTeX
distribution (TeXLive is also available for Windows and has the same
fonts as everywhere). A short search shows that the gnu-freefont set
is also availabe for MikTeX, but I currently don't know whether it
will be installed with a default MikTeX installation.

> This unified preamble approach is consistent with what we do now.
> However, our currently used large preambles will slow down compilation.

Not that much. The time consuming packages like tikz/pgf (used by
beamer) are not part of out default preamble. There is not that much
speed to gain (all times are for a single lualatex run):

1) Only hyperref loaded, no other packages:
   0.46s user 0.10s system 99% cpu 0.568 total

2) Complete default preamble for lualatex:
   0.48s user 0.14s system 99% cpu 0.623 total

3) The same as above, but with babel and mathtools:
   0.51s user 0.15s system 99% cpu 0.673 total

4) And another variant (same as before, but package caption instead of
   capt-of):
   0.53s user 0.14s system 98% cpu 0.674 total

5) Back to our default preamble, but adding fontspec:
   0.60s user 0.14s system 99% cpu 0.748 total

6) With fontspec, unicode-math, babel, mathtools, caption:
   1.02s user 0.19s system 99% cpu 1.220 total

Therefore most of out default packages (and even the addition of
babel) does not change much for the speed of compilation. I don't
think its worth to try to further optimize this default preamble.

Adding fontspec and especially unicode-math adds quite some time, so
maybe its worth to take care to only add these if necessary (only for
lualatex/xelatex and only if e.g. if a font has been selected or math
seems to be used in the document).

And, by the way, our preamble is neither large nor complex. For my
LaTeX documents, the preamble is usually *much* larger. :)


Here is the test file for the default preamble (but with mathtools
instead of amsmath and with babel; test run 3):

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---


Here is the test file for the last run with all extra packages:

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage{fontspec}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage[warnings-off={mathtools-colon,mathtools-overbracket}]{unicode-math}
\usepackage{caption}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---



-- 
Until the next mail...,
Stefan.

Re: insert automatically a reference to a section header and a link

[Stefan Nobis]

Uwe Brauer  writes:

> Yes, but, what do you do, if you have a 10 header and each has 20
> subheaders.

I avoid writing such complex documents for the moment. :)

[Some custom functions]
> Thanks but this did not work! 

Sorry. The code is meant as an inspiration, not to be used out-of-the
box. I never tested the functions outside my highly adjusted default
configuration.

As I read in another post you seem to be a helm user. Therefore it
might be a better idea to use helm helper functions. I assume, helm
has also some function to jump around in Org files, with headings as
targets. If you find such a function, try to copy and adapt (as I did
with the similar `counsel-outline' function): I assume such a function
will use some helper function to collect the candidates for completion
and after the user selected a candidate there is code to jump to the
selected destination. Just try to change this part so that instead of
jumping, a link is inserted at the proper place (that's the part my
function `sn/org-insert-internal-link-action' is responsible for).

Maybe someone with more knowledge about helm might help you with a
complete solution.

-- 
Until the next mail...,
Stefan.

Re: insert automatically a reference to a section header and a link

[Stefan Nobis]

Juan Manuel Macías  writes:

> In Org 9.5 there is a new variable `org-latex-reference-command'.

Thanks for the reminder! I once read about it, but forgot to use it
after upgrading to 9.5. :)

-- 
Until the next mail...,
Stefan.

Re: insert automatically a reference to a section header and a link

[Stefan Nobis]

Uwe Brauer  writes:

> I am not following you. You insert a header as in 

> * Intro

> Now you want to refer to it with a link

> As we have seen in section ...

> So what precisely are you typing?

I type "As we have seen in section [[*Intro]]" (literally, I tend to
not use any keybindings or function to insert the link). This (the
"*Intro" inside double square brackets) is called an internal link to
headlines and they are a default feature of Org:

https://orgmode.org/manual/Internal-Links.html#Internal-Links

BTW: I mostly export to PDF via LaTeX and usually use the combination
of cleveref with varioref. Therefore I prefer to type "As we have seen
in [[*Intro]]" (leaving out "section") and let Org generate a
"\vref{...}" reference. To achive this, I need little bit of extra
setup (and do not forget to add the necessary usepackage commands
either locally in the Org file or add it to
org-latex-default-packages-alist):

#+begin_src emacs-lisp
  (defun sn/ox-latex-filter-special-ref-vref (text backend info)
(when (org-export-derived-backend-p backend 'latex)
  (replace-regexp-in-string "ref{" "vref{" text)))
  
  (add-to-list 'org-export-filter-link-functions 
#'sn/ox-latex-filter-special-ref-vref)
#+end_src

If you need internal links to headings more often and do not want to
type the whole heading text manually, you can use functions like this
(inspired by `worf-goto' and `counsel-outline'; if you do not use
ivy/swiper/counsel, the code should at least give the basic idea):

#+begin_src emacs-lisp
(defun sn/org-insert-internal-link ()
  "Use ivy to insert a link to a heading in the current `org-mode' document."
  (interactive)
  (let ((settings (cdr (assq major-mode counsel-outline-settings
(ivy-read "Heading: " (counsel-outline-candidates settings)
  :action 'sn/org-insert-internal-link-action)))

(defun sn/org-insert-internal-link-action (x)
  "Insert link for `sn/worf-insert-internal-link'"
  (save-excursion
(goto-char (cdr x))
(call-interactively 'org-store-link))
  (org-insert-last-stored-link 1)
  (delete-char -1))
#+end_src

-- 
Until the next mail...,
Stefan.

Re: insert automatically a reference to a section header and a link

[Stefan Nobis]

Uwe Brauer  writes:

> I wonder why this was not implemented or asked for.

Hmmm... for me, the default way to link to headings is just fine, I
seldom need more control over the generated labels:

#+begin_src org
  ,* Intro

  Lorem ipsum dolor sit amet...

  ,* Another section

  As seen in [[*Intro]] there is not much to say.
#+end_src


-- 
Until the next mail...,
Stefan.

Re: [PATCH] Don't fill displayed equations

[Stefan Nobis]

Max Nikulin  writes:

> On 03/10/2021 00:51, Tom Gillespie wrote:

>> I guess one thing I'm missing/not understanding is when/why people
>> want to use \[ \] instead of full #+begin_export latex block?

> For example, because document without equations may become almost
> useless in the case of export to HTML or ODT file.

Remember, as Nicolas said, the alternative to \[...\] is not a
"#+begin_export" block, but

\begin{equation*}
...
\end{equation*}

-- 
Until the next mail...,
Stefan.

Re: [Question] A single *-language-alist in ox-latex.el?

[Stefan Nobis]

Juan Manuel Macías  writes:

> Well, if I'm not mistaken, the situation in the LaTeX ecosystem is
> this: Polyglossia appeared as a babel replacement for XelaTeX and
> LuaLaTeX, since babel, at that time, had no support for these two
> new Unicode based TeX engines.

And, as far as I remember, babel development had nearly ceased during
that period.

Since quite some years, the development has gained much more traction
for babel and, as far as I read, babel is today as good or superior to
polyglossia in many regards (but polyglossia is also in quite a good
shape today). See for example:

https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019

In short: Babel is a very good choice in almost all cases, maybe
except for right-to-left texts set with XeLaTeX.

> But I think it does not make much sense to mantain in ox-latex.el
> two separate lists today. Maybe, for simplicity, it would be better
> to unify the two lists in a single db, something like
> `org-latex-language-alist'. What do you think?

+1

-- 
Until the next mail...,
Stefan.

Re: Org syntax: \[ \] as block element instead of inline object

[Stefan Nobis]

Max Nikulin  writes:

> I like Timothy's idea that \[ \] markup should behave like
> block-level element rather than inline object.

On the other hand, we will loose the ability to inline small parts of
math, that should be typeset as separate equation, like:

...text \[ 1+2=3 \] more text...

I'm quite undecided in this regard. Personally, in almost all cases I
try to let my equations stand out even in the source (Org or LaTeX),
so I mostly use the "\begin{equation*}...\end{equation*}" variant.

At least, Nicolas convinced me, that comparing to LaTeX does not help
much (how LaTeX treats \[...\] is independent from how we want to
structure Org documents).

BTW: In LaTeX, I like to make equations stand out even further like
this:

--8<---cut here---start->8---
Some text
%
\begin{equation*}
...
\end{equation*}
%
more text
--8<---cut here---end--->8---

Is there a simple way to achieve this in Org (without using ugly
solutions like "@@latex:%@@" - something concise, at most 2-3 chars,
better only 1, but still visible in order to distinguish between
compound block belonging to a single paragraph and separate
paragraphs)?

-- 
Until the next mail...,
Stefan.

Re: [PATCH] Don't fill displayed equations

[Stefan Nobis]

Nicolas Goaziou  writes:

> Also, I don't think LaTeX treats it as a block element.
> E.g.,
>
> text
> \[1+1=3\]
> text
>
> is a single paragraph in LaTeX.

Yes and no. LaTeX is a bit more complex and does not only see inline
or block elements. It has paragraph mode (and inner paragraph mode
like \parbox, which does not allow page breaks), vertical mode, LR
mode, math mode and within math mode there is inline math style
and display math style (and some more little details I forgot).

But still, the equation in the example is in display math style and it
is typeset as a separate line. Additionally, as far as I remember,
with processing "\]" LaTeX leaves math mode, typesets the necessary
vertical space, and switches back to paragraph mode. Then, if an empty
line (or the command "\par") is encountered, the marking of a new
paragraph is typeset (e.g. using "\parindent" and "\parskip"), else
normal output resumes.

Therefore, I would argue, LaTeX modes are not really comparable to Org
element types (inline or block).

See also the following LaTeX code:

--8<---cut here---start->8---
\documentclass{article}
\begin{document}
text\par text\\ and more text
\end{document}
--8<---cut here---end--->8---

Here, with an Org point of view, one may say, this is a single block
or paragraph. But LaTeX will typeset two paragraphs in three lines
(and internally stays the whole time in paragraph mode, if I correctly
remember the small fragments I once learned about the LaTeX kernel).

> If it's a block element, you cannot write \[...\] mid-line.

Hmm... so maybe, it's really worth to have both (\[...\] as inline
element and the \begin{equation*}...\end{equation*} block). I'm
undecided. :)

But thanks for your explanations!

-- 
Until the next mail...,
Stefan.

Re: [PATCH] Accept more :tangle-mode specification forms

[Stefan Nobis]

Timothy  writes:

> Thank you for considering potential security implications

BTW: Security-wise I would argue to even forbid the integer case. From
my view next to nobody uses and is used to the decimal codes of file
modes. So this decimal integer representation is the most error prone,
I would say. The more explicit (like "rwx-r-x-r--" etc.) the better.

I would also tend to only support something like "#o755" and forbid
"755" as well as "0755", just to be more explicit and to avoid
misinterpretation.

But all in all I support your patch and your arguments for the change.
Currently, I also do not really see why this attribute value (just a
string if the integer case is forbidden) will make the Org syntax more
complex.

-- 
Until the next mail...,
Stefan.

Re: [PATCH] Don't fill displayed equations

[Stefan Nobis]

Nicolas Goaziou  writes:

> Now, if you want to discuss changing syntax for \[...\] and make it
> a block element

I wonder, why it is not a block element. As far as I know, the only
difference (even in the context of Org) between \(...\) and \[...\]
is, that the former denotes inline math and the latter denotes a math
block. And at least exporting to HTML (with MathJax) and LaTeX results
in a block equation for \[...\].

Do you have a short summary or a pointer why \[...\] has been choosen
to be an inline element? What's the advantage or what would be the
downside of making it a block element?

-- 
Until the next mail...,
Stefan.

Re: LaTeX export: grffile is a stub package

[Stefan Nobis]

Timothy  writes:

> meedst...@teknik.io writes:

> Oh, that reminds me, we can also get rid of texcomp.
> 

Hmmm... one note about xcolor in your list: Some configuration options
are load-time options that have to be set as package load options. If
xcolor is already loaded with no options, its much harder to load it
with special options like [table,svgnames*]. Also some classes like
beamer are very special with reagads to xcolor.

But what about some other tweaks?

To better support lualatex and xelatex in the default configuration,
we should add

("" "fontspec" t ("lualatex" "xelatex"))

Personally, I would also add the following two lines for better
multilingual support with all three engines:

("AUTO,safe=none,math=normal" "babel" t ("pdflatex" "lualatex"))
("AUTO" "polyglossia" t ("xelatex"))

Then, for math it may be nice to substitute "amsmath" with "mathtools"
and for lualatex and xelatex add something like this:

("warnings-off={mathtools-colon,mathtools-overbracket}" "unicode-math" t 
("lualatex" "xelatex"))

What do you think?

-- 
Until the next mail...,
Stefan.

Re: [Worg] Proposing a few CSS changes

[Stefan Nobis]

Timothy  writes:

> I don’t think a completely spartan page is entirely sensible though.

Indeed! I did not want to argue for all or nothing. :)

But font and font size for big chunks of text are quite important and
individual choices. So the rest of the styling should try to be
flexible enough to support different user choices as good as possible.

BTW: I like your design for the Org homepage. My thoughts should only
be seen as a very light weight on Adams side when trying to balancing
the scale of the multitude of styling choices. :)

-- 
Until the next mail...,
Stefan.

Re: [Worg] Proposing a few CSS changes

[Stefan Nobis]

Adam Porter  writes:

> So I think it's very important to respect the user's settings,
> especially for long texts and documentation (i.e. not the "home page"
> parts of Web sites whose purpose is to present projects as a whole).

+1.

HTML pages are neither books nor PDFs nor advertising columns. I have
a LaTeX background and I like to tweak the micro-typography of my PDF
documents (and I find many documents out there quite ugly and hard to
read). Therefore I think I understand and kind of sympathize with
Timothoys point of view.

But the web is quite a different beast. User choices like
Window/viewport size, fonts (serif, non-serif, size,...) are way too
often ignored and even battled against. Sometimes I get the
impression, that every time a web designer gets informed about a new
way for users to override design decisions they try to block these
possibilities - and in most cases to the disadvantage of users.

Yes, today seldom people play with the font settings in their
browsers. But why? I think, because they see that these settings seem
to never really work. Even if you configure your browser to ignore
font settings from HTML/CSS and always use the browser settings, many
pages will be next to unreadable - the layout breaks down, if the
wrong fonts/sizes are used.

Therefore I support Adams wish to honor the configuration of users.
The web should be more seen as a documentation system, not an
installation of art.

-- 
Until the next mail...,
Stefan.

Re: org-cite: how to include a cite with no key?

[Stefan Nobis]

John Kitchin  writes:

> Who is to say why someone would bother. It is a command on page two
> of http://tug.ctan.org/macros/latex/contrib/natbib/natnotes.pdf that
> one can use.

Hmmm... but I would say that the natbib command \citetext is more a
helper/workaround for the missing prefix/suffix options that biblatex
provides. See also the example in the natbib documentation (~texdoc
natbib~ or http://tug.ctan.org/macros/latex/contrib/natbib/natbib.pdf)
in section 2.4 (page 8):

  \citetext{see \citealp{jon90}, or even better \citealp{jam91}}

This is possible (and I would say easier) with biblatex and Org with
the prefix/suffix text options/syntax: A way to include some
additional text inside the citation block.

If inside \citetext no other \cite... command is used, its just the
given text in parentheses. No special formatting, no interaction with
the bibliography. Here's the definition of the command (from
natbib.sty):

  \newcommand\citetext[1]{\NAT@open#1\NAT@close}

It's just the given text surrounded by the chosen citation block
markers (either empty for superscripts, "(..)", "[..]", "$<$..$>$", or
"{..}"). So there is not much to gain from this command in the context
of Org with its rather rich cite syntax that is more expressive than
that of natbib.

As Emmanuel said: If you want a proper entry in the bibliography, then
add the item to the database (e.g. @misc{pm, author={Me},
title={Personal Communication}, year=1984}) and cite it as any other
item.

Or use a macro if you want such comments to be easily
searchable/changeable.

-- 
Until the next mail...,
Stefan.

Re: org-mode export to (latex) PDF

[Stefan Nobis]

Jean-Christophe Helary  writes:

> Since org uses Latex to achieve export to PDF, which is quite a
> common demand nowadays, something that normal org users can
> understand should be posted somewhere.

I second that! I just wanted to try to lower the expectation that
(most) scripts will work out of the box without any kind of manual
configuration.

-- 
Until the next mail...,
Stefan.

Re: org-mode export to (latex) PDF

[Stefan Nobis]

Maxim Nikulin  writes:

> Do Unicode TeX engines support such combination of fonts?

Yes, they do.

My rather long response was due to my impression that you are quite
surprised that not everything is supported with the default
configuration as you expected.

I wanted to highlight that it is even today a rather hard problem to
mix different scripts (even if typographic quality does not matter)
and that there are quite different expectations of what a sensible
default should look like.

> There are two quite distinct cases: documents with carefully chosen
> fonts (e.g. a book) and everyday notes when particular font is not
> so important.

Yes, indeed. And I hope you see that these two requirements are not
easily satisfied with the same default configuration (and I would say
this is a understatement). The LaTeX community has chosen to prefer a
minimum typographic quality for their defaults and the majority still
concentrates more on latin scripts.

And as I said: A good multi-lingual support for Org is a really huge
undertaking. Unicode alone solves only a rather minor part of these
challenges.

> I mean detection if LuaLaTeX or XeLaTeX is usable from Org code.

Org should be rather flexible about the configured engines. There are
reasons why today all three engine are quite alive and used by
different users. I think it would be possible to improve the support
for all three engines, make the selection easier for the Org user and
go some first steps in better supporting different scripts and
languages. But it is not easy and not a matter of a handful lines of
code.

> Randomly chosen examples: "日本", "多喝水", "".

The last glyph ("TELEPHONE RECEIVER") is not visible for me. Remember,
that Unicode gets expanded quite often and it is not easy for font
developers to keep up. I still think that the expectation, that Org
and/or LaTeX will support the whole Unicode range out of the box is a
little bit too far fetched.

-- 
Until the next mail...,
Stefan.

Re: org-mode export to (latex) PDF

[Stefan Nobis]

Maxim Nikulin  writes:

> There are cm-super fonts for at least of 15 years.

There are many tradeoffs in many aspects. No single font pleases
everyone. So you want to say: Your requirements are more
important/common/stylish/whatever that the requirements of other
people?

I do need only latin characters and math (so Latin Modern would
suffice), but still I use different fonts from time to time (like
Libertine, Palatino and others) - and I also mix different fonts (not
all font families provide serif and sans serif and monospace glyphs).

And due to the history of TeX and the structure of font files, there
is no single command to set up all required information to switch all
font families with one command. Usually up to 3-4 command are required
(sometimes more for more advanced requirements) are needed to change
most relevant font information.

Frankly, I'm completely clueless why this should be a problem.

Yes, it may be unfortunate that not all fonts available support all
Unicode glyphs ever invented. But on the other hand: Most of the free
fonts are created by people in their free time and it takes VAST
amounts of time and talent to create nice looking fonts.

I appreciate the many fonts that creative people created to be used for
free. So if all I have to do to use this massive gift is drop a couple
of commands in some or all my documents, I do not complain - I'm
grateful.

I understand that it sometimes sucks to be forced to use tools that
are created with a massive US centric world view, that not only
focuses on latin characters, but even only respcect ASCII (e.g. even
today quite some systems have problems with german umlauts). But try
to get over it: At least in the case of Emacs, Org, and LaTeX it is
possible and in most cases quite easy to overcome the restrictions
that the default settings may impose.

[unicode-math]
> Thank you for the hint. Do you think Org should use it by default?
> Are there any caveats?

Yes, unicode-math should be seen as must have for lualatex and xelatex
(if math is used). As far as I know there are no downsides and it
should be part of the default packages (but only for lualatex and
xelatex, not for pdflatex).

> If LuaTeX and XeLaTeX handles Unicode better, is it possible to make
> any of them the default option and to leave pdflatex as a fallback?

That is possible today and you can easily change the LaTeX engine via
global options in your Emacs init.el or via local settings inside Org
documents.

> Is it possible to detect lualatex and xelatex in runtime?

At runtime of the LaTeX engine, so execute LaTeX commands depending on
the engine that processes the document containing these commands?

Yes, that is possible. The LaTeX package iftex provides macros to
execute commands based on the running engine (see
https://www.ctan.org/pkg/iftex?lang=en).

> Should some packages for lualatex and xelatex be added to default
> list to minimize user problems and at the same time keeping
> configuration safe? (unicode-math, etc.)

Maybe. I'm currently myself struggling a little bit with a flexible
configuration, that can be used with many different kind of documents
(short notes, larger reports, beamer presentations) and provides all
the extras I like to use. There is no clear best package list for
every use case (in some cases unnecessary loaded packages only waste
time, in other cases, especially with some individual set of package
options, there might be errors in some scenario or another).

> Is it possible to provide reasonable defaults for fonts?

I do not think so. You want Cyrillic. But what about Japanese,
Chinese, Devanagari, Tamil, Arabic etc? I doubt that there exists a
single font that supports all these scripts satisfactorily. Despite
the existence of the Unicode encoding(s), the glyphs and font designs
are still quite complex and demanding even for a single script.

But maybe we could assemble a list of good (enough) fonts for
different languages/scripts and provide a default setup in Org for
LaTeX export, that sets a proper font for the chosen document
language?

-- 
Until the next mail...,
Stefan.

Re: org-mode export to (latex) PDF

[Stefan Nobis]

Maxim Nikulin  writes:

[utf8x]
> Maybe, I have seen such warnings. However I have tested neither utf8
> nor utf8x on real examples. That is why I am unaware what can be
> broken in particular. For small examples with various symbols
> outside of ASCII, utf8x may give better support.

The main point: utf8x and the associated package ucs are not
maintained for quite some time (utf8x seems to be last changed in
2004) and as far as I understand have always been more of a workaround
than a solution. But I'm not an expert in this regard.

Nowadays the LaTeX kernel and input encodings like (plain) utf8 are
much more powerful and extensible and do play much better with other
packages.

Especially in the last few years the unicode support has become much
better (for all engines).

> I do not like that it is necessary to specify *all* fonts,

You need to specify all fonts that you want to use and that deviate
from the default (Latin Modern in the case of lualatex). How else
should the system now that you want something else?

And in the case of cyrillic: Sadly, the default fontset Latin Modern
has no good support for the cyrillic alphabet. But the name is at
least a small hint. :)

In LaTeX there are 4 groups of fonts: the main font (usually a serif
one), a sans serif font group, a monospace font group and the math
font set. If you use all kinds of groups and want differ from the
defaults, you need to say so explicitly. On the other hand: If you do
never use e.g. monospace glyphs you do not need to specify the
monospace font.

So here is a minimal version of your document that should work:

#+begin_src latex
\documentclass{article}
\usepackage{fontspec}
\usepackage{unicode-math}
\setmainfont{CMU Serif}
\setsansfont{CMU Sans Serif}
\setmonofont{CMU Typewriter Text}

\begin{document}
Test¹ of superscript and ½ fraction.

\textbf{Теорема.} \emph{Пусть} $\quad α → ∞$ и $\beta \to \infty$.

\verb=Катет= и \textsf{гипотенуза}.

Åå. Text Greek α.
\end{document}
#+end_src

The package "unicode-math" should always be used with lualatex and
xelatex, in order to support unicode math input. In your minimal
example neither polyglossia nor babel are required, but explicit font
selection is necessary to switch all font groups to a fontset with
cyrillic glyphs.

>> (setq org-latex-default-packages-alist
>>  '(("AUTO" "inputenc" t ("pdflatex"))
>>("T1" "fontenc" t ("pdflatex"))

> I just have realized that fontenc behavior should be similar to
> inputenc and babel, e.g. something like \usepackage[T1,T2A]{fontenc}
> should be used for Russian.

Yes, indeed. It would be nice to support this all from Org. So if one
chooses russian as language, that (in case of pdflatex engine) an
option "AUTO" for "fontenc" is supported that get expanded to
"[T1,T2A]" and that the necessary font selection is also generated (if
not overriden with an explicit set choosen by the user). But a full
fledged multi-language solution, that supports more than just latin
and russion may be quite a challenge.

-- 
Until the next mail...,
Stefan.

Re: org-mode export to (latex) PDF

[Stefan Nobis]

Maxim Nikulin  writes:

> (add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))

Do not do this. Both, utf8x and ucs, are obsolete and deprecated for
quite some time.

For proper unicode support, switch from pdflatex to lualatex or
xelatex. With these newer backends (and proper adjustments for the
LaTeX preamble generated by Org) Unicode should work out of the box
(if the font supports the requested Unicode characters).

My current packages setup to support all three engines looks like
this (should work for normal documents and beamer):

--8<---cut here---start->8---

(setq org-latex-default-packages-alist
'(("AUTO" "inputenc" t ("pdflatex"))
  ("T1" "fontenc" t ("pdflatex"))
  ("" "fontspec" t ("lualatex" "xelatex"))
  ("AUTO" "babel" t ("pdflatex" "lualatex"))
  ("AUTO" "polyglossia" t ("xelatex"))
  ("" "graphicx" t)
  ("" "grffile" t)
  ("" "longtable" nil)
  ("" "wrapfig" nil)
  ("" "rotating" nil)
  ("normalem" "ulem" t)
  ("" "mathtools" t)
  ("" "amssymb" t)
  ("" "textcomp" t ("pdflatex"))
  ("warnings-off={mathtools-colon,mathtools-overbracket}" 
"unicode-math" t ("lualatex" "xelatex"))
  ("" "caption" nil)
  ("" "booktabs" t)
  ("" "hyperref" nil)
  "\\tolerance=1000"))

--8<---cut here---end--->8---

To switch e.g. to lualatex (and e.g. use latexmk for compiling), I
use:

--8<---cut here---start->8---

(setq org-latex-compiler "lualatex")
(setq org-latex-bib-compiler "biber")
(setq org-latex-pdf-process '("latexmk -f -pdf -%latex -outdir=%o %f"))

--8<---cut here---end--->8---

--
Until the next mail...,
Stefan.

Re: A requires/provides approach to linking source code blocks

[Stefan Nobis]

Marko Schuetz-Schmuck  writes:

> I would find it useful to have a more declarative way for specifying
> sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to
> capture dependency and then have the exporter compute a sequence
> satisfying these.

I would say that declaring an explicit ordering of blocks via noweb is
quite declarative.

The tensions seems more to be between implicit and explicit ordering.
I'm quite a fan of letting the computer compute things, but in the
context of literate programming I tend to prefer explicit over
implicit. IMHO that's the main point of literate programming: Be more
explicit and document all the details. Try not to hide important
aspects.

If you have so many blocks that maintaining the order of the
concatenation seems like a burden and tiresome I would argue that you
are doing it wrong. Because in the end you need quite a good
understanding of the final order of the blocks or else maintaining the
implicit order via require/provide will also get out of hand.

I also second Tims concerns about the additional complexity and
feature creep.

-- 
Until the next mail...,
Stefan.

Re: suggestion to change default org-latex-pdf-process to latexmk

[Stefan Nobis]

Colin Baxter  writes:

> I really don't understand why the changed is needed.

The upcoming citation support needs a reliable way to run the required
bibliography processor (e.g. biber or bibtex). Therefore the current
default setting that only runs latex three times does not suffice.

On the other hand running biber unconditionally will result in errors
if no citation and bibliography has been used in the document.

So we need a more sophisticated method to run the LaTeX engine and
associated tools. One way would be to use something that tries to
do exactly this: Depending on the LaTeX document and/or the log file
decide what's left to do to get a properly set result. With latexmk it
is also easier to handle generation of index or glossaries files etc.

Or we try to re-build something like this in Elisp (which would be
nice but quite a lot of work; even if we utilize the lessons learned
from latexmk).

-- 
Until the next mail...,
Stefan.

Re: suggestion to change default org-latex-pdf-process to latexmk

[Stefan Nobis]

Scott Randby  writes:

> (1) Which one of the above suggestions should I use? I don't want
> interactions when I'm exporting. I don't want to have to mess with a
> configuration file either.

> (2) How many shell commands will org-latex-pdf-process need? Right
> now there are three. Replace those three with just one latexmk?

I have

--8<---cut here---start->8---
(setq org-latex-pdf-process '("latexmk -f -pdf -%latex -outdir=%o %f"))
--8<---cut here---end--->8---

in my Emacs configuration. The nice thing with latexmk is, that a
single call will suffice. It reads the generated log and checks
whether multiple calls to the LaTeX engine are necessary (after each
run it check whether another run is need, up-to the configurable
maximum of 5 runs). Therefore in some cases (depending on used LaTeX
packages and commands) latexmk may even produce the PDF faster, if
only one or two passes are necessary. But sometimes LaTeX thinks it
may need more passes (e.g. having undefined references, unstable
output due to dynamically generated things at page breaks for example
with cleveref and varioref where floats/references are put on one page
in one run and another page in the following run) - and in these cases
creating the PDF may take a bit longer due to the maximum of 5
(instead of only 3) runs.

Hope that helps a little bit.

-- 
Until the next mail...,
Stefan.

Re: suggestion to change default org-latex-pdf-process to latexmk

[Stefan Nobis]

Tim Cross  writes:

> One reason is that latexmk is not installed on some systems.

Just after starting to write that this is false nowadays I realized
you are right. :)

See: https://mg.readthedocs.io/latexmk.html

For macOS latexmk is distributed with the default TeX installation
MacTeX for quite some years (IIRC at least since 2012). And it is
working OOTB.

As far as I know the default TeX installation for Windows is MikTeX
(is this still true?), which also includes latexmk but lacks the Perl
part (therefore Perl needs to be installed manually). But there is
TeXLive for Windows and as far as I understand in this case Perl is
also installed and latexmk works OOTB.

A manual installation of TeXLive for Linux should also install latexmk
(and Perl should also be available on next to every Linux box). Only
some distributions bundle latexmk in a separate package - that should
be easy to install (but breaks PDF creation if forgotten).

Therefore: latexmk is available on all plattforms and in most cases it
is already installed with the TeX system or easily installable. But
not in all cases does it work OOTB and requires more work like
installing Perl on Windows.

In my opinion its worth to depend on this tool as it makes handling
LaTeX documents much easier. On the other hand it may raise the bar
for some users just to high. Hard to say.

An alternative may be to use latexmk only if citations are found (new
feature, new dependencies). Or a wrapper that checks whether latexmk
is available and works (e.g. trying to call "latexmk --version") and
falls back to the old routine of manually running the engine and
bibtex/biber if necessary.

-- 
Until the next mail...,
Stefan.

Re: suggestion to change default org-latex-pdf-process to latexmk

[Stefan Nobis]

"Bruce D'Arcus"  writes:

> Here's the current command for the "latexmk" option:

> "latexmk -g -pdf -pdflatex=\"%latex\" -outdir=%o %f"

> ... and here's what you have, minus shell-escape.

> "latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f"

The option "-interaction=nonstopmode" forbids user interaction (like
asking for a missing file). Without this explicit option latexmk uses
"-interaction=batchmode" by default - in this case some diagnotic
messages to the terminal (not log file) are suppressed. Thus the
default option from latexmk might suffice.

Regarding "-f" versus "-g" I personally would slightly prefer "-f" for
performance reasons. With "-g" the document will always be newly
generated, even if nothing changed. This is only useful if the latexmk
config (or some environment variable) has changed. Other changes
should be detectable by latexmk, so "-f" should suffice.

The options "-output-directory" and "-outdir" are synonyms.

Regarding the choise of engine: "-pdflatex=\"%latex\"" explicitly sets
the command (including options) to be called by latexmk, without
letting latexmk know that the engine changed. Using "-%latex" (e.g.
the option "-lualatex" or "-xelatex") lets latexmk know that a
different engine should be used.

This matters at least for xelatex, because latexmk can utilize some
optimizations if it knows that xetex is used. In this case the first
runs only produce .xdv files and only the last run will produce the
full pdf to save time (see also option "-pdfxe" which is triggered by
"-xelatex").

Therefore I would tend to use this call:

"latexmk -f -pdf -%latex -outdir=%o %f"

All other aspects of latexmk should be configured via config file
(IMHO).

> In any case, whatever the command is, clearly it should.

Yes, I would also recommend latexmk (it may also speed up PDF
generation, because in quite some cases a single or two passes suffice
and latexmk is quite good in detecting these cases).

-- 
Until the next mail...,
Stefan.

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Stefan Nobis]

Nicolas Goaziou  writes:

> By default, no export processor is selected. All citations are
> removed from output, and print_bibliography keywords, ignored.

As I'm coming from LaTeX and have been bitten more than once by
missing citations in the output (which is solved far better today by
biblatex), I would say this is not a very good default.

Citations should never be removed (or only with quite some effort). If
you publish a text where citations have been removed by accident,
that's asking for much trouble.

Therefore I would suggest to set some sensible default that at least
does not remove citations. For example a simple ASCII export with
number or author-year style could be the default citation export for
all back-ends. For quite some users (e.g. non-academic, internal
white-papers etc.) this may be also a "good enough" solution, so they
get easy citation support OOTB.

Everyone else would choose some more sophisticated back-end.

> It could be possible to change `org-cite-export-processor' so it
> becomes an alist where you can associate back-ends to processors.
> But I can't see how to transpose it nicely to cite_export keyword.

What about "cite_export" for a single/default export engine and
"cite_export_" (with "" something like "html",
"latex", "md", etc.) for overriding the citation exporter for the
given back-end, e.g.

cite_export ascii
cite_export_latex biblatex chicago
cite_export_html csl "some style"

(I forgot about the correct syntax for cite_export, so just a really
rough sketch to illustrate the idea).

Would that be feasible?

> I'm not convinced this would be an improvement either. For example,
> you may want to use two different processors with the same back-end.

I'm not sure if this is true for many back-ends. Currently, I would
assume that this is only the case for the LaTeX back-end (e.g.
preparing a paper for different journals with different citations
requirements). But in this case LaTeX has already quite some tools
that could be utilized. All the different kinds of citation commands
are there to be able to easily switch styles for the whole document
(within a single back-end).

I think what I'm trying to say is, that for the simple Org user it may
be easier to handle peculiarities of his back-ends (like HTML and
LaTeX) that it is for him to write custom Elisp to use exporter A for
HTML and exporter B for LaTeX.

-- 
Until the next mail...,
Stefan.

Display ellipsis at end of headline instead of after tags

[Stefan Nobis]

Hi.

I would prefer to see headline ellipsis always at the end of the
headline, but if tags are present, the ellipsis is drawn after the
tags.

So currently I have something like this:

#+begin_example
,* Headline One...
,* Another Headline  :tag:another:...
,* Third Headline...
#+end_example

But I would prefer this:

#+begin_example
,* Headline One...
,* Another Headline...   :tag:another:
,* Third Headline...
#+end_example

I skimmed through available variables and the code, but I found
nothing to configure this kind of behaviour. Is there an easy way to
accomplish this?

-- 
Until the next mail...,
Stefan.

Re: Microsoft Excel spreadsheet editing directly from within emacs.

[Stefan Nobis]

Jean Louis  writes:

> You speak of a programming language and what is possible with
> programming language.

That's not the point. Org table is integrated with Calc and Calc is a
Computer Algebra System. That is something like Excel combined with
Mathematica (with a little less GUI stuff) - that is powerful
integration to me.

Lisp is nice and for me as a programmer a helpful tool. But the main
point is Calc.

Just putting data in a tabulated form is seldom the interesting part.
It starts to get interesting when you try to do something with the
data, e.g. make some calculations. At this point it is significant,
how many calculations you can do out-of-the box (without much
programming). I did not count, but I assume that Calc has more
calculations to offer than Excel and even for a wider range of topics
(even symbolic math).

Therefore, from this point of view of core functionality, I would say
Org tables with Calc are more powerful that MS Excel. And thinking of
the many quirks and bugs in MS Excel, I still say: Excel is the toy
software and Emacs + Org + Calc is more mature and more professional
and the file format much more future proof (yes, nowadays Excel uses
XML, but the definition and documentation is lacking and too complex;
it seems not possible to re-implement it fully).

I emphasize this, because you wrote: "In comparison to all major known
spreadsheets Org tables is not powerful and not even comparable."

And "powerful" for me means core features, i.e. calculations. And in
this respect, I think the statement is wrong.

> In a spreadsheet program I may visually and nicely presented see a
> slice of a whole table. I may move from slice to slice to other
> pieces of the whole table of data. Moving from cell to cell is
> pretty easy and there are no screen distortions.

If your point of view is, that the main feature are the visual
interactions (hiding/revealing rows/columns, sorting, filtering data
etc.) then yes, maybe Org lacks a bit in these areas (but I think not
quite as much, as you imply; e.g. Org can show labels for rows and
columns and there are ways for hiding, sorting and filtering).

On the other hand: I do find GUI spreadsheets also quite lacking in
this regard (e.g. regex pattern are seldom easy to use). If I need to
tinker with data, explore it, I would put it into a database (or into
R or Julia or - depending on the size of the data - using R/Julia from
within Emacs via Org tables). That's much faster, maintainable and
reproducible.

> Spreadsheet user interface is integrated, it does not require user
> to remember much, or maybe nothing, just use a mouse.

Nice try: There are tons of books about the question what are the best
user interfaces. I have seen people working with computers with
exactly this mindset: "I do not need to learn/remember anything, it
should be easy, just clicking a bit with my mouse". At this level, it
just does not work.

So, yes, a very text-oriented UI is not the best solution for every
task. But then a GUI is also not the best solution for every task.

> Org mode is bringing us back into the era before Doug Engelbart.
> Back to history.

That's IMHO a very simplistic and ignorant view on UX. The problem is
much more complex and yes, in quite some cases are text-based
interfaces even one of the best solutions (and next to never exists a
single best solution, UX always depends very strongly on context and
details).

> Combining various sheets is standard spreadsheet feature. Examples
> you have shown are cryptic for spreadsheet users.

I once showed rather simple Excel sheet to an Excel user and he was
overwhelmed and did not understand how to create such a structure (2-3
tables with formulas across tables). So Excel is cryptic for
spreadsheet users, too. :)

With other words: No tool is simple, you need to learn at least a
little bit - in all cases. I only showed the final result, not the way
how it has been created. Emacs and Org have ways to ease some of the
seemingly complicated parts, just as Excel tries to help formulate
complicated calculations. And then comes habit.

I fully understand that a tool like Excel at least seems to be easier
for the first steps. But that does not mean that it is a given fact,
that it is easier and better suited for any task that is spreadsheet
like (you already mentioned databases - I would say for the typical
spreadsheet users databases are even more cryptic that Emacs and Org).

>> Maybe advanced visual presentation of the data is easier with GUI
>> Spreadsheets -- then again, it is so easy to combine Org tables with
>> the power of Gnuplot, R, Python, Julia, TeX etc. to create
>> astonishing visuals, that I prefer this way in many situations.

> That is like saying to a user to switch from Emacs to C programming
> language as it gives user far more capabilities

No, quite the contrary. I think, this is the main point, you seem not
to understand. Emacs with Elisp is much more expressive than C. Org
with Calc is (for 

Re: Microsoft Excel spreadsheet editing directly from within emacs.

[Stefan Nobis]

Jean Louis  writes:

> I find Org tables useful for small reports. Just as table mode is
> also useful within Emacs. Org tables are primitives that are not
> comparable to spreadsheet software.

It might be a difficult question, whether Org tables are the best
solution in a given situation or whether it is the best interchange
format to use with arbitrary people (but I also doubt that MS Excel is
a good way - I have seen really nasty and expensive problems caused by
the use of Excel to move data around).

But Org tables are very powerful and in many cases even far superior
than most other spreadsheet software (especially MS Excel - I can't
count the number of times that Excel tried to be smart and made a
total mess of my data).

Here is a short example of what is possible with Org tables:

#+begin_src org
,* Org Spreadsheet

,** Example from the Manual

See [[https://orgmode.org/manual/Advanced-features.html#Advanced-features][The 
Spreadsheet - Advanced features]].

|---+-+---+-+--|
|   | Func| n | x   | Result   |
|---+-+---+-+--|
| # | exp(x)  | 1 | x   | 1 + x|
| # | exp(x)  | 2 | x   | 1 + x + x^2 / 2  |
| # | exp(x)  | 3 | x   | 1 + x + x^2 / 2 + x^3 / 6|
| # | x^2+sqrt(x) | 2 | x=0 | x*(0.5 / 0) + x^2 (2 - 0.25 / 0) / 2 |
| # | x^2+sqrt(x) | 2 | x=1 | 2 + 2.5 x - 2.5 + 0.875 (x - 1)^2|
| * | tan(x)  | 3 | x   | x pi / 180 + 5.72e-8 x^3 pi^3|
|---+-+---+-+--|
,#+TBLFM: $5=taylor($2,$4,$3);n3

,** Even symbolic math

|-++---|
| Func| Derivative | Integral (over [a, b])|
|-++---|
| x^2 | 2 x| x^3 / 3   |
| exp(x^2)| 2 x exp(x^2)   | erf(i x) sqrt(pi) / (2 i) |
| ln(x^2) | 2 / x  | 2 x ln(x) - 2 x   |
| sqrt(x) | 0.5 / sqrt(x)  | 2:3 sqrt(x^3) |
| 2x + sin(y) | 2  | x^2 + x sin(y)|
| sin(1/x)| cos(1 / x) pi / (-180 x^2) | integ(sin(1 / x), x)  |
|-++---|
,#+TBLFM: $2=deriv($1, x);S::$3=integ($1, x);S

,** Combine data from different tables
,*** Some special expenses
,#+NAME: tab-special
| Position | Amount |
|--+|
| Abo part 1   | 299.22 |
| Abo part 2   | 299.22 |
| Some random item | 210.83 |
|--+|
| Sum  | 809.27 |
,#+TBLFM: @>$2=vsum(@I..II)
,*** Tax calculation for my room
,#+NAME: tab-room
|   | Position   |   Amount |
|---++--|
|   | Area Room  |11.00 |
|   | Area Flat  |77.42 |
|   | Costs per year | 12000.00 |
|   | Some insurance |   300.00 |
|   | Electricity|   700.00 |
|---++--|
| _ ||A |
|   | Area fraction  |  0.14208 |
|   | tax-deductible Rent|  1747.58 |
|   | tax-deductible Electricity |99.46 |
,#+TBLFM: $A=@2$3/@3$3;%.5f::@>>$3=$A*@4$3+$A*@5$3;%.2f::@>$3=$A*@6$3;%.2f
,*** Summary
,#+NAME: tab-summary
| Position   |  Amount | Comment |
|+-+-|
| Special costs  |  809.27 | |
| Deductible Rent| 1747.58 | put in form field A |
| Deductible Electricity |   99.46 | put in form field B |
| Something else | 1234.56 | very special|
|+-+-|
| Sum| 3890.87 | |
,#+TBLFM: @2$2=remote(tab-special,@>$2)
,#+TBLFM: @3$2=remote(tab-room,@>>$3)
,#+TBLFM: @4$2=remote(tab-room,@>$3)
,#+TBLFM: @>$2=vsum(@I..II)
#+end_src

In respect to core features (listing data, using formulas for
calculation) I doubt that Emacs with Org tables and Calc is missing
anything. Maybe advanced visual presentation of the data is easier
with GUI Spreadsheets -- then again, it is so easy to combine Org
tables with the power of Gnuplot, R, Python, Julia, TeX etc. to create
astonishing visuals, that I prefer this way in many situations.

>From my point of view, MS Excel is the toy (I have not too much
experience with the other GUI spreadsheet programs). In Emacs I have
the power of Calc (a complete computer algebra system) and Lisp (the
best programming language, even if Elisp is not Common Lisp) at my
fingertips. 

Re: Changed list indentation behavior: how to revert?

[Stefan Nobis]

"Dr. Arne Babenhauserheide"  writes:

> Sad story short:...

I'm with you - last weekend I upgrade my OS and had quite some trouble
to get everything working again and still have some nasty hoops to
jump through.

But on the other side: What are we talking about?

Org had a given default configuration for quite some time. To be
clear: THIS DID NOT CHANGE!

But some people are upset now. Why? Because the emergent behaviour
changed. Not the underlying default configuration, but in the context
and details of how each individual uses Org for some users the default
configuration was emergent and evident, but some other users did not
perceive this default configuration.

Now a simple setting, syncing Org with the defaults of Emacs and other
modes with respect to RET and electric-indent-mode, make the OLD,
UNCHANGED default configuration emergent for almost all users.

These are very subtle effects inside a very complex environment.

How should maintainers be able to foresee all possible environments
and use cases and the resulting emergent behaviour?

I'm really surprised that such a simple and insignificant breaking
change results in such a uproar. If a new Org version make all old
files completely unusable or a bunch of important features is totally
broken, say nothing of babel works anymore - yes, is such a case I
would understand the uproar.

But ranting so loudly and insistent and continuously over such a minor
details is really beyond me.

And nobody has to read all NEWS and Changelogs for every single peace
of software they are using. If nothing breaks maybe there is nothing
to worry about. If some minor detail like the new emergent indentation
behaviour annoys you - just have a quick look in the NEWS file of the
new version. Is this really that hard?

On the other hand: What's the alternative? Never change anything
again? Maybe some users rely on the emergent behaviour of some bad
bug (that has bad consequences for some other users). Should it never
be changed, because it may annoy some users and they could be forced
to read the NEWS file?

You cannot have the cookie and eat it!

So, everyone, please calm down and try not to overreact over really
simple, negligible details.

-- 
Until the next mail...,
Stefan.

Re: New website - back to the old unicorn!

[Stefan Nobis]

TEC  writes:

> This seems very suspicious for one reason. I cannot see "Canvas"
> anywhere in the entire codebase of the website, or any loaded
> resources. So I have no idea where on earth the JS you're finding
> has come from - I'm guessing it's improperly injected by a
> extension. FWIW I also run Decentraleyes in Firefox and fail to see
> your issue.

Thanks for your response. So maybe a local error (I think I deactivate
all plugins bug Decentraleyes, but maybe its the combination of
Decentraleyes with Vivaldi or I made another mistake). I will
investigate further when I have a bit more time. For now please assume
this issue as resolved. :)

-- 
Until the next mail...,
Stefan.

Re: New website - back to the old unicorn!

[Stefan Nobis]

Hi.

Thanks for your great work and the wonderful new page!

A minor detail: I use the plugin "Decentraleyes" and with this
activated there is quite a bit JavaScript garbage at the end of the
page (below the "Created by" footer). The part below the footer is
this:

#+begin_src js
{ const iframes = window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i < 
iframes.length; i++) { if (iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData = 
CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }
#+end_src

When I deactivate Decentraleyes and reload the page, the above code
snippet vanishes. This glitch is present both on the official page and
on https://orgmode.tecosaur.com. It seems, there is some weird
interaction with some script from a CDN (maybe loaded partially due to
constraints from the plugin) or something like that.

-- 
Until the next mail...,
Stefan.

Re: The Website Revamp: The final stretch

[Stefan Nobis]

TEC  writes:

> 2. Picking the best 'Hero banner' on the home page ::

I like Variant 1-1 the most - all other variants are a bit too big and
yelling for my eyes.

Maybe use size and layout of Variant 1-1 with colors of the last
variant (page 9, gray background)?

-- 
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

"Thomas S. Dye"  writes:

> There are many pieces of software that will allow the user to the
> violate best typesetting practices easily. LaTeX is not one of them.

Not quite right. I have seen people create really ugly source code
*and* ugly output with LaTeX with ease. You can create garbage with
any kind of software. :)

-- 
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

Emanuel Berg via "General discussions about Org-mode."
 writes:

>> #+attr_latex: :center nil :booktabs t
>> | My | Columns |
>> |+-|
>> |  1 |   2 |
>> |  3 |   4 |

> "PDF file produced with errors."

Sorry that I try to make more general examples that are not exactly
tailored to your use case. As I said in the paragraph above that
example, the package "booktabs" is needed (it is one of my default
packages, so in my config it will always be added to LaTeX code
generated by Org). So either add "#+latex_header:
\usepackage{booktabs}" or remove the ":booktabs t" part.

-- 
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

Emanuel Berg via "General discussions about Org-mode."
 writes:

> OK, but the values still ned to be specified, right?

No, just use the package - it sets the relevant lengths to change the
style of marking paragraphs and tries hard to also reset every other
length that depends on the original values of these variables.

Here is an example of a quite minimal LaTeX document that should show
the effect:

#+begin_src latex
\documentclass{article}
\usepackage{blindtext}
\usepackage{parskip}
\begin{document}
\Blinddocument
\end{document}
#+end_src

As I said: The lengths parskip and parindent are very far-reaching,
fundamental variables in LaTeX. They are used in many places and
globally setting them may lead to unexpected side-effects.

If you just look at a couple of paragraphs you won't see any problems.
But if you write more complex documents, using packages like listings to
display code, use other environments mixed with paragraphs and lists,
there will occur problems with the spacing.

I don't remember all the details, I just always remember to use either
the package parskip or (in most of my use-cases) the documentclass
option "parskip=full" from the Koma script classes (that I use nearly
exclusively) - when I... consider to use this style of marking
paragraphs. :)

--
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

Samuel Wales  writes:

> for my part, i appreciate your using the "wrong" style for your
> email message

A plain text document presented in a monospaced font is quite a
different thing than a (longer) PDF with a plethora of layout and
micro-typographic options.

Do you also appreciate the workarounds to represent complex math
formulas in plain text and do you prefer these workarounds to a nicely
set formula in e.g. a PDF?

So I would say everything depends on the context. In books I very much
prefer the usual style of marking paragraphs by indenting the first
line and no extra space between paragraphs. IMHO much easier to read
(and in case of books with many special elements like formulas also
much less ambiguous).

But in other contexts (even when producing PDFs via LaTeX) other
styles may be preferable. I just add my remarks because I just too
often see the "mail style" marking of paragraphs in longer texts
(reports etc.) where the usual "book style" would be much more
friendly to at least my eyes. Just be aware of the options and try to
find a style that is pleasant to most of your readers. :)

-- 
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

Eric S Fraga  writes:

> #+latex_header: \setlength{\parindent}{0pt}
> #+latex_header: \setlength{\parskip}{\baselineskip}

Better use

#+latex_header: \usepackage{parskip}

as this package has less bad side-effects on other parts of the
document than setting these far-reaching lengths directly.

But otherwise I second your recommendation to not use this style of
marking paragraphs if not absolutely required.

-- 
Until the next mail...,
Stefan.

Re: "text mode" org mode

[Stefan Nobis]

Emanuel Berg via "General discussions about Org-mode."
 writes:

> Thanks, I wonder tho if all this

>   (setq org-descriptive-links  nil)
>   (setq org-hide-emphasis-markers  nil)
>   (setq org-startup-folded'showeverything)

> is implied, with `visual-mode'?

Beware: =visible-mode= not "visual"!

As far as I understand the internal of Org an Emacs, some of the
visual features of Org are implemented with overlays, some are
implemented with text properties. Disabling visible-mode just makes
invisible text visible - but I do not fully understand whether this
affects really all kinds of "invisibility" or just some.

So I for myself prefer to say Org explicitly what I want instead of
trying to take advantage of an indirect effect that may disturb Orgs
internal state (or not; I just do not understand enough of Org and
Emacs internals to really judge this).

-- 
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

Emanuel Berg via "General discussions about Org-mode."
 writes:

> Tim Cross wrote:

>> #+latex_class: korma-article

> user-error: Unknown LaTeX class ‘korma-article’

>> #+latex_header:  \setlength{\parindent}{0pt}

> Yes, that's removed the indentation but didn't insert
> a blank line...

First of all: You don't want this. :)

Marking paragraphs by blank lines and without indentation is deemed
less readable (see for example section 3.10 "Marking Paragraphs" in
https://komascript.de/~mkohm/scrguien.pdf).

But if you really insist on using this style, still the variant of
setting the length parindent and parskip is considered bad practise.
These are very fundamental values for LaTeX and influence a lot more
that just the space between paragraphs. A much better solution would
be to use the package =parskip= (just add "\usepackage{parskip}" to
the preamble of the LaTeX document or add "#+LATEX_HEADER:
\usepackage{parskip}" to the preamble of the Org document).

If you want to customize the Org LaTeX export more globally, you can
put something like this in your Emacs init.el:

#+begin_src elisp
(add-to-list 'org-latex-classes
   '("koma-article"
 "\\documentclass[a4paper, pagesize, headings=normal, 
version=last]{scrartcl}"
 ("\\section{%s}" . "\\section*{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
 ("\\paragraph{%s}" . "\\paragraph*{%s}")
 ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))

(setq org-latex-default-class "koma-article")

(setq org-latex-packages-alist
'(("" "unicode-math" t ("lualatex" "xelatex"))
  ("" "caption" nil)
  ("" "booktabs" t)))
#+end_src

In the case of the document classes of the Koma world, you have quite
some options for paragraph formatting. If you still insist on your
style of paragraph markings, you may add "parskip=full" to the
global options of the documentclass.

With the above settings, you globally define your preferred LaTeX
documentclass and some global settings as well as add some additionals
packages that are used on every LaTeX export done via Org. So you do
not have to put anything special in the individual Org documents but
the pure content (at the cost that the same Org document may produce a
different output on other Emacs installations with different global
settings).

For more details on what can be configured see
https://orgmode.org/manual/Exporting.html#Exporting. The options there
are mostly presented as in-document settings but most if not all of
them may also be set in some way globally via Emacs init.

-- 
Until the next mail...,
Stefan.

Re: basic org questions

[Stefan Nobis]

Hi.

Details about Org tables are to be found in the manual at different
places (maybe not optimal, but that's the current structure). First of
all, aspects of tables inside Emacs and Org are discussed here:

   https://orgmode.org/manual/Tables.html#Tables

But everything about exporting (generating PDF via LaTeX, HTML, etc.)
is discussed in the export sections. So details about exporting Org
tables to LaTeX can be found here:

   https://orgmode.org/manual/Tables-in-LaTeX-export.html#Tables-in-LaTeX-export

Here you can find the relevant option ":center". For example the
following Org table will be exported to LaTeX without centering and
using the booktabs package to nicely format the table:

--8<---cut here---start->8---

#+attr_latex: :center nil :booktabs t
| My | Columns |
|+-|
|  1 |   2 |
|  3 |   4 |

--8<---cut here---end--->8---


Generally, you have the option to just let Org handle all of the LaTeX
details. In this case, in most cases you do not even need to know
anything about LaTeX - that's what some people are excited about. On
the other hand, in this case you get what Org thinks is good enough
for you. If you want to fine-tune every detail about the resulting
PDF, you have no choice but to know LaTeX and use the options and
hooks to sprinkle your fine-tuning in the document.

BTW: I'm a long-time LaTeX user and a big fan of LaTeX. If I want to
typeset a document and tune any detail of it, in most cases I use
LaTeX and not try to modify Org to generate my hand-optimized LaTeX
code. On the other hand nowadays in many cases I just do not need to
control every little aspect of my final documents or the LaTeX code.
In these cases Org helps a lot to speed up creating simple, small
documents. I customized some aspects once globally and have to type
less (but still know LaTeX and sprinkle a few fine-tunings here and
there). So sometimes I view Org as a kind of very flexible LaTeX
template engine. :)

-- 
Until the next mail...,
Stefan.

Re: "text mode" org mode

[Stefan Nobis]

Emanuel Berg via "General discussions about Org-mode."
 writes:

> Stefan Nobis wrote:

>> (setq org-link-descriptive nil)

> I don't have org-link-descriptive, it seems...

No problem, the old name is =org-descriptive-links= (this name has
been deprecated in Org 9.3, but it is still working in 9.4).

-- 
Until the next mail...,
Stefan.

Re: "text mode" org mode

[Stefan Nobis]

Emanuel Berg via "General discussions about Org-mode."
 writes:

> Can I tell Org mode to don't change editing back and
> forth, also don't collapse items in and out, i.e.
> virtually text mode

I did not test it to every detail, but the following two settings may
be a good starting point:

#+begin_src elisp
(setq org-startup-folded 'showeverything)
(setq org-link-descriptive nil)
#+end_src

Also have a look at all the ~org-toggle-*~ commands like
~org-toggle-link-display~ and ~org-toggle-pretty-entities~ (the source
of these commands should reveal the associated variable that can be
set globally to the desired start value).

--
Until the next mail...,
Stefan.

Re: org-time-stamp in German or Spanish or....

[Stefan Nobis]

Uwe Brauer  writes:

> But it still inserts <2020-09-06 Sun>

What's the value of `system-time-locale'?

In a shell (like Bash), is there a difference between the following
two commands:

#+begin_src bash
LC_TIME=C date
#+end_src

#+begin_src bash
LC_TIME=de_DE date
#+end_src

-- 
Until the next mail...,
Stefan.

Re: org-time-stamp in German or Spanish or....

[Stefan Nobis]

Uwe Brauer  writes:

> But is inserts the name of the days in English

The format and language of the time-stamps is controlled by the
function format-time-string (the docstring of this function shows all
the available placeholders, including "%a" for the locale's
abbreviated name of the day of week).

So the name of the days should be controlled by the locale Emacs is
running in (or the relevant language settings inside Emacs).

For example I want to enforce English names, so I have in my init.el:

#+begin_src elisp
(set-language-environment "English")
(set-locale-environment "en_US.UTF-8")
#+end_src

You can check what locale Emacs is using by inspecting the variables
`current-language-environment', and especially `system-time-locale'
(for the case that LC_TIME is set differently than other locale
settings).

-- 
Until the next mail...,
Stefan.

Re: issue tracker?

[Stefan Nobis]

Detlef Steuer  writes:

> I would go as far as saying *this list* is one of the fastest
> reacting amd friendliest communities I have been part of. The job
> Nicolas does is just awesome.

+1!

-- 
Until the next mail...,
Stefan.

Re: wip-cite status question and feedback

[Stefan Nobis]

Joost Kremers  writes:

> I don't think it's necessary to use a dash (or any other character)
> in longer cite commands, though. =citeintext= isn't that much more
> difficult to read than =cite-intext=. (Biblatex does just fine
> without dashes, and there's always camelCase if you're so inclined.)

It is not necessary, but it may be an opportunity to introduce
namespaces. For example cite and citeX (with a single letter) is
strictly reserved for Org core. Package may introduce new commands
like "cite-subcommand" with a single dash and something like
"cite--subcommand" or "cite/subcommand" is reserved for local use by
users and should not be used by packages.

I think citation needs are quite manifold and thus there might be many
upcoming packages each supporting some special needs. Therefore it
would be nice to a some simple kind of namespaces for commands to
avoid name clashes when using multiple specialised support packages at
the same time.

-- 
Until the next mail...,
Stefan.

Re: wip-cite status question and feedback

[Stefan Nobis]

Nicolas Goaziou  writes:

> Alphanumeric suffix provides 62 combinations, which should hopefully
> be enough for any citation back-end out there (I'm looking at you
> biblatex). It's not terribly readable, tho, as you point out.

I second that. Some of the many BibLaTeX commands are due to
compatibility with other (older) packages and to ease transitions.

Another aspect: Maybe it would be a good idea to reserve some chars
(e.g. the numeric ones) for user defined citation commands (a
minimalistic reserved namespace).


[Placing bibliography with "#+bibliography: here"]
> It is smart, but I'm not sure I like using the same keyword for two
> different things. OTOH, I don't have a better idea.

I personally also dislike one keyword for completely different
purposes. Therefore I suggest to take the idea from BibLaTeX and use a
keyword like "printbibliography" the mark the place where the
bibliography should be output.

This command may also have parameters like filtering options (maybe
depending on the backend processor; I only know BibLaTeX so I can't
say if it would be easy to abstract away differences between different
engines). In the case of BiBLaTeX the printbibliography command
optionally accepts multiple key-value parameters. Some examples for
the keys are "heading" for the chapter/section heading, "type" to
output/print only entries of a certain type (like "book"; or type
"online" and with the additional key "nottype" separate non-online and
online sources), "keyword" to filter entries with the associated
keyword etc.

Another nice feature of BibLaTeX is the possibility to generate
bibliography per chapter/section (e.g. setting conference
proceedings). In the simplest case each chapter/section is marked, in
the case of LaTeX/BibLaTeX it is wrapped with "\begin{refsection}" and
"\end{refsection}" and the printbibliography command occurs inside
this refsection block. In this case BibLaTeX defaults to output only
references used inside the marked block.

[Style selection]
> I think this part is out of Org's scope. Since values between
> various citation back-ends are probably not compatible, e.g., some
> may require a file, others a style name, normalization is not useful
> here. They can use whatever keyword they fancy.

Yes, I second that. But it may be worth thinking a second about using
one Org document to generate output with different backends (e.g. PDF
via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have
some way to configure each citation engine form the same document.
Either use different keywords like "#+CSL_STYLE" and
"#+BIBLATEX_STYLE" or we use your original suggestion of a ":style"
parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to
translate its value individually for each engine - e.g. an alist or
some function provided by the user. And if no translation is provided,
just give the value verbatim to the engine, thus if a user only
targets a single backend, he does not need to provide any
extra configuration.

Just my 2¢.

-- 
Until the next mail...,
Stefan.

Re: Bug or not a bug? dot expansion in ob-shell

[Stefan Nobis]

Bastien  writes:

> I agree we should have a discussion on whether :results value is a
> good default.

What about a third collection option 'none' and make this the default?

This would emphasize that there is no sensible default for all babel
languages, users and use cases. Users would be forced to explicitly
select either the 'value' or 'output' option, which also helps
reproducibility a little bit (explicit is better than implicit).

The downside would be that many existing Org documents needs to be
fixed (but maybe it would be not too hard to automate the adjustments)
and some source blocks may become a little more verbose.

Just my 2¢.

-- 
Until the next mail...,
Stefan.

Re: emacs build command for org-files

[Stefan Nobis]

John Kitchin  writes:

> Hi everyone,

> This is only semi-on-topic. I am looking for something like M-x compile for
> my org-files, but I don't want it to necessarily use Makefiles. I am
> looking for suggestions of existing solutions to this, or thoughts on how
> to implement this.

This may not be the solution you are looking for, but maybe a good
source of ideas:

   https://github.com/doublep/eldev

Another idea: Just use a (configurable) function name or source block
name to look for in a document. Then some magic function (say
org-compile-document) can look for a custom function/block inside the
document (e.g. look for a marked source block) and execute it, if
found. If no custom function/block is found, some default action will
be executed (e.g. ask user what to do, run pre-configured default
export action etc.).

-- 
Until the next mail...,
Stefan.

Re: very strange LaTeX error

[Stefan Nobis]

"Fraga, Eric"  writes:

> However, it seems that simply adding \relax does not work if there
> is an \hline immediately following so the solution is not that
> straightforward.

Hmmm... but it should be solvable. Maybe something along the lines of
this (rough sketch, I have next to no experience with the org code
base):

#+begin_src emacs-lisp
(defun org-latex--table-newline (table-row info)
  (let ((next-el (org-export-get-next-element table-row info)))
(concat ""
(when (and next-el
   (not (eq (org-element-property :type next-el) 'rule)))
  "\\relax")
"\n")))
#+end_src

-- 
Until the next mail...,
Stefan.

Re: very strange LaTeX error

[Stefan Nobis]

"Joost Kremers"  writes:

> The solution I usually opt for is to enclose the brackets in an
> additional set of braces: `{[...]}`. Whether Org export can and
> should automate that, I can't say.

In the generated LaTeX adding a '\relax' (so each line ends with
'\\\relax') would be a another solution. The \relax ends the
macro-expansion and thus '\\' does not look further for optional
arguments.

As the org-table does not support all the fancy features of LaTeX
tables and the LaTeX row/line break is generated implicitly, I would
say the LaTeX export should always emit the additional \relax.

-- 
Until the next mail...,
Stefan.

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Stefan Nobis]

Eric Abrahamsen  writes:

> I was confused in part because the "where exists (select *..." looks
> like its main purpose is to return rows.

Indeed that's the purpose: Restrict the set of rows upon which update
acts on. Here I tried to reformat the statement a bit in order to
emphasize its structure:

#+begin_src sql
  UPDATE bookreview
  SET rating = (select rating from updates
where bookreview.id = updates.id)
  WHERE EXISTS (select * from updates
where updates.id = bookreview.id);
#+end_src

The subselect of the "SET rating" part is a correlated subquery. So if
you imagine UPDATE as a kind of loop over the table, the subquery of
the SET part is executed once for every row UPDATE acts on (maybe the
SQL execution engine optimizes this in some kind, but the mental model
here is: run the subquery for every row we visit on our journey
throught the table).

Only the WHERE EXISTS clause belonging directly to the UPDATE
statement will reduce the set of rows to act on.

> Will the select subquery actually restrict the values that are
> available for updating/comparison in the update statement?

No.

> Or does the "exists" mean the subquery is treated as a plain yes/no
> boolean, and the update still has access to anything it likes? We
> could write "where exists (select " to the same effect?

Yes. The SELECT clause of an EXISTS subquery (as in the above example)
is rather meaningless. So somethimes you see constructs like "where
exists (select 1 from ...)". Some SQL engines are not very clever and
execute the subquery of such an EXISTS clause unchanged - meaning that
way too much data is fetched for the intermediate result (unnecessary
IO and maybe polluting caches). Thus the "select 1" as a workaround
for those unclever engines. But current engines should have no
problems with optimizing these EXISTS subqueries and in that case it
does not matter how the select clause looks like - it will be ignored.

> In essence, the "where exists" is acting as an "inner join"...

Yes, effectively we are simulating an inner join at this point. Sadly,
many SQL engines are not able to update rows of join constructs (or at
least have quite severe constraints in these cases). Thus we need to
build these kinds of workarounds to change data in more complex cases.

SQL is quite a capable language, but it has also has some rough edges.
:)

-- 
Until the next mail...,
Stefan.

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Stefan Nobis]

Eric Abrahamsen  writes:

> Okay, it's up. If anyone wants to explain to me the point of the
> "where exists" clause in the SQL, I would be interested to hear. It
> works as expected this way, but is that clause necessary?

Yes, very necessary. Without it, all ratings would be changed - the
two example rows without ratings (ids 5 and 12) would get the values
from the intermediary org table, every other row in table bookreview
would get its rating attribute set to null (because there is no
matching entry in the temporary updates table).

Remember: update without a where clause always touches every single
row of the complete table.

The "where exists" clause ensures that only those rows of bookreviews
are touched that are present in the intermediary org table. If you do
not like "where exists" you could say "where bookreview.id in (select
id from udpates)".

-- 
Until the next mail...,
Stefan.

[O] Clocktable creates superfluous columns

[Stefan Nobis]

Hi.

In version 9.0.5 Org (Emacs 25.1) seems to generate too many columns
in some situations. I'm not quite sure since which version this
happens, in Org 8.x I have not seen this behaviour.

Here is a small example:

--8<---cut here---start->8---
#+BEGIN: clocktable :maxlevel 3 :scope file :narrow 80! :compact
#+CAPTION: Clock summary at [2017-02-18 Sat 12:37], for February 2017.
| Headline  |   Time |   |   |
|---++---+---|
| *Total time*  | *0:15* |   |   |
|---++---+---|
| Some Tasks|   0:15 |   |   |
| \_  STARTED Task1 |   0:15 |   |   |
#+END:

* Some Tasks
** STARTED Task1
   :CLOCK:
   CLOCK: [2017-02-18 Sat 12:00]--[2017-02-18 Sat 12:15] =>  0:15
   :END:
--8<---cut here---end--->8---

It seems that the iteration over the items generates to many "|". And
top level headlines (e.g. "Some Tasks") each generate one more "|"
than their children (but even those seem to generate to many "|").

I did not fully understand the function org-clocktable-write-default,
so I'm not quite sure how to best fix this.

-- 
Until the next mail...,
Stefan.

Re: [O] Clocking work time vs. office time

[Stefan Nobis]

Marcin Borkowski  writes:

> No, you're not - this is one possible solution.  I'm curious about other
> ones.

If tracking the time you're at a specific location is your main
objective (and if you own a Smartphone), I would say: Geofencing. Let
your Smartphone track when you enter/leave the specific location. With
todays tools and apps it should be (easily?) possible to capture the
events/times and for example automatically send an E-Mail. This mail
may go to a special accounting address and maybe even automatically
processed - from this information you may create Org entries to be
appended to a special Org file.

-- 
Until the next mail...,
Stefan.

Re: [O] using vref in latex export, and normal links in html export

[Stefan Nobis]

Alan Schmitt  writes:

> I'm converting a latex document into org-mode to easily export it both
> to latex and html. I've just encountered something that I don't know how
> to do: export a \vref reference. I would like to have something that
> exports to \vref in latex, and to a normal link in html.

I solve this with the help of an export filter:

--8<---cut here---start->8---
(defun sn/ox-latex-filter-varioref (text backend info)
  (when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "ref{" "vref{" text)))

(eval-after-load "ox-latex"
  '(progn
 (add-to-list 'org-export-filter-link-functions 
'sn/ox-latex-filter-varioref)))
--8<---cut here---end--->8---

-- 
Until the next mail...,
Stefan.

[O] Bug in table formular - last column specifier broken

[Stefan Nobis]

Hi.

With the last update to Org-mode version 8.3.2
(8.3.2-48-g700b8e-elpaplus) the following table formular breaks:

--8<---cut here---start->8---

  | |  Mon |  Tue |  Wed | Thu | Fri | Sat | Sun |  Sum |
  |-+--+--+--+-+-+-+-+--|
  | |  | 1:30 | 2:00 | | | | | 03:30:00 |
  |-+--+--+--+-+-+-+-+--|
  | Sum |  |  |  | | | | | 00:00:00 |
  #+TBLFM: $>=vsum($<<..$>>);T

--8<---cut here---end--->8---

The error message is: Invalid table range specifier `9'.

When I change the "$>" to "$9" the formula works as expected.

-- 
Until the next mail...,
Stefan.

Re: [O] Merge branch 'maint'

[Stefan Nobis]

Oleh Krehel  writes:

> Would it be so hard for Git to perform a single merge of master into
> maint on release, while keeping them separate and cherry-picking
> in-between for the sake of a clean linear history?

The question is not whether git is capable of doing this (there are
ways to accomplish this goal). The true question is: Do you really
want a linear history?

A linear history may look pretty, but at the same time you loose
information. In a big complex project that is also a dependency to
another complex project, a bit more ugly bookeeping may make
maintenance easier.

-- 
Until the next mail...,
Stefan.

Re: [O] Babel and R: Call code block and output plot

[Stefan Nobis]

Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 You still have to specify the format of the results of the #+CALL
 line, as in #+CALL: myplot[:exports results]() :results file

Works like a charm, thank you very much.

-- 
Until the next mail...,
Stefan.

[O] Babel and R: Call code block and output plot

[Stefan Nobis]

Hi.

I'm playing a little bit with R code blocks in babel and calling them
in different parts of my document (e.g. showing output in the main
part and the code in the appendix).

With most code blocks (e.g. setting some variables or outputting a
LaTeX table with xtable) this works as expected (thanks to all working
on this; its really great).

Now I wanted to show a plot, but the associated code should also be
shown in the appendix. In this case CALL seems not to work (not plot
file is created or its empty).

Here is a small example of what I'm trying to achieve:

--8---cut here---start-8---
#+TITLE: Plotting Test
#+OPTIONS: author:nil date:nil email:nil toc:nil
#+CREATOR: Emacs 24.5.1 (Org mode 8.2.10)
#+STARTUP: showall
#+PROPERTY: session *R*
#+PROPERTY: exports results

* Main Part

Here I want to show some plot:

#+CALL: myplot[:exports results]()

* Appendix

Here the code of the plot should be shown:

#+NAME: myplot
#+BEGIN_SRC R :results output graphics :exports code :file my-plot.pdf
hist(rnorm(50))
#+END_SRC
--8---cut here---end---8---

Any ideas what I'm doing wrong or how to better achieve my goal?

-- 
Until the next mail...,
Stefan.

Re: [O] org-mode to latex, again!

[Stefan Nobis]

Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 As I wrote - yes, provided you update the filename database
 (e.g. launching mktexlsr from the command line). (Because of speed, TeX
 does not search the directory tree each time it looks for a package or
 something, but uses a database in a familiar, ls -R format.)

This is true, but with one exception: the user texmf tree. So
everything below ~/texmf (or ~/Library/texmf on Mac OS X) should work
without running mktexlsr (on a default TeXLive installation).

-- 
Until the next mail...,
Stefan.

Re: [O] [OT] A short (less than a minute), informal survey about LaTeX

[Stefan Nobis]

Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 1. Did you know about the savetrees package by Scott Pakin

Yes.

 2. Would you find it useful when producing PDF files other that
 scientific articles (using Org-mode or not)?

No. I use org-mode mostly for documentation and even documentation
should look nice (the whitespace in a document is there for a reason;
IIRC in the documentation of koma-script there is some rationale for
the layout).

There are many other ways to influence the layout and save
whitespace on paper. Personally, I use the koma-script classes and
playing with parameters like DIV IMHO give more appealing results. For
controlling the body there are also quite some good packages (like
enumitem), that allow more fine grained control.

With a simple #+LATEX_HEADER_EXTRA: \usepackage[extreme]{savetrees}
it's very easy to get this special effect. But maybe we should make
this easier with a special option like uglyandcompressed:t (pun
intended)?

I'm not against a more compact and cleaned up preamble and maybe a
special orgmode package for LaTeX may be a good idea. But fiddling
with the layout of a document should never be the default and only be
enabled via explicit options, as quite some classes out there do a
really good job.

BTW: If producing PDF for screenreading is important, we should think
about an easy option to switch to A5 with a sane layout. A5 is much
better for screenreading than A4 and even 2 pages A5 printed on a
single A4 looks quite good and readable. The main benefit: With A5
there is much less whitespace (see documentation of koma-script for an
example). Maybe A5 output should be the default setting?

-- 
Until the next mail...,
Stefan.

Re: [O] fontenc makes pdf non-searchable

[Stefan Nobis]

Martin Leduc mart...@hotmail.com writes:

 You can find a minimal example here[1], with the org file, and the
 tex and pdf files generated from it. Firts try to search within the
 pdf. It does not work (at least on my side) To solve the problem,
 remove the line with \usepackage[T1]{fontenc}

Your PDF is not generated with pdflatex (or a newer engine like
lualatex), but with dvips and Ghostscript. Thus the fonts are not PS
Type 1 fonts, but Type 3 fonts (bitmap instead of vector; therefore
scaling/zooming will result in bad quality).

I'm not quite sure if this is also the root cause of the inability to
search. But if i recompile your tex-file (from [1]) with pdflatex, I
get Type 1 fonts and have no problems with searching.

Therefore I would suggest to switch the engine to pdflatex.

Another hint: You should try the Latin Modern font (put a
\usepackage{lmodern} after loading fontenc) -- it's the
(technically) modern variant of Computer Modern (the old TeX default
font). Lati Modern is available as OpenType font and has less problems
with Unicode and special characters like german umlauts (ä, ü,...) or
other non-ASCII letters.

And maybe you should also have a look at biblatex[2] (as a much more
flexible alternative to natbib).

[1] https://www.dropbox.com/sh/7s6di4en5ljbkcq/AAAzyQeg6VkMHnC1X9dQTg6ua?dl=0
[2] http://ctan.org/pkg/biblatex
-- 
Until the next mail...,
Stefan.

Re: [O] fontenc makes pdf non-searchable

[Stefan Nobis]

dbo...@mmm.com (J. David Boyd) writes:

 And how did you determine that please?

I assume you mean how I determined that the PDF has been produced by
dvips and Ghostscript. In this case: I've just looked into the
document information of the PDF file. For example with Acrobat Reader
I just press CMD+D, with Apple Preview its CMD+I (look out in the
menus for document information or properties).

In this document information there is somewhere a line like PDF
creator. If the PDF is created with pdftex or pdflatex, this line
should read something like pdfTeX-1.40.15.

Each PDF viewer shows a different degree of details about the file.
For example with Apple Preview I do not see the used fonts, these are
only shown by Acrobat Reader (or command line tools like pdffonts from
xpdf).

 And how would it be switched?

The default settings of org-mode uses pdflatex. The compilation
process is configurable via the variable org-latex-pdf-process.

I don't know why and how Martin used dvips+gs. Maybe he just generated
the tex file with org and used another tool for generating PDF. Or
maybe he customized org-latex-pdf-process.

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:

 By saying bibtex is not a requirement,

I said exporting to bibtex. You talked about Zotero but showed a
bibtex entry. Therefore exporting from Zotero to bibtex may not
be a requirement, there may be a direct interface to Zotero,
eventually.

We are at the start of the development, we are currently CUTTING EDGE!
Therefore tool support (hopefully including guides to configure
citation managers) will evolve in the future.

My main point is: You found a single example that *may* be a problem
with the current syntax. But there are multiple software packages
involved (Zotero, Zotero to bibtex exporter, org-mode, etc.). The
citation syntax will never be able to handle all of the possible
problems in a longer chain of tools. Sometimes its better to fix a
problem at the start of in the middle of this chain.

IMHO it's a good idea to constrain the syntax for keys a little bit
(no whitespace, no arbitrary unicode character, no punctuation at the
end etc.). If in some cases the default configuration of the involved
tools will create invalid keys, than the configuration should be fixed
instead of dropping constraints for the key syntax.

 I hope you don't mean to imply that bibtex users are any less
 blessed or less holy or that their needs wouldn't be readily
 catered to.

I am a bibtex user. :)

I want to say, that it is impossible to accomodate for all the
citations managers with any possible configurations of them. Sometimes
we have to state: This case is not supported, please adjust your
configuration.

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

t...@tsdye.com (Thomas S. Dye) writes:

 It strikes me that basing core features of the citation syntax on
 the software users happen to be using today is a bit like this--at
 some point the design of the system will prove unprepared for new
 developments.

I don't think this is a big problem. We are talking about citation
managers, that already have to interface to different word processors.
They have to be configurable. Also, I don't think it makes any sense
for developers of citation engines to generate keys with random signs.

On the other hand, if we want to be really liberal in terms of keys,
we must allow whitespace, arbitrary unicode values etc. In this case,
its a hard problem to delimit the key because any character we use as
delimiter (like , ``, , etc.) may be used inside the key.

So some constraints for the key are always necessary. I don't know
every citation manager out there but I'm quite confident that all of
them are quite configurable and that keys containing whitespace or
ending in punctuation characters are really corner cases that could
and should be handled in the citation manager.

IMHO keys with lots of ??? in them are a sign of a data problem.
Therefore the author should solve the root cause.

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:

 On Monday 09 March 2015 02:27 PM, Stefan Nobis wrote:

 IMHO keys with lots of ??? in them are a sign of a data problem.
 Therefore the author should solve the root cause.

 Not in the specific case that I cited. The Bib entry is a pointer to
 a website.

I would say, even a website needs a date (in this case: date last
seen). :)

IMHO here you are mixing two different things: We already talked about
direct support for Zotero as a backend, CSL etc. Therefore exporting
to bibtex is not a requirement. If you use bibtex as the primary
source and Zotero only as a tool to fetch references from the web,
then its easy to edit the key in bibtex.

Maybe the best way is to add a new export module to Zotero for even
better org integration and handle correct keys in this module?

IMHO it's the job of the citation manager to generate sane keys, not
the job of org to accept arbitrary keys.

 If you had shared how I can configure Zotero to leave out the
 question marks that would have been the most helpful comment from
 your side.

I'm not a Zotero expert, I even don't use it. But with a quick look at
Google I found this:

  http://curiousjason.com/zoterotobibtex.html

(in the Firefox profile there is a configuration file
zotero/translators/BibTeX.js that needs to be edited; the above source
is from 2010 - maybe today there is a GUI to edit this setting).

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?

[Stefan Nobis]

Richard Lawrence richard.lawre...@berkeley.edu writes:

 Like I said, this seems like an edge case, and I don't see that it
 is necessarily Org's responsibility to accommodate the keys produced
 by Zotero in such edge cases. And there is a significant benefit to
 *not* accommodating such keys: namely, you can use in-text citations
 at the end of a sentence.

+1

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: a revised proposal

[Stefan Nobis]

Aaron Ecay aarone...@gmail.com writes:

 I count roughly 50 commands in sections 3.7.1 – 3.7.6 of the
 biblatex user’s manual (version 2.9a of 24/06/2014). Some of these
 are quite esoteric, of course, but they are all provided.

There are many commands (and even more private commands are possible)
in order to help reproducing all the various citation styles out there.

The critical question for org and org users is: How many different
citation commands are needed in a single document (or needed by a
single author within all her documents)?

If no single author ever needs more than about a dozen different
commands (including variations like the genetive versions), the
[cite:subcommand ...] syntax should suffice.

 By way of illustration, Biblatex (AFAICT) doesn’t provide a
 possessive citation command, which was mentioned by someone in this
 thread (or its predecessor) as a desideratum. I’d expect a savvy
 latex user to put in their preamble:

 \newcommand{\citeposs}[1]{\citeauthor{#1}’s (\citeyear{#1})}

This is what the subcommand is for. An author may define poss as a
subcommand and use [cite:poss ...]. Then all the nice gimmicks will
still work.

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: a revised proposal

[Stefan Nobis]

Richard Lawrence richard.lawre...@berkeley.edu writes:

 1) Is it worth allowing a name for a user-defined type in the [cite:
 ...] part, or is it OK to confine user-defined types to the second
 part (like: [cite: ...] %%(:type foo) or [cite: ...]{:type foo})?

IMHO it is better to have such an important part of the citation in a
prominent position, therefore I'm in favour of Nicolas suggestion of

[cite:subtype: ...]{backend options}

with the four variations for cite (i.e. [cite:...], [Cite:...],
[(cite):...], and [(Cite):...]).

The drawback is that now subtype is hard or even impossible to vary
for different backends. Therefore I would suggest that either org has
to define the allowed values of subtype or else we should define that
subtype has to be handled by the user (e.g. for use in private filter
functions) and is out of the scope of org (maybe this would be a good
place of extensions like org-ref to plug in their machinery).

 2) If a user-defined type can go in the [cite: ...] part, where should
 it go?

   [cite:subtype ...]
   [cite:subtype: ...]
   [cite/subtype: ...]
   [cite|subtype: ...]

I favor [cite:subtype: ...] a very tiny bit over the other variants.

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: a revised proposal

[Stefan Nobis]

jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes:

 From what I read in this and the previous thread, the new proposal
 tries more or less to reimplement BibTeX in org.

No, that's wrong, not the database should be replaced. The goal is to
make citations a first class citizen in the org world (so no fallback
to LaTeX commands or links with special handlings are needed).

 The biggest advantage of having something org/elisp native as in the
 proposal would be the implementation of functions to create
 bibliographies with a specific style, what Oren Patashnik called
 Bibliography-style hacking, which is very cumbersome in BibTeX
 (maybe is just that I cannot read WEB/Pascal and have a strong
 preference for Lisp dialects).

Hmmm... nowadays one uses biblatex[fn:1] (with its companion biber)
which makes hacking bibliography styles quite easy (in LaTeX; compared
to customizing bst files). I do not think that the current discussion
will lead to writing bib-styles in Lisp instead of LaTeX (at least not
in the foreseeable future).

[fn:1] http://ctan.org/pkg/biblatex

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: a revised proposal

[Stefan Nobis]

jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes:

 I see, so in the examples provided Doe99 is only the key, org would
 not have to know that the author name is Doe and its year is 1999,
 or any other information about the citation.

Yes and no. In the first place org should only get a special syntax
for citations. That means there will be special data structures for
citations and backends get a uniform interface for these parts of the
source text. In the simple case that's all, i.e. the backends get more
information to generate the correct commands (in the case of LaTeX) or
to call some tool that will generate the text/object to be inserted in
the resulting document.

On the other hand org should be able to show additional information
for citations, like linking to its data (in some bib file, in zotero
or wherever). But that's a second step.

 But now it is not clear to me what the actual org reference points
 to. If it is the actual reference, I mean the article's PDF or URL,
 what would you do when you need to cite a physical book?

The org element, say [cite: see @doe99], will point to some
data source, to be defined in the same org document (e.g. with
#+BIBIOGRAPHY:...). This data source for citations may be a bib
file, a zotero database, maybe even Endnote or something else.

As said above, org will not handle every aspect of citation. It should
only know a little more about these things in order to enable some
extra features (e.g. special UI for citations or exporting citations to
different backends instead of the need to fallback to LaTeX commands).

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: a revised proposal

[Stefan Nobis]

Richard Lawrence richard.lawre...@berkeley.edu writes:

 Rasmus ras...@gmx.us writes:

 Parts I hate:

 The flag is either `@' or `'.  `@' [...] The optional hyphen (`-') 

 Too many weird symbols that I won't be able to remember, much less explain
 to somebody else.

 I don't love these either, but I am not sure what a better
 alternative would be.

I would say, just keep @ to mark the key. The others are not really
needed. Both,  and - are better handled by a nice internal
syntax, something like

  [cite:command ...]

or

  [cite: ... @key :part year ...]

These internal extensions via keywords are IMHO much nicer that the
%%(...) variant (as a programmer I also like %%(...), but not as
an author).

I think this kind of syntax (only plain @key or maybe [@key] as
shortcut and everything else within [cite:...]) is also easier to
handle with overlays, user input helpers etc.

Some input helper can make remembering all the options and keywords
inside [cite:...] a non-issue and overlays will render it nice in the
text. Therefore the syntax should be rather simple and regular with as
few exceptions and shorthands as sensible.

-- 
Until the next mail...,
Stefan.

Re: [O] Citation syntax: a revised proposal

[Stefan Nobis]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Time for another crazy idea. Last one on my side for today

   [cite ...] [(cite) ...] [Cite ...] [(Cite) ...]

 It should solve the :capitalize issue.

+1

I really like it - even when looking at the org file with something
weird like vim, it's very clear and intuitive what's meant.

-- 
Until the next mail...,
Stefan.

Re: [O] Colon in block name?

[Stefan Nobis]

Loris Bennett loris.benn...@fu-berlin.de writes:

 The above was attached with Gnus 'C-c RET f', MIME type 'text/x-org'.

But you attached it as inline, so the same problems could arise. To be
sure to transfer the file unmodified, choose attachment as
disposition.

 Reading with Gnus, I don't see any blank lines between the table
 info and the table itself.

It depends on your Gnus configuration. If you set

   (setq gnus-inhibit-mime-unbuttonizing t)

then at least my version of Gnus (v5.13) does indeed split the buffer
in multiple pieces with additional newlines.

-- 
Until the next mail...,
Stefan.

Re: [O] Citations, continued

[Stefan Nobis]

Richard Lawrence richard.lawre...@berkeley.edu writes:

 I know these commands are convenient, and that not having them would
 introduce this class of errors, but the question is whether they are
 so important that it's worth providing an equivalent for them in
 non-LaTeX backends.

Hmmm... I don't see this as a big problem. Either the exporter or some
tool has to be able to read from the bibliography database and has to
understand at least parts of the available fields (e.g. author and
year to enable author-year style citations). Based on this it should
be easy to only output some of the fields (e.g. only author).

 For my part, it seems like the convenience is not worth the effort
 that would be required to make the exporter handle these correctly
 in general. (For example, it seems the exporter would then have to
 worry about things like quoting and emphasizing document titles --
 which means worrying about context, document type, locale and
 language, quotation styles, etc.)

Does the exporter really habe to worry about these things? But anyway:
Some tool is needed to generate the bibliography with all its data -
this tool has to handle all these details and therefore it should be
not too hard to get partial data from it. BTW: I don't think any
special formatting should be required - ASCII or even HTML would never
look the same as a LaTeX generated PDF. So minor drawbacks are IMHO
not as important as to be able to express important details in the
source.

I think, the syntax should be quite flexible (at least easy to extend,
with compact, nice looking extension-syntax). If some backend lacks
support for some feature, maybe someone finds the time to fix it (and
then org-mode would rule the world :)). Otherwise a simple fallback
(default citation style, output citation string unchanged,...) will be
used.

-- 
Until the next mail...,
Stefan.

Re: [O] Citations, continued

[Stefan Nobis]

Richard Lawrence richard.lawre...@berkeley.edu writes:

 Rasmus ras...@gmx.us writes:

 Citation types for extracting parts:
  citeauthor, citetitle, citeyear, citedate, citeurl,

 As I've said in other posts, I think maybe we should not think of
 these as `citation' commands and thus don't need to represent them
 in citation syntax. Instead I suggest we give authors tools to
 insert this information into documents directly.

This would render changes quite hard. Maybe I misspelled something in
the database or I choosed the wrong reference: With above part
extractors all I have to do at most is to replace the @key. But if
data is copied verbatim, I have to search for all years, author names,
titles, urls etc. Very error prone.

I think, even citeauthor or citeurl are citations. A normal \cite
command is nothing else than a short reference to all the detail data
in the bibliography. And sometimes context allows to make these
references even shorter, by only using the author name or a year etc.
I don't really see the distinction between citation and indirection -
each citation is as much an indirection as e.g. citeyear is.

-- 
Until the next mail...,
Stefan.