Upgrade StorageZotero CLI version
Last night I had a dream... sigh... if only a developer would be interested in making a Unixy Zotero CLI version with few dependencies, which would include an interface similar to mutt.
After pondering on this, I wrote some ideas down. Please feel free to share your ideas, and let me know if you'd want to hear mine. Disclaimer: I'm not a heavy user of Zotero, nor a programmer.
zotero [-v,--verbose|-p,--print] {CMD} [OPTIONS] [KEYS|URLS] [post-process OPTIONS]
After pondering on this, I wrote some ideas down. Please feel free to share your ideas, and let me know if you'd want to hear mine. Disclaimer: I'm not a heavy user of Zotero, nor a programmer.
zotero [-v,--verbose|-p,--print] {CMD} [OPTIONS] [KEYS|URLS] [post-process OPTIONS]
You'll have to expand on what you want this CLI to do
(markdown isn't supported here damn)Basically, it would do everything you could currently do with Zotero. I noticed that for improving or adding features, the gui implementation is often a setback. Yet when it comes to managing bibliography, accurate field contents is way more important that quick aggregation of references. Vim-like features allow you to concentrate on the keyboard and automate or search or replace text matters.
Firstoff, imagine zotero gui bringing up a command line interface similar to mutt. A tabular representation of the references from which all references are editable in a Vim-like manner. All the functions could be used in the one-liner mentioned above or in the mutt-like-cli command line.
These functions would include a filter and search function with the args: [-r regex] [-t type] [-a author] [-f field] [pattern], several functions that take either [URL] or [KEY] as arguments, and a set function, for setting options like set verbosity, set proxies, set exportstyle, set attachpath...
Other one-liner commands (will require some cleverness):Key mappings for the cli along with the single character field variables and configuration options could also be defined in .zoterorc.
- functions that take [URL] as arg: scrape, lsitems, lsattach
- functions that take [KEY] as arg: relate, tag, note, cite, export, duplicate, rm, mv and edit
- general functions: update, gettrans, getsty
(Note that I would prefer [KEY] by default, to be autocompleted as a result of a complete setting. That setting would be by default the Zotero cite key, but superseded by the Better-Bib(La)TeX-key from the 'extra' field, if it exists. But you should be able to set additional field names in the list using `zotero set complete 'bbt,citekey,title,author'`.)The scrape and edit functions could have post processing options:
For example: "%a\/%y-%a_%t.pdf" could result in the full path /home/user/.zotero/zotero/default/1978/1978-Author_Short_Title.pdf provided that the "attachpath" setting is /home/user/.zotero/zotero/default/
Piping the output of the search command to grep and then to one of the "[KEY] commands" could be very useful.
Listing scrapable items with zotero lsitems [URL] provides a number per item which can be given as agument to "zotero scrape" to add that item to the library: zotero scape 9 http://example.org/books
That's it for now, I hope it made sense. These are as you know only thoughts about a front-end implementation. But connecting to the localhost, fetching translators and styles etc can't be too hard. Again, I'm not a programmer and I'm not at all familiar with Zotero development.
The more general issue would be that the number of people who love vim-style interfaces is relatively small (though, obviously, people who love vim _really_ love it), so this is going to be of limited appeal . My guess would be that you're looking at tens of thousands, if not hundreds of thousands of dollars worth of developer time (whether paid or volunteered). It's always possible that you find someone who is interested in investing those types of resources--and you can certainly try, that's why Zotero is open--but it's not going to be easy.
It may be possible to write something more limited, which just gives you read/write access to the Zotero database from a CLI but doesn't e.g. have access to translators etc. That could go right through the SQlite and thus do away with the mozilla dependencies, though that's always a bit of a risky proposition.
Let's abandon the shell approach.
Ok, in the event of an enthusiast programmer reading this who wants to get more of Vim into Firefox in order to manage his/her references: please speak up and share some ideas!
My motivation for thinking about this, is that wile I love the obvious benefits of Zotero, I'm bothered by the complicated interface and the amount of mouse clicks it requires. The best and only workflow to get web-scraped references to BibLaTeX is trough Zotero. But as this is a one-way deal, editing exported references involves abandoning the benefits of the database, its sharing and tagging system.
For example, try this to echo multiple lines to the Vimperator output:Maybe a rolling release of a gui-less Zotero addon could be used alongside a Vimperator/Pentadactyl plugin, which have great utilities and modules to play with.
:js liberator.echo(
'<table><tr><td>hello world</td></tr><tr><td>hello again</td></tr></table>',
liberator.modules.commandline.FORCE_MULTILINE
)
Note that the autocompletion of the internal javascript (using :js in Vimperator) really makes browsing the javascript internals easy.
Will Shanks's work on Zoterodactyl is great, but I would go for the full-featured autocompleted cmdline approach, if I were a developer. (I.e. not just map some keys to zotero functions.) Basically the capability of filtering, echoing, opening urls from the output, and tab-selecting items or their fields is already built-in.
So why not use a customisable keyboard-driven interface for editing fields and adding notes for Zotero? It probably requires some thought and developer time and I'm not precisely sure how it should work either. Interfacing with the SQlite database through the Vimperator commandline can't be much different as is currently is.
Imagine typing the following::zopen 1978<tab><tab><CR>to start looking for a pattern that is autocompleted and highlighted in the multiline output, tab-selecting the relevant item and pressing enter to confirm the command, opening the item. I think the simplest thing to do is to generate a simple html form on-the-fly with pre-filled field values and open it in a new tab. The input fields (or any other element) can be easily selected using the usual Vimperator navigation techniques (i.e. [number]gi which I read as 'go input')
From Input mode, (g)vim can then be accessed.
That's it for now, I hope this made sense. Again, these are thoughts about a front-end implementation, maybe I don't fully understand how difficult the implementation for Vimperator modules could be. Thanks for responding!
Is would be absolutely fabulous if at least the zotero.sqlite database could be browsed and exports could be managed via the command line.
I really use the wonderful zotero mostly for agregating and downloading papers into the db. I search and query the storage folder with find.
Also not so sure if the "not used by many" is really the counting argument. Inkscapes comandline interface is also used by a minority. But these are the people that write software that uses it and hence strengthen the opensoftware ecosystem. The commandline is an interface to other software and other users.
You could, for those, take the approach that Emiliano has taken with his Zotero++ series of tools and make them accessible via a localhost server.
It uses the Zotero web API but caches the library in a local SQLite database (with a fulltext-index) for faster querying. You can edit notes with the text editor of your choice in the format of your choice (as long as it's supported by pandoc) and they will be transparently converted into HTML for storage and display in Zotero (the original markup is preserved, though!)