- changed component to API
Moving VAM code into vim-pi
Issue #92
new
Old title: “checking out plugins - would it make sense to move VAM code into vim-pi so that all plugin managers could reuse it?”
Comments (9)
-
-
- changed title to Moving VAM code into vim-pi
- edited description
-
It makes sense. But first of all you should ask @Shougo and probably somebody else whether they will reuse it and what they actually want to reuse.
Maybe it makes more sense to try to push this code into
autoload/getscript[/unpack].vimin main Vim tree. Note: there already is unpacking code. It just is not moved to the function, and does not have some features like 7z support. I would propose the following API:getscript#GuessUnpackSequence :: filename -> [extension](extensions in a list are fixed:abc.tar.gzandabc.tgzboth result in['tar', 'gz']),getscript#Unpack :: (filename, [extension]) -> IO ()(this one also throws). Reasoning for splitting: I have seen some plugins with incorrect extensions like zip with.tar.autoget.pywith the help of magic deals with it (no jokes: it is a name of python module: bindings to the codefileuses) and it may record its results intoaddon-infolike I suggested earlier.// I have highlighted @Shougo so that he should receive notifications.
-
I think the code (from VAM-kr) should be splitted with plugin database like vim-pi-tools repository. People may want to use another routine for it.
-
Agreed on the code already in database, I was thinking about it. But this issue is about code not in vim-pi. I think pushing patch for GLVS is at least worth trying.
-
Agreed on the code already in database, I was thinking about it. But this issue is about code not in vim-pi. I think pushing patch for GLVS is at least worth trying.
-
I think pushing patch for GLVS is at least worth trying.
Why do you want to push patch for it?
-
Because GLVS is already in Vim tree.
-
OK. But Vim may include other official plugin manager.
- Log in to comment
