Combine efforts with vim-spacemacs

[jb55]

https://github.com/jimmay5469/vim-spacemacs has been around for awhile now, maybe combine efforts?

/cc @jimmay5469 @sleexyz @ehamberg @nixmaniack

[ctjhoa]

Yeah sure, no problem with that. Looking at vim-spacemacs's source, it's seems pretty basic but I'm gonna start to support their commands.

[jimmay5469]

I created vim-spacemacs because I had been using spacemacs for a bit and was switching back to vim but found that I liked the spacemacs keybindings better than the ones I had previously set up on my own. Looking around I couldn't find any plugins at the time to help with this. Rather than just putting the keybindings in my own vimrc which it seemed like everyone else was doing, I just created the plugin so maybe other's could benefit from my work and pitch in if they wanted.

Looking through this plugin I am not sure I understand the source. Why are you using let g:lmap instead of regular mappings @ctjhoa, is this a vim-leader-guide thing or something?

[ctjhoa]

Yes let g:lmap is a vim-leader-guide thing (cf https://github.com/hecal3/vim-leader-guide#usage-examples).
I declare all my keybindings in this map and delegate to vim-leader-guide all the hard work.

I have added all your keybinding (except the NERDTree ones because I want to use netrw instead).

[jimmay5469]

Yeah, I think you hit on the biggest issue we are going to run into: what external plugins do we support... personally I do not use NERDTree, I don't even have it installed, but people wanted it and it didn't interfere with my workflow, so it got added. I'm not super experienced writing VIM plugins but if there was a way to create vim-spacemacs/spacevim in a external plugin agnostic sort of way that would be ideal in my mind.

Similarly, I'm not sure how I feel about declaring all my bindings using vim-leader-guide, what if a user doesn't want to use vim-leader-guide? I like the idea of the plugin being as lightweight as possible and then progressively enhancing if external plugins are found.

I've tried my best to keep external plugin usage localized/isolated among the few commands where they are absolutely necessary but this is still not as good as the progressive enhancement idea that I think would be ideal.

What are your thoughts on this? Do you have any idea how something like this might be achieved?

[ctjhoa]

Sure, plugin choices gonna be one of the hardest part.
My configs are always KISS so if I can avoid a plugin I'll do it.

I'm not against the "best effort" behavior (depending if a plugin is installed or not), I wrote all the keybindings with let g:lmap because I'm not a expert in nmap, vmap etc so I found it more readable that way. I will try to write a new branch with nmap syntax.

For progressive enhancement, IMO the best should be to display something like "You try to execute a command but you don't have the associated plugin. You should install 'foo/bar' first". However, I seriously have doubt on my VimL skills to do that now :P

So first, I think that be loosely coupled with vim-leader-guide could be a first step and then, we could start thinking of a better way to handle plugin commands.

Is it OK for you ?

[ctjhoa]

I gonna take example of https://github.com/lverweijen/vim-spacemacs/blob/master/plugin/spacemacs.vim thanks @lverweijen

[ctjhoa]

I have done some work to be independent from vim-leader-guide. Now I could take care of finding a way to do progressive enhancement.

[WuTheFWasThat]

i just found this, coming from jimmay5469/vim-spacemacs#10

vim-leader-guide looks great! is there any real downside to using it? (i've not yet tried using it, but as an outsider, i see none). I would guess prospective spacevim users would generally be happy to install many plugins, assuming no performance issues

(fyi, i also contributed some new bindings to the other project, but this one looks maybe a bit more ahead. i'll look into trying this project out making a PR tonight, but if i can't figure out how spacevim_bind works, someone else should maybe look at it... i do some integration with syntastic, easymotion, and undotree which could be nice)

[ctjhoa]

@WuTheFWasThat

vim-leader-guide could have some drawbacks (eg. hecal3/vim-leader-guide#11) but in most of the cases it's a great plugin. I remove a straight dependency on it to be more flexible.

Sorry I forgot the spacevim_bind documentation. spacevim_bind is just a helper to generate mapping as the same pattern is repeated for all the binding.
The pattern often looks like this:

vnoremap <silent> <SID>indent-region-or-buffer ==
vmap <leader>j= <SID>indent-region-or-buffer

As I want to display command name and not real executed command in vim-leader-guide, I have to do an indirection between keys mapped and the real command execute. So the first line define a silent named mapping, defining what's the displayed name in vim-leader-guide and the real action. And the second line associate keystrokes to a previously named mapping.

I'm not a vimL expert so it may not be the right way to do that.
If anyone have improvment I'm open to suggestion.

[WuTheFWasThat]

i'm no vimL expert either, but i took a stab at some new stuff: #3

i modified spacevim_bind a bit, i'm sure there's a better way than how i did it! i'm happy to change it if you have suggestions. also feel free to just take a subset of the commits or something

[WuTheFWasThat]

anyways with these changes merged, i believe there would be very little left unported from https://github.com/jimmay5469/vim-spacemacs .. should just be:

• <leader>pt for toggling project at root. we could add this, though it requires nerdtree. it also uses nerdtree for a different version of <leader>ft. apparently nerdtree is better so maybe these two switches should be made after all?
• <leader>gd for git diff. it is different from spacemacs, but i think maybe it should be included anyways, since it's nice
• <leader>sp ... i don't really like jimmay's version that much (or maybe it wasn't working for me), can probably be improved

[ctjhoa]

All the things reported by @WuTheFWasThat are backported now.

[WuTheFWasThat]

awesome!

i think you accidentally deleted fzf.vim from the README in 7f0762b

IMO this issue can be closed now, since the other project doesn't appear to really be actively developed anyways