Giter VIP home page Giter VIP logo

citar's Introduction

https://melpa.org/packages/citar-badge.svg

Citar

Features

Citar provides a highly-configurable completing-read front-end to browse and act on BibTeX, BibLaTeX, and CSL JSON bibliographic data, and LaTeX, markdown, and org-cite editing support.

  • quick filtering and selection of bibliographic entries from the minibuffer, and various commands to run against them.
  • a small citar-embark companion package, that provides contextual actions in the minibuffer, and also at-point in org, markdown, and LaTeX buffers.
  • seamless caching of multiple global and local bibliographic sources
  • configurable APIs for:
    • indicatars, that signal the presence of related resources in the minibuffer
    • notes, to integrate with dedicated note packages, with external packages available for org-roam, denote, and zk
    • major-mode adapters
    • entry-opening, to go to the original entry data

Here’s a screenshot with vertico and symbol customization noted below.

images/vertico.png

And here’s citar-capf in a markdown buffer.

images/capf-md.png

To see citar in action with org-cite, you can watch this Emacs Conf 2021 presentation by Ahmed Khaled.

Installation

There are a variety of ways to install citar:

Doom Emacs
The easiest way to install and configure citar and related packages is to use the Doom Emacs biblio module with the vertico completion module.
MELPA
citar is also available via MELPA.
GUIX
provides the emacs-citar package.

In addition, the following packages are strongly recommended for the best experience.

  1. Vertico (completion interface)
  2. Orderless (completion style)
  3. Embark (contextual actions)
  4. Marginalia (annotations, and also candidate classification for Embark)

In particular, if you want to narrow your search using authors, titles, etc (i.e., not only citation keys), you need to use a completion style that is order independent; for example, Orderless with completion-styles set to (orderless basic) (see example config).

We also recommend Emacs 28 or newer.

Configuration

Basic

This is the minimal configuration, and will work with any completing-read compliant vertical completion UI, like Vertico, or the built-in icomplete-vertical, with actions available via M-x commands.

(use-package citar
  :custom
  (citar-bibliography '("~/bib/references.bib")))

citar-capf

This package includes a completion-at-point function to complete citation keys in the buffer, which you can configure like so:

(use-package citar
  :custom
  (citar-bibliography '("~/bib/references.bib"))
  :hook
  (LaTeX-mode . citar-capf-setup)
  (org-mode . citar-capf-setup))

Embark

The citar-embark package adds contextual access actions in the minibuffer and at-point via the citar-embark-mode minor mode.

When using Embark, the Citar actions are generic, and work the same across org, markdown, and latex modes.

(use-package citar-embark
  :after citar embark
  :no-require
  :config (citar-embark-mode))

Org-Cite

This shows the buffer actions made available by citar-embark:

images/org-cite-embark-point.png

If you want to use Citar only in Org-Mode, this is the best option.

(use-package citar
  :no-require
  :custom
  (org-cite-global-bibliography '("~/bib/references.bib"))
  (org-cite-insert-processor 'citar)
  (org-cite-follow-processor 'citar)
  (org-cite-activate-processor 'citar)
  (citar-bibliography org-cite-global-bibliography)
  ;; optional: org-cite-insert is also bound to C-c C-x C-@
  :bind
  (:map org-mode-map :package org ("C-c b" . #'org-cite-insert)))

You can insert citations with the org-cite-insert command, which is bound to C-c C-x C-@ in Org-Mode buffers. The optional :bind command above also gives it the shorter C-c b binding.

If you prefer to have the Embark menu open with org-open-at-point, you should set this variable.

(setq citar-at-point-function 'embark-act)

You can invoke both embark-act and embark-dwim, however, independently of org-at-point, and in other modes such as latex-mode.

Major-mode adapters

Citar includes an adapter framework to enable major-mode specific editing integration. Such adapters can provide the following capabilities, which one can configure with the citar-major-mode-functions alist:

  1. insert-keys: to insert citation keys (this may go away though)
  2. insert-citation: to insert citations
  3. insert-edit: to insert citations or edit at point
  4. local-bib-files: to find bibliographic files associated with a buffer
  5. key-at-point: returns the citation key at point
  6. citation-at-point: returns the list of keys in the citation at point

Citar currently includes the following such adapters:

  1. citar-org: by default, only supports org-cite, but can one can configure for other formats
  2. citar-latex: configurable bibtex, natbib and biblatex support (requires AUCTeX)
  3. citar-markdown: by default, only supports the pandoc citation syntax

None of these should require any configuration, and should load as needed.

Opening reference entries

The citar-open-entry command will open the source data entry. You may configure this using citar-open-entry-function. By default, this uses citar-open-entry-in-file, which will open the relevant bibliographic file and move point to the entry. The other included option is citar-open-entry-in-zotero, which will select the item in Zotero. Note that functionality depends on Better BibTeX (which you should be using anyway!).

Rich UI

There are three sections of the browsing UI.

  1. The prefix, exploiting the affixation feature only available starting with Emacs 28, and holding the symbols to indicate the presence of PDFs or notes associated with the entries.
  2. The main display, which by default shows author, title, and date.
  3. The suffix, which by default shows citekey, reference type, and (if present) tags or keywords.

You can search against all of the above content. For the prefix, you can filter for associated files or notes using has:file or has:notes respectively (and at least with orderless, even the :p or :n shorthand).

images/ui-segments.png

Templates

The citar-templates variable configures formatting for these sections, as well as the default note function. Here’s the default value:

(setq citar-templates
      '((main . "${author editor:30%sn}     ${date year issued:4}     ${title:48}")
        (suffix . "          ${=key= id:15}    ${=type=:12}    ${tags keywords:*}")
        (preview . "${author editor:%etal} (${year issued date}) ${title}, ${journal journaltitle publisher container-title collection-title}.\n")
        (note . "Notes on ${author editor:%etal}, ${title}")))

Note:

  1. You may include multiple variables in a field; the formatter will print the first one it finds.
  2. If you plan to use CSL JSON at all, you can and should include CSL JSON variables names where appropriate as such options. The default main template dates field demonstrates this.
  3. The asterisk signals to the formatter to use available space for the column.
  4. The note template does not take widths, as formatting is inline there rather than columnar.
  5. The % character preceeds a token defined as a key in citar-display-transform-functions, whose value is a list of functions and optional arguments. Note that if you include this, if you also include a width specification, it must come after the width.

Indicators

The UI includes configurable indicators. By default, it includes plain text indicators for, each of which indicates the presence of different resources related to the reference:

  • notes
  • library files
  • links
  • cited (for references cited in the current buffer)

For other indicators, see the wiki.

Here’s a screenshot using this configuration, which removes the links indicator, and mixes plain text and an icon indicator using all-the-icons.

(setq citar-indicators
  (list citar-indicator-files ; plain text
        citar-indicator-notes-icons)) ; icon

images/indicators.png

You can create your own indicators, of course. Here’s an example indicator definition incorporating icons:

(defvar citar-indicator-notes-icons
  (citar-indicator-create
   :symbol (all-the-icons-material
            "speaker_notes"
            :face 'all-the-icons-blue
            :v-adjust -0.3)
   :function #'citar-has-notes
   :padding "  "
   :tag "has:notes"))

Keep in mind, however, the included predicate functions must be performance-optimized, since the completion UI runs them on your entire library every time you open it.

Test Script

The repository test directory also includes a script you can use to run this and associated packages in the emacs -Q sandbox. To do that, simply run ./run.sh from the test directory.

History and predefined searches

citar has functionality similar to the predefined search functionality in helm-bibtex and ivy-bibtex, but with a different implementation. Rather than create a new command with the search terms as argument, you just set the citar-presets variable, and add the strings you want to access:

(setq citar-presets '("one search string" "another search string"))

You then have two ways to access these strings from the completion prompt:

  1. by using M-n from the prompt, which will cycle through the strings
  2. by calling citar-insert-preset with a keybinding, and then selecting the string

citar also preserves the history of your selections (see caveat below about multiple candidate selection though), which are also accessible in your completion UI, but by using M-p. You can save this history across sessions by adding citar-history to savehist-additional-variables.

Refreshing the library display

Citar uses a cache to speed up library display. If a bib file changes, the cache will automatically update the next time you run a Citar command.

Note that cached data preformatted completion candidates are independently tracked by file. So, for example, if you have one very large bibliography file that changes a lot, you might consider splitting into one large file that is more stable, and one-or-more smaller ones that change more frequently.

Notes

Citar offers configurable note-taking and access integration. The citar-notes-sources variable configures note backends, and citar-notes-source activates your chosen backend.

A backend primarily specifies functions to update the Citar display, to create the completion candidates, and to open existing and new notes. See the citar-notes-sources docstring for details, and the citar-register-notes-source and citar-remove-notes-source convenience functions.

Files, file association and file-field parsing

If you have citar-library-paths set, the relevant open commands will look in those directories for file names of CITEKEY.EXTENSION. They will also parse contents of a file-field. The citar-file-parser-functions variable governs which parsers to use, and there are two included parsers:

  1. The default citar-file-parser-default parser works for simple colon or semi-colon-delimited lists of file paths, as in Zotero.
  2. The citar-file-parser-triplet works for Mendeley and Calibre, which represent files using a format like :/path/file.pdf:PDF.

If you have a mix of entries created with Zotero and Calibre, you can set it like so and it will parse both:

(setq citar-file-parser-functions
  '(citar-file-parser-default
    citar-file-parser-triplet))

The citar-library-file-extensions variable governs which file extensions the open commands will recognize; when `nil`, it will recognize all extensions. The citar-file-additional-files-separator variable defines what patterns citar should identify for multiple library files for the same reference key. Here’s an example to only recognize pdf and jpg extensions, but additional file names of the form test-1.jpg:

(setq citar-library-file-extensions (list "pdf" "jpg")
      citar-file-additional-files-separator "-")

To change how citar opens files with given extensions, customize the citar-file-open-functions variable defined in citar-file.el.

When used with embark and consult, you will have a range of alternate actions available for the candidates.

images/file-browser-embark.png

BibTeX Crossref File Support

For BibTeX entries that have a ‘crossref’ field, Citar will associate the entry’s key with the resources (files, notes, links) that are associated with the cross-referenced entry.

For example: consider an entry for “Baym1965” that has a ‘crossref’ field “Meyers1999”. When citar-open is called and “Baym1965” is selected, the minibuffer will list all files, notes, and links associated with both “Baym1965” and “Meyers1999”. The proper prefixes, denoting an associated file, note, or link, will also be listed with each candidate in the minibuffer.

NOTE: For the BibTeX crossref feature to work properly, the entry with the ‘crossref’ field must come before the cross-referenced entry in the bib file. (This is a requirement of BibTeX, not of Citar specifically.) In the example above, then, the entry for “Baym1965” must come before the entry for “Meyers1999”.

Usage

You have a few different ways to use citar.

Org-cite

Citar includes an org-cite citar processor, with “insert,” “activate” and “follow” capabilities. When speaking about org-cite, citations refer to a set of one or more references (citation-references), each of which may have text that precedes it (prefix) and text that proceeds it (suffix). To learn more about org-cite, visit the Citations page in the Org Manual.

The “insert processor” uses citar-select-refs to browse your library to insert and edit citations and citation references using the org-cite-insert command. The command is context-aware, so its behavior depends on the point’s location in a citation. For example, if point:

  • precedes the colon, you are on the citation prefix and will be prompted to edit the style
  • is on an existing citation-reference, you will be prompted to replace it
  • follows or precedes a citation-reference, you will be prompted to add a new citation-reference

The “activate processor” runs the list of functions in citar-org-activation-functions, which by default is the basic processor from oc-basic to provide fontification, and also a little function that adds a keymap (citar-org-citation-map) for editing citations at point. The citar-org-citation-map keymap includes the following bindings that provide additional citation and citation-reference editing options.

keybindingdescription
C-c C-x DELcitar-org-delete-citationdelete citation or citation-reference at point
C-c C-x kcitar-org-kill-citationkill citation or citation-reference at point
S-<left>citar-org-shift-reference-leftmove citation-reference at point left
S-<right>citar-org-shift-reference-rightmove citation-reference at point right
M-pcitar-org-update-prefix-suffixupdate prefix and suffix of reference at point, or,
when called with prefix arg, update all
citation-references in citation at point
<mouse-1>citar-dwimcall the value of citar-at-point-function at point
<mouse-3>embark-actcall embark-act at point

The “follow processor” provides at-point functionality accessible via the org-open-at-point command. By default, in org-mode with org-cite support, when point is on a citation or citation-reference, and you invoke org-open-at-point, it will run the command set in citar-at-point-function, which is citar-open by default. Changing the value of citar-at-point-function to embark-act with embark installed and configured will provide access to the standard citar commands at point.

Org-cite citations include optional “styles” and “variants” to locally modify the citation rendering. When inserting a new citation, calling org-cite-insert with a prefix arg will prompt to select a style. To edit an existing citation’s style, just make sure point is on the citation prefix before running org-cite-insert, and you will get a list of available styles. That list is based on your configuration; if you have the oc-natbib and oc-csl processors configured, for example, the list will include the styles and variants available in those two processors. The variants included in the bundled processors include the following, with the shortcuts in parentheses:

  • bare (b): without surrounding punctuation
  • caps (c): force initial capitalization
  • full (f): ignore et al shortening for author names

Generally, you shouldn’t need these, but they can be useful in certain circumstances. If an export processor doesn’t support a specific variant for a specific style, it should just fallback to the base style. For example, if you specify text/f, and the export processor you use doesn’t support the f variant there, it should just output as if you specified text.

images/oc-styles.png

M-x

Simply do M-x and select the command that you want, enter the terms to find the item you are looking for, and hit return. This runs the default action: the command you invoked.

Access an alternate action via embark-act

If while browsing you instead would rather edit that record, and you have embark installed and configured, this is where embark-act comes in. Simply input the keybinding for embark-act (in my case C-o), and select the alternate action.

Use embark-collect-snapshot

A final option, that can be useful: run embark-collect-snapshot (S) from embark-act. This will select the candidate subset, and open it in a separate buffer. From there, you can run the same options discussed above using embark-act (which is also bound to a in the collect buffer).

So, for example, say you are working on a paper. You hold the complete super-set of items you are interested in citing at some point in that buffer. From there, you can run different actions on the candidates at will, rather than search individually for each item you want to cite.

Use citar-dwim

M-x citar-dwim will run the default action on citation keys found at point directly. If you have embark installed, you use can embark-dwim instead for the same behavior, and embark-act for additional actions at-point.

If no citation key is found, the minibuffer will open for selection. You can disable this behavior by setting citar-at-point-fallback to nil.

Related Packages

The following packages extend or otherwise enhance citar.

Notes Sources

These small packages provide citar notes sources, and so tighter integration with the respective notes management packages.

Comparisons

To understand how citar compares to other packages like org-ref, ivy-bibtex and helm-bibtex (and the related bibtex-completion), see the comparisons page on the wiki.

Acknowledgements

The ideas in this project were initially worked out in a conversation with Maxime Tréca and Daniel Mendler. Daniel, author of consult and marginalia, helped us understand the possibilities of the new suite of completing-read packages, while Maxime came up with an initial prototype.

This code takes those ideas and re-implements them to fill out the feature set, and also optimize the code clarity and performance.

citar's People

Contributors

aikrahguzar avatar andersjohansson avatar andreas-bauer avatar apc avatar balajisivaraman avatar bdarcus avatar benthamite avatar denismaier avatar hugo-heagren avatar ilupin avatar jonathanreeve avatar krisbalintona avatar localauthor avatar mcfarljm avatar mclearc avatar meliache avatar minad avatar natkarmios avatar oantolin avatar publicimageltd avatar rdiaz02 avatar roshanshariff avatar samoed avatar save-buffer avatar seanfarley avatar shuguangsun avatar syohex avatar thisirs avatar titaniumbones avatar tmalsburg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

citar's Issues

drop Emacs 26.3?

This is a new package without wide usage ATM. And Ubuntu's next release in a few weeks will.move to 27.1.

Thoughts?

Add support for new org cite

While it's not done or merged yet, this thread suggests it likely will be "soon" (the syntax is basically done, as is a draft API).

https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00430.html

When it is, citation insertion would need to be adapted to take advantage of it, ideally in bibtex-completion. I don't believe the bibtex-completion-insert-citation function even needs to be changed to do this, given it has customization capabilities; see:

https://github.com/tmalsburg/helm-bibtex#format-of-citations

#113 is adding this.

I'd expect there would be overlap with org-ref too.

It seems, however, there will be opportunities here too, regardless of what code ends up where.

See, for example, #91, which may we the place to start.

PRs welcome, as I'm not sure I have the time or skill to do this ATM.

Aside: this project is under more active current development than bibtex-completion et al. So at times it makes sense to add code here that might later be transferred over to the former later. We use the same license, so that won't be any impediment.

Add completion-at-point

Overview

Perhaps at-point completion would be more efficient for the more narrow task of citation and/or key insertion when writing, particularly for the forthcoming new org-mode citation support, something like you see in the Zettlr markdown editor?

Screenshot from 2021-04-22 04-07-16

Don't really know anything about this, but thought of it because of this new package.

https://github.com/minad/corfu

And there's, of course, company.

If the feature makes sense, I may experiment with it. But a PR would be even better!

EDIT: see this comment for limitations and possibilities, in particular the note you can make it possible move from at-point to the minibuffer.

Possible implementation approach

If I understand how the API works, we'd probably want something like the following functions:

Edited based on discussion in comments.

  1. bibtex-actions-complete-key-at-point (as with Zettlr screenshot above; the easiest and most general, and will cover 90% or so of need, and work with both org and pandoc syntax)
  2. bibtex-actions-complete-citation-at-point (specifically for new org cite support, which will have more complex syntax and features; see #108)

Org-cite syntax

Here's the new syntax:

 [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]

Goal is to make citation entry really smooth and efficient, then.

So I'm thinking user experience would be something like:

  • type [c and that can auto-complete to [cite
  • type / and presents pop-up options of styles, completes that, and places point after this [cite/style:
  • type @ and list of citation keys pops up for selection (this seems the only piece that would be necessary)
  • etc.

bibtex-actions-read returns (nil nil) when selecting item

I have encountered a strange bug: Certain bibliography items seem to cause bibtex-actions-read to hickup. It returns (nil nil). Here's the .bib file:

@book{jorke_2003_Demokratie,
  title = {Demokratie als Erfahrung: John Dewey und die politische Philosophie der Gegenwart},
  shorttitle = {Demokratie als Erfahrung},
  author = {Jörke, Dirk},
  date = {2003},
  publisher = {{Westdt. Verl}},
  location = {{Wiesbaden}},
  url = {http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&doc_number=010344150&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA},
  urldate = {2012-08-31},
  file = {/home/jv/Zotero/storage/3LUESP9S/Jörke - 2003 - Demokratie als Erfahrung John Dewey und die polit.pdf},
  langid = {german}
}

@article{joerissenAnthropologischeHinsichtenPragmatische2002,
  title = {Anthropologische Hinsichten, pragmatische Absichten},
  author = {Jörissen, Benjamin},
  date = {2002},
  pages = {24},
  file = {/home/jv/Zotero/storage/X7X3JUAD/Jörissen - 2002 - Anthropologische Hinsichten, pragmatische Absichte.pdf},
  langid = {german}
}

Selecting the first item yields the key (in a list); selecting the second item yields (nil nil).

Trying to debug that behavior, I encountered another weird error. I wanted to instrument the function with edebug. Edebug, however, said the defun was malformed. So I added a fake variable to the argument list:

(cl-defun bibtex-actions-read (&optional _fake_argument &key initial rebuild-cache)
  "Read bibtex-completion entries. ....")

Now debugging worked -- but the error was gone!

So it turned out that the error occurs only as long as I use the byte compiled version of the package. If I evaluate the function in the buffer directly, everything works fine. I get the error again if I explicitly force a reloading of the package with (load "bibtex-actions").

So my guess is that the problem has to do with compilation.

I use GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.17.4) of 2021-03-26, and the latest bibtex-actions commit 149f9ae.

Support csl-json

Joost merged the parsebib wip/csl branch, which gives support for direct parsing of both bib and json files.

ELISP> (defvar my/bibtest (parsebib-parse (org-cite-list-bibliography-files)))
my/bibtest
ELISP> (gethash "low2001" my/bibtest)
(("subtitle" . "gated communities and the discourse of urban fear")
 ("title" . "The Edge and the Center")
 ("number" . "1")
 ("langid" . "english")
 ("urldate" . "2016-02-18")
 ("doi" . "10.1525/aa.2001.103.1.45")
 ("issn" . "1548-1433")
 ("pages" . "45--58")
 ("volume" . "103")
 ("journaltitle" . "American Anthropologist")
 ("date" . "2001-03-01")
 ("author" . "Low, Setha M.")
 ("shorttitle" . "The Edge and the Center")
 ("=type=" . "article")
 ("=key=" . "low2001"))

Just need a function something like this to manage field name mappings.

(defvar bibtex-actions-field-map
  '(("date" "year" "issued")
    ("author" "editor")
    ("booktitle" "container-title")))

(defun bibtex-actions-get-value (item field)
  "Return biblatex FIELD value for ITEM."
  (or (cdr (assoc-string field item 'case-fold))
      (catch 'success
        (dolist (fm (cdr (assoc field bibtex-actions-field-map)))
          (when fm
            (throw 'success (cdr (assoc-string fm item 'case-fold))))))))

Would also allow removing the bibtex-completion dependency for parsing and such.

This approach would suggest:

  1. maybe a new bibtex-actions-bibliography variable to hold the list of bib (bibtex and/or csl-json) files to load
  2. maybe a new bibtex-actions-init function to load them etc
  3. replace current bibtex-completion-get-value calls with parsebib-get-value, or bibtex-actions-get-value

Note the new parsebib-parse function also does error handling.

Major caveat some bibtex-completion functions currently depend on it's parsing code, though I need to figure out which ones, and how. Also, it might be worth postponing this to see what happens with affixation/decoration in Emacs 28.

joostkremers/parsebib#12

Add affixation function to support prefixes and suffixes for candidate display

See #28 (comment) and minad/marginalia#50 (comment).

Emacs 28 introduces affixation support, which we should be able to exploit for a more functional and elegant UI/UX.

To do that, we need an affixation function, or even a separate package, that adds color-differentiated note/pdf/link icons to the prefix where those items are associated with the candidate, and (maybe user-configurable) secondary metadata to suffix.

Has to be gorgeous, functional, and work well on dark and light themes.

The idea is this would enhance visual scanning of the candidate list (and, TBH, improve the aesthetics).

Example mockup:

Screenshot from 2021-03-13 15-04-00

This will address how to filter on these: tmalsburg/helm-bibtex#363.

Details

The bibtex-completion-candidates function includes the metadata one can use to construct the affixes, and I assume we want to use all-the-icons for the actual icons.

Resolution

I've merged the linked PR with configurable main display and suffix. The latter should also work for pre-Emacs 28 using the annotation-function I added, though I haven't tested this.

Make initial value for the different actions customizable

While debugging that crm problem, I encountered a more conceptual issue. Vanilla Emacs has no sophisticated completion system, it just offers you all strings which match the inital input from the beginning on (like "^initial input). Therefore, the initial input (like "has:pdf") will not filter the list of available items. I had to delete the initial input in order to access the item. It only works if you have the appropriate completion style installed, in my case, that would be orderless. Assuming that one goal of that package is to provide completion with as little requirements as possible, it makes sense to remove that functional dependency.

So my suggestion is to introduce a variable to make the initial input customizable. Here's a draft:

(defcustom bibtex-actions-initial-inputs 
  '((files . "has:pdf")
    (notes . "has:notes")
 ...)

(defcustom bibtex-actions-filter-with-initial-input t
  "Set this to nil of you use an 'unflexible' completion style"
....)

(defun bibtex-actions--get-initial-input (input-type)
 (when bibtex-actions-filter-with-initial-input
  (assoc input-type bibtex-actions-initial-input))

(defun bibtex-actions-open-notes (keys)
    (interactive (list (bibtex-actions-read :initial (bibtex-actions--get-initial-input 'notes)
                                                              :rebuild-cache current-prefix-arg)))
   (bibtex-completion-edit-notes keys))

There would be further stuff to change, like bibtex-actions--affixation. And if we go that route, :initial could actually be changed to just pass a symbol, that would make the code more elegant.

What do you think?

Support multiple candidate selection

In helm-bibtex, when presented with a list of candidates, one can do the following:

  • hit control-space to mark multiple candidates
  • hit tab to access action options, or return to run default

Screenshot from 2021-03-07 02-54-08

In my view, this is an almost ideal UX for selecting and acting on multiple candidates (though arguably the selected candidates should then be grouped at the top of the list).

That will then pass multiple keys to the relevant functions, and for the insert-at-point commands, those functions take care of the formatting; in some cases they are comma-separated inline, and in others (like inserting BibTeX entries), they are separated by newlines.

So how to do this here?

The obvious answer is to change the read function to use completing-read-multiple.

But the selectrum UI support for multiple selection is not really optimized for examples like this with very long candidates. Same for icomplete-vertical, which uses a similar UI.

I did, however, submit an enhancement request to selectrum to support this case. No code yet, but I'm optimistic we will see it.

So it would be good to resolve this on our end before this happens, so we can test and contribute feedback.

Seems we would also need to get embark to support multiple (see comment).

Please add autoloads

First of all, thanks for a great package! It completes my migration to selectrum and allows me to finally remove helm.

When loading the package via use-package, I had to add a special section for predefining the interactive command:

(use-package bibtex-actions
  :quelpa (bibtex-actions)
  :commands (bibtex-actions-open-notes) ;; that one enables lazy loading
  :bind
  (("C-x l" . bibtex-actions-open-notes)))

So I guess if you'd just add an autoload cookie to the interactive entry points, there'd be no need for the :commands part here.

Generalize bibtex-actions-get-key-org-cite

The bibtex-actions-get-key-org-cite at-point function currently only works on citation-reference objects and so only on a single key.

It should be enhanced to also work on citation objects and multiple-keys.

Note, though: the initial-value would need to be set to a regex of the multiple keys, while the org-cite follow processor (see #141) would need to a pass a list of keys to the called function.

This does lead to me wonder if #141 might better be decoupled from bibtex-actions-at-point.

See org-cite-basic-goto for an example:

https://code.orgmode.org/bzg/org-mode/src/wip-cite-new/lisp/oc-basic.el#L485

EDIT: Nicolas just now added a "key-only" optional argument to org-cite-get-references, which should allow this @ilupin:

(bibtex-actions-default-action (org-cite-get-references citation keys-only))

MELPA

I think this code is solid, and the elisp-check github action I've been using from the beginning is passing fine.

If you're using this package without issue and support submitting it, however, please weigh in here, with a thumb's up on this post, or any specific comments?

The file will just be:

(bibtex-actions :repo "bdarcus/bibtex-actions"
  :fetcher github)

field alignments with prefixes

from @apc

I've tried setting the value of bibtex-actions-template-suffix to include ${=has-pdf=:1}${=has-note=:1}:.

bibtex-actions-template-suffix is a variable defined in ‘bibtex-actions.el’.
Its value is
((t . "          ${=key=:15} ${=has-pdf=:1}${=has-note=:1}   ${=type=:12}    ${tags:*}"))
Original value was 
((t . "          ${=key=:15}    ${=type=:12}    ${tags:*}"))

  You can customize this variable.

Documentation:
Configures formatting for the BibTeX entry suffix.
When combined wiht the main template, the same string is used for
display and for search.

I've checked the value of bibtex-actions-template and it is what I assume it should be:

bibtex-actions-template is a variable defined in ‘bibtex-actions.el’.
Its value is ((t . "${author:20}   ${title:48}   ${year:4}"))

  You can customize this variable.

Documentation:
Configures formatting for the BibTeX entry.
When combined with the suffix, the same string is used for
display and for search.

I now see the symbols indicating presence of notes and/or pdfs. But somehow they appear twice and break the alignment of the entries:

image

Any advice on how to adjust this?

(Thanks again!)

I'm on Emacs 27.2.

Originally posted by @apc in #93

Should one or both core read functions be public?

Right now, we have:

  • bibtex-actions--read
  • bibtex-actions--completing-read

I figure I may as well ask the question now: should we make one or both of them public, and so:

  • bibtex-actions-read
  • bibtex-actions-completing-read

EDIT: The linked PR makes the first public, but prompts me to wonder whether it even makes sense to have the two functions. I settled on this split for the bibtex-completion PR, but not sure it's needed here.

Preparing for 1.0; last call for command or function name changes

@apc raised a question about the wisdom of the bibtex-actions-open command name, and I explained the reasoning in a followup here: #120 (comment).

I'm kind of agnostic, so would probably leave as is unless there were strong arguments in favor of changing.

But now is the time to raise the question, as I'm planning to tag 1.0 soon, which is me arbitrarily drawing a line-in-the-sand on command and function name changes.

It doesn't mean we can't revisit later, but that I'd prefer not to.

To recap, we have the follow action verbs:

  1. open
  2. insert
  3. add

... and then command names based on these, the potential confusing ones being:

  • bibtex-actions-open
  • bibtex-actions-open-entry

Do note that aside from the clarity of the commands, I was also shooting for conciseness, to accommodate M-x, and menu displays like which-key (though see [this comment]((defalias 'apc/bib-open #'bibtex-actions-open-entry))) when using embark-act.

Bottomline, this (with marginalia annotations from the docstrings) should be as elegant, clear and concise as possible:

Screenshot from 2021-04-30 13-04-52

So what do people think?

cc @mtreca @wenjie2wang

Add predefined searches

Along with #118, we could support arbitrary pre-defined searches also, as supported in ivy-bibtex and helm-bibtex.

https://github.com/tmalsburg/helm-bibtex#predefined-searches

How best to do this here, given we have no common entry point command?

We might need a generic bibtex-actions command that can be wrapped like this; so:

(defun my/bib-mypubs ()
   (bibtex-actions :initial "Doe"))

... or simply tell users to wrap their default action command.

But if we did this, I guess I'd need an optional initial parameter on all commands.

Any other ideas?

Though I've tried to avoid macros, maybe this would be a good candidate?

OTOH, I'm not clear how useful this feature is, given how easy it is to run a search. The example of searching for your own pubs is not a very compelling one in my view.

Maybe could be useful for things like project-related searches though?

keep UI updated when changes to bib file(s) and pdf/note availability

Here's what we want:

If a user modifies specified bib files or note or pdf directory, the UI should update; e.g. the bibtex-actions-refresh command should auto-run.

I couldn't figure out how to elegantly add this (I don't want to use the bibtex-completion approach to this), but see this wiki section for some ideas.

https://github.com/bdarcus/bibtex-actions/wiki/Configuration#proactive-reloading-of-library

I think ideally a user could add a "watcher" function to their config, and have it handle this seemlessly, but that it would not be on by default.

It might even be a separate file, as with straight.

A PR is welcome.

tmalsburg/helm-bibtex#369

Differences between this and helm-bibtex and ivy-bibtex

For possible documentation:

  • like helm-bibtex, but unlike ivy-bibtex, bibtex-actions has support for multi-selection of candidates (conditioned on resolving #17)
  • helm-bibtex and ivy-bibtex provide a single command, and the actions accessed from there; bibtex-actions provides all of its actions as standard commands, available from M-x, without a single entry point.
  • bibtex-actions is based on completing-read-multiple, with a single dependency, and works with different completion systems (though in practice is best supported in selectrum) and supporting packages that are completing-read compliant; helm-bibtex and ivy-bibtex are based on helm and ivy respectively

Correct completion category?

Currently the code uses simply "bibtex".

But in this post , the author notes emacs has two internal bibtex-related categories:

  • bibtex-key
  • bibtex-string

Does it even matter for this purpose?

add key to "invisible" part of candidate to ensure uniqueness

This may be overthinking things, but the approach here now is that the candidate search string is configured with the two defcustoms. While there are sensible defaults there, it might be feasible that a user configures these in such a way that the candidates are not all unique. For example, say they nil the suffix, and some records don't have titles.

Potential simple solution: add the key to the "invisible" section of the candidate.

Add "bibtex-actions" org-cite "follow" processor

Once org-cite is merged to org-mode master ...

Edit: see comment from @ilupin #143 (comment) with example code to add to the package.

 (org-cite-register-processor 'bibtex-actions
    :follow (lambda (_ _) (call-interactively 'bibtex-actions-at-point)))

Just need to then add this to the README:

(setq org-cite-follow-processor 'bibtex-actions)

The org-cite author describes "follow" processors succinctly as "Follow is what happens when you use C-c C-o on a citation."

We can in turn use embark to attach additional commands, per @publicimageltd #137 (comment), for a lightweight emarkified org-ref-like experience.

The user would then have different choices for at-point functionality; they could do any mix of the following:

  1. use bibtex-actions-at-point to open a bibtex-actions command filtered to key(s)
  2. use org-open-at-point to run the bibtex-completion functions directly (this may be better than 1?)
  3. with 2, also add additional functions, via a keymap, for access with embark-act (see #142)

The user would then do:

  (setq org-cite-follow-processor 'bibtex-actions)

See also #140, and org-cite-basic-goto for an example:

https://code.orgmode.org/bzg/org-mode/src/wip-cite-new/lisp/oc-basic.el#L485

Seems like we might want to split the keymap and have a subset specific to at-point commands?

cc @ilupin and (since he might be curious) @oantolin

format-entry widths

#66 fixed one problem, but introduced another minor one.

The default suffix template has ${tags:*}, which should extend the last column to the end.

But it's truncated much earlier (if you see below, it seems like the tags are truncated at about 27 characters).

Screenshot from 2021-04-13 12-41-19

Must be because we no longer assume a single template.

Here's what I see in ielm:

ELISP> (bibtex-actions--process-display-formats bibtex-actions-template-suffix)
((t "          ${=key=:15}    ${=type=:12}    ${tags:*}" . 45))
ELISP> bibtex-completion-display-formats-internal
((t "${author:36} ${title:*} ${year:4} ${=has-pdf=:1}${=has-note=:1} ${=type=:7}" . 53))

Action does not work

Hi, thanks for the package.

I found that actions in bibtex-actions-open do not work. Below is my setup.

;; -- lexical-binding: t; --

(setq straight-use-package-by-default t
straight-check-for-modifications nil
straight-vc-git-default-clone-depth 1)

;; straight.el
(defvar bootstrap-version)
(let ((bootstrap-file
(expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
(bootstrap-version 5))
(unless (file-exists-p bootstrap-file)
(with-current-buffer
(url-retrieve-synchronously
"https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
'silent 'inhibit-cookies)
(goto-char (point-max))
(eval-print-last-sexp)))
(load bootstrap-file nil 'nomessage))

(defun straight-update-all ()
(interactive)
(straight-pull-all)
(straight-rebuild-all))

(setq use-package-verbose nil
use-package-enable-imenu-support t
use-package-always-defer t)
(straight-use-package 'use-package)

(defvar bibtex-base "~/org/bibliography/")
(defvar bibtex-pdf-directory (expand-file-name "pdf/" bibtex-base))
(defvar bibtex-note-directory (expand-file-name "papers/" bibtex-base))
(defvar bibtex-bibliography-list `(,(expand-file-name "references.bib" bibtex-base)))

(use-package bibtex-completion
:init
(use-package biblio
:bind (:map biblio-selection-mode-map
("n" . biblio--selection-next)
("p" . biblio--selection-previous))
:init (setq biblio-download-directory bibtex-pdf-directory))

(setq bibtex-completion-cite-prompt-for-optional-arguments nil
bibtex-completion-bibliography bibtex-bibliography-list
bibtex-completion-library-path bibtex-pdf-directory
bibtex-completion-notes-path bibtex-note-directory
bibtex-completion-display-formats '((t . "${year:4}\t${author:28}\t${title:*}"))
bibtex-completion-pdf-open-function #'bibtex-completion-pdf-open-external)

(with-eval-after-load 'org-ref-helm-bibtex
(setq bibtex-completion-display-formats '((t . "${year:4}\t${author:28}\t${title:*}"))))

:config
(defun bibtex-completion-pdf-open-external (file)
(save-window-excursion
(async-shell-command
(format "open %s" (shell-quote-argument file))))))

(use-package bibtex-actions
:straight (:host github :repo "bdarcus/bibtex-actions")
:demand t
:after (:any org latex)
:config
(setf (alist-get 'bibtex embark-keymap-alist) 'bibtex-actions-map)
(with-eval-after-load 'org-ref
(define-key org-mode-map [remap org-ref-insert-link] #'bibtex-actions-insert-key)))

(use-package selectrum
:hook (after-init . selectrum-mode)
:bind (("C-x C-z" . selectrum-repeat))
:init (setq selectrum-max-window-height 7))

(use-package prescient
:hook ((after-init . prescient-persist-mode))
:init
(use-package company-prescient
:hook (global-company-mode . company-prescient-mode))

(use-package selectrum-prescient
:hook (selectrum-mode . selectrum-prescient-mode)))

(use-package consult
:demand t
:after selectrum
:bind (("M-"" . consult-complex-command)
("C-x b" . consult-buffer)
("C-x 4 b" . consult-buffer-other-window)
("C-x 5 b" . consult-buffer-other-frame)
("C-x r j" . consult-register)
("C-x r l" . consult-bookmark)
("C-s" . consult-line)
("C-c a" . consult-git-grep)
("C-c i" . consult-imenu)
("C-c I" . consult-project-imenu)
("M-y" . consult-yank-pop)
("M-g m" . consult-mark)
("M-g k" . consult-global-mark)
("M-g o" . consult-outline)
("M-g f" . consult-find)
("M-g e" . consult-error)
("M-s m" . consult-multi-occur)
(" a" . consult-apropos))

:init
(setq consult-async-min-input 1
consult-ripgrep-command "rg --null --line-buffered --color=ansi --max-columns=1000 --no-heading --line-number . -e ARG OPTS")

(setq consult-preview-key nil
consult-config '((consult-line :preview-key any)))

(setq xref-show-xrefs-function #'consult-xref
xref-show-definitions-function #'consult-xref))

(use-package embark
:demand t
:after consult
:bind (("C-z" . embark-act)))

(use-package embark-consult
:demand t
:after (embark consult)
:hook (embark-collect-mode . embark-consult-preview-minor-mode))

When I call embark-act (C-z in my case) and e which should call bibtex-actions-open-notes, nothing happens and minibuffer exits. A message is printed at the same time: Done (re)loading bibliography. [2 times]

However, when I call bibtex-actions-open-notes directly and press Enter, it works fine.

The problem happens when using other actions too.

All package are using the latest master version on github.

CRM wrapper?

I'm not sure this will ever be needed, but I'll just note it for now.

In this comment, minad recommends the following:

I would recommend everyone to write a small wrapper around completing-read, simply because the completing-read API is so ugly. Like I did with consult--read. But in most cases a much simpler wrapper will do.

This might be worth pursuing if at some point we need that function to do more than it does now.

To be clear, we already do have a wrapper; I just mean a more configurable one.

UI options, add annotation function?

Right now, the UI presents a single, undifferentiated, formatted propertized display string, but internally searches using a different string.

This works well, though does result in some problems with multiple candidate selection currently (see #17).

But there's room with completing-read to use annotations for secondary bits of supporting information. Affixation (recently added to Emacs 28) obviously fits here too, though am unclear on the connection between them.

Is there value in rethinking the UI a bit to take advantage of that, and adding an annotation and/or affixation function to support it, either here or in a separate package?

If yes, how would that look, and what should that function generate?

Perhaps prefixes with nice icon fonts to indicate presence of pdfs, notes, or links?

Maybe a suffix with the key, type, and maybe tags?

If yes, the actually displayed string would be more compact (say just author, date, title?) to make room.

Something like this, with blue box indicating main display, and yellow affixes:

Screenshot from 2021-03-08 08-58-26

Maybe it's user-configurable?

Also, early in these discussions, @minad suggested the possibility of a separate package for annotation.

I suppose this ultimately depends just how rich these annotation/affix-based UIs can be now; what improvement they might offer.

Ideally, though, it would simultaneously enhance both the default orientation towards selectrum completion, while also opening up other opportunities.

Or we just don't worry about it for now; it's easy enough to add later, and it might be wise to allow these features to mature in Emacs

If someone does want to experiment with this, and believes to have come up with a better UI, do post screenshots.

See also #20.

Include default display-format better suited to wider range of data

I work closer to the humanities and use biblatex for the data format, and work with a sources that sometimes don't have authors or title, or which use alternate fields for year like date.

The result is I have lines in my display that are mostly empty.

Though we have to check whether anything's changed in bibtex-completion since I submitted it, see tmalsburg/helm-bibtex#192, including proposed solution.

Maybe we should include that so display works better out-of-box out-of-box?

Or maybe better, move example configurations to the wiki?

face conflict in README instructions with mouse highlight

Do you have any idea why the face properties specified as in the all-the-icons setup from the README are being overridden by selectrum-mouse-highlight?

Perhaps it'd be best to explain the odd behavior I'm encountering. Using the values for bibtex-actions-symbols from that snippet in the README, I get (as expected) that the pdf icon (e.g.) for an entry without a corresponding pdf is displayed in the face bibtex-actions-icon-dim. If, however, my mouse happens to be hovering over that entry, the icon is displayed using (I think?) the default face:

Without the pesky mouse hovering over anything:

image

With the mouse:

image

Originally posted by @apc in #94 (comment)

Sort candidates by date-added

I'm not sure how practical this is, given it would need to depend on a date-added field in the data, but it makes sense from a UX perspective: to present the most recently added references first.

No selection highlighting

As mentioned in #45, selectrum's syntax highlighting is not shown when using bibtex-action functions. Looking at the README, there doesn't seem to be any highlighting either (except an current line background highlight).

2021-03-19-180546_1920x1080_scrot

I originally thought that changing bibtex-completion-display-formats was responsible (through bibtex-actions-rich-ui), but setting it to nil doesn't change anything.

The other major change from my implementation (which still displays faces properly) is the use of propertize in bibtex-actions-get-candidates, which I suspect resets pre-existing face settings in the completion minibuffer.

Make macro optional parameter required, or remove macro entirely

This commit introduced the option on the bibtex-actions-define-action macro to explicitly specify the command name, rather than to construct it from the bibtex-completion function names:

166e9c9

Perhaps we should remove the latter functionality, and just require explicitly defining the name?

But arguably that simplifies the macro enough that maybe it's not not needed at all? And there might be benefit in having explicit functions?

Edit: the linked PR does in fact remove the macro.

(defun bibtex-actions-open (keys)
  "doc"
  (interactive (list (bibtex-actions--read)))
  (bibtex-completion-open-any (list keys)))

Should I be seeing a list of available actions when calling `embark-act`?

Ivy user here, testing the waters. Thanks for setting this up. Had shied away from trying non-ivy packages because ivy-bibtex is a central part of my workflow.

I've now disabled all my ivy-related packages and setup selectrum, embark, consult, and bibtex-actions. If I try e.g. bibtex-actions-open I get a list of entries in my main bibliography file. But calling embark-act on any of them doesn't show me a list of options, which is what I would have expected. I see that typing e.g. o will open the URL associated with a given entry, but looking at the bibtex-actions-keymap doesn't help me figure out how to e.g. edit the associated note etc.

Sorry if I'm missing something obvious here!

EDIT: OK, I figured out where to get the values of bibtex-actions-keymap in a readable form. (I just needed to go to the source!). For reasons that escape me, calling C-h v on bibtex-actions-keymap shows me the following unhelpful list of values:

bibtex-actions-map is a variable defined in ‘bibtex-actions.el’.
Its value is shown below.

  This variable may be risky if used as a file-local variable.

Documentation:
Keymap for ’bibtex-actions’.

Value:
(keymap
 (97 . bibtex-actions-add-pdf-to-library)
 (101 . bibtex-actions-open-entry)
 (110 . bibtex-actions-open-notes)
 (116 . bibtex-actions-add-pdf-attachment)
 (98 . bibtex-actions-insert-bibtex)
 (107 . bibtex-actions-insert-key)
 (114 . bibtex-actions-insert-reference)
 (99 . bibtex-actions-insert-citation)
 (108 . bibtex-actions-open-link)
 (112 . bibtex-actions-open-pdf)
 (111 . bibtex-actions-open))

[back]

I was unaware that looking at bibtex-actions.el in this case would have shown a human readable value.

I still want to know whether I should be seeing a list of available actions when calling embark-act, and if not whether there's a way of having that show up. I realize this may be something having to do with my embark settings; if so, please just let me know and I'll close this. (I just copied the example settings from the README on the embark repository.)

add a script for development testing

The new run.sh script is for users to test the released MELPA version.

I'd personally like an analog for development testing, which instead of installing bibtex-actions from MELPA, loads the local version.

add suffix UI

To accompany the recent prefix addition, add a configurable suffix.

add watch functions/commands?

Not sure about this, but we could add a convenience function/command to add and remove file-notify watches?

I wouldn't want to have any hard-coded assumptions though.

For sake of possible illustration, maybe something like:

(bibtex-actions-add-watch)
(bibtex-actions-rm-watch)

... and an accompanying defcustom?

(setq bibtex-actions-watch (list bibtex-completion-bibliography bibtex-completion-notes-path))

Or alternately, we can out some of this on the wiki.

cc @wenjie2wang

if we want to do this ...

I wish github had messaging. @mtreca - I added you to this repo just in case we wanted to do this apart from helm-bibtex. While there are downsides, there are also advantages.

Only makes sense, though, if the changes aren't added to bibtex completion (which I much prefer), so we should wait on that decision.

If we do go this direction, you could add your code, and I could add my changes on top of it.

candidate multi-select broken (again)

I really need to remember to test this before merging changes ...

Latest commit break things again.

I'm assuming I need to trim a string somewhere.

add caching of bib candidates

Thanks for this nice package! I gave it a try and it worked smoothly for me.

I have a relatively large BibTeX file with over 1,000 entries (and 10,000 lines) and I have been using ivy-bibtex. The bibtex-ctions takes a noticeable time to read/load the BibTeX file every time, while ivy-bibtex takes a noticeable time only the first time (assuming that the BibTeX file has not been changed). I guess it is because ivy-bibtex somehow caches the BibTeX file that has been read the first time. Thus, IMHO, it would be great if bibtex-actions contains a similar caching mechanism.

Originally posted by @wenjie2wang in #68

Simplify command names and docstrings

In line with the effort to streamline command names, should we change bibtex-actions-edit-notes to bibtex-actions-open-notes?

Perhaps the same question applies to "show-entry"?

That could simplify action verbs to "open" and "insert", for the most part.

FWIW, here's the helm-bibtex action descriptions. Maybe first line of the docstrings could also be shorter like this?

    :action (helm-make-actions
             "Open PDF, URL or DOI"       'helm-bibtex-open-any
             "Open URL or DOI in browser" 'helm-bibtex-open-url-or-doi
             "Insert citation"            'helm-bibtex-insert-citation
             "Insert reference"           'helm-bibtex-insert-reference
             "Insert BibTeX key"          'helm-bibtex-insert-key
             "Insert BibTeX entry"        'helm-bibtex-insert-bibtex
             "Attach PDF to email"        'helm-bibtex-add-PDF-attachment
             "Edit notes"                 'helm-bibtex-edit-notes
             "Show entry"                 'helm-bibtex-show-entry
             "Add PDF to library"         'helm-bibtex-add-pdf-to-library))

Improve CRM UI

As noted in the README, support for multiple candidate selection isn't great.

I do think the ideal long-term solution is for completion UIs to implement something similar to the helm approach; to improve their CRM UIs.

But in the absence of that, I thought I'd point out this suggestion, which could be a reasonable shorter-term improvement, say for inclusion in the wiki.

minad/vertico#1 (comment)

The basic idea is to have a "short" representation of the candidate string that would be used in the CRM prompt.

Could also be useful for #91.

multi-select broke

Selection of multiple candidates broke (returns empty results), as a result of this change. I guess I didn't test it enough.

The first result below is with a single selection, and the other with two.

ELISP> (bibtex-actions-read)
("sassen2000")

ELISP> (bibtex-actions-read)
(nil nil)

I've established the problem is with --get-candidates.

NOTE on issues vs discussions

FYI, I decided to setup the new GitHub "discussion" feature for discussions that have always had to happen in the issue tracker. If you have questions, general feedback, etc., take a look.

I also started a status thread (#31) over there.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.