Re: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Juan Manuel Macías]

Pedro Andres Aranda Gutierrez writes:

> I agree it does not take advantage of the AUTO facility here, but I
> nevertheless think it would
> be interesting to show people how to do this. Until we expand the AUTO
> facility to cope with
> all quirks of multi-language in pdflatex (lualatex and xetex are a
> different pair of shoes), a quick
> and dirty alternative may be helpful for people. The introductory text
> could be

Pedro, the only problem I see with that is that it is an example of
LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in
the entire section it's already made clear enough what it's used for.

Perhaps a brief reminder (the AUTO facility of the previous examples
is very limited) could be added first, and that if the users want to
obtain more complex, or more specific results (like the case you
exemplify for pdfLaTeX) they must put explicit LaTeX code, using
LaTeX_header. And then your example would come, but emphasizing that the
LaTeX documentation must be consulted. wdyt?

My point is that if we abuse examples of this type (at the expense of
"#+latex_header:something"), or "how is this done in LaTeX?", in the end
a LaTeX manual is made instead of Org.

I'm glad you enjoyed the jump to LuaTeX. :-)

Best regards,

Juan Manuel 


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: Inconsistent usage of "overview"

[Ihor Radchenko]

Carlos Pita  writes:

> I believe my confusion was due to the fact that the docstring of
> org-startup-folded is not particularly precise regarding to its
> possible values.

I improved the docstring on main. Hopefully, it can reduce the
confusion.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c2a58bbd5

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

org-contrib: Remove org-eval-light.el and org-evel.el

[Ihor Radchenko]

Hi,

According to https://orgmode.org/worg/org-contrib/#org4b339dd,
org-eval-lite "... is a reworking of Carsten's org-eval with the goals
of a more uniform syntax, safer default execution rules, and increased
ease of execution. Written by Eric Schulte. Link to raw file. This
modules has been superseded by the Org Babel functionality, which is
^^
part of the Org core and documented in the manual."

The same for org-eval.

Considering how long Org Babel is a part of Org core, it is probably the
time to remove org-eval-light and org-eval from org-contrib - they are
of no use.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Help: How to change faces of words between parenthesis

[Ypo]

Could it be possible to change the color of words between parentheses?

For example, in:

"mejorar su bienestar psicológico (Cronin et al., 2012; Molero, Fuster, 
Jetten y Moriano, 2011; Outten, Schmitt, García y Branscombe, 2009; 
Pérez-Garín et al., 2016)."


I would like that this part changes into a lighter color, so it doesn't 
distract me when reading:


"(Cronin et al., 2012; Molero, Fuster, Jetten y Moriano, 2011; Outten, 
Schmitt, García y Branscombe, 2009; Pérez-Garín et al., 2016)"



Best regards

How to downgrade from the last orgmode version to a stable version

[Ypo]

Hi

I am using Org mode version 9.7-pre (release_N/A-N/A-afc529 @ 
./.emacs.d/elpa/org-9.7pre0.20240130.161905/)


But I receive several error messages and problems with several packages, 
for example after a swiper search, the headline doesn't unfold. Today, 
Vertico has stopped working while in an Emacs session.


If I try to delete the 9.7-pre version, I can't : "package-delete: 
Package ‘org-9.7pre0.20240130.161905’ is used by ‘ox-pandoc’ as 
dependency, not deleting"



What would be the correct way to go back to a stable org version?

Best

Re: Help: How to change faces of words between parenthesis

[Ihor Radchenko]

Ypo  writes:

> Could it be possible to change the color of words between parentheses?
>
> For example, in:
>
> "mejorar su bienestar psicológico (Cronin et al., 2012; Molero, Fuster, 
> Jetten y Moriano, 2011; Outten, Schmitt, García y Branscombe, 2009; 
> Pérez-Garín et al., 2016)."
>
> I would like that this part changes into a lighter color, so it doesn't 
> distract me when reading:

(defun yant/apply-custom-faces ()
  (add-to-list 'org-font-lock-extra-keywords '("([^)]+)" . (0 
'font-lock-comment-face prepend)) 'append))
(add-hook 'org-font-lock-set-keywords-hook #'yant/apply-custom-faces)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to downgrade from the last orgmode version to a stable version

[Ihor Radchenko]

Ypo  writes:

> If I try to delete the 9.7-pre version, I can't : "package-delete: 
> Package ‘org-9.7pre0.20240130.161905’ is used by ‘ox-pandoc’ as 
> dependency, not deleting"
>
> What would be the correct way to go back to a stable org version?

Just delete it manually from elpa folder.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Add two new header args to LaTeX block

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> Considering that 'imagemagick is one of the variants in
>> `org-preview-latex-process-alist', it might be reasonable to allow
>> :process imagemagick == :imagemagick yes
>
> I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
> Instead, «:process 'imagemagick» depends on:
>
> (imagemagick :programs
> ...

Agree.

>> Also, it feels incomplete to be able to define latex command for :file
>> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
>
> The ".png" method without ":imagemagick" does not depend on
> 'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
> depends on the value of 'org-preview-latex-default-process':
> ...
> If you put :file foo.png without :imagemagick, and want to control the
> process or change the compiler, you can do it with:
>
> :process '(foo :latex-compiler ("some LaTeX command")) 
>
> since this syntax is what org-preview-latex-default-process expects.
>
> In all other cases, including :imagemagick, the compilation process
> depends on the value of org-latex-pdf-process.

Got it.
Although, it is confusing to have different formats of :process
value depending on :file extension.

It would make things easier for users if
:results file :file foo.png :process '("lualatex -interaction nonstopmode
-output-directory %o %f")

worked as expected, automatically overriding :latex-compiler value in
let-bound `org-preview-latex-process-alist'.

> Anyway, I don't understand why that feature option (convert to an image
> without :imagemagick method) is limited to .png, when other graphic files are
> possible. I can define something like this:
>
> (setq org-preview-latex-default-process
>   '(my-process
>   :programs ("lualatex" "convert")
>   :description "pdf > jpg"
>   :image-input-type "pdf"
>   :image-output-type "jpg"
>   :latex-compiler ("lualatex -interaction nonstopmode -output-directory 
> %o %f")
>   :image-converter ("convert -density %D -trim -antialias %f -quality 100 
> %O")))
>
> But if I put :file foo.jpg nothing happens. Maybe that part should be
> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?

I agree that it should be corrected.
Moreover, it would be nice to unify handling .png and imagemagick
branches of the code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-ctags: When `ido-mode' is off, use completing-read

[Ihor Radchenko]

Martin Marshall  writes:

> Here's another patch for org-ctags.el.
>
> `org-ctags-find-tag-interactive' uses `ido-completing-read' for
> selecting and jumping to a target.
>
> This patch makes it use `completing-read' instead, unless the user
> enabled `ido-mode'.

Thanks!
I applied an alternative patch, completely removing calls to ido-mode.
We are not supposed to use it at all (completing-read should be able to
do it on its own) after
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fdbf441560

Handled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org may fetch remote content without asking user consent

[Max Nikulin]

On 08/02/2024 22:07, Ihor Radchenko wrote:

Max Nikulin writes:

Max Nikulin writes:


Browsers
have concept of same origin for applying security and privacy measures.


Consider a file opened as /ssh:host:org/test.org that has

#+setupfile: /ssh:host:org/include.org

Formally it is a remote file, actually it resides on the same host as
the current document. Perhaps user consent is redundant.


`org--safe-remote-resource-p' checks the containing Org file as well, in
addition to #+included URL.


If my reading of the code is correct then it considers 
/ssh:host:org/include.org as safe if file:///ssh:host:org/test.org is 
added to `org-safe-remote-resources'. I was considering a case when 
there is no matching entry in `org-safe-remote-resources'. The user 
opens (C-x C-f) /ssh:host:org/test.org and likely it is enough to 
consider /ssh:host:org/include.org safe as well due to the same origin 
"/ssh:host:".



I am not confident in proper policy though. When some URI matches a
pattern in the safe list, likely it is suitable for files created by the
user and it is not really safe to allow it for a mail message attachment.


May you elaborate?


Consider a user that has "#+include:" loaded from their own public 
repository and used for some babel computations. It is safe when 
included into user's files. I am not sure that it is safe for an org 
file opened through a link in the browser. Perhaps it is better to avoid 
included files in `org-safe-remote-resources' and add local directories 
there.

[PATCH] org-ctags: Fix regexp to not break radio targets

[Martin Marshall]

>From 9b9e8ead6c175c76e4f37273a4e4f29b8e41b4f9 Mon Sep 17 00:00:00 2001
From: Martin Marshall 
Date: Sun, 11 Feb 2024 12:36:46 -0500
Subject: [PATCH] org-ctags: Fix regexp to not break radio-target links

* org-ctags.el (org-ctags-tag-regexp): Add left angle-bracket to
excluded characters for tag text.
---
 lisp/org-ctags.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el
index e56ed9cd8..6431a2765 100644
--- a/lisp/org-ctags.el
+++ b/lisp/org-ctags.el
@@ -149,7 +149,7 @@
 (defvar org-ctags-enabled-p t
   "Activate ctags support in org mode?")
 
-(defvar org-ctags-tag-regexp "/<<([^>]+)>>/\\1/d,definition/"
+(defvar org-ctags-tag-regexp "/<<([^<>]+)>>/\\1/d,definition/"
   "Regexp expression used by ctags external program.
 The regexp matches tag destinations in Org files.
 Format is: /REGEXP/TAGNAME/FLAGS,TAGTYPE/
-- 
2.39.2

This updates `org-ctags-tag-regexp' to avoid adding broken entries for
radio targets in the TAGS file.

With the old regexp, org-ctags would add radio targets to the TAGS file
with an extra angle bracket at the beginning.  So a target of
"<<>>" would be entered in the TAGS file as
"

Re: [patch] Add two new header args to LaTeX block

[Juan Manuel Macías]

Ihor Radchenko writes:

> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.

Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...

The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).

The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):

TeX file --> compilation --> PDF --> conversion --> image file

The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:

TeX file --> {compilation + PDF + conversion + params.} --> image file

That is, the compilation and conversion processes along with the
parameters are included in the same pack.

> It would make things easier for users if
> :results file :file foo.png :process '("lualatex -interaction nonstopmode
> -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.

I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts

":process '(luatex etc ...)"

he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.

>> Anyway, I don't understand why that feature option (convert to an image
>> without :imagemagick method) is limited to .png, when other graphic files are
>> possible. I can define something like this:
>>
>> (setq org-preview-latex-default-process
>>   '(my-process
>>  :programs ("lualatex" "convert")
>>  :description "pdf > jpg"
>>  :image-input-type "pdf"
>>  :image-output-type "jpg"
>>  :latex-compiler ("lualatex -interaction nonstopmode -output-directory 
>> %o %f")
>>  :image-converter ("convert -density %D -trim -antialias %f -quality 100 
>> %O")))
>>
>> But if I put :file foo.jpg nothing happens. Maybe that part should be
>> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." 
>> out-file)?
>
> I agree that it should be corrected.
> Moreover, it would be nice to unify handling .png and imagemagick
> branches of the code.

I agree. In any case, I still think that the coexistence of two methods
to convert to images, when one of the methods has a scheme so different
from the rest, becomes difficult: for the user as well as for
maintaining the code.

The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inconveniences. We should see
what more users think.

Another possibility is to clarify the names a little more (for the user):

:image-conv [possible values: default, imagemagick (= :imagemagick yes)]

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Retaking AUTO for \usepackage{fontenc}

[Pedro Andres Aranda Gutierrez]

HI again,

I'm trying to put together all pieces for this before I actually write code.

After looking at the current state, I would be lenient to include an
additional optional property to `org-latex-language-alist' I would directly
call `:fontenc'.

\usepackage[AUTO]{fontenc}
would then take it to replace AUTO. If this property is not present, the
default value would be T1.

Opinions?

Thx, /PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet