all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tony Zorman <mail@tony-zorman.com>
To: Karthik Chikmagalur <karthikchikmagalur@gmail.com>,
	emacs-orgmode@gnu.org
Subject: Re: Using org-latex-preview in other major modes
Date: Mon, 08 Apr 2024 08:23:55 +0200	[thread overview]
Message-ID: <87wmp8l6dg.fsf@hyperspace> (raw)
In-Reply-To: <874jcdf4hj.fsf@gmail.com>

On Sun, Apr 07 2024 10:48, Karthik Chikmagalur wrote:
> [… 14 lines elided …]
>
> 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.

Thanks for taking a look! It indeed seems that caching will be the most
work to properly implement. However, I'm quite happy to not care about
numbers for now and make sure the other stuff works correctly first
before tackling this.

> [… 14 lines elided …]
>
> `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.

Besides `org-latex-preview-auto--maybe-track-element-here`, I was mostly
talking about `org-latex-preview-live--src-buffer-setup` and
`org-latex-preview-live--ensure-overlay`, which I think will be the main
targets. The latter seems to be quite a straightforward translation
(especially my current constraints of not caring about environments),
but the former seems to require a bit more work. Then again, maybe I'm
being too negative—after taking another quick look at the code I think
you're right in that this should not be impossible to overcome.

I'll try to conjure up some time this week to get live previews up and
running; will report back if I hit any unforeseen major bumps.

  Tony

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


  reply	other threads:[~2024-04-08  6:24 UTC|newest]

Thread overview: 13+ 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-10-08  0:40   ` Karthik Chikmagalur
2024-10-10 17:35     ` Ihor Radchenko
2024-04-07 17:48 ` Karthik Chikmagalur
2024-04-08  6:23   ` Tony Zorman [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wmp8l6dg.fsf@hyperspace \
    --to=mail@tony-zorman.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=karthikchikmagalur@gmail.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.