* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-07-25 13:34 6% ` Ihor Radchenko
@ 2022-07-25 17:13 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-25 17:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hi, Ihor,
Here is a new fixed version of the patch, with the addition to NEWS.
Ihor Radchenko writes:
>> - (org-back-to-heading t) ; Sets match data
>> - (match-end 0))
>> + (re-search-backward org-heading-regexp) ; Sets match data
>> + (match-beginning 0))
>
> This will err when the source block is before the first headline in the
> document.
I've reverted the first line to (org-back-to-heading t), keeping the
(match-beginning 0), otherwise you don't get the full headline and all
property drawers would be exported. But it's strange, it doesn't give me
any error when the source block is before the first headline in the
document. Isn't that error prevented with this:
(condition-case nil
...
(error (point-min)))
?
By the way, I've noticed that it's not convenient to export numbered
headers, so I've modified org-babel-export-comment-text-as-plain-text so
that it removes header numbering. I don't know if it's ok to do it this
way...
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-tangle.el-The-org-value-for-comments-is-now-.patch --]
[-- Type: text/x-patch, Size: 3484 bytes --]
From b500fcb1475b0a2e8eee532f031bb5cd236560fb Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 25 Jul 2022 18:48:45 +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.
---
etc/ORG-NEWS | 6 ++++++
lisp/ob-tangle.el | 25 +++++++++++++++++++------
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 478fcf95c..22daa4351 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -375,6 +375,12 @@ purpose of the variable. The replacement variable
accepts =listings= and =verbatim= in place of =t= and =nil= (which
still work, but are no longer listed as valid options).
+*** ~ob-tangle~: the ~org~ value for ~:comments~ is now plain text
+
+When the value of the header argument ~:comments~ is ~org~, the text
+collected in the Org document is exported to ASCII before being passed
+to the tangled source file as a comment.
+
* Version 9.5
** Important announcements and breaking changes
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index fdba72278..da14aaa5a 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,18 @@ 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 (text)
+ "Function to process raw Org TEXT collected to be inserted as
+comments in tangled source-code files. This function is the
+default value for `org-babel-process-comment-text'."
+ ;; Ensure that if TEXT is a header it is not numbered.
+ (let ((text-nonum (with-temp-buffer
+ (insert text)
+ (when (not (org-entry-get nil "UNNUMBERED"))
+ (org-entry-put nil "UNNUMBERED" "t"))
+ (buffer-string))))
+ (org-export-string-as text-nonum '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
@@ -534,7 +547,7 @@ non-nil, return the full association list to be used by
(max (condition-case nil
(save-excursion
(org-back-to-heading t) ; Sets match data
- (match-end 0))
+ (match-beginning 0))
(error (point-min)))
(save-excursion
(if (re-search-backward
--
2.37.1
^ permalink raw reply related [relevance 7%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-07-21 13:44 8% ` Juan Manuel Macías
@ 2022-07-25 13:34 6% ` Ihor Radchenko
2022-07-25 17:13 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-25 13:34 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> 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.
Thanks!
This change should be in ORG-NEWS.
> +(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))
Please document what the function does as the first line and document
the arguments. See D.6 Tips for Documentation Strings in Elisp manual.
The fact that this function is default for something is secondary for
the docstring. If you mention this fact, please also link back to the
defcustom.
> - (org-back-to-heading t) ; Sets match data
> - (match-end 0))
> + (re-search-backward org-heading-regexp) ; Sets match data
> + (match-beginning 0))
This will err when the source block is before the first headline in the
document.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: Improvements in the default LaTeX preamble: templates?
2022-07-25 9:31 5% ` Ihor Radchenko
@ 2022-07-25 10:45 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-25 10:45 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Maxim Nikulin
Ihor Radchenko writes:
> LaTeX is just one export backend to worry about. From broader
> perspective, we can have a generic template library.
Nice idea, I agree. I was targeting LaTeX specifically because of the
questions that have been raised in this thread and other parallel threads.
And because LaTeX is an extremely complex beast. And it has become much
more complex over the years[1]. No two LaTeX documents are alike just as no
two LaTeX users are alike. Just take a look at tex.stackexchange.com to
realize that reality...
(ConTeXt can be a good alternative for those who don't want to mess with
the complexity of LaTeX. In ConTeXt you don't need to load a package for
everything ---modules at most, but that's another story---, so almost
everything is out-of-the-box there).
[1] And there is also the problem of multiplicity: three TeX engines
coexisting at the same time, LaTeX2ε coexisting with LaTeX 3, etc.
> TEC is working on something along these lines. See
> https://tecosaur.github.io/emacs-config/config.html#cleverer-preamble
Thanks for the pointer! I did not know it and it seems to me a
tremendously interesting work. I'll keep an eye on it.
In my workflow, I am used to writing the configuration of a LaTeX
document (aka, "the preamble") through .sty files that I build according
to the requirements of each project. That is, I write my own packages.
That's probably why I have a bias of opinion here (I use LaTeX for
typesetting and editorial production, so I need more control), but I
tend to think that a LaTeX preamble is something so ductile that
achieving a certain degree of automation is an arduous task. At least
one automation that covers all possible use cases. That's where I got
the idea of being able to have a library of templates to cover different
types of documents, even the most idiosyncratic ones. Or, at least, that
they can serve as an inspiration to other users.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Improvements in the default LaTeX preamble: templates? (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists)
2022-07-24 12:06 8% ` Improvements in the default LaTeX preamble: templates? " Juan Manuel Macías
@ 2022-07-25 9:31 5% ` Ihor Radchenko
2022-07-25 10:45 8% ` Improvements in the default LaTeX preamble: templates? Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-25 9:31 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Maxim Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I agree that adding more elements to the standard preamble is a complex
> matter. LaTeX is already horribly complex and multiple, and it is
> difficult to satisfy all kinds of users with a standard code. It
> occurred to me that an alternative to modifying Org's code in this
> regard could be to have some kind of "LaTeX template library". I think
> Pandoc has something similar too, if I remember correctly. Those
> templates could be on Org or provided by third parties somewhere else,
> like Worg. In Org, we also have a great system for creating LaTeX
> documents templates, which is the org-latex-classes list. A large number
> of elements could be defined in a 'single' class for any type of
> document.
LaTeX is just one export backend to worry about. From broader
perspective, we can have a generic template library.
ox.el currently allows export backends to define document template as a
function, which is the most generic way. However, we can come up with
something more customizable - customizable in a consistent way, in
contrast to the current disarray with various export backends
approaching the boilerplate code differently.
TEC is working on something along these lines. See https://tecosaur.github.io/emacs-config/config.html#cleverer-preamble
Note that we also have inner templates that apply to individual exported
elements.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Improvements in the default LaTeX preamble: templates? (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists)
2022-07-23 17:15 8% ` Improvements in the default LaTeX preamble (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists) Juan Manuel Macías
@ 2022-07-24 12:06 8% ` Juan Manuel Macías
2022-07-25 9:31 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-24 12:06 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Maxim Nikulin
Ihor Radchenko writes:
> Adding things like paper size is a much more debatable topic.
> Considering the number of expected developments in this area, including
> the earlier discussion on XeLaTeX/LuaTeX and preamble generation by TEC,
> adding the new specific defaults will need to be a subject of extensive
> discussion and testing. I do not see much point delaying this patch,
> which provides an immediate improvement in the codebase, until we
> complete all that.
I agree that adding more elements to the standard preamble is a complex
matter. LaTeX is already horribly complex and multiple, and it is
difficult to satisfy all kinds of users with a standard code. It
occurred to me that an alternative to modifying Org's code in this
regard could be to have some kind of "LaTeX template library". I think
Pandoc has something similar too, if I remember correctly. Those
templates could be on Org or provided by third parties somewhere else,
like Worg. In Org, we also have a great system for creating LaTeX
documents templates, which is the org-latex-classes list. A large number
of elements could be defined in a 'single' class for any type of
document.
Some time ago I shared here a function I wrote (it's a bit raw and
little tested) to be able to convert a LaTeX document (the preamble)
into a lisp expression to be added to org-latex-classes:
https://list.orgmode.org/87czgly8x8.fsf@posteo.net/
On the one hand Org would offer a more or less basic preamble out of the
box and on the other hand there could be a "org-latex-classes library"
(extensible by users) that would support a multitude of LaTeX document
types or users. This would include preamble types with a bunch of
components: page layout, fonts, lua code, custom LaTeX commands, custom
lua functions, article types, book types, etc. It would suffice to add:
#+latex_class: foo
and the magic is done.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-24 7:15 6% ` Ihor Radchenko
@ 2022-07-24 11:29 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-24 11:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
Ihor Radchenko writes:
> Can you please add the comments, similar to what I requested earlier.
> These magic length of 4 may be hard to grasp otherwise.
Hi Ihor,
Here is the new patch. I have realized that it is not necessary to put a
cond, since in this case it is only necessary to obtain the name of the
language for the metadata, so this new patch is simpler.
Anyway, I think I'm going to prioritize working on a new
org-latex-language-alist that is a plist, to avoid all this stuff about
numbers and lengths...
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Fix-obsolete-variables-for-babel-an.patch --]
[-- Type: text/x-patch, Size: 1497 bytes --]
From 7f3ddd0d2e6e06becd0d43575be88b77b8d699a4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 24 Jul 2022 13:20:25 +0200
Subject: [PATCH] lisp/ox-latex.el: Fix obsolete variables for babel and
polyglossia
* (org-latex--format-spec): Use the new variable `org-latex-language-alist'.
---
lisp/ox-latex.el | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6cd751409..aea602982 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1860,10 +1860,11 @@ INFO is a plist used as a communication channel."
(defun org-latex--format-spec (info)
"Create a format-spec for document meta-data.
INFO is a plist used as a communication channel."
- (let ((language (let ((lang (plist-get info :language)))
- (or (cdr (assoc-string lang org-latex-babel-language-alist t))
- (nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
- lang))))
+ (let ((language (let ((lang (plist-get info :language))
+ ;; Here it would suffice to obtain the second
+ ;; element, which always returns the name
+ ;; language name in `org-latex-language-alist'
+ (nth 1 (assoc-string lang org-latex-language-alist t))))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
(?s . ,(org-export-data (plist-get info :subtitle) info))
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-23 15:29 0% ` Max Nikulin
@ 2022-07-24 7:23 0% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-24 7:23 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 23/07/2022 12:01, Ihor Radchenko wrote:
>> Juan Manuel Macías writes:
>>
>>> Here is a new version of the patch, with the fixes added.
>>
>> Thanks! Considering that the followup discussion deviated from the
>> substance of the patch towards related design issues,
>
> I believed that the subject of discussion is how much values should be
> added to the alist in addition to babel and polyglossia options:
> fontenc, paper size, etc.
Adding things like paper size is a much more debatable topic.
Considering the number of expected developments in this area, including
the earlier discussion on XeLaTeX/LuaTeX and preamble generation by TEC,
adding the new specific defaults will need to be a subject of extensive
discussion and testing. I do not see much point delaying this patch,
which provides an immediate improvement in the codebase, until we
complete all that.
> I hope, not so much third party packages use the changed variables, so
> committing the patch can hardly be harmful even in the case of
> additional change of the list format in future.
This alist is rather internal variable representing current defaults. I
am not even sure how it can be useful for third-party packages. It
should not be modified by packages either (defconst).
Best,
Ihor
^ permalink raw reply [relevance 0%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-23 15:53 9% ` Juan Manuel Macías
@ 2022-07-24 7:15 6% ` Ihor Radchenko
2022-07-24 11:29 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-24 7:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Kai von Fintel, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Hmm. You are actually right.
>> Juan, can you please take a look. It looks like you missed
>> "org-latex--format-spec" in the patch. It should use the new
>> org-latex-language-alist variable instead.
>
> Attached a new patch to fix (I hope) the org-latex-language-alist issue
> in org-latex--format-spec.
Thanks!
> + (let ((language (let* ((lang (plist-get info :language))
> + (l (assoc lang org-latex-language-alist)))
> + (cond ((and (consp l) (= (length l) 4))
> + (nth 2 (assoc-string lang org-latex-language-alist t)))
> + ((and (consp l) (< (length l) 4))
> + (nth 1 (assoc-string lang org-latex-language-alist t)))))))
Can you please add the comments, similar to what I requested earlier.
These magic length of 4 may be hard to grasp otherwise.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Improvements in the default LaTeX preamble (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists)
2022-07-23 15:19 5% ` Max Nikulin
@ 2022-07-23 17:15 8% ` Juan Manuel Macías
2022-07-24 12:06 8% ` Improvements in the default LaTeX preamble: templates? " Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-23 17:15 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> My vote is to configure babel by default if it is possible to provide
> default preamble that allows reasonable quality of PDF for simple Org
> documents with no explicit configuration.
>
> Ideally, the following should be possible out of the box. When no
> advanced features are involved, user should be able to just export
> document to e.g. having printed version of their notes during a
> meeting, to send a summary to the boss. etc. It should be possible for
> users completely ignorant in respect to LaTeX.
>
> Likely language is not enough and e.g. paper size should be guessed
> (LC_PAPER?) as well.
>
> If a document require careful tuning then a couple of extra lines in
> the org file or a couple of additional custom variables in the init
> file should not be a problem.
I think that my position, after all these discussions here and in other
threads, needs a couple of clarifications:
- I am in favor of Org producing a consistent "standard" preamble for
LaTeX out-of-the-box, so that users get a technically optimal PDF
without messing with LaTeX code. This would include not only issues
related to document languages (babel and polyglossia) but also fonts
(especially XelaTeX and LuaLaTeX support), page layout (with geometry
package), publishing support and some other things that can be
proposed here. In this regard, I have changed the subject of this
thread, if that's okay with you.
- I can agree that all of the above is by default. But it seems
essential to me that there is at least the possibility of giving all
that a nil value at a global level, for users who need more control
and want to write (La)TeX code or want to load the entire preamble
from an external document (a .tex file or a .sty file) . Which is not
incompatible with document-level control and fine-tuning (*only* if
the above is enabled).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-23 15:53 9% ` Juan Manuel Macías
2022-07-24 7:15 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-23 15:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Kai von Fintel, orgmode
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hi Ihor and Kai,
Ihor Radchenko writes:
> Hmm. You are actually right.
> Juan, can you please take a look. It looks like you missed
> "org-latex--format-spec" in the patch. It should use the new
> org-latex-language-alist variable instead.
Attached a new patch to fix (I hope) the org-latex-language-alist issue
in org-latex--format-spec.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Fix-obsolete-variables-for-babel-an.patch --]
[-- Type: text/x-patch, Size: 1554 bytes --]
From 95ce88336f6d2106968250379767ce2fe690fe2c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 23 Jul 2022 17:42:50 +0200
Subject: [PATCH] lisp/ox-latex.el: Fix obsolete variables for babel and
polyglossia
* (org-latex--format-spec): Use the new variable `org-latex-language-alist'
---
lisp/ox-latex.el | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6cd751409..ee059d5ce 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1860,10 +1860,12 @@ INFO is a plist used as a communication channel."
(defun org-latex--format-spec (info)
"Create a format-spec for document meta-data.
INFO is a plist used as a communication channel."
- (let ((language (let ((lang (plist-get info :language)))
- (or (cdr (assoc-string lang org-latex-babel-language-alist t))
- (nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
- lang))))
+ (let ((language (let* ((lang (plist-get info :language))
+ (l (assoc lang org-latex-language-alist)))
+ (cond ((and (consp l) (= (length l) 4))
+ (nth 2 (assoc-string lang org-latex-language-alist t)))
+ ((and (consp l) (< (length l) 4))
+ (nth 1 (assoc-string lang org-latex-language-alist t)))))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
(?s . ,(org-export-data (plist-get info :subtitle) info))
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-23 5:01 6% ` [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Ihor Radchenko
2022-07-23 14:11 10% ` Juan Manuel Macías
@ 2022-07-23 15:29 0% ` Max Nikulin
2022-07-24 7:23 0% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-23 15:29 UTC (permalink / raw)
To: emacs-orgmode
On 23/07/2022 12:01, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>
>> Here is a new version of the patch, with the fixes added.
>
> Thanks! Considering that the followup discussion deviated from the
> substance of the patch towards related design issues,
I believed that the subject of discussion is how much values should be
added to the alist in addition to babel and polyglossia options:
fontenc, paper size, etc.
I hope, not so much third party packages use the changed variables, so
committing the patch can hardly be harmful even in the case of
additional change of the list format in future.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-22 14:07 12% ` Juan Manuel Macías
@ 2022-07-23 15:19 5% ` Max Nikulin
2022-07-23 17:15 8% ` Improvements in the default LaTeX preamble (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists) Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-23 15:19 UTC (permalink / raw)
To: emacs-orgmode
On 22/07/2022 21:07, Juan Manuel Macías wrote:
>
> Forget this. On second thought, I think that the option you proposed
> "#+LaTeX_Header: % \usepackage{babel}" is much better.
>
> (I don't know where my head was and I didn't remember there was a
> string-match, so your suggestion is the shortest way. However, the line
> would have to be (with arguments):
>
> #+LaTeX_Header: % \usepackage[something]{babel}
>
> or
>
> #+LaTeX_Header: % \usepackage[something]{polyglossia}
>
> or modify the regexp in org-latex-guess-babel/polyglossia-language.
It was you who suggested
\documentclass[russian]{article}
\usepackage{babel}
At least at first glance it works in texlive-2019 (Ubuntu-20.04), so it
is not a feature from the latest release. Unless commented out,
"#+latex_header: \usepackage{babel}" may be considered as an instruction
to add value of #+language: to \documentclass option. I do not expect
that adjusted regexp will cause a problem.
> Anyway, whatever the choice, I would vote for Org not to load babel or
> polyglossia by default, and for the default option of the custom
> variable that handles that globally to be nil. For example, I'm in the
> group of users that load babel using an external preamble (a .tex or a
> .sty file or a 'latex-class'), and frankly I don't want to have to add a
> new line to all my documents to prevent Org from reloading babel for me
> and return an error on the compilation.
Doesn't the purpose of a custom variable is to set it to a suitable
value in the init file making it unnecessary adding configuration to
each org file? I did not expected that setting it to e.g. nil will be
real burden for users like you.
My vote is to configure babel by default if it is possible to provide
default preamble that allows reasonable quality of PDF for simple Org
documents with no explicit configuration.
Ideally, the following should be possible out of the box. When no
advanced features are involved, user should be able to just export
document to e.g. having printed version of their notes during a meeting,
to send a summary to the boss. etc. It should be possible for users
completely ignorant in respect to LaTeX.
Likely language is not enough and e.g. paper size should be guessed
(LC_PAPER?) as well.
If a document require careful tuning then a couple of extra lines in the
org file or a couple of additional custom variables in the init file
should not be a problem.
^ permalink raw reply [relevance 5%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-23 14:53 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-23 14:53 UTC (permalink / raw)
To: Kai von Fintel; +Cc: orgmode, Ihor Radchenko
Hi Kai,
Kai von Fintel writes:
> I do think that the code on lines 1864 and 1865 of =ox-latex.el=
> (https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox-latex.el#n1864)
> should not use the old variable names. Since you’ve now defined the
> old variables in =org-compat.el=, my exports work, so I’m ok for the
> moment. But I don’t understand why they are still used in the
> definition of =org-latex--format-spec=.
I think you're right. My bad, sorry for that: I have not accounted for
`org-latex--format-spec' in my patch. I will send a new patch soon to fix
this.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-23 14:11 10% ` Juan Manuel Macías
@ 2022-07-23 14:25 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-23 14:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
> Thanks, Ihor. And sorry again for my typos...
No problem.
> If it's okay with you, I can send another patch with the updated
> information in NEWS and the Manual. And we can continue the subsequent
> discussion related of babel, polyglossia et alii in another thread.
Sure. Or you can keep the same thread, probably changing the subject to
something people can notice better (M-x message-change-subject).
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-23 5:01 6% ` [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Ihor Radchenko
@ 2022-07-23 14:11 10% ` Juan Manuel Macías
2022-07-23 14:25 6% ` Ihor Radchenko
2022-07-23 15:29 0% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-23 14:11 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Thanks! Considering that the followup discussion deviated from the
> substance of the patch towards related design issues, I have decided to
> marge the patch as is. We can decide on handling AUTO staff later - it
> would be a major change to remove and the details of an alternative are
> not yet worked out.
>
> Applied onto main via 97cfb959d after adding some double spaces
> between sentences and upcasing the beginning of some sentences.
Thanks, Ihor. And sorry again for my typos...
If it's okay with you, I can send another patch with the updated
information in NEWS and the Manual. And we can continue the subsequent
discussion related of babel, polyglossia et alii in another thread.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-19 15:01 4% ` Juan Manuel Macías
2022-07-19 17:01 5% ` Max Nikulin
@ 2022-07-23 5:01 6% ` Ihor Radchenko
2022-07-23 14:11 10% ` Juan Manuel Macías
2022-07-23 15:29 0% ` Max Nikulin
1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-07-23 5:01 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is a new version of the patch, with the fixes added.
Thanks! Considering that the followup discussion deviated from the
substance of the patch towards related design issues, I have decided to
marge the patch as is. We can decide on handling AUTO staff later - it
would be a major change to remove and the details of an alternative are
not yet worked out.
Applied onto main via 97cfb959d after adding some double spaces
between sentences and upcasing the beginning of some sentences.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-22 12:49 9% ` Juan Manuel Macías
@ 2022-07-22 14:07 12% ` Juan Manuel Macías
2022-07-23 15:19 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-22 14:07 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Juan Manuel Macías writes:
> OK, so why not just:
>
> #+latex_header: % NOLANG
>
> ?
Forget this. On second thought, I think that the option you proposed
"#+LaTeX_Header: % \usepackage{babel}" is much better.
(I don't know where my head was and I didn't remember there was a
string-match, so your suggestion is the shortest way. However, the line
would have to be (with arguments):
#+LaTeX_Header: % \usepackage[something]{babel}
or
#+LaTeX_Header: % \usepackage[something]{polyglossia}
or modify the regexp in org-latex-guess-babel/polyglossia-language.
^ permalink raw reply [relevance 12%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-22 12:16 7% ` Max Nikulin
@ 2022-07-22 12:49 9% ` Juan Manuel Macías
2022-07-22 14:07 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-22 12:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
Max Nikulin writes:
> Form my point of view it is unnecessary magic. Originally #+latex_header
> is intended for valid LaTeX code
OK, so why not just:
#+latex_header: % NOLANG
?
I think this has in its favor: a) it is simple and obvious to remember;
b) it's a single string, and of course c) it's valid LaTeX code. And it
can be easily controlled from org-latex-guess-babel/polyglossia-language
with a conditional.
Anyway, whatever the choice, I would vote for Org not to load babel or
polyglossia by default, and for the default option of the custom
variable that handles that globally to be nil. For example, I'm in the
group of users that load babel using an external preamble (a .tex or a
.sty file or a 'latex-class'), and frankly I don't want to have to add a
new line to all my documents to prevent Org from reloading babel for me
and return an error on the compilation.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-21 15:39 10% ` Juan Manuel Macías
@ 2022-07-22 12:16 7% ` Max Nikulin
2022-07-22 12:49 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-22 12:16 UTC (permalink / raw)
To: emacs-orgmode
On 21/07/2022 22:39, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
> I would vote for a custom variable, at the global level (I agree with
> the options you suggest) and at the document level, to economize,
> perhaps this would be enough to avoid the code of both babel and
> polyglossia:
>
> #+latex_header: NOLANG
Form my point of view it is unnecessary magic. Originally #+latex_header
is intended for valid LaTeX code and "% \usepackage{babel} % disable"
does not make code invalid (being a kind of magic though). If you
consider such cast as too verbose then even
#+options: latex-l10n:nil
might be better. I am unsure if babel or polyglossia are parsed as
strings or as symbols in such context. I am still against a DSL for
"#+options:" to generate complex babel commands in favor of explicit
"#+latex_header:".
On 18/07/2022 23:21, Juan Manuel Macías wrote:
>> \documentclass[11pt,draft,russian]{article}
>> \usepackage{babel}
I have realized that it resembles
\documentstyle[russian,epsfig,wrapfig,12pt]{article}
from the previous century and LaTeX-2.09. Due to lack of support in
babel, several alternatives to add Russian language existed and one of
them required the \documentstyle option.
^ permalink raw reply [relevance 7%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-21 14:36 5% ` Max Nikulin
@ 2022-07-21 15:39 10% ` Juan Manuel Macías
2022-07-22 12:16 7% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-21 15:39 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
Max Nikulin writes:
> The commented out command is a kind a hack, but I consider it as
> acceptable for advanced users who have custom classes or who need to
> compile document without babel (or polyglossia) for some reason.
Yes, I think the ability to control this per document is also necessary.
I would vote for a custom variable, at the global level (I agree with
the options you suggest) and at the document level, to economize,
perhaps this would be enough to avoid the code of both babel and
polyglossia:
#+latex_header: NOLANG
(BTW, in the current version of my patch I'm afraid the commit message
is malformed, and there's an asterisk where it shouldn't be, apologies).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-20 21:30 9% ` Juan Manuel Macías
@ 2022-07-21 14:36 5% ` Max Nikulin
2022-07-21 15:39 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-21 14:36 UTC (permalink / raw)
To: emacs-orgmode
On 21/07/2022 04:30, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
> #+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:
A custom variable may be convenient, however originally I considered
only per-document configuration. If a user do not like babel added by
default then there are some alternatives as
#+latex_header: \usepackage[AUTO]{polyglossia}
or
#+latex_header: % \usepackage{babel} % suppress babel and polyglossia
Certainly with the following variant
#+latex_header: % \usepackage{polyglossia} % no babel or polyglossia
The commented out command is a kind a hack, but I consider it as
acceptable for advanced users who have custom classes or who need to
compile document without babel (or polyglossia) for some reason.
If you feel that defcustom should be added as well, variants may be
- nil to suppress babel and polyglossia
- 'babel or 'polyglossia symbols to get language from #+language:
keyword or from LANGUAGE or LANG environment. Unsure which LC_...
variable may have greater priority.
- string for exact latex code added to preamble.
^ permalink raw reply [relevance 5%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-14 11:55 6% ` Ihor Radchenko
2022-06-15 10:30 9% ` Juan Manuel Macías
@ 2022-07-21 13:44 8% ` Juan Manuel Macías
2022-07-25 13:34 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-21 13:44 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Ihor Radchenko writes:
> The original proposal by Eric Schulte:
> https://list.orgmode.org/4BFFEE4F.5010608@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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-tangle.el-The-org-value-for-comments-is-now-.patch --]
[-- Type: text/x-patch, Size: 2516 bytes --]
From 7095cb5d547bfe9f0576418e71317ad3ebeade77 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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
^ permalink raw reply related [relevance 8%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-20 16:12 6% ` Max Nikulin
@ 2022-07-20 21:30 9% ` Juan Manuel Macías
2022-07-21 14:36 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-20 21:30 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
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
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-19 19:31 7% ` Juan Manuel Macías
@ 2022-07-20 16:12 6% ` Max Nikulin
2022-07-20 21:30 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-20 16:12 UTC (permalink / raw)
To: emacs-orgmode
On 20/07/2022 02:31, Juan Manuel Macías wrote:
> 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 am sorry, I missed the old code below the added lines.
>> 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.
^ permalink raw reply [relevance 6%]
* Re: numbering src blocks in HTML export
@ 2022-07-20 12:07 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-20 12:07 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Fraga, Eric
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
^ permalink raw reply [relevance 8%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-19 17:01 5% ` Max Nikulin
@ 2022-07-19 19:31 7% ` Juan Manuel Macías
2022-07-20 16:12 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-19 19:31 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
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
^ permalink raw reply [relevance 7%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-19 15:01 4% ` Juan Manuel Macías
@ 2022-07-19 17:01 5% ` Max Nikulin
2022-07-19 19:31 7% ` Juan Manuel Macías
2022-07-23 5:01 6% ` [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-19 17:01 UTC (permalink / raw)
To: emacs-orgmode
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').
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 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.
> #+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.
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.
^ permalink raw reply [relevance 5%]
* Re: numbering src blocks in HTML export
2022-07-19 15:28 10% ` Juan Manuel Macías
@ 2022-07-19 16:15 6% ` Fraga, Eric
1 sibling, 0 replies; 200+ results
From: Fraga, Eric @ 2022-07-19 16:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Tuesday, 19 Jul 2022 at 15:28, Juan Manuel Macías wrote:
> I usually do it this way:
>
> #+begin_src sh -n :exports code
Thank you. Obvious (in hindsight). <blush>
I now found the section in the info manual on this (under Markup for
Rich Contents, which is I guess not where I expected it... but did get
there by following link for switches in header arguments which I somehow
missed earlier.)
eric
--
: Eric S Fraga, with org release_9.5.4-643-g057df6 in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-17 9:55 5% ` Ihor Radchenko
2022-07-17 14:48 7% ` Juan Manuel Macías
@ 2022-07-19 15:01 4% ` Juan Manuel Macías
2022-07-19 17:01 5% ` Max Nikulin
2022-07-23 5:01 6% ` [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Ihor Radchenko
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-19 15:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-New-variable-org-latex-language-ali.patch --]
[-- Type: text/x-patch, Size: 12780 bytes --]
From 2f78d6a75849819f1d3aececff70b7ffa4f36c7c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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
+
+
\f
;;; 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 @@
\f
;;; 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" "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" "ecclesiastic")
+ ("lo" "lao" "*")
("lt" "lithuanian")
("lv" "latvian")
- ("ml" "malayalam")
- ("mr" "maranthi")
- ("nb" "norsk")
- ("nko" "nko")
+ ("ml" "malayalam" "*")
+ ("mr" "maranthi" "*")
+ ("nb" "norsk" "norwegian" "bokmal")
("nl" "dutch")
- ("nn" "nynorsk")
+ ("nn" "nynorsk" "norwegian" "nynorsk")
("no" "norsk")
("oc" "occitan")
("pl" "polish")
("pms" "piedmontese")
("pt" "portuges")
("pt-br" "brazilian")
- ("rm" "romansh")
+ ("rm" "romansh" "*")
("ro" "romanian")
("ru" "russian")
- ("sa" "sanskrit")
- ("se" "samin")
+ ("sa" "sanskrit" "*")
("sk" "slovak")
- ("sl" "slovenian")
+ ("sl" "slovene")
("sq" "albanian")
("sr" "serbian")
("sv" "swedish")
- ("syr" "syriac")
- ("ta" "tamil")
- ("te" "telugu")
+ ("syr" "syriac" "*")
+ ("ta" "tamil" "*")
+ ("te" "telugu" "*")
("th" "thai")
("tk" "turkmen")
("tr" "turkish")
("uk" "ukrainian")
- ("ur" "urdu")
+ ("ur" "urdu" "*")
("vi" "vietnamese"))
- "Alist between language code and corresponding Polyglossia option.")
+ "Alist between language code and corresponding Babel/Polyglossia option.
+
+For the names of the languages, the Babel nomenclature is
+preferred to that of Polyglossia, in those cases where both
+coincide.
+
+The alist supports three types of members:
+
+- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
+
+- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION
+ASTERISK (the presence of the asterisk indicates that this
+language is not loaded in Babel using the old method of ldf
+files but using ini files. If Babel is loaded in an Org
+document with these languages, the \"AUTO \" argument is just
+removed, to avoid compilation errors).
+
+- Members with four elements (for variants of languages): CODE
+BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT")
(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
("qbordermatrix" . "\\cr")
@@ -1644,31 +1611,54 @@ Insertion of guessed language only happens when Babel package has
explicitly been loaded. Then it is added to the rest of
package's options.
-The argument to Babel may be \"AUTO\" which is then replaced with
-the language of the document or `org-export-default-language'
-unless language in question is already loaded.
+The optional argument to Babel or the mandatory argument to
+`\babelprovide' command may be \"AUTO\" which is then replaced
+with the language of the document or
+`org-export-default-language' unless language in question is
+already loaded.
Return the new header."
- (let ((language-code (plist-get info :language)))
- ;; If no language is set or Babel package is not loaded, return
- ;; HEADER as-is.
- (if (or (not (stringp language-code))
- (not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
+ (let* ((language-code (plist-get info :language))
+ (language (nth 1 (assoc language-code
+ org-latex-language-alist)))
+ ;; If no language is set or Babel package is not loaded, return
+ ;; HEADER as-is.
+ (header (if (or (not (stringp language-code))
+ (not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
+ header
+ (let ((options (save-match-data
+ (org-split-string (match-string 1 header) ",[ \t]*"))))
+ ;; If LANGUAGE is already loaded, return header
+ ;; without AUTO. Otherwise, replace AUTO with language or
+ ;; append language if AUTO is not present. Languages that are
+ ;; served in Babel exclusively through ini files are not added
+ ;; to the babel argument, and must be loaded using
+ ;; `\babelprovide'.
+ (let ((l (assoc language-code org-latex-language-alist)))
+ ;; Three elements imply that LANGUAGE is served
+ ;; in Babel only by means of an ini file.
+ ;; Therefore it will not be added to the Babel
+ ;; argument. TODO: this should be improved
+ ;; when `org-latex-language-alist' is replaced
+ ;; by a more robust list.
+ (if (and (consp l) (= (length l) 3))
+ header
+ (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))))
+ ", ")
+ t nil header 1)))))))
+ ;; if `\babelprovide[args]{AUTO}' is present, AUTO is
+ ;; replaced by LANGUAGE.
+ (if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
header
- (let ((options (save-match-data
- (org-split-string (match-string 1 header) ",[ \t]*")))
- (language (cdr (assoc-string language-code
- org-latex-babel-language-alist t))))
- ;; If LANGUAGE is already loaded, return header without AUTO.
- ;; Otherwise, replace AUTO with language or append language if
- ;; AUTO is not present.
- (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))))
- ", ")
- t nil header 1)))))
+ (let ((prov (match-string 1 header)))
+ (when (equal "AUTO" prov)
+ (replace-regexp-in-string (format
+ "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
+ (format "\\1\\2%s}" language) header t))))))
(defun org-latex-guess-polyglossia-language (header info)
"Set the Polyglossia language according to the LANGUAGE keyword.
@@ -1710,15 +1700,23 @@ Return the new header."
(concat "\\usepackage{polyglossia}\n"
(mapconcat
(lambda (l)
- (let ((l (or (assoc l org-latex-polyglossia-language-alist)
+ (let ((l (or (assoc l org-latex-language-alist)
l)))
(format (if main-language-set "\\setotherlanguage%s{%s}\n"
(setq main-language-set t)
"\\setmainlanguage%s{%s}\n")
- (if (and (consp l) (= (length l) 3))
- (format "[variant=%s]" (nth 2 l))
+ ;; Four elements implies that there is a
+ ;; variant (4) for LANGUAGE when
+ ;; declared by Polyglossia (3). TODO:
+ ;; this should be improved when
+ ;; `org-latex-language-alist' is
+ ;; replaced by a more robust list.
+ (if (and (consp l) (= (length l) 4))
+ (format "[variant=%s]" (nth 3 l))
"")
- (nth 1 l))))
+ (if (and (consp l) (= (length l) 4))
+ (nth 2 l)
+ (nth 1 l)))))
languages
""))
t t header 0)))))
--
2.37.1
^ permalink raw reply related [relevance 4%]
* Re: numbering src blocks in HTML export
@ 2022-07-19 15:28 10% ` Juan Manuel Macías
2022-07-19 16:15 6% ` Fraga, Eric
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-19 15:28 UTC (permalink / raw)
To: Fraga, Eric; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: [export to CSV]
2022-07-19 6:20 3% ` [export to CSV] (was: org-table with different conventions: decimals) Uwe Brauer
@ 2022-07-19 11:07 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-19 11:07 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* [export to CSV] (was: org-table with different conventions: decimals)
2022-07-18 23:02 9% ` Juan Manuel Macías
@ 2022-07-19 6:20 3% ` Uwe Brauer
2022-07-19 11:07 10% ` [export to CSV] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-07-19 6:20 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan Manuel
> 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.
Thanks but I don't want to export the table to latex, instead I want to
export it to CSV and later import it into Scalc (LO).
So I think the correct way of dealing with this situation is not export
it with english convention to csv and then in Scalc set the default
language to German and import the csv as English (US).
That is a bit cumbersome, but doable.
Regards (take care with the heat if you live in Spain (not sure though))
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 3%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-17 8:58 6% ` Ihor Radchenko
@ 2022-07-19 2:11 0% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-19 2:11 UTC (permalink / raw)
To: emacs-orgmode
On 17/07/2022 15:58, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>
>> I think LEFTWARDS ARROW / #2190 of the 'arrows' Unicode block is much
>> more common:
>
> Thanks for testing!
> I now changed org-agenda to use LEFTWARDS ARROW in b4a72ddf9.
>
> This does not completely solve the reported problem but at least less
> users will suffer from it.
At least in Noto Sans Mono (default font in Kubuntu, unsure concerning
vanilla KDE) \u{2190} "←" arrow is below other dashes like - or —.
Another symbol \u{21fd} "⇽" LEFTWARDS OPEN-HEADED ARROW from the same
arrows Unicode block does not has such problem in this font.
^ permalink raw reply [relevance 0%]
* Re: org-table with different conventions: decimals
@ 2022-07-18 23:02 9% ` Juan Manuel Macías
2022-07-19 6:20 3% ` [export to CSV] (was: org-table with different conventions: decimals) Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-18 23:02 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-18 15:37 6% ` Max Nikulin
@ 2022-07-18 16:21 5% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-18 16:21 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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}
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-18 10:32 7% ` Juan Manuel Macías
2022-07-18 11:01 13% ` Juan Manuel Macías
@ 2022-07-18 15:37 6% ` Max Nikulin
2022-07-18 16:21 5% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-18 15:37 UTC (permalink / raw)
To: emacs-orgmode
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
#+latex_header: \usepackage[french,catalan,uppersorbian,bidi=default]{babel}
#+latex_header: \babelprovide[import,hyphenrules=+]{hebrew}
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.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-18 10:32 7% ` Juan Manuel Macías
@ 2022-07-18 11:01 13% ` Juan Manuel Macías
2022-07-18 15:37 6% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-18 11:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 13%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-18 6:44 5% ` Ihor Radchenko
@ 2022-07-18 10:32 7% ` Juan Manuel Macías
2022-07-18 11:01 13% ` Juan Manuel Macías
2022-07-18 15:37 6% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-18 10:32 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-17 14:48 7% ` Juan Manuel Macías
@ 2022-07-18 6:44 5% ` Ihor Radchenko
2022-07-18 10:32 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-18 6:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Maxim Nikulin
Juan Manuel Macías <maciaschain@posteo.net> 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.
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.
In any case, your existing patch is an already an improvement. I do not
deem it as requirement to apply the patch.
> 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 hope that Timothy's work on more flexible and configurable template
generation can improve things.
> 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?
This sounds reasonable. Implementing via :options-alist export property
will conform more to the overall design (see the docstring of
org-export-options-alist - it enables a lot of flexibility in terms of
customization, including the option syntax similar to what you proposed).
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-17 9:55 5% ` Ihor Radchenko
@ 2022-07-17 14:48 7% ` Juan Manuel Macías
2022-07-18 6:44 5% ` Ihor Radchenko
2022-07-19 15:01 4% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-17 14:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Maxim Nikulin
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
^ permalink raw reply [relevance 7%]
* Re: Org for developing LaTeX packages
2022-07-16 14:33 8% Org for developing LaTeX packages Juan Manuel Macías
@ 2022-07-17 10:09 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-17 10:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Marcin Borkowski
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
I do not think that we need any extensions to org-babel-tangle for this.
AFAIU, appropriate export backend should be more suitable to generate
output that involves both code blocks and other org file elements.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-14 12:34 5% ` Juan Manuel Macías
2022-07-14 15:12 5% ` Max Nikulin
@ 2022-07-17 9:55 5% ` Ihor Radchenko
2022-07-17 14:48 7% ` Juan Manuel Macías
2022-07-19 15:01 4% ` Juan Manuel Macías
1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-07-17 9:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I attach the new version of the patch with both variables declared
> obsolete.
Thanks!
We usually declare obsolete variables in org-compat.el.
> If everything is ok, I can add what is necessary to NEWS and to the Org Manual.
I have some minor comments. You can address them and then go ahead with
NEWS and manual.
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.
> +(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")
> +
As I mentioned earlier, please move the obsoletion statements to org-compat.
> - "Alist between language code and corresponding Polyglossia option.")
> + "Alist between language code and corresponding Babel/Polyglossia option.
> +
> +For the names of the languages, the Babel nomenclature is
> +preferred to that of Polyglossia, in those cases where both
> +coincide.
> +
> +The alist supports three types of members:
> +
> +- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
> +
> +- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION
> +ASTERISK (the presence of the asterisk indicates that this
> +language is not loaded in Babel using the old method of ldf
> +files but using ini files. If Babel is loaded in an Org
> +document with these languages, the \"AUTO \" argument is just
> +removed, to avoid compilation errors).
Two spaces between sentences please, as in
https://orgmode.org/worg/org-contribute.html
> ;; If LANGUAGE is already loaded, return header without AUTO.
> ;; Otherwise, replace AUTO with language or append language if
> ;; AUTO is not present.
> (replace-match
> (mapconcat (lambda (option) (if (equal "AUTO" option) language option))
> (cond ((member language options) (delete "AUTO" options))
> + ((let ((l (assoc language-code org-latex-language-alist)))
> + (and (consp l) (= (length l) 3))) (delete "AUTO" options))
A comment explaining why "3" would be useful.
> - (if (and (consp l) (= (length l) 3))
> - (format "[variant=%s]" (nth 2 l))
> + (if (and (consp l) (= (length l) 4))
> + (format "[variant=%s]" (nth 3 l))
> "")
> - (nth 1 l))))
> + (if (and (consp l) (= (length l) 4))
> + (nth 2 l)
> + (nth 1 l)))))
Again, comment explaining all these 2,3,4 would help.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-13 10:01 10% ` Juan Manuel Macías
@ 2022-07-17 8:58 6% ` Ihor Radchenko
2022-07-19 2:11 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-17 8:58 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Stefan Kangas, Daniel Ortmann, orgmode, Greg Minshall
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think LEFTWARDS ARROW / #2190 of the 'arrows' Unicode block is much
> more common:
Thanks for testing!
I now changed org-agenda to use LEFTWARDS ARROW in b4a72ddf9.
This does not completely solve the reported problem but at least less
users will suffer from it.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Org for developing LaTeX packages
@ 2022-07-16 14:33 8% Juan Manuel Macías
2022-07-17 10:09 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-16 14:33 UTC (permalink / raw)
To: orgmode; +Cc: Marcin Borkowski
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
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-11 14:23 6% ` Juan Manuel Macías
2022-07-11 17:20 5% ` Max Nikulin
@ 2022-07-16 3:01 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-16 3:01 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 11/07/2022 21:23, Juan Manuel Macías wrote:
> Max Nikulin writes:
>>> \\ifpdftex
>>> \\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.
I have noticed the \iftutex command in the iftex.sty manual. It detects
XeTeX, LuaTeX, LuaHBTeX, so it should be more suitable here.
At first I had intention to suggest \ifdefined\XeTeXrevision
\ifdefined\XeTeXrevision you mentioned in
Re [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia
languages alists. Fri, 15 Jul 2022 14:36:07 +0000.
https://list.orgmode.org/878rou30ko.fsf@posteo.net
P.S. I do not remember if CMU Serif, etc. family (that is Computer
Modern Unicode) has been mentioned in this thread. It is not installed
but default, but allows to generate documents with traditional TeX fonts.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-10 10:51 6% ` Max Nikulin
@ 2022-07-15 15:38 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-15 15:38 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
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
^ permalink raw reply [relevance 7%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-15 12:18 5% ` Max Nikulin
@ 2022-07-15 14:36 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-15 14:36 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode, Ihor Radchenko
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
^ permalink raw reply [relevance 7%]
* Re: Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets")
2022-07-12 15:26 7% ` Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets") Juan Manuel Macías
@ 2022-07-15 14:35 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-15 14:35 UTC (permalink / raw)
To: emacs-orgmode
On 12/07/2022 22:26, Juan Manuel Macías wrote:
> 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.
...
> \documentclass{article}
> \usepackage{fontspec}
> \directlua{
> luaotfload.add_fallback ("fallbacktest",{
> "oldstandard:mode=harf;script=grek;color=0000FF;",
> "oldstandard:mode=harf;script=cyrl;color=0000FF;",
> "freeserif:mode=harf;script=arab;color=0000FF;",
> "freeserif:mode=harf;script=dev2;color=0000FF;",
> })}
> \setmainfont{latinmodernroman}[RawFeature={fallback=fallbacktest}]
...
> 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.
I agree that defining fallbacks for each font family is inconvenient.
Defining font per script resembles specifying fonts per language in
babel configuration, however fallback should work without explicit
switching of language. I have seen that babel may determine language
from character code points, but I have not tried if it works reliable
and if it affects performance (as it does for fallback fonts).
Maybe I did not read the manual with enough attention, maybe I tried it
with too old version of LuaTeX, but I had a problem with Emoji.
Depending on font such symbols either broke compilation or did not
appear in PDF (accordingly to pdffonts font was embedded, text may be
copied, but PDF viewers displayed blank space).
https://list.orgmode.org/orgmode/scuirf$m7o$1@ciao.gmane.io/
Maxim Nikulin. Re: org-mode export to (latex) PDF. Sat, 17 Jul 2021
19:35:57 +0700
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-14 18:17 10% ` Juan Manuel Macías
@ 2022-07-15 12:18 5% ` Max Nikulin
2022-07-15 14:36 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-15 12:18 UTC (permalink / raw)
To: emacs-orgmode
On 15/07/2022 01:17, Juan Manuel Macías wrote:
> 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.
I agree that the lists should be merged. My point is that with unnamed
fields and variable number of them it would not be possible to extend
this list with additional fields. So additional step with
`make-obsolete-variable' would be required.
> 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.
It looks like a promising feature.
> 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:
>
> (/usr/share/texmf-dist/tex/generic/babel/locale/es/babel-spanish.tex)
Interesting, Spanish is not mentioned in your document.
> Is this normal or is it a new Babel feature? If it is a new feature, I
> can't find it anywhere in the documentation.
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.
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.
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.
> 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.
That is why I am suggesting a mapping from language to font encoding.
> If you or anyone wants to implement that on top of my
> patch, that's fine with me.
I do not see a solution "on the top of your patch". Either an additional
mapping should be added or your changes should be overwritten by some
extensible structure. The former is a step backward in respect to the
idea of merging alists, the latter might make unhappy developers of
third party packages.
^ permalink raw reply [relevance 5%]
* Re: [tip/offtopic] A function to describe the characters of a word at point
2022-07-14 15:42 5% ` Marcin Borkowski
2022-07-14 22:30 0% ` Samuel Wales
@ 2022-07-15 0:56 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-15 0:56 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Samuel Wales, orgmode
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
^ permalink raw reply [relevance 8%]
* Re: [tip/offtopic] A function to describe the characters of a word at point
2022-07-14 15:42 5% ` Marcin Borkowski
@ 2022-07-14 22:30 0% ` Samuel Wales
2022-07-15 0:56 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Samuel Wales @ 2022-07-14 22:30 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Juan Manuel Macías, orgmode
good idea for command. i like the additional ideas too like the help
text [i hae that put in echo area even in gui].
for even more blue sky stuff, i was thinking along the lines of
information about characters, such as en/locale meanings for cjk. or
furigana [ruby text] for the echo area. requires lookup though. (to
go along with meanings for input method. :))
On 7/14/22, Marcin Borkowski <mbork@mbork.pl> wrote:
>
> On 2022-07-13, at 12:49, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
>> Sorry for the slight offtopic.
>
> Not off-topic at all, as far as I'm concerned! (Though sending this to
> help-gnu-emacs might be an even better idea.) I use `C-u C-x =' pretty
> often, so I fully understand why someone might want to code something
> like this. Very nice, thanks for sharing!
>
> 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.
>
> Also, since the answer to quite a few org-related issues seems to be
> "just insert a zero-width space", making those stand out (like
> non-breaking spaces already are) could also be useful. FWIW, I have
> this function in my init.el:
>
> (defun insert-zero-width-space ()
> "Insert Unicode character \"zero-width space\"."
> (interactive)
> (insert ""))
>
> (of course, the 0-width space is invisible between the quotes).
>
> Best,
> mbork
>
>
>
>> 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
>
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 0%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-14 15:53 9% ` Juan Manuel Macías
@ 2022-07-14 18:17 10% ` Juan Manuel Macías
2022-07-15 12:18 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-14 18:17 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode, Ihor Radchenko
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}</usr/share/texmf-dist/fonts/type1/public/cbfon
ts/grmn1000.pfb></usr/share/texmf-dist/fonts/type1/public/cm-super/sfrm1000.pfb
#+end_src
Is this normal or is it a new Babel feature? If it is a new feature, I
can't find it anywhere in the documentation.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-14 15:12 5% ` Max Nikulin
@ 2022-07-14 15:53 9% ` Juan Manuel Macías
2022-07-14 18:17 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-14 15:53 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [tip/offtopic] A function to describe the characters of a word at point
2022-07-13 10:49 5% [tip/offtopic] A function to describe the characters of a word at point Juan Manuel Macías
@ 2022-07-14 15:42 5% ` Marcin Borkowski
2022-07-14 22:30 0% ` Samuel Wales
2022-07-15 0:56 8% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Marcin Borkowski @ 2022-07-14 15:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2022-07-13, at 12:49, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Sorry for the slight offtopic.
Not off-topic at all, as far as I'm concerned! (Though sending this to
help-gnu-emacs might be an even better idea.) I use `C-u C-x =' pretty
often, so I fully understand why someone might want to code something
like this. Very nice, thanks for sharing!
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.
Also, since the answer to quite a few org-related issues seems to be
"just insert a zero-width space", making those stand out (like
non-breaking spaces already are) could also be useful. FWIW, I have
this function in my init.el:
(defun insert-zero-width-space ()
"Insert Unicode character \"zero-width space\"."
(interactive)
(insert ""))
(of course, the 0-width space is invisible between the quotes).
Best,
mbork
> 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
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-14 12:34 5% ` Juan Manuel Macías
@ 2022-07-14 15:12 5% ` Max Nikulin
2022-07-14 15:53 9% ` Juan Manuel Macías
2022-07-17 9:55 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-14 15:12 UTC (permalink / raw)
To: emacs-orgmode
On 14/07/2022 19:34, Juan Manuel Macías wrote:
> 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.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-10 9:25 6% ` Ihor Radchenko
@ 2022-07-14 12:34 5% ` Juan Manuel Macías
2022-07-14 15:12 5% ` Max Nikulin
2022-07-17 9:55 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-14 12:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-New-variable-org-latex-language-ali.patch --]
[-- Type: text/x-patch, Size: 8306 bytes --]
From 9ff77e71a8cd89b883d5ead37909c887178e4402 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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 @@
\f
;;; 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" "ecclesiastic")
+ ("lo" "lao" "*")
("lt" "lithuanian")
("lv" "latvian")
- ("ml" "malayalam")
- ("mr" "maranthi")
- ("nb" "norsk")
- ("nko" "nko")
+ ("ml" "malayalam" "*")
+ ("mr" "maranthi" "*")
+ ("nb" "norsk" "norwegian" "bokmal")
("nl" "dutch")
- ("nn" "nynorsk")
+ ("nn" "nynorsk" "norwegian" "nynorsk")
("no" "norsk")
("oc" "occitan")
("pl" "polish")
("pms" "piedmontese")
("pt" "portuges")
("pt-br" "brazilian")
- ("rm" "romansh")
+ ("rm" "romansh" "*")
("ro" "romanian")
("ru" "russian")
- ("sa" "sanskrit")
- ("se" "samin")
+ ("sa" "sanskrit" "*")
("sk" "slovak")
- ("sl" "slovenian")
+ ("sl" "slovene")
("sq" "albanian")
("sr" "serbian")
("sv" "swedish")
- ("syr" "syriac")
- ("ta" "tamil")
- ("te" "telugu")
+ ("syr" "syriac" "*")
+ ("ta" "tamil" "*")
+ ("te" "telugu" "*")
("th" "thai")
("tk" "turkmen")
("tr" "turkish")
("uk" "ukrainian")
- ("ur" "urdu")
+ ("ur" "urdu" "*")
("vi" "vietnamese"))
- "Alist between language code and corresponding Polyglossia option.")
+ "Alist between language code and corresponding Babel/Polyglossia option.
+
+For the names of the languages, the Babel nomenclature is
+preferred to that of Polyglossia, in those cases where both
+coincide.
+
+The alist supports three types of members:
+
+- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
+
+- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION
+ASTERISK (the presence of the asterisk indicates that this
+language is not loaded in Babel using the old method of ldf
+files but using ini files. If Babel is loaded in an Org
+document with these languages, the \"AUTO \" argument is just
+removed, to avoid compilation errors).
+
+- Members with four elements (for variants of languages): CODE
+BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT")
(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
("qbordermatrix" . "\\cr")
@@ -1657,14 +1628,16 @@ Return the new header."
header
(let ((options (save-match-data
(org-split-string (match-string 1 header) ",[ \t]*")))
- (language (cdr (assoc-string language-code
- org-latex-babel-language-alist t))))
+ (language (nth 1 (assoc language-code
+ org-latex-language-alist))))
;; If LANGUAGE is already loaded, return header without AUTO.
;; Otherwise, replace AUTO with language or append language if
;; AUTO is not present.
(replace-match
(mapconcat (lambda (option) (if (equal "AUTO" option) language option))
(cond ((member language options) (delete "AUTO" options))
+ ((let ((l (assoc language-code org-latex-language-alist)))
+ (and (consp l) (= (length l) 3))) (delete "AUTO" options))
((member "AUTO" options) options)
(t (append options (list language))))
", ")
@@ -1710,15 +1683,17 @@ Return the new header."
(concat "\\usepackage{polyglossia}\n"
(mapconcat
(lambda (l)
- (let ((l (or (assoc l org-latex-polyglossia-language-alist)
+ (let ((l (or (assoc l org-latex-language-alist)
l)))
(format (if main-language-set "\\setotherlanguage%s{%s}\n"
(setq main-language-set t)
"\\setmainlanguage%s{%s}\n")
- (if (and (consp l) (= (length l) 3))
- (format "[variant=%s]" (nth 2 l))
+ (if (and (consp l) (= (length l) 4))
+ (format "[variant=%s]" (nth 3 l))
"")
- (nth 1 l))))
+ (if (and (consp l) (= (length l) 4))
+ (nth 2 l)
+ (nth 1 l)))))
languages
""))
t t header 0)))))
--
2.36.1
^ permalink raw reply related [relevance 5%]
* [tip/offtopic] A function to describe the characters of a word at point
@ 2022-07-13 10:49 5% Juan Manuel Macías
2022-07-14 15:42 5% ` Marcin Borkowski
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-13 10:49 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 5%]
* Re: [External] : Re: missing a character / font in agenda?
@ 2022-07-13 10:01 10% ` Juan Manuel Macías
2022-07-17 8:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-13 10:01 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Daniel Ortmann, orgmode, Ihor Radchenko, Greg Minshall
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
^ permalink raw reply [relevance 10%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-12 23:04 6% ` Daniel Ortmann
@ 2022-07-12 23:31 0% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-12 23:31 UTC (permalink / raw)
To: Daniel Ortmann, Stefan Kangas; +Cc: Juan Manuel Macías, orgmode
Daniel Ortmann <daniel.ortmann@oracle.com> writes:
> Ihor,
> What are your thoughts?
>
> On 7/12/22 15:03, Juan Manuel Macías wrote:
>> 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.
The offending commit is 998a0aacd from Stefan.
The commit is supposed to fall back to ASCII symbol if the Unicode
variant is not available, but apparently the check failed for some
reason:
(defcustom org-agenda-current-time-string
(if (and (display-graphic-p)
(char-displayable-p ?⭠)
(char-displayable-p ?─))
"⭠ now ───────────────────────────────────────────────"
"now - - - - - - - - - - - - - - - - - - - - - - - - -")
"The string for the current time marker in the agenda."
:group 'org-agenda-time-grid
:version "29.1"
:type 'string)
Stefan, do you have any idea what can go wrong here?
The only thing I can think about is warning in the char-displayable-p
docstring:
>> On a multi-font display, the test is only whether there is an
>> appropriate font from the selected frame's fontset to display
>> CHAR's charset in general. Since fonts may be specified on a
>> per-character basis, this may not be accurate.
Best,
Ihor
^ permalink raw reply [relevance 0%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-12 20:03 13% ` Juan Manuel Macías
@ 2022-07-12 23:04 6% ` Daniel Ortmann
2022-07-12 23:31 0% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Daniel Ortmann @ 2022-07-12 23:04 UTC (permalink / raw)
To: Ihor Radchenko, Juan Manuel Macías; +Cc: orgmode
Ihor,
What are your thoughts?
On 7/12/22 15:03, Juan Manuel Macías wrote:
> 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
^ permalink raw reply [relevance 6%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-12 19:52 9% ` Juan Manuel Macías
@ 2022-07-12 20:03 13% ` Juan Manuel Macías
2022-07-12 23:04 6% ` Daniel Ortmann
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-12 20:03 UTC (permalink / raw)
To: Daniel Ortmann; +Cc: orgmode
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
^ permalink raw reply [relevance 13%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-12 18:45 5% ` [External] : " Daniel Ortmann
@ 2022-07-12 19:52 9% ` Juan Manuel Macías
2022-07-12 20:03 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-12 19:52 UTC (permalink / raw)
To: Daniel Ortmann; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [External] : Re: missing a character / font in agenda?
2022-07-12 17:58 10% ` Juan Manuel Macías
@ 2022-07-12 18:45 5% ` Daniel Ortmann
2022-07-12 19:52 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Daniel Ortmann @ 2022-07-12 18:45 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
That odd new character just showed up after a normal daily org-mode 'git
pull'.
The Symbola.ttf font worked fine.
I used this page for for instructions.
https://linuxconfig.org/how-to-install-and-manage-fonts-on-linux
After copying the font to ~/.local/share/font/ and running the 'fc-cache
-vf' command
... The font appears after emacs + org-mode are restarted.
(I did not need to run set-fontset-font.)
Somewhere in there I also pulled fresh org-mode and emacs code and
rebuilt; am not sure if that was needed.
Here is how that screen now appears:
* Would using the ASCII '<' character be a better solution?
* Is anyone else seeing this issue and missing font?
* What would allow that Symbola font to be available?
* 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?)
Thank you!
On 7/12/22 12:58, Juan Manuel Macías wrote:
> 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://urldefense.com/v3/__https://fontlibrary.org/en/font/symbola__;!!ACWV5N9M2RV99hQ!LCWutd87ZOlNkSgFTjjR0zYsqhv6xP6ZBep63lyK7tIveH2MWiQ331YB8rJexEVU6gjcjT99EdYoJvFPvxABlZvT$
>
> 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
[-- Attachment #2.1: Type: text/html, Size: 2799 bytes --]
[-- Attachment #2.2: NlUOYIKHE6OnYm6T.png --]
[-- Type: image/png, Size: 11127 bytes --]
^ permalink raw reply [relevance 5%]
* Re: missing a character / font in agenda?
@ 2022-07-12 17:58 10% ` Juan Manuel Macías
2022-07-12 18:45 5% ` [External] : " Daniel Ortmann
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-12 17:58 UTC (permalink / raw)
To: Daniel Ortmann; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets")
2022-07-12 11:37 7% ` fontsets Juan Manuel Macías
@ 2022-07-12 15:26 7% ` Juan Manuel Macías
2022-07-15 14:35 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-12 15:26 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko, Stefan Nobis, Maxim Nikulin, Timothy
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=0000FF;",
"oldstandard:mode=harf;script=cyrl;color=0000FF;",
"freeserif:mode=harf;script=arab;color=0000FF;",
"freeserif:mode=harf;script=dev2;color=0000FF;",
}
)
}
\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
^ permalink raw reply [relevance 7%]
* Re: fontsets
2022-07-12 7:12 6% ` fontsets Stefan Nobis
@ 2022-07-12 11:37 7% ` Juan Manuel Macías
2022-07-12 15:26 7% ` Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets") Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-12 11:37 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode, Timothy, Ihor Radchenko, Maxim Nikulin
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
^ permalink raw reply [relevance 7%]
* Re: fontsets
2022-07-11 22:09 8% ` fontsets Juan Manuel Macías
@ 2022-07-12 7:12 6% ` Stefan Nobis
2022-07-12 11:37 7% ` fontsets Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Stefan Nobis @ 2022-07-12 7:12 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> [1] I have to add, by the way, that MatchLowercase is not always a
> panacea.
Hmmm... maybe add optional extra config/output option to the fontset,
like so:
┌────
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│ (myfontb ...)
│ ...)
│ ;; Fontsets
│ ((myfontset .
│ ((sans . myfonta)
│ (serif . myfontb)
│ (mono . myfontc)
│ (extra . ((lualatex . "\\defaultfontfeatures{Scale=MatchLowercase}")
│ (html "some CSS...")...))
│ ...))
│ ...)
└────
This way it may be possible to build a fontset library of fonts that
blend well together, including some necessary fine-tuning.
--
Until the next mail...,
Stefan.
^ permalink raw reply [relevance 6%]
* Re: fontsets
@ 2022-07-11 22:09 8% ` Juan Manuel Macías
2022-07-12 7:12 6% ` fontsets Stefan Nobis
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-11 22:09 UTC (permalink / raw)
To: Timothy; +Cc: orgmode, Ihor Radchenko, Maxim Nikulin
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
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-11 14:23 6% ` Juan Manuel Macías
@ 2022-07-11 17:20 5% ` Max Nikulin
2022-07-16 3:01 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-11 17:20 UTC (permalink / raw)
To: emacs-orgmode
On 11/07/2022 21:23, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
> \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.
Likely it is not relevant to Org, but for the following document
\documentclass{article}
\usepackage{ifpdf}
\begin{document}
\ifpdf PDF\else Not PDF\fi
\end{document}
I get "PDF" when I use pdflatex and "Not PDF" when I run latex.
> 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?
Mathematical expressions may contain non-latin characters as well.
\text{} may be a rescue (anyway such expression usually appears poorly
formatted), but if I remember correctly, it is better to use math mode
commands to get accurate spaces in accordance to TeX design. So math
fonts with wider coverage is somewhere close to minimum readability.
^ permalink raw reply [relevance 5%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 20:22 3% ` Juan Manuel Macías
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
@ 2022-07-11 17:08 4% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-11 17:08 UTC (permalink / raw)
To: emacs-orgmode
On 10/07/2022 03:22, Juan Manuel Macías wrote:
>
> LuaTeX and XeTeX are
> digital typesetting systems. They are not word processors.
I have skimmed through the discussion happened exactly a year ago
https://list.orgmode.org/orgmode/scuirf$m7o$1@ciao.gmane.io/
and I should repeat that you are too much concentrated on books and
carefully designed camera-ready files.
LaTeX is a kind of word processor as well in the sense that it is used
for notes that are not intended to be published. In some cases it is
merely a tool to make readable a text heavy loaded with math. Balance of
efforts and quality is quite different. As much as possible should be
delegated to "word processor". Forcing users to select particular fonts
makes documents less portable, it increases a chance that a colleague
does not have a font installed on your machine or you get a file
requiring a proprietary font you do not have.
For such quick notes the feature currently provided by browser, office,
etc. is indispensable: list of implicit fallbacks to find some available
font having glyphs missed in the primary fonts.
I do not mind that LuaLaTeX alleviated issues with configuring of fonts,
so it is more convenient for books or decorated documents. Personally I
was quite happy with PdfLaTeX fonts I get out of the box without
necessity to override ≥ 6 font families. I did not use hieroglyphs or
fancy Unicode characters, but with LuaLaTeX they anyway require setting
of additional fonts. My current impression is that LuaLaTeX may be
significant step forward for publishers, but for quick notes it is a
kind of trade-off.
^ permalink raw reply [relevance 4%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
@ 2022-07-11 15:00 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-11 15:00 UTC (permalink / raw)
To: Timothy; +Cc: Maxim Nikulin, Ihor Radchenko, orgmode
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
^ permalink raw reply [relevance 10%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-11 12:31 5% ` Max Nikulin
@ 2022-07-11 14:23 6% ` Juan Manuel Macías
2022-07-11 17:20 5% ` Max Nikulin
2022-07-16 3:01 5% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-11 14:23 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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
^ permalink raw reply [relevance 6%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-10 20:58 4% ` Tim Cross
@ 2022-07-11 13:34 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-11 13:34 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
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
^ permalink raw reply [relevance 6%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
` (3 preceding siblings ...)
2022-07-11 8:05 5% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Stefan Nobis
@ 2022-07-11 12:31 5% ` Max Nikulin
2022-07-11 14:23 6% ` Juan Manuel Macías
4 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-11 12:31 UTC (permalink / raw)
To: emacs-orgmode
On 11/07/2022 03:23, Juan Manuel Macías wrote:
>
> 3. A variable (something like 'org-latex-fontspec-default-configuration') would return something like this:
>
> (format
> \\usepackage{iftex}
> \\ifpdftex
I like the idea of unified preamble suitable for pdflatex and lualatex.
For pdftex \usepackage[...]{fontenc} line may be added here.
> \\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.
> \\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.
ox-latex has some code searching for e.g. \usepackage[...]{inputenc} in
the current configuration to avoid adding of extra copy. It would be
great to have something similar for fontspec commands. I guess, it is
harder to detect, since per-language font configuration may be required
as babel options.
Finally, default value may be language-dependent or alternative font set
may be activated when non-latin characters are detected in the document.
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-11 11:39 8% ` Juan Manuel Macías
@ 2022-07-11 12:04 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-11 12:04 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 12%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-11 8:05 5% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Stefan Nobis
@ 2022-07-11 11:39 8% ` Juan Manuel Macías
2022-07-11 12:04 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-11 11:39 UTC (permalink / raw)
To: Stefan Nobis; +Cc: Ihor Radchenko, Greg Minshall, orgmode
Stefan Nobis writes:
> Juan Manuel Macías <maciaschain@posteo.net> 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
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
` (2 preceding siblings ...)
2022-07-11 2:19 5% ` Ihor Radchenko
@ 2022-07-11 8:05 5% ` Stefan Nobis
2022-07-11 11:39 8% ` Juan Manuel Macías
2022-07-11 12:31 5% ` Max Nikulin
4 siblings, 1 reply; 200+ results
From: Stefan Nobis @ 2022-07-11 8:05 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).
I would vote to activate this by default.
> (format
> \\usepackage{iftex}
> \\ifpdftex
> \\relax
> \\else
> \\usepackage{fontspec}
> \\usepackage{unicode-math}
> \\defaultfontfeatures{Scale=MatchLowercase}
> \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
> \\setmainfont{%s}
> \\setsansfont{%s}
> \\setmonofont{%s}
> \\fi
> org-latex-fontspec-mainfont
> org-latex-fontspec-sansfont
> org-latex-fontspec-monofont)
I would prefer to make it easier to stick with the default fonts. So
only add the font selection commands (including defaultfontfeatures)
when the font variables are non-nil. If no font has been explicitly
chosen, just use the default (in case of lualatex Latin Modern).
For me, it does not matter whether the 'org-latex-fontspec-*'
variables have a default of nil or set to the Free* fonts or something
else. For my configuration, I would set these variable to nil in order
to get the LaTeX default fonts and would like to go with the default
preamble of Org and then add to this on a per document basis.
This way, the whole configuration would be a little more composable, I
think.
--
Until the next mail...,
Stefan.
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
2022-07-10 20:31 12% ` Juan Manuel Macías
2022-07-10 20:58 4% ` Tim Cross
@ 2022-07-11 2:19 5% ` Ihor Radchenko
2022-07-11 8:05 5% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Stefan Nobis
2022-07-11 12:31 5% ` Max Nikulin
4 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-11 2:19 UTC (permalink / raw)
To: Juan Manuel Macías, Timothy; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
+1
> 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).
Does it mean that unicode text (like це or 这个) will not be exported 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.
+1
But can someone check if Free* fonts are available on Windows and Mac by
default? If not, can we distribute these fonts with Org?
> 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)
Makes sense. Though I'd rather use format-spec instead to allow
arbitrary order of variable formatting.
> 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?
This unified preamble approach is consistent with what we do now.
However, our currently used large preambles will slow down compilation.
As I recall, Timothy has been working on simplifying preamble
generation. If we do not put unnecessary packages into preamble,
compilation will be significantly faster.
If Timothy can come up with a patch some time soon, I'd prefer to have a
more targeted preamble. Otherwise, the proposed approach is the way to
go.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
2022-07-10 20:31 12% ` Juan Manuel Macías
@ 2022-07-10 20:58 4% ` Tim Cross
2022-07-11 13:34 6% ` Juan Manuel Macías
2022-07-11 2:19 5% ` Ihor Radchenko
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Tim Cross @ 2022-07-10 20:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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?
>
I'll prefix this by being very clear that I'm so out of my depth, I know
nothing! I'm an Australian who lives on the worlds largest
island. Despite being a country where 1/4 people have at least one
parent born in a non-english speaking country, Australia is at this time
monolingual. As a consequence, I've never had to deal with fonts other
than trying to select one which 'looks nice'. This tends to be something
I leave to Latex as my aesthetic skills are only slightly better than my
language skills!
Like many, I have had to struggle with fonts at one time or another -
typically, it was with respect to type formatting of mathematics/logic
and it was what got me using Latex originally (30+ years ago). I rarely
need to do this now.
So, my perspective on this is fairly basic.
- I think the move to luatex is important for org, especially given
the rise of packages which use/need it
- It seems like luatex could make org easier to use for those who do
need support for other non-latin languages and especially for those
who need to work in multiple languages.
- For many simpler people like me, I just want it to work. When I
export to a PDF document, I want to continue to have people say
"Wow, that is a good looking document, what is your secret" and I
can reply, "Don't use MS Office!". I don't want to mess with
selecting fonts, defining font specs etc. I want good defaults.
- For many people, it seems fonts are a very personal and important
component and they want the power to manage them at a lower
level. Therefore, support for this user is as important as my use
case. They need to be able to adapt their document to their
preferred fonts without having to code elisp or low level latex/tex.
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.
but as I said, I know nothing....
^ permalink raw reply [relevance 4%]
* Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
@ 2022-07-10 20:31 12% ` Juan Manuel Macías
2022-07-10 20:58 4% ` Tim Cross
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-10 20:31 UTC (permalink / raw)
To: orgmode
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)
^ permalink raw reply [relevance 12%]
* [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
2022-07-09 20:22 3% ` Juan Manuel Macías
@ 2022-07-10 20:23 7% ` Juan Manuel Macías
2022-07-10 20:31 12% ` Juan Manuel Macías
` (4 more replies)
2022-07-11 17:08 4% ` LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Max Nikulin
1 sibling, 5 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-10 20:23 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 23:49 5% ` Tim Cross
2022-07-10 11:19 0% ` M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?) Ihor Radchenko
@ 2022-07-10 19:31 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-10 19:31 UTC (permalink / raw)
To: Tim Cross
Cc: Maxim Nikulin, Matt Huszagh, Thomas S. Dye, Dominik Schrempf,
Ihor Radchenko, Greg Minshall, orgmode
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
^ permalink raw reply [relevance 10%]
* Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
2022-07-10 11:19 0% ` M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?) Ihor Radchenko
@ 2022-07-10 19:06 0% ` Tim Cross
0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-07-10 19:06 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Juan Manuel Macías, Maxim Nikulin, Matt Huszagh,
Thomas S. Dye, Dominik Schrempf, orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> Juan Manuel Macías <maciaschain@posteo.net> 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
>> ...
>
> Maybe Org can provide this template simply from M-x?
> Would you find such addition useful?
>
That could be a good and easy addition. If we can streamline the worg
submission process, we can probably improve the worg content quite a
bit.
Only drawback I can see is that should we want to change the template,
we would have to wait until a new version is released and then you will
still have a mix of templates as lots of people will wait until next
Emacs version etc.
The question I guess comes down to how often we would need to change the
template - probably very infrequently. I do plan to change the current
template, but if anything, that will be simplifying it.
I will add this idea to the TODO list!
^ permalink raw reply [relevance 0%]
* M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
2022-07-09 23:49 5% ` Tim Cross
@ 2022-07-10 11:19 0% ` Ihor Radchenko
2022-07-10 19:06 0% ` Tim Cross
2022-07-10 19:31 10% ` LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-10 11:19 UTC (permalink / raw)
To: Tim Cross
Cc: Juan Manuel Macías, Maxim Nikulin, Matt Huszagh,
Thomas S. Dye, Dominik Schrempf, orgmode
Tim Cross <theophilusx@gmail.com> writes:
> Juan Manuel Macías <maciaschain@posteo.net> 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
> ...
Maybe Org can provide this template simply from M-x?
Would you find such addition useful?
Best,
Ihor
^ permalink raw reply [relevance 0%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-10 9:25 6% ` Ihor Radchenko
@ 2022-07-10 10:51 6% ` Max Nikulin
2022-07-15 15:38 7% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-10 10:51 UTC (permalink / raw)
To: emacs-orgmode
On 03/10/2021 22:28, Juan Manuel Macías wrote:
> Hi all,
>
> I'm attaching a patch with a proposal to unify in a single constant
> (named `org-latex-language-alist')
> `org-latex-polyglossia-language-alist' and
> `org-latex-babel-language-alist', along with some necessary (minor)
> modifications in `org-latex-guess-polyglossia-language' and
> `org-latex-guess-babel-language'
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")
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2022-07-10 9:25 6% ` Ihor Radchenko
2022-07-14 12:34 5% ` Juan Manuel Macías
2022-07-10 10:51 6% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-10 9:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I'm attaching a patch with a proposal to unify in a single constant
> (named `org-latex-language-alist')
> `org-latex-polyglossia-language-alist' and
> `org-latex-babel-language-alist', along with some necessary (minor)
> modifications in `org-latex-guess-polyglossia-language' and
> `org-latex-guess-babel-language'
>
> The new list, which is not exhaustive, is built taking as a reference
> the documentation of Babel and Polyglossia in their latest versions
> within TeX live 2021. It also assumes the latest improvements in the
> babel package (on the current state of the art regarding the babel and
> polyglossia packages, see this previous thread:
> https://list.orgmode.org/87wnmv4s87.fsf@posteo.net/). I have also
> corrected some minor inconsistencies in the previous two lists.
Thanks!
This looks like an improvement.
However, we may need to preserve the old defconsts for the time being
and declare them obsolete.
Otherwise, the patch looks fine from a cursory look.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 14:58 3% ` Juan Manuel Macías
[not found] ` <b58ee3cc-c58c-b627-9cc5-51993020db2c@gmail.com>
@ 2022-07-10 2:12 4% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-10 2:12 UTC (permalink / raw)
To: Org Mode List
I'm sorry, again, replying to the private copy of the message sent as
Cc, I dropped mail list address at first.
Please, consider my response in the following context:
https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/
Ihor Radchenko, 2022-07-09:
> Or we may go even further and make org-latex-compiler default to luatex.
> This will benefit all the non-latin language users.
On 09/07/2022 21:58, Juan Manuel Macías wrote:
> 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
This set of characters is covered by latin-1.
> https://i.imgur.com/WwGybBA.png
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.
> Frankly, I don't know what Latin Modern you're referring to, and what
> you mean by saying that "it is not nearly unicode".
/usr/share/texmf/fonts/opentype/public/lm/lmroman10-regular.otf I
noticed in the LuaLaTeX log. Do you get non-latin characters with my
example (without modifying \setmainfont) on your machine?
> \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.
I rarely use libreoffice, so settings should be close to defaults. I can
just paste this text and I see whole snippet without additional actions.
I have no idea why Liberation Serif is chosen, but the default font has
much better coverage, so it is suitable for more users.
> 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.
My point it that such freedom is not for free. If you know which font
you would like to have in a book, you are ready to add some settings and
LuaLaTeX has advantages in such case.
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 or typewriter text is missing.
So LuaLaTeX should be a conscious choice of users ready to add set of
fonts for each language used in the document. I do not try to say that
LuaLaTeX has no advantages. Application such as browsers or office has a
feature suitable for routine documents: graceful degradation in respect
to glyphs missed in the specified font. For publishers in some cases it
may be a disaster (however I believe that ideally such issues should be
discovered from logs even when not apparent from visual appearance of
the document).
I am unsure if it was made by design or TeX engines with native support
of Unicode fonts should made another step further, but currently Org is
able to provide default preamble for PdfLaTeX, but not for LuaLaTeX and
the latter is at least not trivial.
^ permalink raw reply [relevance 4%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 9:59 6% ` Juan Manuel Macías
@ 2022-07-09 23:49 5% ` Tim Cross
2022-07-10 11:19 0% ` M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?) Ihor Radchenko
2022-07-10 19:31 10% ` LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Tim Cross @ 2022-07-09 23:49 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Maxim Nikulin, Ihor Radchenko, Matt Huszagh, Thomas S. Dye,
Dominik Schrempf, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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
>
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
^ permalink raw reply [relevance 5%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
[not found] ` <b58ee3cc-c58c-b627-9cc5-51993020db2c@gmail.com>
@ 2022-07-09 20:22 3% ` Juan Manuel Macías
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
2022-07-11 17:08 4% ` LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-09 20:22 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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
^ permalink raw reply [relevance 3%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 12:15 6% ` Max Nikulin
@ 2022-07-09 14:58 3% ` Juan Manuel Macías
[not found] ` <b58ee3cc-c58c-b627-9cc5-51993020db2c@gmail.com>
2022-07-10 2:12 4% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-09 14:58 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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.
^ permalink raw reply [relevance 3%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 10:42 7% ` Juan Manuel Macías
@ 2022-07-09 12:15 6% ` Max Nikulin
2022-07-09 14:58 3% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-07-09 12:15 UTC (permalink / raw)
To: emacs-orgmode
On 09/07/2022 17:42, Juan Manuel Macías wrote:
> 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.
Juan Manuel, we are going to repeat the discussion happened a year ago.
Has something changed since that time? LuaTeX uses Latin Modern and it
is not nearly Unicode. PdfTeX out of the box has e.g. LH fonts -
Cyrillic extension for Computer Modern, so it is enough to specify input
and font encodings and it is not necessary to care concerning particular
font.
> 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:
My point is that it is not about what I want, it is related to what I
have to do, namely choose, maybe install and explicitly configure some
consistent set of fonts. With the following minimal example I got blank
space instead of non-latin characters.
\documentclass{article}
\begin{document}
Abc — Αλφάβητο — Азбука…
\end{document}
Just have tried with
This is LuaTeX, Version 1.10.0 (TeX Live 2019/Debian)
It is from Ubuntu-20.04 system package.
So to switch default engine in Org from PdfLaTeX to LuaLaTeX it is
necessary to write some code inspecting available font set suitable for
specified language.
^ permalink raw reply [relevance 6%]
* Re: Taking notes of videos in Emacs
2022-07-09 7:31 7% ` Gerardo Moro
@ 2022-07-09 11:37 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-09 11:37 UTC (permalink / raw)
To: Gerardo Moro; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 3:23 0% ` Thomas S. Dye
@ 2022-07-09 11:10 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-09 11:10 UTC (permalink / raw)
To: Thomas S. Dye
Cc: Maxim Nikulin, Ihor Radchenko, Matt Huszagh, Thomas S. Dye,
Dominik Schrempf, Greg Minshall, orgmode, Tim Cross
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
^ permalink raw reply [relevance 8%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 2:23 0% ` Max Nikulin
2022-07-09 3:23 0% ` Thomas S. Dye
2022-07-09 3:24 1% ` Tim Cross
@ 2022-07-09 10:42 7% ` Juan Manuel Macías
2022-07-09 12:15 6% ` Max Nikulin
2 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-09 10:42 UTC (permalink / raw)
To: Max Nikulin
Cc: Tim Cross, Ihor Radchenko, Matt Huszagh, Thomas S. Dye,
Dominik Schrempf, Greg Minshall, orgmode
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.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 3:24 1% ` Tim Cross
@ 2022-07-09 9:59 6% ` Juan Manuel Macías
2022-07-09 23:49 5% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-09 9:59 UTC (permalink / raw)
To: Tim Cross
Cc: Maxim Nikulin, Ihor Radchenko, Matt Huszagh, Thomas S. Dye,
Dominik Schrempf, orgmode, orgmode
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
^ permalink raw reply [relevance 6%]
* Re: Taking notes of videos in Emacs
2022-07-08 13:25 10% ` Juan Manuel Macías
2022-07-08 15:54 6% ` Samuel Banya
@ 2022-07-09 7:31 7% ` Gerardo Moro
2022-07-09 11:37 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Gerardo Moro @ 2022-07-09 7:31 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Thank you, all, for the pointers!
As for your own package, Juan Manuel, I understand the main purpose is to
take screenshots of movies. Am I correct?
Thanks!
El vie, 8 jul 2022 a las 16:25, Juan Manuel Macías (<maciaschain@posteo.net>)
escribió:
> 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.fsf@posteo.net/
>
> Best regards,
>
> Juan Manuel
>
[-- Attachment #2: Type: text/html, Size: 1557 bytes --]
^ permalink raw reply [relevance 7%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 2:23 0% ` Max Nikulin
2022-07-09 3:23 0% ` Thomas S. Dye
@ 2022-07-09 3:24 1% ` Tim Cross
2022-07-09 9:59 6% ` Juan Manuel Macías
2022-07-09 10:42 7% ` Juan Manuel Macías
2 siblings, 1 reply; 200+ results
From: Tim Cross @ 2022-07-09 3:24 UTC (permalink / raw)
To: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 09/07/2022 01:49, Thomas S. Dye wrote:
>> Juan Manuel Macías writes:
>>
>>> TL;DR: A list of use cases where using LuaTeX is more advantageous than
>>> using pdfTeX
>> I forgot to ask earlier. Is Lua support in Babel potentially useful? The current
>> implementation doesn't work too well.
>
> In the context of LaTeX your question is rather ambiguous.
>
> - I have never tried lua interpreter as the handler of source blocks in Org (org-babel).
> - If you mean LuaLaTeX as the engine for "#+begin_src: latex" blocks then some
> incompatibilities may arise due to font selection. PdfLaTeX and LuaLaTeX needs different
> code in preamble to specify encoding and fonts. 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.
> - 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. Sorry, if this statement is not precise enough.
Actually, that is a good point.
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).
^ permalink raw reply [relevance 1%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-09 2:23 0% ` Max Nikulin
@ 2022-07-09 3:23 0% ` Thomas S. Dye
2022-07-09 11:10 8% ` Juan Manuel Macías
2022-07-09 3:24 1% ` Tim Cross
2022-07-09 10:42 7% ` Juan Manuel Macías
2 siblings, 1 reply; 200+ results
From: Thomas S. Dye @ 2022-07-09 3:23 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 09/07/2022 01:49, Thomas S. Dye wrote:
>> Juan Manuel Macías writes:
>>
>>> TL;DR: A list of use cases where using LuaTeX is more
>>> advantageous than
>>> using pdfTeX
>> I forgot to ask earlier. Is Lua support in Babel potentially
>> useful?
>> The current implementation doesn't work too well.
>
> In the context of LaTeX your question is rather ambiguous.
>
> - I have never tried lua interpreter as the handler of source
> blocks in Org
> (org-babel).
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.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 0%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-08 18:49 6% ` Thomas S. Dye
@ 2022-07-09 2:23 0% ` Max Nikulin
2022-07-09 3:23 0% ` Thomas S. Dye
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Max Nikulin @ 2022-07-09 2:23 UTC (permalink / raw)
To: emacs-orgmode
On 09/07/2022 01:49, Thomas S. Dye wrote:
> Juan Manuel Macías writes:
>
>> TL;DR: A list of use cases where using LuaTeX is more advantageous than
>> using pdfTeX
>
> I forgot to ask earlier. Is Lua support in Babel potentially useful?
> The current implementation doesn't work too well.
In the context of LaTeX your question is rather ambiguous.
- I have never tried lua interpreter as the handler of source blocks in
Org (org-babel).
- If you mean LuaLaTeX as the engine for "#+begin_src: latex" blocks
then some incompatibilities may arise due to font selection. PdfLaTeX
and LuaLaTeX needs different code in preamble to specify encoding and
fonts. 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.
- 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. Sorry, if this statement is
not precise enough.
^ permalink raw reply [relevance 0%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-08 12:17 4% LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
` (3 preceding siblings ...)
2022-07-08 18:49 6% ` Thomas S. Dye
@ 2022-07-09 0:34 5% ` Matt Huszagh
4 siblings, 0 replies; 200+ results
From: Matt Huszagh @ 2022-07-09 0:34 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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:
>
> <https://gitlab.com/maciaschain/linealb-in-luatex>
>
> 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 },
> │ }}
> │ }
> │
> │ \setmainfont{Linux Libertine O}[RawFeature=+mykern]
> └────
>
> Here you can see a more bizarre and vandalistic example, where I have
> replaced the accent of the accented letters in Spanish with the image of
> a hammer :-)
>
> https://i.imgur.com/iixxJmx.png
>
> Here I have placed the image of a dancer on the tilde of the spanish
> letter ñ:
>
> https://i.imgur.com/oIZzpbJ.png
>
> (The process is simply to decompose the complex characters from the
> precombined form to their canonical decomposition: NFC > NFD, and then
> use a png image as a diacritic :-):
>
> \newunicodechar{^^^^0301}{\raisebox{1.2ex}{\includegraphics[width=.28em]{martillo.png}}}
>
> 1. Lastly, a lot of new (increasingly) LaTeX packages are written on top
> of the advanced features of LuaTeX and require LuaTeX. A very useful
> package, for example, is impnattypo, for post-production fine-tuning
> (<https://www.ctan.org/pkg/impnattypo>). Among the many features of
> impnattypo we have the ability to prevent lines from ending in
> single-letter words. It also highlights in draft mode, homeoarchy
> cases, which are typographically incorrect. An example in one of my
> recent works:
>
> <https://i.imgur.com/Kf8Oot0.png>
>
> Best regards,
>
> Juan Manuel
I typically use luatex instead of pdftex and the sole reason is
performance for pgfplots. The performance gain is night and day when
generating plots with many points. I forget exactly why this is.
When I'm generating very simple documents I stick with pdftex, which is
faster in those cases.
As for lua scripting: I made some brief forays into this but found it
not to be especially useful for me: the reason for that may just have
been lack of persistent effort, though. When I want more modern
programming features I typically use pylatex.
Matt
^ permalink raw reply [relevance 5%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
@ 2022-07-08 19:03 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-08 19:03 UTC (permalink / raw)
To: Bruce D'Arcus; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-08 12:17 4% LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
` (2 preceding siblings ...)
@ 2022-07-08 18:49 6% ` Thomas S. Dye
2022-07-09 2:23 0% ` Max Nikulin
2022-07-09 0:34 5% ` Matt Huszagh
4 siblings, 1 reply; 200+ results
From: Thomas S. Dye @ 2022-07-08 18:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> TL;DR: A list of use cases where using LuaTeX is more
> advantageous than
> using pdfTeX
I forgot to ask earlier. Is Lua support in Babel potentially
useful? The current implementation doesn't work too well.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 6%]
* Re: Taking notes of videos in Emacs
2022-07-08 13:25 10% ` Juan Manuel Macías
@ 2022-07-08 15:54 6% ` Samuel Banya
2022-07-09 7:31 7% ` Gerardo Moro
1 sibling, 0 replies; 200+ results
From: Samuel Banya @ 2022-07-08 15:54 UTC (permalink / raw)
To: Charles Berry
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
Totally separate user, but this is so dang cool. Thanks for the links, Juan. Looks awesome!
On Fri, Jul 8, 2022, at 9:25 AM, Juan Manuel Macías wrote:
> 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.fsf@posteo.net/
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 1510 bytes --]
^ permalink raw reply [relevance 6%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-08 12:17 4% LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
2022-07-08 15:49 1% ` Uwe Brauer
@ 2022-07-08 16:13 6% ` Thomas S. Dye
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Thomas S. Dye @ 2022-07-08 16:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> TL;DR: A list of use cases where using LuaTeX is more
> advantageous than
> using pdfTeX
>
Interesting. Thanks!
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 6%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-08 15:49 1% ` Uwe Brauer
@ 2022-07-08 16:46 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-08 16:46 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
2022-07-08 12:17 4% LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
@ 2022-07-08 15:49 1% ` Uwe Brauer
2022-07-08 16:46 7% ` Juan Manuel Macías
2022-07-08 16:13 6% ` Thomas S. Dye
` (3 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-07-08 15:49 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan
> 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.
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?
Regards
Uwe Brauer
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: Taking notes of videos in Emacs
@ 2022-07-08 13:25 10% ` Juan Manuel Macías
2022-07-08 15:54 6% ` Samuel Banya
2022-07-09 7:31 7% ` Gerardo Moro
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-08 13:25 UTC (permalink / raw)
To: Gerardo Moro; +Cc: orgmode
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.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
@ 2022-07-08 12:17 4% Juan Manuel Macías
2022-07-08 15:49 1% ` Uwe Brauer
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-08 12:17 UTC (permalink / raw)
To: orgmode
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:
<https://gitlab.com/maciaschain/linealb-in-luatex>
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 },
│ }}
│ }
│
│ \setmainfont{Linux Libertine O}[RawFeature=+mykern]
└────
Here you can see a more bizarre and vandalistic example, where I have
replaced the accent of the accented letters in Spanish with the image of
a hammer :-)
https://i.imgur.com/iixxJmx.png
Here I have placed the image of a dancer on the tilde of the spanish
letter ñ:
https://i.imgur.com/oIZzpbJ.png
(The process is simply to decompose the complex characters from the
precombined form to their canonical decomposition: NFC > NFD, and then
use a png image as a diacritic :-):
\newunicodechar{^^^^0301}{\raisebox{1.2ex}{\includegraphics[width=.28em]{martillo.png}}}
1. Lastly, a lot of new (increasingly) LaTeX packages are written on top
of the advanced features of LuaTeX and require LuaTeX. A very useful
package, for example, is impnattypo, for post-production fine-tuning
(<https://www.ctan.org/pkg/impnattypo>). Among the many features of
impnattypo we have the ability to prevent lines from ending in
single-letter words. It also highlights in draft mode, homeoarchy
cases, which are typographically incorrect. An example in one of my
recent works:
<https://i.imgur.com/Kf8Oot0.png>
Best regards,
Juan Manuel
^ permalink raw reply [relevance 4%]
* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
2022-05-31 11:00 8% ` Juan Manuel Macías
@ 2022-07-04 11:44 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-04 11:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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...
I do like the proposed feature. However, I'd prefer if instead of
introducing a whole new functionality we could extend the existing one.
This approach generally leads to code that is easier to maintain.
> 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).
> ...
> 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{}{}
From the above, the verse numbering looks simply like an extended line
numbering. Normal line numbering can be thought as a subset of the
proposed features.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: Convert a Lisp expression to a tree diagram
2022-07-01 1:13 6% ` Ihor Radchenko
@ 2022-07-01 10:45 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-01 10:45 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: Convert a Lisp expression to a tree diagram
2022-06-30 22:30 10% ` Juan Manuel Macías
@ 2022-07-01 1:13 6% ` Ihor Radchenko
2022-07-01 10:45 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-01 1:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> 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 :-))
This capture template is public: https://github.com/yantar92/org-capture-ref
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: Convert a Lisp expression to a tree diagram
2022-06-30 16:21 6% ` arthur miller
@ 2022-06-30 22:32 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-30 22:32 UTC (permalink / raw)
To: arthur miller; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: Convert a Lisp expression to a tree diagram
2022-06-30 15:17 4% ` Ihor Radchenko
@ 2022-06-30 22:30 10% ` Juan Manuel Macías
2022-07-01 1:13 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-30 22:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* RE: Convert a Lisp expression to a tree diagram
2022-06-30 14:19 9% Convert a Lisp expression to a tree diagram Juan Manuel Macías
2022-06-30 15:17 4% ` Ihor Radchenko
@ 2022-06-30 16:21 6% ` arthur miller
2022-06-30 22:32 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: arthur miller @ 2022-06-30 16:21 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
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?
-------- Originalmeddelande --------
Från: Juan Manuel Macías <maciaschain@posteo.net>
Datum: 2022-06-30 16:20 (GMT+01:00)
Till: orgmode <emacs-orgmode@gnu.org>
Ämne: Convert a Lisp expression to a tree diagram
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
[-- Attachment #2: Type: text/html, Size: 2106 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Convert a Lisp expression to a tree diagram
2022-06-30 14:19 9% Convert a Lisp expression to a tree diagram Juan Manuel Macías
@ 2022-06-30 15:17 4% ` Ihor Radchenko
2022-06-30 22:30 10% ` Juan Manuel Macías
2022-06-30 16:21 6% ` arthur miller
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-06-30 15:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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...
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.
Best,
Ihor
----
actual notes below:
***** CANCELLED /u/zainab-ali [Reddit:emacs] (2021) M-x emacs-reddit: pair-tree: a learning tool for visualizing Elisp lists :BOOKMARK:misc:CANCELLED:
SCHEDULED: <2021-03-28 Sun>
:PROPERTIES:
:ID: 1443107e70e8b4e1d6d17499e546a8603b98d03e
:CREATED: [2021-01-19 Tue 10:09]
:Source: [[https://www.reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/]]
:ARCHIVE_TIME: 2021-04-02 Fri 16:15
:ARCHIVE_FILE: ~/Org/notes.org
:ARCHIVE_OLPATH: Topics/Software/Emacs \ org-mode/No deadline
:ARCHIVE_CATEGORY: Emacs[D]
:ARCHIVE_TODO: CANCELLED
:ARCHIVE_ITAGS: COMMON NOREFILE NODEADLINE SKIP
:END:
:LOGBOOK:
- State "CANCELLED" from "NEXT" [2021-03-28 Sun 23:59]
CLOCK: [2021-03-28 Sun 23:57]--[2021-03-28 Sun 23:59] => 0:02
- Refiled on [2021-02-27 Sat 20:47]
- Refiled on [2021-01-19 Tue 10:20]
:END:
:BIBTEX:
#+begin_src bibtex
@misc{1443107e70e8b4e1d6d17499e546a8603b98d03e,
author = {/u/zainab-ali},
howpublished = {Reddit:emacs},
keywords = {emacs},
note = {Online; accessed 19 January 2021},
title = {M-x emacs-reddit: pair-tree: a learning tool for
visualizing Elisp lists},
url =
{https://www.reddit.com/r/emacs/comments/kzeyun/pairtree_a_learning_tool_for_visualizing_elisp/},
year = 2021,
}
#+end_src
:END:
***** CANCELLED /u/__g_p__ [Reddit:emacs] (2022) draw-tree.el :BOOKMARK:misc:CANCELLED:
:PROPERTIES:
:TITLE: draw-tree.el
:BTYPE: misc
:ID: Reddit-emacs-/u/__g_p__2022-draw-tree-el-78e
:AUTHOR: /u/__g_p__
:CREATED: [2022-04-13 Wed 22:50]
:HOWPUBLISHED: Reddit:emacs
:KEYWORDS: emacs
:NOTE: Online; accessed 13 April 2022
:RSS: https://www.reddit.com/r/emacs/comments/u2ca5c/drawtreeel/.rss
:URL: https://www.reddit.com/r/emacs/comments/u2ca5c/drawtreeel/
:YEAR: 2022
:ARCHIVE_TIME: 2022-04-29 Fri 17:33
:ARCHIVE_FILE: ~/Org/notes.org
:ARCHIVE_OLPATH: Topics/Software/Emacs \ org-mode/No deadline
:ARCHIVE_CATEGORY: Emacs[D]
:ARCHIVE_TODO: CANCELLED
:ARCHIVE_ITAGS: COMMON NOREFILE NODEADLINE SKIP
:END:
:LOGBOOK:
- State "CANCELLED" from "TODO" [2022-04-28 Thu 22:56]
- Refiled on [2022-04-14 Thu 08:00]
:END:
^ permalink raw reply [relevance 4%]
* Convert a Lisp expression to a tree diagram
@ 2022-06-30 14:19 9% Juan Manuel Macías
2022-06-30 15:17 4% ` Ihor Radchenko
2022-06-30 16:21 6% ` arthur miller
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-30 14:19 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: PDF export, table of contents and internal links
2022-06-29 22:02 5% ` Sébastien Gendre
@ 2022-06-30 11:41 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-30 11:41 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: PDF export, table of contents and internal links
2022-06-29 19:56 9% ` Juan Manuel Macías
@ 2022-06-29 22:02 5% ` Sébastien Gendre
2022-06-30 11:41 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Sébastien Gendre @ 2022-06-29 22:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Thanks for your advice.
You remember me that, in the past, I had modified
"org-latex-pdf-process". I just forget about it.
By looking this variable with "describe-variable", I see its default
value is:
"latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f"
I modified it to be:
"%latex -shell-escape -interaction nonstopmode -output-directory %o %f"
Because, when I wanted to add "-shell-escape" option to latexmk, it
seemed too complex to me.
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.
Do you have good articles or book to suggest about this part of LaTeX ?
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 ?
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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
^ permalink raw reply [relevance 5%]
* Re: PDF export, table of contents and internal links
@ 2022-06-29 19:56 9% ` Juan Manuel Macías
2022-06-29 22:02 5% ` Sébastien Gendre
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-29 19:56 UTC (permalink / raw)
To: Sébastien Gendre; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: Org mode export accessibility
2022-06-26 10:46 10% ` Org mode export accessibility Juan Manuel Macías
@ 2022-06-26 10:54 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-06-26 10:54 UTC (permalink / raw)
To: Juan Manuel Macías, T.V Raman; +Cc: Tim Cross, orgmode
Let me take a freedom to add T.V Raman to the discussion. This thread
might be of interest for him and he probably knows a lot more about
accessibility options.
This thread starts at
https://list.orgmode.org/87v8sn3obd.fsf@gmail.com/T/#u
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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
^ permalink raw reply [relevance 6%]
* Re: Org mode export accessibility
@ 2022-06-26 10:46 10% ` Juan Manuel Macías
2022-06-26 10:54 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-26 10:46 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: Org and Hyperbole
2022-06-25 14:32 9% ` Juan Manuel Macías
@ 2022-06-25 20:35 1% ` Robert Weiner
0 siblings, 0 replies; 200+ results
From: Robert Weiner @ 2022-06-25 20:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Good idea, Juan. I’m all for quick ways to activate buttons without losing your current context. I’ll take a look at how we might support this as an optional load.
-- Bob
> On Jun 25, 2022, at 10:32 AM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> 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
^ permalink raw reply [relevance 1%]
* Re: Org and Hyperbole
2022-06-24 22:06 6% ` Robert Weiner
@ 2022-06-25 14:32 9% ` Juan Manuel Macías
2022-06-25 20:35 1% ` Robert Weiner
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-25 14:32 UTC (permalink / raw)
To: rswgnu; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Org inside LaTeX (a poor man's approach with LuaTeX)
@ 2022-06-25 3:10 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-25 3:10 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
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
[-- Attachment #2: test.tex --]
[-- Type: application/x-tex, Size: 1541 bytes --]
^ permalink raw reply [relevance 8%]
* Re: Org and Hyperbole
2022-06-24 13:52 7% ` Juan Manuel Macías
@ 2022-06-24 22:06 6% ` Robert Weiner
2022-06-25 14:32 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Robert Weiner @ 2022-06-24 22:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 6013 bytes --]
Hi Juan:
Thanks for the positive thoughts on Hyperbole. I must say everyone here
has a great attitude and writes thoughtfully from what I have seen.
It seems like you are off to a good start utilizing core features as you
get familiar with them and then adding on across time.
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?
-- rsw
On Fri, Jun 24, 2022 at 9:52 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> 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: rsw@gnu.org, I'll likely see your message faster and respond.
>
>
[-- Attachment #2: Type: text/html, Size: 7561 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org and Hyperbole
@ 2022-06-24 13:52 7% ` Juan Manuel Macías
2022-06-24 22:06 6% ` Robert Weiner
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-24 13:52 UTC (permalink / raw)
To: rswgnu; +Cc: orgmode
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: rsw@gnu.org, I'll likely see your message faster and respond.
^ permalink raw reply [relevance 7%]
* Re: Org and Hyperbole
2022-06-22 10:37 9% ` Juan Manuel Macías
2022-06-22 14:35 4% ` Bill Burdick
@ 2022-06-22 19:17 6% ` David Masterson
1 sibling, 0 replies; 200+ results
From: David Masterson @ 2022-06-22 19:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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?
KOutline has a much larger set of commands for working with outlines.
However, that's an example of complexity in that it's a lot to keep in
your head. The permanent (hidden) ids make it possible to build (say) a
personal Wiki of information where rearranging the outline doesn't mess
up the links.
> 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.
I tended to look at EXWM, but didn't get too far. I may look at
Hycontrol again...
> 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.
Have you looked at Hydra? But Hyperbole's implicit links are better.
--
David Masterson
^ permalink raw reply [relevance 6%]
* Re: Org and Hyperbole
2022-06-22 10:37 9% ` Juan Manuel Macías
@ 2022-06-22 14:35 4% ` Bill Burdick
2022-06-22 19:17 6% ` David Masterson
1 sibling, 0 replies; 200+ results
From: Bill Burdick @ 2022-06-22 14:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: David Masterson, orgmode
[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]
Here's a hyperbole-org integration that lets you use org-mode tables
outside of org-mode files. Shift-middle-click a "recalc" button and it will
recalculate the table right under it (this idea is from an old version of
the Oberon environment I wrote in Java, by the way).
Here's the code:
(defun bill/calc (end)
(goto-char end)
(re-search-forward "\n")
(when (org-at-table-p)
(org-table-analyze)
(let* ((table-start (point))
(rows (1- (length org-table-dlines)))
(table-end (re-search-forward "\n" nil t rows))
(inside (<= table-start action-key-depress-prev-point
table-end)))
(when inside
(goto-char action-key-depress-prev-point)
(org-table-maybe-eval-formula))
(goto-char table-start)
(call-interactively 'org-table-recalculate)
(org-table-align))))
(defib recalc ()
"recalculate a table"
(save-excursion
(let* ((pos (point))
(eol (progn (re-search-forward "\n") (point)))
(bol (progn (re-search-backward "\n" nil t 2) (1+ (point))))
(start (progn (goto-char pos) (re-search-backward "<" bol t)))
(end (progn (goto-char pos) (re-search-forward ">" eol t))))
;;(message "pos: %s, prev: %s" (point) action-key-depress-prev-point)
(and start end (string-match "<recalc[> ].*" (buffer-substring start
end))
(hact 'bill/calc end)))))
Here's an example table you can put anywhere. Just shift-middle-click on it
to recalculate the org-mode table. Also, if you type a formula (and keep
the cursor on the same line) and then shift-click recalc, it'll handle the
formula:
<recalc>
| a | 12 |
| a | 5 |
#+TBLFM: @1$2=3*4::@2$2=2+3
-- Bill
On Wed, Jun 22, 2022 at 1:38 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 5104 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Org and Hyperbole
2022-06-20 16:24 4% ` indieterminacy
@ 2022-06-22 14:48 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-22 14:48 UTC (permalink / raw)
To: indieterminacy; +Cc: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: Org and Hyperbole
2022-06-21 3:08 5% ` David Masterson
@ 2022-06-22 10:37 9% ` Juan Manuel Macías
2022-06-22 14:35 4% ` Bill Burdick
2022-06-22 19:17 6% ` David Masterson
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-22 10:37 UTC (permalink / raw)
To: David Masterson; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: About 'inline special blocks'
2022-06-21 16:39 6% ` Max Nikulin
@ 2022-06-21 18:19 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-21 18:19 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: About 'inline special blocks'
2022-06-20 19:06 7% ` Juan Manuel Macías
@ 2022-06-21 16:39 6% ` Max Nikulin
2022-06-21 18:19 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-06-21 16:39 UTC (permalink / raw)
To: emacs-orgmode
On 21/06/2022 02:06, Juan Manuel Macías wrote:
> 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 <img alt="Description"> and
>> <a href="..." title="Description"> 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.
Juan Manuel, your answer is not clear for me. Direct formatting is
another issue. There are cases when attributes are part of *content*,
not formatting. If alternative text for images and description of links
are not convincing, there is e.g.
Org document may be exported as
<abbr title="HyperText Markup Language">HTML</abbr> file.
Do you consider inline special blocks solely for formatting and only for
the kind of it that may be expressed through styles? Then attributes for
inline objects should be another feature with its own syntax.
>>> in html:
>>> <name>contents></name>
>>
>> Concerning <name> vs. <span class="name">, is it the same for
>> assistive technologies like screen readers to add
>> <strong>text</strong> (or <b>text</b>) and <span
>> class="strong">text</span> with "font-weight: bolder;" in CSS?
>
> "<name>contents></name>": it was my confusion, sorry. I already explained
> it here: https://list.orgmode.org/8735g0tnoh.fsf@posteo.net/
I am unsure that <name>content</name> should not be supported at all.
However I admit that difference of the following code may be
insignificant in reality:
<strong class="alert">Do not do it!</strong>
vs.
<span role="strong" class="alert">Do not do it!</span>
^ permalink raw reply [relevance 6%]
* Re: Org and Hyperbole
2022-06-20 14:03 10% Org and Hyperbole Juan Manuel Macías
` (3 preceding siblings ...)
2022-06-20 16:24 4% ` indieterminacy
@ 2022-06-21 3:08 5% ` David Masterson
2022-06-22 10:37 9% ` Juan Manuel Macías
4 siblings, 1 reply; 200+ results
From: David Masterson @ 2022-06-21 3:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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...
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.
--
David Masterson
^ permalink raw reply [relevance 5%]
* Re: Org and Hyperbole
2022-06-20 15:26 6% ` Russell Adams
@ 2022-06-20 23:37 0% ` Tim Cross
1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2022-06-20 23:37 UTC (permalink / raw)
To: emacs-orgmode
Russell Adams <RLAdams@adamsinfoserv.com> writes:
> On Mon, Jun 20, 2022 at 02:03:15PM +0000, Juan Manuel Macías wrote:
>> 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...
>
> Juan,
>
> I've often wondered the same thing. I've looked at Hyperbole several
> times. They have been great at advertising when a new release
> occurs. Yet I find that I can't really find a useful feature in it
> that I don't get from Org-mode.
>
> Is there some keen feature I'm missing? What's the use case for
> Hyperbole if you're already an Org-mode user?
>
> https://www.adamsinfoserv.com/
My experiences with it mirror yours. It looked interesting and there
were some ideas which sounded interesting, but when I came to use it, I
found little, if anything, which didn't have a close equivalence in org
mode and many things in org mode which it did not have.
In the end, it came down to asking myself do I really want yet another
information management framework in my life and the answer was no. I do
vaguely recall (it was a while ago) there were some ideas I thought
would be good to add to org mode though. Unfortunately, I cannot recall
the details now.
^ permalink raw reply [relevance 0%]
* Re: About 'inline special blocks'
2022-06-20 16:57 5% ` Max Nikulin
2022-06-20 19:06 7% ` Juan Manuel Macías
@ 2022-06-20 22:46 0% ` Tim Cross
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2022-06-20 22:46 UTC (permalink / raw)
To: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 19/06/2022 19:47, Juan Manuel Macías wrote:
> Concerning <name> vs. <span class="name">, is it the same for assistive
> technologies like screen readers to add <strong>text</strong> (or <b>text</b>)
> and <span class="strong">text</span> with "font-weight: bolder;" in CSS?
First, never use <b></b> or <it></it>, only use semantic tags for
accessibility.
The question unfortunately has a complicated answer. Basically, <div>
and <span> are the two tags which have no semantic meaning. So, from an
accessibility perspective, they don't convey anything. They are
basically a presentation layout tgag.
However, this is not a bad thing, but rather a very good thing. This
touches on the area where far too many people get accessibility wrong.
It is like the very misguided rule which says all images must have an
alt tag. The key point to consider is whether what your communicating
via layout has any real use for someone using a screen reader. Consider
something like
#+being_src
<section aria-label="section label">
<h3>Section Title</h3>
<section class="fancy-css-class">
<section class="some-css-class">
Some Content wrapped within multiple section elements.
</section>
</section>
...
</section>
#+end_src
The inner <section> is being used to avoid using a <div> in the mistaken
belief that using a <div> (or <span>) would be bad for accessibility.
Unfortunately, the above wil often result in the screen reader reading
out "Seciton section section SOme content" (some screen readers would
ignore the inner section as it has no aria tag).
Same sort of problem occurred with the rule about images must have an
'alt' tag. I cannot count the number of pages I visit where the screen
reader says "logo logo filler righ pad left pad filler logo brand".
So, the span tag is great for accessibility when what the author is
trying to convey is layout information or styling information which is
of no use to blind or VI users. Often such style emphasis is used to
assist sighted users who can quickly scan the page. Blind and VI users
cannot scan in the same way. What is more important for us is the
ability to get an overview of the semantic content of the page -
sections, table, lists etc.
Sadly, org isn't great from an accessibility perspective. This is
something I would like to see improved, but it is a huge and complex
task. There are some 'easy' winds we could try. For example, org still
defaults to using the <b></b> and <i></i> tags instead of
<strong></strong> and <em></em>. Likewise, we should move to html5 as
the default, not xhtml, but last time I raised that, there was
considerable push back to stick with xhtml. We also need complete
overhaul of the use of aria tags and numerous other areas. As I said, a
very large job which is complex and extremely time consuming.
Sadly, I'm not sure there is a lot we can do with accessibility and PDFs
in org mode. This is the one area where TeX/LaTeX does a poor job. Last
time I looked, there was considerable discussion about what to do from
an accessibility standpoint in the TeX community, but seemed to be
little or very slow progress (not a criticism of the efforts of members
of that community, but rather a reflection of how complicated this stuff
is).
^ permalink raw reply [relevance 0%]
* Re: Org and Hyperbole
@ 2022-06-20 23:28 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-20 23:28 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: About 'inline special blocks'
2022-06-20 16:57 5% ` Max Nikulin
@ 2022-06-20 19:06 7% ` Juan Manuel Macías
2022-06-21 16:39 6% ` Max Nikulin
2022-06-20 22:46 0% ` Tim Cross
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-20 19:06 UTC (permalink / raw)
To: orgmode
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 <img alt="Description"> and
> <a href="..." title="Description"> 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}{FF0000}
\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:
>> <name>contents></name>
>
> Concerning <name> vs. <span class="name">, is it the same for
> assistive technologies like screen readers to add
> <strong>text</strong> (or <b>text</b>) and <span
> class="strong">text</span> with "font-weight: bolder;" in CSS?
"<name>contents></name>": it was my confusion, sorry. I already explained
it here: https://list.orgmode.org/8735g0tnoh.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* [BUG] manual: confusing example of adding attributes to a link (affiliated keywords)
@ 2022-06-20 16:25 4% Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-06-20 16:25 UTC (permalink / raw)
To: emacs-orgmode
Hi,
Org Manual in info "(org) Links in HTML export"
https://orgmode.org/manual/Links-in-HTML-export.html has the following
example:
> Org files can also have special directives to the HTML export
> back-end. For example, by using ‘#+ATTR_HTML’ lines to specify new
> format attributes to <a> or <img> tags. This example shows changing
> the link’s title and style:
>
> #+ATTR_HTML: :title The Org mode homepage :style color:red;
> [[https://orgmode.org]]
Likely I have seen similar suggestions in this list as well.
Actually it assigns attribute to paragraphs in addition to links. That
is why, I think, this fragment should be removed from manual as a
confusing one since it gives impression of support of per-link attributes.
Attributes assigned through affiliated keywords belongs to paragraph
(block-level element), not to link (inline object). Actual result of export:
<p title="The Org mode homepage" style="color:red;">
<a href="https://orgmode.org" title="The Org mode homepage"
style="color:red;">https://orgmode.org</a>
</p>
If it were possible to set attributes to links, the result should be
<p>
<a href="https://orgmode.org" title="The Org mode homepage"
style="color:red;">https://orgmode.org</a>
</p>
The reason of my expectation is that a paragraph may have more than one
link with different titles.
I am unsure if formal bug report will help. I promised it in the
following discussion:
Max Nikulin to emacs-orgmode. Re: Org-syntax: Intra-word markup. Thu, 3
Feb 2022 19:10:19 +0700. https://list.orgmode.org/stggnf$d8g$1@ciao.gmane.io
A similar complain:
Anton Linevych. How to add extra attributes to link in Org-mode?
2017-06-21 https://linevi.ch/en/org-link-extra-attrs.html
The reason why I have decided to post this bug report now is the
following message:
Juan Manuel Macías to emacs-orgmode. Re: About 'inline special blocks'
Sun, 19 Jun 2022 12:47:40 +0000.
https://list.orgmode.org/875ykwvmz7.fsf@posteo.net
It states that styles and similar stuff may solve the issue with
attributes for inline objects. From my point of view it is wrong and in
some cases per-object attributes are necessary. While <a rel="nofollow
noreferrer" href="..."> or <a target="_blank" href="..."> may be added
through style, attributes like "alt" for images, "title", "lang", etc.
for links are individual.
I am aware of the following post:
J. Kitchin. Extending the org-mode link syntax with attributes.
2015-02-05
http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
The recipe solves the problem, but this time the topic of inline special
blocks has been risen in the context of limitations in Org markup making
it inappropriate tool for GNU manuals in general and the Org manual in
particular. So some more general solution is required than local
customization.
So as outcome for this bug report I expect that either caveats related
to affiliated keywords are clearly stated in the manual or some
"official" way to assign attributes for specific inline objects is
introduced.
^ permalink raw reply [relevance 4%]
* Re: About 'inline special blocks'
2022-06-19 12:47 8% ` Juan Manuel Macías
2022-06-19 19:30 5% ` Christian Moe
2022-06-19 22:18 5% ` Tim Cross
@ 2022-06-20 16:57 5% ` Max Nikulin
2022-06-20 19:06 7% ` Juan Manuel Macías
2022-06-20 22:46 0% ` Tim Cross
2 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2022-06-20 16:57 UTC (permalink / raw)
To: emacs-orgmode
On 19/06/2022 19:47, Juan Manuel Macías wrote:
>
> 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.
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 <img alt="Description"> and <a href="..."
title="Description"> attributes that are namely per-object, not part of
style.
I was going to raise this issue for several months, so I just have sent
to following bug report:
Max Nikulin to emacs-orgmode. [BUG] manual: confusing example of adding
attributes to a link (affiliated keywords) Mon, 20 Jun 2022 23:25:29
+0700. https://list.orgmode.org/t8q71r$mgv$1@ciao.gmane.io
I have not heard that PDF offers something similar, but e.g. link with
title may be exported as footnote with title text and URL instead of
inline link. However to handle such cases generic attributes available
to all export backends should be introduced.
Even when styles are enough in principle, attributes may be more
convenient since the latter may be composable, so making unnecessary
defining every possible (or used) combination of styles.
> in html:
>
> <name>contents></name>
Concerning <name> vs. <span class="name">, is it the same for assistive
technologies like screen readers to add <strong>text</strong> (or
<b>text</b>) and <span class="strong">text</span> with "font-weight:
bolder;" in CSS?
^ permalink raw reply [relevance 5%]
* Re: Org and Hyperbole
2022-06-20 14:03 10% Org and Hyperbole Juan Manuel Macías
` (2 preceding siblings ...)
2022-06-20 16:09 6% ` Bill Burdick
@ 2022-06-20 16:24 4% ` indieterminacy
2022-06-22 14:48 7% ` Juan Manuel Macías
2022-06-21 3:08 5% ` David Masterson
4 siblings, 1 reply; 200+ results
From: indieterminacy @ 2022-06-20 16:24 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On 20-06-2022 16:03, Juan Manuel Macías wrote:
> 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...
>
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.
While I have not fully applied this technique to my workflow, you can
see some /stub/ experimentations that are used to provide different
function calls based upon where the cursor is in the context of a
specific annotation (namely my annotation approach, Qiuy).
https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/cqc_mqm_interfacing_blooms.el
The logic for the example includes:
<function-call> <function-name> <opening-regex> <closing-regex>
<cursor-regex> <result-from-context> <options>
As you see below, these things build through to build multiple cursor
based contexts.
```
(defil qiuy-1q10hqh_1 "^" "q10hqh.*" "1" "{M-: (print \"context_1 1q\")
RET}" t t)
(defil qiuy-1q10hqh_2 "^1" "10hqh.*" "q" "{M-: (print \"context_2
[1-6]q\") RET}" t t)
(defil qiuy-1q10hqh_3 "^1q" "0hqh.*" "1" "{M-: (print \"context_3
1q10\") RET}" t t)
(defil qiuy-1q10hqh_4 "^1q1" "hqh.*" "0" "{M-: (isearch-forward-symbol
\"q10\") RET}" t t)
(defil qiuy-1q10hqh_5 "^1q10" "qh.*" "h" "{M-: (rg-project \"hqh\"
\".*\") RET}" t t)
(defil qiuy-1q10hqh_6 "^1q10h" "h.*" "q" "{M-: (print \"context_6
1q10hqh\") RET}" t t)
(defil qiuy-1q10hqh_7_\s "^1q10hqh" "$" "\s(.*)" "{M-: (print
\"context_7_\s 1q10hqh \\&\") RET}" t t)
(defil qiuy-1q10hqh_7_\t "^1q10hqh" "$" "\t(.*)" "{M-: (print
\"context_7_\t 1q10hqh \\&\") RET}" t t)
(defil qiuy-1q10hqh_7_- "^1q10hqh" "$" "-(.*)" "{M-: (print
\"context_7_- 1q10hqh \\&\") RET}" t t)
(defil qiuy-1q10hqh_7__ "^1q10hqh" "$" "_(.*)" "{M-: (print
\"context_7__ 1q10hqh \\&\") RET}" t t)
```
Documentation for the function defil can be found here:
https://www.gnu.org/software/hyperbole/man/hyperbole.html#Implicit-Button-Link-Types
The Hyperbole ML is quiet but friendly and informative.
Having examined Hyperbole more broadly, I do wonder if there was more of
a policy to treat Orgmode as more of a parrallel concern.
Today, there is clearly a proactive effort to align and encourage cross
usage.
To hear that somebody as accomplished as yourself is dabbling with
Hyperbole pleases me no end.
It may be worth you visiting one of my knowledge repos here:
https://git.sr.ht/~indieterminacy/3q50cqc_oq_interfaces_emacs
As well as (over time) checking on on these search parameters for my
username:
https://git.sr.ht/~indieterminacy/?search=hyperbole
https://git.sr.ht/~indieterminacy/?search=koutliner
Of note, I should mention my own project, Icebreaker - which has been
augmenting the GemText format with terse syntaxes and formats -
including Hyperboles Koutliner format (which if I understand may be able
to include orgmode tables in its blocks with the new version - I could
be wrong here).
Here is a WIP parser written in TXR - for parsing Koutliner blocks (with
or without my Qiuy annotations) and expressing it as a datalisp:
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean
I shall be tightening it up soon, including integrating it with a WIP
GemText parser (its terser atm but missing a little):
https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext
An NLNet funded project, I am going to later be exporting some of this
information into simple Orgmode syntax as a subset of one of the
deliverables. An earlier protyping is covered here in a more recent
Fosdem talk:
https://fosdem.org/2022/schedule/event/minimalsyntaxes/
Im happy to answer any more questions with regards to this in this
thread or elsewhere.
It may be worth highlighting a matrix room my Icebreaker project runs to
reduce clutter from other MLs.
The members there are friendly, knowledgable and use Orgmode for a range
of tasks:
https://matrix.to/#/#xq_icebreaker:matrix.org
You are a clear and concise writer and coder. I would love to hear the
outcomes from this exploration.
If I recall you are an emacspeak user - which I seem to think has been
praised for its integration with Hyperbole so that should be more than
enough justification to really get into it.
Kind regards,
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 4%]
* Re: Org and Hyperbole
2022-06-20 14:03 10% Org and Hyperbole Juan Manuel Macías
2022-06-20 15:26 6% ` Russell Adams
2022-06-20 15:56 0% ` Uwe Brauer
@ 2022-06-20 16:09 6% ` Bill Burdick
2022-06-20 16:24 4% ` indieterminacy
2022-06-21 3:08 5% ` David Masterson
4 siblings, 0 replies; 200+ results
From: Bill Burdick @ 2022-06-20 16:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
I hadn't heard of it so I'm watching a demo. It looks similar to Oberon
(which heavily influenced Acme and Wily) which is an extremely powerful
"mouse-based text environment".
I'm certainly going to give it a try -- it seems like a great compliment to
org-mode and other Emacs power tools...
-- Bill
On Mon, Jun 20, 2022 at 5:18 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 1569 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org and Hyperbole
2022-06-20 14:03 10% Org and Hyperbole Juan Manuel Macías
2022-06-20 15:26 6% ` Russell Adams
@ 2022-06-20 15:56 0% ` Uwe Brauer
2022-06-20 16:09 6% ` Bill Burdick
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-06-20 15:56 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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...
Quite some time ago (that was at the time org mode was in its infancy) I
gave it a try and found it too confusing and difficult to handle for
every day work.
There were other package that provided similar (well less) functionality
but were much simpler, however they were not stable that is the links
could be damaged during editing. I don't recall the details.
But I am happy with what org mode offers.
Sorry that may have been not that helpful..
Uwe Brauer
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Org and Hyperbole
2022-06-20 14:03 10% Org and Hyperbole Juan Manuel Macías
@ 2022-06-20 15:26 6% ` Russell Adams
2022-06-20 23:37 0% ` Tim Cross
2022-06-20 15:56 0% ` Uwe Brauer
` (3 subsequent siblings)
4 siblings, 2 replies; 200+ results
From: Russell Adams @ 2022-06-20 15:26 UTC (permalink / raw)
To: emacs-orgmode
On Mon, Jun 20, 2022 at 02:03:15PM +0000, Juan Manuel Macías wrote:
> 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...
Juan,
I've often wondered the same thing. I've looked at Hyperbole several
times. They have been great at advertising when a new release
occurs. Yet I find that I can't really find a useful feature in it
that I don't get from Org-mode.
Is there some keen feature I'm missing? What's the use case for
Hyperbole if you're already an Org-mode user?
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
https://www.adamsinfoserv.com/
^ permalink raw reply [relevance 6%]
* Org and Hyperbole
@ 2022-06-20 14:03 10% Juan Manuel Macías
2022-06-20 15:26 6% ` Russell Adams
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-20 14:03 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: About 'inline special blocks'
2022-06-19 12:47 8% ` Juan Manuel Macías
2022-06-19 19:30 5% ` Christian Moe
@ 2022-06-19 22:18 5% ` Tim Cross
2022-06-20 16:57 5% ` Max Nikulin
2 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-06-19 22:18 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
>
Agree. I think your reasoning here is spot on.
> 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.
>
Agreed. In fact, I use in-line blocks so rarely that at first I wasn't
going to respond as I really didn't have much skin in the game when it
comes to inline blocks. The reason I dond't use them much is pretty much
the same as your reasoning above.
> 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.
>
I also like this approach. We need some form of escape hatch. However,
for uncommon edge cases, I would rather have a slightly less convenient
escape hatch and a simple consistent general syntax than a more complex
syntax which is difficult to maintain and keep consistent and reliable.
> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> <name>contents></name>
or should that be <span class="name">contents</name>?
>
> in odt:
>
> <text:span text:style-name="name">contents</text:span>
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
Sound reasoning IMO.
^ permalink raw reply [relevance 5%]
* Re: About 'inline special blocks'
2022-06-19 19:30 5% ` Christian Moe
@ 2022-06-19 20:15 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 20:15 UTC (permalink / raw)
To: Christian Moe; +Cc: orgmode
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
> <name>contents></name>, but <span class="name">contents</span>. 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:<span class="$1">$2</span>@@@@latex:\$1{$2}@@@@odt:<text:span text:style-name="$1">$2</text:span>@@
> #+html_head: <style>.highlight {background-color: yellow;}
> #+html_head: .smallcaps {font-variant: small-caps;}</style>
>
> 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
^ permalink raw reply [relevance 9%]
* Re: About 'inline special blocks'
2022-06-19 12:47 8% ` Juan Manuel Macías
@ 2022-06-19 19:30 5% ` Christian Moe
2022-06-19 20:15 9% ` Juan Manuel Macías
2022-06-19 22:18 5% ` Tim Cross
2022-06-20 16:57 5% ` Max Nikulin
2 siblings, 1 reply; 200+ results
From: Christian Moe @ 2022-06-19 19:30 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías writes:
> To add some ideas that have been occurring to me these days...
>
Hi,
This makes sense to me.
Note: For the html output in your example, I expect you don't mean
<name>contents></name>, but <span class="name">contents</span>. That
would give the desired custom style controle of the output, and would
parallel the behavior of special blocks.
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:<span class="$1">$2</span>@@@@latex:\$1{$2}@@@@odt:<text:span text:style-name="$1">$2</text:span>@@
#+html_head: <style>.highlight {background-color: yellow;}
#+html_head: .smallcaps {font-variant: small-caps;}</style>
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
Yours,
Christian
> 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:
>
> <name>contents></name>
>
> in odt:
>
> <text:span text:style-name="name">contents</text:span>
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 5%]
* Re: Keybinding doubt about ARG
@ 2022-06-19 17:21 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 17:21 UTC (permalink / raw)
To: Bruno Barbier; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: About 'inline special blocks'
2022-05-23 15:20 4% ` Kaushal Modi
2022-05-23 21:06 9% ` Juan Manuel Macías
@ 2022-06-19 12:47 8% ` Juan Manuel Macías
2022-06-19 19:30 5% ` Christian Moe
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-19 12:47 UTC (permalink / raw)
To: orgmode
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:
<name>contents></name>
in odt:
<text:span text:style-name="name">contents</text:span>
and so on.
In short, I think it would be enough to simply implement something like
this.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [Tip] Screenshots as org links with EMMS and socat
@ 2022-06-18 14:35 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-18 14:35 UTC (permalink / raw)
To: orgmode
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
^ permalink raw reply [relevance 7%]
* Re: About 'inline special blocks'
@ 2022-06-17 19:49 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-17 19:49 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> 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
^ permalink raw reply [relevance 10%]
* Re: Utility of description lists
@ 2022-06-17 14:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-17 14:24 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
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.fsf@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
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-14 11:55 6% ` Ihor Radchenko
@ 2022-06-15 10:30 9% ` Juan Manuel Macías
2022-07-21 13:44 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-15 10:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> The original proposal by Eric Schulte:
> https://list.orgmode.org/4BFFEE4F.5010608@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
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-14 11:11 8% ` Juan Manuel Macías
@ 2022-06-14 11:55 6% ` Ihor Radchenko
2022-06-15 10:30 9% ` Juan Manuel Macías
2022-07-21 13:44 8% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-06-14 11:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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:
The original proposal by Eric Schulte:
https://list.orgmode.org/4BFFEE4F.5010608@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.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-14 3:58 6% ` Ihor Radchenko
@ 2022-06-14 11:11 8% ` Juan Manuel Macías
2022-06-14 11:55 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-14 11:11 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-11 11:20 9% ` Juan Manuel Macías
@ 2022-06-14 3:58 6% ` Ihor Radchenko
2022-06-14 11:11 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-06-14 3:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> My first approach was actually to define some options for
> org-babel-process-comment. But I noticed that a header with properties,
> for example:
> ...
>
> I think the culprit is the '(match-end 0)' in
> org-babel-tangle-single-block:
>
> ...
> (org-back-to-heading t) ; Sets match data
> (match-end 0)) ;; <=========
> (error (point-min)))
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.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-13 8:24 6% ` Rudolf Adamkovič
@ 2022-06-13 10:22 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-13 10:22 UTC (permalink / raw)
To: Rudolf Adamkovič; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-12 19:55 9% ` Juan Manuel Macías
@ 2022-06-13 8:24 6% ` Rudolf Adamkovič
2022-06-13 10:22 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Rudolf Adamkovič @ 2022-06-13 8:24 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> but in this way:
>
> ------------------------------------
> ;; Variables
> ;; ==========
> ;; Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
> ;; hendrerit tempor tellus. Donec pretium posuere tellus.
> ------------------------------------
Hello again, Juan!
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.
Rudy
--
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932
Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
^ permalink raw reply [relevance 6%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-12 19:18 6% ` Rudolf Adamkovič
@ 2022-06-12 19:55 9% ` Juan Manuel Macías
2022-06-13 8:24 6% ` Rudolf Adamkovič
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-12 19:55 UTC (permalink / raw)
To: Rudolf Adamkovič; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-10 18:28 8% [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
2022-06-11 5:39 6% ` Ihor Radchenko
@ 2022-06-12 19:18 6% ` Rudolf Adamkovič
2022-06-12 19:55 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Rudolf Adamkovič @ 2022-06-12 19:18 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> As usual, feedback and suggestions for this patch are greatly
> appreciated.
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?
Rudy
--
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969
Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
^ permalink raw reply [relevance 6%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-11 5:39 6% ` Ihor Radchenko
@ 2022-06-11 11:20 9% ` Juan Manuel Macías
2022-06-14 3:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-11 11:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
2022-06-10 18:28 8% [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
@ 2022-06-11 5:39 6% ` Ihor Radchenko
2022-06-11 11:20 9% ` Juan Manuel Macías
2022-06-12 19:18 6% ` Rudolf Adamkovič
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-06-11 5:39 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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,
Thanks for the patch!
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.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
@ 2022-06-10 18:28 8% Juan Manuel Macías
2022-06-11 5:39 6% ` Ihor Radchenko
2022-06-12 19:18 6% ` Rudolf Adamkovič
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-10 18:28 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-tangle.el-add-the-ascii-value-to-the-comment.patch --]
[-- Type: text/x-patch, Size: 2671 bytes --]
From 414e0b3a18abca34bc47f07e55debec0910d4728 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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
^ permalink raw reply related [relevance 8%]
* Re: Org-attach for a directory
[not found] ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
@ 2022-06-09 10:11 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-06-09 10:11 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
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.fsf@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
^ permalink raw reply [relevance 8%]
* Re: Org-attach for a directory
@ 2022-06-08 10:32 9% ` Juan Manuel Macías
[not found] ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-06-08 10:32 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
2022-05-31 5:06 6% ` Ihor Radchenko
@ 2022-05-31 11:00 8% ` Juan Manuel Macías
2022-07-04 11:44 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-31 11:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
2022-05-30 15:36 9% ` Juan Manuel Macías
@ 2022-05-31 5:06 6% ` Ihor Radchenko
2022-05-31 11:00 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-31 5:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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).
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?
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: # Comments export
2022-05-30 10:46 10% ` Juan Manuel Macías
@ 2022-05-30 21:49 5% ` Tim Cross
0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2022-05-30 21:49 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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:span text:background=\"#FFFF00\">%s</text:span>" 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.fsf@posteo.net/
>
I think this is a much better solution. I don't like the idea of adding
the ability to export comments - the whole point of comments are to
provide content which is NOT exported. If you find you have content as
comments which you then want to export, my view would be that these are
not 'comments' in the sense of org-mode. These sound like notes or
annotations and there is likely a better approach than treating them as
org comments. Org comments are probably best thought of as comments
about org content and not org content per se. If you want your comments
to appear as part of yhour exported data at some level, they are no
longer comments, but rather a different class of content and should be
categorised using one of the org content block types or a footnote.
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
2022-05-30 5:10 6% ` Ihor Radchenko
@ 2022-05-30 15:36 9% ` Juan Manuel Macías
2022-05-31 5:06 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-30 15:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: # Comments export
@ 2022-05-30 10:46 10% ` Juan Manuel Macías
2022-05-30 21:49 5% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-30 10:46 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
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:span text:background=\"#FFFF00\">%s</text:span>" 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.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
@ 2022-05-30 5:10 6% ` Ihor Radchenko
2022-05-30 15:36 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-30 5:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I believe that an html attribute to display marginal verse numbers in
> sequence could be useful for certain content, as philological texts
> (like here:
> https://en.wikisource.org/wiki/The_Iliad_and_Odyssey_of_Homer_(Cowper)/Volume_2/The_Odyssey/Book_I)
>
> The `lines' property must be a digit that is equivalent to the verse
> numbers sequence:
>
> #+ATTR_HTML: :lines 5
> #+begin_verse
> some verses...
> #+end_verse
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.
Similarly, line numbering support can be implemented across more
export backends.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [tip] org-publish to work with (very) large books
2022-05-29 12:15 5% ` Ihor Radchenko
@ 2022-05-29 18:01 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-29 18:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 6%]
* Re: [tip] org-publish to work with (very) large books
2022-05-28 8:59 6% ` Juan Manuel Macías
@ 2022-05-29 12:15 5% ` Ihor Radchenko
2022-05-29 18:01 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-29 12:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
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.
> 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/
Thanks! This is interesting.
> 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
For me, the main problem with LuaTeX is that it is generally not
supported by publishers I deal with. Mostly, LaTeX is the requirement.
Some even demand Word documents ):
Hence, all the advanced features of LuaTeX cannot be used in real my
real publications and I cannot convince myself to dedicate time for
playing around with LuaTeX.
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?
>>> 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.
I see. After watching the video more carefully, I do see the your org
file only had the bibliographies. Not the actual book text.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: how to export an org file, to 2 different locations (in to different formats)
2022-05-28 8:40 1% ` Uwe Brauer
@ 2022-05-28 9:06 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-28 9:06 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: [tip] org-publish to work with (very) large books
2022-05-28 3:02 5% ` Ihor Radchenko
@ 2022-05-28 8:59 6% ` Juan Manuel Macías
2022-05-29 12:15 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-28 8:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 6%]
* Re: how to export an org file, to 2 different locations (in to different formats)
2022-05-28 7:23 8% ` Juan Manuel Macías
@ 2022-05-28 8:40 1% ` Uwe Brauer
2022-05-28 9:06 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-05-28 8:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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:
Aha, I see, thanks
Just one observation, while this is more convenient your other method has the benefit that it allows me to export to 2 files in different locations having the *same* extension like
> # my-latex-export-path: "~/path/myfile1.tex"
> # my-latex-export-path: "~/path/myfile2.tex"
Which seems more complicated in the other approach.
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.
In any case thanks for both solution, that was very generous and helpful.
Developers: why to include some of this code in a addon file, if Juan agrees of course!
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: how to export an org file, to 2 different locations (in to different formats)
2022-05-28 6:36 0% ` Uwe Brauer
@ 2022-05-28 7:23 8% ` Juan Manuel Macías
2022-05-28 8:40 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-28 7:23 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: how to export an org file, to 2 different locations (in to different formats)
2022-05-28 0:18 10% ` Juan Manuel Macías
@ 2022-05-28 6:36 0% ` Uwe Brauer
2022-05-28 7:23 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-05-28 6:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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:
Thanks, that looks even more convenient!
I tried to test it with
#+begin_example
# my-latex-export-path: "./myfile2.tex"
# my-html-export-path "~/Desktop/myfile2.html"
,#+begin_src emacs-lisp :exports none :eval never-export :results silent
(my-org/export-to-path 'html "~/Desktop/" "html")
,#+end_src
,#+begin_src emacs-lisp :exports none :eval never-export :results silent
(my-org/export-to-path 'latex "./" "tex")
,#+end_src
,* Excuses
Jim: Which was? Sir Humphrey:
#+end_example
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.
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [tip] org-publish to work with (very) large books
2022-05-27 11:39 8% ` Juan Manuel Macías
@ 2022-05-28 3:02 5% ` Ihor Radchenko
2022-05-28 8:59 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-28 3:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
> 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
Thanks for the clarification! So, you are previewing the whole book with
some \input statements commented out. It is an ok approach, unless you
need cross-references between chapters.
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/
Also, FYI:
https://web.archive.org/web/20160712215709/http://www.howtotex.com:80/tips-tricks/faster-latex-part-iv-use-a-precompiled-preamble/
> 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).
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: how to export an org file, to 2 different locations (in to different formats)
2022-05-27 18:42 9% ` Juan Manuel Macías
@ 2022-05-28 0:18 10% ` Juan Manuel Macías
2022-05-28 6:36 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-28 0:18 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 10%]
* Re: how to export an org file, to 2 different locations (in to different formats)
@ 2022-05-27 18:42 9% ` Juan Manuel Macías
2022-05-28 0:18 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-27 18:42 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
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
^ permalink raw reply [relevance 9%]
* Re: [tip] org-publish to work with (very) large books
2022-05-27 4:19 6% ` Ihor Radchenko
@ 2022-05-27 11:39 8% ` Juan Manuel Macías
2022-05-28 3:02 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-27 11:39 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: [tip] org-publish to work with (very) large books
2022-05-26 13:48 8% ` Juan Manuel Macías
2022-05-26 17:47 6% ` Christian Moe
@ 2022-05-27 4:19 6% ` Ihor Radchenko
2022-05-27 11:39 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-05-27 4:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Christian Moe, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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 :-)
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?
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [tip] org-publish to work with (very) large books
2022-05-26 13:48 8% ` Juan Manuel Macías
@ 2022-05-26 17:47 6% ` Christian Moe
2022-05-27 4:19 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Christian Moe @ 2022-05-26 17:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, Christian Moe, orgmode
Thanks, Juan!
Yours,
Christian
Juan Manuel Macías writes:
> Hi Ihor and Christian,
>
> Ihor Radchenko writes:
>
>> Christian Moe <mail@christianmoe.com> 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
^ permalink raw reply [relevance 6%]
* Re: [tip] org-publish to work with (very) large books
@ 2022-05-26 13:48 8% ` Juan Manuel Macías
2022-05-26 17:47 6% ` Christian Moe
2022-05-27 4:19 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-26 13:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Christian Moe, orgmode
Hi Ihor and Christian,
Ihor Radchenko writes:
> Christian Moe <mail@christianmoe.com> 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
^ permalink raw reply [relevance 8%]
* Re: [tip] org-publish to work with (very) large books
2022-05-26 10:01 5% [tip] org-publish to work with (very) large books Juan Manuel Macías
@ 2022-05-26 12:46 6% ` Christian Moe
0 siblings, 1 reply; 200+ results
From: Christian Moe @ 2022-05-26 12:46 UTC (permalink / raw)
To: emacs-orgmode
Thanks for this, really interesting.
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 couldn't find the :body-only publishing option in the docs ...?
Yours,
Christian
Juan Manuel Macías writes:
> 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: xxxx.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 "_"
> │ (format-time-string "%d-%m-%y"))
> │ (concat (file-name-sans-extension
> │ (file-name-nondirectory master-file-tex))
> │ "_"
> │ (format-time-string "%d-%m-%y")))))
> │ (start-process-shell-command
> │ "project"
> │ "*project*"
> │ (concat
> │ "latexmk"
> │ " -jobname="
> │ jobname
> │ " -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
> │ (file-name-nondirectory master-file-tex)
> │ ".tex")))))))
> └────
^ permalink raw reply [relevance 6%]
* [tip] org-publish to work with (very) large books
@ 2022-05-26 10:01 5% Juan Manuel Macías
2022-05-26 12:46 6% ` Christian Moe
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-26 10:01 UTC (permalink / raw)
To: orgmode
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: xxxx.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 "_"
│ (format-time-string "%d-%m-%y"))
│ (concat (file-name-sans-extension
│ (file-name-nondirectory master-file-tex))
│ "_"
│ (format-time-string "%d-%m-%y")))))
│ (start-process-shell-command
│ "project"
│ "*project*"
│ (concat
│ "latexmk"
│ " -jobname="
│ jobname
│ " -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
│ (file-name-nondirectory master-file-tex)
│ ".tex")))))))
└────
^ permalink raw reply [relevance 5%]
* Re: About 'inline special blocks'
@ 2022-05-25 13:55 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-25 13:55 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
>
> #+attr_latex[name]: <complex config goes here>
> Vestibulum convallis, lorem blockname_[<<name>>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae lacus.
>
> "<<name>>" will be treated as "<complex config goes here>" 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
^ permalink raw reply [relevance 10%]
* Re: About 'inline special blocks'
2022-05-23 21:06 9% ` Juan Manuel Macías
@ 2022-05-24 2:36 6% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Tim Cross @ 2022-05-24 2:36 UTC (permalink / raw)
To: emacs-orgmode
I've not got a lot to add here. I'm not against the idea, but Juan makes
some points below which I think are particularly important and wanted to
add weight to them!
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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_<name>[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:
>
> &_<name>[options]{text}
>
I agree. Selection of the 'symbol' might be tricky, but the idea is
sound.
> 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 :-)
I think this is a really important point. Whenever we add formatting
specific directives, we always end up in a somewhat uncertain situation
with respect to the other back ends. I also feel that in-line blocks
which support large and complex formatting configuration really defeat
the purpose of an in=line block (which I feel should be kept relatively
simple). I also find complex constructs of this form really degrades the
readability of source documents.
>
> 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.
>
Yes, that was my thinking as well.
^ permalink raw reply [relevance 6%]
* Re: About 'inline special blocks'
2022-05-23 15:20 4% ` Kaushal Modi
@ 2022-05-23 21:06 9% ` Juan Manuel Macías
2022-05-24 2:36 6% ` Tim Cross
2022-06-19 12:47 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-23 21:06 UTC (permalink / raw)
To: Kaushal Modi; +Cc: orgmode
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_<name>[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:
&_<name>[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
^ permalink raw reply [relevance 9%]
* Re: About 'inline special blocks'
2022-05-23 14:30 8% About 'inline special blocks' Juan Manuel Macías
@ 2022-05-23 15:20 4% ` Kaushal Modi
2022-05-23 21:06 9% ` Juan Manuel Macías
2022-06-19 12:47 8% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Kaushal Modi @ 2022-05-23 15:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
<maciaschain@posteo.net> wrote:
> 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.
Thanks for doing this. I missed that thread. I would welcome this
feature addition too.
If I understand correctly, this will mean adding a new element type
that all the Org exporters can then support. Right?
> The question is: Does Org Mode need inline special blocks?
Yes.
> On the one hand, it seems that we can live without them.
Not quite. I developed few hacks in ox-hugo to make regular special
blocks act like special inline blocks :D
Example:
=====
More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
#+begin_mark
if someone copies that code to try it out, it will
not work
#+end_mark
!
=====
Another example:
=====
By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
#+begin_sidenote
I planned to fix just this straight quote escaping issue, but then I
also ended up slightly improving the documentation of the ~(FUNC :eval
EVAL)~ and other forms used for adding a function's documentation to
~shortdoc~.
#+end_sidenote
in ..
=====
ox-hugo does the job of deleting the newlines and white-space (leaving
just 1) before and after few "special" special Org blocks.
> Therefore, I think that inline special blocks would fill an important
> gap. They could be translated into HTML as a <span></span> container;
+1
> Perhaps the syntax could be a continuation of that of inline code
> blocks. Something like:
>
> <name>_[options]{text}
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_<name>[options]{text} ?
Using my example above, if I want the <mark> elements in HTML, I would do
abc inline_mark{some text} def
and that would export to below for an HTML based exporter:
abc <mark>some text</mark> def
^ permalink raw reply [relevance 4%]
* About 'inline special blocks'
@ 2022-05-23 14:30 8% Juan Manuel Macías
2022-05-23 15:20 4% ` Kaushal Modi
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-23 14:30 UTC (permalink / raw)
To: orgmode
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 <span></span> 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:
<name>_[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
^ permalink raw reply [relevance 8%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-19 9:40 6% ` Eric S Fraga
@ 2022-05-19 18:01 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-19 18:01 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-17 17:56 8% ` Juan Manuel Macías
2022-05-18 16:14 6% ` Max Nikulin
@ 2022-05-19 9:40 6% ` Eric S Fraga
2022-05-19 18:01 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Eric S Fraga @ 2022-05-19 9:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Tuesday, 17 May 2022 at 17:56, Juan Manuel Macías wrote:
> 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
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.
--
: Eric S Fraga, with org release_9.5.3-504-gcdbb1c in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-17 17:56 8% ` Juan Manuel Macías
@ 2022-05-18 16:14 6% ` Max Nikulin
2022-05-19 9:40 6% ` Eric S Fraga
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-05-18 16:14 UTC (permalink / raw)
To: emacs-orgmode
On 18/05/2022 00:56, Juan Manuel Macías wrote:
> 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.
I expected some drop-in replacement for notify-send that creates native
android notifications might exist
https://github.com/termux/termux-packages/issues/9923
or even more generally an implementation of d-bus server that is
interface to android API
https://specifications.freedesktop.org/notification-spec/latest/ar01s09.html
^ permalink raw reply [relevance 6%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-17 16:22 5% ` Max Nikulin
@ 2022-05-17 17:56 8% ` Juan Manuel Macías
2022-05-18 16:14 6% ` Max Nikulin
2022-05-19 9:40 6% ` Eric S Fraga
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-05-17 17:56 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
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
^ permalink raw reply [relevance 8%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-16 16:05 10% ` Juan Manuel Macías
@ 2022-05-17 16:22 5% ` Max Nikulin
2022-05-17 17:56 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-05-17 16:22 UTC (permalink / raw)
To: emacs-orgmode
On 16/05/2022 23:05, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
> 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...
Do termux and emacs build for it have support of D-Bus or notify-send
binary? The following thread is related to MacOS, but the discussion was
a bit more general. Android notification may have more features though.
stardiviner to emacs-orgmode. [PATCH] make org-notify support for macOS
desktop notification. Sun, 4 Jul 2021 08:23:03 +0800.
https://list.orgmode.org/5B57CD8B-AA91-4C63-A449-A07364083AEE@gmail.com
I have not tried termux, but I agree that it is an interesting project.
Unfortunately it is against various policies (only binaries from the
application package are allowed, even access to filesystem is considered
unsafe, etc.). Unsure if it is possible to implement a kind of
virtualization to hide processes from the host system but to keep
integration with platform. Unfortunately during struggle with
applications requiring unreasonable permissions and with malware,
legitimate applications suffer as well (e.g. KDE Connect).
^ permalink raw reply [relevance 5%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-16 15:00 6% ` Max Nikulin
@ 2022-05-16 16:05 10% ` Juan Manuel Macías
2022-05-17 16:22 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-05-16 16:05 UTC (permalink / raw)
To: Max Nikulin; +Cc: Ihor Radchenko, Eric S. Fraga, orgmode
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
^ permalink raw reply [relevance 10%]
* Re: [tip] Export and open a PDF in Android via Termux
2022-05-16 12:35 6% ` Ihor Radchenko
@ 2022-05-16 15:00 6% ` Max Nikulin
2022-05-16 16:05 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-05-16 15:00 UTC (permalink / raw)
To: emacs-orgmode
On 15/05/2022 18:54, Juan Manuel Macías wrote:
>
> (setq org-file-apps
> '((auto-mode . emacs)
> (directory . emacs)
> ("\\.mm\\'" . default)
> ("\\.x?html?\\'" . default)
> ("\\.pdf\\'" . "termux-open %s")))
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.
^ permalink raw reply [relevance 6%]
* Re: [tip] Export and open a PDF in Android via Termux
@ 2022-05-16 12:35 6% ` Ihor Radchenko
2022-05-16 15:00 6% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-05-16 12:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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")))
Thanks for sharing! I am wondering if tips like this should be added to
worg.
Best,
Ihor
^ permalink raw reply [relevance 6%]
Results 601-800 of ~1600 next (older) | prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-10-03 15:28 [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Juan Manuel Macías
2022-07-10 9:25 6% ` Ihor Radchenko
2022-07-14 12:34 5% ` Juan Manuel Macías
2022-07-14 15:12 5% ` Max Nikulin
2022-07-14 15:53 9% ` Juan Manuel Macías
2022-07-14 18:17 10% ` Juan Manuel Macías
2022-07-15 12:18 5% ` Max Nikulin
2022-07-15 14:36 7% ` Juan Manuel Macías
2022-07-17 9:55 5% ` Ihor Radchenko
2022-07-17 14:48 7% ` Juan Manuel Macías
2022-07-18 6:44 5% ` Ihor Radchenko
2022-07-18 10:32 7% ` Juan Manuel Macías
2022-07-18 11:01 13% ` Juan Manuel Macías
2022-07-18 15:37 6% ` Max Nikulin
2022-07-18 16:21 5% ` Juan Manuel Macías
2022-07-19 15:01 4% ` Juan Manuel Macías
2022-07-19 17:01 5% ` Max Nikulin
2022-07-19 19:31 7% ` Juan Manuel Macías
2022-07-20 16:12 6% ` Max Nikulin
2022-07-20 21:30 9% ` Juan Manuel Macías
2022-07-21 14:36 5% ` Max Nikulin
2022-07-21 15:39 10% ` Juan Manuel Macías
2022-07-22 12:16 7% ` Max Nikulin
2022-07-22 12:49 9% ` Juan Manuel Macías
2022-07-22 14:07 12% ` Juan Manuel Macías
2022-07-23 15:19 5% ` Max Nikulin
2022-07-23 17:15 8% ` Improvements in the default LaTeX preamble (was: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists) Juan Manuel Macías
2022-07-24 12:06 8% ` Improvements in the default LaTeX preamble: templates? " Juan Manuel Macías
2022-07-25 9:31 5% ` Ihor Radchenko
2022-07-25 10:45 8% ` Improvements in the default LaTeX preamble: templates? Juan Manuel Macías
2022-07-23 5:01 6% ` [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Ihor Radchenko
2022-07-23 14:11 10% ` Juan Manuel Macías
2022-07-23 14:25 6% ` Ihor Radchenko
2022-07-23 15:29 0% ` Max Nikulin
2022-07-24 7:23 0% ` Ihor Radchenko
2022-07-10 10:51 6% ` Max Nikulin
2022-07-15 15:38 7% ` Juan Manuel Macías
2021-10-04 14:27 [patch] ox-html.el: add html attribute (verse numbers) to verse blocks Juan Manuel Macías
2022-05-30 5:10 6% ` Ihor Radchenko
2022-05-30 15:36 9% ` Juan Manuel Macías
2022-05-31 5:06 6% ` Ihor Radchenko
2022-05-31 11:00 8% ` Juan Manuel Macías
2022-07-04 11:44 6% ` Ihor Radchenko
2022-05-15 11:54 [tip] Export and open a PDF in Android via Termux Juan Manuel Macías
2022-05-16 12:35 6% ` Ihor Radchenko
2022-05-16 15:00 6% ` Max Nikulin
2022-05-16 16:05 10% ` Juan Manuel Macías
2022-05-17 16:22 5% ` Max Nikulin
2022-05-17 17:56 8% ` Juan Manuel Macías
2022-05-18 16:14 6% ` Max Nikulin
2022-05-19 9:40 6% ` Eric S Fraga
2022-05-19 18:01 8% ` Juan Manuel Macías
2022-05-23 14:30 8% About 'inline special blocks' Juan Manuel Macías
2022-05-23 15:20 4% ` Kaushal Modi
2022-05-23 21:06 9% ` Juan Manuel Macías
2022-05-24 2:36 6% ` Tim Cross
2022-05-24 3:56 ` Ihor Radchenko
2022-05-25 13:55 10% ` Juan Manuel Macías
2022-06-17 6:28 ` Ihor Radchenko
2022-06-17 19:49 10% ` Juan Manuel Macías
2022-06-19 12:47 8% ` Juan Manuel Macías
2022-06-19 19:30 5% ` Christian Moe
2022-06-19 20:15 9% ` Juan Manuel Macías
2022-06-19 22:18 5% ` Tim Cross
2022-06-20 16:57 5% ` Max Nikulin
2022-06-20 19:06 7% ` Juan Manuel Macías
2022-06-21 16:39 6% ` Max Nikulin
2022-06-21 18:19 8% ` Juan Manuel Macías
2022-06-20 22:46 0% ` Tim Cross
2022-06-26 4:07 ` Org mode export accessibility (was: About 'inline special blocks') Ihor Radchenko
2022-06-26 6:29 ` Tim Cross
2022-06-26 10:46 10% ` Org mode export accessibility Juan Manuel Macías
2022-06-26 10:54 6% ` Ihor Radchenko
2022-05-26 10:01 5% [tip] org-publish to work with (very) large books Juan Manuel Macías
2022-05-26 12:46 6% ` Christian Moe
2022-05-26 13:11 ` Ihor Radchenko
2022-05-26 13:48 8% ` Juan Manuel Macías
2022-05-26 17:47 6% ` Christian Moe
2022-05-27 4:19 6% ` Ihor Radchenko
2022-05-27 11:39 8% ` Juan Manuel Macías
2022-05-28 3:02 5% ` Ihor Radchenko
2022-05-28 8:59 6% ` Juan Manuel Macías
2022-05-29 12:15 5% ` Ihor Radchenko
2022-05-29 18:01 6% ` Juan Manuel Macías
2022-05-27 16:23 how to export an org file, to 2 different locations (in to different formats) Uwe Brauer
2022-05-27 18:42 9% ` Juan Manuel Macías
2022-05-28 0:18 10% ` Juan Manuel Macías
2022-05-28 6:36 0% ` Uwe Brauer
2022-05-28 7:23 8% ` Juan Manuel Macías
2022-05-28 8:40 1% ` Uwe Brauer
2022-05-28 9:06 10% ` Juan Manuel Macías
2022-05-28 14:58 # Comments export Ypo
2022-05-28 15:44 ` Timothy
2022-05-28 15:58 ` Ypo
2022-05-28 16:05 ` Timothy
2022-05-28 23:15 ` Samuel Wales
2022-05-29 0:46 ` Ypo
2022-05-30 7:35 ` Eric S Fraga
2022-05-30 10:46 10% ` Juan Manuel Macías
2022-05-30 21:49 5% ` Tim Cross
2022-06-08 9:59 Org-attach for a directory Cletip Cletip
2022-06-08 10:32 9% ` Juan Manuel Macías
[not found] ` <CAPHku6O3RojzhaSu3d2pWfnE8x7N_9WAfjCupHyKcxNyD-i=ew@mail.gmail.com>
2022-06-09 10:11 8% ` Juan Manuel Macías
2022-06-10 18:28 8% [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
2022-06-11 5:39 6% ` Ihor Radchenko
2022-06-11 11:20 9% ` Juan Manuel Macías
2022-06-14 3:58 6% ` Ihor Radchenko
2022-06-14 11:11 8% ` Juan Manuel Macías
2022-06-14 11:55 6% ` Ihor Radchenko
2022-06-15 10:30 9% ` Juan Manuel Macías
2022-07-21 13:44 8% ` Juan Manuel Macías
2022-07-25 13:34 6% ` Ihor Radchenko
2022-07-25 17:13 7% ` Juan Manuel Macías
2022-06-12 19:18 6% ` Rudolf Adamkovič
2022-06-12 19:55 9% ` Juan Manuel Macías
2022-06-13 8:24 6% ` Rudolf Adamkovič
2022-06-13 10:22 10% ` Juan Manuel Macías
2022-06-17 12:47 Utility of description lists Cletip Cletip
2022-06-17 14:24 9% ` Juan Manuel Macías
2022-06-18 14:35 7% [Tip] Screenshots as org links with EMMS and socat Juan Manuel Macías
2022-06-19 15:50 Keybinding doubt about ARG Ypo
2022-06-19 16:49 ` Bruno Barbier
2022-06-19 17:21 10% ` Juan Manuel Macías
2022-06-20 14:03 10% Org and Hyperbole Juan Manuel Macías
2022-06-20 15:26 6% ` Russell Adams
2022-06-20 16:57 ` Eduardo Ochs
2022-06-20 23:28 7% ` Juan Manuel Macías
2022-06-20 23:37 0% ` Tim Cross
2022-06-20 15:56 0% ` Uwe Brauer
2022-06-20 16:09 6% ` Bill Burdick
2022-06-20 16:24 4% ` indieterminacy
2022-06-22 14:48 7% ` Juan Manuel Macías
2022-06-21 3:08 5% ` David Masterson
2022-06-22 10:37 9% ` Juan Manuel Macías
2022-06-22 14:35 4% ` Bill Burdick
2022-06-22 19:17 6% ` David Masterson
2022-06-20 16:25 4% [BUG] manual: confusing example of adding attributes to a link (affiliated keywords) Max Nikulin
2022-06-24 1:45 Org and Hyperbole Robert Weiner
2022-06-24 13:52 7% ` Juan Manuel Macías
2022-06-24 22:06 6% ` Robert Weiner
2022-06-25 14:32 9% ` Juan Manuel Macías
2022-06-25 20:35 1% ` Robert Weiner
2022-06-25 3:10 8% Org inside LaTeX (a poor man's approach with LuaTeX) Juan Manuel Macías
2022-06-29 19:18 PDF export, table of contents and internal links Sébastien Gendre
2022-06-29 19:56 9% ` Juan Manuel Macías
2022-06-29 22:02 5% ` Sébastien Gendre
2022-06-30 11:41 7% ` Juan Manuel Macías
2022-06-30 14:19 9% Convert a Lisp expression to a tree diagram Juan Manuel Macías
2022-06-30 15:17 4% ` Ihor Radchenko
2022-06-30 22:30 10% ` Juan Manuel Macías
2022-07-01 1:13 6% ` Ihor Radchenko
2022-07-01 10:45 10% ` Juan Manuel Macías
2022-06-30 16:21 6% ` arthur miller
2022-06-30 22:32 10% ` Juan Manuel Macías
2022-07-08 12:17 4% LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
2022-07-08 15:49 1% ` Uwe Brauer
2022-07-08 16:46 7% ` Juan Manuel Macías
2022-07-08 16:13 6% ` Thomas S. Dye
2022-07-08 17:27 ` Bruce D'Arcus
2022-07-08 19:03 8% ` Juan Manuel Macías
2022-07-08 18:49 6% ` Thomas S. Dye
2022-07-09 2:23 0% ` Max Nikulin
2022-07-09 3:23 0% ` Thomas S. Dye
2022-07-09 11:10 8% ` Juan Manuel Macías
2022-07-09 3:24 1% ` Tim Cross
2022-07-09 9:59 6% ` Juan Manuel Macías
2022-07-09 23:49 5% ` Tim Cross
2022-07-10 11:19 0% ` M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?) Ihor Radchenko
2022-07-10 19:06 0% ` Tim Cross
2022-07-10 19:31 10% ` LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Juan Manuel Macías
2022-07-09 10:42 7% ` Juan Manuel Macías
2022-07-09 12:15 6% ` Max Nikulin
2022-07-09 14:58 3% ` Juan Manuel Macías
[not found] ` <b58ee3cc-c58c-b627-9cc5-51993020db2c@gmail.com>
2022-07-09 20:22 3% ` Juan Manuel Macías
2022-07-10 20:23 7% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Juan Manuel Macías
2022-07-10 20:31 12% ` Juan Manuel Macías
2022-07-10 20:58 4% ` Tim Cross
2022-07-11 13:34 6% ` Juan Manuel Macías
2022-07-11 2:19 5% ` Ihor Radchenko
2022-07-11 14:19 ` Timothy
2022-07-11 15:00 10% ` Juan Manuel Macías
2022-07-11 17:45 ` fontsets (was: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")) Timothy
2022-07-11 22:09 8% ` fontsets Juan Manuel Macías
2022-07-12 7:12 6% ` fontsets Stefan Nobis
2022-07-12 11:37 7% ` fontsets Juan Manuel Macías
2022-07-12 15:26 7% ` Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets") Juan Manuel Macías
2022-07-15 14:35 5% ` Max Nikulin
2022-07-11 8:05 5% ` [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...") Stefan Nobis
2022-07-11 11:39 8% ` Juan Manuel Macías
2022-07-11 12:04 12% ` Juan Manuel Macías
2022-07-11 12:31 5% ` Max Nikulin
2022-07-11 14:23 6% ` Juan Manuel Macías
2022-07-11 17:20 5% ` Max Nikulin
2022-07-16 3:01 5% ` Max Nikulin
2022-07-11 17:08 4% ` LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX? Max Nikulin
2022-07-10 2:12 4% ` Max Nikulin
2022-07-09 0:34 5% ` Matt Huszagh
2022-07-08 13:03 Taking notes of videos in Emacs Gerardo Moro
2022-07-08 13:25 10% ` Juan Manuel Macías
2022-07-08 15:54 6% ` Samuel Banya
2022-07-09 7:31 7% ` Gerardo Moro
2022-07-09 11:37 10% ` Juan Manuel Macías
2022-07-12 17:18 missing a character / font in agenda? Daniel Ortmann
2022-07-12 17:58 10% ` Juan Manuel Macías
2022-07-12 18:45 5% ` [External] : " Daniel Ortmann
2022-07-12 19:52 9% ` Juan Manuel Macías
2022-07-12 20:03 13% ` Juan Manuel Macías
2022-07-12 23:04 6% ` Daniel Ortmann
2022-07-12 23:31 0% ` Ihor Radchenko
2022-07-13 0:26 ` Stefan Kangas
2022-07-13 10:01 10% ` Juan Manuel Macías
2022-07-17 8:58 6% ` Ihor Radchenko
2022-07-19 2:11 0% ` Max Nikulin
2022-07-13 10:49 5% [tip/offtopic] A function to describe the characters of a word at point Juan Manuel Macías
2022-07-14 15:42 5% ` Marcin Borkowski
2022-07-14 22:30 0% ` Samuel Wales
2022-07-15 0:56 8% ` Juan Manuel Macías
2022-07-16 14:33 8% Org for developing LaTeX packages Juan Manuel Macías
2022-07-17 10:09 6% ` Ihor Radchenko
2022-07-18 6:57 org-table with different conventions: decimals Uwe Brauer
2022-07-18 23:02 9% ` Juan Manuel Macías
2022-07-19 6:20 3% ` [export to CSV] (was: org-table with different conventions: decimals) Uwe Brauer
2022-07-19 11:07 10% ` [export to CSV] Juan Manuel Macías
2022-07-19 15:00 numbering src blocks in HTML export Fraga, Eric
2022-07-19 15:28 10% ` Juan Manuel Macías
2022-07-19 16:15 6% ` Fraga, Eric
2022-07-19 16:18 ` Fraga, Eric
2022-07-20 3:58 ` Ihor Radchenko
2022-07-20 12:07 8% ` Juan Manuel Macías
2022-07-23 13:44 BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Kai von Fintel
2022-07-23 13:59 ` Ihor Radchenko
2022-07-23 14:07 ` Kai von Fintel
2022-07-23 14:22 ` Ihor Radchenko
2022-07-23 14:39 ` Kai von Fintel
2022-07-23 14:50 ` Ihor Radchenko
2022-07-23 15:53 9% ` Juan Manuel Macías
2022-07-24 7:15 6% ` Ihor Radchenko
2022-07-24 11:29 9% ` Juan Manuel Macías
2022-07-23 14:53 10% ` Juan Manuel Macías
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).