Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Ihor Radchenko writes:

> The original proposal by Eric Schulte:
> https://list.orgmode.org/4bffee4f.5010...@ccbr.umn.edu/
 Maybe we should allow either exporting just the headlines of the
 org-mode file or exporting the entire org-mode file -- possibly after an
 ASCII export -- this would have the effect of prefixing every line in
 the org-mode file behind a comment *except* for the tangled source-code
 blocks.
>
> Clearly, the "possible after an ASCII export" dropped somewhere in the
> middle.

New version of the patch attached.

`:comments org' now produces by default plain text comments previously
exported to ascii from org.

Best regards,

Juan Manuel 

>From 7095cb5d547bfe9f0576418e71317ad3ebeade77 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Thu, 21 Jul 2022 13:47:23 +0200
Subject: [PATCH] lisp/ob-tangle.el: The `org' value for `:comments' is now
 plain text

* org-babel-process-comment-text:
`org-babel-export-comment-text-as-plain-text' function is added as a
new default value, which exports the raw Org text as plain text.  This
is useful for removing all org metadata from the source file's
comments.
---
 lisp/ob-tangle.el | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index f4fb2af71..aba87ef13 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -134,11 +134,12 @@ of tangled comments."
   :group 'org-babel
   :type 'boolean)
 
-(defcustom org-babel-process-comment-text 'org-remove-indentation
-  "Function called to process raw Org text collected to be
-inserted as comments in tangled source-code files.  The function
-should take a single string argument and return a string
-result.  The default value is `org-remove-indentation'."
+(defcustom org-babel-process-comment-text 'org-babel-export-comment-text-as-plain-text
+  "Function called to process raw Org text collected to be inserted
+as comments in tangled source-code files.  The function should
+take a single string argument and return a string result.  The
+default value is `org-babel-export-comment-text-as-plain-text'.
+Legacy value is `org-remove-indentation'."
   :group 'org-babel
   :version "24.1"
   :type 'function)
@@ -158,6 +159,11 @@ represented in the file."
   (with-current-buffer (get-file-buffer file)
 (revert-buffer t t t)))
 
+(defun org-babel-export-comment-text-as-plain-text (comment)
+  "Default function to process raw Org text collected to be
+inserted as comments in tangled source-code files."
+  (org-export-string-as comment 'ascii t))
+
 (defmacro org-babel-with-temp-filebuffer (file &rest body)
   "Open FILE into a temporary buffer execute BODY there like
 `progn', then kill the FILE buffer returning the result of
@@ -533,8 +539,8 @@ non-nil, return the full association list to be used by
 	 (buffer-substring
 	  (max (condition-case nil
 		   (save-excursion
-			 (org-back-to-heading t) ; Sets match data
-			 (match-end 0))
+			 (re-search-backward org-heading-regexp) ; Sets match data
+			 (match-beginning 0))
 		 (error (point-min)))
 		   (save-excursion
 		 (if (re-search-backward
-- 
2.37.1

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

>>> On the other hand I would consider adding babel by default without
>>> explicit header. To suppress loading users may add
>>> #+latex_header: % \usepackage{babel}
>> I don't understand this very well. What would happen, then, to users
>> who
>> prefer to use Polyglossia, or those who prefer to explicitly add babel
>> or polyglossia code?
>
> Certainly if polyglossia or explicit babel related commands are
> detected then default babel configuration is not added to preamble.
> The idea is to add babel if a user have not expressed her intentions
> explicitly.

Ah, I see. I think it's a nice idea. I guess a basic babel setup would
be added to preamble. Something like:

#+language: lang

--> \usepackage[lang]{babel}

But I think also users who use custom preamble templates included in
org-latex-classes or those who load the entire preamble via an external
file (a .sty or .tex file) will want to avoid this. Maybe it would be
nice to add a defcustom, with the following values:

- load babel with the value of #+language, when there is no explicit code from 
babel (default?)

- load polyglossia, idem but for polyglossia

- nil

- any other arbitrary string?

If the user loads babel or polyglossia explicitly, with AUTO and all
that, then the current rules in
org-latex-guess-babel/polyglossia-language would be applied.

WDYT?

Best regards,

Juan Manuel

Re: numbering src blocks in HTML export

[Juan Manuel Macías]

Ihor Radchenko writes:

> AFAIU, source block switches are never inherited.
>
> Dear All, may we should provide a normal header arg as an equivalent of
> switches? Honestly, this whole switch syntax sounds unnecessary and only
> over-complicates things.

I think that web pages or documents that contain several code examples
(tutorials, documentation, etc.) tend to unify the style in this regard:
either all examples are line-numbered or all examples are unnumbered;
therefore, if the first option is chosen, it would be good to have some
global setting, when there are many blocks. But I also think this can be
easily achieved with some function locally hooked to
org-export-before-processing-hook. Or even within the document on the
fly.

A global 'factory setting' would also have the extra complication that
there would be two global numbering versions (at least): a) a separate
numbering for each block; b) each block continuing the numbering of the
previous block. And there could be a subtype of b) where it is necessary
to restart the numbering when starting a new section. Or a) and b) could
be arbitrarily mixed in the same document. All this seems complicated
to implement...

But one thing that could be nice is to give an option (perhaps with a
prefix argument) for org-babel-demarcate-block (C-c C-v C-d) to inherit
the switches:

before:

#+begin_src emacs-lisp -n
a
a
a
a
a
a
#+end_src

after C-c C-v C-d

#+begin_src emacs-lisp -n
a
a
a
#+end_src

#+begin_src emacs-lisp +n
b
b
b
#+end_src


Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

> On 19/07/2022 22:01, Juan Manuel Macías wrote:
>> + (replace-match
>> + (mapconcat (lambda (option) (if (equal "AUTO" option) language
>> option))
>> + (cond ((member language options) (delete "AUTO" options))
>> + ((member "AUTO" options) options)
>> + (t (append options (list language
>> + ", ")
>
> In my opinion this code should not attempt to be excessively clever.
> If user skipped AUTO then do not append language. Test for duplicated
> options is redundant as well. Such cases may still be a reason to
> issue a warning (e.g. by `org-lint').

I completely agree. I've kept that old part of the code for backwards
compatibility and because, at the end of the day, it doesn't break
anything new. I mean, if a user declares the main language using
babelprovide and this code (too intrusive) puts the main language in the
Babel argument too (something the user doesn't want in origin), that
syntax is supported by Babel. Babel simply takes into account the main
language declared with babelprovide, if the 'main' option has been
added. But even if it doesn't return any errors, it's unnecessary
redundancy.

Anyway, yes, it's too intrusive. I am in favor of removing that part,
but I don't know if it will have any effect on backwards compatibility.

(BTW, I think I didn't explain in this thread the advantages of using
babelprovide over the traditional ldf file system. With ini files the
user has more control over the loaded language and there are many
options, including the ability to associate a font with a script.
Furthermore the user can create his own custom ini files, and define his
own languages. For example, I could write an ini file with specific
values for Spanish, or even an imaginary language. On the one hand, it
is an important advance. But on the other hand it adds more fuel to the
current great latex pandemic: multiplicity).

> On the other hand I would consider adding babel by default without
> explicit header. To suppress loading users may add
> #+latex_header: % \usepackage{babel}

I don't understand this very well. What would happen, then, to users who
prefer to use Polyglossia, or those who prefer to explicitly add babel
or polyglossia code?

> I like that you decided to avoid inventing of a DSL just to have
> org-like options that are translated to to a couple of preamble
> commands. From my point of view it would not help novices and would
> make things more complicated for experienced LaTeX users.

Yes, in the end I realized that this was getting into a slippery slope,
especially for the reasons you mention...

>> #+latex_class: article
>> #+latex_class_options: [11pt,draft,AUTO]
>> #+LaTeX_Header: \usepackage{babel}
>> #+language: ru
>
> While AUTO is suitable for \usepackage{babel} and \babelprovide, for
> class option the placeholder should be clearly associated with babel,
> e.g. BABEL_LANG instead of AUTO.

What you say makes sense. However, this was ultimately not implemented
in the current version of the patch because the argument of
org-latex-guess-babel-language is a #+latex_header keyword.

> I am not familiar enough with setting used to generate preview of
> equations or images from LaTeX source blocks, so I am not completely
> sure that suggested changes do not affect these features in some
> negative way.

I think that shouldn't affect previsualization, because if I remember
correctly the preamble used for previews is the value of
org-format-latex-header. But I'm not sure...

Best regards,

Juan Manuel 

Re: numbering src blocks in HTML export

[Juan Manuel Macías]

Fraga, Eric writes:

> I really do not understand the last paragraph although it implies that
> org already supports adding the line numbers.  My elisp-fu is not up to
> scratch to figure this out from the code unfortunately.  Would somebody
> explain what to do?  Or should I simply add the CSS code that would do
> it for me?

I usually do it this way:

#+begin_src sh -n :exports code
aa
bb
dd
ee
ff
#+end_src

And you can also indicate the number of the first line, ie -n 20

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Here is a new version of the patch, with the fixes added.

Important: I have modified in this patch org-latex-guess-babel-language
so that it recognizes the new Babel syntax alongside the old syntax.
That is, it is now possible to put:

#+LaTeX_Header: \usepackage[arguments,AUTO]{babel}
#+LaTeX_Header: \babelprovide[arguments]{AUTO}

Languages that are served in Babel *exclusively* via ini files (ie those
with an asterisk in the new list) are not added to the Babel argument
(they must be loaded via babelprovide).

However, the following situation may also occur. A user wants to load
the secondary languages via ldf files and the main language via ini
file (babelprovide):

#+LaTeX_Header: \usepackage[french,english]{babel}
#+LaTeX_Header: \babelprovide[main, import]{AUTO}
#+language: ru

This would produce in LaTeX:

\usepackage[french, english, russian]{babel}
\babelprovide[main, import]{russian}

I have not prevented this behavior as it is correct in Babel: you can
load the main language using the 'old style' and then redefine it using
babelprovide, which is a complement. Besides, maintaining this behavior
is also necessary to preserve backwards compatibility.

Best regards,

Juan Manuel 

>From 2f78d6a75849819f1d3aececff70b7ffa4f36c7c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Tue, 19 Jul 2022 16:51:55 +0200
Subject: [PATCH] * lisp/ox-latex.el: New variable `org-latex-language-alist'

(org-latex-language-alist): Unify in a single list
`org-latex-polyglossia-language-alist' and
`org-latex-babel-language-alist', and make the two variables
obsolete. However, it may be convenient in the future to replace this
list with a more robust one. (see:
`https://list.orgmode.org/taeb0a$r62$1...@ciao.gmane.io')

(org-latex-guess-babel-language): This function has been modified so
that the new Babel command `babelprovide' is also recognized. This
command is necessary to load the languages served by Babel exclusively
through an ini file. Therefore, the new Babel syntax is supported
alongside the old one.  Note that languages that are served
exclusively via an ini file are not added to the Babel argument.
---
 lisp/org-compat.el |   8 ++
 lisp/ox-latex.el   | 236 ++---
 2 files changed, 125 insertions(+), 119 deletions(-)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 6f663cc24..835ec2828 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -880,6 +880,12 @@ context.  See the individual commands for more information."
   'org-truly-invisible-p "9.6"
   "Compatibility alias for legacy misspelling of `org-truly-invisible-p'.")
 
+(make-obsolete-variable 'org-latex-babel-language-alist
+"set `org-latex-language-alist' instead." "9.6")
+
+(make-obsolete-variable 'org-latex-polyglossia-language-alist
+"set `org-latex-language-alist' instead." "9.6")
+
  Obsolete link types
 
 (eval-after-load 'ol
@@ -888,6 +894,8 @@ context.  See the individual commands for more information."
  (org-link-set-parameters "file+sys"))) ;since Org 9.0
 
 
+
+
 
 ;;; Miscellaneous functions
 
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1aab8ffd5..2eed44b62 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -172,144 +172,111 @@
 
 ;;; Internal Variables
 
-(defconst org-latex-babel-language-alist
-  '(("af" . "afrikaans")
-("bg" . "bulgarian")
-("ca" . "catalan")
-("cs" . "czech")
-("cy" . "welsh")
-("da" . "danish")
-("de" . "germanb")
-("de-at" . "naustrian")
-("de-de" . "ngerman")
-("el" . "greek")
-("en" . "english")
-("en-au" . "australian")
-("en-ca" . "canadian")
-("en-gb" . "british")
-("en-ie" . "irish")
-("en-nz" . "newzealand")
-("en-us" . "american")
-("es" . "spanish")
-("et" . "estonian")
-("eu" . "basque")
-("fi" . "finnish")
-("fr" . "french")
-("fr-ca" . "canadien")
-("gl" . "galician")
-("hr" . "croatian")
-("hu" . "hungarian")
-("id" . "indonesian")
-("is" . "icelandic")
-("it" . "italian")
-("la" . "latin")
-("ms" . "malay")
-("nl" . "dutch")
-("nb" . "norsk")
-("nn" . "nynorsk")
-("no" . "norsk")
-("pl" . "polish")
-("pt" . "portuguese")
-("pt-br" . "brazilian")
-("ro" . "romanian")
-("ru" . "russian")
-("sa" . "sanskrit")
-("sb" . "uppersorbian")
-("sk" . "slovak")
-("sl" . "slovene")
-("sq" . "albanian")
-("sr" . "serbian")
-("sv" . "swedish")
-("ta" . "tamil")
-("tr" . "turkish")
-("uk" . "ukrainian"))
-  "Alist between language code and corresponding Babel option.")
-
-(defconst org-latex-polyglossia-language-alist
-  '(("am" "amharic")
+(defconst org-latex-language-alist
+  ;; TODO: replace this list with a property list (the actual
+  ;; implementation is not very robust).
+  '(("am" "amharic" "*")
 ("ar" "arabic")
-("ast" "asturian")
+("ast" "asturian" "*")
 ("bg" "bulg

Re: [export to CSV]

[Juan Manuel Macías]

Uwe Brauer writes:

> Regards (take care with the heat if you live in Spain (not sure though))

Yes, I live in the Sierra de Madrid, where we are always a few degrees
below Madrid, and these days this is an oven. I guess that you are also
in Spain, because of the mail from the UCM. If so, take care too :-).
Although I think that these days few places in Europe are safe...

Best regards,

Juan Manuel 

Re: org-table with different conventions: decimals

[Juan Manuel Macías]

Uwe Brauer writes:

> Now if I want to switch to the convention used in Germany (that might be
> relevant if I want to export it later to csv, but this is a different
> topic) does work in a strange way, any comments? [...]

Hi, Uwe,

If you only need to export to LaTeX you can load the siunitx package,
which not only fits the decimals perfectly in a table but you can also
define a value for the decimal sign that will be seen in the PDF.

It has a small drawback. Columns with numeric value (S) cannot contain
anything other than numbers. If you want to add an arbitrary text string
in one of those columns you must enclose that string in {}. That is, on
the org side it would be @@latex:{foo}@@

You can try this with your example:

#+LaTeX_Header: \usepackage{siunitx}
#+LaTeX_Header: \sisetup{detect-all}
#+LaTeX_Header: \sisetup{output-decimal-marker = {,}}

#+ATTR_LaTeX: :align SSS
| 3.5 | 4.2 | 7.7 |
#+TBLFM: $3=$1+$2

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

> On 18/07/2022 17:32, Juan Manuel Macías wrote:
>> For example, something like this:
>> latex-lang: babel(sorbian) variant(upper)
>> provide(hebrew:import,hyphenrules=+) options(bidi=default),
>> others(french,catalan)
>> returns:
>> \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
>> \babelprovide[import,hyphenrules=+]{hebrew}
>
> I have never tried so complex babel configuration. Should "latex-lang"
> options affect ox-latex in any way besides adding
> \usepackage[...]{babel} and \babelprovide[...]{...}? If not, maybe it
> is better to use

I really think not. It's more of a way to have a more or less complete
configuration of babel (including font options) in a single line and
with a more org-centric syntax. The drawback is that the user would have
to know in this case what he is putting, and know the babel options.

> #+latex_header: \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
> #+latex_header: \babelprovide[import,hyphenrules=+]{hebrew}

That's what I would do as a user. I write all my preambles in pure LaTeX
and don't let Org write anything before the \begin{document} :-)

> directly and add default \usepackage[french]{babel} based on
> "#+language:" only in the case when babel is not loaded through
> "#+latex_header:". Currently such strategy is implemented for inputenc
> or some other package.

humm, what do you think about this idea?:

If I'm not mistaken, the current behavior is as follows. If in the org
document there is this:

#+latex_header: \usepackage[english,french,AUTO]{babel}
#+language: es

it returns:

\usepackage[english,french,spanish]{babel}

But it could be extended to the new babel syntax, so that:

#+latex_header: \usepackage[french,catalan,AUTO,bidi=default]{babel}
#+latex_header: \babelprovide[import,hyphenrules=+]{hebrew}
#+language: es

returns:

\usepackage[french,catalan,spanish,bidi=default]{babel}
\babelprovide[import,hyphenrules=+]{hebrew}

Or, if we want to load the main language via babelprovide (using an ini
file instead of an ldf file):

#+latex_header: \usepackage[french,catalan,spanish]{babel}
#+latex_header: \babelprovide[main,import]{AUTO}
#+language: ru

returns:

\usepackage[french,catalan,spanish]{babel}
\babelprovide[main,import]{russian}

(in this case french, catalan and spanish are the secondary languages)

And this could be extended (in LuaTeX and XeTeX only) to the class
options (which is a new babel feature):

#+latex_class: article
#+latex_class_options: [11pt,draft,AUTO]
#+LaTeX_Header: \usepackage{babel}
#+language: ru

returns:

\documentclass[11pt,draft,russian]{article}
\usepackage{babel}

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Juan Manuel Macías writes:

> latex-lang: babel(sorbian) variant(upper) 
> provide(hebrew:import,hyphenrules=+) options(bidi=default), 
> others(french,catalan) 
>
> returns:
>
> \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
> \babelprovide[import,hyphenrules=+]{hebrew}

PS: In fact, I think that this new implementation would no longer depend
on a list of languages neither for babel nor for polyglossia, since it
is not connected to the #+language keyword. The old list would be kept
for backwards compatibility.

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Ihor Radchenko writes:

> Do you refer to the paragraph below when saying that Org implementation
> makes it hard to add new features? The rest of the above paragraph
> implies that the difficulty is on LaTeX side, not on Org side.

Sorry for not explaining clearly. Actually I think the problem is not
with Org or Babel (LaTeX), but rather with the "translation" from Babel
(latex) to Org. Currently the babel interface is more complex, although
it is more consistent and robust within LaTeX. The challenge is how to
style all of that for an Org user who wants to just get a correct PDF
out-of-the-box using a simple and basic syntax (of course, you don't
need to translate the whole babel: to use babel with all its power it's
better to write the LaTeX code directly). 

For that reason I think that, for now, it is more practical to keep the
old babel syntax on the Org side (as I do in my patch):

\usepackage[langs]{babel}

which is perfectly valid for pdflatex, lualatex and xelatex (except in
the languages that are loaded in babel through ini files).

> In any case, your existing patch is an already an improvement. I do not
> deem it as requirement to apply the patch.

Well, between today and tomorrow I can prepare a new version of the
patch with all your suggestions from the previous email incorporated.
And for the future I can work on a fresh re-implementation of all this,
using the :options-alist export property, as you suggest.

For example, something like this:

latex-lang: babel(sorbian) variant(upper) provide(hebrew:import,hyphenrules=+) 
options(bidi=default), others(french,catalan) 

returns:

\usepackage[french,catalan,uppersorbian,bidi=default]{babel}
\babelprovide[import,hyphenrules=+]{hebrew}

or this (in this case Hebrew is the main language):

latex-lang: babel provide(hebrew:main,import,hyphenrules=+) 
options(bidi=default), others(french,catalan) 

returns:

\usepackage[french,catalan,bidi=default]{babel}
\babelprovide[main,import,hyphenrules=+]{hebrew}

And the above is equivalent to:

latex-lang: babel(hebrew) options(bidi=default,provide=*), 
others(french,catalan) 

returns:

\usepackage[french,catalan,hebrew,bidi=default,provide=*]{babel}

Note that for monolingual documents, now in babel it would be enough to
indicate the language in the document class options (only for LuaTeX and
XeTeX), so it would be enough to do something like this:

#+latex_class: article
#+latex_class_options: [french,10pt,draft]
#+LaTeX_Header: \usepackage{babel}


Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Ihor Radchenko writes:

> For Max's comment, using plist/alist would make things more clear
> code-wise for future developers. I always find it annoying when I need
> to go back and forth checking which element should be second or third or
> forth in the list. Especially if the variable is used all around the
> codebase. Though this particular case is not such -
> `org-latex-language-alist' is used just in few places.

I agree with Maxim and with you that an anonymous list is hardly usable
for future features. For this new list I followed the style of the
previous ones and I admit that I was quite conservative. The problem,
imho, is that with the current org implementation I find it difficult to
add new features. For example, Babel now has two ways of loading
languages: the old one, through ldf files, which is the one that Org
implements and that produces the traditional babel syntax; and the new
system through ini files, which also incorporates a new syntax with many
options and variants. New languages have been defined by ini files, but
cannot be loaded by the old syntax. That is the cause of the asterisks
in my list: when a language has an asterisk it means that it is only
served in babel through an ini file and, therefore, the traditional
syntax cannot be used, so it is not implemented for use in babel. And
furthermore, the new babel syntax and ini files can only be used with
the Unicode TeX engines: XeTeX and LuaTeX. This all looks like a puzzle
(I'm getting dizzy just rereading it :-)), and I don't see a clean and
sensible way to translate it to Org settings.

I also think that the current Org settings for loading languages with
Polyglossia or Babel is unhelpful and unclear. Also, it depends on
putting explicit LaTeX code in the document. A code that, in the case of
Polyglossia, is a fake LaTeX code, because something like this:

\usepackage[french,AUTO]{polyglossia}

is not really the Polyglossia syntax. And it can lead to confusion.

I think this should be reimplemented in the future using a more
org-centric syntax, using keywords (somehow keeping the
above for backwards compatibility). I don't know, maybe something like
this, with a specific keyword for language LaTeX settings:

#+latex_language: es variant:mx babel-ini:t other:en,de,el etc.

In this case, I think it would make more sense to define a more robust
list, an alist or a plist (as Maxim suggested), leaving the door open to
a fresh reimplementation of langs in latex export. I can get to work as
soon as I have some time and finish with other commitments, that will
keep me busy practically all summer.

WDYT?

Best regards,

Juan Manuel 

Org for developing LaTeX packages

[Juan Manuel Macías]

Hi all,

I am writing a package for LuaLaTeX and have decided to use Org for it.
The reasons: org is more powerful, more versatile and more cool than the
'official' LaTeX literate programming utility, docstrip.

Searching for information on this list I found this post from Marcin
Borkowski, from 2013, where he comments on very interesting things
regarding these topic:

https://list.orgmode.org/20130311230246.4c629e36@aga-netbook/

Out of curiosity, I wonder if Marcin or someone else finally got around
to implementing something concrete for this. I think some kind of
extension to org-babel-tangle that would generate the typical docstrip
.dtx and .ins files might be nice. Perhaps this would open up the use of
Org to LaTeX package developers, though admittedly docstrip is deeply
rooted in planet LaTeX and hardly anything else is used.

When I release my package I'll write a makefile, in the style of the
wallcalendar package, which is also written in Org:

https://github.com/profound-labs/wallcalendar/blob/master/Makefile

BTW, Wallcalendar is the only LaTeX package I know of (besides mine,
still work in progress) that is written in Org and not in docstrip. I
don't know if there are any more...

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

> I would consider structures with named fields (alists or plists) for a
> case of adding some additional settings (Font name? But it is rather
> defcustom than defconst)
>
> ("es" . (:babel "spanishmx" :poliglossia "spanish"
> :poliglossia-variant "mexican")

I was paying more attention to the fontenc issue and I had forgotten to
comment this.

I think your proposal to use a property list makes sense. But I don't
quite see what new settings could be added without overcomplicating
things. Babel in its latest versions has several ways to load languages,
and many new commands to select fonts or associate font families to a
specific language or script. But they don't work with pdfLaTeX, so the
only thing I could think of is to keep the old babel method, valid for
all TeX engines, according to which, if a user puts in an org document:

#+language: es
#+latex_header: \usepackage[foo,AUTO]{babel}

it returns:

\usepackage[foo,spanish]{babel}

which is valid for all flavors of TeX. And I think that this way, as Org
was doing so far, it will satisfy most users.

But given the syntactical variety that babel now has (polyglossia is
simpler), I don't see how all of that could be 'translated' to Org via
Org settings. I think this is one of those cases where it's easier for
the user to just build the LaTeX preamble writing LaTeX code or create a
new 'class' for org-latex-classes. The problem with Org writing the
preamble for the user is that it will never satisfy all users. That is
why I think it is necessary for this 'automatic' preamble to be as basic
and elementary as possible (I, for example, always write the preamble
from scratch or write my own sty files). Otherwise we run the risk of
converting, or wanting to convert, Org into a clone of LaTeX, but less
flexible than LaTeX.

I agree that most Org users (like most Pandoc users) just want to
produce a clean pdf without messing with LaTeX. But if users want to do
more things in LaTeX, they should know some LaTeX, even if they prefer
to use a lightweight markup language as a latex 'interface'. That's why
I think it's great that in Org you can enter arbitrary LaTeX (or html)
code anywhere and at many levels. I think this is the real killer
feature of Org. I don't know if I'm explaining myself... But this
reflection of mine (which, of course, is debatable) would take us
further, and this is not the case here. 

Other than that, your idea of using a property list sounds good to me.
What happens is that I do not see a clear advantage (at least in the
short term).

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

> I have tried on Ubuntu-20.04 LTS focal (Latest LTS is 22.04 jammy).
> Without explicit fontenc it may work, but emits a warning
>
> Package babel Warning: No Cyrillic font encoding has been loaded so far.
> (babel)A font encoding should be declared before babel.
> (babel)Default `T2A' encoding will be loaded  on input
> line 74.

Yeah, that's something I forgot to mention. The warning is from
russianb.ldf:

-
\ifx\cyrillicencoding\undefined
  \if@uni@ode
%\ifdefined\XeTeXrevision
%  \edef\cyrillicencoding{EU1}
%\else\ifdefined\luatexversion
%  \edef\cyrillicencoding{EU2}
%\fi\fi
\edef\cyrillicencoding{TU}
  \else
\edef\cyrillicencoding{T2A}
  \fi
  \PackageWarning{babel}%
{No Cyrillic font encoding has been loaded so far.\MessageBreak
 A font encoding should be declared before babel.\MessageBreak
 Default `\cyrillicencoding' encoding will be loaded
}%
  \lowercase\expandafter{\expandafter\input\cyrillicencoding enc.def\relax}%
  \AtBeginDocument{\@setcyrillicencoding}
\fi
-

But there is no warning in the case of Greek, where the LGR fontencoding
is not explicitly indicated either. In any case, I have commented on
this issue on the Hispanic TeX mailing list, where Javier Bezos (current
Babel maintainer) participates. It would be interesting if he could
clarify this for us...

> Unfortunately in the case of
>
> \usepackage[russian,english]{babel}
>
> \selectlanguage{russian} is required, without it compilation fails with
>
>! LaTeX Error: Command \cyrn unavailable in encoding OT1.

Yes, this is the case of the example that I put in my previous message
(russian as second language). If a explicit babel command is not added,
the T2A fontencoding is not loaded. Therefore, you would have to add a
selectlanguage{russian} or, at a low level,
\fontencoding{T2A}\selectfont

> With \usepackage[T2A]{fontenc} it behaves accordingly to acceptable
> for non-important documents graceful degradation. Text is readable,
> but no hyphenation applied.
>
> So I consider explicit loading of fontenc as more reliable.

Wouldn't it be easier in those cases to just load the fontenc package a
second time:

#+LaTeX_Header: \usepackage[T1,T2A]{fontenc}

According to what Egreg says in this thread
(https://tex.stackexchange.com/a/79112), "The only package that's
allowed to be loaded multiple times is fontenc".

So my logic is as follows: since Org has always loaded fontenc with the T1
option by default, I don't see much point in changing that behavior now
that pdfLaTeX is, so to speak, in retirement. And in any case, the user
can change (now) the fontencoding via the babel commands or by loading
the package a second time. For the record, I'm not opposed to redoing
the patch by adding the features you're proposing. Simply, from my point
of view, I think it's not worth the effort. But it's just my opinion,
and besides, I don't use pdfLaTeX, so I may have a bias here.

Best regards,

Juan Manuel 

Re: [tip/offtopic] A function to describe the characters of a word at point

[Juan Manuel Macías]

Hi, Marcin and Samuel, thanks for your comments,

Marcin Borkowski writes:

> You might want to extend it and create a minor mode which would display
> data about the current character in the echo area, Eldoc-style, or in
> a tooltip when you hover the mouse pointer over a character.  Depending
> on what exactly you need, these ideas might be more or less useful, of
> course.

I also have written a smaller function to display a quick information of
a single character at point, something much simpler and not as verbose
as describe-char. But it had never occurred to me to do something
eldoc-like with it. In my case, although for those contexts I prefer
quick information (describe-char also has its relaxing moment), I don't
feel such an urgency :-).

In any case, something quick and dirty, just as a proof of concept,
could be this:

(define-minor-mode char-info-at-point-mode
  "TODO"
  :init-value nil
  :lighter ("chinfo")
  (if char-info-at-point-mode
  (add-hook 'post-command-hook #'char-name-at-point nil t)
(remove-hook 'post-command-hook #'char-name-at-point 'local)))

(defun char-name-at-point ()
  (interactive)
  (let* ((char-name (get-char-code-property (char-after (point)) 'name))
 (code (format "#%x" (char-after (point
 (dec (get-char-code-property (char-after (point)) 'decomposition))
 (info (concat
char-name
" / "
code
" / descomp: "
dec
"\s"
(mapconcat (lambda (cod)
 (format "#%x" cod))
   dec "\s+\s"
(message info)))

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Juan Manuel Macías writes:

> In any case, I personally think that org-latex-language-alist, as it is
> now in this patch, is sufficient.

By the way, Maxim. I have been doing some tests with pdfLaTeX. I've
known for a while now that it's no longer necessary to load the inputenc
package. But it seems that it is not even necessary to load fontenc with
the encoding of each language. Try compiling this:

#+begin_src latex
  \documentclass{article}
  \usepackage[russian,polutonikogreek]{babel}

  \begin{document}

  \today

  Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν Ἀρταξέρξης, 
νεώτερος δὲ
  Κῦρος· ἐπεὶ δὲ ἠσθένει Δαρεῖος καὶ ὑπώπτευε τελευτὴν τοῦ βίου, ἐβούλετο τὼ 
παῖδε ἀμφοτέρω
  παρεῖναι.

  \selectlanguage{russian}

  \today

  Emacs написан на двух языках: C и Emacs Lisp (Elisp, диалект Лиспа). При этом 
сам редактор
  является интерпретатором Elisp. По сути дела, большая часть Emacs написана на 
языке Elisp,
  и её можно рассматривать как расширение к основной программе.

  \end{document}
#+end_src

In TeX live 2022 the compilation is correct (I think). It seems that
Babel (or russian/greek.ldf) loads the font encodings according to the
declared languages. From the log:

#+begin_src sh
(/usr/share/texmf-dist/tex/latex/cyrillic/t2aenc.def
(/usr/share/texmf-dist/tex/latex/base/t2aenc.dfu)))
(/usr/share/texmf-dist/tex/generic/babel-greek/greek.ldf
(/usr/share/texmf-dist/tex/latex/greek-fontenc/lgrenc.def
(/usr/share/texmf-dist/tex/latex/greek-inputenc/lgrenc.dfu)
(/usr/share/texmf-dist/tex/latex/greek-fontenc/greek-fontenc.def
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def) (./fontenc.aux
 (/usr/share/texmf-dist/tex/generic/babel/locale/es/babel-spanish.tex)
(/usr/share/texmf-dist/tex/latex/cbfonts-fd/lgrcmr.fd))
(/usr/share/texmf-dist/tex/latex/cyrillic/t2acmr.fd) [1{/var/lib/texmf/fonts/ma
p/pdftex/updmap/pdftex.map}] (./fontenc.aux) ){/usr/share/texmf-dist/fonts/enc/
dvips/cm-super/cm-super-t2a.enc}

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

>> Subject: [PATCH] * lisp/ox-latex.el: New variable `org-latex-language-alist'
> Writing the previous message I forgot that currently there is no
> default option for the fontenc package (PdfLaTeX), e.g. T2A for
> Cyrillic. As a result it is not enough to specify just language to
> generate PDF file.  From my point of view it is better to have single
> map from language code to various localization options (babel,
> polyglossia, fontenc). Unfortunately plain list
> `org-latex-language-alist' does not allow further extensions. Property
> list would make initialization not so concise, but it would make the
> map more flexible.

Sorry, I hadn't seen your other message and I ignored it...

What you say makes sense. If I'm not mistaken, there is now nothing like
an hypothetical 'org-latex-guess-fontenc', and org defaults to the T1
option. If I remember correctly (because I haven't used pdfLaTeX in
ages), the fontenc option for Greek is LGR. And I imagine there will be
many more cases. If you or anyone wants to implement that on top of my
patch, that's fine with me. I don't have much time to do it right now.
However, my opinion is the following: I think we should focus our
efforts on finding a satisfactory solution for luatex, according to
everything that has been commented in the different sub-threads on the
subject of fonts and fallback fonts. And leave the related to pdfLaTeX
in second place, if in the end LuaTeX is going to be set as the default
engine.

In any case, I personally think that org-latex-language-alist, as it is
now in this patch, is sufficient.

Best regards,

Juan Manuel 

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Ihor Radchenko writes:

> Thanks!
> This looks like an improvement.
> However, we may need to preserve the old defconsts for the time being
> and declare them obsolete.

Hi, Ihor,

I attach the new version of the patch with both variables declared
obsolete.

If everything is ok, I can add what is necessary to NEWS and to the Org Manual.

Best regards,

Juan Manuel

>From 9ff77e71a8cd89b883d5ead37909c887178e4402 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Thu, 14 Jul 2022 13:42:50 +0200
Subject: [PATCH] * lisp/ox-latex.el: New variable `org-latex-language-alist'

(org-latex-language-alist): Unify in a single list
`org-latex-polyglossia-language-alist' and
`org-latex-babel-language-alist', and make the two variables obsolete.
---
 lisp/ox-latex.el | 173 ---
 1 file changed, 74 insertions(+), 99 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1aab8ffd5..9e97f38db 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -172,144 +172,115 @@
 
 ;;; Internal Variables
 
-(defconst org-latex-babel-language-alist
-  '(("af" . "afrikaans")
-("bg" . "bulgarian")
-("ca" . "catalan")
-("cs" . "czech")
-("cy" . "welsh")
-("da" . "danish")
-("de" . "germanb")
-("de-at" . "naustrian")
-("de-de" . "ngerman")
-("el" . "greek")
-("en" . "english")
-("en-au" . "australian")
-("en-ca" . "canadian")
-("en-gb" . "british")
-("en-ie" . "irish")
-("en-nz" . "newzealand")
-("en-us" . "american")
-("es" . "spanish")
-("et" . "estonian")
-("eu" . "basque")
-("fi" . "finnish")
-("fr" . "french")
-("fr-ca" . "canadien")
-("gl" . "galician")
-("hr" . "croatian")
-("hu" . "hungarian")
-("id" . "indonesian")
-("is" . "icelandic")
-("it" . "italian")
-("la" . "latin")
-("ms" . "malay")
-("nl" . "dutch")
-("nb" . "norsk")
-("nn" . "nynorsk")
-("no" . "norsk")
-("pl" . "polish")
-("pt" . "portuguese")
-("pt-br" . "brazilian")
-("ro" . "romanian")
-("ru" . "russian")
-("sa" . "sanskrit")
-("sb" . "uppersorbian")
-("sk" . "slovak")
-("sl" . "slovene")
-("sq" . "albanian")
-("sr" . "serbian")
-("sv" . "swedish")
-("ta" . "tamil")
-("tr" . "turkish")
-("uk" . "ukrainian"))
-  "Alist between language code and corresponding Babel option.")
-
-(defconst org-latex-polyglossia-language-alist
-  '(("am" "amharic")
+(make-obsolete-variable 'org-latex-babel-language-alist
+"set `org-latex-language-alist' instead." "9.6")
+
+(make-obsolete-variable 'org-latex-polyglossia-language-alist
+"set `org-latex-language-alist' instead." "9.6")
+
+(defconst org-latex-language-alist
+  '(("am" "amharic" "*")
 ("ar" "arabic")
-("ast" "asturian")
+("ast" "asturian" "*")
 ("bg" "bulgarian")
-("bn" "bengali")
-("bo" "tibetan")
+("bn" "bengali" "*")
+("bo" "tibetan" "*")
 ("br" "breton")
 ("ca" "catalan")
-("cop" "coptic")
+("cop" "coptic" "*")
 ("cs" "czech")
 ("cy" "welsh")
 ("da" "danish")
-("de" "german" "german")
-("de-at" "german" "austrian")
-("de-de" "german" "german")
-("dsb" "lsorbian")
-("dv" "divehi")
+("de" "ngerman" "german" "german")
+("de-at" "naustrian" "german" "austrian")
+("dsb" "lsorbian" "*")
+("dv" "divehi" "*")
 ("el" "greek")
-("en" "english" "usmax")
-("en-au" "english" "australian")
-("en-gb" "english" "uk")
-("en-nz" "english" "newzealand")
-("en-us" "english" "usmax")
+("el-polyton" "polutonikogreek" "greek" "polytonic")
+("en" "american" "english" "usmax")
+("en-au" "australian" "english" "australian")
+("en-gb" "british" "english" "uk")
+("en-nz" "newzealand" "english" "newzealand")
+("en-us" "american" "english" "usmax")
 ("eo" "esperanto")
 ("es" "spanish")
+("es-mx" "spanishmx" "spanish" "mexican")
 ("et" "estonian")
 ("eu" "basque")
 ("fa" "farsi")
 ("fi" "finnish")
 ("fr" "french")
-("fu" "friulan")
+("fr-ca" "canadien" "french" "canadian")
+("fur" "friulan")
 ("ga" "irish")
 ("gd" "scottish")
 ("gl" "galician")
 ("he" "hebrew")
 ("hi" "hindi")
 ("hr" "croatian")
-("hsb" "usorbian")
+("hsb" "uppersorbian" "sorbian" "upper")
 ("hu" "magyar")
-("hy" "armenian")
+("hy" "armenian" "*")
 ("ia" "interlingua")
-("id" "bahasai")
+("id" "bahasai" "*")
 ("is" "icelandic")
 ("it" "italian")
-("kn" "kannada")
-("la" "latin" "modern")
-("la-classic" "latin" "classic")
-("la-medieval" "latin" "medieval")
-("la-modern" "latin" "modern")
-("lo" "lao")
+("kn" "kannada" "*")
+("la" "latin")
+("la-classic" "classiclatin" "latin" "classic")
+("la-medieval" "medievallatin" "latin" "medieval")
+("la-ecclesiastic" "ecclesiasticlatin" "latin" "ecclesi

[tip/offtopic] A function to describe the characters of a word at point

[Juan Manuel Macías]

Sorry for the slight offtopic.

Since Unicode and character issues come up here from time to time, I'm
sharing this 'homemade' function that I wrote a long time ago for my
work, in case someone finds it useful. It Shows a brief descriptive list
of all characters in a word at point. Each character includes the
Unicode name, code, and canonical decomposition. Example:

ἄρχοντα >>

ἄ (#1f04) ... GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA ... descomp: #1f00 
#301
ρ (#3c1) ... GREEK SMALL LETTER RHO ... descomp: #3c1
χ (#3c7) ... GREEK SMALL LETTER CHI ... descomp: #3c7
ο (#3bf) ... GREEK SMALL LETTER OMICRON ... descomp: #3bf
ν (#3bd) ... GREEK SMALL LETTER NU ... descomp: #3bd
τ (#3c4) ... GREEK SMALL LETTER TAU ... descomp: #3c4
α (#3b1) ... GREEK SMALL LETTER ALPHA ... descomp: #3b1


#+begin_src emacs-lisp
  (defun describe-chars-word-at-point ()
(interactive)
(setq chars-in-word nil)
(if
(not (current-word t t))
(error "Not in a word at point...")
  (let
  ((word (current-word t t)))
(save-excursion
  (with-temp-buffer
(insert word)
(goto-char (point-min))
(while (re-search-forward "\\(.\\)" nil t)
  (let* ((char-name (save-excursion
  (backward-char)
  (get-char-code-property (char-after (point)) 
'name)))
 (char-desc (save-excursion
  (backward-char)
  (get-char-code-property (char-after (point)) 
'decomposition)))
 (char-format (concat (match-string 1) "\s" "("
  (format "#%x" (string-to-char 
(match-string 1)))
  ")\s...\s" char-name 
"\s...\sdecomp:\s"
  (mapconcat (lambda (cod)
   (format "#%x" cod))
 char-desc " "
(push char-format chars-in-word)))
(when (get-buffer "*chars in word*")
  (kill-buffer "*chars in word*"))
(get-buffer-create "*chars in word*")
(set-buffer "*chars in word*")
(insert (mapconcat 'identity
   (reverse chars-in-word) "\n"))
(view-mode)
(temp-buffer-window-show "*chars in word*"
 '((display-buffer-below-selected 
display-buffer-at-bottom)
   (inhibit-same-window . t)
   (window-height . fit-window-to-buffer
  (pop-to-buffer "*chars in word*")
#+end_src

Re: [External] : Re: missing a character / font in agenda?

[Juan Manuel Macías]

Stefan Kangas writes:

> If that is true (I don't know) then maybe we should just use a more
> ubiquitous glyph?

I have done a quick test with some fonts that are ---I believe--- quite
popular. This character is missing from DejaVu Sans Mono, Iosevka,
Source Pro, Fira Code and Hack. JuliaMono does include it:

https://i.imgur.com/O3urnxa.png

I think LEFTWARDS ARROW / #2190 of the 'arrows' Unicode block is much
more common:

https://i.imgur.com/h0NQXvG.png

Best regards,

Juan Manuel 

Re: [External] : Re: missing a character / font in agenda?

[Juan Manuel Macías]

Juan Manuel Macías writes:

> The most reasonable thing would be to use a more
> common symbol. But I'm still intrigued by the origin of that symbol...

It seems that the culprit is in line 1592 of org-agenda.el

I think this should be considered a bug, since the glyph used (LEFTWARDS
TRIANGLE-HEADED ARROW / #2b60) is not present in most fonts.

Best regards,

Juan Manuel

Re: [External] : Re: missing a character / font in agenda?

[Juan Manuel Macías]

Hi, Daniel,

Daniel Ortmann writes:

> – Would using the ASCII '<' character be a better solution?

I've done a quick test and a few very popular (and more or less
complete) fonts don't include a glyph for the LEFTWARDS TRIANGLE-HEADED
ARROW #2b60 character: DejavuSans, Iosevka, Hack Source Code Pro,
JuliaMono or Fira Code. It is a very rare symbol.

> – Is anyone else seeing this issue and missing font?

I haven't seen it, but I'm not using the Git version.

> – Is that Symbola font, or equivalent, now a true dependency?  Or is
>   there something more common which I should be using?  (Perhaps I
>   have missed a normal configuration step?)

I think Symbola should not be a dependency. I use this font just to be
able to display unusual symbols, especially on web pages when I browse
the web with eww-mode. The most reasonable thing would be to use a more
common symbol. But I'm still intrigued by the origin of that symbol...

Best regards,

Juan Manuel

Re: missing a character / font in agenda?

[Juan Manuel Macías]

Hi,

Daniel Ortmann writes:

> Any clues where this particular symbol resides?  A hint about the
> package name would wonderful.  :-)

To be able to display "unusual" symbols in Emacs, I usually use the
symbola font:

You can download it here:

https://fontlibrary.org/en/font/symbola

And then:

(set-fontset-font t 'symbol (font-spec :family "Symbola"))

But I think that what is interesting here is to know how that character
has arrived. Could it be related to some new package you have installed
lately?

Best regards,

Juan Manuel

Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets")

[Juan Manuel Macías]

Today I discovered that luaotfload included in v. 3.12 a new
experimental function, luaotfload.add_fallback, to be able to add a list
of fallback fonts to a LuaTeX document, at a low level.

(More info on page 18 of the luaotfload manual, with some examples).

I've been experimenting a bit with this function. For example:

#+begin_src latex
  \documentclass{article}
  \usepackage{fontspec}
  \directlua{
  luaotfload.add_fallback ("fallbacktest",
  {
  "oldstandard:mode=harf;script=grek;color=FF;",
  "oldstandard:mode=harf;script=cyrl;color=FF;",
  "freeserif:mode=harf;script=arab;color=FF;",
  "freeserif:mode=harf;script=dev2;color=FF;",
  }
  )
  }

  \setmainfont{latinmodernroman}[RawFeature={fallback=fallbacktest}]

  \begin{document}

  Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
  hendrerit tempor tellus. Donec pretium posuere tellus.

  Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
  Ἀρταξέρξης, νεώτερος δὲ Κῦρος· ἐπεὶ δὲ ἠσθένει Δαρεῖος καὶ ὑπώπτευε
  τελευτὴν τοῦ βίου, ἐβούλετο τὼ παῖδε ἀμφοτέρω παρεῖναι. ὁ μὲν οὖν
  πρεσβύτερος παρὼν ἐτύγχανε· Κῦρον δὲ μεταπέμπεται ἀπὸ τῆς ἀρχῆς ἧς
  αὐτὸν σατράπην ἐποίησε, καὶ στρατηγὸν δὲ αὐτὸν ἀπέδειξε πάντων ὅσοι ἐς
  Καστωλοῦ πεδίον ἁθροίζονται.

  Emacs написан на двух языках: C и Emacs Lisp (Elisp, диалект Лиспа).
  При этом сам редактор является интерпретатором Elisp. По сути дела,
  большая часть Emacs написана на языке Elisp, и её можно рассматривать
  как расширение к основной программе. Пользователи могут сами создавать
  части Emacs, от отдельных функций до новых основных режимов. При этом
  можно переопределять любые Elisp-функции, в том числе и те, что
  являются частью самого редактора, и модифицировать функциональность
  Emacs, изменив соответствующим образом некоторые функции.

  Native speakers of Arabic generally do not distinguish between Modern
  Standard Arabic and Classical Arabic as separate languages; they refer
  to both as al-ʻArabīyah al-Fuṣḥá (العربية الفصحى) meaning the pure
  Arabic. They consider the two forms to be two registers of one
  language. When the distinction is made, they are referred to as فصحى
  العصر Fuṣḥá al-ʻAṣr (MSA) and فصحى التراث Fuṣḥá al-Turāth (CA)
  respectively.

  उदु ज्योतिरमृतं विश्वजन्यं विश्वानरः सविता देवो अश्रेत् ।\\
  क्रत्वा देवानामजनिष्ट चक्षुराविरकर्भुवनं विश्वमुषाः ॥ १ ॥\\
  प्र मे पन्था देवयाना अदृश्रन्नमर्धन्तो वसुभिरिष्कृतासः ।\\
  अभूदु केतुरुषसः पुरस्तात्प्रतीच्यागादधि हर्म्येभ्यः ॥ २ ॥

  \end{document}
#+end_src

The main drawback I've found to this (at least I don't know how to solve
it at the moment) is that the fallback feature cannot be added via
\defaultfontfeatures. That would avoid having to (re)define all the
main/sans/mono/math families.

Best regards,

Juan Manuel 

Re: fontsets

[Juan Manuel Macías]

Stefan Nobis writes:

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

I think it's a good idea. And I definitely like Timothy's idea of
fontsets, but I still think that LuaLaTeX and XelaTeX should be unified
in some way.

Perhaps one or two default fontsets could be added.

It was commented in some previous message about the possibility of
checking if a font is present in the system. To add some extra
information, TeX live 2022 includes a lua script, luafindfont, which
runs luaotfload in the background. It is very useful because, in
addition to system fonts, it also returns results from TeX live fonts. I
use this script via helm, and I wrote this to extract a list of
candidates:

#+begin_src emacs-lisp
(defun build-luafindfont-candidates-list (candidate)
  (interactive)
  (let* ((query (shell-command-to-string (concat "luafindfont " candidate)))
 (str (with-temp-buffer
(insert query)
(goto-char (point-min))
(let ((from
   (save-excursion
 (re-search-forward "1\\." nil t)
 (beginning-of-line)
 (point)))
  (to
   (save-excursion
 (goto-char (point-max))
 (point
  (save-restriction
(narrow-to-region from to)
(buffer-string)
 (str-clean (split-string
  (with-temp-buffer
(insert str)
(replace "[[:digit:]]+\\.\s+" "")
(replace "\\(.+\\)\\(\\.otf\\|\\.ttf\\)\s+" "")
(replace "\s+" " -- ")
(buffer-string)) "\n" t)))
(setq luafindfont-list (mapcar 'identity
   str-clean
#+end_src

On the other hand, fontspec includes the \IfFontExistsTF command.
According to the fontspec documentation:

--
\IfFontExistsTF{⟨font name⟩}{⟨true branch⟩}{⟨false branch⟩}

The conditional \IfFontExistsTF is provided to test whether the ⟨font name⟩ 
exists or
is loadable. If it is, the ⟨true branch⟩ code is executed; otherwise, the 
⟨false branch⟩ code is.
This command can be slow since the engine may resort to scanning the filesystem 
for a
missing font. Nonetheless, it has been a popular request for users who wish to 
define ‘fallback
fonts’ for their documents for greater portability.

In this command, the syntax for the ⟨font name⟩ is a restricted/simplified 
version of the
font loading syntax used for \fontspec and so on. Fonts to be loaded by 
filename are detected
by the presence of an appropriate extension (.otf, etc.), and paths should be 
included inline.

E.g.:
\IfFontExistsTF{cmr10}{T}{F}
\IfFontExistsTF{Times New Roman}{T}{F}
\IfFontExistsTF{texgyrepagella-regular.otf}{T}{F}
\IfFontExistsTF{/Users/will/Library/Fonts/CODE2000.TTF}{T}{F}
---

Best regards,

Juan Manuel 

Re: fontsets

[Juan Manuel Macías]

Hi, Timothy,

Timothy writes:

> Yep, so in my config’s implementation I have an alist of fontset names and
> individual fonts. For something part of org-mode itself, we’d probably want to
> add a format level to this, something like:
>
> ┌
> │ ((fontset-name .
> │   ((serif .
> │ ((pdflatex . "\\usepackage{myserif}")
> │  (lualatex . "etc.")
> │  (html . "and so on")))
> │(sans ...) ... ))
> │ (another-fontset ...) ...)
> └
>
> Actually, now that I think of it maybe it would be better to seperate out the
> fontsets and fots, e.g.
>
> ┌
> │ ;; Fonts
> │ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
> │  (myfontb ...)
> │  ...)
> │ ;; Fontsets
> │ ((myfontset .
> │   ((sans . myfonta)
> │(serif . myfontb)
> │(mono . myfontc)
> │...))
> │  ...)
> └
>
>> In any case, I think it would also be nice if the user could add only
>> one family for roman, sans, mono or math, if he/she prefers it that way.
>> Something like:
>>
>> #+options: rmfont:Minion Pro
>
> Sure. There’s another bit of functionality in my config which I think is worth
> noting, you can add a -sans/-serif/-mono suffix to the fontset name to 
> override
> the default body text font.

I see. I like your approach. And the idea of fontsets also seems very
productive. I suppose that a minimum configuration in fontspec
(Scale=MatchLowercase) should be ensured, in order to balance the
x-height when using fonts from different families in a single document[1].

The fact that all of this can also be "reusable" for other outputs such as
html, is a not insignificant plus! I definitely really like all of these
ideas and I don't think there is any contradiction with a balance
between those users who are content with minimal out-of-the-box font
configuration to be able to read non-latin characters, and those who
want more control over fontspec (font features, etc). And there are also
the users (me among them) who leave little or almost no space for Org to
write the preamble for us :-)

On the other hand, maybe (I think) it would be nice not to differentiate
between xelatex and lualatex, since at least at this level both engines
support the same fontspec settings.

[1] I have to add, by the way, that MatchLowercase is not always a
panacea. In many cases, and depending on the fonts, it may be better to
allow some contrast between families. Maybe it would be nice to add to
the documentation or to worg (at least for users who may be interested
in these topics) some basic recommendations for combining families (for
example, combining a bodoni with a bembo is usually a catastrophic
marriage :-).

Best regards,

Juan Manuel

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

[Juan Manuel Macías]

Timothy writes:

> As an illustrative example, if I include this in one of my documents and 
> create
> a PDF:
> ┌
> │ #+options: fontset:biolinum
> └
>
> Then I’ll get text with:
> ⁃ libertine roman as the serif font
> ⁃ biolinum as the serif, and default, font
> ⁃ source code pro as the mono font
> ⁃ newtxmath as the maths font
>
> Similarly I can do `fontset:noto' and you can guess what that does.

I think it's a very good idea to be able to add the options using
#+options:..., forgive the redundancy :-)

When you talk about fontset, I understand that you mean lists of
families with their options that you have previously defined, is that
right? 

In any case, I think it would also be nice if the user could add only
one family for roman, sans, mono or math, if he/she prefers it that way.
Something like:

#+options: rmfont:Minion Pro

Best regards,

Juan Manuel 

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

[Juan Manuel Macías]

Max Nikulin writes:

>>   \\relax
>>   \\else
>
> Is it the case of latex as the old engine with tex->dvi->ps workflow
> besides new XeTeX and LuaTeX? However such engine is not used by Org.

According to the iftex documentation (p. 2):

\ifpdftex, \ifPDFTeX
True if PDFTEX is in use (whether writing PDF or DVI), so this is true
for documents processed with both the latex and pdflatex commands.

So the code says: if pdfTeX is used, do nothing; else, add this (luatex
and xetex related) code.

>>   \\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)
>
> Too many variables to my taste. It can be single property list. If I
> remember correctly, changing of mainfont requires setting of a
> consistent font for mathematics, so more options may be required.

Yes, that is true, sorry. I don't work with math. But:

\setmathrm{⟨font name⟩}
\setmathsf{⟨font name⟩}
\setmathtt{⟨font name⟩}
\setboldmathrm{⟨font name⟩}

Now, weren't we talking about ensuring a minimum readability out of the
box in case non-Latin characters are used? I assume that by default the
mathematical notation is assured, although the default mathematical font
may be typographically or aesthetically incompatible with the chosen
text fonts. For example, Computer Modern and FreeSerif are antipodes in
design. The first is a Didotian font and the second is a times style
typeface. But I think that what is sought here is that certain (non
latin) glyphs are represented in the PDF, beyond other typographical or
aesthetic considerations. My idea here is that a) the user who doesn't
want to mess with all these issues has a minimum of readability out of
the box; b) the user who wants to have full control over the fontspec
options has the possibility to do so; c) the user who does not want Org
to write the preamble under any circumstances (that is, people like me),
has the possibility of continuing doing so.

> Finally, default value may be language-dependent or alternative font
> set may be activated when non-latin characters are detected in the
> document.

If I had to choose between both options, I would prefer the second one.
But don't you think it would be much simpler to ensure the readability
of non-Latin characters (at least in a high percentage) by means of
three default fonts (roman, sans, mono), and let the user who needs
another font be able to choose it freely, simply by changing the value
of those variables? Generally, users working with a certain non-Latin
script are already used to using a certain font (I mean, they haven't
suddenly teleported into the digital world), and they know perfectly
well which fonts to use for their use case and their language. And for
those users who are a bit more lost, a list of recommended fonts can be
added to the documentation (many of which are already installed on their
system or are included with TeX live).

The other more extreme possibility is to default to GNU unifont
(https://unifoundry.com/unifont/index.html). With this font I think the
readability of almost everything is ensured (although it is a horrible
font, but it is not the case here). Or Google's Noto Fonts (but I don't
remember now what license terms those fonts are under).

Best regards,

Juan Manuel 

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

[Juan Manuel Macías]

Tim Cross writes:

> Juan, if I understand your proposal correctly, I think your on the right
> track. It sounds like what you are proposing would have almost no impact
> on basic users like me, but would allow those with more demanding
> requirements to adjust without too much effort. I originally raised the
> question regarding what would need to change with the switch to uatex to
> ensure that we do actually get things positioned to enable people to
> exploit the benefits and not just switch out one tool for another which
> only appears to be a little slower. I think what you are suggesting
> addresses that concern. 

Tim, thanks a lot for your interesting comments.

Indeed, I think that LuaTeX is a good direction for the TeX ecosystem.
And it seems that the third edition of The LaTeX Companion makes the way
clear:

https://tex.stackexchange.com/questions/612573/the-latex-companion-3rd-edition/612586

Of course, LuaTeX is still a kind of cyborg (someone defined it that
funny way :-). TeX has not been rewritten here from scratch (that would
have been preferable), but LuaTeX has brought, in my opinion, two
revolutionary things: being able to control TeX internals from a
scripting language as light and minimalist as Lua (which drastically
influences the creation of packages every increasingly powerful and
sophisticated for all areas) and the fact that TeX is finally native
unicode. From the latter, of course, follows the fact that the user is
no longer dependent on Computer Modern and can choose whatever font he
wants, just like in any other modern textual software, from a simple
word processor to more advanced tools like InDesign-style dtp programs.

Even though pdfTeX was light years ahead of InDesign, this simple
operation of choosing the font or font family has always been horribly
difficult in LaTeX. There were a few packages that incorporated specific
font families (Times, Fourier, etc.), but if one wanted to manually
install Adobe Garamond in pdfTeX ---for example---, the process became
absurdly long and cumbersome. Now in LuaLaTeX and XelaTeX that is as
simple as doing it in libreoffice.

Of course, TeX and LaTeX have always had their historical typeface,
Computer Modern, which is almost like one of their distinguishing
features. This extreme reliance on Computer Modern has often given
people who don't use LaTeX the misconception that any document made in
LaTeX always looks the same.

Despite the fact that I feel enormous admiration for Donald Knuth, and I
believe that to a greater or lesser extent many or almost all of us are
indebted to him, I believe that the design of Computer Modern is not
good and has many legibility problems (imho), especially legibility
screen (precisely because of its Didot-style design, with such a marked
contrast between the strokes). Since there is a thread on this list
about accessibility, it's worth remembering that Computer Modern isn't
exactly an easy-to-read font. Of course, you have to put things in their
historical context. When TeX was created there was nothing similar to
what we have today in fonts, there was no truetype or opentype, there
were no free fonts either. It was all to do. And, naturally, if one
creates "a new typesetting system intended for the creation of beautiful
books" (Texbook page 5, Preface), it would be somewhat strange if this
new typesetting system were born without a typeface to show the world
the excellence of TeX. For that reason Knuth created Metafont and the
Computer Modern font.

Now with LuaTeX and XeTeX choosing the font, any font, is easy, fast and
trivial.

> but as I said, I know nothing

I don't think so. Knowing (or not knowing) things or facts (after all, all
of this is just "data") is not the same as being wise and speaking
wisely :-)

Best regards,

Juan Manuel 

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

[Juan Manuel Macías]

Juan Manuel Macías writes:

> By the way, although I've already commented on it in some post in the
> parent thread, i think this package I wrote might be useful for doing a
> quick visual test of a font (including opentype features test), using
> org-latex-preview (compiling with LuaTeX). It can be done on any font
> marked in dired. There are three options: insert arbitrary characters,
> insert the Unicode code of the characters, or display a specimen of the
> font. The default specimen is in the file specimen.tex, which can be
> edited to add examples and languages.
>
> Some screenshots:
>
> https://i.imgur.com/3faKSjA.png
>
> https://i.imgur.com/OJfUcO9.png

Sorry, I forgot the link:

https://gitlab.com/maciaschain/org-font-spec-preview

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

[Juan Manuel Macías]

Stefan Nobis writes:

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

I voted nil because of the available fonts issue. But I think what you
say below is a good idea, so it could be activated 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.

Sounds like a good idea and I agree. If I understand correctly, if the
sans, roman, and mono font variables (or any of them) are non-nil,
enable font selection. Otherwise, leave the default Latin Modern font.

By the way, although I've already commented on it in some post in the
parent thread, i think this package I wrote might be useful for doing a
quick visual test of a font (including opentype features test), using
org-latex-preview (compiling with LuaTeX). It can be done on any font
marked in dired. There are three options: insert arbitrary characters,
insert the Unicode code of the characters, or display a specimen of the
font. The default specimen is in the file specimen.tex, which can be
edited to add examples and languages.

Some screenshots:

https://i.imgur.com/3faKSjA.png

https://i.imgur.com/OJfUcO9.png

To create font tables I often use the LaTeX package unicodefonttable. An
example of usage within Org:

#+header: :headers '("\\usepackage{unicodefonttable}")
#+begin_src latex :imagemagick yes :iminoptions -density 600 :results raw 
:results file :file -2256080143431736233.png
\displayfonttable*[range-start=1F00,range-end=1FFE]{Old Standard}
\displayfonttable*[range-start=0600,range-end=06FF]{FreeSerif}
#+end_src

A screenshot:

https://i.imgur.com/Fwsg7bb.png

Maybe it could also be added as an emergency fallback font GNU Unifont:

https://unifoundry.com/

Best regards,

Juan Manuel 

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

[Juan Manuel Macías]

Sorry, I forgot to add quotes :-)  "\\usepackage{iftex}...\\fi"

Juan Manuel Macías writes:

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

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

[Juan Manuel Macías]

Considering some discussions in the parent thread, I think maybe it
wouldn't hurt to ensure a minimal preamble when the output is compiled
with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
is loaded to be able to read PDFs in non-Latin scripts.

But before proposing the patch directly, I'd like to discuss its
structure. I think (IMHO) that a certain balance should be ensured
between a) users who don't want to mess with fontspec and want something
more out-of-the-box and b) users who prefer to be in control when
compiling with LuaTeX and XeTeX.

I think maybe it would be nice to let LaTeX do the work, via a
conditional from the iftex package (idea taken from pandoc).

The structure of the patch could be this:

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

2. There would be three variables for the default fonts: roman, sans and
mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
set as default value, since they are very ubiquitous and have a very
good coverage for non-Latin scripts.

3. A variable (something like 'org-latex-fontspec-default-configuration') would 
return something like this:

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

(and this string would be added at some point to org-latex-make-preamble)

4. Conclusion: I think the good thing about letting LaTeX do the
conditional work with iftex is that it saves us less invasive code on
our end. I also think that other more complex approaches, such as
searching for the fonts present in the system and adding them according
to the document scripts, would lead us to a completely slippery slope.
Of course, a list of recommended free-licensed fonts could be included
in the documentation.

WDYT?

Best regards,

Juan Manuel

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Tim Cross writes:

> Thanks Juan. It will be fairly trivial to compile the information you
> have provided into a basic org document which I can then add to org. If
> on the other hand you would prefer to write it up, all I need is an org
> document which is based on the (current) org 'worg' template, which is
> very simple i.e.
>
> #+:begin_src org
>
> #+TITLE:  [No title for now, please update]
> #+AUTHOR: Worg people
>
> #+OPTIONS:H:3 num:nil toc:t \n:nil ::t |:t ^:t -:t f:t *:t tex:t d:(HIDE) 
> tags:not-in-toc
> #+STARTUP:align fold nodlcheck hidestars oddeven lognotestate
>
> #+SEQ_TODO:   TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
>
> #+TAGS:   Write(w) Update(u) Fix(f) Check(c)
> #+LANGUAGE:   en
>
> #+PRIORITIES: A C B
> #+CATEGORY:   worg
>
> #+HTML_LINK_UP:index.html
> #+HTML_LINK_HOME:  https://orgmode.org/worg/
>
> # This file is released by its authors and contributors under the GNU
> # Free Documentation license v1.3 or later, code examples are released
> # under the GNU General Public License v3 or later.
>
> # This file is the default header for new Org files in Worg.  Feel free
> # to tailor it to your needs.
>
> #+end_src

Thanks so much for all the pointers, Tim.

I can collect and clean up (and possibly expand) all the information
I've put in this thread and make an Org document with this template. I
agree with Ihor that the template would be a great addition to Org-Mode.

Best regards,

Juan Manuel

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Max Nikulin writes:

> Characters from Latin scripts, the set is wider than latin-1 but does
> not cover other languages. I do not dispute that font encoding is
> Unicode (if it can be stated so), usually support of Unicode is
> associated with smooth experience with wide range of languages.

A Unicode font is a Unicode-encoded font. It can have 2 glyphs or 2000.
But it's still a Unicode font.

> But for default settings getting blank instead of text in some routine
> notes is hardly acceptable. Unfortunately \setmainfont is not enough.
> Starting for "the simplest of basic" on the next step a user may
> notice that bold...

Please, compile this:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{FreeSerif}
\begin{document}
Abc — Αλφάβητο — Азбука…
\emph{Abc — Αλφάβητο — Азбука…}
\textbf{Abc — Αλφάβητο — Азбука…}
\textbf{\emph{Abc — Αλφάβητο — Азбука…}}

With \setmainfont{FreeSerif} I'm telling LuaTeX to use the full
FreeSerif family as the main roman font, which includes bold, italic,
and bold italic. It is the duty of the user (at least the LuaTeX user)
to know that this family is present in his/her system and includes those
styles.

> or typewriter text is missing.

\setmainfont{FreeSerif}
\setsansfont{FreeSans}
\setmonofont{FreeMono}

I honestly don't understand why you find it unacceptable that the
responsibility for managing fonts and the languages associated with
those fonts falls on the user. It is to be expected. And it is something
that has finally corrected a great anomaly that TeX and LaTeX has always
been dragging along for almost its entire history, and that put it
(being more powerful and sophisticated) behind other types of
typesetting software like Indesign or quark. LuaTeX and XeTeX are
digital typesetting systems. They are not word processors. The user who
wants fine tuning in this regard will have to read the fontspec manual
and the babel or polyglossia manual thoroughly. I can agree with you
that the choice of the "default" font (Latin Modern) is not exactly happy,
due to the little coverage that this font has for non-Latin scripts. But
the demanding LuaTeX user is rarely going to use latin modern (I've
never used it in my life for real production). I think I made it clear
in the first post of this thread what kind of use cases LuaTeX is
suitable for. If someone finds that unacceptable, of course you'd better
use pdfLaTeX. By the way, in pdfLaTeX you can't write Greek out of the
box, nor Arabic, nor Japanese, etc., etc. So I don't see where the
difference is.

And even so, I insist, it is not necessary to go into typographical
depths. A configuration like the one I put before
(FreeSerif/FreeSans/FreeMono) will satisfy 90% of lazy users or those
who want to use LaTeX in autopilot mode.

Is it possible to implement all that in Org in such a way that a minimum
preamble is generated with what is necessary? How to define "what is
necessary", when there are thousands of options in fontspec and many
ways to declare and define font families and font features with
fontspec, with babel and with polyglossia? That's not counting
specialized packages for Arabic, Japanese, etc. (and I am writing a
package for greek). I think doing something like that in Org would be
highly intrusive on Org's part. Maybe something very, very, very basic
and minimal would work in order to avoid those empty spaces that seem
unacceptable to you, maybe three variables for
setmainfont/-sansfont/-monofont[1]. Going further, in my opinion, makes
no sense. I think it is much more important to unify in org the issue of
languages, polyglossia and babel, because as it is now it collects an
obsolete scenario.

[1] In my opinion, something similar to what pandoc does by default,
using the iftex package, would suffice:

\usepackage{iftex}
\ifPDFTeX
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{textcomp} 
\else
  \usepackage{fontspec}
\usepackage{unicode-math}
\defaultfontfeatures{Scale=MatchLowercase}
\defaultfontfeatures[\rmfamily]{Ligatures=TeX}
\setmainfont{FreeSerif}
\setsansfont{FreeSans}
\setmonofont{FreeMono}
\fi

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Max Nikulin writes:

> LuaTeX uses Latin Modern
> and it is not nearly Unicode

Maxim, please look at this screenshots carefully:

https://i.imgur.com/uMfheCL.png

https://i.imgur.com/WwGybBA.png

https://i.imgur.com/hpreFNQ.png

Frankly, I don't know what Latin Modern you're referring to, and what
you mean by saying that "it is not nearly unicode".

The default LM font in LuaLaTeX and XeTeX is an otf and Unicode font.
Which is not to say that it has all the glyphs to represent all possible
characters. Because I guess you know the difference between glyph and
character...

Perhaps a font with a broader coverage could have been chosen by default
for LuaLaTeX, but here the (LaTeX) historical reasons have prevailed.
It's probably not the happiest choice, but LM is still a Unicode font
nonetheless.

And I insist: what you say about it being necessary to completely
configure everything related to fonts in LuaTeX is not correct. It
depends on the use case, and you can go (as I said in my previous email)
from the simplest to the most complex configuration.

On the other hand: I think that in the case of LuaTeX and XeTeX the
choice and configuration of fonts should be on the LaTeX side and not
Org's. Implementing that in Org would lead to a bunch of variables to
cater for all possible cases. It might suffice to give some examples of
basic use (like the ones I have put in the previous mail, and that will
be enough for most users) and recommend free license fonts for different
languages[1]. Maybe starting here:

https://tug.org/FontCatalogue/opentypefonts.html

But if the user needs more fine-tuning of fonts and languages, he/she
will undoubtedly have to read the fontspec and babel manuals, depending
on his needs, which can be very different from one user to another.

[1] Although I see it as unnecessary. Fonts are not recommended when the
output is odt...

> With the following minimal example I got
> blank space instead of non-latin characters.

> \documentclass{article}
> \begin{document}
> Abc — Αλφάβητο — Азбука…
> \end{document}

\documentclass{article}
% 
\usepackage{fontspec}
\setmainfont{FreeSerif}
% 
\begin{document}
Abc — Αλφάβητο — Азбука…
\end{document}

\usepackage{fontspec}\setmainfont{FreeSerif} is the same as choosing the
font in the libreoffice font menu.

You have to keep in mind that LuaTeX and XeTeX are designed so that it
is the user who decides which fonts to use and so that it's the user who
has the freedom to manage those fonts as he wishes. Okay: they could
have made a series of fallback fonts load by default to cover all
glyphs, for users who don't want to mess with typography. But I think
that this basic example that I have put is quite simple, and gives the
user the freedom to choose his preferred font and not the one imposed by
the system. And, at the end of the day, TeX is essentially a
typographical tool, whether you like it or not. Of course, LaTeX can be
used on autopilot because many scientific publications ask for articles
in LaTeX (with very little room for maneuver on the part of the authors,
since in the end a LaTeXpert will do the typesetting for the
publication). But there are also users who want to create their own book
layout from scratch, and use whatever font they want, in the same way as
when exporting to html from org there are users who like to write their
own css styles. LuaTeX and XeTeX offer the user that freedom, and it can
be done very simply. I have used pdfLaTeX for a long, long time and I
know very well how immensely laborious it was to install new type1
fonts, because I installed quite a few. Now, in LuaTeX any system font
can be used in a simple and fast way, I think it is something that users
should value more.

Re: Taking notes of videos in Emacs

[Juan Manuel Macías]

Hi, Gerardo,

Gerardo Moro writes:

> As for your own package, Juan Manuel, I understand the main purpose is
> to take screenshots of movies. Am I correct?
> Thanks!

Yes, it is a series of homemade hacks (if i called it "package" I would
sound too presumptuous lol), just to be able to take screenshots and add
them to an org document, along with a timestamp. I wrote it because I
use EMMS and not mpv.el, and also I don't need most of the features of
org-media-note.

If you don't use EMMS and are looking for something more complete that
includes screenshots, notes and many more features, then org-media-note
is definitely the ideal choice.

Best regards,

Juan Manuel 

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Hi Thomas,

Thomas S. Dye writes:

> Yes, what I called Babel you call org-babel.  I don't know if the Lua
> handler of source blocks in Org might be useful for someone interested
> to write Lua extensions to LaTeX.

I'm writing a package for LuaLaTeX in Org[1] using lua code blocks, and
everything works fine. But if you mean to evaluate these blocks from
Org, it wouldn't really make sense because LuaTeX uses its own Lua
interpreter and that's where the code should be evaluated. For example,
in LuaTeX you should use tex.print or tex.sprint to print a result in
LaTeX, instead of 'print'.

A simple example to create a counter using Lua:

\newcommand{\mydefcounter}[2]{{\directlua{#1 = #2}}}
\newcommand{\mycounter}[2]{\directlua{%
function count ()
#1 = #1 + #2
tex.print (#1)
end
count()
}}

\mydefcounter{foo}{0}

\mycounter{foo}{1}

\mycounter{foo}{1}

\mycounter{foo}{1}

You might want to take a look at the chickenize package, which includes
loads of examples and is very instructive.

https://www.ctan.org/pkg/chickenize

[1] btw, I thought I was the only one to write a LaTeX package in Org,
instead of the 'official' LaTeX docstrip suite (doing it in Org is
infinitely more comfortable!), but I've seen that the wallcalendar
package has also taken the unorthodox route, with all source code and
documentation in Org :-):

https://github.com/profound-labs/wallcalendar/blob/master/Makefile

Best regards,

Juan Manuel 

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Hi, Maxim,

Max Nikulin writes:

> [...] With LuaTeX you get more convenient OTF and TTF font selection, but
> you you have to pay for the feature. It is necessary to explicitly
> specify all families: normal, typewriter, italics, etc if you need
> Unicode. -

Not necessarily. You can go from the simplest or basic to the most
complex, depending on the user's needs. If the user does not need to
write in non-Latin scripts, and is not particularly interested in fonts
and otf esoteric features, then the otf version of the Computer Modern
font (which LuaTeX uses by default) will suffice, as this font has
coverage for latin, latin-1, latin-extended, etc.

If you need to fine-tune fonts or work with non latin scripts, then it
is necessary to load fontspec. But equally here you can go from the most
basic to the most complex fontspec options and features, depending on
the needs of the user.

For example, if you want to write an article in both Russian (main
language) and English, and want to use the Old Standard font (which has
excellent coverage for Cyrillic), the basics might be:

\usepackage{fontspec}
\usepackage[english,russian]{babel}
\setmainfont{Old Standard}

or, using the Babel style (which requires fontspec in the background):

\babelfont{rm}{Old Standard}

That would be the classic setup. Another example, here with modern Babel
notation: an article in Spanish with the secondary language in ancient
Greek. We want to use Linux Libertine as the main font, and for
Greek Old Standard:

\usepackage[spanish]{babel}
\babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
\babelfont{rm}{Linux Libertine O}
\babelfont[greek]{rm}{Old Standard}

That would be the most basic. And, from there, everything can be made
more complex, according to the needs.

> There is babel LaTeX package. A decade ago polyglossia was
> a replacement of babel for XeTeX and LuaTex, but currently babel is
> recommended for these LaTeX engines as well.

That's correct. Babel is strongly recommended, and development of Babel is
very active.

A few months ago I proposed this patch here to adapt Org to the new
scenario regarding Babel and Polyglossia. It is a first approximation
and I have to review it. But the idea is to unify in a single list
(named `org-latex-language-alist' `org-latex-polyglossia-language-alist'
and `org-latex-babel-language-alist':

https://list.orgmode.org/87sfxiw2jp@posteo.net/

Best regards,

Juan Manuel 

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Hi, Tim, thank you for your comments,

Tim Cross writes:

> Juan, I think it would be great to add your post to worg. I'm happy to
> do this, but I think it wold also be good if we could include a basic
> 'setup' i.e. what changes people might need to (or should do to maximise
> benefit) in order to try out luatex. For example, what settings to put
> in org-latex-pdf-process (I'm guessing something like "lualatex
> -interaction nonstopmode -output-directory %o %f") and what (if any)
> packages to add/remove from the org-latex-packages-alist etc (I'm
> guessing that perhaps some font related packages may need tweaking?).
>
> Ideally, what would be good is a very simple recipe for what someone
> should do in order to try out luatex and get the most out of it (or at
> least see potential).

I have no problem with my post being added to worg, but I don't have
much experience in working with worg... Of course, I can prepare
everything you need, if you think it might be useful.

The *only* difference between a minimal document for lualatex and a
minimal document for pdfLaTeX is that for LuaLaTeX it is not necessary
to load the fontenc and inputenc packages. The following mwe
compiles perfectly in LuaLaTeX:

\documentclass{article}
\begin{document}
Hello world!
á é í ó ú ñ à è ì ò ù
\end{document}

LuaTeX defaults to an otf version of the Computer Modern font, so any
user who isn't interested in fonts and writing in non-Latin languages,
but wants to work in a real Unicode environment, won't need to fine-tune
fonts, nor load any special package. The rest is exactly the same as any
document for pdfLaTeX.

If in the Org document is added:

#+LATEX_COMPILER: lualatex 

the fontenc and inputenc packages are not loaded in the output, which is
correct and it is the minimum requirement for LuaLaTeX. I think Org is
already doing a good job here.

If the user wants to use other fonts, the fontspec package must be
loaded. Depending on the user's needs, you can go from the simplest to
the most complex configurations (the different options and possibilities
are explained in detail in the fontspec manual). The simplest: if a user
just wants to use the Times New Roman font as the main font in his
document, this lines would suffice:

\usepackage{fontspec}
\setmainfont{Times New Roman}

That is, by indicating the name of the family (Times New Roman), luatex
would use this family for normal text, italics, bold, etc. Of course,
it's a good idea to load a family that has italic, bold, bold italic,
and other subtypes. Fontspec has tons more options, but this would be
the basics. But I think this aspect is more on the LaTeX side than in
the Org side.

LuaTeX can use the fonts installed on the system, without the need to
add more (that is, simply by putting the name of the family, LuaTeX
accesses them); and you can also use any font in any directory, just by
giving the path. I wrote BTW this little package to preview any font in
Emacs, and test the opentype features. it uses org-latex-preview in the
background and compiles with LuaTeX:

https://gitlab.com/maciaschain/org-font-spec-preview

Best regards,

Juan Manuel 

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Bruce D'Arcus writes:

> Today, I think the only advantage pdftex has is speed; it's a lot
> faster to compile documents than luatex.

That's true, but it seems to be a LaTeX and fontspec issue. I think
ConTeXt, which uses LuaTeX, is faster, but I don't have the hard data.
In general TeX is slow and single-threaded and cannot take advantage of
the latest hardware. The ideal would be to rewrite TeX from scratch.
There is this project (among others), very interesting:

https://sile-typesetter.org/what-is-sile/

(It is written entirely in Lua and implements the TeX algorithms. The
problem is that it lacks the LaTeX package ecosystem, is a niche.)

> And maybe some advanced microtypography features, though I haven't tracked 
> that.

This is one of the most interesting parts of pdfTeX, based on Hermann
Zapf's theories on the Gutenberg Bible. I believe that Zapf himself
advised the author of pdfTeX for his famous thesis, from which pdfTeX
arose.

LuaTeX has inherited the microtype properties of pdfTeX, so they can be
perfectly used and applied in luaLaTeX with the microtype package
(generally speaking, LuaTeX is still a kind of evolved pdfTeX...).

BTW, This article explains very well these microtypographic theories and
their origin. InDesign's poor implementation compared to pdfTeX is also
commented on:

http://www.typografi.org/justering/gut_hz/gutenberg_hz_english.html

In general, font expansion greatly improves the visual quality of the
paragraph and the use of space. Character protrusion works well for
producing a more consistent justification as well, but relies on ad hoc
values being used for each font. There are already some defaults for
various fonts in the microtype package. Indesign, on the other hand,
just uses generic values, which doesn't make much sense.

Best regards,

Juan Manuel 

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

Hi Uwe,

Uwe Brauer writes:

> Thanks for that list.
>
> Well I have felt in the past the same about pdftex, but I have partially
> switched to xetex precisely on the reasons you list.
>
> I have not have the time, to really try out Luatex. Did you have the
> time to compare it with XeTeX?

First of all, if you feel comfortable with xetex, my advice is to use
XeTeX. I've been using XeTeX for a long time, before fully migrating to
LuaTeX, and I think it's great. In fact, XeTeX was a great revolution in
the TeX ecosystem, for being able to use system fonts in a simple way.
LuaTeX came later.

The first TeX engine I ever used was Omega, an experimental engine
(later forked as "Aleph") that was the first TeX engine with full Unicode
support. But it still produced dvi files, not pdf. LuaTeX has evolved
from pdfTeX and has incorporated the more advanced and sophisticated
features of Omega/Aleph.

Any LaTeX document that you compile in XeTeX can be easily compiled in
LuaTeX. There may be some small incompatibilities, for example if you
include some native xetex primitives. You can do the test. The reverse
path is also possible, as long as the document does not contain Lua
code or luatex primitives.

In general, for an average user, moving from xetex to luatex does not
make any visible changes. The advanced features of LuaTeX, as I said,
are more on the developer side. Of course, if the user programs in Lua,
he/she can switch LaTeX code with lua code, use callbacks and pre/post
process lua filters, which offer enormous control over the document. But
it is not necessary. But keep in mind that you can get a lot of control
over the low-level gears of TeX by the Lua scripting, which is much
simpler and lighter than pure TeX.

The essential differences between luatex and xetex are in the last two
points on my list. The last point is important to keep in mind, as
more and more packages (some tremendously useful) are coming out that
only work in LuaTeX.

On the other hand, LuaTeX is an evolutionary step from pdfTeX (xetex
would be a separate branch), so luatex is meant to be the default or
"official" engine and replace pdfTeX, just as pdfTeX replaced TeX in its
day.

Best regards,

Juan Manuel 

Re: Taking notes of videos in Emacs

[Juan Manuel Macías]

Gerardo Moro writes:

> Hi, 
>
> I recently discover the Obsidian Media Extended plugin
> (https://www.youtube.com/watch?v=GQXVWtNkeZw) to take notes while
> watching videos / listening to audios with keybindings to stop the
> video and create timestamps with link to the specific moment of the
> video, etc.
>
> Is there something similar in Emacs?

See org-media-note: https://github.com/yuchen-lea/org-media-note

And, for something simpler, I shared here days ago this code:

https://list.orgmode.org/871qvmt4xr@posteo.net/

Best regards,

Juan Manuel 

LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Juan Manuel Macías]

TL;DR: A list of use cases where using LuaTeX is more advantageous than
using pdfTeX



Many times Org users who frequently need to export their documents to
LaTeX, but who do not have much LaTeX experience (or their knowledge of
the TeX ecosystem is somewhat out of date), find themselves confused by
the different versions of the TeX engine: pdfTeX, XeTeX, LuaTeX… In Org
pdfTeX is the default engine, which in 2022 has a few limitations and is
really old, but still perfectly meets the needs of a significant group
of users. However, there may be a number of cases where it is more
advantageous to compile with LuaTeX, so here I will leave a short list
of those cases where LuaTeX may be a happy choice over pdfTeX.

But first it is worth clarifying some things about LuaTeX along with
some misunderstandings:

• LuaTeX is the evolution of pdfTeX, therefore LuaTeX can be considered
  as the current de facto TeX engine. It is intended to replace pdfTeX,
  and in fact many of us already consider pdfTeX obsolete and
  deprecated.

• To use LuaTeX it is not necessary to learn anything new or to know how
  to program in Lua. LuaTeX includes a Lua interpreter and the ability
  to bypass TeX primitives through Lua scripting (hence called LuaTeX).
  But all of that is more on the side of developers and packagers. For
  example, I am currently writing two LaTeX packages (one in
  collaboration with a colleague) where 80% of the code is Lua and 20%
  is (La)TeX. Of course, any user who knows Lua can take advantage of
  the \directlua primitive or the luacode environment in their
  documents.

• A standard LaTeX document is always a LaTeX document, regardless of
  the flavor of TeX used to compile that document. There will be some
  minor differences. For example, in LuaLaTeX it is unnecessary to add
  fontenc and inputenc commands in the preamble.

And now we go with the non-exhaustive list of cases where compiling with
LuaTeX can be more advantageous for the user:

1. When you need to work in a *real* Unicode environment and not in
   pdfTeX’s 'fake Unicode'. And, especially, when it is required to work
   with languages that use a non-Latin writing system: Greek, Arabic,
   Hebrew, all the languages that use Cyrillic, oriental languages, etc.
   An extreme example you can see in this small code that I wrote for
   LuaTeX in order to be able to use the syllabograms of the ancient
   Mycenaean script:

   

2. When using truetype or opentype fonts is required. The pdfTeX user is
   limited to using only the included type1 fonts, the number of which
   is very limited. Besides, type1 is a deprecated and pre-unicode
   format. In fact, it almost always ends up leaving the default
   Computer Modern font. In LuaTeX we can use not only all the fonts
   installed on our system but also any font (just indicate the path),
   which is an important advantage over XeTeX. A basic command could be
   something like (loading the fontspec package):

   ┌
   │ \setmainfont{Palatino Linotype}
   └

   And with the latest versions of Babel we can associate fonts for
   different writing systems, without the need to change languages
   explicitly with a \selectlanguage.

   We can define all the font families we want or redefine the default
families. For example, with this command I define the default
monospaced font and request that it be scaled according to the
height of the lowercase of the main font:

   ┌
   │ \setmonofont{Iosevka Fixed Curly}[Scale=MatchLowercase]
   └

3. When you need to take advantage, to a greater or lesser extent, of
   the opentype features of a font. For example, here we define the main
   font to use old style numbers:

   ┌
   │ \setmainfont{Palatino Linotype}[Numbers=Lowercase]
   └

   We can also load the otf tags directly:

   ┌
   │ \setmainfont{Palatino Linotype}[RawFeature=+onum]
   └

   The fontspec package for managing fonts in LuaTeX and XeTeX is very
versatile and powerful. We can also associate a different font as
italic for an already defined font family, use different optical
resolutions of a font, etc. If what you are looking for is precise
and absolute fine-tuning of the fonts used, of course LuaTeX is the
ideal choice.

4. In general, when professional-level typographic fine-tuning is needed
   (and far superior to that offered by dtp programs like InDesign or
   QuarkXpress). For example, we can define on the fly new position
   opentype properties for a specific font, without having to edit the
   font. It is a non-destructive method that uses the
   fonts.handlers.otf.addfeature lua function. For example, we can
   define a new kerning value for the letters A and V. We’ll call it
   ’mykern’

┌
│ \directlua{
│ fonts.handlers.otf.addfeature
│ {
│name ="mykern",
│type ="kern",
│data =
│   {
│["A"] = { ["V"] =  270 },
│ }}
│ }
│ 
│ \setmainfo

Re: Convert a Lisp expression to a tree diagram

[Juan Manuel Macías]

Ihor Radchenko writes:

> This capture template is public: https://github.com/yantar92/org-capture-ref

Thank you! It is very complete, and I have seen that it also integrates
with qutebrowser. I'll try it as soon as I have time.

Best regards,

Juan Manuel 

Re: Convert a Lisp expression to a tree diagram

[Juan Manuel Macías]

arthur miller writes:

> This one draws graph of cons cells (lists):
>
> https://github.com/amno1/draw-cons-tree
>
> I never tried with random s-expressions, but I guess you could pass
> them in as lists?

Hi, Arthur,

Thank you for the pointer to draw-cons-tree. I didn't know this package,
I'll take a look.

Best regards,

Juan Manuel

Re: Convert a Lisp expression to a tree diagram

[Juan Manuel Macías]

Ihor Radchenko writes:

> Invoking search across my notes and archives (all stored in Org, of
> course) yielded the following:
>
> https://reddit.com/r/emacs/comments/u2ca5c/drawtreeel/
> https://reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/
>
> linking to
>
> https://github.com/amno1/draw-cons-tree
> https://github.com/zainab-ali/pair-tree.el (example: 
> https://teddit.namazso.eu/pics/w:2172_vetc0martyb61.png)
>
> Hope it helps.

Thanks a lot, Ihor! There is some very juicy information there.

> actual notes below:

Awesome notes. Hats off to such a detailed capture (reminds me to give
my poor org-capture templates some more love one day :-))

Best regards,

Juan Manuel

Convert a Lisp expression to a tree diagram

[Juan Manuel Macías]

Hi all,

Sorry for the slight offtopic. I'd like to be able to graphically
convert (from a src block) a Lisp expression to a tree diagram, similar
to trees used in (human) syntax and grammar, especially generative
grammar (this is a web app for generating such trees:
http://www.ironcreek.net/syntaxtree/). I think I can try some LaTeX hack
using the 'forest' package (here's a related thread with pros and cons:
https://tex.stackexchange.com/questions/140812/drawing-a-lisp-expression-as-a-tree),
but I was wondering if anyone knows of any more emacs/elisp/org friendly
packages/solutions. Some time ago I saw an Emacs package that could
convert a Elisp expression into an ascii text tree diagram, but I can't
remember its name and I can't find it anywhere...

Best regards,

Juan Manuel 

Re: PDF export, table of contents and internal links

[Juan Manuel Macías]

Sébastien Gendre writes:

> If I learned LaTeX syntax in the past, I never take enough time to learn
> how work each compilation possibility. I feel lost with all the
> pdflatex, teklive, lualatex, double or quadruple compilation, etc.

The problem of multiple compilations is not related, in general, to the
TeX engine being used (pdfTeX, XeTeX, LuaTeX) but to LaTeX itself, which
continually needs to write and read auxiliary files. If, in addition,
you need to use citations, add an analytical index or other elements to
your work, you will also have to call the corresponding engines (bibtex,
biber, xindy, etc.) and compile again. And to all this is added that
there are specific packages that also need more than one compilation. So
it's often the best idea to let latexmk take care of all that instead of
compiling manually.

You may be interested in taking a look at another TeX format, ConTeXt,
not as popular as LaTeX but very powerful. It has certain advantages
over LaTeX. For my workflow, I prefer LaTeX. But there are users who can
be better served by ConTeXt, and they should be aware of it. Unlike
LaTeX, whose concept is of a minimal kernel that can be extended by
packages, ConTeXt starts from a monolithic kernel, which includes
everything or almost everything. In other words, it is not necessary to
load a package for this, another package for that, etc. Its interface is
more minimalist than the LaTeX interface and its compilation process is
(I think) faster. And, on the Org side, we luckily already have a
ConTeXt exporter, ox-context, written by Jason Ross:

https://github.com/Jason-S-Ross/ox-context/

There is a very complete introductory manual to ConTeXt written by
Joaquín Ataz López, with translations into various languages, including
English and French:

https://github.com/contextgarden/not-so-short-introduction-to-context

> Do you have good articles or book to suggest about this part of LaTeX ?

A good read might be: /The Not so Short Introduction to LaTeX2e/
(https://scholar.google.com/scholar?q=the not so short introduction to
latex2e)

And if you dare to program at a low level in pure TeX, this is very
good: /TeX for the Impatient/
(http://mail.tug.org/TUGboat/tb11-4/tb30ads.pdf)

> To come back to "org-latex-pdf-process", I only added "-shell-escape"
> for the minted package. To have beautify code block. But maybe it exist
> better solution ? Someone have experience with Engrave Faces ?

The -shell-escape flag only makes sense if you need to call an external
process during compilation (as in the case of minted). It is also
necessary if you need to use an indexing engine like xindy. But apart
from these cases and some more, an org user will have more advantages
using babel.

I use Minted, but I'm not convinced. It also has some problems with
certain LaTeX packages. I have Engrave Faces on my TODO list to try. And
possibly I will migrate to it...

Best regards,

Juan Manuel 

Re: PDF export, table of contents and internal links

[Juan Manuel Macías]

Hi, Sébastien,

Sébastien Gendre writes:

> To generate the table of contents, I have to compile my .tex file into
> PDF 2 times. The first time, I got no toc. The second time the toc was
> here.

I would say It's a normal LaTeX thing. Sometimes LaTeX needs more than
one compilation to finish processing things like TOC or
cross-references, because it writes to auxiliary files if there has been
any change in those elements. What I suggest is that you use latexmk as
the default 'org-latex-pdf-process'. latexmk is a script that takes care
of intelligently compiling everything, as many times as necessary.

I have in my init:

(setq org-latex-pdf-process
  '("latexmk -lualatex -output-directory=%o -e '$lualatex=q/lualatex
  %%O -shell-escape %%S/' %f"))

(I use LuaTeX instead of pdfTeX).

Best regards,

Juan Manuel 

Re: Org mode export accessibility

[Juan Manuel Macías]

Tim Cross writes:

> As I understand it (which isn't brilliant), the core problem is more to
> do with how the LaTeX/TeX engine processes the input to generate the
> postscript and pdf output. Modern PDFs have a wealth of internal tagging
> which simply sin't supported via the tex -> pdf pathway. The matter is
> made slightly worse by a lack of built-in support within latex/tex for
> accessibility 'tags' (similar to the aria tags for web content). 

There is a relatively recent experimental package for LaTeX that may be
of interest to you:

CTAN: https://www.ctan.org/pkg/tagpdf

GitHub: https://github.com/u-fischer/tagpdf

The package is maintained by Ulrike Fischer, who is very active in the
TeX community. However, the package description says:

> The package offers tools to experiment with tagging and accessibility
> using pdfLaTeX and LuaTeX. It isn't meant for production but allows
> the user to try out how difficult it is to tag some structures; to try
> out how much tagging is really needed; to test what else is needed so
> that a pdf works e.g. with a screen reader. Its goal is to get a
> feeling for what has to be done, which kernel changes are needed, how
> packages should be adapted.

Best regards,

Juan Manuel 

Re: Org and Hyperbole

[Juan Manuel Macías]

Hi, Robert,

Robert Weiner writes:

> We do like avy and as you say, Hyperbole can work with it.  We try to
> avoid requiring any non-builtin Emacs packages for Hyperbole.  With a
> few, we support them optionally.  Unless there is a strong use case
> for utilizing avy in certain ways, we would tend to leave that to
> others to extend Hyperbole but personally I just add it in and use its
> character and line navigation sometimes.  Did you have any particular
> uses in mind?

My use of the mouse within Emacs is practically nonexistent, and outside
of Emacs I have relegated the mouse to a few graphical applications such
as Gimp, Krita, Scribus, and little else. That's why I find avy
extremely handy for quickly navigating through text. By adding an action
to avy-dispatch-alist you can execute an arbitrary command once the
cursor has jumped to its target. For example, I have put this for
hyperbole in my init:

(add-to-list 'avy-dispatch-alist '(?: . (lambda (pt)
  (goto-char pt)
  (hkey-either

Thus, the typical action to activate a 'far' hyperbole button would be:

1. Call avy and insert a letter;

2. When avy's hints are displayed in the screen, I hit the colon key ":"
and then the hint letter I want to go to (an implicit button, for
example). And at the moment the associated action of that button is
executed.

For those of us who hardly use the mouse, it is really very practical,
and I think maybe mentioning that tip might be nice in the hyperbole
documentation.

Best regards,

Juan Manuel 

Org inside LaTeX (a poor man's approach with LuaTeX)

[Juan Manuel Macías]

Hi all,

I know some old school LaTeX users who are interested in giving Org a
try, but seem to have a hard time getting out of their LaTeX comfort
zone. So I thought maybe it wouldn't be a bad idea to invite them to try
some Org doses without leaving LaTeX. I got the idea from the LaTeX
markdown package... With one drastic difference: the markdown package
includes a complete LaTeX markdown parser. Mine is just a poor man hack
that runs emacs --batch through Lua.

For example, you can put things like this in a LaTeX document:

\begin{luacode*}

org = [[

* Section

/Lorem ipsum dolor/

*Lorem ipsum dolor*

#+caption: Lorem ipsum dolor
#+ATTR_LaTeX: :booktabs t
|-+-+-|
| lorem   | ipsum   | dolor   |
|-+-+-|
| lorem ipsum | lorem ipsum | lorem ipsum |
| lorem ipsum | lorem ipsum | lorem ipsum |
| lorem ipsum | lorem ipsum | lorem ipsum |
| lorem ipsum | lorem ipsum | lorem ipsum |
|-+-+-|
| lorem ipsum | lorem ipsum | lorem ipsum |
|-+-+-|

]]

org_output()

\end{luacode*}

Unfortunately I've only gotten it to work this way explicitly. If I try
to define a macro or environment to make it simpler, it returns errors
everywhere.

If anyone wants to try it, I am attaching to this email a 'test.tex'
document that contains everything you need. You just have to compile it
with lualatex.

Best regards and happy weekend,

Juan Manuel


test.tex
Description: TeX document

Re: Org and Hyperbole

[Juan Manuel Macías]

Hi, Robert,

First of all, welcome to the list. And of course congratulations on all
the great work you've done with hyperbole. In my ignorance, when I
recently installed it from ELPA, I thought it was a relatively recent
package. But it seems that you have been developing it for a long time,
while adapting it to the latest GNU Emacs trends. This is fortunate,
because what is new is combined with experience and the residue of work
already done over the years.

At the moment I am not going to comment here anything specific on the
technical level, because I have been using hyperbole for a short time
and my knowledge of this package is still very limited. I think the best
strategy for using hyperbole, from a user's point of view, is to simply
use it. And gradually discover which parts of hyperbole can be useful
and integrate into one's workflow. This is more practical than trying to
start from a global conceptual base (IMHO). I'm still having trouble
explaining what Org is for and what Org really is :-). But this is also
the case with Emacs itself. When I first started using Emacs I thought
it was just a text editor, like any other text editor. In fact, on my
first day with Emacs I hated it dearly and uninstalled it in a rage. Now
it's my desktop environment and my work environment, with EXWM, with
Org, among others, and hopefully with Hyperbole as well. I suppose that
it is the daily use that is making us connect the dots...

I really like the implicit link system, and it is really easy to define
new links. I have already defined a set of new buttons for LaTeX, which
recognize commands and environments and point to the local TeX live
documentation or texstackexchange.com. And with avy they work great.
Have you thought about giving a support for avy? In any case it is easy
to add a new avy action to avy-dispatch-alist.

Best regards,

Juan Manuel 

Robert Weiner writes:

> Hi:
>
> Thanks to Juan for starting this thread and the interesting
> conversation it has started.  I just joined this mail list, so I don't
> have the prior messages and can't reply to the thread, so I have
> started this new one.
>
> I am the author of Hyperbole and would be happy to answer questions
> concerning Hyperbole today (so you don't have to answer based on
> experience from the 1990s).  Hyperbole has been modernized for use
> with Org mode and Emacs 28 and continues to develop.  There are videos
> that demonstrate some of its features in simple, understandable ways.
> Hyperbole is a single Emacs package that can be installed and
> uninstalled quickly for testing.  It is largely a global minor mode,
> so you can also disable it quickly if you ever care to.  In 20 minutes
> you can get through the builtin, interactive demo and be on your way
> to basic yet powerful usage.  We have listened to much feedback in the
> last few years and made it much more approachable.
>
> I find most of the confusion is people trying to understand how
> Hyperbole works under the covers rather than just following the
> tutorial and exploring it.  Hyperbole can be hacked on if you are a
> moderate to advanced programmer but it is meant to be used, like Org
> mode.  Hyperbole recognizes many, many common contexts in buffers that
> could serve as hyperlinks (paths, URLs, multiple key sequences, mail
> addresses, and on and on) and performs the typically desired action
> when you press its Action Key {M-RET} on these 'implicit buttons'.
> You get all this for free with no effort on your part.  Then if you
> want to extend such behavior, as you have seen a bit of, you can
> define your own implicit button and action types once and then
> activate an infinite number of matching implicit buttons.  For
> example, in an Emacs shell buffer, type:
>
>echo $PATH
>
> then press the {M-RET} key or Shift-Middle mouse button on any path
> there and jump right to it.  I find that very useful as a simple
> example.  People are often surprised at how many things simply work
> right out of the box because such broad context-sensitive behavior is
> difficult to develop and rarely seen.  Just try it out and you should
> find some contexts that you can leverage rapidly.  {C-h A} displays
> what Hyperbole's Action Key will do in any context so you can always
> check and learn before activating anything.  We say: Hyperbole brings
> your text to life.  Like Org and Emacs, it provides an extensive
> environment that you can grow into across time, getting ever more
> productive rather than hitting a ceiling as with most point
> packages/tools.
>
> I am happy to answer questions and discuss ways we can make Hyperbole
> and Org work even better together; one direct question per message
> would typically work best.  Responses may take awhile as my schedule
> makes it difficult to keep up with high volume mailing lists but if
> you cc: r...@gnu.org, I'll likely see your message faster and respond.

Re: Org and Hyperbole

[Juan Manuel Macías]

Hi Jonathan, sorry for my late response,

indieterminacy writes:

> I recommend Hyperbole, though I must confess Ive been using Orgmode a 
> lot less since Ive been focusing on the format GemText.
>
> I should recommend the use of the function defil, for people who like 
> regexes and want to operate differing contexts (to launch via the ACTION 
> operator). Its mid-grade compared to the more simpler approach and the 
> more complex eLisp approach.

Thank you very much for all the very interesting information about hyperbole!

I am liking the idea of implicit buttons more and more, and I see a few
applications of this concept that I can find very practical. To play
around with the defil function, which you recommend in your email, I've
tried defining some 'contextual help' for LaTeX and Org. Specifically for
Org it has occurred to me to convert some keywords into implicit buttons
that point to the info pages. Something like this:

#+begin_src emacs-lisp
  (defil org-attr-latex
"#+" ":" "attr_latex\\|caption"
(let ((el (org-element-at-point)))
  (cond ((eq (org-element-type el) 'src-block)
 (lambda (x)
   (info "(org)Source blocks in LaTeX export")))
((eq (org-element-type el) 'table)
 (lambda (x)
   (info "(org)Tables in LaTeX export")))
((eq (org-element-type el) 'plain-list)
 (lambda (x)
   (info "(org)Plain lists in LaTeX export")))
((eq (org-element-type el) 'paragraph)
 (lambda (x)
   (info "(org)Images in LaTeX export")))
((eq (org-element-type el) 'verse-block)
 (lambda (x)
   (info "(org)Verse blocks in LaTeX export")))
((eq (org-element-type el) 'special-block)
 (lambda (x)
   (info "(org)Special blocks in LaTeX export")))
((eq (org-element-type el) 'example-block)
 (lambda (x)
   (info "(org)Example blocks in LaTeX export")))
((eq (org-element-type el) 'quote-block)
 (lambda (x)
   (info "(org)Quote blocks in LaTeX export"))

  (defil org-attr-html
"#+" ":" "attr_html\\|caption"
(let ((el (org-element-at-point)))
  (cond ((eq (org-element-type el) 'table)
 (lambda (x)
   (info "(org)Tables in HTML export")))
((eq (org-element-type el) 'paragraph)
 (lambda (x)
   (info "(org)Images in HTML export"))


  (defil org-options-kw "#+" ":" "options"
(lambda (x)
  (info "(org)Export Settings")
  (occur "‘OPTIONS’")))
#+end_src

I've also discovered the defib function, which allows you to define
implicit buttons using predicates, instead of just using regular
expressions and delimiters.

Best regards,

Juan Manuel 

Re: Org and Hyperbole

[Juan Manuel Macías]

Hi David, 

David Masterson writes:

> I haven't touched Hyperbole in ...decades...?  Even then, it was
> complicated and full-featured (but I still keep it in my .emacs file).
> My discussions with Bob Weiner were interesting at the time and I really
> wanted to make use of it.
>
> As you've discovered, it integrates a lot of what Org has in, perhaps, a
> tighter fashion (which makes it more complicated, but the pain might be
> useful). The Smart Keys and Buttons are very similar to Org.  The
> outliner (KOutline) is more powerful than Org, but not integrated with
> export capabilities to other formats (I think there is a way of
> exporting an outline to Org).  Something that Org does not have is
> browsing capabilities for Object Oriented languages.  This is an add-on
> (for C++ ?) in Hyperbole (search for OO-Browser).  Since I retired, I
> don't do much programming, so Org's project management has been more
> interesting to me.
>
> It's nice to see that it's actually still being developed by Bob.

Thanks for all the interesting facts about hyperbole. I hadn't looked at
the package source code info yet, and didn't know that this is all the
work of one person. I also thought hyperbole was more recent...

It certainly has some interesting stuff. In what way is KOutline more
powerful than Org? Do you think there is any useful feature of KOutline
that could be incorporated into Org?

So far I've been able to find a couple of practical uses for this
package in my workflow. The whole window control system is very
powerful, although it would have been better if it had been a single
separate package, IMHO.

Implicit links have a lot of potential. For example, I've managed to
define some buttons for LaTeX, which recognize LaTeX commands and
environments and lead to the local TeX live documentation or
tex.stackexchange.org. It's like giving a LaTeX document a sort of hover
help. This could also be done in Org, by defining some patterns as
implicit buttons to lead to Org info pages.

Best regards,

Juan Manuel 

Re: About 'inline special blocks'

[Juan Manuel Macías]

Max Nikulin writes:

> If alternative text for images and description of
> links are not convincing [...]

It does convince me, Maxim, that's why I told you in my previous message
that you were right in that example you had put about the alternate
text. And my question was (and still is) if you consider that a scenario
of this type, where the attributes are part of the content and not the
output format (and the latter happens in 90% of the cases) could occur
in the inline special blocks. If so, then I'm fine with inline special
blocks supporting attributes. But in my opinion this data should somehow
go outside the paragraph. Or be hidden as in the links.

I still think, however, that the attributes are unnecessary for inline
special blocks. I can't find any examples where they might be needed and
not something that is resolved at the global style level[1] or via
export filter. But I'm open to considering examples and use cases.

[1] There are cases in LaTeX of commands with more than one argument,
e.g. \foreignlanguage{lang}{content}, \textcolor{color}{content} and
the like. But even those can be simplified from the preamble by defining
macros with a single argument. And in Babel you can also do something
like \babeltags{de = german} and write \textde{text in german}.

The csquotes package is an extreme case, where there are intra-paragraph
commands that take optional arguments to \cite and punctuation, but I
think org-cite would be more appropriate in these cases:

\foreigntextquote{lang}[cite][punct]{text}

Best regards,

Juan Manuel 

Re: Org and Hyperbole

[Juan Manuel Macías]

Hi all,

Thank you very much for your comments and contributions in this thread
about Org & hyperbole, which have helped me a lot to position myself.

Certainly, for the short time I've been using hyperbole, it has me
baffled. It's like someone grabbed all the tools that could be useful
ten minutes before the zombie apocalypse starts. There's all the buttons
stuff, but also a feature to expand regions in a style similar to the
expand-region package, which I use a lot, by the way. And also features
to write emails, store contacts, execute searches, a buffer and frame
control system (this in particular is what most caught my attention
about hiperbole and what I am using the most, since it has some very
useful functionalities). The implicit and explicit buttons system is
certainly powerful, but I don't think it will surprise the average Org
user much in this regard.

I think that Eduardo Ochs's description ("Hyperbole is meant to be used,
not to be hacked") is quite accurate. On the other hand, I find the
hyperbole menu (C-h h) very confusing and ugly. I think it would have
gained in cleanliness if they had used transient.

It seems that the hyperbole developers put a commendable and honest
effort into introducing hyperbole to users. But I perceive that
something is failing in the communication. I suspect that hyperbole is
an attempt to establish synaptic relationships between Emacs documents
and buffers. But that is also what is sought with Org. Without wishing
to make comparisons (because, as I say, my knowledge of hyperbole is
extremely limited) I would say that there is an important difference
between org and hyperbole. Both are huge, and both are complex, and both
are packed with features. But in Org there is a coherent and consistent
language that ties everything together: once you learn how to ask for a
glass of water in the org dialect (something you can do from day one),
it doesn't take long to start more complex conversations. In hiperbole I
don't just see that language that gives consistency to everything, that
"org-style". Or at least it's not so obvious to me. But I'll keep giving
it a chance. The whole window configuration control part is extremely
interesting to me.

Best regards,

Juan Manuel 

Re: About 'inline special blocks'

[Juan Manuel Macías]

Max Nikulin writes:

Hi Maxim,

Max Nikulin writes:

> I would like to stress that styles can not be a rescue in some
> important cases. Let's leave aside ad hoc final tuning of formatting.
> In the case of HTML export there are still  and
>  attributes that are namely
> per-object, not part of style.

You are right, but my question is: Could there be a similar use case
within inline special blocks? Keep in mind that this (for now,
hypothetical) element type would be intended only for very short
segments of text within the paragraph. I don't find a scenario where
it's worth overloading that with options and attributes, IMHO.

I believe that direct formatting (as a rule of composition and not as an
exception), which comes ---I suppose--- from the use and abuse of word
processors, is the great cancer for the consistency of the documents,
where a guiding style and a series of constants must prevail. Of course,
I do not deny that it is often necessary to do a post-process and adjust
exceptions. There are always exceptions. In the case of LaTeX and
ConTeXt, TeX is powerful enough to deal with exceptions also at a high
level, due to its high degree of automation. And LuaTeX, even more so. A
simple example to automatically adjust the width of the caption in
figures with a simple lua function in LuaLaTeX:

#+begin_src latex
\begin{luacode*}
  function caption_width ( text )
  text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
  text = string.gsub ( text, "(\\caption{.+})", 
"\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
  return text
  end
\end{luacode*}
\newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}
\AtBeginDocument{\CaptionAutoWidth}
#+end_src


However, note that I speak in general terms. It is difficult to get rid
of manual intervention one hundred percent. But the question is whether
it's worth adding fine-tuning options to an element as "specialized" as
inline special blocks. Of course, LaTeX is more flexible and you can
always change a variable on the fly. You can do something like:

#+begin_src latex
\definecolor{foo}{HTML}{FF}
\definecolor{var}{HTML}{7CFC00}
\def\mycolor{foo}
\newcommand\mytextcolor[1]{%
  \textcolor{\mycolor}{#1}}
\begin{document}
lorem \mytextcolor{ipsum dolor}
\def\mycolor{var}
lorem \mytextcolor{ipsum dolor}
#+end_src

html/css seems more rigid and I'm not that familiar with it. Perhaps
there is more uses case where the existence of ad hoc attributes and
options would be justified? And, in any case, how to implement it
without the paragraph becoming unreadable? The solution that Ihor
commented on in a past post of using identifiers for each inline block
would be fine (and maybe it could be used also for the attributes of the
links within the paragraph).

>> in html:
>> contents>
>
> Concerning  vs. , is it the same for
> assistive technologies like screen readers to add
> text (or text) and  class="strong">text with "font-weight: bolder;" in CSS?

"contents>": it was my confusion, sorry. I already explained
it here: https://list.orgmode.org/8735g0tnoh@posteo.net/

Best regards,

Juan Manuel 

Org and Hyperbole

[Juan Manuel Macías]

Hi,

I've been intrigued with GNU Hyperbole for a while. I'm reading the
documentation and trying it out a bit. It seems that its button system
is very powerful. But Org links are also powerful (and exportable), and
can be extended outside of Org docs. It seems that hyperbole offers some
cool stuff that Org also has. And other things that are not in Org. I
find some parts a bit confusing. I wonder if anyone is using hyperbole
with Org and can put here some minimal workflow example where both
complement each other in some way. Just in case I'm missing something
useful...

Best regards,

Juan Manuel 

Re: About 'inline special blocks'

[Juan Manuel Macías]

Hi, Christian,

Thanks for your comments.

Christian Moe writes:

> Hi,
>
> This makes sense to me.
>
> Note: For the html output in your example, I expect you don't mean
> contents>, but contents. That
> would give the desired custom style controle of the output, and would
> parallel the behavior of special blocks.

You are absolutely right, it is my fault. These days I'm doing a work
with a lot of xml, and I've mixed things up in my head :-). In html the
expected form is as you say. Apologize for the confusion.

> If "inline special blocks" will be able to nest, they will have an
> advantage over org macros, which cannot.
>
> Apart from nesting, an org macro could do the same job, but less
> elegantly. The suggested inline syntax would not require commas to be
> escaped in the contents. And it would be somewhat more concise and far
> more legible, as illustrated in the below example (with working macros,
> imagined inline special blocks, and a CSS implementation):
>
> #+begin_example
> #+macro: fmt @@html: class="$1">$2latex:\$1{$2}odt: text:style-name="$1">$2@@
> #+html_head: .highlight {background-color: yellow;}
> #+html_head:.smallcaps {font-variant: small-caps;}
>
> This is some {{{fmt(highlight, highlighted text)}}} and this is some
> {{{fmt(smallcaps, text in small caps)}}}.
>
> This is some %[highlight]{highlighted text} and this is some
> %[smallcaps]{text in small caps}.
> #+end_example

I have used macros a lot in the past for these purposes. But the problem
of having to escape commas and the somewhat confusing (and ugly) syntax
of macros has led me to rarely use them now. Links have been a good
replacement for me, but they still have their limitations (the most
important, as Ihor commented, not being able to include a link within
the description. But we can't put footnotes either). I actually think
that inline special blocks could be tremendously useful and versatile.
And, in syntactic terms, an important point in favor of Org against
Markdown, which if I'm not mistaken does not have anything similar (I
hardly use md, so I'm not very aware).

Best regards,

Juan Manuel

Re: Keybinding doubt about ARG

[Juan Manuel Macías]

Bruno Barbier writes:

> But, you can easily define your own command.
>
> (defun my-scroll-up-of-1 ()
>   (interactive)
>   (scroll-up-command 1))
>
> (define-key global-map (kbd "M-n") 'my-scroll-up-of-1)

Or simply doing something like:

(define-key global-map (kbd "M-n") (lambda ()
 (interactive)
 (scroll-up-command 1)))

Best regards,

Juan Manuel

Re: About 'inline special blocks'

[Juan Manuel Macías]

To add some ideas that have been occurring to me these days...

I am more and more convinced that inline special blocks, by their
nature, should not support fine tune options or anything like
attr_latex, attr_html, etc. like its older brothers, as it would produce
an overly complicated syntax. Big brothers are independent of the
paragraph and there it makes sense to add lines with attr_latex, etc.,
since it is a line-oriented syntax. Bringing that into the paragraph is
unnecessarily overloading the paragraph and breaking the social contract
of lightweight markup, where paragraphs should still look like
paragraphs.

Another argument against possible fine-tuning within inline special
blocks, for export purposes, is that (in my opinion) direct formatting
is a practice that should be avoided as much as possible in a document.
A document with a lot of direct formatting is an inconsistent document.
In html, all possible formatting should be controlled by style sheets;
in LaTeX, by (re)defining macros, commands and environments in the
preamble or in a .sty file; in odt using character styles.

Perhaps if we detach special blocks from fine-tuning possibilities we
lose some (export) flexibility, but we gain in a clearer implementation
of these elements and keep Org aseptic about the output format. And in
any case, if someone needs a fine-tuning in a certain case, there are
always the export filters. Or it can be implemented in a similar way to
inline tasks, with a default format function (for html, latex, etc),
which can be changed via a defcustom.

Starting from that, a syntax like this in Org:

%[name]{contents}

Would produce in LaTeX, by default:

\name{contents}

in html:

contents>

in odt:

contents

and so on.

In short, I think it would be enough to simply implement something like
this.

Best regards,

Juan Manuel 

[Tip] Screenshots as org links with EMMS and socat

[Juan Manuel Macías]

Hi all,

I’m writing an article about a movie, and I needed to get some
screenshots as image links inside Org. I know some package for those
things, like org-media-note, a nice library but for me it has two
drawbacks: it has, for what I need, too many bells and whistles; and
uses the mpv.el package in the background. I use the mpv player, but
through EMMS. In fact, I have all my multimedia setup in Emacs around
EMMS, and I'm too lazy to use something else. What I am looking for is,
therefore, something much simpler, EMMS-centric and "homemade". If
someone is in the same situation as me and also uses EMMS with mpv, I’m
sharing my solution here, in case it’s useful (I’ve taken some ideas
from org-media-note and mpv.el):

Socat needs to be installed first, to communicate with the mpv process
via the command line. In Arch it is in the official repositories:

┌
│ sudo pacman -S socat
└

My EMMS configuration:

┌
│ (require 'emms-setup)
│ (emms-all)
│ (emms-default-players)
│ (setq emms-player-list '(emms-player-mpv))
└

And these two variables are for socat communication:

┌
│ (setq emms-player-mpv-ipc-method 'ipc-server)
│ (setq emms-player-mpv-ipc-socket "~/.emacs.d/emms/mpv-ipc.sock")
└

The directory to save the screenshots:

┌
│ (defvar my-screenshot-dir "/path/to/screenshot/dir/")
└

This function returns the formatted timestamp and path of the current
mpv process:

┌
│ (require 'org-timer)
│ (defun my-mpv-format-timestamp-and-path ()
│   (let* ((timestamp-command (shell-command-to-string
│ "echo '{ \"command\": [\"get_property\", \"playback-time\"] }' | 
socat - ~/.emacs.d/emms/mpv-ipc.sock"))
│(path-command (shell-command-to-string
│   "echo '{ \"command\": [\"get_property\", \"path\"] }' | socat - 
~/.emacs.d/emms/mpv-ipc.sock"))
│(timestamp (org-timer-secs-to-hms (round
│   (cdr
│(car
│ (json-read-from-string 
timestamp-command))
│(path (cdr
│   (car
│(json-read-from-string path-command)
│ (format "%s --- %s" path timestamp)))
└

And, finally, the function that inserts the screenshot at point as an
org image link:

┌
│ (defun my-mpv-put-screenshot-on-org ()
│   (let* ((time (format-time-string "%d-%m-%y-%H-%M-%S"))
│(screenshot-file-name (format "fotograma-%s.png" time))
│(screenshot-final (expand-file-name screenshot-file-name 
my-screenshot-dir)))
│ (start-process-shell-command 
│  "screenshot" nil
│  (format
│   "echo \"screenshot-to-file %s\" | socat - 
\"~/.emacs.d/emms/mpv-ipc.sock\""
│   screenshot-final))
│ (insert (format "#+media: %s\n" (my-mpv-format-timestamp-and-path)))
│ (insert (format "[[file:%s]]" screenshot-final
└

A short demo video: https://cloud.disroot.org/s/6zrGYxkKT67kFGx

Best regards,

Juan Manuel

Re: About 'inline special blocks'

[Juan Manuel Macías]

Ihor Radchenko  writes:

> While arbitrary markup can indeed be introduced using our current link
> syntax, there is one important limitation of links:
>
>  *** link description cannot contain other links ***
>
> If one seriously tries to extend Org syntax with custom markup elements,
> nested markup will not be possible. And we do not want to change Org
> links to allow other links inside.
>
> Inline special blocks may not have such limitation if we allow special
> blocks to be nested.

  +1.

This seems to me a *very* important point.

Best regards,

Juan Manuel 

Re: Utility of description lists

[Juan Manuel Macías]

Hi,

Cletip Cletip writes:

> - they are made implicitly to make a "key :: value" couple, which can
> be convenient

Leaving aside typographical considerations, what LaTeX calls, for
example, "description" (because Org is totally typographic agnostic), I
find this property that you mention very useful. For example, for my
translation (work in progress) of Homer's Odyssey, I am writing a
descriptive list with the Homeric formulas in Greek (key) and how I
translate each specific formula (value), since they are terms that are
repeated a lot in the text. With a bit of Elisp I can later recover
some specific formula from the list.

See: https://list.orgmode.org/87bl5tzof2@posteo.net/

Then, when I publish the translation (if I ever finish it ;-)), that
list will be translated in typographic terms, into a glossary of
homeric formulas.

Best regards,

Juan Manuel 

Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Ihor Radchenko writes:

> The original proposal by Eric Schulte:
> https://list.orgmode.org/4bffee4f.5010...@ccbr.umn.edu/
 Maybe we should allow either exporting just the headlines of the
 org-mode file or exporting the entire org-mode file -- possibly after an
 ASCII export -- this would have the effect of prefixing every line in
 the org-mode file behind a comment *except* for the tangled source-code
 blocks.
>
> Clearly, the "possible after an ASCII export" dropped somewhere in the
> middle.

I see... Thanks for the clarification! So it seems that the current
behavior of ':comments org' is no more than a fluke, rather than
intentional. One possibility that occurs to me, instead of adding a new
value to ':comments', would be to 'return' ASCII export for the
:comments org value, and leave it that way by default. And add an
option, of course, for recover the old value. It could be done from
org-babel-process-comment-text, and then redo some lines in
org-babel-tangle-single-block, as we discussed in the other mail. I
think it would be cleaner that way, but I don't know if this would be
too groundbreaking...

Best regards,

Juan Manuel 

Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Ihor Radchenko writes:

> I think that the existing code can be improved. Relying on the
> undocumented behavior of (org-back-to-heading) is not ideal. Not to
> mention code blocks before first headline.
>
> It would be great if you rewrite the existing code to suite both the
> defaults and the proposed behavior.

Yes, I agree that this needs a more robust approach. Also, I've noticed
that the patch I've proposed has a rather silly bug: replacing the
second `match-end 0' with `match-beginning 0' naturally causes
intermediate code blocks to be exported as comments (!). Returning it to
`match-end 0' everything is OK, but the present approach is still
tricky.

I'm going to see if I can try something cleaner these days. Ideally,
everything should be controlled from org-babel-process-comment-text...

On the other hand, I have a curiosity. I understand that the behavior of
the `:comments org' option should be left intact to ensure backwards
compatibility. But I've always wondered if there is any use case where
this value, as it behaves, might be practical. I don't quite understand
how useful all the Org metadata in the comments of the tangled file can
be. The expectation with `:comments org' is that only the content of the
Org document will be rendered (as comments), but not its metadata, that
all they do is unnecessarily fatten up the source file. I'm thinking,
for example, of headers with lots of properties. or comment blocks,
which would be visible in the tangled source file:

┌
│ ;;   Header
│ ;;   :PROPERTIES:
│ ;;   :A_LOT_OF: properties
│ ;;   :END:
│ 
│ ;; #+begin_comment
│ ;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit 
tempor tellus.
│ ;; Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, 
convallis nec,
│ ;; purus. Cum sociis natoque penatibus et magnis dis parturient montes, 
nascetur ridiculus
│ ;; mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. 
Cras placerat
│ ;; accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl.
│ ;; #+end_comment
└

Best regards,

Juan Manuel 

Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Hi, Rudolph,

Rudolf Adamkovič writes:

> Oh, I see.  Thank you for the explanation.  I can see myself using such
> new tangle comments all the time!  But then, I use UTF-8 and not the
> standard 7-bit ASCII for my Org documents.  Hence, I would want to see
> ':comments plain' or ':comments plain-text' instead.

What you comment makes sense, because `ascii' can lead to confusion. I
chose the term `ascii' because the backend used to convert the text is
called `ascii', although if I evaluate something like

(org-export-string-as "αβγδ" 'ascii t)

the result is utf8.

I think it might be a good idea to use `plain' for the value name, as
you say, instead of `ascii'...

Best regards,

Juan Manuel 

Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Hi, Rudolph, thanks for your comments,

Rudolf Adamkovič writes:

> Juan, hi!
>
> I do not understand the meaning of ASCII.  How will such comments look
> like?  Will they include at least the file name?  If so, those can
> contain Unicode characters, right?

The main motivation for proposing this new option is that when I choose
the ':comments org' option, all the Org metadata that is close to the
code block in my org file are 'preserved', so comments in the source
file are somewhat awkward to read (as simple comments). My idea is that
with this new option the comments pass as plain text, without property
drawers, keywords, etc.

For example, that a header like this:


* Variables
  :PROPERTIES:
  :foo:  var
  :END:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus. Donec pretium posuere tellus.


does not pass to the source file like this:


;; Variables
;;   :PROPERTIES:
;;   :foo:  var
;;   :END:
;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
;; hendrerit tempor tellus. Donec pretium posuere tellus.


but in this way:


;; Variables
;; ==
;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
;; hendrerit tempor tellus. Donec pretium posuere tellus.


Best regards,

Juan Manuel

Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Hi, Ihor, thanks for your comments,

Ihor Radchenko writes:

> Wouldn't it be better to supply a customization for
> org-babel-process-comment-text instead?
>
> I do not feel that per-src-block control on the comment type makes much
> sense here.

My first approach was actually to define some options for
org-babel-process-comment. But I noticed that a header with properties,
for example:

* Header
  :PROPERTIES:
  :FOO:  var
  :END:

is interpreted as:

;; Header
;; :FOO: var

I think the culprit is the '(match-end 0)' in
org-babel-tangle-single-block:

...
(comment
  (when (or (string= "both" (cdr (assq :comments params)))
(string= "org" (cdr (assq :comments params
;; From the previous heading or code-block end
(funcall
 org-babel-process-comment-text
 (buffer-substring
  (max (condition-case nil
   (save-excursion
 (org-back-to-heading t) ; Sets match data
 (match-end 0)) ;; <=
 (error (point-min)))
   (save-excursion
 (if (re-search-backward
  org-babel-src-block-regexp nil t)
 (match-end 0)  ;; <=
   (point-min
  (point)
...

So I couldn't think of any other solution than to put the change there,
so as not to break backwards compatibility. But it is a somewhat tricky
solution...

Best regards,

Juan Manuel 

[Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Juan Manuel Macías]

Hi,

With this new value, comments are passed to the source file as plain
text, without the org metadata (keywords, property drawers, etc.).

As usual, feedback and suggestions for this patch are greatly appreciated.

Best regards and happy weekend,

Juan Manuel

>From 414e0b3a18abca34bc47f07e55debec0910d4728 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Fri, 10 Jun 2022 20:12:37 +0200
Subject: [PATCH] lisp/ob-tangle.el: add the `ascii' value to the `comments'
 head. arg.

* (org-babel-tangle-single-block): With the value ascii the comments
are passed as plain text. This is useful for removing all org
metadata from the source file's comments.
---
 lisp/ob-tangle.el | 53 ---
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 6685a1599..aed241416 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -525,23 +525,42 @@ non-nil, return the full association list to be used by
 	  (run-hooks 'org-babel-tangle-body-hook)
 	  (buffer-string
 	 (comment
-	  (when (or (string= "both" (cdr (assq :comments params)))
-		(string= "org" (cdr (assq :comments params
-	;; From the previous heading or code-block end
-	(funcall
-	 org-babel-process-comment-text
-	 (buffer-substring
-	  (max (condition-case nil
-		   (save-excursion
-			 (org-back-to-heading t) ; Sets match data
-			 (match-end 0))
-		 (error (point-min)))
-		   (save-excursion
-		 (if (re-search-backward
-			  org-babel-src-block-regexp nil t)
-			 (match-end 0)
-		   (point-min
-	  (point)
+	  (cond ((or (string= "both" (cdr (assq :comments params)))
+		 (string= "org" (cdr (assq :comments params
+		 ;; From the previous heading or code-block end
+		 (funcall
+		  org-babel-process-comment-text
+		  (buffer-substring
+		   (max (condition-case nil
+			(save-excursion
+			  (org-back-to-heading t) ; Sets match data
+			  (match-end 0))
+			  (error (point-min)))
+			(save-excursion
+			  (if (re-search-backward
+			   org-babel-src-block-regexp nil t)
+			  (match-end 0)
+			(point-min
+		   (point
+		((string= "ascii" (cdr (assq :comments params)))
+		 ;; From the previous heading or code-block end
+		 (let ((org-babel-process-comment-text
+			(lambda (str)
+			  (org-export-string-as str 'ascii t
+		   (funcall
+		org-babel-process-comment-text
+		(buffer-substring
+		 (max (condition-case nil
+			  (save-excursion
+(org-back-to-heading t) ; Sets match data
+(match-beginning 0))
+			(error (point-min)))
+			  (save-excursion
+			(if (re-search-backward
+ org-babel-src-block-regexp nil t)
+(match-beginning 0)
+			  (point-min
+		 (point)))
  (src-tfile (cdr (assq :tangle params)))
 	 (result
 	  (list start-line
-- 
2.36.1

Re: Org-attach for a directory

[Juan Manuel Macías]

Cletip Cletip writes:

> Thank you for your answer. 

You're welcome.

> Your answer seems perfect to answer my question: I modify a function
> of org-mode, and it allows me to attach folders and files to a
> heading. 
> Unfortunately, it doesn't work (probably because of my version of
> org-mode I guess)
>
> I have the following error:
> make-directory: The file exists:
> /home/user/sharedDirectoryPrivate/notes/braindump/.data/11e080/1b-7896-4f20-a24a-b9f45337e940

I don't know all the details of your problem. But if it gives you an
error saying The file exists, I would say that the cause is that the
directory you want to copy already exists in your attach folder. Could
it be that in your case? Note that the 'copy-directory' function does not
overwrite copied directories.

> Just to make sure I understood correctly: you can, with the "copy"
> method and the simple modification of the "org-attach-attach"
> function, attach a folder to a heading of org mode? 
> If so, this is exactly what I am looking for, and this would be a
> great help.

Exactly. I wrote a new version of org-attach-attach, modified that part,
as I told you, and added it via advice-add (with :override keyword) so
that it overrides the old function.

> To clarify my second question, I would like to have a folder system
> with org-mode, and therefore only use org-attach to arrange my
> documents, exactly like you. 
> Could you describe your workflow in more detail? Your use of tags for
> example, do you put dates, etc.

Now I have less time than I would like to go into the details, but
perhaps some reflections that I shared here may be useful to you:

https://list.orgmode.org/875yms7wys@posteo.net/

The strong point of my approach is to think of Org nodes and not the
classic directory/file scheme. But for that to work well you must rely
on a system that ensures a semantic search through the nodes. For me the
answer is org-ql (and if you're a helm user, you have helm-org-ql too).
Basically it's turning all your Org documents into a human-readable
database, where searches can be narrowed down by tags, status, content,
etc.

Another important point is that this scheme works wonderfully well with
org-capture.

Best regards,

Juan Manuel 

Re: Org-attach for a directory

[Juan Manuel Macías]

Hi,

Cletip Cletip writes:

> My question is in the object : can we attach a directory to a heading?
> If yes, how, if not, why. Can we solve the problem?

I have in my init the following modification to the org-attach-attach
function so that I can copy a directory. I have replaced the line

((eq method 'cp) (copy-file file attach-file))

with this:

((eq method 'cp) (if (file-directory-p file) 
 (copy-directory file attach-file)
   (copy-file file attach-file)))


You can override the old function with advice-add:

(advice-add 'org-attach-attach :override 'my-new-org-attach-attach)

> Subsidiary question:
> Can we use org-attach as a filesystem? 
> Thanks in advance for your future answers

Can you please elaborate more? In my case, I use org-attach almost as a
replacement for my folder system (ie org nodes have come to replace
directories, and many nodes have a folder attached); I access the nodes
via org-ql/helm-org-ql (https://github.com/alphapapa/org-ql). It's very
productive.

Best regards,

Juan Manuel 

Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> The default switches syntax was originally designed for code block and
> it generally supports continuous numbering across several subsequent
> code blocks or starting the numbering from certain line. Will such
> features be useful for verses?
> [...]
> Do you know if customizing :lines 5 to something other than 5 is often
> needed? Maybe it can be an export option?

There are some differences between code numbering and verse numbering,
which is a convention used in Humanities and used by wikipedia and other
sites as well:

- The first verse is never numbered;

- White lines are not numbered;

- Numbering is added in a sequence, never continuously. The sequence is
  generally 5, but it is common to find sequences of 3, 10 or other
  digits (with that I answer your second question).

All of these features are performed in LaTeX by the 'verse' package, and
in the patch I submit for LaTeX I simply passed the options to these
package on LaTeX export. See:

(info (org)Verse blocks in LaTeX export)

The :lines attribute accepts any integer for the sequence: :lines 7
:lines 10, etc. :lines t defaults to 5. With this html patch I tried to
keep that same syntax. To format the verse numbering in html I was loosely
inspired by the way wikipedia does it.

I think line numbering is an idiosyncratic case and should not be
confused with standard line numbering as understood by Emacs linum-mode
or any other text editor. What I don't know is if the switches code
numbering could be reused in that peculiar case. An interesting
functionality could be to choose at which number the quoted fragment or
poem begins (because it is common to quote fragments of long poems. In
the LaTeX version this is obtained by :latexcode \setverselinenums{}{}

Nota bene: I understand that all these functionalities for verses are,
at the moment, a minority in Org, since Org has a small number of
Humanities users (here in Spain I try to gain followers among my
colleagues, but it is an arduous task). In any case, I think features
like this can attract more Humanities users...

Best regards,

Juan Manuel 

Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Sounds reasonable. However, a more consistent way to handle line numbers
> would be using switches, like what we do in EXAMPLE blocks. See
> org-element-example-block-parser and 12.6 Literal Examples section of
> the manual.

(I didn't remember that I had sent this patch...).

I'll take a look at the function you mention, when I have some time. In
any case, keep in mind that there are some conventions in verse
numbering: the white lines (separation between stanzas) are never
numbered and there is a sequence: 5 (first verse alwais remains
unnumbered) ... 10 ... 15 ..., which can be chosen using the :lines
attribute. :lines t defaults to a sequence of 5 verses. I chose this
syntax to follow the syntax of verse numbering with output to LaTeX
(another patch of mine that is already included in Org. In that case,
the 'verse' LaTeX package is used).

Verse numbering is a special case. In fact, a long time ago I wrote this
package: https://gitlab.com/maciaschain/org-verse-num

Best regards,

Juan Manuel 

Re: # Comments export

[Juan Manuel Macías]

Eric S Fraga writes:

> I use drawers for this and then have specific processing of different
> types of drawers, depending on target.
>
> For instance, I might have :note: drawers (similar to inline tasks) with
> the following processing (for odt export; similar for LaTeX):
>
> --8<---cut here---start->8---
> (setq-local org-odt-format-drawer-function
> (lambda (name contents)
>   (if (string= name "note")
>   (progn
> (format " text:background=\"#00\">%s" contents)
> --8<---cut here---end--->8---
>
> (progn because I used to do more in there...)

I use a special type of footnote, which is exported to LaTeX as pdf
annotations (with the pdfannotate package) and to odt as comments. The
use of footnotes allows me to put comments and annotations within the
paragraph:

https://list.orgmode.org/877de55cjf@posteo.net/

Best regards,

Juan Manuel 

Re: [tip] org-publish to work with (very) large books

[Juan Manuel Macías]

Ihor Radchenko writes:

> Yet, the information is surprisingly scattered. I was unable to find a
> single guide on the available possibilities. Mostly unanswered or
> partially answered questions from users.

Yes you're right. In addition, what I have been testing is not a panacea
either. In general, when it comes to long and complex documents, there
is no other solution than to arm yourself with patience, launch
asynchronous processes and dedicate yourself to doing another task while
LaTeX does its job. And, of course, trust that there are no errors. The
only advantage to debugging the code of a LaTeX document is how much you
learn about LaTeX and TeX in the process. But many times it is something
that can become frustrating, and the log file can be more cryptic than a
Sumerian inscription. The cause/effect relationship in LaTeX errors can
be the most surrealistic things in the world :-D.

Luckily, there's texstackexchange, where the LaTeX core and LaTeX
package developers themselves write, which is an endless source of
help...

> Do you have anything from LuaTeX in mind that could improve the current
> ox-latex pdf export when LuaTeX is used as the TeX engine?

I've thought about it sometimes, but haven't been able to find anything
concrete for Org. LuaLaTeX cares that a well-formed LaTeX document is
delivered to it, and Org already does that very well. In LuaTeX you can
insert lua code between La(TeX) code. For example:

\begin{luacode}
local x = "foo"
local y = "bar"
tex.print (x .. " and " .. y)
\end{luacode}

But in Org we have all the power of Babel: Org wins.

In LuaTeX you can write functions as pre-process filters, and associate
these functions with different callbacks. For example, there is a
callback_input_buffer, but we already have something like that in Org,
and with a larger scope and not limited to output to LaTeX.

In general, the advanced features of LuaTeX are more typographical and
micro-typographical in nature, and I guess they are of little use to
Org. For example, I recently wrote this function that highlights in red
the text that is in a language other than the main language of the
document (in my case, Spanish, langid 80). Act low-level on the line
node, just before LuaTeX does the line break to create the paragraph:

\directlua{
w = node.new("whatsit","pdf_literal")
w.data = "1 0 0 rg"
z = node.new("whatsit","pdf_literal")
z.data = "0 g"
function other_langs(h,c)
   for n in node.traverse_id(0,h) do
  for x in node.traverse_id(node.id("glyph"),n.head) do
 if x.lang < 80 or x.lang > 80 then
local before, after = node.copy(w), node.copy(z)
n.head = node.insert_before(n.head,x,before)
n = node.insert_after(n,x,after)
 end
  end
   end
   return h
   end

luatexbase.add_to_callback('post_linebreak_filter', other_langs, 'other_langs')
}

According to the LuaTeX manual, "TeX’s nodes are represented in Lua as
userdata objects with a variable set of fields". What this function does
is simply manipulate the .lang field of the glyph nodes in an hlist node
(the line with its components).

Functions associated with the post_linebreak_filter callback are very
useful and productive, but from a purely typographical point of view.

At the pure LaTeX level, LuaLaTeX is not very different from LaTeX. Any
LaTeX document, generally speaking, can be compiled with LuaLaTeX, as
long as it is in utf8 and does not contain some pdfLaTeX- or
XelaTeX-specific commands. Today the compatibility between engines is
reasonably good, and more and more packages designed exclusively for
LuaTeX are uploaded to CTAN. The TeX ecosystem is notorious for its
slowness and conformism, but LuaTeX is meant to be the natural
replacement for pdfTeX. Sometime in the uncertain future :-)

Best regards,

Juan Manuel 

Re: how to export an org file, to 2 different locations (in to different formats)

[Juan Manuel Macías]

Uwe Brauer writes:

> I have also to confess, that I usually am I bit hesitant to use
> defadvice since it changes the vanilla function, and might cause
> problems, but maybe this is just me.

You are absolutely right, and I confess that I would have the same
precautions :-). Also, the defadvice code is very poorly tested, and is
likely to cause some collateral kills... If you need it for specific use
cases, you can try evaluating it only for specific sessions, instead of
leaving it in your init file. Or make a mode that turns it on or off.

Best regards,

Juan Manuel 

Re: [tip] org-publish to work with (very) large books

[Juan Manuel Macías]

Ihor Radchenko writes:

> A more advanced approach would be using
> \include + \includeonly instead of \input:
>
> https://web.archive.org/web/20160627050806/http://www.howtotex.com/tips-tricks/faster-latex-part-i-compile-only-parts/

Yeah, \include and \includeonly save the .aux files for each part.
However, I think choosing between \input, \include or \includeonly is
not the important part here. I usually use \input for convenience,
because I have not needed in the work done to make references between
parts. You can choose any of the options, according to needs. Also this
procedure can be made more complex. For example, sometimes (when it
comes to a bilingual edition with facing pages), I also start from
precompiled documents together with tex (subdocument) files. The
precompiled documents are placed on the odd and even pages of the
bilingual part:

https://i.imgur.com/Jbjutmf.jpg

> Also, FYI:
>
> https://web.archive.org/web/20160712215709/http://www.howtotex.com:80/tips-tricks/faster-latex-part-iv-use-a-precompiled-preamble/

Using a precompiled preamble can improve compilation sometimes, but
other times it's not worth it. Also, I use a lot of code in Lua. When it
comes to a very complex preamble, with lots of code, it is usually more
practical to create a .sty file (that is, a package, in LaTeX parlance).
The difference is that I prefer to use org and org-babel-tangle instead
of the 'official' LaTeX suite docstript for writing packages, which I
find horribly hard, especially compared to the ease of Org :-)

Improving performance and compile time in TeX is an old topic, and there
are a few tricks here and there. But TeX is what Emacs is, both are
venerably old; and both are single-thread. There are more ''modern''
approaches, like Patoline or Sile (of course, based heavily on TeX,
which is the father of everything). Sile, especially, is very
interesting and from time to time I like to play with it. The problem
with these new projects is that they don't have the LaTeX package
ecosystem, and they are poorly documented. Well, Sile in particular is
the work of a single person. Links:

https://patoline.github.io/#documentation

https://sile-typesetter.org/

As for LuaTeX, which is the state of the art today in the TeX ecosystem,
it is nothing more than TeX + a lua interpreter + the implementation of
advanced features from previous engines like pdfTeX and the experimental
Omega/Alef. It has the advantage that it is a scriptable TeX (TeX
primitives can be controlled by Lua scripts, and truly amazing things[1]
can be achieved with very little effort[2]); it has the disadvantage that
the scripting language is Lua. The ideal would have been a Lisp-TeX ;-)

[1] The chickenize package contains many examples, some of them somewhat
absurd and not very useful in
appearance: https://www.ctan.org/pkg/chickenize

[2] https://tug.org/TUGboat/tb31-3/tb99isambert.pdf

>> The moment one breaks down a large piece of work into specialized parts,
>> one gains more control over that piece of work. And org-publish helps
>> manage all of that. It is about managing a large book as a website (via
>> org-publish). In short, the combination of org-publish, projectile and
>> latexmk is quite productive for me in this type of work.
>
> This is a bit confusing. You still keep the book in a single giant Org
> file. It indeed does not mean anything given that we can always narrow
> to subtree, but I fail to see where you break the book into specialized
> parts then (LaTeX performance trickery aside).

I think this is inaccurate. The book is split across multiple
subdocuments. The master file is just the 'outline' of the book.

Best regards,

Juan Manuel 

Re: how to export an org file, to 2 different locations (in to different formats)

[Juan Manuel Macías]

Uwe Brauer writes:

> When I run it I obtain 
> if: Symbol’s value as variable is void: my-latex-export-path
>
> Another point is if I decide to export it to ods, I need to modify that
> advice, but I agree the new function is more convenient.

You must add the variables to the document as local variables, at the
end of the document, like this:

# Local Variables:
# my-latex-export-path: "~/path/myfile.tex"
# my-html-export-path: "~/path/myfile.html"
# End:

But (it's important, I didn't tell you, sorry) before you must globally
define the variables with nil value, so that you don't get an error in
other documents:

(setq my-latex-export-path nil
  my-html-export-path nil)

With this 'define-advice' procedure you don't need the other code I gave
you. You can export in the usual way, using the dispatcher. The only
difference is that in any document where these variables exist, the
resulting file will be saved in the directory/name specified in the
variables, depending on whether you export to latex or html.

To add more cases, like odt, simply:

(1) you define a new variable:

  (setq my-latex-export-path nil
my-html-export-path nil
my-odt-export-path nil)

and locally:

# Local Variables:
# my-latex-export-path: "~/path/myfile.tex"
# my-html-export-path: "~/path/myfile.html"
# my-odt-export-path: "~/path/myfile.html"
# End:

(2) And you add a new condition at the end of the define-advice:

[...]
(if (and my-latex-export-path
 my-html-export-path
 my-odt-export-path)
(cond ((equal extension ".tex")
   my-latex-export-path)
  ((equal extension ".html")
   my-html-export-path)
  ((equal extension ".odt")
   my-odt-export-path))
  (apply old-func args)))

It means that: if those variables exist, it returns as a result the
path/name that you have specified for each case. Otherwise, the
org-export-output-file-name function is executed normally.

Best regards,

Juan Manuel 

Re: how to export an org file, to 2 different locations (in to different formats)

[Juan Manuel Macías]

Juan Manuel Macías writes:

> One (pedestrian) way to achieve it, with this function:

I think it can be done better this way, defining an advice around
'org-export-output-file-name'.

In your org file you should add these two local variables:

# my-latex-export-path: "~/path/to/myfile.tex"
# my-html-export-path "~/path/to/myfile.html"

And this is the define-advice code. It should export to one or another 
path/file every
time you export your document to LaTeX or html. I haven't tried it much:

(define-advice org-export-output-file-name (:around (old-func extension &rest 
args))
  (setq old-func (lambda (extension &optional subtreep pub-dir)
   (let* ((visited-file (buffer-file-name (buffer-base-buffer)))
  (base-name
   (concat
(file-name-sans-extension
 (or
  ;; Check EXPORT_FILE_NAME subtree property.
  (and subtreep (org-entry-get nil 
"EXPORT_FILE_NAME" 'selective))
  ;; Check #+EXPORT_FILE_NAME keyword.
  (org-with-point-at (point-min)
(catch :found
  (let ((case-fold-search t))
(while (re-search-forward
"^[ \t]*#\\+EXPORT_FILE_NAME:[ 
\t]+\\S-" nil t)
  (let ((element (org-element-at-point)))
(when (eq 'keyword (org-element-type 
element))
  (throw :found
 (org-element-property :value 
element
  ;; Extract from buffer's associated file, if any.
  (and visited-file
   (file-name-nondirectory
;; For a .gpg visited file, remove the .gpg 
extension:
(replace-regexp-in-string "\\.gpg\\'" "" 
visited-file)))
  ;; Can't determine file name on our own: ask user.
  (read-file-name
   "Output file: " pub-dir nil nil nil
   (lambda (n) (string= extension 
(file-name-extension n t))
extension))
  (output-file
   ;; Build file name.  Enforce EXTENSION over whatever 
user
   ;; may have come up with.  PUB-DIR, if defined, 
always has
   ;; precedence over any provided path.
   (cond
(pub-dir (concat (file-name-as-directory pub-dir)
 (file-name-nondirectory 
base-name)))
((file-name-absolute-p base-name) base-name)
(t base-name
 ;; If writing to OUTPUT-FILE would overwrite original 
file, append
 ;; EXTENSION another time to final name.
 (if (and visited-file (file-equal-p visited-file 
output-file))
 (concat output-file extension)
   output-file
  (if (and my-latex-export-path my-html-export-path)
  (cond ((equal extension ".tex")
 my-latex-export-path)
((equal extension ".html")
 my-html-export-path))
(apply old-func args)))

Best regards,

Juan Manuel 

Re: how to export an org file, to 2 different locations (in to different formats)

[Juan Manuel Macías]

Hi Uwe,

Uwe Brauer writes:

> Hi
>
> Currently I use 
> #+EXPORT_FILE_NAME: /home/oub/Desktop/some-stuff.html
>
> To export my org file in html format to that location.
>
> But I would also like to export it as a latex file to a different
> location, without modifying the above line, or to be more precise to add
> a different location, like
>
> 1. if export to latex use that folder
>
> 2. If export to html use this folder
>
> Anybody know about such a functionality?
>
> Thanks and regards
>
> Uwe Brauer 

One (pedestrian) way to achieve it, with this function:

(defun my-org/export-to-path (backend export-path extension)
  (org-element-map (org-element-parse-buffer) 'keyword
(lambda (k)
  (when (string= (org-element-property :key k) "EXPORT_FILE_NAME")
(let ((value (org-element-property :value k)))
  (org-export-to-file backend
  (format
   "%s%s.%s"
   export-path
   value extension)))

And then you could evaluate it inside a block in your document, with the
chosen arguments. For example:

#+EXPORT_FILE_NAME: myfile

#+begin_src emacs-lisp :exports none :eval never-export :results silent
  (my-org/export-to-path 'html "~/Desktop/" "html")
#+end_src

Best regards,

Juan Manuel 

Re: [tip] org-publish to work with (very) large books

[Juan Manuel Macías]

Ihor Radchenko writes:

> I am not sure if I understand correctly. Do you mean that you only
> preview the book parts you are currently working on via latexmk -pvc?
> What kind of more control are you referring to?

The -pvc flag means that if latexmk detects any modification to any
document involved in the current job (a subdocument, the .sty file, a
.bib file, or whatever), it reruns the appropriate builds to bring the
pdf up to date, and it only stops when everything is up to date. I can
focus that action on parts of the book by commenting or uncommenting
elements in the master file.

The moment one breaks down a large piece of work into specialized parts,
one gains more control over that piece of work. And org-publish helps
manage all of that. It is about managing a large book as a website (via
org-publish). In short, the combination of org-publish, projectile and
latexmk is quite productive for me in this type of work.

Anyway, as they say that a picture is worth a thousand words, I have
made this short example video. This is a dictionary I produced a year
ago. Each dictionary entry has its own separate bibliographic list, so I
had to manage more than 100 separate bib files. I have all these files
inside an Org document, and I create them using org-babel-tangle. The
video shows editing a field in a bib file. I've removed the build time
from the video, as the entire book is almost a thousand pages long.

https://cloud.disroot.org/s/PiSaHqWZr25GfJY

Best regards,

Juan Manuel 

Re: [tip] org-publish to work with (very) large books

[Juan Manuel Macías]

Hi Ihor and Christian,

Ihor Radchenko writes:

> Christian Moe  writes:
>
>> Do I understand correctly that the main advantage of this approach (over
>> #+INCLUDE) is the ability to continuously update preview of the whole
>> book with latexmk -pvc even if you only re-export one chapter from
>> Org-mode?
>
> I am not sure why Juan did not use include. Include would not require
> LaTeX to re-compile unchanged files. See
> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>
>> I couldn't find the :body-only publishing option in the docs ...?
>
> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>
> Best,
> Ihor
>

Sorry for not explaining the \input part in more detail. I think the
essential part here is that all the .tex files (the subdocuments) are
already created by org-publish before I compile the master document. The
master document simply stores all the subdocuments: I use
\input{subdocument.tex} instead of the org #+INCLUDE directive (not the
LaTeX \include command). The master document calls ready-made TeX files,
not Org files. And it is independent of the whole org-publish process,
which is responsible for creating only the parts of the book. This
procedure, apart from being able to compile parts of the book in real
time with latexmk -pvc, allows me to have more control over these parts.
But it makes more sense to use it when dealing with very long books. The
first time I used it was in a book of more than 1000 pages :-)

The skeleton of the process is that subdocuments are produced with
org-publish (as uncompiled tex files) and the master document is
exported to tex from org and then compiled with latexmk inside /tex
directory.

Best regards,

Juan Manuel 

[tip] org-publish to work with (very) large books

[Juan Manuel Macías]

Hi all,

- tl; dr: I describe here my workflow with org-publish to work with long
books.

—

I discovered a long time ago that `org-publish' not only works very well
for managing websites but also for working with long and complex books
with many parts, with output to LaTeX/PDF. I developed a workflow around
it that has been quite productive for me, and that I briefly describe
here in case someone finds it useful and wants to try it or modify/adapt
it to their needs. I usually use it for my typesetting work, but I think
it can also be useful for personal projects, such as doctoral theses.

First of all, each folder of my project-books has the same structure:
two subdirectories named `/org' and `/tex', for the source `org' files
and for the output `.tex' documents, respectively. And, inside the `org'
directory I include a `setup' file, an `elisp' file (for export
filters), and another `/img' directory for image files. Each `org' file
is a part of the book, and usually begins simply with the directives:

┌
│ #+SETUPFILE: xxx.setup
│ #+INCLUDE: "elisp"
└

`Org-publish' exports the subdocuments (body only!) as `.tex' documents
in the `/tex' folder, but they are not compiled.

What gets compiled is a master `.org' file, which is also inside the
`org' folder. I compile this master file using an asynchronous function
that calls `latexmk'. I put all the LaTeX configuration, the packages to
load, the (re)defined commands and macros, the necessary Lua code, etc.
in a `.sty' file that I load at the very beginning of the master
document. Subdocuments are loaded into this file by the LaTeX command
(\input), not by the org #+INCLUDE directive. So the master file usually
looks like this:

┌
│ #+LaTeX_CLASS: my-custom-latex-class
│ #+LaTeX_Header: \input{my-custom-conf.sty}
│ #+SETUPFILE: .setup
│ #+INCLUDE: "elisp"
│ 
│ * Part 1
│ ** Chapter 1
│ #+LaTeX: \input{chapter1.tex}
└

When I eval my function, `latexmk' compiles the entire book with the
`-pvc' option, which keeps the session open, and if it detects any
changes to the entire document, it recompiles and refresh the pdf view.
For example, if I edit one of the subdocuments and run
`org-publish-current-file', everything is automatically recompiled.

When I have the project folder ready, I add this to
`org-publish-project-alist' (this is an example from one of the books I
did recently):

┌
│ ("cartas-org"
│  :base-directory "~/Git/cartas/libro/org/"
│  :base-extension "org"
│  ;; Directorio para los ficheros *.tex
│  :publishing-directory "~/Git/cartas/libro/tex/"
│  :publishing-function org-latex-publish-to-latex
│  :body-only t ;; this is important!
│  :exclude "cartas-master\\.org\\|bibliografia-cartas\\.org"
│  :recursive t)
│ 
│ ("cartas-img"
│  :base-directory "~/Git/cartas/libro/org/img/"
│  :base-extension "jpg\\|png"
│  :publishing-directory "~/Git/cartas/libro/tex/img/"
│  :recursive t
│  :publishing-function org-publish-attachment)
│ 
│ ("cartas" :components ("cartas-tex" "cartas-img"))
└

And finally, this is the function that compiles everything (each project
usually has some local variables, like the value of ’jobname’ or the
status of the printing proofs).

Nota Bene: The reason for using async is that in some projects,
especially bilingual editions, I need to pre-compile some files first.
Under normal conditions I don't think it's necessary to use async, since
org-publish just exports everything to .tex documents (short timeout)
and then start-process-shell-command run latexmk asynchronously.

Best regards,

Juan Manuel 

┌
│ (require 'async)
│ (require 'projectile)
│ 
│ (defun latexmk-compile-project-async ()
│   (interactive)
│   (let*
│   ((project-root (projectile-project-root))
│(master-file (read-file-name "Compile: "
│   (concat project-root "libro/org/")))
│(master-file-tex (file-name-sans-extension
│(expand-file-name master-file)))
│(dir-tex (file-name-directory
│(expand-file-name
│ (replace-regexp-in-string "/org/" "/tex/" master-file)
│ ;; save the master document
│ (with-current-buffer
│   (find-file-noselect master-file)
│   (save-buffer))
│ (async-start
│  (lambda ()
│(load "~/.emacs")
│(with-current-buffer
│  (find-file-noselect master-file)
│(org-show-all)
│(save-buffer)
│(org-latex-export-to-latex nil nil nil nil nil))
│;; remove all old auxiliary files before compiling
│(shell-command (concat "rm -r " dir-tex (file-name-base 
master-file-tex) "*"))
│(shell-command (concat "mv " master-file-tex ".tex" " " dir-tex))
│"Document exported")
│  (lambda (resultado)
│(message resultado)
│(let
│  ((default-directory dir-tex)
│   (jobname (if (and jobname-local printing-proofs-state)
│(concat jobname-local "_" printing-proofs-state "_

Re: About 'inline special blocks'

[Juan Manuel Macías]

Ihor Radchenko writes:

> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
>
> #+attr_latex[name]: 
> Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae lacus.
>
> "<>" will be treated as "" during
> export/parsing.

I really like this idea of taking the complex configuration (in case it
is needed) out of the paragraph. I vote for a procedure of this style.
That rows in favor of legibility and lightness. Of course, the blocks
that need an /ad hoc/ configuration represent, in my opinion, an extreme
use case; and, as I mentioned before, I think that it should be avoided
as much as possible. I also fully agree with Tim's comments on this.
Ideally, any format settings for LaTeX, odt, html, etc. must be done
globally, outside the body.

Best regards,

Juan Manuel 

Re: About 'inline special blocks'

[Juan Manuel Macías]

Hi, Kaushal, thanks for all your interesting comments,

Kaushal Modi writes:

> The challenging part will be deciding the syntax so that there are no
> false matches.
>
> May be reserve "inline_" for inline blocks?
>
> e.g. inline_[options]{text}  ?

It seems to me the most consistent option, if we continue in some way
the syntax of the inline code blocks, which would be the close relatives
of the inline special blocks. Perhaps (to shorten the syntax a bit)
'inline' could be replaced by some reserved symbol. Something like:

&_[options]{text}

I think a major issue would also be how to properly compact <[options]>
so as not to result in too overloaded syntax. Maybe something like:

[latex(list of attributes) html(list of attributes)...]

?

But that is an abuse of direct formatting, which I think should always be
avoided, especially in a format-agnostic environment like Org, which is
more of a logician than a typesetter :-)

And, in any case, it is to be expected that the user will not need to
overload that part, since these hypothetical inline blocks would be
intended for short segments of text within the paragraph. I think the
most typical use case would be something like your 'mark' example.

Best regards,

Juan Manuel 

About 'inline special blocks'

[Juan Manuel Macías]

Hi all,

I think this idea was suggested by Ihor in a thread from a few months
ago (I don't remember which one), but since other topics were discussed,
the idea remained a bit in limbo. I still find the idea very
interesting, and I think it would be very productive for Org to have a
multipurpose inline container, so it occurred to me to open this thread
to invite a possible discussion on the subject.

I suppose it would have been more practical to start the thread directly
proposing a patch, but since it is about adding a new element to Org,
which is not trivial, I thought that maybe it would be more convenient
to have a previous discussion and poll the users' and developers opinion.

The question is: Does Org Mode need inline special blocks? On the one
hand, it seems that we can live without them. Macros and links can work
competently for this purpose. But macros have the drawback of the comma
as an escape character; and links also have its drawbacks, although the
org-link-set-parameters function is very versatile. And even a huge fan
of links like me can recognize these limitations :-). For example, we
cannot put a footnote inside a link.

Therefore, I think that inline special blocks would fill an important
gap. They could be translated into HTML as a  container; to
odt as character styles or to LaTeX as commands with arguments. And they
would open the doors to a real solution for multilingual support in Org.

Perhaps the syntax could be a continuation of that of inline code
blocks. Something like:

_[options]{text}

And in options include some 'jibarized' version of attr_latex,
attr_html, etc.

Well, I don't know if I have managed to sell the product well or if I
have been too abstract :-)

Best regards,

Juan Manuel 

Re: [tip] Export and open a PDF in Android via Termux

[Juan Manuel Macías]

Eric S Fraga writes:

> Same with me.  I have to have a smartphone as our institution made the
> decision to remove all landlines and have all staff use MS Teams as our
> work "phone".  I use termux to give me access to Emacs + org so that I
> at least get some real use out of the "smart"phone.

Smartphones are the opium of the 21st century... And worst of all, they
will become the new identity cards. For example, until recently I could
do transactions with my bank through its website. But now it is
mandatory to have a smartphone and download an application, of course
proprietary.

Anyway, termux and Emacs, without a physical keyboard, is torture. I
usually connect a compact mechanical keyboard that I have for my laptop.

By the way, I've noticed how easy it is to write Elisp functions that
call Termux commands from Emacs. I recently wrote this to send SMS (you
can enter the phone number directly or choose a contact saved in BBDB
data base, if you use BBDB). To see the list of contacts it works better
if you use also some completion framework like ivy or helm:

(defun send-sms ()
  (interactive)
  (save-window-excursion (bbdb ".+"))
  (let* ((tlf (if (yes-or-no-p "Enter a contact: ")
  (let ((record (bbdb-get-records "Contact: ")))
(aref
 (car (aref (car record) 5)) 1))
(read-from-minibuffer "Phone number: ")))
 (sms (read-from-minibuffer "Texto del SMS: "))
 (cmd (format "termux-sms-send -n %s %s" tlf sms)))
(call-process-shell-command cmd)))

Best regards,

Juan Manuel

Re: [tip] Export and open a PDF in Android via Termux

[Juan Manuel Macías]

Max Nikulin writes:

> Do termux and emacs build for it have support of D-Bus or notify-send
> binary?

I'm not sure, but I would say yes, because Termux has a repository for
X11 applications and to be able to run desktop environments and
graphical applications (via VNC). But in such a case, I understand that
notify-send would only have life within that frame.

Full GNU/Linux distros can also be installed on termux in a proot
environment. In fact, there is another application, andronix, which
speeds up the process through a series of scripts. Recently I tried
to install using Arch and it worked fine (at least in the installation,
another thing is what can be done in there...).

Anyway, I agree with you about the caveats you mention around termux.
Termux and those other neighboring projects are very notable but they
are still (to put it in some way) juggling games and tightrope walks
without a net. A year ago I made the decision not to use a smartphone,
but lately I have been forced to go back to these devices for work
reasons, so I thought of Termux as the foreigner who is in a strange
land and finds something familiar :- ) The ideal would be a smartphone
running GNU/Linux, but there seems to be a long way to go: hostile
hardware, no drivers... I'm more or less aware of projects like librem
or pinephone, but I'm too lazy to do the disbursement...

Best regards,

Juan Manuel 

Re: [tip] Export and open a PDF in Android via Termux

[Juan Manuel Macías]

Max Nikulin writes:

> Does termux have a notion of mailcap, e.g. mime-support package or
> something similar? I have a hope that
>
> application/pdf; termux-open %s
>
> in /etc/mailcap or in ~/.mailcap might be enough instead of explicit
> configuration of particular packages.

I've been playing with Termux for a short time and what you're
suggesting hadn't occurred to me. Indeed, it works fine with a
~/.mailcap file! I have done a test with an attachment in Gnus:

https://imgur.com/a/g1Auvxp

Termux is quite interesting (and addictive :-)). Now I am playing with
Termux-api to send notifications from Emacs/Gnus to Android (with
gnus-desktop-notifier and the termux-notification command). And also to
send sms from Emacs and bbdb...

Best regards,

Juan Manuel 

Re: I can't set dabbrev to respect the writen case

[Juan Manuel Macías]

Ypo writes:

> These are my variables, it keeps changing what I have already written:
>
> '(case-replace nil)
>
>  '(dabbrev-case-distinction t)
>  '(dabbrev-case-fold-search t)
>  '(dabbrev-case-replace t)
>  '(dabbrev-upcase-means-case-search nil)

With those values it works for me as expected. Maybe it's a problem with
your configuration. Try starting emacs with 'emacs -q' and evaluate the
variables with:

M-x eval-expression 

(setq dabbrev-case-distinction t   
  dabbrev-case-fold-search t
  dabbrev-case-replace t   
  abbrev-upcase-means-case-search nil)

RET

I hardly use dabbrev and I'm afraid I can't give you any more tips.
Try asking  as well.

Best regards,

Juan Manuel 

[tip] Export and open a PDF in Android via Termux

[Juan Manuel Macías]

Hi all,

I have recently installed TeX live on Android inside Termux:

$ pkg install texlive-installer

(https://wiki.termux.com/wiki/TeX_Live)

And I've managed to open a PDF exported from Org using an external
android viewer (mupdf, downloaded from f-droid). The Termux command is
termux-open. You need to add:

(setq org-file-apps
  '((auto-mode . emacs)
 (directory . emacs)
 ("\\.mm\\'" . default)
 ("\\.x?html?\\'" . default)
 ("\\.pdf\\'" . "termux-open %s")))

It is necessary also to uncomment the line 'allow-external-apps = true' in 
'~/.termux/termux.properties'.

And to open the PDF from AUCTeX:

(setq TeX-view-program-list '(("termux" "termux-open %o")))

(setq TeX-view-program-selection
'(((output-dvi has-no-display-manager)
  "dvi2tty")
 ((output-dvi style-pstricks)
  "dvips and gv")
 (output-dvi "xdvi")
 (output-pdf "termux")
 (output-html "xdg-open")))

A screencast: https://imgur.com/a/iBvwDTo

Best regards,

Juan Manuel 

Re: I can't set dabbrev to respect the writen case

[Juan Manuel Macías]

Ypo writes:

> Hi
>
> I find dabbrev and fancy-dabbrev very useful to typing fast. But there
> is a problem I am not able to solve: When I apply an expansion while
> writing, the case is always that of the expansion, I can't make it to
> respect what I have written. An example:
>
> — (Typing) "Hel
>
> — (Offered expansion) "hello"
>
> — (What I get when accepting the expansion) "hello"
>
> — (What I wanted) "Hello"
>
> Best regards,
>
> Ypo
>

Take a look at these variables. I have them configured as non-nil:

(setq dabbrev-case-replace t)

(setq dabbrev-case-fold-search t)

Best regards,

Juan Manuel 

Re: simple request letter - help

[Juan Manuel Macías]

andrés ramírez writes:

> Right. It is giving me an error I have NOT noticed it because the pdf is
> being generated.

Your document is probably compiled on export with the
`-intercaction=nonstopmode' option, and thus does not break the
compilation with an error. In any case, I don't really understand why
you export that part literally to LaTeX and why you add the & at
beginning of line:

& John Doe\\
& ID: 

Those characters are usually reserved for tabular
environments, so LaTeX returns an error. If you want to use an &
literally in LaTeX you must escape it as \&. But if you write the
anpersand directly in Org Mode you don't need to escape it, since Org
takes care of it when it exports the document.

Also, in the signature you could also avoid direct formatting. You can
define a simple environment, with an extra space before it, if you need
to add that space. This is a very elementary example, based on your
format. Then you can use in Org a special block, with the name of the
environment:

#+LaTeX_Header: 
\newenvironment{signature}{\bigskip\raggedright\makebox[1.5in]{\hrulefill}\par}{\par}

#+begin_signature
John Doe

ID: 
#+end_signature

Best regards,

Juan Manuel 

Re: simple request letter - help

[Juan Manuel Macías]

hi Andrés,

andrés ramírez writes:

> Hi. Juan.
> My comments below.

I'll explain what happens. There really isn't an alignment issue. TeX by
default applies a first line indent to paragraphs. It also defaults to
applying English typographical conventions, as is the case in your
document, where the first paragraph following a section is not indented.
This is what is happening :):

section
no indent -
indent   --
indent   --

Another more general typographical convention is that when paragraphs
are separated by a vertical space, they do not need to indent the first
line, as it is a redundant mark. Besides, you are making paragraph
separation by direct format (\bigskip). I usually recommend not applying
direct format in LaTeX, or applying it as little as possible. To disable
the first line indentation and make the paragraphs have a space between
them, it is enough that you add this:

#+LaTeX_Header: \parindent=0em\parskip=\bigskipamount

That way, you're giving the first line indentation a global value of
zero and a paragraph spacing value equivalent to \bigskip, and you don't
need to put a \bigsip every time you start a paragraph.

On the other hand, this code at the end does not give you an error?

\makebox[1.5in]{\hrulefill} \hspace {1.0in} \\
& John Doe \\
& ID: \\

best regards, 

Juan Manuel 

Re: simple request letter - help

[Juan Manuel Macías]

Hi Andrés,

Andrés Ramírez writes:

> When I export the file M-x org-export-distpach l p
>
> The second and third paragraph do nat have right alignment as the first
> paragraph.

Can you please copy the contents of your .tex file here: `M-x
org-export-disptatch l l'?

Best regards,

Juan Manuel 

citation-style-language: new LaTeX package in TL 2022

[Juan Manuel Macías]

Hi all,

TeX Live 2022 includes a new LaTeX package for citations,
'citation-style-language', written by Zeping Lee. According to the
package description:

"[...] The citation-style-language package is aimed to provide another
reference formatting method for LaTeX that utilizes the CSL styles. It
contains a citation processor implemented in pure Lua (citeproc-lua)
which reads bibliographic metadata and performs sorting and formatting
on both citations and bibliography according to the selected CSL style.
A LaTeX package (citation-style-language.sty) is provided to communicate
with the processor."

https://ctan.org/pkg/citation-style-language

https://github.com/zepinglee/citeproc-lua

I'm not sufficiently familiar (at the moment) with org-cite, but I share
the news here in case this new LaTeX package could have some kind of use
for org-cite export options.

Best regards,

Juan Manuel