Bug report: Dataview Picking Up Backslash \ in Inline Field

[SlRvb]

What happened?

While using inline fields from dataview in a table with an alias, it seems the escape character \ is being picked up and dataview seemed to be unable to find a note because of the backslash applied to it:

| Table | Test |
|---|---|
| Field | (Field:: [[DV File 1\|Inline Syntax Formatting]])

Field:: [[DV File 2\|Inline Syntax]]

Field:: [[DV File 2|Not Escaped File]]

The file on the right is linked to the file on the left, but doesn't appear in the dataview list because of the escaped link.

Figured out it was a dataview issue with the dataview query below. Using this.file.link doesn't find the note since it's not DV File 1, the inline field reads the link as DV File 1\ which doesn't exist.

---

Issue discovered initially when using breadcrumbs: https://github.com/SkepticMystic/breadcrumbs/issues/386

DQL

TABLE WITHOUT ID Field
FROM ""
WHERE contains(Field, this.file.link)

JS

No response

Dataview Version

0.5.9

Obsidian Version

0.14.7

OS

Windows

[blacksmithgu]

Bad link parser implementation; thanks for flagging.

[SlRvb]

Hmm, updating to 0.5.23, it seems like the issue still persists. Also the inline syntax is broken when there's a link inside of it.

(Above:: Test)
**(Above:: Test)**

> [!Metadata|i-at]
> **(Story:: Testing)**
> (Above:: Test)

---
> [!Metadata|i-at]
> **(Story:: Testing)**
> (Above:: [[Test Bench]])

(Above:: [[Test Bench|Test]])
(Above:: [[Test Bench\|Test]])

[blacksmithgu]

The rendering issue appears to be Obsidian - I get it even for basic escaped links like [[Hello\|There]] (which still renders a "There" in Obsidian).

Also, now that I looked at this again, how are you even using "|" in files? Obsidian prevents it in file names.

[SlRvb]

Also, now that I looked at this again, how are you even using "|" in files? Obsidian prevents it in file names.

It's not actually in the file name, it's an alias. I generally use it because my files have ugly prefix stuff, but I only want to see a simplified name. So instead of SL-M-A - Worlds as an ugly looking link, I just get Worlds from [[SL-M-A - Worlds|Worlds]]. It's not actually the file name since pipes aren't allowed by my OS either.

Wanting the escapes to work is so that I can have this alias syntax work with tables and not break 🙈

The links only really break with an escaped pipe [[File name\|Alias]] as it seems to include the pipe and alias with it, The regular aliased link [[File name|Alias]] seems to do alright in the previous and newer console log screenshots with finding the file path 🤔

[blacksmithgu]

I adjusted the way links render in 0.5.26 to properly escape when being printed, which may help? I have tests which explicitly check link parsing with escapes and the functionality at least mostly seems to work - do you have a case which breaks?

[SlRvb]

So I'm on dataview 0.5.26 which has made some stuff go a little more haywire 😵‍💫 (visible in the genre column of the query)

My query is just this, basically look for songs where the album field links back to the current note:

```dataview
TABLE WITHOUT ID 
    link(file.link, Alias) AS Song, 
    N AS "\#", 
    Genre,
    Year
FROM "30 Projects/Music/Songs"
WHERE contains(Album, this.file.link)
SORT N asc

Which works for the file `Meridian Ambit` since the album link doesn't have an escaped alias, but the others don't show up as they're escaped and are thus read as `SL-M-A - Worlds|Worlds` which is a file that doesn't exist so there's no file.link or file.path for the query to grab even though the file `SL-M-A - Worlds` exists and is linked. The escaped link isn't parsed to read the part before `\|` to search for that it seems so it breaks my query.

![Obsidian_cGtEmVfCKz](https://user-images.githubusercontent.com/54087190/172038354-8658674c-e2e8-49e1-b76e-fa6397fa07de.png)

Removing the escape `[[SL-M-A - Worlds|Worlds]]` does work, but since there's a pipe, it breaks the link visually in the table 🥴 

![Obsidian_lOLlecD8uF](https://user-images.githubusercontent.com/54087190/172038456-c5b56f89-54e2-4911-bded-580ef0c1d5be.png)