horizontal line breaks (ASCII) breaks dataview in text code blocks

[paxsali]

What happened?

Hi all,

there is apparently a bug in dataview that causes the builtin PDF export funtion in obsidian to output trash near the end of the exported document (random dataview error messages).

The funny thing is that the markdown file I used doesn't even use dataview, so I guess that's a prio 1 bug, if it breaks Obsidian itself without using dataview.

I am using Obsidian for technical documentation of changes (commands & their outputs).

Recently I had the following, reproducable bug:

Bug descriptions

Step 1) Take the following body (copy as markdown!) and put it in a markdown document:

<====== cut here and copy as Markdown (!!!), meaning add triple backticks to the code blocks (first code block = bash, second = text) as I cannot print markdown in markdown 1:1!

Command:

mkdir v11.5.7_linuxx64_client
tar xf v11.5.7_linuxx64_client.tar.gz -C v11.5.7_linuxx64_client
chown -R root:root v11.5.7_linuxx64_client
cd v11.5.7_linuxx64_client/client

./db2prereqcheck -c -v 11.5.0.0

Output:

==========================================================================

Tue Jul 26 11:23:16 2022
Checking prerequisites for DB2 installation. Version "11.5.0.0". Operating system "Linux" 
   
Validating "Linux distribution " ... 
   Required minimum operating system distribution: "SUSE"; Version: "12"; Service pack: "3". 
   Actual operating system distribution Version: "12"; Service pack: "4". 
   Requirement matched. 
   
Validating "kernel level " ... 
   Required minimum operating system kernel level: "3.10.0". 
   Actual operating system kernel level: "4.12.14". 
   Requirement matched. 
   
Validating "C++ Library version " ... 
   Required minimum C++ library: "libstdc++.so.6" 
   Standard C++ library is located in the following directory: "/usr/lib64/libstdc++.so.6.0.28". 
   Actual C++ library: "CXXABI_1.3.1" 
   Requirement matched. 
   

Validating "32 bit version of "libstdc++.so.6" " ... 
   Found the 32 bit "/usr/lib/libstdc++.so.6" in the following directory "/usr/lib". 
   Requirement matched. 
   
Validating "libnuma.so version " ... 
DBT3610I  The db2prereqcheck utility successfully loaded the libnuma.so.1 file. 
   Requirement matched. 
   
Validating "/lib/libpam.so*" ... 
   Requirement matched. 
DBT3533I  The db2prereqcheck utility has confirmed that all installation prerequisites were met.

<==== until here

Step 2) try to print the markdown document as PDF using the builtin PDF export function.

Step 3) by default the produced PDF automatically should open and then scroll to the very bottom of the PDF and see the trailing dataview error messages:

Example of the trailing dataview error messages (inside the PDF document):

Dataview (inline field
'=============================================================
============
Tue Jul 26 11:23:16 2022
Checking prerequisites for DB2 installation. Version
"11.5.0.0". Operating system "Linux"
Validating "Linux distribution " ...
Required minimum operating system distribution: "SUSE";
Version: "12"; Service pack: "3".
Actual operating system distribution Version: "12"; Service
pack: "4".
Requirement matched.
Validating "kernel level " ...
Required minimum operating system kernel level: "3.10.0".
Actual operating system kernel level: "4.12.14".
Requirement matched.
Validating "C++ Library version " ...
Required minimum C++ library: "libstdc++.so.6"
Standard C++ library is located in the following directory:
"/usr/lib64/libstdc++.so.6.0.28".
Actual C++ library: "CXXABI_1.3.1"
Requirement matched.
Validating "32 bit version of "libstdc++.so.6" " ...
Found the 32 bit "/usr/lib/libstdc++.so.6" in the following
directory "/usr/lib".
 Requirement matched.
Validating "libnuma.so version " ...
DBT3610I The db2prereqcheck utility successfully loaded the
libnuma.so.1 file.
Requirement matched.
Validating "/lib/libpam.so*" ...
Requirement matched.
DBT3533I The db2prereqcheck utility has confirmed that all
installation prerequisites were met.'): Error:
-- PARSING FAILED --------------------------------------------
------
> 1 |
==============================================================
===========
| ^
2 |
3 | Tue Jul 26 11:23:16 2022
Expected one of the following:
'(', 'null', boolean, date, duration, file link, list ('[1, 2,
3]'), negated field, number, object ('{ a: 1, b: 2 }'),
string, variable

Expecations

I'd naively expect if I don't use dataview blocks or directives, that my PDF is produces normally.

Workaround

Temporarily disable dataview, export document to PDF => the resulting PDF is correct now.

Synopsis

From what's self-evident is that the one line with the horizontal "====== ..." line break of equal signs causes dataview to spasm for no apparent reason. To me personally, it's not even obsvious why dataview is involved here at all, TBH.

That's all.

Environment

Using Obsidian v0.15.9 on Windows 10. Using Dataview v0.5.41.

If you need more info I can provide.

DQL

No response

JS

No response

Dataview Version

0.5.41

Obsidian Version

0.15.9

OS

Windows

[blacksmithgu]

Dataview is interpreting the codeblock starting with ============================... as an inline dataview query and attempting to evaluate it. I suspect you would see the dataview errors in Read mode, or in the upcoming Dataview errors which evaluates inline queries in Live Preview.

You can fix this by either (1) turning off inline queries in settings, or (2) changing the inline queries prefix to something less conflicting like dv=.

[paxsali]

I changed the inline query strings to dataview-inline-query= and dataviewjs-inline-query= to make it less probable that such a thing happens again.

[paxsali]

IMHO, there needs to be a change with the defaults of obsidian-dataview.

When I encountered this issue at first, I was under the assumption that I'm not using the dataview plugin at all, which is the main reason why I was so confused about this error.

This assumption was based on the fact that I didn't include a code block with dataview as it's language manually.

I believe it is not an unreasonable assumption to make and it's certainly unintuitive to the vast majority of obsidian users, why dataview was triggered in that instance.

Having merely a = at the beginning of any line inside code blocks trigger the inline query of dataview is "too loose/common/unspecific" and therefore an unnecessary risk to break the user experience in other parts of the software.

The workaround has been described in my previous post.

It's best if the authors waited for the next dataview release with breaking changes and use that as an opportunity to also roll out new default prefixes for the inline queries, idealy with a proper warning to users on the plugin's page that they need to adjust their previous inline queries to the new defaults.

I say this because obviously changing the defaults will break any existing users' documents which make use of dataview inline queries, so there is no quick and dirty solution to this problem, unfortunatelly.

IMHO, the current inline query trigger prefixes were of bad taste/short-sighted to begin with, and I know that's easy to say in retrospec.

I'm closing this issue right now as the workaround will help any users who come across it.