Troubleshooting Common Problems
This is caused by an incorrect parent scheme setting in your custom scheme. The custom scheme
file can be found in the color subdirectory of the JetBrains product you are using and the
file will have the name of your scheme and a .icls extension.
For a dark scheme the first line should have Darcula as the parent_scheme attribute: <scheme name="YourSchemeName" version="142" parent_scheme="Darcula">.
If it is Default then you need to change parent_scheme="Default" to
parent_scheme="Darcula". Otherwise, the IDE uses the wrong default colors from the plugin
default color map. This would also affect other custom language plugins not just
idea-multimarkdown.
Here is an example of a custom dark scheme with parent_scheme="Default" on the left and
parent_scheme="Darcula" on the right:
This is usually caused by caches being corrupt and is not noticed after installing a new custom language plugin that requires re-indexing. Invalidate caches and restart. If the problem persists please open an issue in GitHub: GitHub Issues
JavaFx WebView preview requires JDK 1.8.0u40 or later that includes jfxrt.jar in the JDK's
lib/ext directory, which is its standard location.
If jfxrt.jar is not found or the plugin cannot create the new editor class due to errors, it
will fall back to using the Swing preview browser: JEditorPane with HTMLEditorKit preview.
If you change the boot JDK, see Changing Boot JDK for instructions, and want the plugin to
use the new preview, deselect the User Old Preview in Preferences > Other Settings >
MultiMarkdown.
In order for the links in the preview tab to resolve to corresponding files on GitHub the file must be under a git vcs root, the directory where target files are located must be part of the project's files and not marked as excluded.
Multiple vcs roots are supported. A file is considered under the vcs root that is above it in
the directory hierarchy. Files with status UNKNOWN, IGNORED and ADDED are considered not
to have remote counterparts.
For all files that don't have remote counterparts the links will resolve to local files. This includes files that were added but not yet committed.
Relative links from GitHub markdown documents in main the repository to wiki pages should be
prefixed with ../../wiki because the documents in the root of the main repository are located
at /blob/branch and wiki pages are in /wiki. The same applies to issues, pulls, graphs,
pulse. Relative links will resolve to the same pages as they would on GitHub using the same
relative links.
If you are clicking on a link that you expect to have a remote but a local file opens then the
file does not resolve to a remote as far as the plugin is concerned. It could be because the
remote origin has no URL that is an http: or https: protocol or it lacks a .git extension. Also
the file should have been committed at least once so that it looses its ADDED status.