Inline fields multiline lists and texts

[mnaoumov]

I would like to have a nicer syntax for multiline lists in inline fields.

Right now we have two ways to define fields

front matter

---
my-list:
  - long item with commas,,,,and quotes"""" etc
  - another item
---

and inline field

my-list:: long item with commas,,,,and quotes""""
my-list:: another item

front matter approach has its own flaws with escaping single and double quotes, that I don't want to touch here

so I am more interested in the better way of handling multiline lists in inline fields with something like

my-list:: @@@
  - long item with commas,,,,and quotes""""
  - another item
@@@

@@@ -is just a marker for multiline field

This approach will also allow setting multiline text variables

my-multi-line-text:: @@@"
Really long text with any possible characters including "quotes",
line breaks

empty lines

etc
"@@@

[pjeby]

One possible way to do this would be block ids. e.g. ^my-multi-line-text at the end of a paragraph, block quote, table, list, etc. You can put arbitrary amounts of text in a block quote and then give it a block ID as a field name.

To be clear, that doesn't work now in dataview, but it's something that dataview could implement in principle without adding a lot of parsing overhead, redesigning the parser, or creating new markdown syntax, since the Obsidian metadata cache literally stores the exact positions of every ID'd block in a file and could thus extract them in a straightforward way, including turning bullet lists into actual lists of individual items.

Indeed, markdown headings could potentially be turned into fields as well, though there would need to be some mapping from header names to names that would work with DQL field access.

[blacksmithgu]

I'm still fiddling with some performance things, but Dataview does have a full markdown parser implementation now (that's just not hooked up to the indexer): https://github.com/blacksmithgu/obsidian-dataview/blob/master/src/data/parse/markdown.ts.

We can afford to be more aggressive with a real markdown parser, since it includes indentation information & other things for paragaphs. So we could simply use indented codeblock syntax:

field::
    I am an indented codeblock, which would now allow for arbitary multiline text!

[mnaoumov]

@blacksmithgu indented code blocks or maybe explicit code blocks?

field::
```
my long long
text with any characters
```

also I think your idea wouldn't work nice with lists syntax, because in code blocks lists are not rendered as lists with bullet points

field::
    - item 1
    - item2

[pjeby]

We can afford to be more aggressive with a real markdown parser

I looked over the parser and all it seems to be doing is duplicating info that you can get directly from the metadata cache without doing any parsing at all. Maybe it was written before Obsidian had the sections and listItems caches?

The file cache's sections field is a list of line ranges for all those blocks you're parsing, and the listItems field is a list of all list items and tasks, with tasks detectable by their checkbox field.

The tags field has the positions of every tag, so you can associate them with the blocks, list items, or sections (i.e. headings, in the headings field) they are in. That information is all there for free with no parsing to do, no duplication of code that might not be parsing exactly the same, no maintenance of the parser, no extra CPU overhead at startup, possibly no need for workers and the extra memory/cpu for inter-thread comms, etc. And Obsidian saves it all to disk so it's available on startup without re-parsing every file.

It's true that you'd still need to look for the existing inline field syntax within some of those blocks, but the sections field will let you skip codeblocks and blockquotes and headings and the like, and listItems will not require you to parse the indents (the ranges always start at the actual bullet) or the checkbox (if it has one, the item will have a task field with the checkbox character (space, x, or something else).

I think this would be a better direction to take than introducing new syntax as well. Being able to use the headings and list items directly as fields would be a good feature in itself, as it would allow you to do things like treat kanban board columns as list fields. Block fields are handy, too: I currently use ^do as a block ID on things so I can embed the next action for a note in other lists. Being able to use the same field in queries would be nice.

[zsviczian]

I see this feature-request has been quite since January. This would make list of links in a field much more readable.

From my very limited perspective if the following list format would be supported that would drastically improve readability of long list:

field::
- [[Item 1]]
- Item 2
- [[Item 3]]

[Sigbert11]

Are there any updates on the timeline of this feature request? inline object declaration or at least the above list syntax would mean such a boost of workflow in noting on-the-fly definitions like

defintionsForTopicX::
- word1: meaning1
- word2: meaning2 
- word3: [[meaning reference3]]  

Or did I miss out on sth

• it was added to the already passed 0.5 milestone
  • https://github.com/blacksmithgu/obsidian-dataview/issues/342#issuecomment-882578724
  • @AB1908 as you closed the issue

However

• documentation doesn't mention the syntax yet
• the example from the proposed syntax shows an empty query result

[AB1908]

I think I closed it because it was a duplicate

[ldgraaf]

I'm not sure if this is what you are talking about but I've been using HTML line breaks to seperate my lines for inline fields. field:: Some text<br>More text on a new line<br>Even more on a third line This makes it show up on different lines when I do a dataview table.

[mnaoumov]

I'm not sure if this is what you are talking about but I've been using HTML line breaks to seperate my lines for inline fields. field:: Some text<br>More text on a new line<br>Even more on a third line This makes it show up on different lines when I do a dataview table.

Yes, this is a workaround but not very readable. I still think that better built-in syntax for multiline lists and strings would be very useful

[ldgraaf]

Yes, this is a workaround but not very readable. I still think that better built-in syntax for multiline lists and strings would be very useful

I agree, although you don't see the HTML unless your cursor is on that line when you are in editing view and you don't see them at all in dataview, but yes a built-in syntax would be nice.