citation.vim
citation.vim copied to clipboard
rafaqz
Denite support
Add support for denite.nvim which supersedes unite.vim.
I am looking at how denite.nvim works and see if I can do a pull request.
However since citation.vim is a source for unite.vim it may need a rewrite for denite.nvim.
Should citation.vim-like source for denite.nvim be a separate plugin?
It should be relatively simple to support both as its already in python - it can hook in directly skipping the vimscript component, if I understand the new plugin system correctly.
The bulk of code is in the bibtex/zotero database loading and parsing and it would be pretty wasteful to split that over two plugins (and have to update eg. the new betterbibtex format twice). I'm pretty sure only citation.py and loader.py have any knowledge of vim at all, it just a question of formatting the returned list of items in builder.py for consumption by denite.
It's been on my list but the documentation just wasnt there last time I looked, + I'm very busy, so a pull request would really be appreciated.
Yes the documentation is a bit thin. My first concern is getting variables from vimrc into Python.
On 14 Nov 2017 11:47 p.m., "Rafael Schouten" [email protected] wrote:
It should be relatively simple to support both as its already in python - it can hook in directly skipping the vimscript component, if I understand the new plugin system correctly.
The bulk of code is in the bibtex/zotero database loading and parsing and it would be pretty wasteful to split that over two plugins (and have to update eg. the new betterbibtex format twice). I'm pretty sure only citation.py and loader.py have any knowledge of vim at all, it just a question of formatting the returned list of items in builder.py for consumption by denite.
It's been on my list but the documentation just wasnt there last time I looked, + I'm very busy, so a pull request would really be appreciated.
The documentation wasn't great last time I looked
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rafaqz/citation.vim/issues/15#issuecomment-344438622, or mute the thread https://github.com/notifications/unsubscribe-auth/AIB3VYp0nUV0tyxp-9pxTOcBpSMJ_EhWks5s2iaHgaJpZM4Qdex7 .
Yep that is a question. Hopefully a vim.eval("g:citation_vim_bibtex_file") kind of thing is possible, then we don't have to change much. Other issues will include updating color highlighting and hooking in commands for file/url opening and showing combined info.
I'm imagining we split out unite and denite frontends from builder.py and everything deeper than that can stay as is.
Two options for configuration
- Old works for unite
vim.eval("g:citation_vim_bibtex_file")
- New
vim.vars.get('citation_vim_bibtex_file', 'path'),
which requires the following configuration in vimrc
call denite#custom#var('citation.vim', 'citation_vim_bibtex_file', 'path')
I have not yet found any dual unite/denite sources so with my limited understanding of unite/denite, I am unsure what to do in order to share configuration between unite and denite.
I actually prefered functions to variables in vimscript as I don't really understand g: stuff..
Actually, denite works this way regarding configuration. In source
self.vars = {
'mode': 'zotero',
'zotero_version': 4,
'zotero_path': '~/Zotero'
...
}
only require configuration in vimrc for example
call denite#custom#var('citation.vim', 'mode', 'zotero',)
call denite#custom#var('citation.vim', 'zotero_version', 4)
call denite#custom#var('citation.vim', 'zotero_path', '~/Zotero')
That looks good - if understand you we wont have to communicate with vim at all - just access self.vars directly in python?
It does mean everyone will have to convert their variable configuration to that format to use denite, but its only five or so lines.
The x:var_name situation defines variable in a particular scope (as far as I understand it) g: is just a globally scoped variable, as v: is an argument variable, s: is script level? etc.
Finding another plugin conversions to follow was an issue for me too, this should be pretty formulaic and there are a lot of plugins needing conversion...
plot of plugins needing conversion
Please explain that part? Are you saying that there is a number of unite plugins needing conversion?
I found a useful example of highlight and syntax here.
This is a source for grep by Shougo.
You need to use two functions define_syntax and highlight to control the syntax of output.
In grep source's case, the functions appears to execute vimscript so it may be trivial to copy the syntax region and syntax match stuff to denite source of citation.vim.
Thinking about global variables. The current unite implementation declare the global variables with defaults. For denite, two options similar to configuration above
- Should a vimscript file declare these global variables and the python source executes vim.vars.get(variable) to get these variables to work with?
- Or store defaults in python source?
The first option allows the unite and denite to share the defaults.
Sorry, I missed one of your comments regarding converting configuration to denite. This will only happen to users who use denite and so should make sense to them.
My idea is to change Context() class to be BaseContext() and copy Loader to UniteLoader. UniteLoader will inherit BaseContext() and add functions to extract relevant information through vim calls. BaseContext() will be used by denite sources.
Sorry I meant there are a lot of plugins that need to go through this same unite -> denite conversion process we are discussing so there should be a few examples around documenting the process.
It would be nice to go with option 1. and pull the vars in from vim globals so you can swap unite/denite smoothly, unless option 2 is vastly cleaner and simpler.
I was vaguely hoping there would be a syntax highlighting method without regex... we're building the description string from known separate strings then using regex to split it up again! for any other application it would be an insane strategy. But if the conversion is easy that's fine too.
The Context/UniteLoader idea sounds right. Context could have pre-defined fields too, its purpose is quite opaque right now. But you might need to split out some of Buillder() as well depending on the format denite wants data in. build_source() currently returns a list of arrays of length 4 built by item_to_array() from Item() objects, for consumption in vimscript. Another process might make more sense for denite.
Do you know of any unite plugin undergoing migration to denite?
On 17 Nov 2017 5:39 p.m., "Rafael Schouten" [email protected] wrote:
Sorry I meant there are a lot of plugins that need to go through this same unite -> denite conversion process we are discussing so there should be a few examples around documenting the process.
It would be nice to go with option 1. and pull the vars in from vim globals so you can swap unite/denite smoothly, unless option 2 is vastly cleaner and simpler.
I was vaguely hoping there would be a syntax highlighting method without regex... we're building the description string from known separate strings then using regex to split it up again! for any other application it would be an insane strategy. But if the conversion is easy that's fine too.
The Context/UniteLoader idea sounds ring. Context could have pre-defined fields too, its purpose is quite opaque right now. But you might need to split out some of Buillder() as well depending on the format denite wants data in. build_source() currently returns a list of arrays of length 4 built by item_to_array() from Item() objects, for consumption in vimscript. Another process might make more sense for denite.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rafaqz/citation.vim/issues/15#issuecomment-345312215, or mute the thread https://github.com/notifications/unsubscribe-auth/AIB3VcN1uPavgWsLQUvmk2zMo93-P1Bdks5s3cThgaJpZM4Qdex7 .
Found dual unite/denote sources
- https://github.com/rhysd/vim-grammarous
I suggest creating a dev branch for denite support and so I can push to it if I have time.
Can you work in a branch in your own repository? I shouldn't need to manage a dev branch here. I will pull it to master when it's working, but feel free to put in a pull request before that for feedback.
@DancingQuanta ?
I haven't worked on this because unite is still working fine, and I'm flat out with modelling projects and other work.
I'm keen for a pull request if anyone writes one. It shouldn't be major. See the discussions above, although I largely forget the details now. Otherwise I'll eventually do it when unite dies from neglect, or I have some spare time for this, but the first is more likely to be honest.
From what I can tell, denite.nvim loads new sources via importlib's SourceFileLoader.load_module(). This means one source per file.
This gives me two options;
- either I write a source for each of the bibliographic fields with a name like
citation/[field] args, or - use arguments like this
citation [field] args. The builder will check that the field is valid.
Yeah lets not write them all out. I used code generation in vimscript to avoid that kind of duplication originally, really the only reason there are so many sources - adding them only takes a few lines.
It seems like a poor design choice to have sources allocated at the file level instead of as some kind of hooks that you can trigger multiple times programatically within one specific file, but we will have to work with that. The args seem to be a good idea if it the syntax will be clean and easy.
Edit: Summarise - the second option seems best
I am inaccurate about the second option. The relevent denite.nvim documentation for the Denite command is
COMMANDS *denite-commands*
:Denite [{options}] {sources} *:Denite*
Creates a new Denite buffer.
Denite can be invoked with one or more sources. This can be
done by specifying the list on the command line, separated by
spaces. The list of candidates (the matches found in the
source by your filter string) will be ordered in the same
order that you specify the {sources}.
For example:
:Denite file/rec line
Will first list the files, then lines of the current buffer.
See also |denite-sources| the available sources.
Denite can accept a list of strings, separated with ":", after
the name of sources. You must escape ":" and "\" with "\"
in parameters themselves, or surround the parameter with quotes.
Examples:
"file/rec:foo:bar": the parameters of source file are
["foo", "bar"].
"file/rec:foo\:bar": the parameter of source file is
["foo:bar"].
"file/rec:'foo:bar'": the parameter of source file is
["foo:bar"].
"file/rec:foo::bar": the parameters of source file are
["foo", "", "bar"].
You can use evaluation cmdline by ``.
Note: In the evaluation, The special characters(spaces, "\"
and ":") are escaped automatically.
>
Arguments are separated by : for each source.
That still looks good to me. One thing to keep in mind is that arguments like that are already used for zotero database search. But they can just be tacked on after the source argument. Also citation_source will probably need to be in a separate source file, as its a different mechanism.
Just to be clear the option is that we otherwise have 20 something separate files, one for each source? I do think the argument is better!
I am thinking about replacing Context() with a dict because denite uses a lot of dicts and I do not want to map from a dict to Context(). This would mean rewriting the codebase.
The denite source allows you to specify a dict of variables with default and which a user can set a value from their vimrc. Also denite use a dict to store context information.
Just keep in mind that I still use unite and am reasonably happy with my set of plugins, and probably a few hundred other people as well going on download stats... so still working in unite with no config changes is the most important thing. Other than that do what needs to be done!
Yes, I will make to keep the unite source's functionality the same.
My plan is then to create two pull requests:
- Change Context() to dict (I worked out a vim search and replace regex to do this should be quick).
- Add denite source
This way I can make sure that each pull request is tested and ensure that unite source behaves as normally.
Thats a good idea. I have a testing suite to hammer it with, but it needs a zotero install with lots of specific data, bibtex files and does things like open pdfs so I never bothered to set up Travis. But I'll run it on your branch before merging each pull request.