As is too often the case (I’m sorry), I’m surprised there are people that have discovered an obscure API, started using it, and if I quietly remove it things break 
Today: index.defineTag, who’s using it? And if so, what for? I’ve already removed it from the website docs, because I think I’ll soon have a replacement that (in my mind) serves more purposes, but to verify that I’d first like to hear from people who use this API and what for.
cc @deepkn
Ok, through search on the forums I see reference to it here: Global page decorations in V2 - #4 by zef (supporting pageDecorations as described there is the goal of the successor to this API).
I also see that @ChenZhu-Xie is using it here: ABC - Accurate 🖇️ Bi-directional 🖱️ Cursor-level linking system but I’m not sure if this is something you’re still actively using or relying on?
Yes, currently ABC - Accurate 🖇️ Bi-directional 🖱️ Cursor-level linking system is actively using this streamlined API. It is convenient for dynamically augmenting objects with supplementary attributes and later invoking those values. Specifically, the plugin assigns an additional _.thBlabel property to link objects, which is then formatted in the BackRefs(...) function using template.new[==[[[${_.ref}|${_.thBlabel}]]]==].
Historically, add Visitimes Property in another plugin ABC - Adaptive Bread Crumb - #2 by ChenZhu-Xie also employed this API, but its state proved ephemeral, resetting whenever SB was reopened, in contrast to the datastore API’s long-lived, cumulative persistence via IndexedDB. For this reason, I migrated that plugin to the datastore for ‘permanent’ key–value storage. That said, short/lightweight lifecycles can be appropriate, and the earlier plugin benefited from such behavior.
Notably, the API is not inherently transient; the clearing behavior stemmed from the use of local Visitimes = Visitimes or 0, which redefined the value when SB reindexed Lua blocks at launch.
Overall, (1) this API is quite convenient, (2) it is actively used, and (3) in some cases it is indispensable. Naturally, if a better alternative or an improved version emerges, the plugin can be upgraded accordingly without much difficulty.
Ok, let me make this an exercise in keeping the APIs stable and taking a “slow deprecation” approach.
A head’s up, while I will keep the old index.defineTag API working, on edge it ought to be replace with this: tag
I’m the opposite here, I saw last night the new tag.define API and I have already implemented it, and brought back my missing “attributes” for tasks 
Wanted to try the API/tag on 2.4.1-85ac15546f15d22b1cfadcabd94aae8c0f372860 (edge), but I can’t get it to work.
on silverbullet.md running 2.4.1-45-g923b18eb seems to work. How to get this version?
PS: I don’t use index.defineTag
I have that same version and I confirm it is working for me. I have in CONFIG:
```space-lua
tag.define {
name = "task",
transform = function(o)
-- Match Deadline 📅
local deadline = o.name:match("📅%s*(%d%d%d%d%-%d%d%-%d%d)")
if deadline then
o.deadline = deadline
end
}
I also have a local snippet to easily type it in:
```space-lua
local snippets = {
["due"] = function() return "📅 " .. os.date("%Y-%m-%d") end,
}
What @paletochen mentioned regarding CONFIG is important. Tag definitions will only be active if they’re picked up before indexing happens. The best way to ensure this is them in the CONFIG page, which is evaluated immediately at boot. Still thinking of ways to avoid this restriction, but for now it’s there (also in the docs I think).
I think it would be interesting to apply the same solution to the item object (item.define).
Attributes can also be used on items. I use…
This should work for anything including items. Note it’s always tag.define just with different names pointing to task or item or page or whatever you like.
If I correctly understand the example provided in the doc relating to the deadline of a task, we assign a value to this attribute (optional) even though it does not appear in the text (I understood that this is the aim of the manipulation).
We therefore contravene the principle according to which “the truth is in the markdown !” because to reconstitute the index, the rule for assigning the value must always be present and active. Weird !
However, the same result is obtained using css rules:
.sb-attribute[data-deadline]::before {
content: "📅 ";
display: inline;
}
.sb-attribute[data-deadline] > .sb-list.sb-frontmatter{
background: none;
color: blue;
}
.sb-attribute[data-deadline] > .sb-list.sb-frontmatter.sb-atom {
display: none;
}
.sb-attribute[data-deadline]> .sb-list.sb-frontmatter.sb-meta {
display: none;
}
then, the markdown conforms to the index:
@jsehnoutka’s script can be adapted. Just replace:
local newText = ws ..
"* [ ] " ..
rest ..
" 📅" ..
result.value
by this:
local newText = ws ..
"* [ ] " ..
rest ..
" [deadline: " ..
result.value ..
"] "
It does appear in the text. Your task e.g. says “
some-date” in there somewhere in the name, which is then parsed out and interpreted as a deadline using a regular expression.
No we don’t, the date is still there in the markdown. I suppose the phrase should be “the truth is encoded in the markdown”
I understand what you say. And yes, “ some-date” can parsed using a regular expession to reconstruct the value of the “deadline” attribute.
So, for me, the problem is that some attributes will be encoded with the standard schema ([: ]) and others will be “encoded” in fancy non-standardized strings (eg: why not adopt another emoji to mark the deadline ?).
If I’m embarrassed, it’s not because I’m using Task Explorer (admittedly, the filter cannot work correctly since the attribute is only identifiable in the text if you know the code used: emoji, … but the problem is minor). It’s more out of principle.
To summarize, if the encoding is done only on display (for example, with css), no problem. But, if it is the data itself that is transformed, I fear that the basic principle will be transgressed.
It seems to me that an attribute must be normalized, like a tag.
(I hope I understand how it works; if not, my apologies)