Inés

On the field never being indexed — that is the single most common cause of a query returning nothing, and it is almost always one of these:

• Front matter that is not valid. One bad line and the whole block is dropped silently, so every field in that note vanishes. Tabs instead of spaces, a colon inside an unquoted value, an unclosed bracket. If one note behaves differently from the rest, check its front matter first.
• Inline fields with the wrong number of colons. The inline syntax is distinct from the front matter syntax and it is easy to write one when you meant the other.
• A field inside a code block or a quote, which is deliberately not indexed.
• The vault not being reindexed after a bulk change made outside the app. A restart or a forced refresh fixes it, and it is worth ruling out before rewriting a query that was correct all along.

Also: field names are case-sensitive in ways people do not expect, and a trailing space in a name is invisible and fatal.

Not a limitation — you are producing a string where you need to produce either markup or a link object, and the distinction is the whole answer.

Why the path renders as text. Your field holds a path, which is a string. The table renders values, and a string renders as its characters. The app is not scanning generated output for anything that resembles a path and helpfully turning it into an image.

Two ways to fix it, and they suit different situations.

1. Build the markup in the query. Concatenate your path into an image embed and let the result render as markup rather than as text. A column expression that produces the embed syntax around your path value will display the picture. You can size it in the same expression, which you will want to — full-size covers make a table unusable.

This works for links too: build the link syntax around the target, and it renders clickable.

The caveat is quoting. If a path contains spaces or brackets, naive concatenation produces broken markup, and the symptom is a column that renders as a mangled string rather than as an error. Store paths without spaces if you can.

2. Store the field as a link in the first place. This is the better answer when the field points at something in the vault. Write the value as an actual link in the note rather than as a path string — then the plugin indexes it as a link object, and the table renders it as a working link with no query-side work at all.

Same for images: if the field holds a link to an image inside the vault, the embed form of that link renders the picture.

For anything more involved, drop to the scripting variant. The declarative query language deliberately does very little formatting. The scripting form of the same plugin gives you the pages as data and lets you build the table yourself, which means you can produce a proper file link with the embed flag set, generate an HTML element, or handle a missing image with a placeholder instead of an empty cell.

That last point is what usually pushes people over: in a declarative query, a note with no cover produces a broken embed. In the scripting form you write one conditional and it produces a blank cell.

A practical note on external images. If your covers are remote URLs rather than files in the vault, they will render but every table view fetches them, which is slow and leaks what you are reading to whoever hosts them. Downloading the covers into the vault once is worth it for a list you look at often.

Small practical addition for the shared-laptop case: even with separate accounts, check what your notes app leaves outside the vault folder.

Recently-opened lists, window state, plugin caches, search indexes and crash logs live in application data, and some of them contain note titles or fragments of content. Under separate user accounts that is all inside your profile and therefore protected — but if you are relying on an encrypted container inside a shared account, those crumbs are outside it.

Does not change the recommendation, just worth knowing that the vault folder is not always the only copy.