Re: sorting plain list while making - equal spc [was Re: [O] About org-sort -> org-sort-list with custom sort function]
miraculously i made a buggy solution for myself only. it might sort wrong if you have [-] in rest of line. so fwiw. in org-list.el. for anybody who is searching for same thing: ((= dcst ?x) (or (and (stringp (match-string 1)) (replace-regexp-in-string "\\[-\\]" "[ ]" ;; " - [X] whatever") ;; " - [ ] whatever") ;; " - [-] whatever") (match-string 1))) On 7/1/22, Samuel Wales wrote: > i am confused by the custom sorting function for plain > lists. are there examples? [note: still on maint.] > > i want to ignore [-] for sorting by checked. it can be equal to [ ]. > i don't need it to be custom but that seems available. > > a rationale and possible interesting solutions are below, but i'm ok > with anything. current x/X is always flawed for me. > > > rationale: > > suppose you have a long list like > > - [ ] hello > + [ ] hi > + [ ] greetings > ... [long list] > > suppose you mark greetings as [X] with c-c c-c, at least with my > settings, hello will become [-] to indicate "partly X". > > suppose hello is still high priority. but you don't notice it's there > because you use very large fonts and it is not on the same page. it's > in the middle. you keep your list in priority sequence. you have at > the top something like > > - [ ] bonjour > - [ ] some kind of greeting > ... > > and most are spc like that and - is rare. suppose you mark bonjour X > with c-c c-c. now it is in your face and you want to move it down. > so you sort by checked. now it is out of your face. but you didn't > notice that your hello moved down also. > > this isn't particularly a bug; it is just that - is part of sorting > and it is hardcoded to be below SPC [i think]. > > so hello gets moved down a whoole lot. its place in the > list is gone. you aren't even looking at the bottom of hte list > because it is so long. it is as if hello has disappeared. > > and this is because you marked a sub-item as X. and then sorted the > top level by checked. and didn't notice. > > so i'm thinking this is a feature that could cause unexpected results. > [because it did that to me. existence proof.] > > and there's nothing really wrong with existing semantics, but i'd want > - to be ignored in sorting, because of the above. > > i can think of some possible solutions. for example > > - have something like an x X command that makes - eqal to spc or > custom variable for sorting with ability to specify '(? ?x) thus > ignoring ?-. > - have a command that moves all X to a sibling header so you don't > need sorting to get X out of your face > - have the possibility of this all working on sublists too > > > [i kinda want all there are more ideas. please do not shoot me > or say i am destroying the spirit and letter of org and the milky way > galaxy. these are just brainstorms. possibilities to possibly > consider, not analyzed to perfection.] > > thanks! > > > On 5/8/17, Kyle Meyer wrote: >> Kyle Meyer writes: >> >>> Nicolas Goaziou writes: >>> The we may not need `call-interactively' at all. WDYT? >>> >>> Yeah, I agree that there's no need for call-interactively here because >>> the interactive forms of org-table-sort-lines, org-sort-list, >>> org-sort-entries are covered by org-sort's. >>> >>> Switched call-interactively to funcall in c1addc825. >> >> Ehh, I should have looked more closely at org-table-sort-lines. Unlike >> org-sort-entries and org-sort-list, it uses called-interactively-p to >> determine whether it should prompt the user. I've put the >> org-call-with-arg back, at least for now. >> >> -- >> Kyle >> >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
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.
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Juan Manuel Macías 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
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
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
change headings to list but have a nested numeration?
Hi I start with this part * The pseudo code ** The actual Matlab code ** Initialisation *** Details Which is converted via org-ctrl-c-minus to * The pseudo code - The actual Matlab code - Initialisation - Details However here the structure depends on the indentation and that might not be that rebust would it be possible to convert to such a structure: * The pseudo code 1. The actual Matlab code 2. Initialisation 1.1 Details That looks more stable to me. Thanks and regards Uwe Brauer -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Max Nikulin writes:
> LuaTeX uses Latin Modern
> and it is not nearly Unicode
Maxim, please look at this screenshots carefully:
https://i.imgur.com/uMfheCL.png
https://i.imgur.com/WwGybBA.png
https://i.imgur.com/hpreFNQ.png
Frankly, I don't know what Latin Modern you're referring to, and what
you mean by saying that "it is not nearly unicode".
The default LM font in LuaLaTeX and XeTeX is an otf and Unicode font.
Which is not to say that it has all the glyphs to represent all possible
characters. Because I guess you know the difference between glyph and
character...
Perhaps a font with a broader coverage could have been chosen by default
for LuaLaTeX, but here the (LaTeX) historical reasons have prevailed.
It's probably not the happiest choice, but LM is still a Unicode font
nonetheless.
And I insist: what you say about it being necessary to completely
configure everything related to fonts in LuaTeX is not correct. It
depends on the use case, and you can go (as I said in my previous email)
from the simplest to the most complex configuration.
On the other hand: I think that in the case of LuaTeX and XeTeX the
choice and configuration of fonts should be on the LaTeX side and not
Org's. Implementing that in Org would lead to a bunch of variables to
cater for all possible cases. It might suffice to give some examples of
basic use (like the ones I have put in the previous mail, and that will
be enough for most users) and recommend free license fonts for different
languages[1]. Maybe starting here:
https://tug.org/FontCatalogue/opentypefonts.html
But if the user needs more fine-tuning of fonts and languages, he/she
will undoubtedly have to read the fontspec and babel manuals, depending
on his needs, which can be very different from one user to another.
[1] Although I see it as unnecessary. Fonts are not recommended when the
output is odt...
> With the following minimal example I got
> blank space instead of non-latin characters.
> \documentclass{article}
> \begin{document}
> Abc — Αλφάβητο — Азбука…
> \end{document}
\documentclass{article}
%
\usepackage{fontspec}
\setmainfont{FreeSerif}
%
\begin{document}
Abc — Αλφάβητο — Азбука…
\end{document}
\usepackage{fontspec}\setmainfont{FreeSerif} is the same as choosing the
font in the libreoffice font menu.
You have to keep in mind that LuaTeX and XeTeX are designed so that it
is the user who decides which fonts to use and so that it's the user who
has the freedom to manage those fonts as he wishes. Okay: they could
have made a series of fallback fonts load by default to cover all
glyphs, for users who don't want to mess with typography. But I think
that this basic example that I have put is quite simple, and gives the
user the freedom to choose his preferred font and not the one imposed by
the system. And, at the end of the day, TeX is essentially a
typographical tool, whether you like it or not. Of course, LaTeX can be
used on autopilot because many scientific publications ask for articles
in LaTeX (with very little room for maneuver on the part of the authors,
since in the end a LaTeXpert will do the typesetting for the
publication). But there are also users who want to create their own book
layout from scratch, and use whatever font they want, in the same way as
when exporting to html from org there are users who like to write their
own css styles. LuaTeX and XeTeX offer the user that freedom, and it can
be done very simply. I have used pdfLaTeX for a long, long time and I
know very well how immensely laborious it was to install new type1
fonts, because I installed quite a few. Now, in LuaTeX any system font
can be used in a simple and fast way, I think it is something that users
should value more.
Re: Org mode export accessibility
Ihor Radchenko writes: What can or cannot be preserved is a function of the export format. MathJax is a wonderful thing and the LaTeX expression embedded in the HTML is the best one can do -- MathML loses semantics -- which is why I always recommend preserving the LaTeX when going to HTML. PDF as a format doesn't have the affordance to preserve the LaTeX and even if you kluged up something --- the tools to extract that out of the PDF would need to be invented. > "T.V Raman" writes: > >> > > 3. For math especially, make sure the TeX/LaTeX is preserved one >> > > way or the other in the export >> > >> > Do you refer to the TeX source? To any specific export format? >> 2. Math: Yes -- I meant the TeX/LaTeX representation of a math >>expression. >>Ihor Radchenko writes: > > For html export we do preserve TeX/LaTeX representation because we use > Mathjax that directly supports such representation. > > However, I am not sure how to preserve the original representation, say, > in LaTeX pdf export. > > Best, > Ihor -- Thanks, --Raman(I Search, I Find, I Misplace, I Research) ?7?4 Id: kg:/m/0285kf1 ?0?8
Re: Mathjax and org-mime-htmlize
Thanks for your reply. This problem is not very important. If I find a solution (I mean how including Mathjax in html emails) I will be back to report it on this list. Thanks for org-mime, it is a very useful tool ! Best whises, Jo. --- https://www.vidal-rosset.net Envoyé avec la messagerie sécurisée Proton Mail. --- Original Message --- Le samedi 9 juillet 2022 à 05:47, Ihor Radchenko a écrit : > Joseph Vidal-Rosset jos...@vidal-rosset.net writes: > > > Is there a way to include Mathjax in html emails produced via M-x > > org-mime-htmlize ? > > > > I would be glad to find a solution to this (small) problem. > > > Note that org-mime is not a part of Org. It is hosted and developed at > https://github.com/org-mime/org-mime > > Searching inside the org-mime repo, I can see > https://github.com/org-mime/org-mime/issues/34 where a user complained > that MathJax simply cannnot be used inside emails and thus it has been > deliberately disabled my org-mime. > > Best, > Ihor
Re: Alternatives to clocking in/out for reporting time
On Sat, Jul 09, 2022 at 12:00:53PM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > > I just want to get the agenda items in a programmatic way so I can > > report on them. > > Can you then formulate what exactly you want to achieve? > Do you want to consider only agenda items? All the timestamps in the > matching items or maybe just some? I typically use agenda for the month with logbook view and inactive timestamps enabled. I'd love to iterate over the list of all timestamps from that view. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
On Sat, Jul 9, 2022 at 2:10 AM wrote: > I take the opportunity to say that I think that the simple > self-contained example > >#+bibliography: references.bib >[cite:@key] >#+print_bibliography: > > should be part of the manual, especially since the > 2021-07-31-citations post does not seem to be referred to in the > manual any more (I have org version 9.5.4). The terseness of this section of the manual is a known problem. I'll try to find time to do a patch to include your suggestions, which make sense. Bruce
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
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.
Re: Taking notes of videos in Emacs
Hi, Gerardo, Gerardo Moro writes: > As for your own package, Juan Manuel, I understand the main purpose is > to take screenshots of movies. Am I correct? > Thanks! Yes, it is a series of homemade hacks (if i called it "package" I would sound too presumptuous lol), just to be able to take screenshots and add them to an org document, along with a timestamp. I wrote it because I use EMMS and not mpv.el, and also I don't need most of the features of org-media-note. If you don't use EMMS and are looking for something more complete that includes screenshots, notes and many more features, then org-media-note is definitely the ideal choice. Best regards, Juan Manuel
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Hi Thomas,
Thomas S. Dye writes:
> Yes, what I called Babel you call org-babel. I don't know if the Lua
> handler of source blocks in Org might be useful for someone interested
> to write Lua extensions to LaTeX.
I'm writing a package for LuaLaTeX in Org[1] using lua code blocks, and
everything works fine. But if you mean to evaluate these blocks from
Org, it wouldn't really make sense because LuaTeX uses its own Lua
interpreter and that's where the code should be evaluated. For example,
in LuaTeX you should use tex.print or tex.sprint to print a result in
LaTeX, instead of 'print'.
A simple example to create a counter using Lua:
\newcommand{\mydefcounter}[2]{{\directlua{#1 = #2}}}
\newcommand{\mycounter}[2]{\directlua{%
function count ()
#1 = #1 + #2
tex.print (#1)
end
count()
}}
\mydefcounter{foo}{0}
\mycounter{foo}{1}
\mycounter{foo}{1}
\mycounter{foo}{1}
You might want to take a look at the chickenize package, which includes
loads of examples and is very instructive.
https://www.ctan.org/pkg/chickenize
[1] btw, I thought I was the only one to write a LaTeX package in Org,
instead of the 'official' LaTeX docstrip suite (doing it in Org is
infinitely more comfortable!), but I've seen that the wallcalendar
package has also taken the unorthodox route, with all source code and
documentation in Org :-):
https://github.com/profound-labs/wallcalendar/blob/master/Makefile
Best regards,
Juan Manuel
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Hi, Maxim,
Max Nikulin writes:
> [...] With LuaTeX you get more convenient OTF and TTF font selection, but
> you you have to pay for the feature. It is necessary to explicitly
> specify all families: normal, typewriter, italics, etc if you need
> Unicode. -
Not necessarily. You can go from the simplest or basic to the most
complex, depending on the user's needs. If the user does not need to
write in non-Latin scripts, and is not particularly interested in fonts
and otf esoteric features, then the otf version of the Computer Modern
font (which LuaTeX uses by default) will suffice, as this font has
coverage for latin, latin-1, latin-extended, etc.
If you need to fine-tune fonts or work with non latin scripts, then it
is necessary to load fontspec. But equally here you can go from the most
basic to the most complex fontspec options and features, depending on
the needs of the user.
For example, if you want to write an article in both Russian (main
language) and English, and want to use the Old Standard font (which has
excellent coverage for Cyrillic), the basics might be:
\usepackage{fontspec}
\usepackage[english,russian]{babel}
\setmainfont{Old Standard}
or, using the Babel style (which requires fontspec in the background):
\babelfont{rm}{Old Standard}
That would be the classic setup. Another example, here with modern Babel
notation: an article in Spanish with the secondary language in ancient
Greek. We want to use Linux Libertine as the main font, and for
Greek Old Standard:
\usepackage[spanish]{babel}
\babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
\babelfont{rm}{Linux Libertine O}
\babelfont[greek]{rm}{Old Standard}
That would be the most basic. And, from there, everything can be made
more complex, according to the needs.
> There is babel LaTeX package. A decade ago polyglossia was
> a replacement of babel for XeTeX and LuaTex, but currently babel is
> recommended for these LaTeX engines as well.
That's correct. Babel is strongly recommended, and development of Babel is
very active.
A few months ago I proposed this patch here to adapt Org to the new
scenario regarding Babel and Polyglossia. It is a first approximation
and I have to review it. But the idea is to unify in a single list
(named `org-latex-language-alist' `org-latex-polyglossia-language-alist'
and `org-latex-babel-language-alist':
https://list.orgmode.org/87sfxiw2jp@posteo.net/
Best regards,
Juan Manuel
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Hi, Tim, thank you for your comments,
Tim Cross writes:
> Juan, I think it would be great to add your post to worg. I'm happy to
> do this, but I think it wold also be good if we could include a basic
> 'setup' i.e. what changes people might need to (or should do to maximise
> benefit) in order to try out luatex. For example, what settings to put
> in org-latex-pdf-process (I'm guessing something like "lualatex
> -interaction nonstopmode -output-directory %o %f") and what (if any)
> packages to add/remove from the org-latex-packages-alist etc (I'm
> guessing that perhaps some font related packages may need tweaking?).
>
> Ideally, what would be good is a very simple recipe for what someone
> should do in order to try out luatex and get the most out of it (or at
> least see potential).
I have no problem with my post being added to worg, but I don't have
much experience in working with worg... Of course, I can prepare
everything you need, if you think it might be useful.
The *only* difference between a minimal document for lualatex and a
minimal document for pdfLaTeX is that for LuaLaTeX it is not necessary
to load the fontenc and inputenc packages. The following mwe
compiles perfectly in LuaLaTeX:
\documentclass{article}
\begin{document}
Hello world!
á é í ó ú ñ à è ì ò ù
\end{document}
LuaTeX defaults to an otf version of the Computer Modern font, so any
user who isn't interested in fonts and writing in non-Latin languages,
but wants to work in a real Unicode environment, won't need to fine-tune
fonts, nor load any special package. The rest is exactly the same as any
document for pdfLaTeX.
If in the Org document is added:
#+LATEX_COMPILER: lualatex
the fontenc and inputenc packages are not loaded in the output, which is
correct and it is the minimum requirement for LuaLaTeX. I think Org is
already doing a good job here.
If the user wants to use other fonts, the fontspec package must be
loaded. Depending on the user's needs, you can go from the simplest to
the most complex configurations (the different options and possibilities
are explained in detail in the fontspec manual). The simplest: if a user
just wants to use the Times New Roman font as the main font in his
document, this lines would suffice:
\usepackage{fontspec}
\setmainfont{Times New Roman}
That is, by indicating the name of the family (Times New Roman), luatex
would use this family for normal text, italics, bold, etc. Of course,
it's a good idea to load a family that has italic, bold, bold italic,
and other subtypes. Fontspec has tons more options, but this would be
the basics. But I think this aspect is more on the LaTeX side than in
the Org side.
LuaTeX can use the fonts installed on the system, without the need to
add more (that is, simply by putting the name of the family, LuaTeX
accesses them); and you can also use any font in any directory, just by
giving the path. I wrote BTW this little package to preview any font in
Emacs, and test the opentype features. it uses org-latex-preview in the
background and compiles with LuaTeX:
https://gitlab.com/maciaschain/org-font-spec-preview
Best regards,
Juan Manuel
Re: [PATCH] oc-basic: Detect malformed bibtex bibliographies
Ihor Radchenko writes: > I believe that it is useful for the users to see such issues instead of, > say, failing silently on malformed bibliographies. Applied onto main via 5b45ad083. Best, Ihor
Re: @string abbreviation in bib file not honored in (basic) org-cite
Dear All, On Sat, 9 Jul 2022 at 05:55, Ihor Radchenko wrote: > The problem with parsebib is that it does not even have license > (I do not see any in https://github.com/joostkremers/parsebib). If > parsebib were a part of Emacs core or at least a part of ELPA, we would > also be able to use it in Org core. looking into the source code (parsebib.el), the library seems to be under a BSD-type license. best wishes, András
Re: Taking notes of videos in Emacs
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 () 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@posteo.net/ > > Best regards, > > Juan Manuel >
Re: [PATCH] Remove additional newline at end of results block
I am replying here because the original reply did not go into my inbox.
Matt Huszagh writes:
>> I'd like to request other people who use export and source blocks
>> extensively to try the patch and see if it breaks anything.
>>
>> Meanwhile, could you please reword the commit message and make it more
>> concise and clear?
>
> Can you clarify what you find to be unclear? Rereading my own commit
> message, my only problem with it is how it starts: I'd add one sentence
> to contextualize it a bit. For instance,
I will provide a detailed response below.
Also, I have found an edge case where your patch creates an issue:
#+begin_src emacs-lisp
2
#+end_src
: fixed-width area, unrelated to the above.
If you execute the above code with your patch, the fixed width area gets
deleted.
> The previous behavior always ensured the presence of an empty line
> between the results block of a source block and the subsequent
> text. However, inserting this newline prevents a valid use-case and
> protects against an edge-case that is completely avoidable without the
> additional guarantee it provides. ... (the rest remains unchanged)
The second sentence is hard to understand because (1) it contains two
non-obvious statements; (2) the statements will only become clear for
the reader after reading the next sentences. In writing, it is generally
advised to start from something reader is familiar with and introduce
new things one by one.
> This commit message isn't short, but I think it's very clear. It
> describes the previous behavior, explains the rationale for that
> behavior, and then illustrates (with a complete example) how this
> prevents a valid use case. It also explains why the new change does not
> prohibit any behavior that was previously possible.
>
> As someone who frequently uses git log, I'd much rather see a commit
> message like this than the typical (usually) unhelpful one or two
> sentences that fail to provide the motivation for a change. There's no
> downside to a long commit message, and this one is structured such that
> it proceeds from more general to more specific information - not
> everyone has to read the entire thing.
>
> I'm not trying to be difficult :) but I do care about the quality of
> this codebase (as I know do you), so I'm reluctant to change something
> in a way I feel is inferior. But, if you have specific parts etc you
> feel are unclear I'm more than happy to address those.
Sorry, I think you misunderstood my intentions. I am not against
detailed commit messages. I also prefer when commits have sufficient
information to understand the motivation behind.
However, there is no reason to give lengthy and hard-to-understand
explanations when more concise wording is possible.
Now, detailed comments on what is confusing about the commit message:
> * lisp/ob-core.el (org-babel--insert-results-keyword): Remove newline
> at end of results block.
This is minor, but I'd rather say "Do not add newline ...". Because it
is what the patch actually does.
> Inserting this newline prevents a valid use-case and protects against
> an edge-case that is completely avoidable without the additional
> guarantee it provides. The original intention for inserting the
> newline was to avoid the edge case in which a user does not insert a
> newline between a source block and the subsequent text and the
> subsequent text is merged with the results.
This is hard to understand.
It is unclear which part of code you are referring to. If a reader is
not familiar with the changed function, the first statement "inserting
this newline..." is unclear. What does "this" refer to?
In the second sentence you are trying to describe the original edge
case, but it is really hard to imagine without having an example.
I'd say something like:
"Previously, `org-babel--insert-results-keyword' inserted an empty line
after result of evaluation even when the original source block had no
empty lines. This was done to address the following issue:"
Then, I'd provide an example on the original issue.
Then, I'd continue with your original wording:
> However, there are valid cases in which a user would not want a
> newline between a results block and the subsequent buffer text. For
> example, many display equations in LaTeX are considered as part of the
> surrounding paragraph. Additionally, it is possible to setup a LaTeX
> source block to be executable and insert results into the org
> buffer. Consider the following example:
>
> some org file (leading colons to prevent git ignoring lines starting
> with #):
> ```
> : We can write the simplest equation as
> : #+begin_src latex
> : \begin{equation}
> : 1 + 1 = 2,
> : \end{equation}
> : #+end_src
> : and hope that no one is confused by this.
> ```
"and hope that no one is confused by this" sounds too similar to the
main commit message. When I was reading your example Org text, I kept
confusing this phrase with the actual message.
> We might then execute this source
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
On 09/07/2022 10:50, Ihor Radchenko wrote: Or we may go even further and make org-latex-compiler default to luatex. This will benefit all the non-latin language users. 1. It is necessary to detect if LuaLaTeX is installed to fallback to PdfLaTeX otherwise. On Ubuntu presence of lualatex binary does not mean that all necessary files are installed. Perhaps it is possible to ask kpsewhich whether lualatex.fmt is available (or some other file specific to lualatex). 2. It is necessary to found suitable fonts installed in the user system. It becomes more complicated that different fonts are required for different scripts (Cyrillic, Greek, Thai combined in the single document), it is not CSS where list of fonts may be provided and a rendering engine pics first one having a necessary glyph. See the earlier discussion: https://list.orgmode.org/orgmode/m18s299yxm@nobis-it.eu/T/#u
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
Bruce D'Arcus writes on Fri 8 Jul 2022 08:05:
> On Fri, Jul 8, 2022 at 7:25 AM wrote:
>
> > As I do not know which of these alternatives
> >
> >- it is normal, this feature should not be there,
> >- it is an oversight,
> >- this feature is not implemented yet,
>
> I believe this is the answer, and it's arguable (I have no opinion,
> and could see reasonable arguments either way) whether a "basic"
> processor should support it?
Is someone using natbib/bibtex (say) expected to never ever use
'basic'? (I don't know.) If so, perhaps there is indeed no need to
implement the feature. Otherwise, it seems to me that not
implementing it amounts to having to give up on @string altogether.
> The parsebib library, which most third party packages use (for
> org-cite, there's my citar), does support this feature.
Thank you. I guess that if it would have be mentioned I would have
silently accepted it.
Some context: although I have been using org-mode for more than 5
years, I had always delayed the "bibliography step", namely, learn
org-ref. But wait, now there is org-cite, so which one should I
learn? Spending days (literally) reading a lot of material, trying to
digest the terminology (it is a real mess). OK, org-cite seems to be
the future, so I'll give it a try. First elementary test -> failure
-- so frustrating. I conclude that the project is not mature enough
(at least the documentation), and I give up. It is only because I
could not have org-ref work either that I came back to org-cite.
I take the opportunity to say that I think that the simple
self-contained example
#+bibliography: references.bib
[cite:@key]
#+print_bibliography:
should be part of the manual, especially since the
2021-07-31-citations post does not seem to be referred to in the
manual any more (I have org version 9.5.4).
Frankly, the manual was cryptic to me at the beginning (and still is,
to a significant extent -- granted, I am a very slow learner), and I
don't know how much time it would have taken me to come up with this
simple example.
Similar minimal examples with natbib, biblatex, etc., together with
the required instructions in the emacs init file, would also be most
welcome (I spent a day to have one work for me with natbib... I
include it below, in case it could be useful to someone else; the
examples I found on this mailing list did not work for me). I
understand that it is not possible to provide an example for each
possible combination of the parameters, but a few ones are perhaps a
reasonable wish? Not only a working example helps to get started, but
it also helps a lot to understand the documentation in return.
Furthermore, it gets much easier to ask for help: "I did this (or a
slight modification of it), it does not work, please help".
Many thanks and congratulations for org-cite.
Regards.
-
my setup for org-cite with natbib
-
org file:
-
#+cite_export: natbib plainnat
#+bibliography: cite.bib
[cite:@chouet88]
#+print_bibliography:
NB: 'plainnat' above refers to file
/usr/share/texlive/texmf-dist/bibtex/bst/natbib/plainnat.bst, which,
on my Fedora 34 GNU/Linux distribution, is part of the
texlive-natbib-svn20668.8.31b-39.fc34.noarch rpm package.
cite.bib file:
--
@string{jgr="J. Geophys. Res."}
@ARTICLE{chouet88,
journal=jgr,
author={Chouet, B.}, title={Resonance of a fluid-driven crack: [...]},
year={1988}, volume={93}, number={B5}, pages={4375-4400}
}
emacs init file:
(require 'oc-natbib)
(setq org-latex-pdf-process '("pdflatex -interaction nonstopmode
-output-directory %o %f" "bibtex %b" "pdflatex -interaction
nonstopmode -output-directory %o %f" "pdflatex -interaction
nonstopmode -output-directory %o %f" ) )
NB: It does not work for me without '-interaction nonstopmode' (I have
emacs 27.2 and org 9.5.4.).
Then 'C-c C-e l o' from the org file to display the pdf, which shows:
Contents
[Chouet, 1988]
References
B. Chouet. Resonance of a fluid-driven crack: [...]. J. Geophys. Res.,
93(B5): 4375–4400, 1988.
--
EOST (École et Observatoire des Sciences de la Terre)
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44
F-67084 Strasbourg Cedex, France | [ slot available for rent ]
