* 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: 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%]
* 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 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
` (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: 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
0 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%]
* [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-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%]
* 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-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 15:26 6% ` Russell Adams
@ 2022-06-20 23:37 0% ` Tim Cross
2022-09-27 13:06 0% ` Jean Louis
1 sibling, 1 reply; 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: 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: 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: 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: 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: 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-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-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-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-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%]
* 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 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%]
* 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 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 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: 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: 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 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%]
* 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: 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%]
* 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 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 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 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-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: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
@ 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%]
* 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: 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%]
* 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: 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: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: 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
` (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: 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
` (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 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-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-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: 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 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: 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: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: 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 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: 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?
[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 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?
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: [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: [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%]
* 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: 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%]
* 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%]
* [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: [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%]
* 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
@ 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
` (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-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-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-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-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-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-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: 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 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: 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: 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-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%]
* 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: 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%]
* 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: [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 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 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 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-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%]
* [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: [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%]
* 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: [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 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: [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: [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: [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: [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: 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-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: [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: [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%]
* 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: [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%]
* 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: 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-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: [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-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-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 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 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: 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: [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%]
* [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: [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%]
* 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: [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
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-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: [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: 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 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: [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] 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
0 siblings, 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 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] 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-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-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-22 12:49 9% ` Juan Manuel Macías
@ 2022-07-22 14:07 12% ` Juan Manuel Macías
2022-07-23 15:19 4% ` 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-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-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-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: 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-22 14:07 12% ` Juan Manuel Macías
@ 2022-07-23 15:19 4% ` 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 4%]
* 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: 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%]
* 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 4% ` 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
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%]
* 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-24 7:15 6% ` Ihor Radchenko
@ 2022-07-24 11:29 9% ` Juan Manuel Macías
2022-07-26 11:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 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%]
* 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: 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%]
* 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: [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: [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
2022-07-26 5:35 4% ` Ihor Radchenko
0 siblings, 1 reply; 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-25 17:13 7% ` Juan Manuel Macías
@ 2022-07-26 5:35 4% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-26 5:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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)))
>
> ?
Hmm. You are indeed right. I missed the condition-case part.
In any case, re-search-backward is not reliable when you have inlinetasks.
> 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...
The path you took is indeed a bit awkward.
You may need to use the approach similar to orgtbl-to-latex.
Also, things to watch are org-export-exclude-tags,
org-export-with-section-numbers, org-export-with-archived-trees,
org-export-with-broken-links (we don't want tangle to fail because of
broken links), org-export-with-inlinetasks, org-export-with-toc,
and org-export-with-tasks.
> +(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)))
"Function to" can be safely dropped. See D.6 Tips for Documentation
Strings in Elisp manual:
• The first line of the documentation string should consist of one or
two complete sentences that stand on their own as a summary. ‘M-x
apropos’ displays just the first line, and if that line’s contents
don’t stand on their own, the result looks bad. In particular,
start the first line with a capital letter and end it with a
period.
For a function, the first line should briefly answer the question,
“What does this function do?” For a variable, the first line should
briefly answer the question, “What does this value mean?”
Don’t limit the documentation string to one line; use as many lines
as you need to explain the details of how to use the function or
variable. Please use complete sentences for the rest of the text
too.
• The first line should mention all the important arguments of the
function, and should mention them in the order that they are
written in a function call. If the function has many arguments,
then it is not feasible to mention them all in the first line; in
that case, the first line should mention the first few arguments,
including the most important arguments.
• For consistency, phrase the verb in the first sentence of a
function’s documentation string as an imperative—for instance, use
“Return the cons of A and B.” in preference to “Returns the cons of
A and B.” Usually it looks good to do likewise for the rest of the
first paragraph. Subsequent paragraphs usually look better if each
sentence is indicative and has a proper subject.
Best,
Ihor
^ permalink raw reply [relevance 4%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-24 11:29 9% ` Juan Manuel Macías
@ 2022-07-26 11:58 6% ` Ihor Radchenko
2022-07-26 16:19 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-07-26 11:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> 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.
Thanks for the update!
The patch has some misplaced parenthesis.
> - (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))))))
Your (nth 1 ...) sexp is inside the let definition:
(let ((lang ...)
(nth 1 ..))
nil)
Please pay attention to the compiler warnings.
Also, the original code contained the clause:
(or (get lang from the alist1)
(get lang from the alist2)
lang ; Fallback to provided language if not known.
)
Your variant does not have the fallback part. Is it intentional?
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-26 11:58 6% ` Ihor Radchenko
@ 2022-07-26 16:19 9% ` Juan Manuel Macías
2022-07-28 12:36 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-26 16:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Hi Ihor,
A thousand apologies for my horrible carelessness with the parentheses.
I should have checked the code. Here goes the patch again corrected. I
hope it's alright now.
Ihor Radchenko writes:
> Also, the original code contained the clause:
> (or (get lang from the alist1)
> (get lang from the alist2)
> lang ; Fallback to provided language if not known.
> )
>
> Your variant does not have the fallback part. Is it intentional?
Yes, I removed it because I thought it was not necessary, because after
all the user must put a supported language as the value of #+language.
Anyway, in case it breaks something backwards I have replaced it. Now
the or expression is:
(or (nth 1 (assoc-string lang org-latex-language-alist t))
lang)
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Remove-Babel-and-Polyglossia-alists.patch --]
[-- Type: text/x-patch, Size: 1324 bytes --]
From 483cf69e0ca56c560c3bd53db13887a63d529ec9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 26 Jul 2022 18:01:52 +0200
Subject: [PATCH] lisp/ox-latex.el: Remove Babel and Polyglossia alists
* (org-latex--format-spec): The new variable is now `org-latex-language-alist'
---
lisp/ox-latex.el | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 121a3f84c..14728f0ba 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1861,8 +1861,10 @@ INFO is a plist used as a communication channel."
"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))
+ ;; Here it would suffice to obtain the second
+ ;; element, which always returns the name
+ ;; language name in `org-latex-language-alist'
+ (or (nth 1 (assoc-string lang org-latex-language-alist t))
lang))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] org-export: Remove zero-width space escapes during export
@ 2022-07-27 3:30 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-07-27 3:30 UTC (permalink / raw)
To: emacs-orgmode
On 26/07/2022 19:59, Ihor Radchenko wrote:
>
> I am attaching a tentative patch that will make Org export remove
> zero-width spaces when those spaces actually separate the object
> boundaries.
Ihor, I have realized that you did not address another use case: zero
width spaces may be added to suppress activation of markup. In such
cases they are in the middle of text objects, but they should be removed.
Switch to the *scratch* buffer.
I consider zero width spaces as a workaround that is acceptable in some
cases but awkward in others. It is tricky to deal with it in some
general way.
I do not agree with the stance "just maintain status quo" expressed in
response to Juan Manuel Macías. On zero width spaces and Org syntax.
Fri, 03 Dec 2021 12:48:16 +0000
https://list.orgmode.org/orgmode/87ilw5yhv3.fsf@posteo.net/
An idea. At certain moment I was surprised that markup markers are not
activated at the borders of export snippets:
intra@@org:@@*w*@@org:@@ord
It is not really lightweight markup but at least it is purely ASCII and
visible by default. It might be breaking change in some edge cases. I am
unsure concerning increasing complexity of the parser. Macro markers
{{{macro}}} have similar behavior.
^ permalink raw reply [relevance 5%]
* Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
2022-07-26 16:19 9% ` Juan Manuel Macías
@ 2022-07-28 12:36 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-07-28 12:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> A thousand apologies for my horrible carelessness with the parentheses.
> I should have checked the code. Here goes the patch again corrected. I
> hope it's alright now.
Thanks!
Applied onto main via d37c0ee5f after adding full stop after sentences
in the commit message and amending some wording.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d37c0ee5fa7dc4be4bbe3aa9b6f4e79d4b1e638d
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Add new entity \-- serving as markup separator/escape symbol
@ 2022-07-29 0:32 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-07-29 0:32 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor,
Ihor Radchenko writes:
> Given the raised objections, zero-width space does not appear to be a
> useful escape symbol because it has its valid uses as a standalone space
> symbol.
>
> The raised objections can be solved using some kind of intricate
> heuristics, but I do not feel like it is a good direction to go. The
> code will be too complex and fragile.
>
> Therefore, I am proposing a different approach for shielding
> fontification: introducing a special entity.
>
> The new entity is \--, which is a valid boundary between emphasis
> markup. It will be removed during export (replaced by "").
>
> "\--" specifically is somewhat arbitrary choice. The actual requirements
> for the entity name are: (1) No clash with LaTeX (which is why simpler
> \- would not cut it); (2) Being a valid markup boundary: entity must end
> with (any space ?- ?\( ?' ?\" ?\{).
>
> I am attaching a tentative patch introducing the new entity. Note that
> some minor tweaks to the parser were needed. I do not see it as a big
> deal - the current entity regexp has much more cumbersome exceptions.
>
> Also, the patch will not work correctly on org → org export, similar to
> pointed in one of the replies to the previous abandoned approach. I do
> not want to address it here because a much more appropriate solution for
> this issue is changing org-element-interpret-data.
>
> Consider (org-element-interpret-data '("asd" (bold () "bold") "bsd"))
> This will return "asd*bold*bsd", which is not correct even though the
> given Org datum is not wrong by itself - such things can easily appear
> when user filters are applied to parse tree during org→org export.
>
> Otherwise, the patch should be good enough to play around and kick-start
> the discussion.
I'm late joining this thread, although I am particularly interested in
the topic.
I can't make any technical comments because I haven't had time to test
the patch yet, but I have to say that your idea of using a special
entity seems to me the best approach to the problem. I would vote for
this to be the way to go.
I believe that using the zero width space character as an escape
character is not a happy idea, and I have already left my arguments in
some other thread, long ago. The zero width space is a random
workaround, but should not (in my opinion) be part of the markup. For
various reasons: it is not an ascii character, there are certain
contexts in which it can produce an unexpected result in LaTeX, etc. In
addition, the zero width space, as an escape character, has a curious
anomaly: it is an escape character that does not have a plan B and a way
to escape the escape character when you want to use it by itself.
I also like the idea of using a special entity because it is not
necessary to invent anything new and it takes advantage of an existing
resource.
Well, that's my opinion.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [PATCH] ox-latex.el: `org-latex-language-alist' improved
@ 2022-07-31 1:00 3% Juan Manuel Macías
2022-08-03 11:23 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-07-31 1:00 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
Hi,
I've managed to get some free time to remake this list, following Maxim
Nikulin's suggestion
(https://list.orgmode.org/orgmode/taeb0a$r62$1@ciao.gmane.io/). It's no
longer an anonymous list and I agree it now has a more robust structure
with name fields. I have also added the `:lang-name' property, whose
value is the actual language name. For example:
("el-polyton" . (:babel "polutonikogreek" :polyglossia "greek"
:polyglossia-variant "polytonic" :lang-name "Polytonic Greek"))
Thanks to this I think the code for org-latex-guess-babel-language,
org-latex-guess-polyglossia-language and org-latex--format-spec is also
simpler.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-lisp-ox-latex.el-org-latex-language-alist-improved.patch --]
[-- Type: text/x-patch, Size: 18752 bytes --]
From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 31 Jul 2022 02:31:08 +0200
Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved.
* (org-latex-language-alist): Alist between language code and
corresponding properties, such as Babel/Polyglossia options and
language names. Each element of the list consists of a cons cell,
where car is the language code and cdr is a property list.
* (org-latex-guess-babel-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex-guess-polyglossia-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex--format-spec): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
---
lisp/ox-latex.el | 287 +++++++++++++++++++++++------------------------
1 file changed, 138 insertions(+), 149 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c56f9d347..669458913 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -173,110 +173,106 @@
;;; Internal Variables
(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" "*")
- ("bg" "bulgarian")
- ("bn" "bengali" "*")
- ("bo" "tibetan" "*")
- ("br" "breton")
- ("ca" "catalan")
- ("cop" "coptic" "*")
- ("cs" "czech")
- ("cy" "welsh")
- ("da" "danish")
- ("de" "ngerman" "german" "german")
- ("de-at" "naustrian" "german" "austrian")
- ("dsb" "lsorbian" "*")
- ("dv" "divehi" "*")
- ("el" "greek")
- ("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")
- ("fr-ca" "canadien" "french" "canadian")
- ("fur" "friulan")
- ("ga" "irish")
- ("gd" "scottish")
- ("gl" "galician")
- ("he" "hebrew")
- ("hi" "hindi")
- ("hr" "croatian")
- ("hsb" "uppersorbian" "sorbian" "upper")
- ("hu" "magyar")
- ("hy" "armenian" "*")
- ("ia" "interlingua")
- ("id" "bahasai" "*")
- ("is" "icelandic")
- ("it" "italian")
- ("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" "norwegian" "bokmal")
- ("nl" "dutch")
- ("nn" "nynorsk" "norwegian" "nynorsk")
- ("no" "norsk")
- ("oc" "occitan")
- ("pl" "polish")
- ("pms" "piedmontese")
- ("pt" "portuges")
- ("pt-br" "brazilian")
- ("rm" "romansh" "*")
- ("ro" "romanian")
- ("ru" "russian")
- ("sa" "sanskrit" "*")
- ("sk" "slovak")
- ("sl" "slovene")
- ("sq" "albanian")
- ("sr" "serbian")
- ("sv" "swedish")
- ("syr" "syriac" "*")
- ("ta" "tamil" "*")
- ("te" "telugu" "*")
- ("th" "thai")
- ("tk" "turkmen")
- ("tr" "turkish")
- ("uk" "ukrainian")
- ("ur" "urdu" "*")
- ("vi" "vietnamese"))
- "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")
+ '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic"))
+ ("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name "Arabic"))
+ ("ast" . (:babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian"))
+ ("bg" . (:babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian"))
+ ("bn" . (:babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali"))
+ ("bo" . (:babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan"))
+ ("br" . (:babel "breton" :polyglossia "breton" :lang-name "Breton"))
+ ("ca" . (:babel "catalan" :polyglossia "catalan" :lang-name "Catalan"))
+ ("cop" . (:babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic"))
+ ("cs" . (:babel "czech" :polyglossia "czech" :lang-name "Czech"))
+ ("cy" . (:babel "welsh" :polyglossia "welsh" :lang-name "Welsh"))
+ ("da" . (:babel "danish" :polyglossia "danish" :lang-name "Danish"))
+ ("de" . (:babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German"))
+ ("de-at" . (:babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German"))
+ ("dsb" . (:babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian"))
+ ("dv" . (:babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi"))
+ ("el" . (:babel "greek" :polyglossia "greek" :lang-name "Greek"))
+ ("el-polyton" . (:babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek"))
+ ("en" . (:babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English"))
+ ("en-au" . (:babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English"))
+ ("en-gb" . (:babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English"))
+ ("en-nz" . (:babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English"))
+ ("en-us" . (:babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English"))
+ ("eo" . (:babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto"))
+ ("es" . (:babel "spanish" :polyglossia "spanish" :lang-name "Spanish"))
+ ("es-mx" . (:babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish"))
+ ("et" . (:babel "estonian" :polyglossia "estonian" :lang-name "Estonian"))
+ ("eu" . (:babel "basque" :polyglossia "basque" :lang-name "Basque"))
+ ("fa" . (:babel "farsi" :polyglossia "farsi" :lang-name "Farsi"))
+ ("fi" . (:babel "finnish" :polyglossia "finnish" :lang-name "Finnish"))
+ ("fr" . (:babel "french" :polyglossia "french" :lang-name "French"))
+ ("fr-ca" . (:babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French"))
+ ("fur" . (:babel "friulan" :polyglossia "friulan" :lang-name "Friulian"))
+ ("ga" . (:babel "irish" :polyglossia "irish" :lang-name "Irish"))
+ ("gd" . (:babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic"))
+ ("gl" . (:babel "galician" :polyglossia "galician" :lang-name "Galician"))
+ ("he" . (:babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew"))
+ ("hi" . (:babel "hindi" :polyglossia "hindi" :lang-name "Hindi"))
+ ("hr" . (:babel "croatian" :polyglossia "croatian" :lang-name "Croatian"))
+ ("hsb" . (:babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian"))
+ ("hu" . (:babel "magyar" :polyglossia "magyar" :lang-name "Magyar"))
+ ("hy" . (:babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian"))
+ ("ia" . (:babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua"))
+ ("id" . (:babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai"))
+ ("is" . (:babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic"))
+ ("it" . (:babel "italian" :polyglossia "italian" :lang-name "Italian"))
+ ("kn" . (:babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada"))
+ ("la" . (:babel "latin" :polyglossia "latin" :lang-name "Latin"))
+ ("la-classic" . (:babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin"))
+ ("la-medieval" . (:babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin"))
+ ("la-ecclesiastic" . (:babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin"))
+ ("lo" . (:babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao"))
+ ("lt" . (:babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian"))
+ ("lv" . (:babel "latvian" :polyglossia "latvian" :lang-name "Latvian"))
+ ("ml" . (:babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam"))
+ ("mr" . (:babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi"))
+ ("nb" . (:babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål"))
+ ("nl" . (:babel "dutch" :polyglossia "dutch" :lang-name "Dutch"))
+ ("nn" . (:babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk"))
+ ("no" . (:babel "norsk" :polyglossia "norsk" :lang-name "Norwegian"))
+ ("oc" . (:babel "occitan" :polyglossia "occitan" :lang-name "Occitan"))
+ ("pl" . (:babel "polish" :polyglossia "polish" :lang-name "Polish"))
+ ("pms" . (:babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese"))
+ ("pt" . (:babel "portuges" :polyglossia "portuges" :lang-name "Portuges"))
+ ("pt-br" . (:babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges"))
+ ("rm" . (:babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh"))
+ ("ro" . (:babel "romanian" :polyglossia "romanian" :lang-name "Romanian"))
+ ("ru" . (:babel "russian" :polyglossia "russian" :lang-name "Russian"))
+ ("sa" . (:babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit"))
+ ("sk" . (:babel "slovak" :polyglossia "slovak" :lang-name "Slovak"))
+ ("sl" . (:babel "slovene" :polyglossia "slovene" :lang-name "Slovene"))
+ ("sq" . (:babel "albanian" :polyglossia "albanian" :lang-name "Albanian"))
+ ("sr" . (:babel "serbian" :polyglossia "serbian" :lang-name "Serbian"))
+ ("sv" . (:babel "swedish" :polyglossia "swedish" :lang-name "Swedish"))
+ ("syr" . (:babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac"))
+ ("ta" . (:babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil"))
+ ("te" . (:babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu"))
+ ("th" . (:babel "thai" :polyglossia "thai" :lang-name "Thai"))
+ ("tk" . (:babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen"))
+ ("tr" . (:babel "turkish" :polyglossia "turkish" :lang-name "Turkish"))
+ ("uk" . (:babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian"))
+ ("ur" . (:babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu"))
+ ("vi" . (:babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+ "Alist between language code and corresponding properties, such
+as Babel/Polyglossia options and language names.
+
+Each element of the list consists of a cons cell, where car is
+the language code and cdr is a property list. Valid keywords for
+this list can be:
+
+- `:babel' the name of the language loaded by the Babel LaTeX package
+
+- `:poliglosia' the name of the language loaded by the Polyglossia LaTeX package
+
+- `:babel-ini-only' the name of the language loaded by Babel
+ exclusively through the new ini files method.
+
+- `:polyglossia-variant' the language variant loaded by Polyglossia
+
+- `:lang-name' the actual name of the language."))
(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
("qbordermatrix" . "\\cr")
@@ -1619,11 +1615,15 @@ already loaded.
Return the new 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))
+ (plist (cdr
+ (assoc language-code org-latex-language-alist)))
+ (language (plist-get plist :babel))
+ (language-ini-only (plist-get plist :babel-ini-only))
+ ;; If no language is set, or Babel package is not loaded, or
+ ;; LANGUAGE keyword value is a language served by Babel
+ ;; exclusively through ini files, return HEADER as-is.
+ (header (if (or language-ini-only
+ (not (stringp language-code))
(not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
header
(let ((options (save-match-data
@@ -1634,22 +1634,13 @@ Return the new header."
;; 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)))))))
+ (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))
@@ -1658,7 +1649,9 @@ Return the new header."
(when (equal "AUTO" prov)
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
- (format "\\1\\2%s}" language) header t))))))
+ (format "\\1\\2%s}"
+ (or language language-ini-only))
+ header t))))))
(defun org-latex-guess-polyglossia-language (header info)
"Set the Polyglossia language according to the LANGUAGE keyword.
@@ -1675,13 +1668,13 @@ replaced with the language of the document or
using \setdefaultlanguage and not as an option to the package.
Return the new header."
- (let ((language (plist-get info :language)))
+ (let* ((language (plist-get info :language)))
;; If no language is set or Polyglossia is not loaded, return
;; HEADER as-is.
(if (or (not (stringp language))
(not (string-match
- "\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
- header)))
+ "\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
+ header)))
header
(let* ((options (org-string-nw-p (match-string 1 header)))
(languages (and options
@@ -1700,23 +1693,20 @@ Return the new header."
(concat "\\usepackage{polyglossia}\n"
(mapconcat
(lambda (l)
- (let ((l (or (assoc l org-latex-language-alist)
- l)))
- (format (if main-language-set "\\setotherlanguage%s{%s}\n"
+ (let* ((plist (cdr
+ (assoc language org-latex-language-alist)))
+ (polyglossia-variant (plist-get plist :polyglossia-variant))
+ (polyglossia-lang (plist-get plist :polyglossia))
+ (l (if (equal l language)
+ polyglossia-lang
+ l)))
+ (format (if main-language-set (format "\\setotherlanguage{%s}\n" l)
(setq main-language-set t)
"\\setmainlanguage%s{%s}\n")
- ;; Four elements implies that there is a
- ;; variant (4) for LANGUAGE when
- ;; declared by Polyglossia (3).
- ;; FIXME: 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))
+ (if polyglossia-variant
+ (format "[variant=%s]" polyglossia-variant)
"")
- (if (and (consp l) (= (length l) 4))
- (nth 2 l)
- (nth 1 l)))))
+ l)))
languages
""))
t t header 0)))))
@@ -1860,12 +1850,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)))
- ;; The second element in
- ;; `org-latex-language-alist' is always the
- ;; language name, regardless of the type of the
- ;; alist entry.
- (or (nth 1 (assoc-string lang org-latex-language-alist t))
+ (let ((language (let* ((lang (plist-get info :language))
+ (plist (cdr
+ (assoc lang org-latex-language-alist))))
+ ;; Here the actual name of the LANGUAGE or LANG is used
+ (or (plist-get plist :lang-name)
lang))))
`((?a . ,(org-export-data (plist-get info :author) info))
(?t . ,(org-export-data (plist-get info :title) info))
--
2.37.1
^ permalink raw reply related [relevance 3%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
2022-07-31 1:00 3% [PATCH] ox-latex.el: `org-latex-language-alist' improved Juan Manuel Macías
@ 2022-08-03 11:23 5% ` Ihor Radchenko
2022-08-04 10:04 3% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-03 11:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I've managed to get some free time to remake this list, following Maxim
> Nikulin's suggestion
> (https://list.orgmode.org/orgmode/taeb0a$r62$1@ciao.gmane.io/). It's no
> longer an anonymous list and I agree it now has a more robust structure
> with name fields. I have also added the `:lang-name' property, whose
> value is the actual language name. For example:
>
> ("el-polyton" . (:babel "polutonikogreek" :polyglossia "greek"
> :polyglossia-variant "polytonic" :lang-name "Polytonic Greek"))
>
> Thanks to this I think the code for org-latex-guess-babel-language,
> org-latex-guess-polyglossia-language and org-latex--format-spec is also
> simpler.
Thanks! I have some minor comments on the patch.
> From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00 2001
> From: Juan Manuel Macias <maciaschain@posteo.net>
> Date: Sun, 31 Jul 2022 02:31:08 +0200
> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved.
No dot after the firs message line, please.
> + '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :lang-name
"Amharic"))
> + ("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name "Arabic"))
A simpler form would be
("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
> + "Alist between language code and corresponding properties, such
> +as Babel/Polyglossia options and language names.
The first line of the docstring should fit 80 characters and be a full
sentence. It is needed to make sure that eldoc can display the short
docstring in the message area.
> +- `:poliglosia' the name of the language loaded by the Polyglossia LaTeX
package
`:polyglossia', I think.
> +- `:babel-ini-only' the name of the language loaded by Babel
> + exclusively through the new ini files method.
May we put some kind of reference to LaTeX docs here?
> + (let ((language (let* ((lang (plist-get info :language))
> + (plist (cdr
> + (assoc lang org-latex-language-alist))))
> + ;; Here the actual name of the LANGUAGE or LANG is
used
Please end the comment sentence with ".".
Best,
Ihor
[-- Attachment #2: Type: text/html, Size: 2843 bytes --]
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
2022-08-03 11:23 5% ` Ihor Radchenko
@ 2022-08-04 10:04 3% ` Juan Manuel Macías
2022-08-04 12:16 7% ` Max Nikulin
2022-08-06 7:13 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-04 10:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]
Hi, Ihor,
Ihor Radchenko writes:
> Thanks! I have some minor comments on the patch.
>
>> From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00
> 2001
>> From: Juan Manuel Macias <maciaschain@posteo.net>
>> Date: Sun, 31 Jul 2022 02:31:08 +0200
>> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist'
> improved.
>
> No dot after the firs message line, please.
>
>> + '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :
> lang-name "Amharic"))
>> + ("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name
> "Arabic"))
>
> A simpler form would be
> ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name
> "Amharic")
>
>> + "Alist between language code and corresponding properties, such
>> +as Babel/Polyglossia options and language names.
>
> The first line of the docstring should fit 80 characters and be a full
> sentence. It is needed to make sure that eldoc can display the short
> docstring in the message area.
>
>> +- `:poliglosia' the name of the language loaded by the Polyglossia
> LaTeX package
>
> `:polyglossia', I think.
>
>> +- `:babel-ini-only' the name of the language loaded by Babel
>> + exclusively through the new ini files method.
>
> May we put some kind of reference to LaTeX docs here?
>
>> + (let ((language (let* ((lang (plist-get info :language))
>> + (plist (cdr
>> + (assoc lang org-latex-language-alist))))
>> + ;; Here the actual name of the LANGUAGE or LANG
> is used
>
> Please end the comment sentence with ".".
Thanks for your comments and patience, and sorry again for the typos.
I am attaching a new fixed version of the patch. If everything is ok, I
get down to work with the Manual and NEWS. I think it would be nice to
add a few usage examples, and some links to the Babel and Polyglossia
documentation.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-lisp-ox-latex.el-org-latex-language-alist-improved.patch --]
[-- Type: text/x-patch, Size: 18544 bytes --]
From 3d67d46cfc3e2f4a8feab1fed0598912700118a6 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Thu, 4 Aug 2022 11:54:01 +0200
Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved
* (org-latex-language-alist): Alist between language code and
corresponding properties, such as Babel/Polyglossia options and
language names. Each element of the list consists of a cons cell,
where car is the language code and cdr is a property list.
* (org-latex-guess-babel-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex-guess-polyglossia-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex--format-spec): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
---
lisp/ox-latex.el | 290 +++++++++++++++++++++++------------------------
1 file changed, 140 insertions(+), 150 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c56f9d347..69d01b9c7 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -173,110 +173,107 @@
;;; Internal Variables
(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" "*")
- ("bg" "bulgarian")
- ("bn" "bengali" "*")
- ("bo" "tibetan" "*")
- ("br" "breton")
- ("ca" "catalan")
- ("cop" "coptic" "*")
- ("cs" "czech")
- ("cy" "welsh")
- ("da" "danish")
- ("de" "ngerman" "german" "german")
- ("de-at" "naustrian" "german" "austrian")
- ("dsb" "lsorbian" "*")
- ("dv" "divehi" "*")
- ("el" "greek")
- ("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")
- ("fr-ca" "canadien" "french" "canadian")
- ("fur" "friulan")
- ("ga" "irish")
- ("gd" "scottish")
- ("gl" "galician")
- ("he" "hebrew")
- ("hi" "hindi")
- ("hr" "croatian")
- ("hsb" "uppersorbian" "sorbian" "upper")
- ("hu" "magyar")
- ("hy" "armenian" "*")
- ("ia" "interlingua")
- ("id" "bahasai" "*")
- ("is" "icelandic")
- ("it" "italian")
- ("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" "norwegian" "bokmal")
- ("nl" "dutch")
- ("nn" "nynorsk" "norwegian" "nynorsk")
- ("no" "norsk")
- ("oc" "occitan")
- ("pl" "polish")
- ("pms" "piedmontese")
- ("pt" "portuges")
- ("pt-br" "brazilian")
- ("rm" "romansh" "*")
- ("ro" "romanian")
- ("ru" "russian")
- ("sa" "sanskrit" "*")
- ("sk" "slovak")
- ("sl" "slovene")
- ("sq" "albanian")
- ("sr" "serbian")
- ("sv" "swedish")
- ("syr" "syriac" "*")
- ("ta" "tamil" "*")
- ("te" "telugu" "*")
- ("th" "thai")
- ("tk" "turkmen")
- ("tr" "turkish")
- ("uk" "ukrainian")
- ("ur" "urdu" "*")
- ("vi" "vietnamese"))
- "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")
+ '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
+ ("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
+ ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
+ ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
+ ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
+ ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
+ ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton")
+ ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
+ ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
+ ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech")
+ ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
+ ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish")
+ ("de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
+ ("de-at" :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
+ ("dsb" :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
+ ("dv" :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
+ ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek")
+ ("el-polyton" :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
+ ("en" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
+ ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
+ ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
+ ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
+ ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
+ ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
+ ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
+ ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
+ ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
+ ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque")
+ ("fa" :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
+ ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
+ ("fr" :babel "french" :polyglossia "french" :lang-name "French")
+ ("fr-ca" :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
+ ("fur" :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
+ ("ga" :babel "irish" :polyglossia "irish" :lang-name "Irish")
+ ("gd" :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
+ ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician")
+ ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew")
+ ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi")
+ ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian")
+ ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian")
+ ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar")
+ ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian")
+ ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua")
+ ("id" :babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai")
+ ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic")
+ ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian")
+ ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada")
+ ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin")
+ ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin")
+ ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin")
+ ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin")
+ ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao")
+ ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian")
+ ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian")
+ ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam")
+ ("mr" :babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi")
+ ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål")
+ ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch")
+ ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk")
+ ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian")
+ ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan")
+ ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish")
+ ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese")
+ ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges")
+ ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges")
+ ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh")
+ ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian")
+ ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian")
+ ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit")
+ ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak")
+ ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene")
+ ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian")
+ ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian")
+ ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish")
+ ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac")
+ ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil")
+ ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu")
+ ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai")
+ ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen")
+ ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish")
+ ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian")
+ ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu")
+ ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+ "Alist between language code and corresponding properties for LaTeX export.
+
+In each element of the list car is always the code of the
+language and cdr is a property list. Valid keywords for this
+list can be:
+
+- `:babel' the name of the language loaded by the Babel LaTeX package
+
+- `:polyglosia' the name of the language loaded by the Polyglossia LaTeX package
+
+- `:babel-ini-only' the name of the language loaded by Babel
+ exclusively through the new ini files method. See
+ `http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf'
+
+- `:polyglossia-variant' the language variant loaded by Polyglossia
+
+- `:lang-name' the actual name of the language.")
+
(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
("qbordermatrix" . "\\cr")
@@ -1619,11 +1616,15 @@ already loaded.
Return the new 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))
+ (plist (cdr
+ (assoc language-code org-latex-language-alist)))
+ (language (plist-get plist :babel))
+ (language-ini-only (plist-get plist :babel-ini-only))
+ ;; If no language is set, or Babel package is not loaded, or
+ ;; LANGUAGE keyword value is a language served by Babel
+ ;; exclusively through ini files, return HEADER as-is.
+ (header (if (or language-ini-only
+ (not (stringp language-code))
(not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
header
(let ((options (save-match-data
@@ -1634,22 +1635,13 @@ Return the new header."
;; 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)))))))
+ (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))
@@ -1658,7 +1650,9 @@ Return the new header."
(when (equal "AUTO" prov)
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
- (format "\\1\\2%s}" language) header t))))))
+ (format "\\1\\2%s}"
+ (or language language-ini-only))
+ header t))))))
(defun org-latex-guess-polyglossia-language (header info)
"Set the Polyglossia language according to the LANGUAGE keyword.
@@ -1675,13 +1669,13 @@ replaced with the language of the document or
using \setdefaultlanguage and not as an option to the package.
Return the new header."
- (let ((language (plist-get info :language)))
+ (let* ((language (plist-get info :language)))
;; If no language is set or Polyglossia is not loaded, return
;; HEADER as-is.
(if (or (not (stringp language))
(not (string-match
- "\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
- header)))
+ "\\\\usepackage\\(?:\\[\\([^]]+?\\)\\]\\){polyglossia}\n"
+ header)))
header
(let* ((options (org-string-nw-p (match-string 1 header)))
(languages (and options
@@ -1700,23 +1694,20 @@ Return the new header."
(concat "\\usepackage{polyglossia}\n"
(mapconcat
(lambda (l)
- (let ((l (or (assoc l org-latex-language-alist)
- l)))
- (format (if main-language-set "\\setotherlanguage%s{%s}\n"
+ (let* ((plist (cdr
+ (assoc language org-latex-language-alist)))
+ (polyglossia-variant (plist-get plist :polyglossia-variant))
+ (polyglossia-lang (plist-get plist :polyglossia))
+ (l (if (equal l language)
+ polyglossia-lang
+ l)))
+ (format (if main-language-set (format "\\setotherlanguage{%s}\n" l)
(setq main-language-set t)
"\\setmainlanguage%s{%s}\n")
- ;; Four elements implies that there is a
- ;; variant (4) for LANGUAGE when
- ;; declared by Polyglossia (3).
- ;; FIXME: 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))
+ (if polyglossia-variant
+ (format "[variant=%s]" polyglossia-variant)
"")
- (if (and (consp l) (= (length l) 4))
- (nth 2 l)
- (nth 1 l)))))
+ l)))
languages
""))
t t header 0)))))
@@ -1860,13 +1851,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)))
- ;; The second element in
- ;; `org-latex-language-alist' is always the
- ;; language name, regardless of the type of the
- ;; alist entry.
- (or (nth 1 (assoc-string lang org-latex-language-alist t))
- lang))))
+ (let ((language (let* ((lang (plist-get info :language))
+ (plist (cdr
+ (assoc lang org-latex-language-alist))))
+ ;; Here the actual name of the LANGUAGE or LANG is used.
+ (or (plist-get plist :lang-name)
+ lang))))
`((?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 3%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
2022-08-04 10:04 3% ` Juan Manuel Macías
@ 2022-08-04 12:16 7% ` Max Nikulin
2022-08-05 17:14 9% ` Juan Manuel Macías
2022-08-06 7:13 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2022-08-04 12:16 UTC (permalink / raw)
To: emacs-orgmode
On 04/08/2022 17:04, Juan Manuel Macías wrote:
>>> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist'
>> improved.
Thank you, Juan Manuel. The patch looks like what I was trying to
suggest. However I have not tried to implement fontenc on the top of it.
> + (format "\\1\\2%s}"
> + (or language language-ini-only))
Likely never variant is ideal. Maybe language should be always in :babel
and :babel-ini-only should be boolean. I am not sure though that it will
not make code more complex in other places, so feel free to ignore this
comment.
^ permalink raw reply [relevance 7%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
2022-08-04 12:16 7% ` Max Nikulin
@ 2022-08-05 17:14 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-05 17:14 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Likely never variant is ideal. Maybe language should be always in
> :babel and :babel-ini-only should be boolean. I am not sure though
> that it will not make code more complex in other places, so feel free
> to ignore this comment.
What you say makes a lot of sense. Really the only reason why I avoided
doing something like that was rather the economy, so I didn't have to
put things like (two properties instead of one):
:babel xx :babel-ini-only t etc.
It is also expected that babel-ini-only is a 'temporary' property. At
least I would like it to be so.
According to the Babel documentation:
> Babel is moving gradually from the old and fuzzy concept of language
> to the more modern of locale.
Which is precisely what the new ini files are meant for. Now these files
can only be loaded via \babelprovide or by adding provide=* (and some
other variants) to the babel arguments (this last option is not
supported by my patch, for pdfLaTeX compatibility, where ini files don't
work. I imagine that when that transition is complete, there will be a
more inclusive and universal interface in babel.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
2022-08-04 10:04 3% ` Juan Manuel Macías
2022-08-04 12:16 7% ` Max Nikulin
@ 2022-08-06 7:13 5% ` Ihor Radchenko
2022-08-06 21:32 13% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-06 7:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a new fixed version of the patch. If everything is ok, I
> get down to work with the Manual and NEWS. I think it would be nice to
> add a few usage examples, and some links to the Babel and Polyglossia
> documentation.
Applied onto main via e47bcb021 with minor amendments: I fixed a typo
"polyglosia" and shortened the first line of a docstring to less than 80
chars.
FYI, there is display-fill-column-indicator-mode, which is useful to
guide the docstring in Elisp. Just need to set fill-column to 80.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e47bcb02133608e37bc4c532aec4d4723f8eeca8
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved
2022-08-06 7:13 5% ` Ihor Radchenko
@ 2022-08-06 21:32 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-06 21:32 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> FYI, there is display-fill-column-indicator-mode, which is useful to
> guide the docstring in Elisp. Just need to set fill-column to 80.
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e47bcb02133608e37bc4c532aec4d4723f8eeca8
Thanks a lot for the suggestion, Ihor. With this I also realize that 90%
of my functions have the first line of the docstring too long...
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* org-verse-num: display verse numbers within a verse block
@ 2022-08-07 12:53 13% Juan Manuel Macías
2022-08-07 13:39 0% ` Colin Baxter
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-07 12:53 UTC (permalink / raw)
To: orgmode; +Cc: emacs-humanities
Hi all,
I've added some minor improvements to my little package 'org-verse-num',
which was born out of necessity in my translation to spanish
(work-in-progress) of Homer's Odyssey (11600 verses spread over 24
books):
https://gitlab.com/maciaschain/org-verse-num
org-verse-num includes some functions and a minor mode to aid in
navigating through (very) long poems within an Org-mode verse block. It
displays verse numbers sequentially (avoiding empty lines between
stanzas) and you can also move the cursor to a specific verse number.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: org-verse-num: display verse numbers within a verse block
2022-08-07 12:53 13% org-verse-num: display verse numbers within a verse block Juan Manuel Macías
@ 2022-08-07 13:39 0% ` Colin Baxter
2022-08-07 14:22 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Colin Baxter @ 2022-08-07 13:39 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, emacs-humanities
>>>>> Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi all, I've added some minor improvements to my little package
> 'org-verse-num', which was born out of necessity in my translation
> to spanish (work-in-progress) of Homer's Odyssey (11600 verses
> spread over 24 books):
> https://gitlab.com/maciaschain/org-verse-num
Your site tells me to turn JavaScript, enable Cookies and complete a
CAPTCHA, all of which I refuse to do.
Do you have an alternative web-site?
^ permalink raw reply [relevance 0%]
* Re: org-verse-num: display verse numbers within a verse block
2022-08-07 13:39 0% ` Colin Baxter
@ 2022-08-07 14:22 13% ` Juan Manuel Macías
2022-08-07 14:44 6% ` Jeremie Juste
2022-08-07 15:16 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-07 14:22 UTC (permalink / raw)
To: m43cap; +Cc: orgmode, Ihor Radchenko
Colin Baxter writes:
> Your site tells me to turn JavaScript, enable Cookies and complete a
> CAPTCHA, all of which I refuse to do.
>
> Do you have an alternative web-site?
Sorry for the inconvenience. I plan to set up my own GitLab instance in
the future, but I don't have time to do it anytime soon.
BTW, is there any proprietary JavaScript free alternative to
GitLab/GitHub? I would be very grateful for any recommendations.
(I noticed that my previous message was sent to the duplicate list.
Apologies for that).
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: org-verse-num: display verse numbers within a verse block
2022-08-07 14:22 13% ` Juan Manuel Macías
@ 2022-08-07 14:44 6% ` Jeremie Juste
2022-08-07 15:16 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Jeremie Juste @ 2022-08-07 14:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: m43cap, orgmode, Ihor Radchenko
Hello Juan,
On Sunday, 7 Aug 2022 at 14:22, Juan Manuel Macías wrote:
> I've added some minor improvements to my little package 'org-verse-num',
> which was born out of necessity in my translation to spanish
> (work-in-progress) of Homer's Odyssey (11600 verses spread over 24
> books):
> https://gitlab.com/maciaschain/org-verse-num
Many thanks for sharing.
>
> Sorry for the inconvenience. I plan to set up my own GitLab instance in
> the future, but I don't have time to do it anytime soon.
>
> BTW, is there any proprietary JavaScript free alternative to
> GitLab/GitHub? I would be very grateful for any recommendations.
https://sourcehut.org/ seems to gain popularity, but they charge a
fee. But it might still be less expensive than hosting your own gitlab
repository. (I have no affiliation with sourcehut and I am not an expert).
>
> (I noticed that my previous message was sent to the duplicate list.
> Apologies for that).
No problem for posting to two lists. I didn't know about emacs-humanities
<emacs-humanities@gnu.org>.
Best regards,
Jeremie
^ permalink raw reply [relevance 6%]
* Re: org-verse-num: display verse numbers within a verse block
2022-08-07 14:22 13% ` Juan Manuel Macías
2022-08-07 14:44 6% ` Jeremie Juste
@ 2022-08-07 15:16 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-08-07 15:16 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: m43cap, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> BTW, is there any proprietary JavaScript free alternative to
> GitLab/GitHub? I would be very grateful for any recommendations.
For self-hosted solutions, you may check out https://gitea.io/en-us/
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 6%]
* [PATCH] Documentation and NEWS for ` org-latex-language-alist'
@ 2022-08-08 14:39 9% Juan Manuel Macías
2022-08-09 11:43 5% ` Ihor Radchenko
2022-08-09 15:39 6% ` [PATCH] Documentation and NEWS for ` org-latex-language-alist' Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-08 14:39 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 347 bytes --]
Hi,
I am attaching a patch with the documentation of the new variable in the
Manual and the updated NEWS.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-org-manual.org-documentation-for-org-latex-langu.patch --]
[-- Type: text/x-patch, Size: 4540 bytes --]
From 2ec740e4b2f691f619878a7b86e4874fa05d3a82 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 8 Aug 2022 16:30:01 +0200
Subject: [PATCH] doc/org-manual.org: documentation for
`org-latex-language-alist'
* etc/ORG-NEWS: update the news with the new variable.
---
doc/org-manual.org | 57 ++++++++++++++++++++++++++++++++++++++++++++--
etc/ORG-NEWS | 13 +++++++++++
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..5d0283bf2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13370,19 +13370,72 @@ general options (see [[*Export Settings]]).
- =LANGUAGE= ::
#+cindex: @samp{LANGUAGE}, keyword
#+vindex: org-latex-packages-alist
+ #+vindex: org-latex-language-alist
+ #+vindex: org-export-default-language
+
+ The list of languages supported by Org is stored in the variable
+ ~org-latex-language-alist~.
+
In order to be effective, the =babel= or =polyglossia=
packages---according to the LaTeX compiler used---must be loaded
with the appropriate language as argument. This can be accomplished
by modifying the ~org-latex-packages-alist~ variable, e.g., with the
- following snippet:
+ following snippet (note that =polyglossia= does not work with
+ pdfLaTeX):
#+begin_src emacs-lisp
(add-to-list 'org-latex-packages-alist
- '("AUTO" "babel" t ("pdflatex")))
+ '("AUTO" "babel" t ("pdflatex" "xelatex" "lualatex")))
(add-to-list 'org-latex-packages-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_src
+ LaTeX packages =babel= or =polyglossia= can also be loaded in a
+ document. The "AUTO" string will be replaced in both cases by the
+ appropiate value for the =LANGUAGE= keyword, if present in the
+ document, or by the value of ~org-export-default-language~. Let's
+ see some examples in one or another case.
+
+ =Babel= accepts the classic syntax and (in addition) the new syntax
+ with the =\babelprovide= command to load the languages using the new
+ =INI= files procedure. Keep in mind that there are a number of
+ languages that are only served in babel using =INI= files, so they
+ cannot be declared using the classic syntax, but only using the
+ =\babelprovide= command (see
+ http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
+ Valid usage examples could be:
+
+ #+begin_example
+ ,#+LATEX_HEADER: \usepackage[french,italian,AUTO]{babel}
+ #+end_example
+
+ where "AUTO" is the main language. But it can also be loaded using
+ the =\babelprovide= command:
+
+ #+begin_example
+ ,#+LATEX_HEADER: \usepackage[french,italian]{babel}
+ ,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
+ #+end_example
+
+ =Polyglossia=, for this procedure to be effective, must be loaded
+ using the same =babel= classic syntax (but note that /this is not/
+ the actual polyglossia syntax). For example, suppose a document
+ declares Polytonic Greek as the primary language, and French as the
+ secondary language. In this case, it would be expressed as:
+
+ #+begin_example
+ ,#+LANGUAGE: el-polyton
+ ,#+LATEX_HEADER: \usepackage[french,AUTO]{polyglossia}
+ #+end_example
+
+ This would produce in LaTeX (with the actual =polyglossia= syntax):
+
+ #+begin_example
+ \usepackage{polyglossia}
+ \setmainlanguage[variant=polytonic]{greek}
+ \setotherlanguage{french}
+ #+end_example
+
- =LATEX_CLASS= ::
#+cindex: @samp{LATEX_CLASS}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 00fe101dc..fc9ac688a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -431,6 +431,19 @@ prompting for a link description. It can be a string (used as-is) or
a function (called with the same arguments as
~org-make-link-description-function~ to return a string to use).
+*** New list of languages for LaTeX export: ~org-latex-language-alist~
+
+~org-latex-language-alist~ unifies into a single list the old language
+lists for the =babel= and =polyglossia= LaTeX packages:
+~org-latex-babel-language-alist~ and
+~org-latex-polyglossia-language-alist~, respectively, which are
+declared obsolete.
+
+This new list captures the current state of art regarding language
+support in LaTeX. The new =babel= syntax for loading languages via
+=ini= files and the new command =\babelprovide= (see:
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf)
+are also supported.
* Version 9.5
** Important announcements and breaking changes
--
2.37.1
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
2022-08-08 14:39 9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
@ 2022-08-09 11:43 5% ` Ihor Radchenko
2022-08-16 14:16 8% ` Juan Manuel Macías
2022-08-09 15:39 6% ` [PATCH] Documentation and NEWS for ` org-latex-language-alist' Max Nikulin
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-09 11:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a patch with the documentation of the new variable in the
> Manual and the updated NEWS.
Thanks!
I tried to apply your patch and read the relevant section of the manual
from the beginning. I feel that the new wording is awkward.
The patch is adding text to LaTeX export settings section where
individual #+KEYWORDS are discussed. Yet, the patch goes deeply into
setting some variables from the very beginning only providing a single
example where the #+LANGUAGE keyword is actually used.
I attached the screenshot of HTML version of the manual for clarity.
[-- Attachment #2: exported-patch-as-it-reads.png --]
[-- Type: image/png, Size: 220253 bytes --]
[-- Attachment #3: Type: text/plain, Size: 613 bytes --]
I feel like we should first describe what #+LANGUAGE keyword does and
go into the gory details of LaTeX language support a bit later.
Basically, I am asking you to reshuffle paragraphs a bit possibly moving
some parts to more relevant 13.10.3 LaTeX header and sectioning
structure. People have no idea about #+LATEX_HEADER when reading 13.10.2
LaTeX specific export settings (coming before the 13.10.3).
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
2022-08-08 14:39 9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
2022-08-09 11:43 5% ` Ihor Radchenko
@ 2022-08-09 15:39 6% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-08-09 15:39 UTC (permalink / raw)
To: emacs-orgmode
On 08/08/2022 21:39, Juan Manuel Macías wrote:
>
> I am attaching a patch with the documentation of the new variable in the
> Manual and the updated NEWS.
> + =\babelprovide= command (see
> + http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
> + Valid usage examples could be:
Firefox may block downloading of a file through unencrypted http:
protocol if a link is opened from a https: page (HTML version of the Org
manual served from orgmode.org this case). The problem with CTAN mirrors
is that not all hosts have TLS certificates including their CTAN names.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
2022-08-09 11:43 5% ` Ihor Radchenko
@ 2022-08-16 14:16 8% ` Juan Manuel Macías
2022-08-18 15:39 6% ` Max Nikulin
2022-08-20 5:51 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-08-16 14:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Maxim Nikulin
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
Hi, Ihor. Sorry for my late reply. These last few days have been a bit
complicated for me due to work issues.
Ihor Radchenko writes:
> I feel like we should first describe what #+LANGUAGE keyword does and
> go into the gory details of LaTeX language support a bit later.
>
> Basically, I am asking you to reshuffle paragraphs a bit possibly moving
> some parts to more relevant 13.10.3 LaTeX header and sectioning
> structure. People have no idea about #+LATEX_HEADER when reading 13.10.2
> LaTeX specific export settings (coming before the 13.10.3).
I am attaching a new version of the patch.
Addendum: Just as I was going to send this email, I saw the other email
from Maxim in this thread, who says:
> Firefox may block downloading of a file through unencrypted http:
> protocol if a link is opened from a https: page (HTML version of the
> Org manual served from orgmode.org this case). The problem with CTAN
> mirrors is that not all hosts have TLS certificates including their
> CTAN names.
I can't figure out how to link to the babel documentation in a way other
than a link to CTAN. If this might be an inconvenience (due to https
issues), perhaps we could simply put in the documentation something like
'see the Babel docs', or referencing the command 'texdoc -M
babel', which opens the locally installed babel documentation. The
problem is that not all GNU/Linux distributions include the
documentation in their versions of TeX live. For example, Arch Linux
does not include documentation in the official repos and must be
installed separately via an AUR package.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-org-manual.org-documentation-for-org-latex-langu.patch --]
[-- Type: text/x-patch, Size: 4628 bytes --]
From 46192df70cd00e2eca2e8e059e9d39723b9d32d8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 16 Aug 2022 15:41:22 +0200
Subject: [PATCH] doc/org-manual.org: documentation for
`org-latex-language-alist'
* etc/ORG-NEWS: update the news with the new variable.
---
doc/org-manual.org | 58 ++++++++++++++++++++++++++++++++++++++++++++--
etc/ORG-NEWS | 13 +++++++++++
2 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..8973f08ce 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13370,15 +13370,21 @@ general options (see [[*Export Settings]]).
- =LANGUAGE= ::
#+cindex: @samp{LANGUAGE}, keyword
#+vindex: org-latex-packages-alist
+ #+vindex: org-latex-language-alist
+
+ The list of languages supported by Org is stored in the variable
+ ~org-latex-language-alist~.
+
In order to be effective, the =babel= or =polyglossia=
packages---according to the LaTeX compiler used---must be loaded
with the appropriate language as argument. This can be accomplished
by modifying the ~org-latex-packages-alist~ variable, e.g., with the
- following snippet:
+ following snippet (note that =polyglossia= does not work with
+ pdfLaTeX):
#+begin_src emacs-lisp
(add-to-list 'org-latex-packages-alist
- '("AUTO" "babel" t ("pdflatex")))
+ '("AUTO" "babel" t ("pdflatex" "xelatex" "lualatex")))
(add-to-list 'org-latex-packages-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_src
@@ -13508,6 +13514,54 @@ A sample Org file with the above headers:
some more text
#+end_example
+#+cindex: @samp{LANGUAGE}, keyword
+#+vindex: org-export-default-language
+LaTeX packages =babel= or =polyglossia= can also be loaded in a
+document. The "AUTO" string will be replaced in both cases by the
+appropiate value for the =LANGUAGE= keyword, if present in the
+document, or by the value of ~org-export-default-language~. Let's see
+some examples in one or another case.
+
+=Babel= accepts the classic syntax and (in addition) the new syntax
+with the =\babelprovide= command to load the languages using the new
+=INI= files procedure. Keep in mind that there are a number of
+languages that are only served in babel using =INI= files, so they
+cannot be declared using the classic syntax, but only using the
+=\babelprovide= command (see
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf).
+Valid usage examples could be:
+
+#+begin_example
+,#+LATEX_HEADER: \usepackage[french,italian,AUTO]{babel}
+#+end_example
+
+where "AUTO" is the main language. But it can also be loaded using
+the =\babelprovide= command:
+
+#+begin_example
+,#+LATEX_HEADER: \usepackage[french,italian]{babel}
+,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
+#+end_example
+
+=Polyglossia=, for this procedure to be effective, must be loaded
+using the same =babel= classic syntax (but note that /this is not/
+the actual polyglossia syntax). For example, suppose a document
+declares Polytonic Greek as the primary language, and French as the
+secondary language. In this case, it would be expressed as:
+
+#+begin_example
+,#+LANGUAGE: el-polyton
+,#+LATEX_HEADER: \usepackage[french,AUTO]{polyglossia}
+#+end_example
+
+This would produce in LaTeX (with the actual =polyglossia= syntax):
+
+#+begin_example
+\usepackage{polyglossia}
+\setmainlanguage[variant=polytonic]{greek}
+\setotherlanguage{french}
+#+end_example
+
*** Quoting LaTeX code
:PROPERTIES:
:DESCRIPTION: Incorporating literal @LaTeX{} code.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 00fe101dc..fc9ac688a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -431,6 +431,19 @@ prompting for a link description. It can be a string (used as-is) or
a function (called with the same arguments as
~org-make-link-description-function~ to return a string to use).
+*** New list of languages for LaTeX export: ~org-latex-language-alist~
+
+~org-latex-language-alist~ unifies into a single list the old language
+lists for the =babel= and =polyglossia= LaTeX packages:
+~org-latex-babel-language-alist~ and
+~org-latex-polyglossia-language-alist~, respectively, which are
+declared obsolete.
+
+This new list captures the current state of art regarding language
+support in LaTeX. The new =babel= syntax for loading languages via
+=ini= files and the new command =\babelprovide= (see:
+http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf)
+are also supported.
* Version 9.5
** Important announcements and breaking changes
--
2.37.2
^ permalink raw reply related [relevance 8%]
* [off topic] List all non-latin characters in a buffer
@ 2022-08-16 15:19 9% Juan Manuel Macías
2022-08-19 14:50 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-16 15:19 UTC (permalink / raw)
To: orgmode
Sorry for the offtopic, but I thought this homemade function I wrote
some time ago for my work might perhaps be useful to some Orgers. When
executed in a buffer, the `list-non-latin-chars' function opens a window
displaying a list of all the non (basic) Latin characters present in
that document. Each item in the list contains the character, its Unicode
canonical name, and its hexadecimal code. For example:
殿 CJK IDEOGRAPH-6BBF #6bbf
Also, each item is a button (created with button.el). If the button
is activated, there are currently two options: a: execute occur on that
character in the document; b : execute describe-char on that character.
By default, the characters displayed in the list correspond to any
Unicode block other than basic-latin. Which means that the zero width
space character is included, a very famous character in this mailing
list :-)
And here is the code (lexical binding is required). Of course, feedback
welcome.
Best regards,
Juan Manuel
#+begin_src emacs-lisp
(setq ext-chars-actions-list '((?a "Occur"
(lambda (buf char)
(interactive)
(with-current-buffer buf
(occur char))))
(?b "Describe char"
(lambda (buf char)
(interactive)
(with-current-buffer buf
(save-excursion
(goto-char (point-min))
(when (re-search-forward char nil t)
(describe-char (- (point) 1)))))))))
(defun ext-chars-choose-action (buf char)
(let ((opt (read-char-choice (concat "Escoger acción >>\n\n"
(mapconcat (lambda (item)
(format "%c: %s"
(car item) (nth 1 item)))
ext-chars-actions-list " --- "))
(mapcar #'car ext-chars-actions-list))))
(apply (nth 2 (assoc opt ext-chars-actions-list))
(list buf char))))
(defvar ext-chars-list nil)
(defun list-non-latin-chars ()
(interactive)
(setq ext-chars-list nil)
(let ((buf (buffer-name)))
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\([^\u0000-\u007F]\\)" nil t)
(add-to-list 'ext-chars-list (format "%s" (match-string 1))))
(setq ext-chars-list-final
(mapcar (lambda (char)
(let
((char-name (get-char-code-property (string-to-char char) 'name))
;; convert to hexadecimal
(char-code (format "#%x" (string-to-char char))))
(setq char (format "%s\s\s%s\s\s%s" char char-name char-code))))
ext-chars-list))
(let ((temp-buf (format "*non latin chars in %s*" buf)))
(when (get-buffer temp-buf)
(kill-buffer temp-buf))
(get-buffer-create temp-buf)
(set-buffer temp-buf)
;; necessary for Arabic, Hebrew, etc.
(setq bidi-display-reordering nil)
;; insert buttons list
(mapc (lambda (el)
(let ((char (when (string-match "^\\(.\\)\s" el)
(match-string 1 el))))
(insert-button (format "%s" el)
'action (lambda (x)
(interactive)
(ext-chars-choose-action buf char)))
(insert "\n\n")))
ext-chars-list-final)
(pop-to-buffer temp-buf)
(goto-char (point-min))
(view-mode)))))
#+end_src
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
2022-08-16 14:16 8% ` Juan Manuel Macías
@ 2022-08-18 15:39 6% ` Max Nikulin
2022-08-20 5:51 5% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-08-18 15:39 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 16/08/2022 21:16, Juan Manuel Macías wrote:
>
>> Firefox may block downloading of a file through unencrypted http:
>> protocol if a link is opened from a https: page (HTML version of the
>> Org manual served from orgmode.org this case). The problem with CTAN
>> mirrors is that not all hosts have TLS certificates including their
>> CTAN names.
>
> I can't figure out how to link to the babel documentation in a way other
> than a link to CTAN. If this might be an inconvenience (due to https
> issues), perhaps we could simply put in the documentation something like
> 'see the Babel docs', or referencing the command 'texdoc -M
> babel', which opens the locally installed babel documentation. The
> problem is that not all GNU/Linux distributions include the
> documentation in their versions of TeX live. For example, Arch Linux
> does not include documentation in the official repos and must be
> installed separately via an AUR package.
I would suggest https (TLS) link and title of the document. I believe
that is should be a requirement for "official" CTAN mirrors to have
valid TLS certificate.
P.S. Why there is no ol-texdoc.el?
^ permalink raw reply [relevance 6%]
* Re: [off topic] List all non-latin characters in a buffer
2022-08-16 15:19 9% [off topic] List all non-latin characters in a buffer Juan Manuel Macías
@ 2022-08-19 14:50 1% ` Uwe Brauer
2022-09-09 14:15 6% ` Robert Pluim
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-08-19 14:50 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan
> Sorry for the offtopic, but I thought this homemade function I wrote
> some time ago for my work might perhaps be useful to some Orgers. When
> executed in a buffer, the `list-non-latin-chars' function opens a window
> displaying a list of all the non (basic) Latin characters present in
> that document. Each item in the list contains the character, its Unicode
> canonical name, and its hexadecimal code. For example:
Very very nice,
Till now I used only a very simple search function
(defun my-search-no-ascii ()
"Simple function to search for no ASCII symbols in a file."
(interactive)
(skip-chars-forward "\001-\177"))
That is so much better!
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
2022-08-16 14:16 8% ` Juan Manuel Macías
2022-08-18 15:39 6% ` Max Nikulin
@ 2022-08-20 5:51 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-20 5:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Maxim Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a new version of the patch.
Thanks!
Applied onto main via 243ded74b adding one sentence to the =LANGUAGE=
keyword description and changing the ctan links to https.
I have added a short description of what LANGUAGE keyword value is:
"Language code of the primary document language."
> Addendum: Just as I was going to send this email, I saw the other email
> from Maxim in this thread, who says:
>
>> Firefox may block downloading of a file through unencrypted http:
>> protocol if a link is opened from a https: page (HTML version of the
>> Org manual served from orgmode.org this case). The problem with CTAN
>> mirrors is that not all hosts have TLS certificates including their
>> CTAN names.
>
> I can't figure out how to link to the babel documentation in a way other
> than a link to CTAN. If this might be an inconvenience (due to https
> issues), perhaps we could simply put in the documentation something like
> 'see the Babel docs', or referencing the command 'texdoc -M
> babel', which opens the locally installed babel documentation. The
> problem is that not all GNU/Linux distributions include the
> documentation in their versions of TeX live. For example, Arch Linux
> does not include documentation in the official repos and must be
> installed separately via an AUR package.
I went with https. It does open at least in some cases. The problem with
CTAN certificates is not our problem. Users may still search the
relevant documents if the link is dead.
Note that we still have a number of http links in the manual. One may
want to fix them.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: http: links in the manual
@ 2022-08-21 9:55 9% ` Juan Manuel Macías
2022-08-22 2:46 6% ` Auto-checking dead links in the manual (was: http: links in the manual) Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-21 9:55 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> One may got no response trying to fix a link.
>
> Max Nikulin to emacs-orgmode. [PATCH] org-manual.org: Update links to
> MathJax docs. Sun, 3 Oct 2021 23:17:46 +0700.
> https://list.orgmode.org/sjcl3b$gsr$1@ciao.gmane.io
>
> In the particular case of docs.mathjax.org I am unsure if mild
> preference of http: over https: is not a mistake in the server
> configuration. I do not mind "https:" there, any variant is better
> than the old broken link.
Maybe, instead of repairing the links manually, we could think of some
code that would do this work periodically, and also check the health of
the links, running a url request on each link and returning a list of
broken links. I don't know if it is possible to do something like that
in Elisp, as I don't have much experience with web and link issues. I
think there are also external tools, like Selenium Web Driver, but my
experience with it is very limited (I use Selenium from time to time
when I want to take a screenshot of a web page).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Auto-checking dead links in the manual (was: http: links in the manual)
2022-08-21 9:55 9% ` Juan Manuel Macías
@ 2022-08-22 2:46 6% ` Ihor Radchenko
2022-08-22 15:29 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-08-22 2:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Max Nikulin to emacs-orgmode. [PATCH] org-manual.org: Update links to
>> MathJax docs. Sun, 3 Oct 2021 23:17:46 +0700.
>> https://list.orgmode.org/sjcl3b$gsr$1@ciao.gmane.io
>>
>> In the particular case of docs.mathjax.org I am unsure if mild
>> preference of http: over https: is not a mistake in the server
>> configuration. I do not mind "https:" there, any variant is better
>> than the old broken link.
>
> Maybe, instead of repairing the links manually, we could think of some
> code that would do this work periodically, and also check the health of
> the links, running a url request on each link and returning a list of
> broken links. I don't know if it is possible to do something like that
> in Elisp, as I don't have much experience with web and link issues. I
> think there are also external tools, like Selenium Web Driver, but my
> experience with it is very limited (I use Selenium from time to time
> when I want to take a screenshot of a web page).
This is a good idea.
Selenium is probably an overkill since we should better not link JS-only
websites from the manual anyway. What we can do instead is a make target
that will use something like wget.
Patches are welcome!
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 6%]
* Re: Auto-checking dead links in the manual (was: http: links in the manual)
2022-08-22 2:46 6% ` Auto-checking dead links in the manual (was: http: links in the manual) Ihor Radchenko
@ 2022-08-22 15:29 0% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-08-22 15:29 UTC (permalink / raw)
To: emacs-orgmode
On 22/08/2022 09:46, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>
>> Maybe, instead of repairing the links manually, we could think of some
>> code that would do this work periodically, and also check the health of
>> the links, running a url request on each link and returning a list of
>> broken links. I don't know if it is possible to do something like that
>> in Elisp, as I don't have much experience with web and link issues. I
>> think there are also external tools, like Selenium Web Driver, but my
>> experience with it is very limited (I use Selenium from time to time
>> when I want to take a screenshot of a web page).
>
> This is a good idea.
>
> Selenium is probably an overkill since we should better not link JS-only
> websites from the manual anyway. What we can do instead is a make target
> that will use something like wget.
>
> Patches are welcome!
I hope that selenium is currently overkill, however more sites are
starting to use anti-DDOS shields like cloudflare and HTTP client may be
banned just because it does not fetch other resources like JS scripts.
I do not have a patch, just an idea: export backend that ignores
everything besides link and either send requests from lisp code or
generate file for another tool.
#+attr_linklint: ...
may be used to specify regexp that target page is expected to contain.
There are some complications like e.g. "info:" links having special code
to generate HTML with URL derived from original path. So it may be more
robust to parse HTML document (without checking of linked document text).
^ permalink raw reply [relevance 0%]
* Re: Have all the tags of a heading, with a tag hierarchy
@ 2022-08-28 16:21 13% ` Juan Manuel Macías
2022-08-28 16:34 5% ` Cletip Cletip
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-08-28 16:21 UTC (permalink / raw)
To: Cletip Cletip; +Cc: orgmode
Cletip Cletip writes:
> After multiple searches on the internet, I did not find the answer to
> my question (which is the subject of this mail): when calling the
> "org-get-tags" function, only the tags put on the heading, and not the
> inherited tags, are retrieved. How can I get the inherited tags as
> well? Does such a function already exist? Did I miss an essential
> variable?
In my case, I do manage to get the iherited tags. Do you have
`org-use-tag-inheritance' set to non-nil?
According to the `org-get-tags' docstring:
> According to ‘org-use-tag-inheritance’, tags may be inherited from
> parent headlines, and from the whole document, through
> ‘org-file-tags’. In this case, the returned list of tags contains tags
> in this order: file tags, tags inherited from parent headlines, local
> tags. If a tag appears multiple times, only the most local tag is
> returned.
and
> However, when optional argument LOCAL is non-nil, only return tags
> specified at the headline.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Have all the tags of a heading, with a tag hierarchy
2022-08-28 16:21 13% ` Juan Manuel Macías
@ 2022-08-28 16:34 5% ` Cletip Cletip
0 siblings, 0 replies; 200+ results
From: Cletip Cletip @ 2022-08-28 16:34 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]
Thank you for your answer!
I may not have been specific enough:
I want the tags also inherited with this "method"
https://orgmode.org/manual/Tag-Hierarchy.html.
So imagine this in your configuration file
(setq org-tag-alist '((:startgrouptag)
("GTD")
(:grouptags)
("Control")
(:Persp)
(:endgrouptag)
(:startgrouptag)
( Control)
(:grouptags)
("Context")
(:Task")
(:endgrouptag))
So, if I put the "Control" tag, I am also supposed to have the "GTD" tag,
because "Control" is a child of "GTD".
But, with the "org-get-tags" function, I don't have this famous "GTD" tag
Le dim. 28 août 2022 à 18:22, Juan Manuel Macías <maciaschain@posteo.net> a
écrit :
> Cletip Cletip writes:
>
> > After multiple searches on the internet, I did not find the answer to
> > my question (which is the subject of this mail): when calling the
> > "org-get-tags" function, only the tags put on the heading, and not the
> > inherited tags, are retrieved. How can I get the inherited tags as
> > well? Does such a function already exist? Did I miss an essential
> > variable?
>
> In my case, I do manage to get the iherited tags. Do you have
> `org-use-tag-inheritance' set to non-nil?
>
> According to the `org-get-tags' docstring:
>
> > According to ‘org-use-tag-inheritance’, tags may be inherited from
> > parent headlines, and from the whole document, through
> > ‘org-file-tags’. In this case, the returned list of tags contains tags
> > in this order: file tags, tags inherited from parent headlines, local
> > tags. If a tag appears multiple times, only the most local tag is
> > returned.
>
> and
>
> > However, when optional argument LOCAL is non-nil, only return tags
> > specified at the headline.
>
> Best regards,
>
> Juan Manuel
>
> --
> --
> ------------------------------------------------------
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
[-- Attachment #2: Type: text/html, Size: 3290 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Agenda 'Org view' (org-projection?)
@ 2022-09-06 14:21 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-06 14:21 UTC (permalink / raw)
To: Eduardo Suarez; +Cc: orgmode
Hi, Eduardo:
Eduardo Suarez writes:
> Based on my previous mail "Manual Ordering and Dynamic Priority" I would like
> also to comment about this related idea.
>
> In Agenda, it is possible to generate different views. I wonder whether it
> would be possible to generate an "org mode" view. That is, a buffer in org-mode
> format with all the tasks from our agenda query (no really a sparse tree view).
> Then that file could be edited and reordered to create a planning. If the file
> could also sync with new queries that would be great. I think of that maybe as
> a package called 'org-projection' (project org into org).
>
> With such feature, I could have a general org file e.g. for a working project,
> and then a planning (projected) file in association with it. I would add the
> latter to the Agenda files.
>
> I can't do lisp development and have no idea if that makes sense, but I just
> wanted to share this idea with you.
I think this is not 100% related to what you're proposing, but if it
helps, I use the excellent org-super-agenda package a lot, which allows
you to sort and compose the agenda view according to many parameters:
tags, priorities, properties, etc:
https://github.com/alphapapa/org-super-agenda
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [off topic] List all non-latin characters in a buffer
2022-08-19 14:50 1% ` Uwe Brauer
@ 2022-09-09 14:15 6% ` Robert Pluim
0 siblings, 0 replies; 200+ results
From: Robert Pluim @ 2022-09-09 14:15 UTC (permalink / raw)
To: emacs-orgmode
>>>>> On Fri, 19 Aug 2022 16:50:54 +0200, Uwe Brauer <oub@mat.ucm.es> said:
>>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Uwe> Hi Juan
>> Sorry for the offtopic, but I thought this homemade function I wrote
>> some time ago for my work might perhaps be useful to some Orgers. When
>> executed in a buffer, the `list-non-latin-chars' function opens a window
>> displaying a list of all the non (basic) Latin characters present in
>> that document. Each item in the list contains the character, its Unicode
>> canonical name, and its hexadecimal code. For example:
Uwe> Very very nice,
Uwe> Till now I used only a very simple search function
Uwe> (defun my-search-no-ascii ()
Uwe> "Simple function to search for no ASCII symbols in a file."
Uwe> (interactive)
Uwe> (skip-chars-forward "\001-\177"))
Equivalently you can do
(skip-chars-forward "[[:ascii:]]")
(or use `re-search-forward' with the [:nonascii:] character class.)
Robert
--
^ permalink raw reply [relevance 6%]
* Re: error org export to pdf when latex letter class has been added to org-latex-classes
@ 2022-09-13 17:55 13% ` Juan Manuel Macías
2022-09-13 19:59 5% ` M. Pger
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-13 17:55 UTC (permalink / raw)
To: M. Pger; +Cc: orgmode
Hi,
M. Pger writes:
> (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
>
> ! LaTeX Error: Environment thebibliography undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H <return> for immediate help.
> ...
>
> l.1063 \renewenvironment{thebibliography}
> [1]{%
> ?
> ! Emergency stop.
> ...
>
> l.1063 \renewenvironment{thebibliography}
> [1]{%
> ! ==> Fatal error occurred, no output PDF file produced!
Are you including citations in your letter? Maybe this is related:
https://latex.org/forum/viewtopic.php?f=4&t=3359
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: error org export to pdf when latex letter class has been added to org-latex-classes
2022-09-13 19:59 5% ` M. Pger
@ 2022-09-13 20:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-13 20:15 UTC (permalink / raw)
To: M. Pger; +Cc: orgmode
M. Pger writes:
> Thank you for your answer.
>
>> Are you including citations in your letter?
>
> No, that's also why it is puzzling. You should be able to reproduce
> the issue by creating a really minimalist init file including the
> following:
>
> ```
> (with-eval-after-load 'ox-latex
> (add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
> )
>
> (setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
> ```
>
> As mentioned in my previous mail, the error also appears when using `pdflatex` instead of `latexmk`.
Hmm, it's weird. With your configuration I cannot reproduce the problem.
Anyway, I have Org configured so that it doesn't load any package in the
preamble.
And if you directly compile the .tex file generated by org during
export, does it also give you an error? Could you please paste the
preamble of that tex file here, up to the \begin{document}?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: error org export to pdf when latex letter class has been added to org-latex-classes
2022-09-13 17:55 13% ` Juan Manuel Macías
@ 2022-09-13 19:59 5% ` M. Pger
2022-09-13 20:15 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: M. Pger @ 2022-09-13 19:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi,
Thank you for your answer.
> Are you including citations in your letter?
No, that's also why it is puzzling. You should be able to reproduce the issue by creating a really minimalist init file including the following:
```
(with-eval-after-load 'ox-latex
(add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
)
(setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
```
As mentioned in my previous mail, the error also appears when using `pdflatex` instead of `latexmk`.
Best,
M
------- Original Message -------
On Tuesday, September 13th, 2022 at 7:55 PM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> M. Pger writes:
>
> > (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
> >
> > ! LaTeX Error: Environment thebibliography undefined.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H <return> for immediate help.
> > ...
> >
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ?
> > ! Emergency stop.
> > ...
> >
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ! ==> Fatal error occurred, no output PDF file produced!
>
>
> Are you including citations in your letter? Maybe this is related:
> https://latex.org/forum/viewtopic.php?f=4&t=3359
>
> Best regards,
>
> Juan Manuel
>
> --
> --
> ------------------------------------------------------
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 5%]
* [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-18 12:27 9% Juan Manuel Macías
2022-09-18 16:14 6% ` Max Nikulin
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-18 12:27 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
Hi all,
I don't know if the following scenario usually appears in the workflow
of other Org users as well. Otherwise, I think this patch could be
ignored.
In my workflow I often need to pre- or postpend some LaTeX code
immediately before or after a section. Consider the following example:
------------------
* A section
Lorem ipsum
#+latex: \foo
* Another section
Lorem ipsum
-----------------
The \foo command affects the second section, but for Org it belongs to
the content of the first section. If I comment this section out or mark
it as non-exportable, then the LaTeX code has no effect. I think a
simple solution could be to have the PRESEC AND POSTSEC properties to
prepend or postpend arbitrary code to a section. These properties could be
extended with PRESEC+ and POSTSEC+. An example of use:
* Section
:PROPERTIES:
:presec: \begingroup\foo
:postsec: \endgroup
:END:
...
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-properties-for-arbitrary-LaTeX-.patch --]
[-- Type: text/x-patch, Size: 2844 bytes --]
From 56924d69a2090dfeedf4b35ca33e10a48cbc42b5 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 18 Sep 2022 13:56:05 +0200
Subject: [PATCH] lisp/ox-latex.el: Add properties for arbitrary LaTeX code.
* (org-latex-headline): The `PRESEC' and `POSTSEC' properties prepend
and postpend arbitrary LaTeX code to a section, respectively.
---
lisp/ox-latex.el | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1eb70ab20..a8c9aecd2 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2322,22 +2322,32 @@ holding contextual information."
(and (string-match-p "\\<headlines\\>" v)
(string-match-p "\\<local\\>" v)
(format "\\stopcontents[level-%d]" level)))))
- info t)))))
- (if (and opt-title
- (not (equal opt-title full-text))
- (string-match "\\`\\\\\\(.+?\\){" section-fmt))
- (format (replace-match "\\1[%s]" nil nil section-fmt 1)
- ;; Replace square brackets with parenthesis
- ;; since square brackets are not supported in
- ;; optional arguments.
- (replace-regexp-in-string
- "\\[" "(" (replace-regexp-in-string "\\]" ")" opt-title))
- full-text
- (concat headline-label pre-blanks contents))
- ;; Impossible to add an alternative heading. Fallback to
- ;; regular sectioning format string.
- (format section-fmt full-text
- (concat headline-label pre-blanks contents))))))))
+ info t))))
+ ;; `PRESEC' and `POSTSEC' properties for arbitrary LaTeX code.
+ (pre-sec (let ((beg (org-element-property :begin headline)))
+ (goto-char beg)
+ (org-entry-get nil "PRESEC")))
+ (post-sec (let ((beg (org-element-property :begin headline)))
+ (goto-char beg)
+ (org-entry-get nil "POSTSEC"))))
+ (concat
+ (when pre-sec (format "%s\n\n" pre-sec))
+ (if (and opt-title
+ (not (equal opt-title full-text))
+ (string-match "\\`\\\\\\(.+?\\){" section-fmt))
+ (format (replace-match "\\1[%s]" nil nil section-fmt 1)
+ ;; Replace square brackets with parenthesis
+ ;; since square brackets are not supported in
+ ;; optional arguments.
+ (replace-regexp-in-string
+ "\\[" "(" (replace-regexp-in-string "\\]" ")" opt-title))
+ full-text
+ (concat headline-label pre-blanks contents))
+ ;; Impossible to add an alternative heading. Fallback to
+ ;; regular sectioning format string.
+ (format section-fmt full-text
+ (concat headline-label pre-blanks contents)))
+ (when post-sec (format "%s\n\n" post-sec))))))))
(defun org-latex-format-headline-default-function
(todo _todo-type priority text tags _info)
--
2.37.3
^ permalink raw reply related [relevance 9%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-18 12:27 9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
@ 2022-09-18 16:14 6% ` Max Nikulin
2022-09-19 10:04 5% ` Fraga, Eric
2022-09-20 13:26 5% ` Ihor Radchenko
2 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-09-18 16:14 UTC (permalink / raw)
To: emacs-orgmode
On 18/09/2022 19:27, Juan Manuel Macías wrote:
>
> * Section
> :PROPERTIES:
> :presec: \begingroup\foo
> :postsec: \endgroup
> :END:
Juan Manuel, can it be implemented using a derived backend that calls
the original variant of headline transcoder (`org-latex-headline') and
adds pre/post code to the returned value? I have not tried to implement
this idea, so perhaps I just have missed something obvious. Actually I
wonder if the purpose of your patch is solely convenience or you faced a
limitation with no reasonable workaround.
My only real objection is that the new keywords works for LaTeX only,
but their names are rather generic. Moreover, Org's term is "headline",
not "section". I would consider something like
- :headline_pre_latex: \begingroup\foo
- :headline_pre: :latex \begingroup\foo
By the way, are affiliated keywords a part of the following headline?
* Section One
#+attr_latex: :headline_pre \begingroup\foo
* Section Two
^ permalink raw reply [relevance 6%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-18 12:27 9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
2022-09-18 16:14 6% ` Max Nikulin
@ 2022-09-19 10:04 5% ` Fraga, Eric
2022-09-20 13:26 5% ` Ihor Radchenko
2 siblings, 0 replies; 200+ results
From: Fraga, Eric @ 2022-09-19 10:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Sunday, 18 Sep 2022 at 12:27, Juan Manuel Macías wrote:
> I don't know if the following scenario usually appears in the workflow
> of other Org users as well. Otherwise, I think this patch could be
> ignored.
I would find something like this useful as I often have commands such as
\newpage and \appendix preceding a headline, commands that are indeed
not really part of the previous element.
I've not tried your patch: I've been on holiday [1] and have come back
to 3000+ emails so I'll be some time...
eric
Footnotes:
[1] definition: turn all Internet access off and have a break,
preferably with good company, food, drink, and sunshine.
--
: Eric S Fraga, with org release_9.5.4-768-g5bb699 in Emacs 29.0.50
^ permalink raw reply [relevance 5%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-18 12:27 9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
2022-09-18 16:14 6% ` Max Nikulin
2022-09-19 10:04 5% ` Fraga, Eric
@ 2022-09-20 13:26 5% ` Ihor Radchenko
2022-09-20 17:18 10% ` Juan Manuel Macías
2 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-20 13:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I don't know if the following scenario usually appears in the workflow
> of other Org users as well. Otherwise, I think this patch could be
> ignored.
>
> In my workflow I often need to pre- or postpend some LaTeX code
> immediately before or after a section. Consider the following example:
>
> ------------------
> * A section
>
> Lorem ipsum
>
> #+latex: \foo
>
> * Another section
>
> Lorem ipsum
> -----------------
>
> The \foo command affects the second section, but for Org it belongs to
> the content of the first section. If I comment this section out or mark
> it as non-exportable, then the LaTeX code has no effect. I think a
> simple solution could be to have the PRESEC AND POSTSEC properties to
> prepend or postpend arbitrary code to a section. These properties could be
> extended with PRESEC+ and POSTSEC+. An example of use:
I do not like this idea.
Please remember that headlines may be exported as parts, sections,
subsections, list items, or paragraphs depending on the headline level.
Arbitrary pre/post commands may unexpectedly break things during export.
However, I do agree that per-heading control over latex export is
currently cumbersome.
The canonical ox-latex approach to customize headline export is
org-latex-classes variable. This variable defines (among other things)
pre/post commands during headline export:
>> The sectioning structure of the class is given by the elements
>> following the header string. For each sectioning level, a number
>> of strings is specified. A %s formatter is mandatory in each
>> section string and will be replaced by the title of the section.
>>
>> Instead of a cons cell (numbered . unnumbered), you can also
>> provide a list of 2 or 4 elements,
>>
>> (numbered-open numbered-close)
>>
>> or
>>
>> (numbered-open numbered-close unnumbered-open unnumbered-close)
>>
>> providing opening and closing strings for a LaTeX environment
>> that should represent the document section. The opening clause
>> should have a %s to represent the section title.
>>
>> Instead of a list of sectioning commands, you can also specify
>> a function name. That function will be called with two
>> parameters, the (reduced) level of the headline, and a predicate
>> non-nil when the headline should be numbered. It must return
>> a format string in which the section title will be added.
What about allowing to customize these open/close statements on
per-heading level during export? This will be more consistent with the
existing ox-latex structure.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-20 13:26 5% ` Ihor Radchenko
@ 2022-09-20 17:18 10% ` Juan Manuel Macías
2022-09-21 8:55 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-20 17:18 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I do not like this idea.
> Please remember that headlines may be exported as parts, sections,
> subsections, list items, or paragraphs depending on the headline level.
> Arbitrary pre/post commands may unexpectedly break things during export.
I don't see why, if the user knows LaTeX and knows what he/she is doing.
Sometimes it's just adding an "\addtocontents" just before the
section/subsection,etc. The property that adds the string before and the
property that adds the string after are understood to affect the entire
heading at the current level and its contents, including lower levels.
For example, if someone wants the current heading (and all its
sublevels) not to be included in the TOC but to be included in the
headers of the pages, it would suffice to (I keep here the original name
of the properties that I proposed in the patch, but I think Maxim's
proposed name is more accurate):
-----------------------------------
* Section
:PROPERTIES:
:presec: \setcounter{secnumdepth}{0}
:presec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
:postsec: \setcounter{secnumdepth}{2}
:postsec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
:END:
Lorem ipsum dolor.
** Subsection one
lorem
** Subsection two
ipsum
Which would pass to LaTeX as:
\setcounter{secnumdepth}{0} \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
\section{Section}
Lorem ipsum dolor.
\subsection{Subsection one}
lorem
\subsection{Subsection two}
ipsum
\setcounter{secnumdepth}{2} \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
----------------------------------
(The above can even be simplified from LaTeX by defining a simple
environment, but I've exemplified it like this to make it look better).
In what situations might this return unexpected results?
> However, I do agree that per-heading control over latex export is
> currently cumbersome.
>
> The canonical ox-latex approach to customize headline export is
> org-latex-classes variable. This variable defines (among other things)
> pre/post commands during headline export:
Apologies in advance if I misunderstood what you're suggesting, but
isn't the "org-latex-classes" property supposed to affect the structure
of the entire document? What I'm proposing here is rather something
specific to particular headings (and its entire content), like the
":ALT_TITLE:" property. If I understand correctly, what you are
suggesting is that org-latex-classes can have "local values" for
specific headings, if such headings are 'marked' with some property?
Best regards,
Juan Manuel
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: Re [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-20 19:35 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-20 19:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
>> Can it be extended to add properties to a
>> #BEGIN_example
>> #END_example
>> snippet?
>
> Didn't we conclude that wrapping blocks during LaTeX export should be
> done via special blocks? (This question has been raised multiple times,
> I am unsure if you are referring to the same discussion I have in mind).
Special blocks is usually the best solution for these cases. But
(without wishing to add more fuel to old discussions) I think it would
be nice to have as attr_latex a series of positions similar to the hooks
in the etoolbox LaTeX package:
\AtBeginEnvironment
\AtEndEnvironment
\BeforeBeginEnvironment
\AfterEndEnvironment
Something like :pre :post :precontent :postcontent.
In the case of blocks, I think this would simplify the documents a lot
if what you are looking for makes sense only in LaTeX export (special
blocks are exported to everything).
And in the case of floating objects such as tables or figures, it would
be really useful, since here you cannot resort to the use of special
blocks (*inside* those environments, I mean), and the workarounds that are
usually provided are still a bit tricky.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-20 17:18 10% ` Juan Manuel Macías
@ 2022-09-21 8:55 5% ` Ihor Radchenko
2022-09-21 14:43 10% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2022-09-21 8:55 UTC (permalink / raw)
To: Juan Manuel Macías, Daniel Fleischer; +Cc: orgmode
Adding Daniel Fleischer (the ox-latex maintainer) to this exchange.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> I do not like this idea.
>> Please remember that headlines may be exported as parts, sections,
>> subsections, list items, or paragraphs depending on the headline level.
>> Arbitrary pre/post commands may unexpectedly break things during export.
>
> I don't see why, if the user knows LaTeX and knows what he/she is doing.
> Sometimes it's just adding an "\addtocontents" just before the
> section/subsection,etc. The property that adds the string before and the
> property that adds the string after are understood to affect the entire
> heading at the current level and its contents, including lower levels.
> For example, if someone wants the current heading (and all its
> sublevels) not to be included in the TOC but to be included in the
> headers of the pages, it would suffice to (I keep here the original name
> of the properties that I proposed in the patch, but I think Maxim's
> proposed name is more accurate):
>
> -----------------------------------
>
> * Section
> :PROPERTIES:
> :presec: \setcounter{secnumdepth}{0}
> :presec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :postsec: \setcounter{secnumdepth}{2}
> :postsec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
> Lorem ipsum dolor.
There is nothing wrong about this, but I feel that this kind of approach
is encouraging to shoot your own leg a bit too much. It will be better
if Org provides a semantics that is facilitating more safe approach.
More below.
> Which would pass to LaTeX as:
>
> \setcounter{secnumdepth}{0} \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>
> \section{Section}
> Lorem ipsum dolor.
> \subsection{Subsection one}
> lorem
> \subsection{Subsection two}
> ipsum
>
> \setcounter{secnumdepth}{2} \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> ----------------------------------
>
> (The above can even be simplified from LaTeX by defining a simple
> environment, but I've exemplified it like this to make it look better).
>
> In what situations might this return unexpected results?
It may produce unexpected results if "Section" heading is demoted all
the way to paragraph. Also, :presec/:postsec property names are
confusing --- it is unclear if they are specific to LaTeX. (when about,
say, Beamer)
>> However, I do agree that per-heading control over latex export is
>> currently cumbersome.
>>
>> The canonical ox-latex approach to customize headline export is
>> org-latex-classes variable. This variable defines (among other things)
>> pre/post commands during headline export:
>
> Apologies in advance if I misunderstood what you're suggesting, but
> isn't the "org-latex-classes" property supposed to affect the structure
> of the entire document? What I'm proposing here is rather something
> specific to particular headings (and its entire content), like the
> ":ALT_TITLE:" property. If I understand correctly, what you are
> suggesting is that org-latex-classes can have "local values" for
> specific headings, if such headings are 'marked' with some property?
Yes, org-latex-classes is controlling the entire document. What I am
proposing (as an alternative) is subtree-level equivalent of
org-latex-classes that is also close to org-latex-classes semantics.
More concretely, I mean something like
* Section
:PROPERTIES:
:attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
:attr_latex+: :prepend "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
:attr_latex+: :append "section" \setcounter{secnumdepth}{2}
:attr_latex+: :append "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
:END:
I suggest to use more canonical attr_latex that explicitly limits the
export backend.
Further, it mentions a regexp limiting the applicable LaTeX environment
("section"). In other environments, the code will be omitted.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-21 8:55 5% ` Ihor Radchenko
@ 2022-09-21 14:43 10% ` Juan Manuel Macías
2022-09-22 14:08 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-21 14:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> It may produce unexpected results if "Section" heading is demoted all
> the way to paragraph.
If Section heading is demoted all the way to paragraph, I assume that
the expected will happen: that in the output to LaTeX a string will be
added before \paragraph and another string after the content of
\paragraph, which is perfectly consistent with the behavior of these two
properties. It is not that I intend to insist on a discussion; I just
don't quite understand what you mean. Note that these properties are for
LaTeX fine-tuning, and the user is expected to know what he/she wants
and where he/she wants it. If a user wants the arbitrary LaTeX code
before a certain header to be exported as a section (because, for
example, he/she has defined a command in LaTeX that changes the style of
the next \section), you would expect to put those properties in a
"\section" heading.
> Also, :presec/:postsec property names are
> confusing --- it is unclear if they are specific to LaTeX. (when about,
> say, Beamer)
Yes, I agree with that, and I had already commented on it in my previous
message, based on what Maxim had pointed out before, that the names I
had chosen were too imprecise. I like part of what you propose below:
`:attr_latex: :prepend'.
>>> However, I do agree that per-heading control over latex export is
>>> currently cumbersome.
>>>
>>> The canonical ox-latex approach to customize headline export is
>>> org-latex-classes variable. This variable defines (among other things)
>>> pre/post commands during headline export:
>>
>> Apologies in advance if I misunderstood what you're suggesting, but
>> isn't the "org-latex-classes" property supposed to affect the structure
>> of the entire document? What I'm proposing here is rather something
>> specific to particular headings (and its entire content), like the
>> ":ALT_TITLE:" property. If I understand correctly, what you are
>> suggesting is that org-latex-classes can have "local values" for
>> specific headings, if such headings are 'marked' with some property?
>
> Yes, org-latex-classes is controlling the entire document. What I am
> proposing (as an alternative) is subtree-level equivalent of
> org-latex-classes that is also close to org-latex-classes semantics.
>
> More concretely, I mean something like
>
> * Section
> :PROPERTIES:
> :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
> :attr_latex+: :prepend "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
> :attr_latex+: :append "section" \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
>
> I suggest to use more canonical attr_latex that explicitly limits the
> export backend.
I see. But in any case, something like `:prepend "section"' would be
unnecessary (and even counterproductive) for what I'm proposing, but I'm
afraid I didn't explain myself well in the first message. One of the
benefits of approaching this issue with a few minor modifications to
org-latex-headline is that the result is regardless of the section level
at which the property is applied. We may want to prefix the section with
a specific LaTeX code only for \section (or \paragraph or whatever) and
we may want to introduce a more general LaTeX code, level-agnostic.
Explicitly put "section", "subsection", etc, IMHO unnecessarily
complicates things. But I also insist (as I said at the beginning) that
I don't know if this use case can also be extended to other users.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
@ 2022-09-21 14:51 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-21 14:51 UTC (permalink / raw)
To: Daniel Fleischer; +Cc: Ihor Radchenko, orgmode
Daniel Fleischer writes:
> I don't understand the usecase, that's why I wasn't really following. If
> you write \vspace{10cm} before some headline, it's going to do the right
> thing even if it "belongs" to a previous headline.
Imagine, for example, that you have defined a LaTeX command that changes
the style of the section (or chapter, subsection, or whatever) below.
And you want to apply it before a certain section. If for any reason you
comment out the preceding section, or mark it as non-exportable, or even
delete it, the preceding command is no longer there when you export to
LaTeX. That would also happen if you move the section.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-21 14:43 10% ` Juan Manuel Macías
@ 2022-09-22 14:08 5% ` Ihor Radchenko
2022-09-24 14:50 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-22 14:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I suggest to use more canonical attr_latex that explicitly limits the
>> export backend.
>
> I see. But in any case, something like `:prepend "section"' would be
> unnecessary (and even counterproductive) for what I'm proposing, but I'm
> afraid I didn't explain myself well in the first message. One of the
> benefits of approaching this issue with a few minor modifications to
> org-latex-headline is that the result is regardless of the section level
> at which the property is applied. We may want to prefix the section with
> a specific LaTeX code only for \section (or \paragraph or whatever) and
> we may want to introduce a more general LaTeX code, level-agnostic.
> Explicitly put "section", "subsection", etc, IMHO unnecessarily
> complicates things. But I also insist (as I said at the beginning) that
> I don't know if this use case can also be extended to other users.
Yeah. Extra matcher is probably too cumbersome.
Yet, I feel like conditional prefix/suffix may be useful in some
scenarios.
Having read the available replies in this thread, I am thinking of the
following:
1. Instead of explicit prefix and suffix, we can unify extra text around
the exported Org element to a template:
* headline
:PROPERTIES:
:ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
:ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
:ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " *this*)
:ATTR_BACKEND+: babel_block_name(exported=*this*)
:ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
:ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
:END:
#+ATTR_BACKEND: :export_template "can also work on non-headings"
Paragraph.
2. The generic Org export routine will remove the :export_template
attributes prior to passing the element to backend-defined export
transcoder, thus avoiding the problem Max raised wrt ox-html
attributes.
3. Similar to :export_template, we can have
:export_prefix/:export_suffix, but I feel that the template will be
more flexible.
WDYT?
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-22 14:08 5% ` Ihor Radchenko
@ 2022-09-24 14:50 11% ` Juan Manuel Macías
2022-09-25 3:33 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-24 14:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, sorry for the late reply,
Ihor Radchenko writes:
> Having read the available replies in this thread, I am thinking of the
> following:
>
> 1. Instead of explicit prefix and suffix, we can unify extra text around
> the exported Org element to a template:
>
> * headline
> :PROPERTIES:
> :ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
> :ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
> :ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " *this*)
> :ATTR_BACKEND+: babel_block_name(exported=*this*)
> :ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
> :ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
> :END:
I really like this approach and I would buy it. On the one hand, if I
understand correctly, it's a universal solution that doesn't depend on a
particular backend (although, to be honest, I don't see much use for
this beyond LaTeX: maybe in HTML). And, on the other hand,
`:export_template' is an attribute that can be, as you say, very
versatile. With this, in my opinion, it would no longer be necessary to
define two 'pre' and 'post' attributes.
I imagine the value of ATTR_BACKEND (would quotes be necessary?) could
be easily converted to a plist, with code borrowed from
`org-export-read-attribute':
(:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} ... etc. ...")
> #+ATTR_BACKEND: :export_template "can also work on non-headings"
> Paragraph.
In this case I would not see it necessary, IMHO. For simple things (of
the begin/end style) there are the special blocks. And for more complex
pre- and/or post- code we have export blocks and export snippets. Since
there is no heading involved here, there would be no danger of the
pre-code leaving with the content of the previous header.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-24 14:50 11% ` Juan Manuel Macías
@ 2022-09-25 3:33 6% ` Ihor Radchenko
2022-09-25 12:06 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-25 3:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>> Paragraph.
>
> In this case I would not see it necessary, IMHO. For simple things (of
> the begin/end style) there are the special blocks. And for more complex
> pre- and/or post- code we have export blocks and export snippets. Since
> there is no heading involved here, there would be no danger of the
> pre-code leaving with the content of the previous header.
I do not insist on this. I just see supporting this easier (it will work
automatically) compared to explicitly limiting :export_template to
headings/inlinetasks.
Also, some people prefer to have such option (Pedro Andres Aranda
Gutierrez in off-list reply to
https://orgmode.org/list/87fsgmyyhw.fsf@localhost)
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 6%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-25 3:33 6% ` Ihor Radchenko
@ 2022-09-25 12:06 10% ` Juan Manuel Macías
2022-09-26 3:56 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-25 12:06 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>>> Paragraph.
>>
>> In this case I would not see it necessary, IMHO. For simple things (of
>> the begin/end style) there are the special blocks. And for more complex
>> pre- and/or post- code we have export blocks and export snippets. Since
>> there is no heading involved here, there would be no danger of the
>> pre-code leaving with the content of the previous header.
>
> I do not insist on this. I just see supporting this easier (it will work
> automatically) compared to explicitly limiting :export_template to
> headings/inlinetasks.
>
> Also, some people prefer to have such option (Pedro Andres Aranda
> Gutierrez in off-list reply to
> https://orgmode.org/list/87fsgmyyhw.fsf@localhost)
Well, it's evident that your idea of the export_template attribute is
very productive and can be consistently extended to more situations. One
scenario where I think it would be very useful is also in tables and
figures, but in this case to insert arbitrary code *inside* the table,
figure, etc. environments. This is something that gets asked on the list
from time to time and the solutions provided are usually a bit tricky.
Going back to the earlier :ATTR_BACKEND: issue as a property for
headings, I've been doing some testing and scribbled down a possible
function[1] whose code is almost entirely stolen from
org-export-read-attribute, with some modifications. Evaluated at the
headline, it returns the value of the ATTR_BACKEND property as a plist.
And then that plist could be easily manipulated on each backend to
format export_template conveniently. For example:
* headline
:PROPERTIES:
:ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
:ATTR_LaTeX+: blah blah blah
:END:
==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")
I don't know if that would be the way to go...
Best regards,
Juan Manuel
[1]
(defun possible-function (attribute)
"TODO"
(let* ((prepare-value
(lambda (str)
(save-match-data
(cond ((member str '(nil "" "nil")) nil)
((string-match "^\"\\(\"+\\)?\"$" str)
(or (match-string 1 str) ""))
(t str)))))
(attributes
(let ((value (org-entry-get nil attribute)))
(when value
(let ((s value) result)
(while (string-match
"\\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ \t]+\\|$\\)"
s)
(let ((value (substring s 0 (match-beginning 0))))
(push (funcall prepare-value value) result))
(push (intern (match-string 1 s)) result)
(setq s (substring s (match-end 0))))
;; Ignore any string before first property with `cdr'.
(cdr (nreverse (cons (funcall prepare-value s) result))))))))
attributes))
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: Dynamic keybindings in the manual
@ 2022-09-25 17:52 3% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-25 17:52 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
Hi, Timothy,
Timothy writes:
> This prompted me to take a look at `orgcard.tex' and I was surprised to discover
> that it’s TeX TeX, not even LaTeX, and it has hard-coded keybindings.
Wow, it's in plainTeX... I've tried cleaning that document and removing
most of the code, as it's unnecessary. I've left just the sections in a
new LaTeX document, and redefined the \key command like so:
\newcommand\key[2]{%
#1 \quad%
\{\{\{kbd(#2)\}\}\}\par}
so that a line like this:
\key{rotate current subtree between states}{TAB}
produce in the PDF this, literally:
rotate current subtree between states {{{kbd(TAB)}}}
I don't know if this could help to copy the text from the PDF, create an
Org document and then manipulate those macros. In case this helps, I'm
attaching the new tex document here.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: orgcard-clean.tex --]
[-- Type: application/x-tex, Size: 14555 bytes --]
% -*- coding: utf-8 -*-
\documentclass{article}
\parindent=0em
\newcommand\key[2]{%
#1 \quad %
\{\{\{kbd(#2)\}\}\}\par}
\begin{document}
\section{Getting Started}
\key{To read the on-line documentation try}{M-x org-info}
\section{Visibility Cycling}
\key{rotate current subtree between states}{TAB}
\key{rotate entire buffer between states}{S-TAB}
\key{restore property-dependent startup visibility}{C-u C-u TAB}
\key{show the whole file, including drawers}{C-u C-u C-u TAB}
\key{reveal context around point}{C-c C-r}
\key{toggle indented view}{M-x org-indent-mode}
\section{Motion}
\key{next/previous heading}{C-c C-n/p}
\key{next/previous heading, same level}{C-c C-f/b}
\key{backward to higher level heading}{C-c C-u}
\key{jump to another place in document}{C-c C-j}
\key{previous/next plain list item}{S-UP/DOWN}
\section{Structure Editing}
\key{insert new heading/item at current level}{M-RET}
\key{insert new heading after subtree}{C-RET}
\key{insert new TODO entry/checkbox item}{M-S-RET}
\key{insert TODO entry/ckbx after subtree}{C-S-RET}
\key{turn (head)line into item, cycle item type}{C-c -}
\key{turn item/line into headline}{C-c *}
\key{promote/demote heading}{M-LEFT/RIGHT}
\key{promote/demote current subtree}{M-S-LEFT/RIGHT}
\key{move subtree/list item up/down}{M-UP/DOWN}
\key{move the line at point up/down}{M-S-UP/DOWN}
\key{sort subtree/region/plain-list}{C-c \^{}}
\key{clone a subtree}{C-c C-x c}
\key{copy visible parts of the region}{C-c C-x v}
\key{kill/copy subtree}{C-c C-x C-w/M-w}
\key{yank subtree}{C-c C-x C-y or C-y}
\key{narrow buffer to subtree / widen}{C-x n s/w}
\section{Capture - Refile - Archiving}
\key{capture a new item (C-u C-u = goto last)}{C-c c}
\key{refile subtree (C-u C-u = goto last)}{C-c C-w}
\key{archive subtree using the default command}{C-c C-x C-a}
\key{move subtree to archive file}{C-c C-x C-s}
\key{toggle ARCHIVE tag / to ARCHIVE sibling}{C-c C-x a/A}
\key{force cycling of an ARCHIVEd tree}{C-TAB}
\section{Filtering and Sparse Trees}
\key{construct a sparse tree by various criteria}{C-c /}
\key{view TODO's in sparse tree}{C-c / t/T}
\key{global TODO list in agenda mode}{C-c a t}
\section{Tables}
{\bf Creating a table}
%\key{insert a new Org-mode table}{M-x org-table-create}
\key{just start typing, e.g.}{|Name|Phone|Age RET |- TAB}
\key{convert region to table}{C-c |}
\key{... separator at least 3 spaces}{C-3 C-c |}
{\bf Commands available inside tables}
The following commands work when the cursor is {\it inside a table}.
Outside of tables, the same keys may have other functionality.
{\bf Re-aligning and field motion}
\key{re-align the table without moving the cursor}{C-c C-c}
\key{re-align the table, move to next field}{TAB}
\key{move to previous field}{S-TAB}
\key{re-align the table, move to next row}{RET}
\key{move to beginning/end of field}{M-a/e}
{\bf Row and column editing}
\key{move the current column left}{M-LEFT/RIGHT}
\key{kill the current column}{M-S-LEFT}
\key{insert new column to left of cursor position}{M-S-RIGHT}
\key{move the current row up/down}{M-UP/DOWN}
\key{kill the current row or horizontal line}{M-S-UP}
\key{insert new row above the current row}{M-S-DOWN}
\key{insert hline below (\texttt{C-u} : above) current row}{C-c -}
\key{insert hline and move to line below it}{C-c RET}
\key{sort lines in region}{C-c \^{}}
{\bf Regions}
\key{cut/copy/paste rectangular region}{C-c C-x C-w/M-w/C-y}
%\key{copy rectangular region}{C-c C-x M-w}
%\key{paste rectangular region}{C-c C-x C-y}
{\bf Miscellaneous}
\key{to limit column width to \texttt{N} characters, use}{...| <N> |...}
\key{edit the current field in a separate window}{C-c `}
\key{make current field fully visible}{C-u TAB}
\key{export as tab-separated file}{M-x org-table-export}
\key{import tab-separated file}{M-x org-table-import}
\key{sum numbers in current column/rectangle}{C-c +}
{\bf Tables created with the \texttt{table.el} package}
\key{insert a new \texttt{table.el} table}{C-c ~}
\key{recognize existing table.el table}{C-c C-c}
\key{convert table (Org-mode $\leftrightarrow$ table.el)}{C-c ~}
{\bf Spreadsheet}
Formulas typed in field are executed by \texttt{TAB},
\texttt{RET} and \texttt{C-c C-c}. \texttt{=} introduces a column
formula, \texttt{:=} a field formula.
\key{Example: Add Col1 and Col2}{|=\$1+\$2 |}
\key{... with printf format specification}{|=\$1+\$2;\%.2f|}
\key{... with constants from constants.el}{|=\$1/\$c/\$cm |}
\key{sum from 2nd to 3rd hline}{|:=vsum(@II..@III)|}
\key{apply current column formula}{| = |}
\key{set and eval column formula}{C-c =}
\key{set and eval field formula}{C-u C-c =}
\key{re-apply all stored equations to current line}{C-c *}
\key{re-apply all stored equations to entire table}{C-u C-c *}
\key{iterate table to stability}{C-u C-u C-c *}
\key{rotate calculation mark through \# * ! \^ \_ \$}{C-\#}
\key{show line, column, formula reference}{C-c ?}
\key{toggle grid / debugger}{C-c \}/\{}
{\it Formula Editor}
\key{edit formulas in separate buffer}{C-c '}
\key{exit and install new formulas}{C-c C-c}
\key{exit, install, and apply new formulas}{C-u C-c C-c}
\key{abort}{C-c C-q}
\key{toggle reference style}{C-c C-r}
\key{pretty-print Lisp formula}{TAB}
\key{complete Lisp symbol}{M-TAB}
\key{shift reference point}{S-cursor}
\key{shift test line for column references}{M-up/down}
\key{scroll the window showing the table}{M-S-up/down}
\key{toggle table coordinate grid}{C-c \}}
\section{Links}
\key{globally store link to the current location}{C-c l}
\key{insert a link (TAB completes stored links)}{C-c C-l}
\key{insert file link with file name completion}{C-u C-c C-l}
\key{edit (also hidden part of) link at point}{C-c C-l}
\key{open file links in emacs}{C-c C-o}
\key{...force open in emacs/other window}{C-u C-c C-o}
\key{open link at point}{mouse-1/2}
\key{...force open in emacs/other window}{mouse-3}
\key{record a position in mark ring}{C-c \%}
\key{jump back to last followed link(s)}{C-c \&}
\key{find next link}{C-c C-x C-n}
\key{find previous link}{C-c C-x C-p}
\key{edit code snippet of file at point}{C-c '}
\key{toggle inline display of linked images}{C-c C-x C-v}
\section{Working with Code (Babel)}
\key{execute code block at point}{C-c C-c}
\key{open results of code block at point}{C-c C-o}
\key{check code block at point for errors}{C-c C-v c}
\key{insert a header argument with completion}{C-c C-v j}
\key{view expanded body of code block at point}{C-c C-v v}
\key{view information about code block at point}{C-c C-v I}
\key{go to named code block}{C-c C-v g}
\key{go to named result}{C-c C-v r}
\key{go to the head of the current code block}{C-c C-v u}
\key{go to the next code block}{C-c C-v n}
\key{go to the previous code block}{C-c C-v p}
\key{demarcate a code block}{C-c C-v d}
\key{execute next key sequence in code edit buffer}{C-c C-v x}
\key{execute all code blocks in current buffer}{C-c C-v b}
\key{execute all code blocks in current subtree}{C-c C-v s}
\key{tangle code blocks in current file}{C-c C-v t}
\key{tangle code blocks in supplied file}{C-c C-v f}
\key{ingest all code blocks in supplied file into the Library of Babel}{C-c C-v i}
\key{switch to the session of the current code block}{C-c C-v z}
\key{load the current code block into a session}{C-c C-v l}
\key{view sha1 hash of the current code block}{C-c C-v a}
\section{Completion and Template Insertion}
In-buffer completion completes TODO keywords at headline start, TeX
macros after ``{\tt \\}'', option keywords after ``{\tt \#-}'', TAGS
after ``{\tt :}'', and dictionary words elsewhere.
\key{complete word at point}{M-TAB}
\key{structure template (insert or wrap region)}{C-c C-,}
\section{TODO Items and Checkboxes}
\key{rotate the state of the current item}{C-c C-t}
\key{select next/previous state}{\quad\quad S-LEFT/RIGHT}
\key{select next/previous set}{\quad\quad\quad C-S-LEFT/RIGHT}
\key{toggle ORDERED property}{C-c C-x o}
\key{view TODO items in a sparse tree}{C-c / t}
\key{view 3rd TODO keyword's sparse tree}{C-3 C-c / t}
\key{set the priority of the current item}{C-c , [ABC]}
\key{remove priority cookie from current item}{C-c , SPC}
\key{raise/lower priority of current item}{S-UP/DOWN}
\key{insert new checkbox item in plain list}{M-S-RET}
\key{toggle checkbox(es) in region/entry/at point}{C-c C-x C-b}
\key{toggle checkbox at point}{C-c C-c}
%\key{checkbox statistics cookies: insert {\tt [/]} or {\tt [\%]}}{}
\key{update checkbox statistics (\texttt{C-u} : whole file)}{C-c \#}
\section{Tags}
\key{set tags for current heading}{C-c C-q}
\key{realign tags in all headings}{C-u C-c C-q}
\key{create sparse tree with matching tags}{C-c}
\key{globally (agenda) match tags at cursor}{C-c C-o}
\section{Properties and Column View}
\key{set property/effort}{C-c C-x p/e}
\key{special commands in property lines}{C-c C-c}
\key{next/previous allowed value}{S-LEFT/RIGHT}
\key{turn on column view}{C-c C-x C-c}
\key{capture columns view in dynamic block}{C-c C-x x}
\key{quit column view}{q}
\key{show full value}{v}
\key{edit value}{e}
\key{next/previous allowed value}{n/p or S-LEFT/RIGHT}
\key{edit allowed values list}{a}
\key{make column wider/narrower}{> / <}
\key{move column left/right}{M-LEFT/RIGHT}
\key{add new column}{M-S-RIGHT}
\key{Delete current column}{M-S-LEFT}
\section{Timestamps}
\key{prompt for date and insert timestamp}{C-c .}
\key{like \texttt{C-c .} but insert date and time format}{C-u C-c .}
\key{like \texttt{C-c .} but make stamp inactive}{C-c !} % FIXME
\key{insert DEADLINE timestamp}{C-c C-d}
\key{insert SCHEDULED timestamp}{C-c C-s}
\key{create sparse tree with all deadlines due}{C-c / d}
\key{the time between 2 dates in a time range}{C-c C-y}
\key{change timestamp at cursor $\pm 1$ day}{\quad\quad\quad\quad S-RIGHT/LEFT}
\key{change year/month/day at cursor by $\pm 1$}{S-UP/DOWN}
\key{access the calendar for the current date}{C-c >}
\key{insert timestamp matching date in calendar}{C-c <}
\key{access agenda for current date}{C-c C-o}
\key{select date while prompted}{mouse-1/RET}
%\key{... select date in calendar}{mouse-1/RET}
%\key{... scroll calendar back/forward one month}{< / >}
%\key{... forward/backward one day}{S-LEFT/RIGHT}
%\key{... forward/backward one week}{S-UP/DOWN}
%\key{... forward/backward one month}{M-S-LEFT/RIGHT}
\key{toggle custom format display for dates/times}{C-c C-x C-t}
{\bf Clocking time}
\key{start clock on current item}{C-c C-x C-i}
\key{stop/cancel clock on current item}{C-c C-x C-o/x}
\key{display total subtree times}{C-c C-x C-d}
\key{remove displayed times}{C-c C-c}
\key{insert/update table with clock report}{C-c C-x C-x}
\section{Agenda Views}
\key{add/move current file to front of agenda}{C-c [}
\key{remove current file from your agenda}{C-c ]}
\key{cycle through agenda file list}{C-'}
\key{set/remove restriction lock}{C-c C-x </>}
\key{compile agenda for the current week}{C-c a a}
\key{compile global TODO list}{C-c a t}
\key{compile TODO list for specific keyword}{C-c a T}
\key{match tags, TODO kwds, properties}{C-c a m}
\key{match only in TODO entries}{C-c a M}
\key{find stuck projects}{C-c a \#}
\key{configure custom commands}{C-c a C}
%\key{configure stuck projects}{C-c a !}
\key{agenda for date at cursor}{C-c C-o}
{\bf Commands available in an agenda buffer}
{\bf View Org file}
\key{show original location of item}{SPC/mouse-3}
%\key{... also available with}{mouse-3}
\key{show and recenter window}{L}
\key{goto original location in other window}{TAB/mouse-2}
%\key{... also available with}{mouse-2}
\key{goto original location, delete other windows}{RET}
\key{show subtree in indirect buffer, ded.\ frame}{C-c C-x b}
\key{toggle follow-mode}{F}
{\bf Change display}
\key{delete other windows}{o}
\key{view mode dispatcher}{v}
\key{switch to day/week/month/year/def view}{d w vm vy vSP}
\key{toggle diary entries / time grid / habits}{D / G / K}
\key{toggle entry text / clock report}{E / R}
\key{toggle display of logbook entries}{l / v l/L/c}
\key{toggle inclusion of archived trees/files}{v a/A}
\key{refresh agenda buffer with any changes}{r / g}
\key{filter with respect to a tag}{/}
\key{save all org-mode buffers}{s}
\key{display next/previous day,week,...}{f / b}
\key{goto today / some date (prompt)}{. / j}
{\bf Remote editing}
\key{digit argument}{0-9}
\key{change state of current TODO item}{t}
\key{kill item and source}{C-k}
\key{archive default}{\$ / a}
\key{refile the subtree}{C-c C-w}
\key{set/show tags of current headline}{: / T}
\key{set effort property (prefix=nth)}{e}
\key{set / compute priority of current item}{, / P}
\key{raise/lower priority of current item}{S-UP/DOWN}
\key{run an attachment command}{C-c C-a}
\key{schedule/set deadline for this item}{C-c C-s/d}
\key{change timestamp one day earlier/later}{S-LEFT/RIGHT}
\key{change timestamp to today}{>}
\key{insert new entry into diary}{i}
\key{start/stop/cancel the clock on current item}{I / O / X}
\key{jump to running clock entry}{J}
\key{mark / unmark / execute bulk action}{m / u / B}
{\bf Misc}
\key{follow one or offer all links in current entry}{C-c C-o}
{\bf Calendar commands}
\key{find agenda cursor date in calendar}{c}
\key{compute agenda for calendar cursor date}{c}
\key{show phases of the moon}{M}
\key{show sunrise/sunset times}{S}
\key{show holidays}{H}
\key{convert date to other calendars}{C}
{\bf Quit and Exit}
\key{quit agenda, remove agenda buffer}{q}
\key{exit agenda, remove all agenda buffers}{x}
\section{LaTeX and cdlatex-mode}
\key{preview LaTeX fragment}{C-c C-x C-l}
\key{expand abbreviation (cdlatex-mode)}{TAB}
\key{insert/modify math symbol (cdlatex-mode)}{` / '}
\key{insert citation using RefTeX}{C-c C-x [}
\section{Exporting and Publishing}
Exporting creates files with extensions {\it .txt\/} and {\it .html\/}
in the current directory. Publishing puts the resulting file into
some other place.
\key{export/publish dispatcher}{C-c C-e}
\key{toggle asynchronous export}{C-c C-e C-a}
\key{toggle body/visible only export}{C-c C-e C-b/v}
\key{toggle subtree export}{C-c C-e C-s}
\key{insert template of export options}{C-c C-e \#}
\key{toggle fixed width for entry or region}{C-c :}
\key{toggle pretty display of scripts, entities}{C-c C-x {\tt\char`\\}}
Lines starting with \texttt{\#} and subtrees starting with COMMENT are
never exported.
\key{toggle COMMENT keyword on entry}{C-c ;}
\section{Dynamic Blocks}
\key{update dynamic block at point}{C-c C-x C-u}
\key{update all dynamic blocks}{C-u C-c C-x C-u}
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
^ permalink raw reply [relevance 3%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-25 12:06 10% ` Juan Manuel Macías
@ 2022-09-26 3:56 5% ` Ihor Radchenko
2022-09-26 7:47 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-09-26 3:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Going back to the earlier :ATTR_BACKEND: issue as a property for
> headings, I've been doing some testing and scribbled down a possible
> function[1] whose code is almost entirely stolen from
> org-export-read-attribute, with some modifications. Evaluated at the
> headline, it returns the value of the ATTR_BACKEND property as a plist.
> And then that plist could be easily manipulated on each backend to
> format export_template conveniently. For example:
>
> * headline
> :PROPERTIES:
> :ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
> :ATTR_LaTeX+: blah blah blah
> :END:
>
> ==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")
>
> I don't know if that would be the way to go...
What I have in mind is to modify `org-export-read-attribute' directly.
Then, we can call `org-export-read-attribute' in `org-export-data';
resolve the refs in the template (re-use code from
`org-babel-ref-resolve' and `org-babel-parse-multiple-vars'); do normal
export and pass it to the template. Before running the normal export, we
strip :export_template from the INFO to avoid issues with ox-html which
puts every single attr into the generated html.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
2022-09-26 3:56 5% ` Ihor Radchenko
@ 2022-09-26 7:47 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-26 7:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> What I have in mind is to modify `org-export-read-attribute' directly.
> Then, we can call `org-export-read-attribute' in `org-export-data';
> resolve the refs in the template (re-use code from
> `org-babel-ref-resolve' and `org-babel-parse-multiple-vars'); do normal
> export and pass it to the template. Before running the normal export, we
> strip :export_template from the INFO to avoid issues with ox-html which
> puts every single attr into the generated html.
OK, it makes sense. I can try something on this idea, although I'm
afraid not in the short term. If someone else wants to do it I have no
problem.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Extract toc from org file
@ 2022-09-26 15:39 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-09-26 15:39 UTC (permalink / raw)
To: reza; +Cc: orgmode
reza writes:
> Is there a way to extract a toc from an org file e.g:
>
> #+INCLUDE: myfile.org :toc only
>
> I want to assemble the toc's from several files into one file and there
> seems to be no easy way to do this.
Maybe the org-make-toc package can help you with what you're looking for:
https://github.com/alphapapa/org-make-toc
You can choose a heading on every document to contain a TOC. And then link each heading via org-transclusion:
https://github.com/nobiot/org-transclusion
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Create in Org a bilingual book with facing pages
@ 2022-09-27 9:09 8% Juan Manuel Macías
2022-09-27 12:29 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-09-27 9:09 UTC (permalink / raw)
To: orgmode
Hi all,
TL; DR:
The bilingual critical edition (ancient Greek/Spanish) of the letters of
Demosthenes and Aeschines has recently been published in Spain, a book
whose production and typesetting I have taken charge of, using Org and
Org-publish. Although I already have a long experience typesetting
bilingual editions of a certain complexity, especially for philological
use, I had never done it until now by centralizing the entire process in
Org-Mode. I have to say that it has been a very interesting experience,
so I leave here below a brief description of the process and some tips,
in case they can be useful to someone who wants to prepare from Org
bilingual texts with facing pages and certain complexity.
BTW, Here’s a sample of two pages from the book:
<https://i.imgur.com/XUOGEnf.png>
Long version:
First of all, for this kind of work you have to take into account an
inherent limitation of TeX: the compilation process in TeX is a
single-threaded process. That is, in TeX you cannot compile different
parts of a document, with different configurations (= different
preambles), at the same time. For example, you cannot have one
configuration for odd pages and another for even pages (original and
translation) and compile them in parallel and asynchronously. In Adobe
InDesign-style DTP programs you can load multiple page threads in
parallel, but these programs don’t have the typographic refinement of
TeX. And besides, I never use proprietary software ;-).
Therefore, to create a bilingual edition with facing pages, and for this
particular type of book where the odd pages (the text in Greek) is a
critical edition with a strong critical apparatus
(https://en.wikipedia.org/wiki/Critical_apparatus), it is necessary to
compile two separate documents and then synchronize them. The good news:
I have found that, thanks to Org, the process is much more streamlined
and controlled.
On the other hand, since in this book the content of the odd and even
pages is variable, the synchronization has been done per page, so that
the reader always obtains the same content on the odd and even page when
facing the open book. For the Greek document I used the reledmac LaTeX
package, which is the most mature LaTeX package for philological
critical editions, but I used it through my org-critical-edition package
(<https://gitlab.com/maciaschain/org-critical-edition>).
Once both PDFs are obtained and synchronized, they are loaded into the
master Org document using the pdfpages LaTeX package. Since it was
necessary to introduce in certain pages some commands specific to each
page, such as page styles, index entries or labels for references, and
to avoid having to load the pages one by one with pdfpages commands, I
wrote a function that obtains the number of pages of the synchronized
PDF (via mutool) and it does all that work. The function has three
arguments: the path to the synced PDF, the general page command, and a
list of page numbers with particular commands (these last two arguments
are optional). An example of use would be:
┌────
│ (inserta-pdfpages-bi "resultado.pdf" "\\thispagestyle{plain}" '((2 "\\label{some-label}")))
└────
The function is evaluated in the master document within a source block:
<https://i.imgur.com/yps6xRA.png>
To compile the two PDFs separately and get the PDF in sync, I also do it
from Org using a shell source block. So I have all PDFs always
synchronized up to date. The synchronized PDF is obtained with pdftk:
<https://i.imgur.com/qbSg2po.png>
The rest of the book, introduction, indices, etc. it is normally done
via Org publish. And the final compilation (the master document that
includes all sub-documents) is done asynchronously using latexmk.
And that’s it. The next challenge for this fall is going to be a
trilingual edition of the New Testament (Greek, Latin, Spanish). My idea
is to try to adapt to Org the use of the LaTeX package flowfram (an
attempt to create dynamic indesign-style text boxes in LaTeX, but
---because of TeX's limitations--- they would not be asynchronous
boxes). Then, each text in a language would go inside an org block.
We'll see how it turns out :-)
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* Re: Create in Org a bilingual book with facing pages
2022-09-27 9:09 8% Create in Org a bilingual book with facing pages Juan Manuel Macías
@ 2022-09-27 12:29 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-09-27 12:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The bilingual critical edition (ancient Greek/Spanish) of the letters of
> Demosthenes and Aeschines has recently been published in Spain, a book
> whose production and typesetting I have taken charge of, using Org and
> Org-publish. Although I already have a long experience typesetting
> bilingual editions of a certain complexity, especially for philological
> use, I had never done it until now by centralizing the entire process in
> Org-Mode. I have to say that it has been a very interesting experience,
> so I leave here below a brief description of the process and some tips,
> in case they can be useful to someone who wants to prepare from Org
> bilingual texts with facing pages and certain complexity.
>
> BTW, Here’s a sample of two pages from the book:
>
> <https://i.imgur.com/XUOGEnf.png>
Thanks for sharing!
This post appears to be a nice fit for
https://orgmode.org/worg/org-blog-articles.html (except non-permanent
imgur links). Do you have an Org version? Or maybe an actual blog post?
> To compile the two PDFs separately and get the PDF in sync, I also do it
> from Org using a shell source block. So I have all PDFs always
> synchronized up to date. The synchronized PDF is obtained with pdftk:
>
> <https://i.imgur.com/qbSg2po.png>
I notice two things here:
1. \clearpage command, which reminds me about
https://orgmode.org/list/87mtamjrft.fsf@localhost
May it be useful to have page break syntax element in Org?
2. You had to use direct LaTeX for caption. Can we do something to make
the #+caption keywords more useful?
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
^ permalink raw reply [relevance 5%]
* Re: Org and Hyperbole
2022-06-20 23:37 0% ` Tim Cross
@ 2022-09-27 13:06 0% ` Jean Louis
0 siblings, 0 replies; 200+ results
From: Jean Louis @ 2022-09-27 13:06 UTC (permalink / raw)
To: Tim Cross; +Cc: emacs-orgmode
* Tim Cross <theophilusx@gmail.com> [2022-06-21 02:43]:
>
> 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.
I somehow cannot relate to it, Hyperbole and Org mode are quite
different things. I have Hyperbole all the time here running, no
matter if I use Org mode or what other lightweight markup language.
Let's say there is region marked, I use sometimes Hyperbole to search
Internet for marked term. That is not related and not comparable to
Org mode which is meant to handle markup in a text file.
Hyperbole is what it says, extravagant exaggeration. It is meta to
Org.
I have specific window setup with different buffers and I want to
remember it, then I use Hyperbole {C-h h w n a} to remember it.
One can understand it by running demo {C-h h d d}, it is not related
to Org mode, it is to be used in Emacs over anything, regardless of modes.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [relevance 0%]
Results 801-1000 of ~1600 next (newer) | prev (older) | 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 4% ` 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 ` Ihor Radchenko
2022-05-30 15:36 ` Juan Manuel Macías
2022-05-31 5:06 ` Ihor Radchenko
2022-05-31 11:00 ` Juan Manuel Macías
2022-07-04 11:44 6% ` Ihor Radchenko
2022-05-23 14:30 About 'inline special blocks' Juan Manuel Macías
2022-05-23 15:20 ` Kaushal Modi
2022-06-19 12:47 ` Juan Manuel Macías
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-06-10 18:28 [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments' Juan Manuel Macías
2022-06-11 5:39 ` Ihor Radchenko
2022-06-11 11:20 ` Juan Manuel Macías
2022-06-14 3:58 ` Ihor Radchenko
2022-06-14 11:11 ` Juan Manuel Macías
2022-06-14 11:55 ` Ihor Radchenko
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-07-26 5:35 4% ` Ihor Radchenko
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-09-27 13:06 0% ` Jean Louis
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-26 11:58 6% ` Ihor Radchenko
2022-07-26 16:19 9% ` Juan Manuel Macías
2022-07-28 12:36 6% ` Ihor Radchenko
2022-07-23 14:53 10% ` Juan Manuel Macías
2022-07-25 19:02 How to force markup without spaces K
2022-07-26 1:26 ` Ihor Radchenko
2022-07-26 2:23 ` Max Nikulin
2022-07-26 4:26 ` K K
2022-07-26 12:59 ` [PATCH] org-export: Remove zero-width space escapes during export Ihor Radchenko
2022-07-27 3:30 5% ` Max Nikulin
2022-07-28 13:17 ` [PATCH] Add new entity \-- serving as markup separator/escape symbol Ihor Radchenko
2022-07-29 0:32 8% ` Juan Manuel Macías
2022-07-31 1:00 3% [PATCH] ox-latex.el: `org-latex-language-alist' improved Juan Manuel Macías
2022-08-03 11:23 5% ` Ihor Radchenko
2022-08-04 10:04 3% ` Juan Manuel Macías
2022-08-04 12:16 7% ` Max Nikulin
2022-08-05 17:14 9% ` Juan Manuel Macías
2022-08-06 7:13 5% ` Ihor Radchenko
2022-08-06 21:32 13% ` Juan Manuel Macías
2022-08-07 12:53 13% org-verse-num: display verse numbers within a verse block Juan Manuel Macías
2022-08-07 13:39 0% ` Colin Baxter
2022-08-07 14:22 13% ` Juan Manuel Macías
2022-08-07 14:44 6% ` Jeremie Juste
2022-08-07 15:16 6% ` Ihor Radchenko
2022-08-08 14:39 9% [PATCH] Documentation and NEWS for ` org-latex-language-alist' Juan Manuel Macías
2022-08-09 11:43 5% ` Ihor Radchenko
2022-08-16 14:16 8% ` Juan Manuel Macías
2022-08-18 15:39 6% ` Max Nikulin
2022-08-20 5:51 5% ` Ihor Radchenko
2022-08-20 7:17 ` http: links in the manual Max Nikulin
2022-08-21 9:55 9% ` Juan Manuel Macías
2022-08-22 2:46 6% ` Auto-checking dead links in the manual (was: http: links in the manual) Ihor Radchenko
2022-08-22 15:29 0% ` Max Nikulin
2022-08-09 15:39 6% ` [PATCH] Documentation and NEWS for ` org-latex-language-alist' Max Nikulin
2022-08-16 15:19 9% [off topic] List all non-latin characters in a buffer Juan Manuel Macías
2022-08-19 14:50 1% ` Uwe Brauer
2022-09-09 14:15 6% ` Robert Pluim
2022-08-28 15:37 Have all the tags of a heading, with a tag hierarchy Cletip Cletip
2022-08-28 16:21 13% ` Juan Manuel Macías
2022-08-28 16:34 5% ` Cletip Cletip
2022-09-06 12:25 Agenda 'Org view' (org-projection?) Eduardo Suarez
2022-09-06 14:21 13% ` Juan Manuel Macías
2022-09-13 15:54 error org export to pdf when latex letter class has been added to org-latex-classes M. Pger
2022-09-13 17:55 13% ` Juan Manuel Macías
2022-09-13 19:59 5% ` M. Pger
2022-09-13 20:15 10% ` Juan Manuel Macías
2022-09-18 12:27 9% [Patch] Pre-/postpend arbitrary LaTeX code to a section Juan Manuel Macías
2022-09-18 16:14 6% ` Max Nikulin
2022-09-19 10:04 5% ` Fraga, Eric
2022-09-20 13:26 5% ` Ihor Radchenko
2022-09-20 17:18 10% ` Juan Manuel Macías
2022-09-21 8:55 5% ` Ihor Radchenko
2022-09-21 13:55 ` Daniel Fleischer
2022-09-21 14:51 13% ` Juan Manuel Macías
2022-09-21 14:43 10% ` Juan Manuel Macías
2022-09-22 14:08 5% ` Ihor Radchenko
2022-09-24 14:50 11% ` Juan Manuel Macías
2022-09-25 3:33 6% ` Ihor Radchenko
2022-09-25 12:06 10% ` Juan Manuel Macías
2022-09-26 3:56 5% ` Ihor Radchenko
2022-09-26 7:47 13% ` Juan Manuel Macías
2022-09-19 8:59 Re " Pedro Andres Aranda Gutierrez
2022-09-20 13:19 ` Ihor Radchenko
2022-09-20 19:35 12% ` Juan Manuel Macías
2022-09-25 15:30 Dynamic keybindings in the manual Timothy
2022-09-25 17:52 3% ` Juan Manuel Macías
[not found] <100cb12a-b3f1-739a-84f1-847f5e86a8bc@housseini.me>
2022-09-26 11:53 ` Extract toc from org file reza
2022-09-26 15:39 13% ` Juan Manuel Macías
2022-09-27 9:09 8% Create in Org a bilingual book with facing pages Juan Manuel Macías
2022-09-27 12:29 5% ` Ihor Radchenko
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).