Karthik Chikmagalur <[email protected]> writes:

> I got confused because we were discussing live-preview behavior in
> org-src buffers.  The behavior of live-preview re: latex export blocks
> is a new issue.  I'm assuming that you could not break live-previews +
> org-src buffers after I updated the implementation of
> org-latex-preview-live--src-buffer-setup.

Yes, I could not break it after the update.

>> 1. make repro
>> 2. (require 'ob-latex) (require 'org-latex-preview) (setq 
>> org-latex-preview-live t)
>> 3. Open the above
>> 4. M-x org-latex-preview-mode
>> 5. C-c C-x C-l
>> 6. Note that equations inside #+begin_export... are NOT previewed
>> 7. Go to begin_src, C-c C-c
>> 8. Observe equation inside begin_export results being previewed
>
> Okay, I can reproduce this.  I can't find a way to fix it though.  Here
> is what's happening.  When I hit C-c C-c inside
>
> #+begin_src latex
>   \(x = z\)
> #+end_src
>
> ob-latex first inserts the result as a latex fragment, not an export
> block:
>
> #+begin_src latex
>   \(x = z\)
> #+end_src
>
> #+RESULTS:
> \(x = z\)
>
> When this happens, the after-change-handler for live-previews calls
> (org-element-context) and sees a latex-fragment, not an export block.
> So it renders the preview.
>
> In a separate buffer change afterwards, the export block delimiters are
> added, turning it into
>
> #+begin_src latex
>   \(x = z\)
> #+end_src
>
> #+RESULTS:
> #+begin_export latex
> \(x = z\)
> #+end_export
>
> Now the (org-element-context) returns an export-block element, but it is
> too late.  The preview has already been generated.

What you describe might happen as a part of normal or programmatic
editing as well, so the problem may not be limited to ob-latex.

> There are two ways I can see to fix this:
>
> - Make ob-latex/org-babel-insert-result insert the full result (export
> latex block containing the fragment) in one `insert' call.
>
> - Make a special case in
> org-latex-preview-mode--maybe-track-element-here to check if the
> insertion is happening in the vicinity of a #+RESULTS marker.  This is a
> heuristic/hack that can fail in many ways, and it will slow down buffer
> tracking for live previews, so I don't want to do this.
>
> If you have any ideas let me know.

One way will be postponing after-change handling to
post-command-hook. You can make use of track-changes to further simplify
things.

Another way is refusing to apply the overlay image when no longer on
latex fragment.

>> Also, I note that make repro complains about org-loaddefs on olp
>> branch. Not sure what is going on, but it is not the case on main.
>
> Here is the output of make repro for me:
> ...
>
> What should I be looking for here?

Look at the Emacs instance spawned by make repro. It will say

   For information about GNU Emacs and the GNU system, type C-h C-a.
   WARNING: No org-loaddefs.el file could be found from where org.el is loaded.
   You need to run "make" or "make autoloads" from Org lisp directory
   Org mode version 9.8-pre (release_9.7.39-911-g52ca57 @ 
/home/yantar92/Git/org-mode/lisp/)


-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Reply via email to