joostkremers/parsebib

Aligning key/type field names in json and bib/latex

Closed this issue · 2 comments

A follow-up to #12.

The changes I needed to make to use parsebib-parse for the initial bibtex-actions candidate list, and therefore also bypass all that bibtex-completion code, were trivial.

image

Two high-level conclusions:

  1. The mapping approach as in #12 (comment) mostly works (see screenshot).
  2. Except, there's seems to be a minor problem with the different ways types and keys are represented in bib/latex and in csl json, so bibtex-completion functions which depends on looking that data up directly (like edit-entry it seems; actually, not sure on this) don't work with the json representation.

For parsebib, the obvious solution for both is what we've previously discussed: parsebib-get-value to also address 1, and for our packages to use that.

On the bibtex-completion end, if we could get this addressed, it should allow you to simultaneously remove a lot of code, @tmalsburg, and secondarily get json support. I don't see a lot places in the current code that look explicitly and directly for =key=, for example; most are using the bibtex-completion-get-value wrapper, which could be adjusted to look for both =key= and id, or to call a possible parsebib alternative.

For parsebib, the obvious solution for both is what we've previously discussed: parsebib-get-value to also address 1, and for our packages to use that.

Sorry, I wasn't able to reply earlier. (Much to do, little time...)

Alternatively, there could be an option to use =key= and =type= even for CSL-JSON. Since bibtex-completion doesn't need a faithful representation of the underlying file anyway, that shouldn't be a problem.

Alternatively, there could be an option to use =key= and =type= even for CSL-JSON. Since bibtex-completion doesn't need a faithful representation of the underlying file anyway, that shouldn't be a problem.

It's not a big deal for me ATM, as I've just rewritten much of my code to use parsebib directly.

I do think it'd be helpful for it to be consistent, though, and maybe configurable (for example, use csl "id" rather than "=key=").