File does not exist when imagesdir is a remote URL

[ggrossetie]

I get an error when I'm using a remote URL as imagesdir.

= Introduction to Cypher
:imagesdir: https://raw.githubusercontent.com/neo4j-contrib/training-v3/58eef39b7199b58bd7d5679c348c0871a375b9f5/modules/demo-intro/images/

image::Properties.png[Overview,align=center]

Please note that the image exists but I don't think the extension should check if a remote image exists or not: https://raw.githubusercontent.com/neo4j-contrib/training-v3/58eef39b7199b58bd7d5679c348c0871a375b9f5/modules/demo-intro/images/Properties.png

In fact, the image could be unavailable from localhost but available from where the document will be published, so the error will be annoying.

AsciiDoc Plugin Version

0.30.74

IDE Name and Version

IntelliJ IDEA 2019.3.5 (Ultimate Edition)
Build #IU-193.7288.26, built on May 6, 2020
Runtime version: 11.0.6+8-b520.66 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.15.0-101-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 1981M
Cores: 8
Registry: 
Non-Bundled Plugins: BashSupport, Batch Scripts Support, CMD Support, CheckStyle-IDEA, FindBugs-IDEA, JFormDesigner, com.dmarcotte.handlebars, com.intellij.ideolog, com.jetbrains.lang.ejs, com.jetbrains.plugins.jade, com.wix.eslint, org.asciidoctor.intellij.asciidoc, org.intellij.scala, org.jetbrains.idea.grammar, org.jetbrains.kotlin, org.jetbrains.plugins.slim, org.jetbrains.plugins.ruby

[ahus1]

Thanks for raising this issue. I wonder how common a remote imagesdir is. Is it an exception, or a common case?

If it is an exceptional case, the user could add to this image (or the whole file) an override:

// suppress inspection "AsciiDocLinkResolve"
image::Properties.png[Overview,align=center]

If it is a common case, I'll try to evaluate the imagesdir (it might be defined in the current file, but it might be defined in a different place where this file is being included).

[ggrossetie]

The imagesdir attribute is available on the document. But we already resolve the image target no? I think it's important to resolve the image target otherwise we will return a lot of false positives.

Also, as soon as the target is a remote URI we should disable the checks. The examples below should not produce an error:

image::https://path.to/img/cat.png[]

:imagesdir: https://path.to/img/

image::cat.png[]

Please note that you can also use data-uri as target.

Another issue is that the images could be copied by a build tool to a local or remote target. In other words, the link to the image is correct but only when the document is "published" to the "output" location.

I think this check is only accurate/useful when the images are resolved relative to the document in both the workspace and the output location no?

If it is an exceptional case, the user could add to this image (or the whole file) an override:

I don't like this workaround, it forces users to put a suppress inspection whereas they did nothing wrong. At the very least we should provide an option to disable this feature if we don't want or cannot resolve the image target properly.

[ahus1]

The next version will handle the case where the imagesdir is set before the image in the same file and will not trigger an error in the editor.

An image starting with a URI of http(s)/file/ftp/irc is already excluded in the current version. I'll add the data-URI to that.

Some background on the implementation: The reasoning is done on an AST, not on a rendered document.

If the user uses a build tool that copies files around, the user can disable this inspection in their IDE settings in "inspections". There is a shortcut in the editor as well, see below:

[ahus1]

Pre-release 0.30.75 is available fixes the following: no error is shown when the image references an URI, or an imagesdir is defined in the same file before the image.

The new pre-release of the plugin is available from GitHub releases and the IntelliJ AsciiDoc EAP repository.