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 block