From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
To: Tony Zorman <mail@tony-zorman.com>, emacs-orgmode@gnu.org
Subject: Re: Using org-latex-preview in other major modes
Date: Sun, 07 Apr 2024 10:48:56 -0700 [thread overview]
Message-ID: <874jcdf4hj.fsf@gmail.com> (raw)
In-Reply-To: <87edbhljr7.fsf@hyperspace>
Hi Tony,
Just tried it out, it's very promising! Thanks for taking the initiative
on this.
> I've prodded the code a little bit and, mostly just following [1],
> managed to implement basic previews in a relatively straightforward
> fashion. Attached is a proof-of-concept—aptly named
> latex-latex-preview.el :) The main user facing functions so far are
> 'latex-latex-preview' to preview the maths fragment at point, and
> 'latex-latex-preview-region' to preview all fragments in a region. Both
> functions currently ignore things like numbered equations and
> environments, though both do not seem exceptionally difficult to add
> back in.
There are two issues with numbering:
- providing an Org-agnostic API point to attach a numbering table to, and
- calculating the new numbering table in LaTeX (or other major-modes).
For The first issue, we need a way to provide an updated numbering table
during the auto-regeneration of edited fragments. Currently this is
done implicitly by calling `org-latex-preview--place-from-elements' from
the `--regenerate-overlay` function.
The second requires fast numbering table updates. We do it in Org by
mapping over the org-element cache (see
`org-latex-preview--get-numbered-environments'). Even this is too slow
sometimes, so we suspend numbering updates when live-previewing until
the cursor exits the fragment. Parsing the LaTeX buffer from point to
the end when (re)generating each preview is going to be too slow, so
you'll have to create some kind of cache and update it incrementally.
> There's also a stub 'latex-latex-preview-auto-mode' minor mode. Stepping
> in and out of already rendered environments works fine, with the preview
> being regenerated if needed; only the implementation of
> 'org-latex-preview-auto--regenerate-overlay' had to change for that.
This was a pleasant surprise, I was expecting more trouble here.
> The mode does not currently feature live-previews. The innards of
> 'org-latex-preview-auto--detect-fragments-in-change' and
> 'org-latex-preview-live--setup' look a bit more org-specific, with
> queries to 'org-element-*' functions all over the place, but all of
> that looks fixable—at least from afar. I will continue prodding the
> code a little bit and will report back with any bumps that are hit
> along the way.
`org-latex-preview-auto--detect-fragments-in-change' is written for
speed. It only does quick text-matching and is thus mostly Org-agnostic,
except for a call to a numbering calculation near the end. This should
be easy to adapt. The problem is the function it calls,
`org-latex-preview-auto--maybe-track-element-here', which finds the
bounds of the inserted LaTeX fragment using org-element and
conditionally sets up a preview overlay. You will need an equivalent of
this for LaTeX-mode.
Since you have auto-mode working already, live previews should be quite
easy to add. From what I can see, you only need to provide your own
`org-latex-preview-live--ensure-overlay'. This function creates the
preview overlay next to or under the LaTeX fragment. All the other live
preview code only changes overlay properties or calls
`--regenerate-overlay`, which you've already implemented.
Karthik
next prev parent reply other threads:[~2024-04-07 17:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-07 7:22 Using org-latex-preview in other major modes Tony Zorman
2024-04-07 11:59 ` Ihor Radchenko
2024-04-07 18:06 ` Karthik Chikmagalur
2024-04-09 14:11 ` Ihor Radchenko
2024-04-07 17:48 ` Karthik Chikmagalur [this message]
2024-04-08 6:23 ` Tony Zorman
2024-04-08 6:36 ` Karthik Chikmagalur
2024-04-09 20:06 ` Tony Zorman
2024-04-21 19:10 ` Tony Zorman
2024-04-22 3:41 ` Karthik Chikmagalur
2024-04-22 9:29 ` Tony Zorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jcdf4hj.fsf@gmail.com \
--to=karthikchikmagalur@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@tony-zorman.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).