Bruce D'Arcus

I'm not necessarily advocating for this (it was just a question), but note that CSL-JSON now has a "custom" property that could be used to dump non-standard data like this....

Yes, there are examples [embedded in the schema](https://github.com/citation-style-language/schema/blob/5b8bbc824e026959417757d4ce4012a26b10e637/schemas/input/csl-data.json#L448-452). ```json { "short_id": "xyz", "other-ids": ["alternative-id"] } ```

@andras-simonyi - when you have time, can you review this simple PR?

That's a good point. I went this way because I wasn't sure if we want the org-bibtex parser in the citar package, or in a separate package. I'm still not...

@aikrahguzar > So the problematic scenario is when the parser is in a separate package and we don't want to depend on it? That's the immediate issue I was thinking...

Although some other functions seem slower than the cl equivalents. https://kisaragi-hiu.com/performance-cl-lib-dash-seq @aikrahguzar @roshanshariff from another interesting thread on this on the doom discord. http://ix.io/49ul `cl-remove-if-not` is a fair bit faster...

> I thought this was an interesting idea so I whipped up a prototype here https://github.com/aikrahguzar/citar/blob/main/citar-no-cache.el > > It works well enough, not as snappy as using the cache but...

This is more a polish issue not important ATM, but might be nice if it loaded, say, the last 100 selected references from history initially. I find it a little...

See `citar-cache--entries`: https://github.com/emacs-citar/citar/blob/731c0ae81aecca94f7dcc4f2dad51a0cd1c3de68/citar-cache.el#L108-L113 It's one of those details I'm unclear how would be handled in this approach.

> * with caching annotation support ala marginalia Not following this part. We don't use annotation; we use affixation, and only for the "has" prefix. And that has to be...