Alternating inline fields are invisible when using Dataview Format

[Chris-Andrews]

Please check that this issue hasn't been reported before.

• I searched previous Bug Reports didn't find any similar reports.

Expected Behavior

All inline fields should be visible for tasks in the default editing mode (live preview)

Current behaviour

When Dataview Format is used and multiple task parameters are set (priority, due date, start date, etc.), pairs of parameters are interpreted as reference-style links. The effect is that every even-numbered parameter is invisible. An example is provided in the first task for the image below.

Steps to reproduce

With Dataview Format enabled, use the create/edit task function to create a task with all of the properties set (like above). When two Dataview Format properties are next to each other, the second one will not be visible in live preview.

Which Operating Systems are you using?

• Android
• iPhone/iPad
• Linux
• macOS
• Windows

Obsidian Version

v1.1.16

Tasks Plugin Version

3.3.0

Checks

• I have tried it with all other plugins disabled and the error still occurs

Possible solution

Two possible workarounds are shown in the image above. One is to have two spaces between Dataview Formatted properties, and the other is to separate them with commas.

[claremacrae]

Hi @Chris-Andrews

Many thanks for taking the time to log this.

Steps to reproduce

With Dataview Format enabled, use the create/edit task function to create a task with all of the properties set (like above).

Please supply text for the tasks you showed above. Thank you.

[kedestin]

Please supply text for the tasks you showed above. Thank you.

- [ ] Single space [priority:: medium] [created:: 2023-04-24 ] [start:: 2023-04-25] [due:: 2023-04-26]
- [ ] Two spaces [priority:: medium]  [created:: 2023-04-24 ]  [start:: 2023-04-25]  [due:: 2023-04-26]
- [ ] Comma seperated [priority:: medium], [created:: 2023-04-24 ], [start:: 2023-04-25], [due:: 2023-04-26]

I can repro this issue with the text above, with or without Tasks installed. This is reproducible in a vault with no plugins so long as live preview is enabled.

---

I would've assumed this would have been reported on Dataview's repo before, but searching any of [invisible, disappear, reference-style link] doesn't bring up any relevant results.

I think the easiest "fix" would be to add a warning in the docs and endorse one of the workarounds (two spaces would work with no code changes), unless there is a non-hacky way to tell Obsidian "this isn't actually a reference style link".

[claremacrae]

Wow, many thanks @Chris-Andrews for reporting this and the workarounds, and @kedestin for giving the text.

I think the easiest "fix" would be to add a warning in the docs and endorse one of the workarounds (two spaces would work with no code changes), unless there is a non-hacky way to tell Obsidian "this isn't actually a reference style link".

If we recommend two spaces, I think auto-suggest and the Edit task modal will need to be changed to write two spaces out.

The problem currently with the comma idea is that it prevents Tasks parsing the fields...

If we were to fix the parsing to allow text in between fields, as is requested elsewhere, I think that after the user has edited the task, the current code would put all the fields/properties after all the commas and the problem would reappear again.

I played with different dataview settings around whether to do inline highlighting - and none of it helped.

I'll ask in the dataview channel on Obsidian Discord to see what others do...

[claremacrae]

I'll ask in the dataview channel on Obsidian Discord to see what others do...

https://discord.com/channels/686053708261228577/1014259487445622855/1100358299028828181

[kedestin]

If we recommend two spaces, I think auto-suggest and the Edit task modal will need to be changed to write two spaces out.

I'll see what I can do

The problem currently with the comma idea is that it prevents Tasks parsing the fields...

If we were to fix the parsing to allow text in between fields, as is requested elsewhere, I think that after the user has edited the task, the current code would put all the fields/properties after all the commas and the problem would reappear again.

I had already started on implementation of #1505 and have a proof of concept working, but dropped it soon after realizing that it:

• Would probably also require that Tasks is smart about how it edits an existing Task: If a user uses the edit modal to update the due date of - [ ] This task is [due::2023-04-25] and has [priority::high], the expectation would probably be that the position of the due date is preserved within the task. This could be implemented by:
  • Preserving signifiers in a task description, so you can keep track of where they were. (This is a breaking change)
  • Adding a bunch of bookkeeping so that signifiers continue to be removed from descriptions, but we know where they were.
• Would likely require a full rewrite of DefaultTaskSerializer, DataviewTaskSerializer and a partial rewrite of whatever code depends on DefaultTaskSerializer.componentToString.
  • Parsing recurrences in arbitrary positions in the emoji format is particularly challenging given that it's natural language text, and the parsing code is owned by a dependency.

There may be more that I'm not remembering off the top of my head.

---

I'd rather not leave folks in a poor state w.r.t Dataview support, so I'd be willing to keep working on this if we decide it's the best course of action.

[claremacrae]

There was a suggestion on Discord that I think might be a good workaround...

one question. if you use regex to search for the inline fields, then couldn't you just include the , after the [] too?

[claremacrae]

@kedestin thanks for a very helpful comment... I do agree that we are straying in to #1505 territory, so will quote your above comment there and then reply there...

[claremacrae]

I'd rather not leave folks in a poor state w.r.t Dataview support, so I'd be willing to keep working on this if we decide it's the best course of action.

The only thing I'd add to this is that the situation in #1913 must have existed in dataview in some time, and as far as I can see, nobody has complained about it.

I really am comfortable with documenting a known limitation that is outside Tasks' control.

Another solution might be to log this as an Obsidian bug on the Forum.

[kedestin]

There was a suggestion on Discord that I think might be a good workaround...

one question. if you use regex to search for the inline fields, then couldn't you just include the , after the [] too?

I will:

• Update the modal and suggestion behavior to add 2 spaces
• Make the parsing leninent enough to allow for commas (the commas won't be included in the description, which may lead to a breaking change if Make Tasks find signifiers even in there is text after them #1505 is implemented and includes the commas in the description)

I'd rather not leave folks in a poor state w.r.t Dataview support, so I'd be willing to keep working on this if we decide it's the best course of action.

The only thing I'd add to this is that the situation in #1913 must have existed in dataview in some time, and as far as I can see, nobody has complained about it.

When I was initially searching for reports of this, I found this repo https://github.com/dsarman/better-inline-fields, which has this gif in its README:

The gif is nearly a year old, so I assume this issue is already known and this gif is an example of someone using commas as a workaround.

I really am comfortable with documenting a known limitation that is outside Tasks' control.

Just to ask explicitly, we don't need #1505 to be implemented to close this issue?

[claremacrae]

Just to ask explicitly, we don't need #1505 to be implemented to close this issue?

Yes that's fine.

If you are on Discord, before spending much time on it, may I very gently encourage you to ask on #plugin-dev in case the Obsidian team has any ideas or if there is already a known workaround...

[claremacrae]

The fix for this has just been released in Tasks 3.5.0.

[bb010g]

I think the easiest "fix" would be to add a warning in the docs and endorse one of the workarounds (two spaces would work with no code changes), unless there is a non-hacky way to tell Obsidian "this isn't actually a reference style link".

Per the CommonMark Dingus, one space is already enough to make a link not reference-style. GitHub Flavored Markdown does not modify the spec here. This seems like an Obsidian bug.

[kedestin]

Per the CommonMark Dingus, one space is already enough to make a link not reference-style. GitHub Flavored Markdown does not modify the spec here. This seems like an Obsidian bug.

Huh, didn't realize Obsidian claimed compatibility with existing formats

Obsidian mainly uses CommonMark, with some functionality from GitHub Flavored Markdown and LaTeX.

• From: https://help.obsidian.md/Editing+and+formatting/Obsidian+Flavored+Markdown

---

Like @bb010g said, both Github's spec and the Commonmark spec forbid the space:

• Github Flavored Markdown
• Commonmark 0.30

(Both use the same example and almost the same text, so I'm only quoting Github):

No whitespace is allowed between the link text and the link label:
[...]
This is a departure from John Gruber’s original Markdown syntax description, which explicitly allows whitespace between the link text and the link label. It brings reference links in line with inline links, which (according to both original Markdown and this spec) cannot have whitespace after the link text. More importantly, it prevents inadvertent capture of consecutive shortcut reference links. If whitespace is allowed between the link text and the link label, then in the following we will have a single reference link, not two shortcut reference links, as intended:

---

@claremacrae It might be worthwhile filing this as a bug report for Obsidian. If they fix, then most of the warning in the docs can go away. Though, this would technically be a breaking change for Obsidian, so I'm unsure if they'd be willing to.

[claremacrae]

Wow, thank you very much indeed @bb010g and @kedestin - with that info I plan to log it as on Obsidian bug when I have time.

• Log Obsidian bug about too-relaxed parsing of reference style links.

[claremacrae]

Reminder logged in:

• Log Obsidian bug about too-relaxed parsing of reference style links. #1936