Denite support

[DancingQuanta]

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?

[rafaqz]

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.

[DancingQuanta]

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" ***@***.***> 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 <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIB3VYp0nUV0tyxp-9pxTOcBpSMJ_EhWks5s2iaHgaJpZM4Qdex7> .

[rafaqz]

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.

[DancingQuanta]

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..

[DancingQuanta]

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')

[rafaqz]

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.

[rafaqz]

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...

[DancingQuanta]

plot of plugins needing conversion

Please explain that part? Are you saying that there is a number of unite plugins needing conversion?

[DancingQuanta]

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.

[DancingQuanta]

Thinking about global variables. The current unite implementation declare the global variables with defaults.
For denite, two options similar to configuration above

1. Should a vimscript file declare these global variables and the python source executes vim.vars.get(variable) to get these variables to work with?
2. Or store defaults in python source?

The first option allows the unite and denite to share the defaults.

[DancingQuanta]

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.

[rafaqz]

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.

[DancingQuanta]

Do you know of any unite plugin undergoing migration to denite?

…

On 17 Nov 2017 5:39 p.m., "Rafael Schouten" ***@***.***> 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 <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIB3VcN1uPavgWsLQUvmk2zMo93-P1Bdks5s3cThgaJpZM4Qdex7> .

[DancingQuanta]

Found dual unite/denote sources

• https://github.com/rhysd/vim-grammarous

[DancingQuanta]

https://github.com/lervag/vimtex