Re: Using org-latex-preview in other major modes
On Sun, Apr 21 2024 20:41, Karthik Chikmagalur wrote: >> Anyways, before I put this off for much longer, there is some more code >> attached. Live previews (and general environments) work now, and besides >> the above mentioned points there were no new surprises waiting—at least >> for getting the basic functionality to work. > > Thank you for the update! This looks promising. I'll test it when I > have time. > >> I did notice that precompilation being a bit flaky. In the end, this >> was the result of importing local packages; with the precompilation >> happening somewhere in /tmp/, access to these files wasn't given. >> haven't looked too closely into this—and it's probably a use-case >> that's specific to LaTeX-mode—but it seems worth considering > > Sorry, I should have mentioned this in my original write-up. There is a > reason for this, as explained below. This issue should not be happening > in most cases though, so I'll need more details to help. > >> (lots of people carry one big style file around that they include in >> all of their projects). > > This is true of Org mode files that are intended for LaTeX export too, > but we avoid this problem in Org. > > 1. Why we precompile in /tmp: > >Precompilation is a blocking operation, so we want to do it as >infrequently as possible. Imagine if LaTeX previews in every Org >buffer/file you opened required a precompile step that blocked Emacs >for 3 seconds. > >Precompiled dump files are identified by a hash that includes the >preamble and a default-directory. If we precompile in /tmp (or some >other fixed directory), we can reuse dump files for all Org buffers >that have the same preamble, irrespective of where they're located. > >Precompiled files are stored in org-persist and don't expire for a >long time. So we'd like to avoid generating loads of them, and reuse >them whenever possible. > >1a. Why is precompilation a blocking operation? > >It doesn't have to be, but including it in the async chain is a >little annoying. It can be made async in the future. > > 2. What happens if the user includes a directory-local .sty, .cls or >other tex files in the header? > >When precompiling, we check the header to see if it has an \input{} >or \include{} statement. If it does, we assume that there are local >dependencies and precompile it in the default-directory. See >org-latex-preview--create-tex-file for the implementation of this >logic. > >Is there some other common way that a LaTeX file can have local >dependencies? \usepackage accepts relative paths, although I think it will generate a warning since the package called will provide «pkg» instead of .relative/path/to/«pkg». Either way, it's not uncommon to see things like \usepackage[opt1, opt2=lf]{style/nested/too/deeply/style} Modulo Windows, one might check for slashes in \usepackage invocations, since I don't think TeX packages can have those. (Users *should* really add /path/to/«pkg» to LaTeX's search path, but that will never happen :)) > 3. How to force precompilation to occur in the default-directory instead > of in /tmp: > >Based on 1 and 2, the easiest way would be to add an \input{} or >\include{} statement to the preamble. The current test is very >simple, you can even place it in a LaTeX comment and it should work. This does indeed work; thanks! Tony -- Tony Zorman | https://tony-zorman.com/
Re: Using org-latex-preview in other major modes
On Tue, Apr 09 2024 22:06, Tony Zorman wrote: > As a very brief summary, one currently needs to—in addition to supplying > a preamble and a way to recognise maths and environments—patch the > following functions: > > · org-latex-preview--place-from-elements > · org-latex-preview-auto--regenerate-overlay > · org-latex-preview-auto--maybe-track-element-here > · org-latex-preview-live--ensure-overlay > > The last two are only needed for the "live" part of the live previews to > work. > > I will clean the code up a little bit (hopefully by the weekend, but no > promises), Whoops! Anyways, before I put this off for much longer, there is some more code attached. Live previews (and general environments) work now, and besides the above mentioned points there were no new surprises waiting—at least for getting the basic functionality to work. I did notice that precompilation being a bit flaky. In the end, this was the result of importing local packages; with the precompilation happening somewhere in /tmp/, access to these files wasn't given. I haven't looked too closely into this—and it's probably a use-case that's specific to LaTeX-mode—but it seems worth considering (lots of people carry one big style file around that they include in all of their projects). Tony latex-latex-preview.el Description: application/emacs-lisp -- Tony Zorman | https://tony-zorman.com/
Re: Using org-latex-preview in other major modes
On Sun, Apr 07 2024 23:36, Karthik Chikmagalur wrote: > You can ignore `org-latex-preview-live--src-buffer-setup', this is for > previewing when using `org-edit-special' (C-c '), which does not apply > to any other major mode. So `org-latex-preview-live--ensure-overlay' is > the only function you need to rewrite, which should be easy. Oh, indeed, you are right; seems like it only looked intimidating! I quickly hacked this in just now, and it works just fine. As a very brief summary, one currently needs to—in addition to supplying a preamble and a way to recognise maths and environments—patch the following functions: · org-latex-preview--place-from-elements · org-latex-preview-auto--regenerate-overlay · org-latex-preview-auto--maybe-track-element-here · org-latex-preview-live--ensure-overlay The last two are only needed for the "live" part of the live previews to work. I will clean the code up a little bit (hopefully by the weekend, but no promises), and try to add support for LaTeX environments instead of just maths. I reckon that once this is finished one can get a pretty good idea in which direction org-latex-preview.el would need to be nudged to more easily facilitate this kind of integration. After that I guess there's still the issue of caching and numbering, but I'll cross that bridge once we get to it :) Tony -- Tony Zorman | https://tony-zorman.com/
Re: Using org-latex-preview in other major modes
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/
Using org-latex-preview in other major modes
Hi, I'm interested in adjusting org-latex-preview to work in other major modes (most notably LaTeX-mode itself, so one can get rid of preview.el). On the advice of Karthik (Cc'd) I'll move the discussion from private mails to this list, so more people who might be interested can join in. 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'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. 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. Tony [1]: https://abode.karthinks.com/org-latex-preview/latex-preview-everywhere.html latex-latex-preview.el Description: application/emacs-lisp -- Tony Zorman | https://tony-zorman.com/
Re: The org--math-p advice around texmathp
On Sat, Mar 16 2024 10:07, Ihor Radchenko wrote: > In Org mode, there is a significant difference between \alpha and > \(\alpha\). The former is natively fontified (with `org-pretty-entities' > set to t) and natively exported to HTML/ASCII/ODT/etc. In contrast, > \(\alpha\) is very generic and Org mode has to invoke LaTeX, and > transform the contents into an image to render it. This includes export. > > So, plain \alpha entity is generally more universal when in Org mode. That's fair enough, I didn't know about org-pretty-entities! I guess for me org-cdlatex-mode was always something to insert *LaTeX* in Org, and not arbitrary Unicode (especially since there's currently no check in place that verifies whether the entered symbol can actually be rendered correctly via org-pretty-entities and cdlatex-math-symbol can insert arbitrary LaTeX code) > Further on the topic of the advice, the original texmathp has no idea > about Org-mode's syntax. If you have something like > > Verbatim text: =\(= followed by \alpha \) > > Then, (texmathp) will return non-nil on "\alpha" disregarding Org mode's > syntax. Ah indeed, this is a good point. I guess I would wish for more granular advice, but I recognise the difficulty in getting this exactly right. Thanks for your patience! Tony -- Tony Zorman | https://tony-zorman.com/
Re: The org--math-p advice around texmathp
On Fri, Mar 15 2024 14:14, Ihor Radchenko wrote: > Tony Zorman writes: > >>> Because Org mode syntax is not LaTeX and `texmathp' assumes that we are >>> inside >>> LaTeX buffer. So, we first check using Org syntax whether the point is >>> inside latex fragment in Org sense. >> >> But isn't what Org calls LaTeX math pretty equivalent to what would >> count as the same in a LaTeX buffer? From a quick scan of texmathp.el, I >> couldn't actually see a hard-dependency on a TeX-derived mode at all. I >> wouldn't really care about this so much, but the fact that the Org >> variant just misreports the position is a bit unfortunate, in my >> opinion. > > No, there is a difference. > > For example, something like \alpha is a valid Org mode entity. > Without `org--math-p' advice, if you do "`a" in Org buffer with > org-cdlatex-mode, you will see $\alpha$ inserted. With the advice, just > \alpha will be inserted. > > There are likely other similar edge cases. > > We would not choose to advice third-party function without a strong > reason. I believe you, but apparently I still haven't really understood the point of the advice. For example, I would think it's expected behaviour that "`a" in a string produces "\(\alpha\)" with CDLaTeX; indeed, so far I thought it was just a bug that it didn't! Likewise, that a standalone `a produces \alpha instead of \(\alpha\). Why is this not expected behaviour in Org? Tony -- Tony Zorman | https://tony-zorman.com/
Re: The org--math-p advice around texmathp
On Wed, Mar 13 2024 12:58, Ihor Radchenko wrote: > Tony Zorman writes: > >> I recently stumbled upon the fact that Org has some around advice for >> texmathp: org--math-p. For reasons that aren't entirely clear to me, >> this has some special handling for cdlatex-math-symbol, and recognises >> display and inline maths environments on its own, only calling out to >> texmathp if it could not find anything. In the former cases, it also >> populates the texmathp-why variable, although the position is just >> filled in with 0. >> >> I suppose my succinct question is: why? Is there any advantage in >> handling inline and display maths in this way, only deferring to >> texmathp as a last resort? I'm asking because I wrote a small package to >> switch between environments, and the position information that >> texmathp-why provides is very useful in choosing the closest >> environment. > > Because Org mode syntax is not LaTeX and `texmathp' assumes that we are inside > LaTeX buffer. So, we first check using Org syntax whether the point is > inside latex fragment in Org sense. But isn't what Org calls LaTeX math pretty equivalent to what would count as the same in a LaTeX buffer? From a quick scan of texmathp.el, I couldn't actually see a hard-dependency on a TeX-derived mode at all. I wouldn't really care about this so much, but the fact that the Org variant just misreports the position is a bit unfortunate, in my opinion. Tony -- Tony Zorman | https://tony-zorman.com/
The org--math-p advice around texmathp
Hi, I recently stumbled upon the fact that Org has some around advice for texmathp: org--math-p. For reasons that aren't entirely clear to me, this has some special handling for cdlatex-math-symbol, and recognises display and inline maths environments on its own, only calling out to texmathp if it could not find anything. In the former cases, it also populates the texmathp-why variable, although the position is just filled in with 0. I suppose my succinct question is: why? Is there any advantage in handling inline and display maths in this way, only deferring to texmathp as a last resort? I'm asking because I wrote a small package to switch between environments, and the position information that texmathp-why provides is very useful in choosing the closest environment. Thanks! Tony -- Tony Zorman | https://tony-zorman.com/
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
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/