Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error Processing LaTeX stems #326

Closed
dillonredding opened this issue Sep 2, 2019 · 9 comments
Closed

Error Processing LaTeX stems #326

dillonredding opened this issue Sep 2, 2019 · 9 comments
Assignees
Labels

Comments

@dillonredding
Copy link

dillonredding commented Sep 2, 2019

When using the following STEM block using latexmath, the previewer displays "[Math Processing Error]" in red italics:

:stem:

[latexmath]
++++
\begin{align*}
f(x) &= x^2 + x^2\\
     &= 2x^2
\end{align*}
++++

I expect this to display what's displayed when compiling the AsciiDoc using the asciidoctor CLI. This does work sometimes, but not always. It also doesn't happen for every latexmath STEM block. It seems to be breaking on the \begin{align*}...\end{align*} commands. I haven't figured out what triggers it start working, but when it does work, it starts breaking after editing the document.

AsciiDoc Plugin Version: 0.29.10

IDE Name and Version:
IntelliJ IDEA 2019.2.1 (Community Edition)
Build #IC-192.6262.58, built on August 20, 2019
Runtime version: 11.0.3+12-b304.39 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 980M
Cores: 4
Registry:
Non-Bundled Plugins: CMD Support, Lombook Plugin, org.asciidoctor.intellij.asciidoc, com.cursiveclojure.cursive, izhangzhihao.rainbow.brackets, in.1ton.idea.spring.assistant.plugin, org.jetbrains.spek.spek-idea-plugin, org.zalando.intellij.swagger

@dillonredding
Copy link
Author

It appears to start working after commenting and uncommenting the STEM block.

@ahus1
Copy link
Contributor

ahus1 commented Sep 2, 2019

Thanks for reporting this. I'll look into it.

As a workaround: please enable uncheck the setting "Replace preview contents without flicker (JavaFX preview only)" for a more robust preview generation.

Using this option the preview will flicker, but the error will not show up. I'll update this issue once a fix is available.

@ahus1 ahus1 self-assigned this Sep 2, 2019
@ahus1 ahus1 added the bug label Sep 2, 2019
ahus1 added a commit that referenced this issue Sep 2, 2019
…h problems, plus popup hint with MathML error message in preview (#326)
ahus1 added a commit that referenced this issue Sep 3, 2019
@ahus1
Copy link
Contributor

ahus1 commented Sep 3, 2019

@dillonredding - a new pre-release 0.30.2 is available that fixes this issue.

latexmath-style formulas are now displayed correctly. The new pre-release of the plugin is available from GitHub releases and the IntelliJ AsciiDoc EAP repository.

I've also added a feature that when the latexmath-parsing fails, the error message is directly visible in the preview.

Please let me know if this works for you. I'll then publish the version for everyone else.

math-error

@dillonredding
Copy link
Author

@ahus1 I tried the early access version and it appears to work! Thanks!

I did notice, however, that the preview seems to slow down significantly after awhile. Not sure if it's because of multiple STEM blocks or just having it open after some amount of time. I tried removing a majority of the content, but the previewer didn't speed up any.

@ahus1
Copy link
Contributor

ahus1 commented Sep 5, 2019

@dillonredding thank you for this information.

How many math elements do you have in the preview (current file and maybe included files)? The number of equations will slow down the preview.

How long is the lag from keystroke to preview refresh in seconds? With mathml there is a lag, but I try to keep it below one second. This might vary on hardware type and document size.

Is the preview faster again when you close the editor and reopen the editor (just the editor of the current file)? This action will initialize the preview and would clear any memory leaks that might be there.

How long does it take for the preview to get slow (please estimate the number of characters typed if that is possible, as it is an equivalent of how the preview needs to refresh)?

Your answers will help me to investigate this. Thanks!

@dillonredding
Copy link
Author

I started IntelliJ back up and it took about 2 seconds for the previewer to render everything after it was finished initializing. This is much faster than what I was seeing two days ago.

I started with 167 stemss in a 7533 character file (no includes). After about 20 minutes (not sure that matters) of editing, I added 10 stems and 260 characters and the previewer slows down to about 3 seconds. This was just adding content. This was adding, then removing, maybe some editing of other parts here and there.

It seems to get worse as I add more. I noticed that if I take it down to one stem, it seems to speed back up. Not sure if it matters, but most of my stems are inline.

I'm running all this on a laptop with these specs:
Processor: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz 2.20GHz
Installed RAM: 8.00 GB

It's probably worth noting that I updated IntelliJ before doing all this. Here's the info:
IntelliJ IDEA 2019.2.2 (Community Edition)
Build #IC-192.6603.28, built on September 6, 2019
Runtime version: 11.0.3+12-b304.56 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 980M
Cores: 4
Registry:
Non-Bundled Plugins: CMD Support, Lombook Plugin, org.asciidoctor.intellij.asciidoc, com.cursiveclojure.cursive, izhangzhihao.rainbow.brackets, in.1ton.idea.spring.assistant.plugin, org.jetbrains.spek.spek-idea-plugin, org.zalando.intellij.swagger

@ahus1
Copy link
Contributor

ahus1 commented Sep 7, 2019

Thank for for answering the questions.

I did some local tests reproduced the slowdown. There must have been a memory leak triggered on every refresh of the preview. The refresh of the preview is triggered on every edit. While MathML is quite slow, it grew slower with every edit.

A new preview version 0.30.3 is available that shouldn't slow down any more. Please give it a try. This now waits up to three seconds for the refresh to complete. With a single stem the preview should be well below one second, with your number of stems I hope it will stay below three seconds.

The lag of the preview correlates with the number of stems. You might want to consider breaking down your document into smaller chapters. Smaller chapters will allow for a faster preview. A master document can the in include the different chapters.

At the moment the preview is refreshed completely even for small text changes. Due to the nature of MathML future versions might cache MathML to speed up the preview on text-only changes. I need to find out if this is possible. It would take some effort and time to complete, and I wouldn't be a able to tell when it be available.

Another option would be to add an option in the plugin's configuration to disable math. This could be a straight-forward option with a short lead-time that could be implemented in one of the upcoming pre-releases.

Please let me know what you would prefer from a user's point of view. Thanks!

@ahus1 ahus1 changed the title Error Processing LaTeX Error Processing LaTeX stems Sep 7, 2019
@dillonredding
Copy link
Author

Thanks for the update! I'll try it out next chance I get and let you know.

I like the idea of separating out "chapters" into individual files! That might be my preferred option.

The option to disable math might be useful, but not for my scenario. I want to see the rendered math without having to compile the document each time.

Would it be possible to only refresh the part of the preview being viewed, rather than the entire thing?

@ahus1
Copy link
Contributor

ahus1 commented Sep 17, 2019

I consider the original issue to be fixed. To optimize the speed of the preview I've opened #333

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants