Allow "has" affixation to be configurable

[bdarcus]

I don't know if this is a good idea, but with #634, it occurred to me:

It might be good to allow configurable indicators?

That would allow to edit the current ones (for example, remove "links"), or to add new ones.

[roshanshariff]

I was also thinking this, and was going to implement a more configurable system, but it looked like it would increase the complexity more than necessary. I think it's a good idea, but we should wait until we have a concrete use case and make sure whatever we implement works for that purpose.

The main constraint is that any indicators have to be very fast at display time. This means that if you want to do any non-trivial work, you have to do it earlier, when the bibliography is parsed (at least as much as possible). So you'd want to have a customizable list of "data augmentation" functions that run when the bibliography is parsed. They would pre-compute extra information that gets attached to each bibliography entry. Then, ideally, the indicators would just be able to look at this augmented information.

I have some thoughts on how to implement all this but, as I said, I think we should wait for a concrete use case.

Just allowing the built-in indicators to be removed is very easy. We don't do this now, but we can just disable the file and note indicators when has-files-functions or has-notes-functions are nil. Currently we just won't show the indicators, but still reserve the space for them. We could easily add a similar option for links.

[bdarcus]

To be clear, I do not advocate adding this now, or even necessarily soon. I just thought it worth considering. For that reason, I marked the milestone "future".

[bdarcus]

FYI, I just linked a PR with a "concrete use case": in this case, for citar-org-roam, indicating when what notes cite a reference, and therefore when citar-org-roam-cited will return a result.

But TBH, that needs some more thought in any case.

[bdarcus]

I think we have enough concrete use cases at this point to figure this out.

I'll see if I can find the time to look at the code and at least figure out what be involved in implementing it, if not actually code it. I'm not sure ATM how big a PITA this would be.

[bdarcus]

This was added in #753.