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

[Dominik Schrempf]

FWIW: I have switched to lualatex years ago. In my opinion the additional
compilation time is worth much more than my time debugging problems with
weird symbols. Even when I only use Latin in the main text, most of the
time, there are some special symbols that would need special attention in
the bibliography.

Re: [PATCH] Fix behavior of lambda default header arg vars

[Ihor Radchenko]

Matt Huszagh  writes:

> ... Try these.

Thanks!
Applied onto main via e8dd98d15 and 8be689f11 with amendments.
I have modified the commit messages to provide the properly formatted
changelog entries that include the modified function/defcustom name.
Also, I have changed the commit messages and the comments to have double
space between sentences.

Best,
Ihor

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

[Tim Cross]

Ihor Radchenko  writes:

> 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). 
>
> If only a minor tweaking is required to make luatex work with generic
> Org export, I'd add direct support of luatex to ox-latex.el depending on
> the value of org-latex-compiler.
>
> Or we may go even further and make org-latex-compiler default to luatex.
> This will benefit all the non-latin language users.
>

Perhaps easy choice/switching would be useful. Not sure about changing
the default - from what I can see, it would make processing slower for
all those using latin languages. (however, I'm not good on judging slow
- from my perspective, little is slow these days. I still recall
waiting overnight just to compile my linux kernel, which was much much
smaller back then. My thesis, written in Latex, use to take
enough time to generate a postscript file I could go and make a coffee!
Everything has gotten faster as I've gotten slower!)

Re: Warning (org-element-cache): org-element--cache: Warning( *helm-org-rifle-fontify*): Unregistered buffer modifications detected. Resetting.

[Ihor Radchenko]

Gregor Zattler  writes:

> I then updated org-mode, applied your patch: No warning
> either.  I then purged ~/.cache/org/persist and restarted
> emacs: No warnings.
>
> So while there are no downsides regarding my small test with
> your patch, I cannot verify that it addresses the problem,
> because I was not able to reproduce it :-(  Sorry about that.

The situation I observe in the backtrace appears to be rather uncommon -
cache sync timer is triggered between before-change-functions and
after-change-functions. At least, it is my guess on what have happened
and the patch should be anyway useful in such a case.
So,
Applied onto main via e0e016c1a.

Let me know if you run into this issue again in future.

Best,
Ihor

Re: [PATCH] org-src.el: Add plain to org-src-window-setup customization

[Ihor Radchenko]

Matt Rudary  writes:

> I was trying to customize org-src-window-setup and noticed that "plain" was
> not an option, despite being documented. I checked the commit and it seems
> the implementation was added but the choice list in the defcustom was not
> updated.

Thanks for your contribution!
Applied onto main via a7cc95c60 with minor amendments to the commit
message. I have added `' quotes to function symbols.

Bastien, could you please add Matt to tiny change contributor list?

Best,
Ihor

Re: Alternatives to clocking in/out for reporting time

[Ihor Radchenko]

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?

Best,
Ihor

Re: [BUG] org-agenda-prepare-buffers does not save restrictions

[Ihor Radchenko]

Al Haji-Ali  writes:

> On 08/07/2022, Ihor Radchenko wrote:
>> Could you please create a proper patch
>
> See attached. I made a further change to use `with-current-buffer` instead of
> `set-buffer+save-excursion`.

Thanks!
Two more comments.

> * lisp/org.el (org-agenda-prepare-buffers): Call
> `save-restriction'/`save-excursion' for every buffer in the agenda
> instead of just once for the current buffer. Use `with-current-buffer'
> instead of `set-buffer'/`save-excursion'.

Please use double space between sentences.

> +  (save-excursion
> +(save-restriction
> +  (widen)

A more concise way is

(org-with-wide-buffer ...)

Best,
Ihor

Re: @string abbreviation in bib file not honored in (basic) org-cite

[Ihor Radchenko]

"Bruce D'Arcus"  writes:

> 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?
>
> The parsebib library, which most third party packages use (for
> org-cite, there's my citar), does support this feature.

oc-basic.el is relying on built-in bibtex.el. AFAIK, bibtex.el does not
support @string abbreviations.

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.

Or one could extend bibtex.el with abbreviation support.

Best,
Ihor

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

[Ihor Radchenko]

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

If only a minor tweaking is required to make luatex work with generic
Org export, I'd add direct support of luatex to ox-latex.el depending on
the value of org-latex-compiler.

Or we may go even further and make org-latex-compiler default to luatex.
This will benefit all the non-latin language users.

Best,
Ihor

Re: Mathjax and org-mime-htmlize

[Ihor Radchenko]

Joseph Vidal-Rosset  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: org-meta-return / org-insert-heading does not insert new heading in middle of heading even id org-M-RET-may-split-line is set

[Ihor Radchenko]

Guillaume MULLER  writes:

> I'm not sure what did the trick, but if someone is looking for a solution, 
> it's probably a mix of:
> - disabling org in Doom's init.el and/or
> - manually pulling & compiling the versions in 
> ~/.emacs.d/.local/straight/{repos,build-27.1}/org  and/or
> - changing the :pin setup in ~/.emacs.d/modules/lang/org/packages.el to point 
> to the latest commit.

AFAIU, :pin should be the right way that will not break updates.

> FWIW, "list-packages" only shows the 9.3 builtin version of org, so my 
> current working 9.5.4 org version seems to actually be loaded from the code 
> previously installed by Doom and manually (re)compiled by me, even if org is 
> disabled in init.el ...

This is because list-packages is not used by Doom. list-packages is a
built-in Vanilla Emacs package manager, while Doom uses straight.el
package manager.

>> What do you mean by "breaks too many other things in org"?
>
> When calling some functions (e.g. org-meta-return or org-ctrl-c-ctrl-c in a 
> code block or hitting C-x C-c to quit Emacs) I got errors like "function xxx 
> is void" or "wrong arguments listp, xxx".

That sounds like "mixed" installation of built-in and Doom's versions of
Org. Should not be an issue as long as you manage to find the proper way
to configure Doom.

Best,
Ihor

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

[Tim Cross]

Max Nikulin  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). 

Re: Org mode export accessibility

[Ihor Radchenko]

"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

Re: [PATCH v4] ol.el: add description format parameter to org-link-parameters

[Ihor Radchenko]

Hugo Heagren  writes:

> Since the last version of this patch, I have:
> - moved the code which sets `type' in `org-insert-link' to a position
>   where it covers more cases
> - rewritten the macros used in the tests, so that always (and
>   correctly) restore the original state after running, even after
>   errors. Thanks to Max Nikulin for suggesting using `condition-case'

Thanks!

> tl;dr The question is: what is the Good Behaviour when
> :default-description is set to something, which is meant to return a
> string and returns 'nil instead? Should it be treated like an empty
> string, or as an error?

Currently, the internal implementation will treat nil return value as if
there was no :default-description and org-link-make-description-function
were set to nil. We may probably document this. It sounds like a useful
behavior.

If the :default-description function returns non-string and not nil, the
behavior is simply undefined. It was also the case for
org-link-make-description-function. Though we might add a cl-assert
somewhere near the end of org-insert-link to deliberately throw an
error.

> Subject: [PATCH 2/2] test-ol: tests for default-description param when
>  inserting links

> Add tests for various values of `:default-description' in
> `org-link-parameters'.

Could you also add the proper changelog entry for the test-ol.el file?

> +;;; Insert Links
> +
> +(defmacro test-ol-with-link-parameters-as (type parameters  body)
> +  "Pass TYPE/PARAMETERS to `org-link-parameters' and execute BODY.
> +
> +Save the original value of `org-link-parameters', execute
> +`org-link-set-parameters' with the relevant args, execute BODY
> +and restore `org-link-parameters'.
> +
> +TYPE is as in `org-link-set-parameters'.  PARAMETERS is a plist to
> +be passed to `org-link-set-parameters'."
> +  ;; Copy all keys in `parameters' and their original values to
> +  ;; `orig-parameters'. For `parity': nil = odd, non-nill = even

*non-nil

Also, please end each sentence in the comment with ".".

> +  `(let (parity orig-parameters)
> + (dolist (p ',parameters)
> +   (unless parity
> + (setq orig-parameters
> +   (plist-put orig-parameters p (org-link-get-parameter ,type 
> p
> +   (setq parity (not parity)))

This is a bit awkward code. You can instead use cl-loop by 'cddr or
a simple while loop with two (pop parameters) statements inside.

Also, ',parameters will fail if PARAMETERS argument is a variable name.

> + ;; Set `parameters' values
> + (condition-case err
> + (let ((_ (org-link-set-parameters ,type ,@parameters))
> +   ;; Do body
> +   (rtn (progn ,@body)))
> +   ;; Restore original values
> +   (apply 'org-link-set-parameters ,type orig-parameters)
> +   ;; Return whatever the body returned
> +   rtn)
> +   ;; In case of error, restore state anyway AND really error
> +   (error
> +(apply 'org-link-set-parameters ,type orig-parameters)
> +(signal (car err) (cdr err))

unwind-protect is more suitable here and will lead to more concise code.

> Subject: [PATCH 1/2] ol.el: add description format parameter to
>  org-link-parameters
>
> * ol.el (org-link-parameters): add parameter `:default-description', a
> string or a function.
> * (org-insert-link): if no description is provided (pre-existing or as
> an argument), next option is to use the `:default-description' (if
> non-nil) parameter to generate one.
>
> Default descriptions are predictable within a link type, but because
> link types are quite diverse, are NOT predictable across many types. A
> type-parameter is thus a good place to store information on the
> default description.

Please start sentences after ":" with capital letter. Also, you missed
double space between sentences.

> +`:default-description'
> +
> +  String or function used as a default when prompting users for a
> +  link's description.  A string is used as-is, a function is
> +  called with two arguments: the full link text, and the
> +  description generated by `org-insert-link'.  It should return
> +  the description to use (this reflects the behaviour of
> +  `org-link-make-description-function').
> +
>  `:display'

I think that we should also document the new parameter in ORG-NEWS.
  
Best,
Ihor

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

[Thomas S. Dye]

Max Nikulin  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

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

[Max Nikulin]

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.

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

[Matt Huszagh]

Juan Manuel Macías  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:
>
>
>
> 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 

Re: [PATCH] Fix caption format for custom latex src block

[Matt Huszagh]

Timothy  writes:

> As mentioned by Ihor, you’ll want to take a look at the curent version of
> ox-latex, specifically `org-latex-src-block--custom' which now contains `(?c .
> ,caption)'. You may want to consider modifying 
> `org-latex--caption/label-string' to
> accept the form `(element info  content-only)' or reimplementing 
> just the
> bits needed for this purpose — which ever works out nicer. Looking at
> `org-latex--caption/label-string' a substring approach looks quite fragile, 
> though
> you might be able to get away with an application of 
> `replace-regexp-in-string',
> though I’d personally consider this a bit of a last resort.

Thanks for the directions Timothy.

I failed to reproduce the old issue with the latest commit to main, so
it looks like this patch is no longer needed. Nice! I'll post back if I
notice any issues in the future, but otherwise I'd say we can consider
this closed.

Matt

Re: [PATCH] Remove additional newline at end of results block

[Matt Huszagh]

Ihor Radchenko  writes:

> Thanks for the patch! And sorry for the late reply.

No worries for the delay - I know you have a lot of these. Thanks for
the review.

> Your explanation is quite confusing, but I think I managed to understand
> what you referred to:
>
> --
>  We can write the simplest equation as
>  #+begin_src latex :exports results
>  \begin{equation}
>1 + 1 = 2,
>  \end{equation}
>  #+end_src
> the paragraph should continue here.
> 
>
> will be exported as
>
> --
> We can write the simplest equation as
> \begin{equation}
>   1 + 1 = 2,
> \end{equation}
>
> the paragraph should continue here.
> --
>
> Note the extra empty line below equation environment.
>
> However, I am not confident if the proposed change is going to be safe
> for other uses of src blocks.
>
> 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,

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)

Oh and I also made a typo. A sentence further down should read
"...generate an SVG image...".

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.

Matt

Re: [PATCH] Fix behavior of lambda default header arg vars

[Matt Huszagh]

Ihor Radchenko  writes:

> This patch does not apply. It does not appear to be based on the
> original main branch:
>
> Applying: ob-core.el: Improve org-babel-default-header-args docstring
> error: sha1 information is lacking or useless (lisp/ob-core.el).
> error: could not build fake ancestor

My mistake. Try these.

Matt

>From 6894d7b441fe975bc90177d85102c031cffe3c46 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Mon, 27 Jun 2022 20:41:02 -0700
Subject: [PATCH 1/2] ob-core.el: Fix behavior of lambda default header arg
 vars

* lisp/ob-core.el: Permit multiple :var default header arguments when
using closures.
---
 lisp/ob-core.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 75a6a167d..0d9ec5c84 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2749,6 +2749,11 @@ parameters when merging lists."
 	(pcase pair
 	  (`(:var . ,value)
 	   (let ((name (cond
+;; Default header arguments can accept lambda
+;; functions. We uniquely identify the var
+;; according to the full string contents of
+;; the lambda function.
+			((functionp value) value)
 			((listp value) (car value))
 			((string-match "^\\([^= \f\t\n\r\v]+\\)[ \t]*=" value)
 			 (intern (match-string 1 value)))
-- 
2.31.1

>From 12833bc6c089af9d94c9535835e0a68d189c8496 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Mon, 27 Jun 2022 20:42:27 -0700
Subject: [PATCH 2/2] ob-core.el: Improve org-babel-default-header-args
 docstring

* lisp/ob-core.el: Provide example illustrating one benefit of using
closures as default header arguments. Additionally, explain how to
provide the same type of header argument multiple times in the default
alist.
---
 lisp/ob-core.el | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 0d9ec5c84..d85c66e76 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -482,12 +482,14 @@ For the format of SAFE-LIST, see `org-babel-safe-header-args'."
 This is a list in which each element is an alist.  Each key
 corresponds to a header argument, and each value to that header's
 value.  The value can either be a string or a closure that
-evaluates to a string.  The closure is evaluated when the source
-block is being evaluated (e.g. during execution or export), with
-point at the source block.  It is not possible to use an
-arbitrary function symbol (e.g. \\='some-func), since org uses
-lexical binding.  To achieve the same functionality, call the
-function within a closure (e.g. (lambda () (some-func))).
+evaluates to a string.
+
+A closure is evaluated when the source block is being
+evaluated (e.g. during execution or export), with point at the
+source block.  It is not possible to use an arbitrary function
+symbol (e.g. 'some-func), since org uses lexical binding.  To
+achieve the same functionality, call the function within a
+closure (e.g. (lambda () (some-func))).
 
 To understand how closures can be used as default header
 arguments, imagine you'd like to set the file name output of a
@@ -504,7 +506,16 @@ this with:
 
 Because the closure is evaluated with point at the source block,
 the call to `org-element-at-point' above will always retrieve
-information about the current source block.")
+information about the current source block.
+
+Some header arguments can be provided multiple times for a source
+block.  An example of such a header argument is :var.  This
+functionality is also supported for default header arguments by
+providing the header argument multiple times in the alist.  For
+example:
+
+'((:var . \"foo=\\\"bar\\\"\")
+  (:var . \"bar=\\\"foo\\\"\"))")
 
 (put 'org-babel-default-header-args 'safe-local-variable
  (org-babel-header-args-safe-fn org-babel-safe-header-args))
-- 
2.31.1

Re: Warning (org-element-cache): org-element--cache: Warning( *helm-org-rifle-fontify*): Unregistered buffer modifications detected. Resetting.

[Gregor Zattler]

Hi Ihor,
* Ihor Radchenko  [2022-07-08; 12:25]:
> Thanks for reporting! The backtrace is very helpful.
>
> Can you please try the attached patch and let me know if it helps?

thanks for the patch.  I first tried to provoke again the
warnings but did not succeed, although I use the same emacs
and org-mode builds.  But my org-mode files are a bit
different now.  Anyway:  No warnings.

I then updated org-mode, applied your patch: No warning
either.  I then purged ~/.cache/org/persist and restarted
emacs: No warnings.

So while there are no downsides regarding my small test with
your patch, I cannot verify that it addresses the problem,
because I was not able to reproduce it :-(  Sorry about that.

Thanks for your attention, Gregor

Re: [BUG] Inline src blocks do not work for LaTeX [9.5.4 (release_9.5.4-3-g6dc785 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Rudolf Adamkovič]

Christian and Ihor,

Thank you folks for taking the time to explain the matter to me.  Your
messages made me realize that I completely misunderstood inline source
blocks.  It all makes sense, and I have no bug to report!

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Taking notes of videos in Emacs

[Quiliro Ordóñez]

El 2022-07-08 08:23, Tor Kringeland escribió:
> Gerardo Moro  writes:
> 
>> Is there something similar in Emacs?
> 
> mpv.el [1] is a starting point.  You can play videos from YouTube (and
> other websites) in mpv if you install yt-dlp [2] (or another youtube-dl
> fork).  With a little bit of hacking you can get all the features of the
> package you mention in Emacs.
> 
> - [1] https://github.com/kljohann/mpv.el
> 
> - [2] https://github.com/yt-dlp/yt-dlp

That is nice.  eev also plays videos from the links it creates.

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

[Juan Manuel Macías]

Bruce D'Arcus writes:

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

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

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

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

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

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

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

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

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

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

Best regards,

Juan Manuel 

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

[Thomas S. Dye]

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.


All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

[PATCH] org-src.el: Add plain to org-src-window-setup customization

[Matt Rudary]

Hi,

I was trying to customize org-src-window-setup and noticed that "plain" was
not an option, despite being documented. I checked the commit and it seems
the implementation was added but the choice list in the defcustom was not
updated.

Best,
Matt Rudary


0001-org-src.el-Add-plain-to-org-src-window-setup-customi.patch
Description: Binary data

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

[Bruce D'Arcus]

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

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

Bruce

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

[Greg Minshall]

Juan Manuel, et al.,

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

i'm guessing this would be a nice addtion to worg (if it's not already
there).

cheers, Greg

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

[Thomas S. Dye]

Juan Manuel Macías  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

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

[Juan Manuel Macías]

Hi Uwe,

Uwe Brauer writes:

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

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

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

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

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

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

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

Best regards,

Juan Manuel 

Re: Taking notes of videos in Emacs

[Samuel Banya]

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@posteo.net/
> 
> Best regards,
> 
> Juan Manuel 
> 
> 

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

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  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 


smime.p7s
Description: S/MIME cryptographic signature

Re: when does :cache not cache?

[Fraga, Eric]

Please ignore.  Restarting Emacs fixed the problem.  For some reason,
re-loading org was not enough.  I can export without error again.

-- 
: Eric S Fraga, with org release_9.5.4-613-gb3b17c in Emacs 29.0.50

Re: when does :cache not cache?

[Ihor Radchenko]

"Fraga, Eric"  writes:

> I updated org recently (and again just now) and am getting the error
> shown in the attached file.  This is related to your patch, I think
> given that it fails in accessing the "stable-file", but haven't verified
> it.  Before I investigate further, I thought I would raise the issue.

Can you check the value of org-babel-temporary-stable-directory and its
docstring?

Best,
Ihor

Re: when does :cache not cache?

[Fraga, Eric]

Hi Ihor,

On Monday,  4 Jul 2022 at 21:06, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
>
>> The patch introduces a new functionality to ob-core.el allowing more
>> stable temporary file names. I am not sure if my implementation is the
>> best way to solve the problem, so comments are welcome.
>
> Applied onto main via 080462198.

I updated org recently (and again just now) and am getting the error
shown in the attached file.  This is related to your patch, I think
given that it fails in accessing the "stable-file", but haven't verified
it.  Before I investigate further, I thought I would raise the issue.

Thank you,
eric

-- 
Eric S Fraga, @ericsfraga:matrix.org, GnuPG: 0xc89193d8fffcf67d
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-exists-p(nil)
  org-babel-temp-stable-file(((:cache . "yes") (:colname-names (plotdata "PSO" 
"" "PPA" "" "GA" "")) (:eval . "no-export") (:exports . "results") (:file . 
"images/permdbetaevolutionplot.png") (:hlines . "no") (:noweb . "yes") 
(:result-params "replace" "file") (:result-type . value) (:results . "replace 
file") (:rowname-names) (:session) (:tangle . "no") (:var plotdata [...] )) 
"gnuplot-")
  #f(compiled-function (pair) # [...])
  org-babel-gnuplot-process-vars([...])
  org-babel-expand-body:gnuplot([...])
  org-babel-sha1-hash([...])
  org-babel-exp-src-block((src-block (:language "gnuplot" :switches nil 
:parameters nil :begin 68881 :end 69528 :number-lines nil :preserve-indent nil 
:retain-labels t :use-labels t :label-fmt nil :value "  reset\n  set logscale 
xy\n  set xlabel \"n_f\"\n  set..." :post-blank 1 :post-affiliated 69077 :name 
"permdbetaplotevolution" :header (":var plotdata=permdbetaresultstable :file 
\"images/..." ":results file" ":exports results" ":eval no-export") :mode 
planning :granularity element :org-element--cache-sync-key (55 . 70525) :cached 
t :parent (section (:begin 68881 :end 79730 :contents-begin 68881 :contents-end 
79679 :robust-begin 68881 :robust-end 79677 :post-blank 51 :post-affiliated 
68881 :mode section :granularity element :org-element--cache-sync-key (55 . 
70524) :cached t :parent (headline (:raw-value "results" :begin 68810 :end 
79730 :pre-blank 0 :contents-begin 68881 :contents-end 79679 :robust-begin 
68883 :robust-end 79677 :level 3 :priority nil :tags (...) :todo-keyword nil 
:todo-type nil :post-blank 51 :footnote-section-p nil :archivedp nil 
:commentedp nil :post-affiliated 68810 :title "results" :mode nil :granularity 
element :org-element--cache-sync-key (55 . 68551) :cached t :parent (headline 
...
  org-babel-exp-process-buffer()
  org-export-as(latex nil nil nil (:output-file "book.tex"))
  org-export-to-file(latex "book.tex" nil nil nil nil nil org-latex-compile)
  org-latex-export-to-pdf(nil nil nil nil)
  (org-open-file (org-latex-export-to-pdf nil s v b))
  (if a (org-latex-export-to-pdf t s v b) (org-open-file 
(org-latex-export-to-pdf nil s v b)))
  (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b) (org-open-file 
(org-latex-export-to-pdf nil s v b(nil nil nil nil)
  org-export-dispatch(nil)
  funcall-interactively(org-export-dispatch nil)
  command-execute(org-export-dispatch)

Re: Problem with defining stuck projects

[Bob Heffernan]

On 22-07-08 12:51, Ihor Radchenko wrote:
> "^[ \t]*\\(SCHEDULED:\\|DEADLINE:\\)"

Ihor,
This seems to work.  Thank you.

Regards,
Bob

Re: Org mode export accessibility

[T.V Raman]

1. Labels: yes -- figure captions etc. are examples of "labels" in
   general.

2. Math: Yes -- I meant the TeX/LaTeX representation of a math
   expression.
   Ihor Radchenko writes:
 > "T.V Raman"  writes:
 > 
 > > On org side:
 > 
 > Thanks for the feedback!
 > 
 > > 1. During authoring, ensure that authors have the ability to label
 > >images, drawings and math content.
 > >2. When exporting, make sure that that information gets through to
 > >   the exported format.
 > 
 > Could you please elaborate what you mean by "label"?
 > 
 > Org generally supports figures and equations in export, including adding
 > captions - all specific to the corresponding export backends (when the
 > backends support figures/equations).
 > 
 > >   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?
 > 
 > Best,
 > Ihor

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  瑩

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  瑩

Re: Org mode export accessibility

[T.V Raman]

Correct.
1. Org should be the truth, not some export format that is picked
   based on political opinion.

2. Lowest Common denominator in my vocabulary is a "bad word" that LCD
   is something that makes everyone equally unhappy.

   So Take-Away:

   1. Make org the best format for holding the authored content.
  2. Consider all exports to be either modality or use-case
 specific and produce the  best version that that export
 format can support.

 3. But then dont fall into the delusion that the export
format is the truth --

   

Ihor Radchenko writes:
 > briangpowell  writes:
 > 
 > > Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
 > > documents as output:
 > > TeXinfo docs should be used as the LCD doctype--suggest you focus on
 > > creating 1 document in Texinfo that you use to create all other sorts of
 > > documents, when possible:
 > >
 > > Pipeline should be more like
 > > OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF
 > >
 > > * TeXinfo: https://savannah.gnu.org/projects/texinfo
 > > https://www.gnu.org/software/texinfo
 > 
 > I do not think that using Texinfo as intermediate format is useful.
 > Texinfo does not support many of the available Org syntax structures
 > like, for example, backend-specific export blocks. We will inevitably
 > lose some document structure information when exporting to Texinfo.
 > Please remember that Texinfo is by no means a generic export engine - it
 > is tailored to produce software documentation specifically and may not
 > be suitable for more generic authored documents.
 > 
 > Note that we already have a much more feature-full export functionality.
 > RMS even suggested that Org might be used as a replacement for Texinfo:
 > https://yhetil.org/emacs-devel/e1nzqh5-0001ob...@fencepost.gnu.org
 > 
 > Best,
 > Ihor

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  瑩

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  瑩

Re: org-meta-return / org-insert-heading does not insert new heading in middle of heading even id org-M-RET-may-split-line is set

[Guillaume MULLER]

Hi again,

> I am using Vanilla Emacs.
> Note that Doom is known for carelessly advising some Org functions and
> can sometimes break things. Such issues should be reported to Doom
> developers.

Thanks for your help & pointers.

Yes I agree, the problem must come from Doom's config (the commit version it 
uses seems 24k+ commits behind your HEAD!!). I reported the problem directly to 
them:
https://github.com/doomemacs/doomemacs/issues/6544

I did some more tests within Doom's config (see the issue for details) but 
couldn't find the proper way to get it running the latest org release (9.5.4).

Fortunately, I ended up with a working config. 

I'm not sure what did the trick, but if someone is looking for a solution, it's 
probably a mix of:
- disabling org in Doom's init.el and/or
- manually pulling & compiling the versions in 
~/.emacs.d/.local/straight/{repos,build-27.1}/org  and/or
- changing the :pin setup in ~/.emacs.d/modules/lang/org/packages.el to point 
to the latest commit.

FWIW, "list-packages" only shows the 9.3 builtin version of org, so my current 
working 9.5.4 org version seems to actually be loaded from the code previously 
installed by Doom and manually (re)compiled by me, even if org is disabled in 
init.el ...

This will probably break at next Doom sync/upgrade, but since it works, I won't 
touch it anymore :)

> What do you mean by "breaks too many other things in org"?

When calling some functions (e.g. org-meta-return or org-ctrl-c-ctrl-c in a 
code block or hitting C-x C-c to quit Emacs) I got errors like "function xxx is 
void" or "wrong arguments listp, xxx".

Have a nice day


Guillaume


OpenPGP_signature
Description: OpenPGP digital signature

Mathjax and org-mime-htmlize

[Joseph Vidal-Rosset]

Hello,

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.

All the best,

Jo.

Re: Taking notes of videos in Emacs

[Juan Manuel Macías]

Gerardo Moro writes:

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

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

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

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

Best regards,

Juan Manuel 

Re: Taking notes of videos in Emacs

[Ihor Radchenko]

Gerardo Moro  writes:

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

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

Re: Taking notes of videos in Emacs

[Tor Kringeland]

Gerardo Moro  writes:

> Is there something similar in Emacs?

mpv.el [1] is a starting point.  You can play videos from YouTube (and
other websites) in mpv if you install yt-dlp [2] (or another youtube-dl
fork).  With a little bit of hacking you can get all the features of the
package you mention in Emacs.

- [1] https://github.com/kljohann/mpv.el

- [2] https://github.com/yt-dlp/yt-dlp

Re: Taking notes of videos in Emacs

[Kaushal Modi]

On Fri, Jul 8, 2022, 9:07 AM Gerardo Moro  wrote:

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

I think Sacha Chua uses Org mode to take time stamped notes. She might be
able to point you to her note taking flow.

>

Taking notes of videos in Emacs

[Gerardo Moro]

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?

Thank you!

G.

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

[Juan Manuel Macías]

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



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

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

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

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

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

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

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

   

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

   ┌
   │ \setmainfont{Palatino Linotype}
   └

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

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

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

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

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

   We can also load the otf tags directly:

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

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

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

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

Re: @string abbreviation in bib file not honored in (basic) org-cite

[Bruce D'Arcus]

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?

The parsebib library, which most third party packages use (for
org-cite, there's my citar), does support this feature.

>- it does not work for me for some reason,
>- other,

Bruce

@string abbreviation in bib file not honored in (basic) org-cite

[Alain . Cochard]

Hello.

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,
   - it does not work for me for some reason,
   - other,

is valid, I decided to report this minor issue.

Specifically, I followed the following (found on
https://blog.tecosaur.com/tmio/2021-07-31-citations.html, linked from
https://orgmode.org/Changes.html):
 
   So, to summarise, all one needs to get started is:
   #+bibliography: references.bib
   [cite:@key]
   #+print_bibliography:
   That’s it!

My .bib file is 

   @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}

Of course I use [cite:@chouet88].

Then I do 'C-c e l o' and I get (copied from the resulting .pdf):

   Contents
   (Chouet, B., 1988)
   Chouet, B. (1988). Resonance of a fluid-driven crack: [...], jgr.

Regards,
a.

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

Re: [BUG] org-agenda-prepare-buffers does not save restrictions

[Al Haji-Ali]

On 08/07/2022, Ihor Radchenko wrote:
> Could you please create a proper patch

See attached. I made a further change to use `with-current-buffer` instead of
`set-buffer+save-excursion`.

Best regards,
-- Al
>From 398fee0c235c53399cd8cc481f9e732f64ae88cb Mon Sep 17 00:00:00 2001
From: Al Haji-Ali 
Date: Fri, 8 Jul 2022 10:24:08 +0100
Subject: [PATCH] lisp/org.el: Save restrictions in all agenda file buffers.

* lisp/org.el (org-agenda-prepare-buffers): Call
`save-restriction'/`save-excursion' for every buffer in the agenda
instead of just once for the current buffer. Use `with-current-buffer'
instead of `set-buffer'/`save-excursion'.

TINYCHANGE
---
 lisp/org.el | 80 ++---
 1 file changed, 39 insertions(+), 41 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 661efeb9c..ef3e4b950 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15031,49 +15031,47 @@ When a buffer is unmodified, it is just killed.  When modified, it is saved
   "Create buffers for all agenda files, protect archived trees and comments."
   (interactive)
   (let ((inhibit-read-only t)
-	(org-inhibit-startup org-agenda-inhibit-startup)
-	pos)
+	(org-inhibit-startup org-agenda-inhibit-startup))
 (setq org-tag-alist-for-agenda nil
 	  org-tag-groups-alist-for-agenda nil)
-(save-excursion
-  (save-restriction
-	(dolist (file files)
-	  (catch 'nextfile
-	(if (bufferp file)
-		(set-buffer file)
-	  (org-check-agenda-file file)
-	  (set-buffer (org-get-agenda-file-buffer file)))
-	(widen)
-	(org-set-regexps-and-options 'tags-only)
-	(setq pos (point))
-	(or (memq 'category org-agenda-ignore-properties)
-		(org-refresh-category-properties))
-	(or (memq 'stats org-agenda-ignore-properties)
-		(org-refresh-stats-properties))
-	(or (memq 'effort org-agenda-ignore-properties)
-(unless org-element-use-cache
-		  (org-refresh-effort-properties)))
-	(or (memq 'appt org-agenda-ignore-properties)
-		(org-refresh-properties "APPT_WARNTIME" 'org-appt-warntime))
-	(setq org-todo-keywords-for-agenda
-		  (append org-todo-keywords-for-agenda org-todo-keywords-1))
-	(setq org-done-keywords-for-agenda
-		  (append org-done-keywords-for-agenda org-done-keywords))
-	(setq org-todo-keyword-alist-for-agenda
-		  (append org-todo-keyword-alist-for-agenda org-todo-key-alist))
-	(setq org-tag-alist-for-agenda
-		  (org--tag-add-to-alist
-		   org-tag-alist-for-agenda
-		   org-current-tag-alist))
-	;; Merge current file's tag groups into global
-	;; `org-tag-groups-alist-for-agenda'.
-	(when org-group-tags
-	  (dolist (alist org-tag-groups-alist)
-		(let ((old (assoc (car alist) org-tag-groups-alist-for-agenda)))
-		  (if old
-		  (setcdr old (org-uniquify (append (cdr old) (cdr alist
-		(push alist org-tag-groups-alist-for-agenda)
-	(goto-char pos)
+(dolist (file files)
+  (catch 'nextfile
+(with-current-buffer
+(if (bufferp file)
+file
+  (org-check-agenda-file file)
+  (org-get-agenda-file-buffer file))
+  (save-excursion
+(save-restriction
+  (widen)
+	  (org-set-regexps-and-options 'tags-only)
+	  (or (memq 'category org-agenda-ignore-properties)
+		  (org-refresh-category-properties))
+	  (or (memq 'stats org-agenda-ignore-properties)
+		  (org-refresh-stats-properties))
+	  (or (memq 'effort org-agenda-ignore-properties)
+  (unless org-element-use-cache
+		(org-refresh-effort-properties)))
+	  (or (memq 'appt org-agenda-ignore-properties)
+		  (org-refresh-properties "APPT_WARNTIME" 'org-appt-warntime))
+	  (setq org-todo-keywords-for-agenda
+		(append org-todo-keywords-for-agenda org-todo-keywords-1))
+	  (setq org-done-keywords-for-agenda
+		(append org-done-keywords-for-agenda org-done-keywords))
+	  (setq org-todo-keyword-alist-for-agenda
+		(append org-todo-keyword-alist-for-agenda org-todo-key-alist))
+	  (setq org-tag-alist-for-agenda
+		(org--tag-add-to-alist
+		 org-tag-alist-for-agenda
+		 org-current-tag-alist))
+	  ;; Merge current file's tag groups into global
+	  ;; `org-tag-groups-alist-for-agenda'.
+	  (when org-group-tags
+	(dolist (alist org-tag-groups-alist)
+		  (let ((old (assoc (car alist) org-tag-groups-alist-for-agenda)))
+		(if old
+		(setcdr old (org-uniquify (append (cdr old) (cdr alist
+		  (push alist org-tag-groups-alist-for-agenda))
 (setq org-todo-keywords-for-agenda
   (org-uniquify org-todo-keywords-for-agenda))
 (setq org-todo-keyword-alist-for-agenda
--
2.24.4

Re: Ignore, skip, omit headline when exporting to LaTeX

[edgar]

On 2022-07-08 05:04, Ihor Radchenko wrote:

ed...@openmail.cc writes:


This is on topic and can be useful for others  So, there should 
be no issue with

posting this here 


Thanks!


Note that this modified version of the function is derived from
org-export-ignore-headlines from ox-extra.el [1]


Thank you for the link.


However, a part of the original function code is omitted.
AFAIU, this version also discards the headline contents, in addition to
the headline itself (unlike what org-export-ignore-headlines does).


Sorry, I just had the version from 2014! :P  As mentioned in the comment 
of the new function, I just added a conditional and replaced "ignore" 
with "ignoreltx". As a suggestion, it could be possible to replace 
"ignore" with a variable and use another variable such that the headline 
is omitted when other export types (latex, html, etc.) are used.


In any case: Thanks for almost 20 years!



[1] https://git.sr.ht/~bzg/org-contrib

Best,
Ihor


To you too!

-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: Alternatives to clocking in/out for reporting time

[Russell Adams]

On Fri, Jul 08, 2022 at 03:02:00PM +0800, Ihor Radchenko wrote:
> You may hook into timestamp insertion/todo-state change functions and
> accumulate the "time" into headline properties.

Hooking on insertion is a bit low level, and sounds like it's only
about maintaining state in the currently running Emacs.

I just want to get the agenda items in a programmatic way so I can
report on them.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: Alternatives to clocking in/out for reporting time

[Ihor Radchenko]

Russell Adams  writes:

> I find Org's clocking to be too detailed, and that it doesn't play
> well with dynamically organized hierarchies of notes. I frequently
> create and close subtasks, or switch parts of the tree. Clocking each
> one is too much overhead, and too granular. I don't need to provide
> down to the minute reports of each item. It also doesn't appear to
> allow rounding of values, so I still have to adjust the results.
>
> What I envision is a way to count items in the agenda view to produce
> a time report. Counting any inactive timestamp as 15 minutes, where if
> a half hour or more is logged I round up to bill the hour. Closed TODO
> items should count toward billing that whole hour. Clearly this should
> be customized.
>
> The point is that I'm not worried about accounting time by task,
> instead I'm aggregating tasks into accounting by whole hours.
>
> I'm looking at org-element, and it appears I'd have to do my own
> agenda style scan of the whole tree to find items to classify by
> hour. While I'm somewhat proficient at elisp, that sounds like a steep
> wall to climb.
>
> Is there an iterative way to review items in an agenda view so I can
> do the math to produce a report?

You may hook into timestamp insertion/todo-state change functions and
accumulate the "time" into headline properties.

I did something conceptually similar in
https://github.com/yantar92/emacs-config/blob/master/config.org#bonuspenalty-based-time-management

Hope it helps.

Best,
Ihor

Re: org-insert-heading-before-current

[Ihor Radchenko]

Tyler Grinn  writes:

> In general, I like to order my headings from newest to oldest top to
> bottom. I'm looking for a function which will prepend a heading at the
> current level in the current subtree. Some examples:
>
>
>   * Subtree  * Subtree
>   ** Item 2  >>> ** |
>   ** Item 1| ** Item 2
>  ** Item 1

One can implement this using prefix arguments for org-insert-heading.
Similar to the existing C-u and C-u C-u arguments (see the docstring of
org-insert-heading).

Patches are welcome. (If you find this feature sufficiently important,
feel free to implement this new functionality and submit the patch)

Best,
Ihor

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Dr. Arne Babenhauserheide]

Richard Stallman  writes:

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > "Note: To be PCI compliant, you must load Stripe.js directly from
>   > https://js.stripe.com. You cannot include it in a bundle or host
>   > it yourself. This package wraps the global Stripe function
>   > provided by the Stripe.js script as an ES module."
>
> That is hard for me to understand, since I don't know what "PCI
> compliant" means (or who is expected to comply with "PCI" or why).

PCI compliance is a requirement by the credit card industry: 
https://www.investopedia.com/terms/p/pci-compliance.asp

Companies that follow and achieve the Payment Card Industry Data Security 
Standards (PCI DSS) are considered to be PCI compliant.
The PCI Security Standards Council is responsible for developing the PCI 
DSS.
PCI DSS has 12 key requirements, 78 base requirements, and 400 test 
procedures to ensure that organizations are PCI compliant.
Being PCI compliant reduces data breaches, protects the data of 
cardholders, avoids fines, and improves brand reputation.
PCI compliance is not required by law but is considered mandatory through 
court precedent.

> Also, what is a "ES module" and what are the implications of that?

ES module (EcmaScript modules) is just the term for the module system in
Javascript.
https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/

> I wonder if users could run the free version of that JS code
> while talking with Stripe.

You could try replacing it in your browser.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature