Dataviewjs ignores entries which look like numbered lists

Help
1

What I’m trying to do

I want a list of all uncompleted todos with a certain tag (here “#bau”) and no date (in the format yyyy-mm-dd) contained in the todo-line.

Things I have tried

Most stuff has been developed here: Query for notes containing tags with a date of in the next x days
The current code is

const regex = /[\d]{4}\-[\d]{2}\-[\d]{2}/g

function safe_match(t) {
	m = t.text.match(regex)
	if (m != null) {
		return m[0]
	}
}

const tasks = dv.pages().file.tasks.where(t => t.text.includes("#bau")).where(t => dv.date(safe_match(t)) == null).where(t => !t.completed)
dv.taskList(tasks)

This works nearly perfect, however there is a flaw. The following items are displayed

  • [ ] Test 1 #bau
  • [ ] 1 Test #bau
  • [ ] Test 1. #bau

but not this line

  • [ ] 1. Test #bau

It seems like every line beginning with a number followed by a dot, so appearing a bit like a numbered list, seems to be ignored even though it’s not supposed to be. I’m not sure if my code is flawed here or if it’s a bug in dataviewjs.

2

I simplified your example into this:

 -   [ ] TestA 1
 -   [ ] 1 TestB 
 -   [ ] TestC 1. 
 -   [ ] 1. TestD 
 -   [ ] TestE

And in a sandbox vault (in 1.1.16 with installer 1.1.16), it does display as the following:
Live-preview on the left, and reading view on the right

One can clearly see that “TestD” indeed displays as a task with a numbered list. So this is somewhat related to some markdown syntax issue. As such I don’t think dataview is to blame for not recognising this as a task, which it doesn’t. It’s only registered as another list item, see image below:

image
image1186×268 12.8 KB

I’m not sure whether this is just a feature or to be considered a bug of some sort. But I can confirm that this behaviour exists, and as long as dataview doesn’t recognise it as task, it’ll not be listed in any TASK related queries, like my TASK ... above, or through the use of file.tasks in your query.

You could try raising an issue with Dataview here: Issues · blacksmithgu/obsidian-dataview · GitHub

Are you able to avoid that particular syntax, or is it something you’re likely to keep writing in your use cases? (I see that doing 1 . avoid this behaviour, and also other variants like \1. or <span />1., but neither looks particular good in source mode (or reading view for some of them))

1 Like
3

Thanks for your review and comments! I honestly never use the “reading” mode in obsidian, since the “editing” mode works perfectly fine for me also for reading, therefore I never observed that it is actually treated as a numbered list.

I can try to avoid the syntax, but I’m a bit afraid that I might forget about this once and therefore miss some important task. That’s what nearly happened here when finding out about the problem. So it would be great to know that there is no risk of ignored tasks.

Yes, I might raise an issue there, I was just hesitant as long as I wasn’t sure whether the reason might be a flaw in my code. Let’s see if that might be changed or there might be another solution to that. Could I use your screenshots there?

4

Feel free to use my screenshots, but do remember to include the text so it’s easy for others to reproduce the output.