Have a table like the following…
| foo | bar |
|---|---|
| oof | qwe #QWE |
| foo | ewq [qwe: foo] |
table where tags = 'QWE'
This works and yields
| tableref | ref | tag | tags | page | pos | foo | bar |
|---|---|---|---|---|---|---|---|
| Sandbox/Test@36 | Sandbox/Test@56 | table | QWE | Sanbox/Test | 56 | oof | qwe |
But the next one does not!
tag where name = 'QWE'
This is a great, really, limitation. I would expect literaly every tag be present in the tag object. It’s tag and it should be accessible as such. Something like the following…
| ref | tag | name | page | parent |
|---|---|---|---|---|
| Sandbox/Test@56:table | tag | QWE | Sandbox/Test | table |
Perhaps… Or something like that that does make more sense… @zef ?? Could this great limitation be somehow resolved?
Use case: I have many things in tables tagged and these tags are missing from all my tag listings… ![]()
Side note: whereever tag are indexes, the same should be true for [attr: ibutes], I think. Both should be indexed the same way, consistently.
Idea: Add more object types for table: row and column and cell, so there will be 4 indices for the tables. Then methods to access any of the 4 table objects can be elaborated on in the future. That could allow for powerful “poor-man’s” spreadsheets built with these new 4 indices.