Context sensitive insertion of optional fields in bib file

[ddbrierton]

Is your feature request related to a problem? Please describe. The current bib file snippets insert the minimal required fields into an entry type. When additional fields are needed there is no help as to which are applicable to the current entry type. I often have to search for another similar entry to remember what the fields I need are.

Describe the solution you'd like When editing an entry type in a bib file, I’d like a command which presented a list (in the command palette) of the valid additional fields I could insert.

[jlelong]

Really implementing intellisense for optional parameters may be a bit overkilling but instead add all available optional fields prefixed by _OPT to every entry template. For instance, typing @article would insert

@article{key,
  author  = {},
  title   = {},
  journal = {},
  volume  = {},
  number  = {},
  year    = {},
  OPT_pages = {}, 
  OPT_month = {}, 
  OPT_note = {}
}

This is how emacs proceeds http://www.jonathanleroux.org/bibtex-mode.html#0442. It is far simpler to implement and I guess sufficient. From the bibtex manual, all non required, nor optional fields are ignored.

[ddbrierton]

That certainly would be one way to go, although looking at Biber and BibLaTeX aren’t there an enormous number of optional and alternative fields? For instance your example above misses out doi, url, abstract and others. That probably wouldn’t be a problem if there was also an equivalent to BiTeX-mode's command clean-entry:

Instead of removing 'OPT' and 'ALT' prefixes and unnecessary delimiters one by one, you can use the command bibtex-clean-entry (normally bound to C-c C-c) to let BibTeX mode do the work for you. When you enter this command, all prefixes are deleted from all field names with non-empty contents and delimiters around pure numerical fields are removed.

It’s been a while since I’ve used Emacs for LaTeX but I remember that one of the cool things about bibtex-clean-entry was that it would also generate a reference key.

[jlelong]

The fields doi and url and are not standard in bibtex. They seem to be added by natbib styles. So making an exhaustive list of optional fields is not so obvious and moreover have some optional fields that are only understood by certain styles does not make sense.

Have you considered using latex-workshop.intellisense.bibtexJSON.replace to define the list of fields you want for a given entry type?

The above discussion gives me the impression that the details of this feature are not yet mature.

[ddbrierton]

No, I haven’t, I’m pretty new to VS Code and am still finding my way around.

Nonetheless I’m very happy to help out in anyway I can if you choose to implement this feature. If you want me to research all the different fields for the different entry-types I can do that. (What is the reference here? Are people mostly using BibLaTeX now? Or is BibTeX still the reference as far as you are concerned?)

Have you considered using latex-workshop.intellisense.bibtexJSON.replace to define the list of fields you want for a given entry type?

So I just searched for that in the settings, and I see I can customise the fields for each entry-name. I was not aware I could do that. If you feel that this feature is not worth implementing then that gives me a solution, so thank you. I did think that this might be something other users would like “out of the box” so to speak, but obviously you have a much keener sense of that than I do.

(And if I don’t get another chance, thank you for this incredible extension. It’s absolutely outstanding.)

[jlelong]

As you pointed out, biblatex and natbib accept a huge number of optional fields, which makes the OPT_ approach unfeasible.

My thoughts on a possible implementation of the feature:

• Create a dictionary of all the possible options associated to every entry type and store it in .json format
• Create a dedicated function (accessible via the Command Palette) to insert an optional field based on the current entry type. The available optional fields will be proposed to the user using a window.showQuickPick.

[ddbrierton]

That sounds perfect!