Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Jun Inoue]

Super!  ;)

2024年9月4日(水) 9:18 Karthik Chikmagalur :

> Jun, thank you for the detailed explanation and fix.
>
> > * Cause
> > This is because org-latex-preview:
> > 1. Runs dvisvgm in the same directory as the .org file, and
> > 2. Tells dvisvgm to report the output SVG file names as relative paths
> > using ?svgfile, but
> > 3. Then expands those file names under temporary-file-directory in
> > org-latex-preview--dvisvgm-filter.
> >
> > So dvisvgm relativizes in one path, then org-latex-preview expands in
> > another.
> >
>
> I had gathered from other repors that this was the issue, but I didn't
> know how to fix it as I don't have dvisvgm 3.2 available yet.  Scanning
> the man page for dvisvgm 3.0.3 didn't give me any hits for `svgfile'.
>
> The fix looks very simple, we'll apply it.
>
> Karthik
>

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

Jun, thank you for the detailed explanation and fix.

> * Cause
> This is because org-latex-preview:
> 1. Runs dvisvgm in the same directory as the .org file, and
> 2. Tells dvisvgm to report the output SVG file names as relative paths
> using ?svgfile, but
> 3. Then expands those file names under temporary-file-directory in
> org-latex-preview--dvisvgm-filter.
>
> So dvisvgm relativizes in one path, then org-latex-preview expands in
> another.
>

I had gathered from other repors that this was the issue, but I didn't
know how to fix it as I don't have dvisvgm 3.2 available yet.  Scanning
the man page for dvisvgm 3.0.3 didn't give me any hits for `svgfile'.

The fix looks very simple, we'll apply it.

Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Jun Inoue]

Yaroslav, I had a similar issue.  The problem there was that the relative
path
../../../../var/folders/3m/9xzpnkks773bfdwzqlvr421rgn/T/org-tex-BYOo4y-1.svg
was being expanded in the wrong directory.  Can you see if the problem
reproduces with the attached patch?  (You could also just find the string
"{?svgfile}" in (alist-get 'dvisvgm org-latex-preview-process-alist) and
replace it with "{?svgpath}".


Here's a copy of the email I sent to this list regarding the issue.  It
seems to have fallen through the cracks, so it would be great if someone
could have a look, independently of Yaroslav's issue if it turns out to be
different.

Recently, the previews stopped working after a system update.

* Symptom
On macOS with dvisvgm 3.2+, org-latex-preview can't typeset LaTeX fragments
at all in a lot of files.  It gives an error like the following:

error in process filter: Opening input file: No such file or directory,
/var/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T/org-tex-ZqKlQw-1.svg
[2 times]

** Steps to Reproduce
Put dvisvgm 3.2+ on your path and create a .org file anywhere outside
temporary-file-directory that is shallower than (i.e. has fewer slashes
than) temporary-file-directory.  Try to preview any LaTeX fragment in that
file.

This should theoretically reproduce on non-macOS, but macOS has an
especially deep temporary-file-directory that looks like
/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmg, making it easier to
reproduce.  If temporary-file-directory is /tmp on your system, I think you
have to make the .org file in the root directory or change
temporary-file-directory to a deeper directory (haven't tried).

* Cause
This is because org-latex-preview:
1. Runs dvisvgm in the same directory as the .org file, and
2. Tells dvisvgm to report the output SVG file names as relative paths
using ?svgfile, but
3. Then expands those file names under temporary-file-directory in
org-latex-preview--dvisvgm-filter.

So dvisvgm relativizes in one path, then org-latex-preview expands in
another.

For instance, if I try to typeset fragments in /Users/jun/org/test/test.org,
then dvisvgm reports:

output written to:
../../../../var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T/org-tex-CWRtgi-1.svg

where /var/folders/8g... is the absolute path of the output file.  This is
expanded under temporary-file-directory, which is
/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T, leading org-latex-preview
to busy-wait for files to arrive in
/var/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T.

I think this is hard to reproduce on most non-macOS systems where the
temporary-file-directory is shallow.  ?svgfile contains as many ../ as
there are slashes in the directory hosting the .org file, and expanding
that relative to (say) /tmp will effectively remove all those ../, making
it expand to the correct absolute path by accident.

* Fix
Use ?svgpath instead of ?svgfile.  Here's a patch that applies to commit
9584a76a843e2e8122799e5653bb9120fe568f64 of [[
https://git.tecosaur.net/tec/org-mode.git]].

modified   lisp/org-latex-preview.el
@@ -200,7 +200,7 @@ Place-holders only used by `:image-converter':
  (list
   (concat "dvisvgm --page=1- --optimize --clipjoin
--relative --no-fonts"
   (if (>=
org-latex-preview--dvisvgm3-minor-version 2)
-  " -v3 --message='processing page {?pageno}:
output written to {?svgfile}'" "")
+  " -v3 --message='processing page {?pageno}:
output written to {?svgpath}'" "")
   " --bbox=preview -o %B-%%9p.svg %f"))

 (defcustom org-latex-preview-compiler-command-map
@@ -2792,7 +2792,7 @@ EXTENDED-INFO, and displayed in the buffer."
 (when (save-excursion
 (re-search-forward "output written to \\(.*.svg\\)$" end
t))
   (setq fragment-info (nth (1- page) fragments))
-  (plist-put fragment-info :path (expand-file-name (match-string
1) temporary-file-directory))
+  (plist-put fragment-info :path (match-string 1))
   (when (save-excursion
   (re-search-forward "^  page is empty" end t))
 (unless (plist-get fragment-info :error)

** Environment
GNU Emacs 29.1 (build 1, aarch64-apple-darwin21.6.0, Carbon Version 165
AppKit 2113.6) of 2023-08-09 (Brew tap railwaycat emacs-mac)

dvisvgm 3.2.2

On Wed, Sep 4, 2024 at 12:51 AM Karthik Chikmagalur <
karthikchikmaga...@gmail.com> wrote:

> >> Sorry for delay.
> >>
> >> 1. pdflatex
> >> 2. processing page 1: output written to
> ../../../../var/folders/3m/9xzpnkks773bfdwzqlvr421rgn/T/org-tex-BYOo4y-1.svg
> >> 3. nil
> >
> > Karthik, any thoughts?
> >
>
> It will be useful to know if that svg exists at that path.  I've had
> reports from other Mac users complaining about dvisvgm reporting the wrong
> path.
>
> Karthik
>
>

-- 
Jun Inoue

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

>> Sorry for delay.
>>
>> 1. pdflatex
>> 2. processing page 1: output written to 
>> ../../../../var/folders/3m/9xzpnkks773bfdwzqlvr421rgn/T/org-tex-BYOo4y-1.svg
>> 3. nil
>
> Karthik, any thoughts?
>

It will be useful to know if that svg exists at that path.  I've had reports 
from other Mac users complaining about dvisvgm reporting the wrong path.

Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Yaroslav Drachov  writes:

> Sorry for delay.
>
> 1. pdflatex
> 2. processing page 1: output written to 
> ../../../../var/folders/3m/9xzpnkks773bfdwzqlvr421rgn/T/org-tex-BYOo4y-1.svg
> 3. nil

Karthik, any thoughts?

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Jun Inoue]

Hi there!  I've been using this excellent overhaul ever since it came out,
and I'd like to contribute a bug fix. I hope replying to this thread is the
right way to do that; if not, please let me know.

Recently, the previews stopped working after a system update.

* Symptom
On macOS with dvisvgm 3.2+, org-latex-preview can't typeset LaTeX fragments
at all in a lot of files.  It gives an error like the following:

error in process filter: Opening input file: No such file or directory,
/var/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T/org-tex-ZqKlQw-1.svg
[2 times]

** Steps to Reproduce
Put dvisvgm 3.2+ on your path and create a .org file anywhere outside
temporary-file-directory that is shallower than (i.e. has fewer slashes
than) temporary-file-directory.  Try to preview any LaTeX fragment in that
file.

This should theoretically reproduce on non-macOS, but macOS has an
especially deep temporary-file-directory that looks like
/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmg, making it easier to
reproduce.  If temporary-file-directory is /tmp on your system, I think you
have to make the .org file in the root directory or change
temporary-file-directory to a deeper directory (haven't tried).

* Cause
This is because org-latex-preview:
1. Runs dvisvgm in the same directory as the .org file, and
2. Tells dvisvgm to report the output SVG file names as relative paths
using ?svgfile, but
3. Then expands those file names under temporary-file-directory in
org-latex-preview--dvisvgm-filter.

So dvisvgm relativizes in one path, then org-latex-preview expands in
another.

For instance, if I try to typeset fragments in /Users/jun/org/test/test.org,
then dvisvgm reports:

output written to:
../../../../var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T/org-tex-CWRtgi-1.svg

where /var/folders/8g... is the absolute path of the output file.  This is
expanded under temporary-file-directory, which is
/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T, leading org-latex-preview
to busy-wait for files to arrive in
/var/var/folders/8g/k689fc1j3gg2ny7xrzqchjsmgn/T.

I think this is hard to reproduce on most non-macOS systems where the
temporary-file-directory is shallow.  ?svgfile contains as many ../ as
there are slashes in the directory hosting the .org file, and expanding
that relative to (say) /tmp will effectively remove all those ../, making
it expand to the correct absolute path by accident.

* Fix
Use ?svgpath instead of ?svgfile.  Here's a patch that applies to commit
9584a76a843e2e8122799e5653bb9120fe568f64 of [[
https://git.tecosaur.net/tec/org-mode.git]].

modified   lisp/org-latex-preview.el
@@ -200,7 +200,7 @@ Place-holders only used by `:image-converter':
  (list
   (concat "dvisvgm --page=1- --optimize --clipjoin
--relative --no-fonts"
   (if (>=
org-latex-preview--dvisvgm3-minor-version 2)
-  " -v3 --message='processing page {?pageno}:
output written to {?svgfile}'" "")
+  " -v3 --message='processing page {?pageno}:
output written to {?svgpath}'" "")
   " --bbox=preview -o %B-%%9p.svg %f"))

 (defcustom org-latex-preview-compiler-command-map
@@ -2792,7 +2792,7 @@ EXTENDED-INFO, and displayed in the buffer."
 (when (save-excursion
 (re-search-forward "output written to \\(.*.svg\\)$" end
t))
   (setq fragment-info (nth (1- page) fragments))
-  (plist-put fragment-info :path (expand-file-name (match-string
1) temporary-file-directory))
+  (plist-put fragment-info :path (match-string 1))
   (when (save-excursion
   (re-search-forward "^  page is empty" end t))
 (unless (plist-get fragment-info :error)

** Environment
GNU Emacs 29.1 (build 1, aarch64-apple-darwin21.6.0, Carbon Version 165
AppKit 2113.6) of 2023-08-09 (Brew tap railwaycat emacs-mac)

dvisvgm 3.2.2

On Sun, Mar 12, 2023 at 9:35 PM Timothy  wrote:

> Hi All,
>
> After months of work, Karthink and I have prepared a rather large patch-set
> completely overhauling the LaTeX preview system. I hope to have a patch set
> shortly, but in the mean time it would be good to get some more people
> testing
> this.
>
> To test this feature, please check out the `dev' branch of
>  (it’s the default branch).
> There are
> also some other changes there currently, but I don’t think anything is
> broken.
>
> You can view the almost-ready path set/diff here:
> , see the
> ORG-NEWS and org-manual entries to get a bit more of an idea of what’s
> changed.
> The short version is that now:
> • Previews are generated in bulk, and hundreds of LaTeX fragments can be
> processed per second.
> • Images are placed continuously as they are generated.
> • Preview generation is asynchronous and will not block Emacs.
> • Inline previews are al

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Yaroslav Drachov]

Hi,

Sorry for delay.

1. pdflatex
2. processing page 1: output written to 
../../../../var/folders/3m/9xzpnkks773bfdwzqlvr421rgn/T/org-tex-BYOo4y-1.svg
3. nil

Best wishes,
Yaroslav

> 26 июня 2024 г., в 22:05, Karthik Chikmagalur  
> написал(а):
> 
> I don't see anything wrong in the diagnostic information you've
> provided.  Here are some more questions for you.
> 
> 1. What is your org-latex-compiler set to?
> 
> 2. Could you try to use dvisvgm to generate previews, and when it fails,
> check the contents of the buffer "*Org Preview Convert Output*"?  You
> can include it with your reply.
> 
> 3. Disable hl-line-mode if you use it, then move the cursor into one of
> the LaTeX fragments and run the following using M-x eval-expression:
> 
> (overlay-get (car (overlays-at (point))) 'preview-image)
> 
> If it returns an svg file path, could you open that file and check if
> the svg is being generated as expected?  If it returns nil, that will be
> useful to know as well.
> 
> Karthik
> 
> 
> Yaroslav Drachov  writes:
> 
>> Not yet.
>> 
>> Best wishes,
>> Yaroslav
>> 
>>> 23 июня 2024 г., в 13:53, Ihor Radchenko  написал(а):
>>> 
>>> Yaroslav Drachov  writes:
>>> 
 My system-configuration-features are
 
 "ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
 PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP 
 XIM XWIDGETS ZLIB".
 
 RSVG is in the list.
 
 org-latex-preview-check-health diagnostic info:
 ...
>>> 
>>> May I know if this problem has been resolved?
>>> 
>>> -- 
>>> Ihor Radchenko // yantar92,
>>> Org mode contributor,
>>> Learn more about Org mode at .
>>> Support Org development at ,
>>> or support my work at 

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

I don't see anything wrong in the diagnostic information you've
provided.  Here are some more questions for you.

1. What is your org-latex-compiler set to?

2. Could you try to use dvisvgm to generate previews, and when it fails,
check the contents of the buffer "*Org Preview Convert Output*"?  You
can include it with your reply.

3. Disable hl-line-mode if you use it, then move the cursor into one of
the LaTeX fragments and run the following using M-x eval-expression:

(overlay-get (car (overlays-at (point))) 'preview-image)

If it returns an svg file path, could you open that file and check if
the svg is being generated as expected?  If it returns nil, that will be
useful to know as well.

Karthik


Yaroslav Drachov  writes:

> Not yet.
>
> Best wishes,
> Yaroslav
>
>> 23 июня 2024 г., в 13:53, Ihor Radchenko  написал(а):
>> 
>> Yaroslav Drachov  writes:
>> 
>>> My system-configuration-features are
>>> 
>>> "ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
>>> PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP 
>>> XIM XWIDGETS ZLIB".
>>> 
>>> RSVG is in the list.
>>> 
>>> org-latex-preview-check-health diagnostic info:
>>> ...
>> 
>> May I know if this problem has been resolved?
>> 
>> -- 
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Yaroslav Drachov]

Not yet.

Best wishes,
Yaroslav

> 23 июня 2024 г., в 13:53, Ihor Radchenko  написал(а):
> 
> Yaroslav Drachov  writes:
> 
>> My system-configuration-features are
>> 
>> "ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
>> PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP 
>> XIM XWIDGETS ZLIB".
>> 
>> RSVG is in the list.
>> 
>> org-latex-preview-check-health diagnostic info:
>> ...
> 
> May I know if this problem has been resolved?
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Yaroslav Drachov  writes:

> My system-configuration-features are
>
> "ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
> PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP 
> XIM XWIDGETS ZLIB".
>
> RSVG is in the list.
>
> org-latex-preview-check-health diagnostic info:
> ...

May I know if this problem has been resolved?

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[ Sorry, I do not have a better starting point for this.  ]

After updating Latex, I got the message:

Creating LaTeX preview images failed (exit code 252). Please see *Org 
Preview LaTeX Output* for details

which corresponds to

RUNNING: latex -interaction nonstopmode -output-directory /tmp/ 
/home/viz/doc/uni/notes/org-tex-KByBIT.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2025/dev/Debian) 
(preloaded 
format=/home/viz/.cache/org-persist/70/4b50e3-c1f1-4ed9-be3a-acf259bf6d3d-54035ced5d211d19e0eec7be4671c146)
 restricted \write18 enabled.
---! 
/home/viz/.cache/org-persist/70/4b50e3-c1f1-4ed9-be3a-acf259bf6d3d-54035ced5d211d19e0eec7be4671c146.fmt
 made by different executable version, strings are different
(Fatal format file error; I'm stymied)

Would it be possible to give a more informative message for this case?
It is not a showstopper since the error message by pdfTeX is informative
enough but something more informative from Org would be nice regardless.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Корякин Артём]

Max Nikulin  writes:

> On 19/04/2024 00:58, Корякин Артём wrote:
>>>  shell-file-name
>> ; "pwsh.exe"
>>>  system-type
>> ; windows-nt
>>>  (w32-shell-dos-semantics)
>> ; nil
>
> I have no idea what style of escaping is expected by pwsh.exe. If it
> is the same as for cmd.exe then I would try to add it to
> `w32-system-shells' and would file a bug report against emacs with
> links to docs. However pwsh.exe as a shell may require dedicated
> support in Emacs (it it does not lead to other issues).
>
> See emacs sources for details.

Thanks. I removed that part of the config that sets pwsh.exe as
shell-file-name and now latex-previews works without any problems and
necessity to run workaround.

I am sorry. It was my fault all way around.

>> and removed shell-quote-argument from org-fc functions[4].
>
> It is no go. Improper escaping leads to vulnerabilities like

I get it. I understand that something like that only can be a temporary
local solution.

> you dropped my address in the second copy I would not receive a duplicate.

>> I don't know how to do this automatically from gnus unfortunately.
> I am not a Gnus user. Perhaps it has reply to list and reply to all
> actions. Unfortunately the message composed in gmail lacks In-Reply-To
> and Reference headers, and it causes broken thread.

I am sorry again.
Gnus has post follow up on article button and
gnus-summary-wide-reply[-with-original] commands. I tried the former

Best regards, Artsiom.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Max Nikulin]

On 19/04/2024 00:58, Корякин Артём wrote:

 shell-file-name

; "pwsh.exe"

 system-type

; windows-nt

 (w32-shell-dos-semantics)

; nil


I have no idea what style of escaping is expected by pwsh.exe. If it is 
the same as for cmd.exe then I would try to add it to 
`w32-system-shells' and would file a bug report against emacs with links 
to docs. However pwsh.exe as a shell may require dedicated support in 
Emacs (it it does not lead to other issues).


See emacs sources for details.


and removed shell-quote-argument from org-fc functions[4].


It is no go. Improper escaping leads to vulnerabilities like

https://security-tracker.debian.org/tracker/CVE-2023-28617
"org-babel-execute:latex in ob-latex.el in Org Mode through 9.6.1 for 
GNU Emacs allows attackers to execute arbitrary commands via a file name 
or directory name that contains shell metacharacters."



Sorry for resending this message again. > I forgot to add CC to mailing list.


I you dropped my address in the second copy I would not receive a duplicate.


I don't know how to do this automatically from gnus unfortunately.
I am not a Gnus user. Perhaps it has reply to list and reply to all 
actions. Unfortunately the message composed in gmail lacks In-Reply-To 
and Reference headers, and it causes broken thread.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Корякин Артём]

Max Nikulin  writes:

> Please, evaluate the following expressions e.g. in the scratch buffer:
>
> shell-file-name
; "pwsh.exe"
> system-type
; windows-nt
> (w32-shell-dos-semantics)
; nil
> (w32-shell-name)
; "pwsh.exe"


For clarification:
I specifically configured[1] MS pwsh as default shell for emacs when I
was trying to get org-fc working[2]. I get some progress back then, but
in the end I just installed busybox using scoop[3] and removed
shell-quote-argument from org-fc functions[4].


> On Windows `shell-quote-argument' should use an escaping strategy
> quite different from POSIX systems. Disclaimer: I do not have a
> Windows box, so it is unlikely that I could help with further
> steps. Perhaps other functions should be used to deal with file names.

> Windows box

I need this laptop to run windows, because pirated CAD programms that I
need for studying would run only on Windows.
I also use emacs for studying and I plan to eventually switch to
KiCAD and freecad on the free operating system.

> Perhaps other functions should be used to deal with file names.

I will try to replace two functions that Karthik mentioned
org-latex-preview--tex-compile-async
org-latex-preview--image-extract-async
with their corresponding versions without shell-quote-argument.

But you also gave me another idea:
I could try to set default shell for emacs to sh that comes from
installed busybox package.

If there is an issue with shell-quote-argument behaving on windows like
on POSIX system, than it might be logical to try to launch these
commands using POSIX shell. 

[1]:https://github.com/artsi0m/emacs-organizer/tree/1e1bac13b0f845cb622db08759b9e14fe35fcae7?tab=readme-ov-file#set-powershell-to-default-shell-on-windows


[2]: https://todo.sr.ht/~l3kn/org-fc/43#event-334320
[3]: https://scoop.sh
[4]: 
https://github.com/artsi0m/emacs-organizer/tree/1e1bac13b0f845cb622db08759b9e14fe35fcae7?tab=readme-ov-file#org-fc-awkfind-on-windows

Sorry for resending this message again.
I forgot to add CC to mailing list.
I don't know how to do this automatically from gnus unfortunately.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Корякин Артём]

Karthik Chikmagalur  writes:

> As a temporary measure, could you try replacing calls to
> shell-quote-argument with identity in the following two functions?
>
> org-latex-preview--tex-compile-async
> org-latex-preview--image-extract-async

I did[1] exactly this. It works, but only if I eval it manually after
loading emacs, even if I will load it using (org-babel-load-file) from
init before. But I think it is enough for today and for workaround type
of temporary solution.

I might need an advice where to go next to solve problem with
(shell-quote-argment) i.e. to which mailing lists I should subscribe to
work on patch and send it one day.

I think I will also try to remove part of my config where I will change
default shell and see if running with default configuration brings any
changes, because comment on this function in subr.el says that it may
missbehave with unusual shells.

Also, my idea to set emacs shell-file-name to busybox sh didn't worked
out, but I wasn't sure about it anyway.

Thanks a lot for the patience.

[1]: 
https://github.com/artsi0m/emacs-organizer/blob/1a1463da6e54b29af071b721e992295a9d24dec9/org-latex-preview-workaround.org

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Yaroslav Drachov]

My system-configuration-features are

"ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS 
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM 
XWIDGETS ZLIB".

RSVG is in the list.

org-latex-preview-check-health diagnostic info:

(:image-converters (("convert" "Version: ImageMagick 7.1.1-29 Q16-HDRI x86_64 
21991 https://imagemagick.org"; "/usr/local/bin/convert") ("dvisvgm" "dvisvgm 
3.2.2" "/Library/TeX/Distributions/Programs/texbin/dvisvgm") ("dvipng" "This is 
dvipng 1.17 Copyright 2002-2015, 2019 Jan-Ake Larsson" 
"/Library/TeX/Distributions/Programs/texbin/dvipng")) :latex-processors 
(("lualatex" "This is LuaHBTeX, Version 1.18.0 (TeX Live 2024)" 
"/Library/TeX/Distributions/Programs/texbin/lualatex") ("xelatex" "XeTeX 
3.141592653-2.6-0.96 (TeX Live 2024)" 
"/Library/TeX/Distributions/Programs/texbin/xelatex") ("pdflatex" "pdfTeX 
3.141592653-2.6-1.40.26 (TeX Live 2024)" 
"/Library/TeX/Distributions/Programs/texbin/pdflatex")) :interactive t 
:org-version "9.7-pre" :modified ((org-latex-preview-appearance-options 
:foreground auto :background "Transparent" :scale 1.6 :zoom 1.2 :page-width 0.8 
:matchers ("begin" "$1" "$" "$$" "\\(" "\\[")) (org-persist-after-read-hook 
org-element--cache-persist-after-read) (org-latex-engraved-theme . 
modus-operandi) (org-latex-minted-langs (jupyter-Wolfram\ Language "Wolfram 
Language") (jupyter-python "python") (emacs-lisp "common-lisp") (cc "c++") 
(cperl "perl") (shell-script "bash") (caml "ocaml")) 
(org-persist-before-read-hook org-element--cache-persist-before-read) 
(org-latex-format-drawer-function . #[514 "\207" [] 3 "

(fn _ CONTENTS)"]) (org-latex-format-headline-function . 
org-latex-format-headline-default-function) (org-latex-preview-live-debounce . 
0.25) (org-latex-preview-process-alist (dvipng :programs ("latex" "dvipng") 
:description "dvi > png" :message "you need to install the programs: latex and 
dvipng." :image-input-type "dvi" :image-output-type "png" :latex-compiler ("%l 
-interaction nonstopmode -output-directory %o %f") :latex-precompiler ("%l 
-output-directory %o -ini -jobname=%b \"&%L\" mylatexformat.ltx %f") 
:image-converter ("dvipng --follow -D %D -T tight --depth --height -o 
%B-%%09d.png %f") :transparent-image-converter ("dvipng --follow -D %D -T tight 
-bg Transparent --depth --height -o %B-%%09d.png %f")) (dvisvgm :programs 
("latex" "dvisvgm") :description "dvi > svg" :message "you need to install the 
programs: latex and dvisvgm." :image-input-type "dvi" :image-output-type "svg" 
:latex-compiler ("%l -interaction nonstopmode -output-directory %o %f") 
:latex-precompiler ("%l -output-directory %o -ini -jobname=%b \"&%L\" 
mylatexformat.ltx %f") :image-converter ("dvisvgm --page=1- --optimize 
--clipjoin --relative --no-fonts -v3 --message='processing page {?pageno}: 
output written to {?svgfile}' --bbox=preview -o %B-%%9p.svg %f")) (imagemagick 
:programs ("pdflatex" "convert") :description "pdf > png" :message "you need to 
install the programs: latex and imagemagick." :image-input-type "pdf" 
:image-output-type "png" :latex-compiler ("pdflatex -interaction nonstopmode 
-output-directory %o %f") :latex-precompiler ("pdftex -output-directory %o -ini 
-jobname=%b \"&pdflatex\" mylatexformat.ltx %f") :image-converter ("convert 
-density %D -trim -antialias %f -quality 100 %B-%%09d.png"))) 
(org-latex-classes ("tikzposter" "\\documentclass[]{tikzposter}" 
("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" . "\\subsection*{%s}") 
("\\subsubsection{%s}" . "\\subsubsection*{%s}") ("\\paragraph{%s}" . 
"\\paragraph*{%s}") ("\\subparagraph{%s}" . "\\subparagraph*{%s}")) 
("extarticle" "\\documentclass[14pt]{extarticle}" ("\\section{%s}" . 
"\\section*{%s}") ("\\subsection{%s}" . "\\subsection*{%s}") 
("\\subsubsection{%s}" . "\\subsubsection*{%s}") ("\\paragraph{%s}" . 
"\\paragraph*{%s}") ("\\subparagraph{%s}" . "\\subparagraph*{%s}")) ("article" 
"\\documentclass[11pt]{article}" ("\\section{%s}" . "\\section*{%s}") 
("\\subsection{%s}" . "\\subsection*{%s}") ("\\subsubsection{%s}" . 
"\\subsubsection*{%s}") ("\\paragraph{%s}" . "\\paragraph*{%s}") 
("\\subparagraph{%s}" . "\\subparagraph*{%s}")) ("report" 
"\\documentclass[11pt]{report}" ("\\part{%s}" . "\\part*{%s}") ("\\chapter{%s}" 
. "\\chapter*{%s}") ("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" . 
"\\subsection*{%s}") ("\\subsubsection{%s}" . "\\subsubsection*{%s}")) ("book" 
"\\documentclass[11pt]{book}" ("\\part{%s}" . "\\part*{%s}") ("\\chapter{%s}" . 
"\\chapter*{%s}") ("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" . 
"\\subsection*{%s}") ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))) 
(org-latex-engraved-preamble . "\\usepackage{fvextra}

[FVEXTRA-SETUP]

% Make line numbers smaller and grey.
\\renewcommand\\theFancyVerbLine{\\footnotesize\\color{black!40!white}\\arabic{FancyVerbLine}}

\\usepackage{xcolor}

% In case engrave-faces-latex-gen-preamble has not been run.
\\providecolor{Ef

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> I hope I understand correctly how to use this mail-thread. Thank you
> very much for such a great enhancement of Org-mode LaTeX preview
> capabilities. I am on macOS Big Sur and have some troubles with
> dvisvgm preview in your particular fork. Everything works just fine in
> stable release of Org-mode, and in your release dvipng method work
> almost as expected. dvisvgm preview method actually generate svg’s in
> /var/folders/3m…, but don’t make an overlay after all and equation
> environments remain being formatted as text.

Quick check: 

1. Is your Emacs compiled with svg support? (on Linux, this means
system-configuration-features will include RSVG)
2. Could you run the function at
https://gist.github.com/karthink/0ac48411a81459c0f3fd7557c4e817db
and supply us with the results?  It should pop up a buffer with some
diagnostics pertaining to LaTeX previews.

Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Max Nikulin]

On 18/04/2024 03:11, Корякин Артём wrote:

Maybe I could somehow rewrite shell-quote-argument using advices ?
Maybe some more global changes is needed for emacs on windows ?


Please, evaluate the following expressions e.g. in the scratch buffer:

shell-file-name
system-type
(w32-shell-dos-semantics)
(w32-shell-name)

On Windows `shell-quote-argument' should use an escaping strategy quite 
different from POSIX systems. Disclaimer: I do not have a Windows box, 
so it is unlikely that I could help with further steps. Perhaps other 
functions should be used to deal with file names.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Корякин Артём]

I've got problem when I use this version of org-latex preview:

RUNNING: dvisvgm --page=1- --optimize --clipjoin --relative --no-fonts 
--bbox=preview -o c\:/Users/artsi0m/AppData/Local/Temp/org-tex-DAJVTr-%9p.svg 
c\:/Users/artsi0m/AppData/Local/Temp/org-tex-DAJVTr.dvi

ERROR: can't open file 
'c\:/Users/artsi0m/AppData/Local/Temp/org-tex-DAJVTr.dvi' for reading

As you can get from the traceback it is problem with windows. But I
remember solving simillar problem with org-fc already[1][2]. I just removed
escaping (quoting) from one of the elisp functions.

So, the main problem of the problem is that on Windows
(shell-quote-argument) function will quote c:/ as c\:/ which breaks
ability to find one or another file. It maybe other function with this
quoting, but I suppose that it is it.

Please, point me in the right direction to solve this problem.
Maybe I could somehow rewrite shell-quote-argument using advices ?
Maybe some more global changes is needed for emacs on windows ?

Thanks a lot for the patience and for reading this email.
Sorry for misspelling or grammar mistakes, english is not my mother tongue.

[1]:https://github.com/artsi0m/emacs-organizer/tree/1e1bac13b0f845cb622db08759b9e14fe35fcae7?tab=readme-ov-file#org-fc-awkfind-on-windows
[2]: https://todo.sr.ht/~l3kn/org-fc/43

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> I've got problem when I use this version of org-latex preview:
>
> RUNNING: dvisvgm --page=1- --optimize --clipjoin --relative --no-fonts 
> --bbox=preview -o c\:/Users/artsi0m/AppData/Local/Temp/org-tex-DAJVTr-%9p.svg 
> c\:/Users/artsi0m/AppData/Local/Temp/org-tex-DAJVTr.dvi
>
> ERROR: can't open file 
> 'c\:/Users/artsi0m/AppData/Local/Temp/org-tex-DAJVTr.dvi' for reading
>
> As you can get from the traceback it is problem with windows. But I
> remember solving simillar problem with org-fc already[1][2]. I just removed
> escaping (quoting) from one of the elisp functions.

Thank you for testing the new LaTeX preview system, we haven't had any
reports yet from Windows.

As a temporary measure, could you try replacing calls to
shell-quote-argument with identity in the following two functions?

org-latex-preview--tex-compile-async
org-latex-preview--image-extract-async

I'd be interested to know if it works as expected otherwise.

> So, the main problem of the problem is that on Windows
> (shell-quote-argument) function will quote c:/ as c\:/ which breaks
> ability to find one or another file. It maybe other function with this
> quoting, but I suppose that it is it.

shell-quote-argument is used all over Emacs, so I'm quite surprised it
mangles file paths on Windows.

Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Yaroslav Drachov]

Hello everyone,

I hope I understand correctly how to use this mail-thread. Thank you very much 
for such a great enhancement of Org-mode LaTeX preview capabilities. I am on 
macOS Big Sur and have some troubles with dvisvgm preview in your particular 
fork. Everything works just fine in stable release of Org-mode, and in your 
release dvipng method work almost as expected. dvisvgm preview method actually 
generate svg’s in /var/folders/3m…, but don’t make an overlay after all and 
equation environments remain being formatted as text.

Best wishes,
Yaroslav

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Matt,

Thanks for taking this branch for a spin and reporting back.

I’m a bit mystified by the difference you see between `$$' and `\(\)' 
delimiters (I
can’t detect any difference my end). Regarding the specific comments in your
last email though:

Matt Huszagh  writes:

> When using \(\) delimiters, using a depth adjustment of 0 (instead of
> 0.02) looks correct to me. I checked this by blowing up the fragment
> with a very large scale factor (eg 10) and then baseline misalignments
> become more obvious. This is how I ensured my baseline computation was
> correct when I wrote that patch aligning the baseline several years
> ago. I /think/ that’s a valid method, and I’ve been using my code for
> the last couple years and the baseline has always looked correct.
>
> Anyway, can you explain more why you came to the conclusion of that
> slight depth adjustment?

So, this minor correction factor came abound from blowing up the fontsize and
trying a number of combinations of fonts (as in the comment). The 0.02
correction isn’t a “best with computer modern” value, but a compromise between
the various values that seemed best for the common LaTeX maths fonts tested. A
value of 0.02 seemed to produce consistently good results across the range of
fonts.

This testing was done several months ago, so I forget the particular details,
but that is the methodology used. It’s entirely possible this could benefit from
some tweaking, I’d just like to see some high-res screenshots with a range of
fonts to help convince me that a chance is beneficial.

> Are you using $$ delimiters? That also appears> to produce other visual
> imperfections. For $F=ma$, I see the bottom of the “m” and “a” cut off
> slightly. I wonder why different delimiters produce different results.

I always use `\(\)' myself, but can’t see why that would affect the preview.

> I used> slightly different settings for dvisvgm in my implementation
> (including –exact-bbox). I wonder if that has any relevance…

It does. `--exact-bbox' is known to produce slightly dodgy results with recent
dvisvgm versions (and seems to behave differently on MacOS for some reason). Is
there a particular reason you changed the dvisvgm settings?

> I also used a different document class - standalone in preview mode.

Hmmm, I’m not sure if that could cause any issues.

> Now that I think about it, IIRC that was to address another corner case I ran
> into, which is that for large images, article will crop it before it gets to
> dvisvgm. It’s been a while since I did this and my memory is hazy, but I think
> that’s why I used standalone.

I wonder to what extend this can be resolved by just decreasing the
margins/increasing the page size.

> I can try to investigate that with a minimal issue.

That would be good :)

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Matt Huszagh]

Matt Huszagh  writes:

> Another minor issue I've encountered. Using different delimiters results
> in images of slightly different sizes.
>
> For example, in a file containing:
>
> ```
> Using first delimiters: \(F=ma\).
>
> Using other delimiters: $F=ma$.
> ```
>
> The snippet with dollar sign delimiters is slightly larger than the one
> using \(\).

The following code, where you compute the ascent value, seems relevant
to this observation:

;; The baseline seems to tend to sit slightly
;; lower than it should be, and a very mild
;; bias seems to improve the visual result.
;; From testing with a collecting of LaTeX
;; maths fonts (cm, cmbright, arev, pxfonts,
;; notomath, nextxsf, eulervm) decreacing the
;; depth measurement by 0.02pt in the baseline
;; calculation seems to work well.
;; I have yet to come across any situation
;; where this results in a negative depth,
;; however we may as well ensure that never
;; occurs.
(round (* 100 (- 1 (/ (max 0.0 (- depth 0.02))
  height

When using \(\) delimiters, using a depth adjustment of 0 (instead of
0.02) looks correct to me. I checked this by blowing up the fragment
with a very large scale factor (eg 10) and then baseline misalignments
become more obvious. This is how I ensured my baseline computation was
correct when I wrote that patch aligning the baseline several years
ago. I /think/ that's a valid method, and I've been using my code for
the last couple years and the baseline has always looked correct.

Anyway, can you explain more why you came to the conclusion of that
slight depth adjustment? Are you using $$ delimiters? That also appears
to produce other visual imperfections. For $F=ma$, I see the bottom of
the "m" and "a" cut off slightly. I wonder why different delimiters
produce different results. I used slightly different settings for
dvisvgm in my implementation (including --exact-bbox). I wonder if that
has any relevance... I also used a different document class - standalone
in preview mode. Now that I think about it, IIRC that was to address
another corner case I ran into, which is that for large images, article
will crop it before it gets to dvisvgm. It's been a while since I did
this and my memory is hazy, but I think that's why I used standalone. I
can try to investigate that with a minimal issue.

Matt

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Matt Huszagh]

Timothy,

Another minor issue I've encountered. Using different delimiters results
in images of slightly different sizes.

For example, in a file containing:

```
Using first delimiters: \(F=ma\).

Using other delimiters: $F=ma$.
```

The snippet with dollar sign delimiters is slightly larger than the one
using \(\).

Matt

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Matt Huszagh]

Hi Timothy,

Thanks for your work on this.

I've run into an issue related to the change you made in
209e5f5f4047a34db27c3b5dff4077bb1da9ceed that makes org-latex-compile
asynchronous.

This breaks the org-babel-latex-pdf-svg-process functionality I
introduced in commit ae35a345903c640397a8d29812112d72a9f8494a.

To reproduce the issue, you can create an org file with the following
single latex source block:

#+header: :file "out.svg"
#+begin_src latex :hidden
\begin{equation}\tag{1.6.3.1}
  \mathbf{F} = q \mathbf{E},
\end{equation}
#+end_src

If you execute this with C-c C-c, it complains about the PDF file not
being present. The problem can be found starting in line 182 of
ob-latex.el of your current (as of this writing) feature branch commit
8384289762b41b26e75d2e80c37ec84bcc552d32. The issue is that
org-babel-latex-tex-to-pdf (which delegates to org-latex-compile)
creates the PDF after org-compile-file (in line 185) tries to generate
an SVG file from it. In fact, I was initially confused because I
couldn't reproduce the issue with edebug (obviously, because that gave a
long enough delay for the file to be created before attempting the svg
creation).

org-latex-compile seems like it could be a dangerous function to change
to be asynchronous, as it's used in a lot of places and its very
possible that other people (like myself) were relying on it being
synchronous when they made some change that used it. I haven't looked at
its other invocations, but I wouldn't be surprised if this breaks other
things too. I hesitate to suggest alternatives because I don't know
enough about your use case. But, maybe you could achieve what you want
through a new org-latex-compile-async function, or add a nondefault
option to org-latex-compile?

Matt

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hello again everyone,

I’ve recently found a window of blissfully free time, and plan on using it to
polish up this effort.

Now is a great time to take the branch for a spin and report issues/requests 🙂.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Roshan Shariff]

Hi Timothy and Karthik,

Thanks for your wonderful work on this feature!  I've been using it
for several weeks and it's been working extremely well in my
experience.

I noticed a small visual glitch when inline latex previews wrap to the
next line, that is apparent when org-highlight-latex-and-related is
set to '(native).  The post-line-ending space on the previous line
takes on the background color of the org-block face.

I've described the reason for the problem and written a potential
solution in a patch following this message.  It appears to fix the
problem completely, but I'm not sure if it's the best way to go about
it.  I'd appreciate if you could take a look, and thanks for your
time!

Regards,
Roshan

Roshan Shariff (1):
  Fix background color when line-wrapping latex previews

 lisp/org-latex-preview.el | 51 +--
 lisp/org.el   |  5 ++--
 2 files changed, 46 insertions(+), 10 deletions(-)

-- 
2.41.0

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[திங்கள் ஆகஸ்ட் 21, 2023] Karthik Chikmagalur wrote:

>> I have lualatex installed as part of another texlive package but I am
>> not sure if org uses it however.
>
> If you haven't changed `org-latex-compiler' (globally or in the Org
> buffer using a keyword), it's using pdflatex.

I am indeed using pdflatex.

>>> 3. If no, do you mind sharing this file (or a stripped down version
>>> you're okay sharing that still has these issues) along with the LaTeX
>>> preamble?  That would be `org-latex-preview-preamble' and
>>> `org-latex-packages-alist'.  I would like to reproduce this bug.
>
> Please let us know if you can reproduce the precompilation failure.
> This shouldn't be happening.

Hmm, I tried to reproduce it again but failed to do it.  Perhaps, being
a bit more patient is the key.  Sorry for the false alarm.  I will turn
on precompilation and report if/when I can reproduce the failure.

>> No, AFAICT I don't see the issue with png previews.  
>
> Sizing issues with pdflatex+svg previews should be fixed soon.
>
>> However, all latex previews, \( \) and \[ \], seem to be of the same
>> size now.
>
> Should they not be the same size?

After using the svg previews, I was under the impression that inline
maths environments would be at the same size as the rest of the text
whereas the other environments would be at a slightly higher size.

>>> Previewing unadorned LaTeX macros is officially unsupported but
>>> partially supported in practice.  If you move the cursor over the \ch{}
>>> and call `org-latex-preview' it should be previewed.  From that point it
>>> should behave like a regular LaTeX fragment.  Editing it should cause
>>> the preview to be auto-updated (If you are using
>>> org-latex-preview-auto-mode).
>>
>> Is there no automagic way to do this?  Like changing a regexp variable
>> and hoping it would work till the end of time™.  (:
>
> You can change `org-latex-preview--tentative-math-re' to suit your
> needs.  This variable is used to identify LaTeX fragments when calling
> `org-latex-preview'.  All subsequent checks involve the org-element api,
> but for reasons I can't recall at the moment the initial search is via a
> regexp.

Thanks, that seems to work!

> Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> I have lualatex installed as part of another texlive package but I am
> not sure if org uses it however.

If you haven't changed `org-latex-compiler' (globally or in the Org
buffer using a keyword), it's using pdflatex.

>> 3. If no, do you mind sharing this file (or a stripped down version
>> you're okay sharing that still has these issues) along with the LaTeX
>> preamble?  That would be `org-latex-preview-preamble' and
>> `org-latex-packages-alist'.  I would like to reproduce this bug.

Please let us know if you can reproduce the precompilation failure.
This shouldn't be happening.

> No, AFAICT I don't see the issue with png previews.  

Sizing issues with pdflatex+svg previews should be fixed soon.

> However, all latex previews, \( \) and \[ \], seem to be of the same
> size now.

Should they not be the same size?

>> Previewing unadorned LaTeX macros is officially unsupported but
>> partially supported in practice.  If you move the cursor over the \ch{}
>> and call `org-latex-preview' it should be previewed.  From that point it
>> should behave like a regular LaTeX fragment.  Editing it should cause
>> the preview to be auto-updated (If you are using
>> org-latex-preview-auto-mode).
>
> Is there no automagic way to do this?  Like changing a regexp variable
> and hoping it would work till the end of time™.  (:

You can change `org-latex-preview--tentative-math-re' to suit your
needs.  This variable is used to identify LaTeX fragments when calling
`org-latex-preview'.  All subsequent checks involve the org-element api,
but for reasons I can't recall at the moment the initial search is via a
regexp.

Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[திங்கள் ஆகஸ்ட் 21, 2023] Karthik Chikmagalur wrote:

>> It worked well all around except for three things:
>>
>> 1. I had to set org-latex-preview-precompile to nil to produce the
>>preview for ~2000 snippets.  I got errors in process filters such
>>as arg-out-of-range, and Emacs completely blocked itself.  I can
>>confirm that mylatexformat is installed
>
> 1. Are you using xelatex/lualatex?  

I have lualatex installed as part of another texlive package but I am
not sure if org uses it however.

> 2. If yes, precompilation should have turned itself off with a warning.
> 3. If no, do you mind sharing this file (or a stripped down version
> you're okay sharing that still has these issues) along with the LaTeX
> preamble?  That would be `org-latex-preview-preamble' and
> `org-latex-packages-alist'.  I would like to reproduce this bug.
>
> Previewing 2000 snippets is exactly where the new async/speedy system is
> expected to shine compared to the old one.
>
>> 2. Apparently, org-latex-default-packages-alist no longer contain
>>asmsymb and asmmath?  This change pulled the rug under me since
>>it took me quite a while to figure out why some of my formulas
>>were coloured red...
>
> `org-latex-default-packages-alist' was modified to omit amsmath and
> amssymb (among others) in preparation for a conditional export system
> where required packages will be determined automatically from the buffer
> text -- i.e. to avoid exactly the kind of headache you encountered.
> Unfortunately this export system is not part of the patch set yet.

Ah, OK.  I will add them in my config and call it a day.  ;-)

>> 3. The image sizes of the same latex environment (e.g., \[ \]) is
>>different for different formulas.  I can send a screenshot of
>>this if required.
>
> This is a recent regression.  Could you generate png previews by:
>
> 1. (setq org-latex-preview-default-process 'dvipng)
> 2. regenerating previews
>
> and checking if this still happens?  If these look fine, this is a
> dvisvgm issue and we will fix it soon.

No, AFAICT I don't see the issue with png previews.  However, all latex
previews, \( \) and \[ \], seem to be of the same size now.

>>> If you do come across any issues, please let me know either in a reply here 
>>> or
>>> the org-mode matrix room. If you could also run
>>>  and 
>>> share the
>>> diagnostic info, that would be quite helpful.
>>
>> If needed, I can do this after reproducing (1).
>>
>> BTW, would it possible to arrange other latex environments (\ch{} in my
>> case) to be previewed as well?  Currently, I do \(\ch{}\) but omitting
>> \( \) would be nice.
>
> Previewing unadorned LaTeX macros is officially unsupported but
> partially supported in practice.  If you move the cursor over the \ch{}
> and call `org-latex-preview' it should be previewed.  From that point it
> should behave like a regular LaTeX fragment.  Editing it should cause
> the preview to be auto-updated (If you are using
> org-latex-preview-auto-mode).

Is there no automagic way to do this?  Like changing a regexp variable
and hoping it would work till the end of time™.  (:

> Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> It worked well all around except for three things:
>
> 1. I had to set org-latex-preview-precompile to nil to produce the
>preview for ~2000 snippets.  I got errors in process filters such
>as arg-out-of-range, and Emacs completely blocked itself.  I can
>confirm that mylatexformat is installed

1. Are you using xelatex/lualatex?  
2. If yes, precompilation should have turned itself off with a warning.
3. If no, do you mind sharing this file (or a stripped down version
you're okay sharing that still has these issues) along with the LaTeX
preamble?  That would be `org-latex-preview-preamble' and
`org-latex-packages-alist'.  I would like to reproduce this bug.

Previewing 2000 snippets is exactly where the new async/speedy system is
expected to shine compared to the old one.

> 2. Apparently, org-latex-default-packages-alist no longer contain
>asmsymb and asmmath?  This change pulled the rug under me since
>it took me quite a while to figure out why some of my formulas
>were coloured red...

`org-latex-default-packages-alist' was modified to omit amsmath and
amssymb (among others) in preparation for a conditional export system
where required packages will be determined automatically from the buffer
text -- i.e. to avoid exactly the kind of headache you encountered.
Unfortunately this export system is not part of the patch set yet.

> 3. The image sizes of the same latex environment (e.g., \[ \]) is
>different for different formulas.  I can send a screenshot of
>this if required.

This is a recent regression.  Could you generate png previews by:

1. (setq org-latex-preview-default-process 'dvipng)
2. regenerating previews

and checking if this still happens?  If these look fine, this is a
dvisvgm issue and we will fix it soon.

>> If you do come across any issues, please let me know either in a reply here 
>> or
>> the org-mode matrix room. If you could also run
>>  and 
>> share the
>> diagnostic info, that would be quite helpful.
>
> If needed, I can do this after reproducing (1).
>
> BTW, would it possible to arrange other latex environments (\ch{} in my
> case) to be previewed as well?  Currently, I do \(\ch{}\) but omitting
> \( \) would be nice.

Previewing unadorned LaTeX macros is officially unsupported but
partially supported in practice.  If you move the cursor over the \ch{}
and call `org-latex-preview' it should be previewed.  From that point it
should behave like a regular LaTeX fragment.  Editing it should cause
the preview to be auto-updated (If you are using
org-latex-preview-auto-mode).

Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Visuwesh]

[ஞாயிறு மார்ச் 12, 2023] Timothy wrote:

> Hi All,
>
> After months of work, Karthink and I have prepared a rather large patch-set
> completely overhauling the LaTeX preview system. I hope to have a patch set
> shortly, but in the mean time it would be good to get some more people testing
> this.
>
> To test this feature, please check out the `dev' branch of
>  (it’s the default branch). There 
> are
> also some other changes there currently, but I don’t think anything is broken.

I tested commit '6eb77305361a1f6a3f67c3229f837f1c4e95f546' of the dev
branch.

It worked well all around except for three things:

1. I had to set org-latex-preview-precompile to nil to produce the
   preview for ~2000 snippets.  I got errors in process filters such
   as arg-out-of-range, and Emacs completely blocked itself.  I can
   confirm that mylatexformat is installed

   % dpkg-query -S mylatexformat
   texlive-latex-extra: 
/usr/share/texlive/texmf-dist/tex/latex/mylatexformat
   texlive-latex-extra: 
/usr/share/texlive/texmf-dist/tex/latex/mylatexformat/mylatexformat.ltx

2. Apparently, org-latex-default-packages-alist no longer contain
   asmsymb and asmmath?  This change pulled the rug under me since
   it took me quite a while to figure out why some of my formulas
   were coloured red...

3. The image sizes of the same latex environment (e.g., \[ \]) is
   different for different formulas.  I can send a screenshot of
   this if required.

Except for these hiccups, it works without a hitch.  Thank you very much
for your work!

> If you do come across any issues, please let me know either in a reply here or
> the org-mode matrix room. If you could also run
>  and share 
> the
> diagnostic info, that would be quite helpful.

If needed, I can do this after reproducing (1).

BTW, would it possible to arrange other latex environments (\ch{} in my
case) to be previewed as well?  Currently, I do \(\ch{}\) but omitting
\( \) would be nice.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

WANG Yicheng  writes:

> Also, the org-latex-preview also rendered (deliberately put) inline \[…\] as 
> inline images.
>
> I guess it could be caused by org-latex-math-environments-re. Could you add 
> support to recognize \[…\] also as equations? Thank you.

For context, \[...\] fragments are considered as a part of paragraph by Org
mode. Changing org-latex-math-environments-re would break this
assumption will be considered a breaking change in Org syntax.

How these fragments are displayed and exported is another question and
may be a subject of discussion.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[WANG Yicheng]

Hi!

I just tried that out. As I mentioned 
here:https://lists.gnu.org/archive/html/emacs-orgmode/2023-08/msg00092.html, I 
found that, when using the dvisvgm option for exporting TeX snippets to HTML, 
the displayed math enclosed by \[…\] is not rendered as equation block, while 
math environments enclosed by \begin{…} \end{…} are rendered correctly.

Also, the org-latex-preview also rendered (deliberately put) inline \[…\] as 
inline images.

I guess it could be caused by org-latex-math-environments-re. Could you add 
support to recognize \[…\] also as equations? Thank you.

Regards,
ywangmy

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Pedro Andres Aranda Gutierrez]

Ok, so that’s excluded ;-) 

PA

Enviado desde mi iPhone

> El 5 jun 2023, a las 1:29, Rudolf Adamkovič  escribió:
> 
> Pedro Andres Aranda Gutierrez  writes:
> 
>> this might not be completely the case, but I recently reported a bug
>> against native compilation in Emacs. What about trying without netive
>> compilation?
> 
> I have just tried without native compilation.  No luck!  I get the exact
> same error.
> 
> Rudy
> -- 
> "Great minds discuss ideas; average minds discuss events; small minds discuss
> people."
> --- Anna Eleanor Roosevelt (1884-1962)
> 
> Rudolf Adamkovič  [he/him]
> Studenohorská 25
> 84103 Bratislava
> Slovakia

Re: Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Rudolf Adamkovič]

Pedro Andres Aranda Gutierrez  writes:

> this might not be completely the case, but I recently reported a bug
> against native compilation in Emacs. What about trying without netive
> compilation?

I have just tried without native compilation.  No luck!  I get the exact
same error.

Rudy
-- 
"Great minds discuss ideas; average minds discuss events; small minds discuss
people."
--- Anna Eleanor Roosevelt (1884-1962)

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

Re: Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Pedro Andres Aranda Gutierrez]

HI,

this might not be completely the case, but I recently reported a bug
against native compilation in Emacs. What about trying without netive
compilation?

Hope it helps!
/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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Rudolf,

Thanks for testing the branch :)

> ISSUE 1: CLIPPING
>
> On my HiDPI screen, the new previews are clipped slightly at the edges.
> I had this issue before and fixed it in [1][2].  Has the same bug crept
> back?
>
> [1] 
> 
> [2] 
> 

We’re thinking of adding `--exact-bbox' to the default `dvisvgm' flags, which it
seems has a good chance of resolving this. It was originally swapped for
`--bbox=preview' (when using `dvisvgm' to get dimension info), but now we do 
this
via the LaTeX compilation stdout, and so we can go back to `--exact-bbox'.

> ISSUE 2: TIKZ
>
> I use LaTeX Babel blocks for TikZ, and these stopped working.  From the
> *Messages* buffer:
>
> Executing Latex unknown at position 846…
> Processing LaTeX file 
> /var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex…
> Compiling 
> /var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex…
> org-compile-file: File 
> “/var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.svg”
>  wasn’t producedorg babel latex failed
> PDF file produced.
>
> The linked LaTeX file compiles without errors, and a PDF file with
> correct content sits next to it.  Perhaps the preview system needs to
> wait longer?

Hmmm, not sure what’s going on. Care to provide a MWE?

> [Also notice the missing space in “producedorg”.]
>
> It would be *FABULOUS* if this patch-set could also make ’ob-babel’ use
> the same mechanism as the new previews, ’dvisvgm’ (TeX to DVI to SVG)
> instead of Inkscape (TeX to PDF to SVG).  It would fix, for example,
> scaling.  On my system, LaTeX Babel outputs everything at half of the
> correct size, and I cannot convince Inkscape to scale up to save my
> life.  The previews and ’dvisvgm’ work as expected, conversely.

The hard part was the overhauled machinery, hooking up the new system to
ob-babel should be possible without too much hassle. It might need to wait for
another patch-set though (this one is already at ~100 commits and a few thousand
lines changed).

> It would be *SUPER-FABULOUS* if the new previews worked with TikZ out of
> the box, as per the Org manual saying “any LaTeX environment is handled”
> [1] when not using MathJax.  Currently, PGF plots show as “blobs of
> letters” and the simplest TikZ pictures, such as
>
> \begin{tikzpicture}
>   \filldraw (0, 0) circle[radius = 1cm];
> \end{tikzpicture}
>
> make the preview system choke with
>
> error in process filter: org-latex-preview–svg-make-fg-currentColor: Wrong 
> type argument: stringp, nil
> error in process filter: Wrong type argument: stringp, nil

I tried this example on my computer, and it worked flawlessly (see
). If you could give me a stacktrace, that might help.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Rudolf Adamkovič]

Timothy  writes:

> If you do come across any issues, please let me know either in a reply
> here or the org-mode matrix room.

First of all, thank you for working on this!

Here are some issues, after using your patch-set for 1 day:

ISSUE 1: CLIPPING

On my HiDPI screen, the new previews are clipped slightly at the edges.
I had this issue before and fixed it in [1][2].  Has the same bug crept
back?

[1] https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=52ebf6b45
[2] https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5337a49f3

ISSUE 2: TIKZ

I use LaTeX Babel blocks for TikZ, and these stopped working.  From the
*Messages* buffer:

Executing Latex unknown at position 846...
Processing LaTeX file 
/var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex...
Compiling 
/var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex...
org-compile-file: File 
"/var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.svg"
 wasn’t producedorg babel latex failed
PDF file produced.

The linked LaTeX file compiles without errors, and a PDF file with
correct content sits next to it.  Perhaps the preview system needs to
wait longer?

[Also notice the missing space in "producedorg".]

It would be *FABULOUS* if this patch-set could also make 'ob-babel' use
the same mechanism as the new previews, 'dvisvgm' (TeX to DVI to SVG)
instead of Inkscape (TeX to PDF to SVG).  It would fix, for example,
scaling.  On my system, LaTeX Babel outputs everything at half of the
correct size, and I cannot convince Inkscape to scale up to save my
life.  The previews and 'dvisvgm' work as expected, conversely.

It would be *SUPER-FABULOUS* if the new previews worked with TikZ out of
the box, as per the Org manual saying "any LaTeX environment is handled"
[1] when not using MathJax.  Currently, PGF plots show as "blobs of
letters" and the simplest TikZ pictures, such as

\begin{tikzpicture}
  \filldraw (0, 0) circle[radius = 1cm];
\end{tikzpicture}

make the preview system choke with

error in process filter: org-latex-preview--svg-make-fg-currentColor: Wrong 
type argument: stringp, nil
error in process filter: Wrong type argument: stringp, nil

[1] https://orgmode.org/manual/LaTeX-fragments.html

Rudy
-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
-- Walter Warwick Sawyer, Mathematician's Delight, 1943

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Jun Inoue]

On Wed, May 10, 2023 at 7:23 PM Timothy  wrote:

>
> Hi Jun,
>
> > You mention in a separate email that XeLaTeX is known to cause
> > hassles, but is this one of them? I could migrate to PDFLaTeX, but I'd
> > lose the convenience of editing with unicode-math.
>
> This is indeed one of the niggles we're currently aware of. Simply put,
> XeLaTeX seems to report sizing information differently, and that's
> rather unhelpful.
>
> Hopefully this will be addressed in the next few weeks, but in the
> meantime pdfLaTeX remains a good fallback.
>

Bummer, but it's good to know it's being worked on.   I'm no expert on this
stuff, so I'll just have to wait, I guess.  Thanks for clarifying!



>
> All the best,
> Timothy
>
> --
> Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at .
>


-- 
Jun Inoue

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Jun,

> You mention in a separate email that XeLaTeX is known to cause
> hassles, but is this one of them? I could migrate to PDFLaTeX, but I'd
> lose the convenience of editing with unicode-math.

This is indeed one of the niggles we're currently aware of. Simply put,
XeLaTeX seems to report sizing information differently, and that's
rather unhelpful.

Hopefully this will be addressed in the next few weeks, but in the
meantime pdfLaTeX remains a good fallback.

All the best,
Timothy

--
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Jun Inoue]

Hello Timothy, I love what you and Karthink have done here!  Typesetting is
so much faster now!  And the little nuggets like error reporting and
intelligent sizing & coloring is so going to boost my org QoL.  Thank you
so much for your work!

I've been trying this on and off for a few days now, and it works really
well, except for one thing.  I'm using XeLaTeX, and whenever I typeset a
LaTeX fragment containing a letter that sticks below the baseline (g, j, y,
etc), the fragment is typeset too small, almost like subscripts.  It
reproduces when this is the only setting I have:

(use-package org
:ensure nil
:custom
(org-latex-compiler "xelatex") ;; drop this line and the issue goes away
)

Minimal 1-line org file to trigger the bug:
abc $d$ $y$ -- the y is typeset too small compared to abc.  The d is just
the right size.

You mention in a separate email that XeLaTeX is known to cause hassles, but
is this one of them?  I could migrate to PDFLaTeX, but I'd lose the
convenience of editing with unicode-math.

On Sun, Mar 12, 2023 at 9:35 PM Timothy  wrote:

> Hi All,
>
> After months of work, Karthink and I have prepared a rather large patch-set
> completely overhauling the LaTeX preview system. I hope to have a patch set
> shortly, but in the mean time it would be good to get some more people
> testing
> this.
>
> To test this feature, please check out the `dev' branch of
>  (it’s the default branch).
> There are
> also some other changes there currently, but I don’t think anything is
> broken.
>
> You can view the almost-ready path set/diff here:
> , see the
> ORG-NEWS and org-manual entries to get a bit more of an idea of what’s
> changed.
> The short version is that now:
> • Previews are generated in bulk, and hundreds of LaTeX fragments can be
> processed per second.
> • Images are placed continuously as they are generated.
> • Preview generation is asynchronous and will not block Emacs.
> • Inline previews are aligned and scaled to match the font baseline and
> size.
> • Previews scale along with text when the text scale is changed.
> • Previews are coloured to match surrounding text and the active theme.
> • SVG previews automatically change colors when the active theme changes.
> • Error encountered when compiling LaTeX fragments can be accessed by
> mousing over preview images.
> • Preview overlays can hide and show themselves dynamically based on
> cursor position.
> • Org mode can auto-generate LaTeX previews as you type or edit the text
> of existing ones.
> • Org mode can keep equation numbering consistent by regenerating previews
> as needed.
>
> If you do come across any issues, please let me know either in a reply
> here or
> the org-mode matrix room. If you could also run
>  and
> share the
> diagnostic info, that would be quite helpful.
>
> Lastly, Karthink has prepared a video giving an overview of the new
> capabilities, you can give it a watch here:
> 
>
> All the best,
> Timothy
>
> --
> Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at .
>


-- 
Jun Inoue

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Max Nikulin  writes:

> On 09/05/2023 18:34, Ihor Radchenko wrote:
>> I can easily see Lualatex-specific preamble simply failing to work on
>> Latex. Or things being rendered wrongly.
>
> iftex.sty has \ifpdftex and \iftutex (XeTeX, LuaTeX, LuaHBTeX) commands, 
> so it is possible to create universal preamble with some additional efforts.

Sure. I mostly had user-specified #+LATEX_HEADER options in mind.
They are unlikely to be universal.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Max Nikulin]

On 09/05/2023 18:34, Ihor Radchenko wrote:

I can easily see Lualatex-specific preamble simply failing to work on
Latex. Or things being rendered wrongly.


iftex.sty has \ifpdftex and \iftutex (XeTeX, LuaTeX, LuaHBTeX) commands, 
so it is possible to create universal preamble with some additional efforts.


https://list.orgmode.org/9aef1174-ddfc-6957-8a2b-90cf21eae...@gmail.com/
Max Nikulin. Re: [possible patch] Basic fontspec code for LuaLaTeX and 
XelaTeX. Sat, 16 Jul 2022 10:01:30 +0700

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[General discussions about Org-mode.]

Timothy  writes:

> Hi Ihor,
>
>>> As a result of this issue (plus other issues with xelatex), I’m
>>> considering adding an option to specify different LaTeX compilers for
>>> previews and exports, with the default option continuing to be
>>> the value of `org-latex-compiler’.
>>
>> I am not sure if it is a good idea.
>> I can easily see Lualatex-specific preamble simply failing to work on
>> Latex. Or things being rendered wrongly.
>>
>> One option could be trying pdflatex first and falling back to the
>> default compiler on failure. But only as non-default option.
>
> To be clear, the default will be “use the same preview compiler as document
> compiler”, but the hassles we’re currently experiencing with XeLaTeX/LuaLaTeX
> make us think it could be worth adding an override option.

Since we had been talking only about LuaLaTeX being slow, can we also
establish whether XeLaTeX is slow?  I don't think we have confirmed this
yet.  Thanks.

> All the best,
> Timothy


-- 
Best,


RY

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Ihor,

>> To be clear, the default will be “use the same preview compiler as document
>> compiler”, but the hassles we’re currently experiencing with XeLaTeX/LuaLaTeX
>> make us think it could be worth adding an override option.
>
> I understand. I propose to fall back to the default even if override is
> provided, but fails compilation.

Hmm. I’m on board with this as long as the implementation isn’t to complex (I
think this should be fine), and only for overriding the global default (i.e.
stick with a different value if it was set specifically for the current buffer).

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Timothy  writes:

>> One option could be trying pdflatex first and falling back to the
>> default compiler on failure. But only as non-default option.
>
> To be clear, the default will be “use the same preview compiler as document
> compiler”, but the hassles we’re currently experiencing with XeLaTeX/LuaLaTeX
> make us think it could be worth adding an override option.

I understand. I propose to fall back to the default even if override is
provided, but fails compilation.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Ihor,

>> As a result of this issue (plus other issues with xelatex), I’m
>> considering adding an option to specify different LaTeX compilers for
>> previews and exports, with the default option continuing to be
>> the value of `org-latex-compiler’.
>
> I am not sure if it is a good idea.
> I can easily see Lualatex-specific preamble simply failing to work on
> Latex. Or things being rendered wrongly.
>
> One option could be trying pdflatex first and falling back to the
> default compiler on failure. But only as non-default option.

To be clear, the default will be “use the same preview compiler as document
compiler”, but the hassles we’re currently experiencing with XeLaTeX/LuaLaTeX
make us think it could be worth adding an override option.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Karthik Chikmagalur  writes:

> As a result of this issue (plus other issues with xelatex), I'm
> considering adding an option to specify different LaTeX compilers for
> previews and exports, with the default option continuing to be
> the value of `org-latex-compiler'.

I am not sure if it is a good idea.
I can easily see Lualatex-specific preamble simply failing to work on
Latex. Or things being rendered wrongly.

One option could be trying pdflatex first and falling back to the
default compiler on failure. But only as non-default option.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Konstantinos Chousos]

> This checks out.  I tested previews with lualatex for a bit, and it's
> about 8-10x slower than pdflatex.  One big chunk of this gap is the
> absence of precompilation, the rest appears to be inherent to lualatex.
> I'm not familiar with lualatex, so if someone knows how it can be sped
> up I'd be glad to be educated.  For now I'd recommend using pdflatex for
> LaTeX previews.

Yes, you're right. Tested pdflatex myself and the difference is like
night and day. My choice to use lualatex was based in the fact that I
write in greek as well and sometimes may need greek script in latex
fragments. But, seeing the difference in speed, both in buffer
previews and in live ones, I'll probably stick with pdflatex and just
work around the language part.

> I've had trouble getting LaTeX environments to show via eldoc in the
> echo-area, whereas eldoc-box has worked fine.  I'm making a note to
> investigate this later.

In my setup it only works if I open the eldoc buffer. But eldoc-box
doesn't work.

>> I tried setting `org-latex-preview-default-process' to `dvipng' and
>> found that previews as well appear blank. Don't know what might be the
>> problem.
>
> Is this in the context of previews or HTML exports?

Both. But with pdflatex it works.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> Yeah, it kinda works ok now. It is kinda slow, but it probably takes
> the same time as the normal previews. May the fact that I use
> `lualatex' be the culprit?

This checks out.  I tested previews with lualatex for a bit, and it's
about 8-10x slower than pdflatex.  One big chunk of this gap is the
absence of precompilation, the rest appears to be inherent to lualatex.
I'm not familiar with lualatex, so if someone knows how it can be sped
up I'd be glad to be educated.  For now I'd recommend using pdflatex for
LaTeX previews.

As a result of this issue (plus other issues with xelatex), I'm
considering adding an option to specify different LaTeX compilers for
previews and exports, with the default option continuing to be
the value of `org-latex-compiler'.

> Both `buffer' and `eldoc' work as expected. Although, when I use `eldoc' and
> use the `eldoc-box' package, nothing is shown. But, this probably isn't
> in the scope of this conversation and it's really secondary.

I've had trouble getting LaTeX environments to show via eldoc in the
echo-area, whereas eldoc-box has worked fine.  I'm making a note to
investigate this later.

> I tried setting `org-latex-preview-default-process' to `dvipng' and
> found that previews as well appear blank. Don't know what might be the
> problem.

Is this in the context of previews or HTML exports?

-Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Konstantinos Chousos]

Update about a little bug I found:

When it comes to fragments that contains things such as limits, under/over 
braces etc., the live preview's borders get kind of messed up. Don't know how 
to describe it exactly, see the attached image.

-Konstantinos

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Konstantinos Chousos  writes:

>> Tecosaur will have a better idea of what's happening here.  Note that
>> the export options for html are `tex:dvipng' or `tex:dvisvgm', not
>> `dvipg' and `dvisvg'.
>
> Oops, you're right. `dvisvgm' works.

It would be useful if unexpected values there triggered a warning.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Konstantinos Chousos]

> They shouldn't be any slower than when you manually call
> `org-latex-preview' on a fragment.  To be sure, you could try
>
> (setq org-latex-preview-debounce 0.3
>   org-latex-preview-throttle 0.3)
>
> and then turn on (or turn off + on) `org-latex-preview-auto-mode'.

Yeah, it kinda works ok now. It is kinda slow, but it probably takes
the same time as the normal previews. May the fact that I use `lualatex'
be the culprit?

> The video you linked to was a proof of concept.  Here is a demo of the
> current design: 
>
> If `org-latex-preview-live-display-type' is set to `eldoc':
> - show live previews using Eldoc.  You may need to pop up the Eldoc doc
> buffer for larger previews to be visible (`M-x eldoc-mode', followed by
> `M-x eldoc-doc-buffer').
>
> Else:
> - Inline fragments are live-previewed inline
> - LaTeX environments are previewed below the environment

Both `buffer' and `eldoc' work as expected. Although, when I use `eldoc' and
use the `eldoc-box' package, nothing is shown. But, this probably isn't
in the scope of this conversation and it's really secondary.

> Tecosaur will have a better idea of what's happening here.  Note that
> the export options for html are `tex:dvipng' or `tex:dvisvgm', not
> `dvipg' and `dvisvg'.

Oops, you're right. `dvisvgm' works.

Since this was what was wrong, I tried setting
`org-latex-preview-default-process' to `dvipng' and found that previews as
well appear blank. Don't know what might be the problem.

> It shouldn't be happening every time -- only when certain conditions are
> met.  Deleting fragments might be one of these conditions.

Today it works better, I don't know what I did differently. But as you
said, it certainly bugs out when you delete the fragment.

Now that I've tried it a bit, it seems smoother than at first
glance. I'll probably keep using it and report any problems that might
arise.

-Konstantinos

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> The preview now works as stated, although I find it kinda slow to
> regenerate, even if I set `org-latex-preview-throttle' to 0.2.

They shouldn't be any slower than when you manually call
`org-latex-preview' on a fragment.  To be sure, you could try

(setq org-latex-preview-debounce 0.3
  org-latex-preview-throttle 0.3)

and then turn on (or turn off + on) `org-latex-preview-auto-mode'.

> Also for some reason my previews appear to the right of the cursor,
> instead of under it like in the linked webm.

The video you linked to was a proof of concept.  Here is a demo of the
current design: https://tinyurl.com/ms2ksthc

If `org-latex-preview-live-display-type' is set to `eldoc':
- show live previews using Eldoc.  You may need to pop up the Eldoc doc
buffer for larger previews to be visible (`M-x eldoc-mode', followed by
`M-x eldoc-doc-buffer').

Else:
- Inline fragments are live-previewed inline
- LaTeX environments are previewed below the environment

> My last problem is that exports are kinda borked. For example, these
> days I started using `org-msg' and when my email exports to html and
> latex is included, one of these happen:
>
> - The fragment appears as a blank image when the options `tex:dvipg' or
>   `tex:dvisvg' are used.
> - The email doesn't even export to html with a message like
>   `org-html-latex-image: Expected LaTeX preview
> "424ed928d1eaca9e3c4c588469a4a0b87a7f4329" to exist in the cache'
>   with the option `tex:imagemagick'.

Tecosaur will have a better idea of what's happening here.  Note that
the export options for html are `tex:dvipng' or `tex:dvisvgm', not
`dvipg' and `dvisvg'.

>> If the live preview is not removed automatically after you move away
>> from a LaTeX fragment, you might have to manually eval
>> `(org-latex-preview-live--clearout)'.
>
> Yeah, it happens to me to. Even if I remove the fragment the preview
> persists.

It shouldn't be happening every time -- only when certain conditions are
met.  Deleting fragments might be one of these conditions.

-Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Konstantinos Chousos]

> Is tooltip-mode turned on?

That was it! Thank you so much! Now both error messages and live
previews work!

> We'd like to focus on improving the user experience of the core features
> first.  If these issues are cleaned up before 9.7, I will work on
> polishing the live previews feature.

Totally agree. It should only be merged when its ready.


> There is no documentation for live-previews yet.  If you would like
> to try it -- and I encourage you to -- you could set:
>
> (setq org-latex-preview-auto-generate 'live)
>
> and then turn on `org-latex-preview-auto-mode'.  The variables
> `org-latex-preview-throttle' and `org-latex-preview-debounce' control
> the responsiveness of the live previews.

The preview now works as stated, although I find it kinda slow to
regenerate, even if I set `org-latex-preview-throttle' to 0.2. Also for
some reason my previews appear to the right of the cursor, instead of
under it like in the linked webm.

My last problem is that exports are kinda borked. For example, these
days I started using `org-msg' and when my email exports to html and
latex is included, one of these happen:

- The fragment appears as a blank image when the options `tex:dvipg' or
  `tex:dvisvg' are used.
- The email doesn't even export to html with a message like
  `org-html-latex-image: Expected LaTeX preview
"424ed928d1eaca9e3c4c588469a4a0b87a7f4329" to exist in the cache'
  with the option `tex:imagemagick'.

> If the live preview is not removed automatically after you move away
> from a LaTeX fragment, you might have to manually eval
> `(org-latex-preview-live--clearout)'.  This is one of the many edge
> cases with the feature that need to be handled.

Yeah, it happens to me to. Even if I remove the fragment the preview
persists.


Thanks for your quick reply. All the best.

--Konstantinos

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

> 1. Use TEC's org-mode =dev= branch, up to the =---NOPUSH PERSONAL
>DIVIDER---= commit.
> 2. Set some config options, which can be in the above link.
> 3. Test the new features.
> 4. When a latex fragment contained an error, its color would turn red,
>but no popup would appear on hover, or ever for that matter.
>
>My temporary solution is to directly check the =*Org Preview LaTeX
>Output*= buffer.

Is tooltip-mode turned on?

>> We don't think live previews will be ready or stable enough in time
>> for Org 9.7, so it is not currently part of the patch set.
>
> That's too bad, it looked really neat and useful.

We'd like to focus on improving the user experience of the core features
first.  If these issues are cleaned up before 9.7, I will work on
polishing the live previews feature.

>> It's available as a later WIP (work in progress) commit on
>> tecosaur's dev branch, if you are interested in trying it.
>
> I noticed that but as I said above, I already use that branch. Perhaps
> the bug with the error popups and this are related? After all, both have
> to do with popups. Also it is important to note that I have already set
> the configuration variables that are relevant to the /live/ preview (at
> least those that I could find).

There is no documentation for live-previews yet.  If you would like
to try it -- and I encourage you to -- you could set:

(setq org-latex-preview-auto-generate 'live)

and then turn on `org-latex-preview-auto-mode'.  The variables
`org-latex-preview-throttle' and `org-latex-preview-debounce' control
the responsiveness of the live previews.

If the live preview is not removed automatically after you move away
from a LaTeX fragment, you might have to manually eval
`(org-latex-preview-live--clearout)'.  This is one of the many edge
cases with the feature that need to be handled.

> All in all this is a huge improvement and a quality-of-life upgrade for
> all org-mode users. Thank you both for your work.

Thank you! The testing is very helpful as well.

-Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Konstantinos Chousos]

(Don't mind the mail change, still the same guy. Just started dabbling
in email in Emacs and gmail works better for that).

> From your diagnostic report, it looks like you're using lualatex +
> precompilation.  This can cause some issues, but not the ones you
> report above so this is interesting.

If I remember correctly, when I run the test I had precompilation turned
off, because with it =lualatex= didn't work, but the diagnostics kept
thinking it was on. Even so, it is currently disabled.

>> 1. When a snippet contains a mistake, it correctly turns red, but no
>> error message is shown when I hover my mouse over it. I have to
>> switch to the *Org Preview LaTeX Output* to see the error.
>
> This is a bug, could you list the steps to reproduce it?

All my relevant configuration was attached in my previous message. If it
helps, my complete Emacs configuration resides at
https://github.com/kchousos/Emacs/blob/master/Emacs.org. The only
noteworthy thing I can think of is that i use Wayland. Also, my Emacs'
version is =29.0.90= and found at
https://copr.fedorainfracloud.org/coprs/majore-biscuit/Emacs-29/. After
that, the steps were the following:

1. Use TEC's org-mode =dev= branch, up to the =---NOPUSH PERSONAL
   DIVIDER---= commit.
2. Set some config options, which can be in the above link.
3. Test the new features.
4. When a latex fragment contained an error, its color would turn red,
   but no popup would appear on hover, or ever for that matter.

   My temporary solution is to directly check the =*Org Preview LaTeX
   Output*= buffer.

> We don't think live previews will be ready or stable enough in time
> for Org 9.7, so it is not currently part of the patch set.

That's too bad, it looked really neat and useful.

> It's available as a later WIP (work in progress) commit on
> tecosaur's dev branch, if you are interested in trying it.

I noticed that but as I said above, I already use that branch. Perhaps
the bug with the error popups and this are related? After all, both have
to do with popups. Also it is important to note that I have already set
the configuration variables that are relevant to the /live/ preview (at
least those that I could find).


All in all this is a huge improvement and a quality-of-life upgrade for
all org-mode users. Thank you both for your work.

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Konstantinos Chousos]

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Karthik Chikmagalur]

>From your diagnostic report, it looks like you're using lualatex +
precompilation.  This can cause some issues, but not the ones you report
above so this is interesting. 

> 1. When a snippet contains a mistake, it correctly turns red, but no
> error message is shown when I hover my mouse over it. I have to switch
> to the *Org Preview LaTeX Output* to see the error.

This is a bug, could you list the steps to reproduce it?

> 2. Live previews do not work (like shown here
> https://tinyurl.com/5fu7z27w), although I am using the related options
> and use your branch up to the ---PATCH SET DIVIDER--- commit.

We don't think live previews will be ready or stable enough in time for
Org 9.7, so it is not currently part of the patch set.  It's available
as a later WIP (work in progress) commit on tecosaur's dev branch, if
you are interested in trying it.

> 4. Some key-binds (like C-c C-e to publish or C-c C-x C-l for
> latex-preview) do not work when the cursor is at the top of the file,
> before the first header.

This is also a bug, thanks for the report.  I'll look into it.

-Karthik

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[K. Chousos]

Hello Timothy.

First of all, thank you for your contribution. I use your fork for some days
now and I can verify that it is working correctly. I have only faced the 
following problems:

1. When a snippet contains a mistake, it correctly turns red, but no error 
message
   is shown when I hover my mouse over it. I have to switch to the *Org Preview 
LaTeX Output*
   to see the error.

2. Live previews do not work (like shown here https://tinyurl.com/5fu7z27w), 
although
   I am using the related options and use your branch up to the ---PATCH SET 
DIVIDER--- commit.

3. When using your version, the ox-hugo exporter no longer works when latex is 
involved.
   The error that appears is the following:
   org-html-format-latex: Invalid function: org-export-with-buffer-copy

4. Some key-binds (like C-c C-e to publish or C-c C-x C-l for latex-preview) do 
not work
   when the cursor is at the top of the file, before the first header.

In the attachments there are the diagnostics from the 
org-latex-preview-check-health
function and my relevant configuration.

Again, thank you for this amazing overhaul and I hope it won't be long till
we see it merged in the official Org branch.

diagnostic-results
Description: Binary data
(setq org-latex-compiler "lualatex"
  org-latex-preview-auto-generate 'live
  org-latex-preview-persist nil
  org-latex-preview-processing-indicator 'fringe
  org-latex-preview-numbered t
  org-latex-preview-width 0.75
  org-latex-preview-use-precompilation nil
  ;; org-latex-preview-live-display-type 'eldoc
  org-startup-with-latex-preview t
  org-latex-preview-auto-generate t)

(setq org-latex-preview-preamble
  "\\documentclass{article}
\\usepackage{amsmath}
\\usepackage{amssymb}
\\usepackage{amsfonts}
[DEFAULT-PACKAGES]
[PACKAGES]
\\usepackage{xcolor}")

;; \\usepackage{polyglossia}  
;; \\setmainlanguage{greek}   
;; \\setotherlanguage{english}

(plist-put org-format-latex-options :zoom 1.2) ; Calibrated based on the TeX font and org-buffer font.

(add-hook 'org-mode-hook #'org-latex-preview-auto-mode)

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[K. Chousos]

Hello Timothy.

First of all, thank you for your contribution. I use your fork for some days
now and I can verify that it is working correctly. I have only faced the 
following problems:

1. When a snippet contains a mistake, it correctly turns red, but no error 
message
   is shown when I hover my mouse over it. I have to switch to the *Org Preview 
LaTeX Output*
   to see the error.

2. Live previews do not work (like shown here https://tinyurl.com/5fu7z27w), 
although
   I am using the related options and use your branch up to the ---PATCH SET 
DIVIDER--- commit.

3. When using your version, the ox-hugo exporter no longer works when latex is 
involved.
   The error that appears is the following:
   org-html-format-latex: Invalid function: org-export-with-buffer-copy

4. Some key-binds (like C-c C-e to publish or C-c C-x C-l for latex-preview) do 
not work
   when the cursor is at the top of the file, before the first header.

In the attachments there are the diagnostics from the 
org-latex-preview-check-health
function and my relevant configuration.

Again, thank you for this amazing overhaul and I hope it won't be long till
we see it merged in the official Org branch.(setq org-latex-compiler "lualatex"
  org-latex-preview-auto-generate 'live
  org-latex-preview-persist nil
  org-latex-preview-processing-indicator 'fringe
  org-latex-preview-numbered t
  org-latex-preview-width 0.75
  org-latex-preview-use-precompilation nil
  ;; org-latex-preview-live-display-type 'eldoc
  org-startup-with-latex-preview t
  org-latex-preview-auto-generate t)

(setq org-latex-preview-preamble
  "\\documentclass{article}
\\usepackage{amsmath}
\\usepackage{amssymb}
\\usepackage{amsfonts}
[DEFAULT-PACKAGES]
[PACKAGES]
\\usepackage{xcolor}")

;; \\usepackage{polyglossia}  
;; \\setmainlanguage{greek}   
;; \\setotherlanguage{english}

(plist-put org-format-latex-options :zoom 1.2) ; Calibrated based on the TeX font and org-buffer font.

(add-hook 'org-mode-hook #'org-latex-preview-auto-mode)


diagnostic-results
Description: Binary data

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Tony Zorman]

Hi,

> After months of work, Karthink and I have prepared a rather large
> patch-set completely overhauling the LaTeX preview system. I hope to
> have a patch set shortly, but in the mean time it would be good to get
> some more people testing this.

thank you for this!  I've been testing it (from purely a user
perspective) for about a week, and I haven't run into any significant
problems so far.

One nice-to-have thing that I would personally like to see is a
`preview-auto-reveal`-like feature from AUCTeX's preview.el: one can
very precisely control when preview.el unprettifies a rendered LaTeX
fragment.  This is very convenient when, for example, going through a
rendered document by pressing C-n or , as unprettifying in this
case is (at least in my case) a mistake more often than not.

Thanks!
  Tony

-- 
Tony Zorman | https://tony-zorman.com/

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> What about
>
> (define-fringe-bitmap
> 'sand-clock
> [#b
>  #b1001
>  #b0110
>  #b0110
>  #b01101110
>  #b0000
>  #b00011000
>  #b00100100
>  #b0110
>  #b01011010
>  #b
>  #b])

The good old hourglass is back! :)

Love it!

Rudy
-- 
"Strange as it may sound, the power of mathematics rests on its evasion
of all unnecessary thought and on its wonderful saving of mental
operations."
-- Ernst Mach, 1838-1916

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Timothy  writes:

>>> • Org mode can keep equation numbering consistent by regenerating previews 
>>> as needed.
>>
>> This is disabled by default, right?
>> But I am still seeing the numbering (see the attached) the Org text
>> below.
>
> Correct. Numbering settings have been re-done to hopefully make what’s 
> happening
> more obvious.

I see. The numbers are replaced by diamonds. Looks good.

>> Also, One of the preview is truncated.
>>
>> [2. image/png; preview-artifact.png]…
>
> LaTeX has a page width when generating previews, you can increase how wide the
> text area is easily via `org-latex-preview-width'. This could be developed 
> more in
> the future, but for now it works I think.

Ok. Let's see if relevant bug reports stream in.
For now, the functionality is acceptable.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Timothy  writes:

>> 3. It took 20+ seconds (!!!) to generate previews in a single section in
>>my large notes.org. Profile attached - org-latex-preview parses the
>>whole 20Mb buffer to generate the preamble. Why?
>
> Because of the use of buffer info in generating the preamble, which calls
> `org-export--annotate-info'. I’m currently considering introducing a variable 
> to
> allow for the use of buffer-specific info to be toggled.

What if `org-export--annotate-info' could be made async?

>> 5. Why triangles? Something resembling “waiting” would be more
>>meaningful.
>
> It has to be a small icon, so that basically means simple geometric shapes 
> only.
> There’s also the “grey text” indicator, and “no indicator” option.

What about

(define-fringe-bitmap
'sand-clock
[#b
 #b1001
 #b0110
 #b0110
 #b01101110
 #b0000
 #b00011000
 #b00100100
 #b0110
 #b01011010
 #b
 #b])



>> 6. What will happen if I add/remove #+LATEX_HEADER in the buffer? in
>>subtree properties? Are in-buffer latex settings supposed to affect
>>anything? I tried to add #+LATEX_HEADER on top of the file, but the
>>preview do not appear to be re-generated.
>
> Currently you need to set `org-latex-preview--preamble-content' to nil, which
> currently can be done by doing `C-c C-c' on the header / otherwise running
> `org-restart'.

It would be better to provide a command.
C-c C-c is too dramatic - it will reset much more than just preview
cache. (Like org-element-cache).

Or better add a new prefix arg to org-latex-preview that will force
re-generation.

Further, as discussed in the DM, we may need to consider that equation
preview may depend on latex export settings:

1. preview might be generic, utilizing "average" common latex preamble
2. preview might try to conform to latex export settings according to
   full document export
3. preview might use a different latex preamble when the current subtree
   will not actually be exported - like in commented subtrees. In
   particular, it matters for equation numbering
4. preview might try to generate preamble according to subtree export
   settings - some Org workflows involve multiple documents in one Org
   file, exported separately via subtree export.
   
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Ihor,

>> • Preview overlays can hide and show themselves dynamically based on cursor 
>> position.
>
> How? I do not see anything and I cannot find any relevant customization
> in org-latex-preview.el

I think the docs might need to be edited to make `org-latex-preview-auto-mode'
more prominently mentioned.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Ihor,

>> • Org mode can keep equation numbering consistent by regenerating previews 
>> as needed.
>
> This is disabled by default, right?
> But I am still seeing the numbering (see the attached) the Org text
> below.

Correct. Numbering settings have been re-done to hopefully make what’s happening
more obvious.

> Also, One of the preview is truncated.
>
> [2. image/png; preview-artifact.png]…

LaTeX has a page width when generating previews, you can increase how wide the
text area is easily via `org-latex-preview-width'. This could be developed more 
in
the future, but for now it works I think.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Ihor,

> 1. Plenty of valid warnings and one of third-party packages broken when
>using the branch [*]

Thanks for highlighting these, I’m gradually going through them.

> 2. I had to (require ’org-latex-preview). `org-latex-preview’ is not
>autoloaded for some reason.

I haven’t had that issue, so I’m guessing it’s something to do with how your
autoloads were built.

> 3. It took 20+ seconds (!!!) to generate previews in a single section in
>my large notes.org. Profile attached - org-latex-preview parses the
>whole 20Mb buffer to generate the preamble. Why?

Because of the use of buffer info in generating the preamble, which calls
`org-export--annotate-info'. I’m currently considering introducing a variable to
allow for the use of buffer-specific info to be toggled.

> 4. Triangle symbols do not disappear if I C-g in the middle of
>generating the preamble.

Hmm, we haven’t really considered the preamble generation being interrupted.

> 5. Why triangles? Something resembling “waiting” would be more
>meaningful.

It has to be a small icon, so that basically means simple geometric shapes only.
There’s also the “grey text” indicator, and “no indicator” option.

> 6. What will happen if I add/remove #+LATEX_HEADER in the buffer? in
>subtree properties? Are in-buffer latex settings supposed to affect
>anything? I tried to add #+LATEX_HEADER on top of the file, but the
>preview do not appear to be re-generated.

Currently you need to set `org-latex-preview--preamble-content' to nil, which
currently can be done by doing `C-c C-c' on the header / otherwise running
`org-restart'.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Ihor,

Thanks for mentioning this, I’ve now added a priority of -80 🙂.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Ihor Radchenko  writes:

> The previews still interfere with hl-line overlay - their background is
> not replaced with hl-line background. Maybe we can also put low
> 'priority in the preview overlays? To make them closer to ordinary text
> in buffer.

See the attached where I compared default preview overlay with me adding
'priority -100 property.


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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Timothy  writes:

> • Preview overlays can hide and show themselves dynamically based on cursor 
> position.

How? I do not see anything and I cannot find any relevant customization
in org-latex-preview.el

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Timothy  writes:

> • Previews are coloured to match surrounding text and the active theme.
> • SVG previews automatically change colors when the active theme changes.

The previews still interfere with hl-line overlay - their background is
not replaced with hl-line background. Maybe we can also put low
'priority in the preview overlays? To make them closer to ordinary text
in buffer.

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

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Ihor Radchenko]

Timothy  writes:

> • Org mode can keep equation numbering consistent by regenerating previews as 
> needed.

This is disabled by default, right?
But I am still seeing the numbering (see the attached) the Org text
below. Also, One of the preview is truncated.



Org source:
---

For isotropic materials:

\begin{equation}
\begin{bmatrix}
\epsilon_{11} \\ \epsilon_{22} \\ \epsilon_{33} \\ 2\epsilon_{23} \\ 
2\epsilon_{13} \\ 2\epsilon_{12}
\end{bmatrix} = 
\frac{1}{E} 
\begin{bmatrix}
1 & -\nu & -\nu & 0 & 0 & 0 \\
-\nu & 1 & -\nu & 0 & 0 & 0 \\
-\nu & -\nu & 1 & 0 & 0 & 0 \\
0 & 0 & 0 & 2+2\nu & 0 & 0 \\
0 & 0 & 0 & 0 & 2+2\nu & 0 \\
0 & 0 & 0 & 0 & 0 & 2+2\nu
\end{bmatrix}  
\begin{bmatrix}
\sigma_{11} \\ \sigma_{22} \\ \sigma_{33} \\ \sigma_{23} \\ \sigma_{13} \\ 
\sigma_{12}
\end{bmatrix}  
\end{equation}

\begin{equation}
\begin{bmatrix}
\sigma_{11} \\ \sigma_{22} \\ \sigma_{33} \\ \sigma_{23} \\ \sigma_{13} \\ 
\sigma_{12}
\end{bmatrix} = 
\frac{E}{\left(1+\nu\right)\left(1-2\nu\right)} 
\begin{bmatrix}
1-\nu & \nu & \nu & 0 & 0 & 0 \\
\nu & 1-\nu & \nu & 0 & 0 & 0 \\
\nu & \nu & 1-\nu & 0 & 0 & 0 \\
0 & 0 & 0 & \frac{1-2\nu}{2} & 0 & 0 \\
0 & 0 & 0 & 0 & \frac{1-2\nu}{2} & 0 \\
0 & 0 & 0 & 0 & 0 & \frac{1-2\nu}{2}
\end{bmatrix}  
\begin{bmatrix}
\epsilon_{11} \\ \epsilon_{22} \\ \epsilon_{33} \\ 2\epsilon_{23} \\ 
2\epsilon_{13} \\ 2\epsilon_{12}
\end{bmatrix}  
\end{equation}

\begin{equation}
\begin{bmatrix}
\sigma_{11} \\ \sigma_{22} \\ \sigma_{33} \\ \sigma_{23} \\ \sigma_{13} \\ 
\sigma_{12}
\end{bmatrix} = 
\begin{bmatrix}
2\mu+\lambda & \lambda & \lambda & 0 & 0 & 0 \\
\lambda & 2\mu+\lambda & \lambda & 0 & 0 & 0 \\
\lambda & \lambda & 2\mu+\lambda & 0 & 0 & 0 \\
0 & 0 & 0 & \mu & 0 & 0 \\
0 & 0 & 0 & 0 & \mu & 0 \\
0 & 0 & 0 & 0 & 0 & \mu
\end{bmatrix}  
\begin{bmatrix}
\epsilon_{11} \\ \epsilon_{22} \\ \epsilon_{33} \\ 2\epsilon_{23} \\ 
2\epsilon_{13} \\ 2\epsilon_{12}
\end{bmatrix}  
\end{equation}


\begin{equation}
E=2\mu(1+\nu)
\end{equation}
\begin{equation}
G=2\mu
\end{equation}


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