Re: Overriding builtin plugin with packages?

Ben Fritz wrote: > In testing my 2html plugin, I wanted to install it simply in my user > directory using the packages feature, like I do with my other plugins. > > When I do this, placing a vim-tohtml folder under > .vim/pack/mine/start/vim-tohtml, Vim correctly adds the vim-t

Overriding builtin plugin with packages?

In testing my 2html plugin, I wanted to install it simply in my user directory using the packages feature, like I do with my other plugins. When I do this, placing a vim-tohtml folder under .vim/pack/mine/start/vim-tohtml, Vim correctly adds the vim-tohtml package directory to the runtimepath

Re: vim-8 packages and package managers

Hi, 2017/7/8 Sat 23:22:50 UTC+9 Marcin wrote: > Hello vim_use > > Vim-8 has packages. Is this a breaking feature for some of the vim package > managers out there, and to which extend they support it?. I know that > pathogen supports them, what about others like VAM, vu

vim-8 packages and package managers

Hello vim_use Vim-8 has packages. Is this a breaking feature for some of the vim package managers out there, and to which extend they support it?. I know that pathogen supports them, what about others like VAM, vundle, neobundle? Best regards, Marcin Szamotulski -- -- You received

Re: How to load updated syntax files using native packages?

> Is that related to your symbolic link you mentioned? I wonder if it actually > does cause an impact. It... looks like that might actually be the case. I tried again with ~/.vim/pack as a normal directory and not as a symbolic link. Now, ~/.vim/pack was second in the runtimepath after ~/.vim.

Re: How to load updated syntax files using native packages?

On Thursday, November 17, 2016 at 10:54:22 PM UTC-6, Dugan Chen wrote: > > If I clone it as ~/.vim/pack/me/start/python-syntax and then start vim > without a .vimrc, then I get this as the output for "set rtp": > >

Re: How to load updated syntax files using native packages?

Before you ask about the paths: ~/.vim/pack is a symbolic link. I assume that's not a problem. -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You

Re: How to load updated syntax files using native packages?

On Thursday, November 17, 2016 at 8:39:39 AM UTC-8, Ben Fritz wrote: > Vim *inserts* the package directories prior to the distributed runtime files. > So it *should* find your package syntax files first. > Posting your actual 'runtimepath' may help. Also see the output of the > :scriptnames

Re: How does one load plugin-specific settings after a plugin with the new packages feature?

Ben Fritz wrote: > > > Previously, when I installed a plugin, I could set up mappings to that > > > plugin's functionality by putting commands in > > > ~/vimfiles/after/plugin/someplugin_maps.vim > > > > > > Now with packages, this no

Re: How does one load plugin-specific settings after a plugin with the new packages feature?

On Friday, August 5, 2016 at 2:08:15 PM UTC-5, Bram Moolenaar wrote: > Ben Fritz wrote: > > > Previously, when I installed a plugin, I could set up mappings to that > > plugin's functionality by putting commands in > > ~/vimfiles/after/plugin/someplugin_maps.vim &g

Re: How does one load plugin-specific settings after a plugin with the new packages feature?

Ben Fritz wrote: > Previously, when I installed a plugin, I could set up mappings to that > plugin's functionality by putting commands in > ~/vimfiles/after/plugin/someplugin_maps.vim > > Now with packages, this no longer works, because loading plugins is done as > with

How does one load plugin-specific settings after a plugin with the new packages feature?

Previously, when I installed a plugin, I could set up mappings to that plugin's functionality by putting commands in ~/vimfiles/after/plugin/someplugin_maps.vim Now with packages, this no longer works, because loading plugins is done as with ":runtime! plugin/**/*.vim" BEFORE loadin

Re: Difficulty with Packages

On Tuesday, June 28, 2016 at 3:39:50 PM UTC-5, Bram Moolenaar wrote: > Matthew Desjardins wrote: > > > > > I've been trying to get packages to work, but I'm having difficulties > > > > with the resulting 'runtimepath'. Packages are all added after my own > >

Re: Difficulty with Packages

Tumbler Terrall wrote: > > Looks like a forward/backward slash mixup problem. > > > > Can somone using Windows reproduct this and find out what is the best > > way to fix it? > > I don't think that mixes slashes is the problem. I have mixed slashes > in my runtimepath, and it works fine.

Re: Difficulty with Packages

> Looks like a forward/backward slash mixup problem. > > Can somone using Windows reproduct this and find out what is the best > way to fix it? I don't think that mixes slashes is the problem. I have mixed slashes in my runtimepath, and it works fine. Windows happily uses either kind (or even

Re: Difficulty with Packages

Matthew Desjardins wrote: > > > I've been trying to get packages to work, but I'm having difficulties > > > with the resulting 'runtimepath'. Packages are all added after my own > > > "after" directory, which I would have assumed would be at the end

Re: Difficulty with Packages

On Monday, June 27, 2016 at 4:56:46 PM UTC-4, Bram Moolenaar wrote: > Matthew Desjardins wrote: > > > I've been trying to get packages to work, but I'm having difficulties > > with the resulting 'runtimepath'. Packages are all added after my own > > "after" dir

Re: Difficulty with Packages

Matthew Desjardins wrote: > I've been trying to get packages to work, but I'm having difficulties > with the resulting 'runtimepath'. Packages are all added after my own > "after" directory, which I would have assumed would be at the end to > allow me to override thi

Difficulty with Packages

I've been trying to get packages to work, but I'm having difficulties with the resulting 'runtimepath'. Packages are all added after my own "after" directory, which I would have assumed would be at the end to allow me to override things. Am I missing something? -- -- Yo

Re: list packages installed through vimball

On Fri, Apr 29, 2016 at 1:59 AM, Gary Johnson <garyj...@spocom.com> wrote: > On 2016-04-28, kamaraju kusumanchi wrote: >> Can someone tell me how to list all packages that were installed >> through vimball? >> >> :help vimball tells about how to install, remove a v

Re: list packages installed through vimball

On 2016-04-28, kamaraju kusumanchi wrote: > Can someone tell me how to list all packages that were installed > through vimball? > > :help vimball tells about how to install, remove a vimball. It does > not talk about listing all the package names. Any ideas? > > FWI

list packages installed through vimball

Can someone tell me how to list all packages that were installed through vimball? :help vimball tells about how to install, remove a vimball. It does not talk about listing all the package names. Any ideas? FWIW, I am using vim 7.4 on Debian Jessie. thanks raju -- Kamaraju S Kusumanchi | http

Re: Packages and plugin's subdirectories

Nicola wrote: > On 2016-03-30 04:43:56 +, Nicola said: > > > > If that is the intended behaviour, maybe it should be noted more explicitly > > in the help files. In `:h packages`, it is written that Vim: > > Also note this difference: if pack/foo/opt/n

Re: Packages and plugin's subdirectories

On 2016-03-30 04:43:56 +, Nicola said: If that is the intended behaviour, maybe it should be noted more explicitly in the help files. In `:h packages`, it is written that Vim: Also note this difference: if pack/foo/opt/neocomplete is loaded during a session with `:packadd neocomplete

Re: Packages and plugin's subdirectories

, let's hear it. If that is the intended behaviour, maybe it should be noted more explicitly in the help files. In `:h packages`, it is written that Vim: [...] scans all directories in 'packpath' for plugins [...] and loads them. The directory is added to 'runtimepath'. In the example Vim will find

Re: Packages and plugin's subdirectories

e.vim > buffer.vim > dictionary.vim > tag.vim > > It saves a bit of time searching directories. > > If someone sees a good reason to also search in subdirectories, let's > hear it. This variant is not usable for the

Re: Packages and plugin's subdirectories

Nicola wrote: > Neocomplete's plugin folder is organized as follows: > > plugin/ > neocomplete.vim > neocomplete/ > buffer.vim > dictionary.vim > tag.vim > > No matter whether neocomplete is in pack/*/start/ or in pack/*/opt/, > only plugin/neocomplete.vim is loaded (at startup

Packages and plugin's subdirectories

Neocomplete's plugin folder is organized as follows: plugin/ neocomplete.vim neocomplete/ buffer.vim dictionary.vim tag.vim No matter whether neocomplete is in pack/*/start/ or in pack/*/opt/, only plugin/neocomplete.vim is loaded (at startup or with :packadd, respectively). Is that

Re: Packages: best practices?

Am 26.03.2016 um 21:03 schrieb Gary Johnson: On 2016-03-26, Andy Wokula wrote: if has("vim_starting") " init on VimEnter else " init immediately endif That's a very odd application of has(). The has() function is clearly intended to indicate presence or absence of some feature that

Re: Packages: best practices?

Andy Wokula wrote: > Am 26.03.2016 um 19:31 schrieb Nicola: > > On 2016-03-26 17:56:34 +, Bram Moolenaar said: > > >> I suppose there is no easy way to know if VimEnter already fired. > > >> Perhaps we need a flag that indicatest this, so you can do: > >> > >> if v:vim_did_enter > >>

Re: Packages: best practices?

On 2016-03-26, Andy Wokula wrote: > Am 26.03.2016 um 19:31 schrieb Nicola: > >On 2016-03-26 17:56:34 +, Bram Moolenaar said: > > >>I suppose there is no easy way to know if VimEnter already fired. > > >>Perhaps we need a flag that indicatest this, so you can do: > >> > >>if

Re: Packages: best practices?

On 2016-03-26 18:53:44 +, Andy Wokula said: if has("vim_starting") " init on VimEnter else " init immediately endif That works, thanks! Nicola -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For

Re: Packages: best practices?

Am 26.03.2016 um 19:31 schrieb Nicola: On 2016-03-26 17:56:34 +, Bram Moolenaar said: I suppose there is no easy way to know if VimEnter already fired. Perhaps we need a flag that indicatest this, so you can do: if v:vim_did_enter call s:init() else au VimEnter *

Re: Packages: best practices?

On 2016-03-26 17:56:34 +, Bram Moolenaar said: Nicola wrote: Then, everything should work as before, with the exception of YCM, which must now be loaded manually. To do so, I need :packadd youcompleteme but also :call youcompleteme#Enable() because :packadd does not trigger VimEnter.

Re: Packages: best practices?

Nicola wrote: > > Then, everything should work as before, with the exception of YCM, which > > must > > now be loaded manually. To do so, I need > > > > :packadd youcompleteme > > > > but also > > > > :call youcompleteme#Enable() > > > > because :packadd does not trigger VimEnter. > > This

Re: Packages: best practices?

On 2016-03-25 19:15:59 +, Nicola said: I would like to start using Vim's new package feature, but first I want to make sure that I have understood how it is supposed to be used. Is it too early to ask for tips about that? First let me summarize what I have understood about packages (please

Packages: best practices?

I would like to start using Vim's new package feature, but first I want to make sure that I have understood how it is supposed to be used. Is it too early to ask for tips about that? First let me summarize what I have understood about packages (please correct anything wrong): - every package

Re: Packages

Matthew Desjardins wrote: > I like the current implementation, but what about "after" directories? > Is it just me or are those missing, too? The "after" directory is mosly useful to add your personal preferences. In what situation would you want to use an "after" directory in a package? --

Re: Packages

On Wednesday, March 16, 2016 at 9:43:24 AM UTC-5, Bram Moolenaar wrote: > Matthew Desjardins wrote: > > > I like the current implementation, but what about "after" directories? > > Is it just me or are those missing, too? > > The "after" directory is mosly useful to add your personal

Re: Packages

I like the current implementation, but what about "after" directories? Is it just me or are those missing, too? -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit

Re: Packages

On 8 March 2016, Bram Moolenaar wrote: > > Gary Johnson wrote: > > > On 2016-03-07, Eric Christopherson wrote: > > > On Sun, Mar 06, 2016, Benjamin Fritz wrote: > > > [in attachment] > > > > +directory under your package, whereas plugins you enable on demand go > > > > in

Re: Packages

Hi Bram, 2016-3-8(Tue) 21:49:39 UTC+9 Bram Moolenaar: > Gary Johnson wrote: > > > On 2016-03-07, Eric Christopherson wrote: > > > On Sun, Mar 06, 2016, Benjamin Fritz wrote: > > > [in attachment] > > > > +directory under your package, whereas plugins you enable on demand go > > > > in an > > >

Re: Packages

Gary Johnson wrote: > On 2016-03-07, Eric Christopherson wrote: > > On Sun, Mar 06, 2016, Benjamin Fritz wrote: > > [in attachment] > > > +directory under your package, whereas plugins you enable on demand go in > > > an > > > +"opt" directory so that |:packadd| can find them. See |pack-add|

Re: Packages

On 2016-03-07, Bram Moolenaar wrote: > Eric Christopherson wrote: > > > On Sun, Mar 06, 2016, Benjamin Fritz wrote: > > [in attachment] > > > +directory under your package, whereas plugins you enable on demand go in > > > an > > > +"opt" directory so that |:packadd| can find them. See |pack-add|

Re: Packages

On 2016-03-07, Eric Christopherson wrote: > On Sun, Mar 06, 2016, Benjamin Fritz wrote: > [in attachment] > > +directory under your package, whereas plugins you enable on demand go in an > > +"opt" directory so that |:packadd| can find them. See |pack-add| below. > > OK, I see that the intended

Re: Packages

.vim > > > ~/.vim/bundle/someplugin/syntax/beez.vim > > > > > > With packages, the default 'packpath' is the same as runtimepath. The > > > example code creates a ~/.vim/pack/my/always directory. Is "always" > > > synonymous with "

Re: Packages

Eric Christopherson wrote: > On Sun, Mar 06, 2016, Benjamin Fritz wrote: > [in attachment] > > +directory under your package, whereas plugins you enable on demand go in an > > +"opt" directory so that |:packadd| can find them. See |pack-add| below. > > OK, I see that the intended semantics of

Re: Packages

On Mon, Mar 07, 2016, Nikolay Aleksandrovich Pavlov wrote: > Without isolated namespaces this is absolutely useless behaviour. If A > depends on B, C depends on B and D does not depend on anything and > plugin manager created packages (A,B1), (C,B2) and (D) then out of B1

Re: Packages

On Sun, Mar 06, 2016, Benjamin Fritz wrote: [in attachment] > +directory under your package, whereas plugins you enable on demand go in an > +"opt" directory so that |:packadd| can find them. See |pack-add| below. OK, I see that the intended semantics of the word "ever" is as a synonym of

Re: Packages

l files for a plugin, into a >> > directory under "bundle": >> > >> > ~/.vim/bundle/someplugin/plugin/foo.vim >> > ~/.vim/bundle/someplugin/autoload/bar.vim >> > ~/.vim/bundle/someplugin/syntax/beez.vim >> > >> > With packag

Re: Packages

eplugin/plugin/foo.vim > > ~/.vim/bundle/someplugin/autoload/bar.vim > > ~/.vim/bundle/someplugin/syntax/beez.vim > > > > With packages, the default 'packpath' is the same as runtimepath. The > > example code creates a ~/.vim/pack/my/always directory. Is "always

Re: Packages

On Saturday, March 5, 2016 at 4:09:50 PM UTC-5, ZyX wrote: > I guess you now see why built-in solution is needed: I found *six* > ways to break code that has only five lines. Solution should not > necessary be a built-in command, but at least autoload function > shipped with Vim, or you will see

Re: Packages

ple are thinking about them that >> way :)), pathogen has one more useful feature, the :Helptags command. >> It runs :helptags in the directories in runtimepath. Perhaps add a >> :packhelptags[!] that does the same thing for packages (with the bang >> version forcing update of

Re: Packages

d. > It runs :helptags in the directories in runtimepath. Perhaps add a > :packhelptags[!] that does the same thing for packages (with the bang > version forcing update of help for disabled plugins)? > > /lcd Well that's really easy to implement in vimscript, something l

Re: Packages

t to your package. The advantage is that you can test that > specific version. Might have a name conflict if the user downloads > it separately, thus you may want to rename it. And of course keep it > updated. [...] So what happens when two packages come with conflicting versions o

Re: Packages

gt; > the new code fails at that as well. > > > > I tried to avoid the explosion of 'runtimepath', but it appears so many > > users and plugins already rely on it (see the response in this thread) > > that I had to give up on it. Also, it seems nobody is complaini

Re: Packages

Eric Christopherson wrote: > On Fri, Mar 04, 2016, Matthew Desjardins wrote: > > On Friday, March 4, 2016 at 12:37:08 PM UTC-5, Bram Moolenaar wrote: > > > It does add the extra directory level, so that groups of plugins can be > > > installed together. Some installed always, some optionally

Re: Packages

On Fri, Mar 04, 2016, Matthew Desjardins wrote: > On Friday, March 4, 2016 at 12:37:08 PM UTC-5, Bram Moolenaar wrote: > > It does add the extra directory level, so that groups of plugins can be > > installed together. Some installed always, some optionally (or when > > needed or when specific

Re: Packages

ails at that as well. > > I tried to avoid the explosion of 'runtimepath', but it appears so many > users and plugins already rely on it (see the response in this thread) > that I had to give up on it. Also, it seems nobody is complaining about > the long path. > > So I added

Re: Packages

On 4 March 2016, Bram Moolenaar wrote: > > Lcd wrote: > > > On 4 March 2016, Nikolay Aleksandrovich Pavlov > > wrote: > > > 2016-03-04 14:25 GMT+03:00 LCD 47 : > > > > A tangentially related question. Assume I need to check > > > >

Re: Packages

On Friday, March 4, 2016 at 12:37:08 PM UTC-5, Bram Moolenaar wrote: > It does add the extra directory level, so that groups of plugins can be > installed together. Some installed always, some optionally (or when > needed or when specific features are present, e.g. Python). > > This does make it

Re: Packages

Lcd wrote: > On 4 March 2016, Nikolay Aleksandrovich Pavlov wrote: > > 2016-03-04 14:25 GMT+03:00 LCD 47 : > > > On 3 March 2016, Bram Moolenaar wrote: > > > [...] > > >> I realize several people who have previously been using Pathogen >

Re: Packages

I had to give up on it. Also, it seems nobody is complaining about the long path. So I added 'packpath' as the short alternative. > Maybe it's time to step back and document the goals of this new > interface and design a coherent system to address each goal before > throwing code at it. The curr

Re: Packages

On 4 March 2016, Nikolay Aleksandrovich Pavlov wrote: > 2016-03-04 14:55 GMT+03:00 LCD 47 : > > On 4 March 2016, Nikolay Aleksandrovich Pavlov > > wrote: > >> 2016-03-04 14:25 GMT+03:00 LCD 47 : > >> > On 3 March 2016,

Re: Packages

2016-03-04 14:55 GMT+03:00 LCD 47 : > On 4 March 2016, Nikolay Aleksandrovich Pavlov wrote: >> 2016-03-04 14:25 GMT+03:00 LCD 47 : >> > On 3 March 2016, Bram Moolenaar wrote: >> > [...] >> >> I realize several people who

Re: Packages

On 4 March 2016, Nikolay Aleksandrovich Pavlov wrote: > 2016-03-04 14:25 GMT+03:00 LCD 47 : > > On 3 March 2016, Bram Moolenaar wrote: > > [...] > >> I realize several people who have previously been using Pathogen > >> are confused.

Re: Packages

t;autoload/foo.vim", 1) != "" > " foo is installed > ... > endif > > What would be the preferred way to do the same with the new package > scheme, accounting for optional packages, old style plugins, and so on? > >

Re: Packages

if globpath(, "autoload/foo.vim", 1) != "" " foo is installed ... endif What would be the preferred way to do the same with the new package scheme, accounting for optional packages, old style plugins, and so on? /lcd -- -- You

Re: Packages

On Thursday, March 3, 2016 at 2:02:52 PM UTC-6, Bram Moolenaar wrote: > Matthew Desjardins wrote: > > > On Friday, February 26, 2016 at 9:20:00 AM UTC-5, Matthew Desjardins wrote: > > > There have been a couple of people posting about how the new package > > > feature can, in its current state,

Re: Packages

Matthew Desjardins wrote: > On Friday, February 26, 2016 at 9:20:00 AM UTC-5, Matthew Desjardins wrote: > > There have been a couple of people posting about how the new package > > feature can, in its current state, replace Pathogen. > > > >

Re: Packages

On Friday, February 26, 2016 at 9:20:00 AM UTC-5, Matthew Desjardins wrote: > There have been a couple of people posting about how the new package feature > can, in its current state, replace Pathogen. > > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ >

Re: Packages

Den 2016-03-02 kl. 21:52, skrev Bram Moolenaar: > >Still wondering what to call the command that adds a directory under > >pack/opt to 'runtimepath': > > :addfrompack > > :packadd > > :addrunpath > > > >? > >I suggest :addplugin or :addpluginrtp to be consistent with

Re: Packages

2016-03-02 1:43 GMT+03:00 Bram Moolenaar : > > Matthew Desjardins wrote: > >> It also seems that even if a plugin has "plugin/*.vim" files, its >> "ftdetect" files aren't loaded in time. > > I suppose we should load them at the same time. > > I now notice that ftdetect isn't

Re: Packages

Matthew Desjardins wrote: > It also seems that even if a plugin has "plugin/*.vim" files, its > "ftdetect" files aren't loaded in time. I suppose we should load them at the same time. I now notice that ftdetect isn't mentioned in the startup procedure. Still wondering what to call the command

Re: Packages

It also seems that even if a plugin has "plugin/*.vim" files, its "ftdetect" files aren't loaded in time. -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit

Re: Packages

Ben Fritz wrote: > On Friday, February 26, 2016 at 12:02:42 PM UTC-6, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > > > > Really a plugin directory is necessary? That sounds awkward. What about > > > colorschemes, indent or ftplugins and syntax scripts? > > > > > > We could still

Re: Packages

On Friday, February 26, 2016 at 12:02:42 PM UTC-6, Bram Moolenaar wrote: > Christian Brabandt wrote: > > > > Really a plugin directory is necessary? That sounds awkward. What about > > colorschemes, indent or ftplugins and syntax scripts? > > > > We could still change it, right? > > > > > It

Re: Packages

Christian Brabandt wrote: > On Fr, 26 Feb 2016, Bram Moolenaar wrote: > > > > > Matthew Desjardins wrote: > > > > > There have been a couple of people posting about how the new package > > > feature can, in its current state, replace Pathogen. > > > > > >

Re: Packages

On Fr, 26 Feb 2016, Bram Moolenaar wrote: > > Matthew Desjardins wrote: > > > There have been a couple of people posting about how the new package > > feature can, in its current state, replace Pathogen. > > > > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ > >

Re: Packages

Matthew Desjardins wrote: > There have been a couple of people posting about how the new package > feature can, in its current state, replace Pathogen. > > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ > https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ > >

Packages

There have been a couple of people posting about how the new package feature can, in its current state, replace Pathogen. https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ Could someone explain how? It doesn't seem

Re: Search Vam Packages

Excerpts from Sayth Renshaw's message of Sat Dec 08 00:37:56 +0100 2012: Is there a simple way to search VAM repositories to know what is available and what exact format we should write our plugins in. grep docs for this line: I want feature X such as browsable lists of plugins. ActivateAddons

Search Vam Packages

Hi Is there a simple way to search VAM repositories to know what is available and what exact format we should write our plugins in. Other than obviously just searching google for packages. For example writing syntastic fails where Syntastic succeeds. Sayth -- You received this message from

Re: Vim Script that displays site-packages source python

Maybe I am not saying it right. Ill try again. I am looking to be able to get source of a file that is installed in the site-packages directory. Instead of opening the file and finding where it is in the package I want to be able to do :PySource django.views.generic.DetailView and it open

Re: Vim Script that displays site-packages source python

Colin Wood, Tue 2012-02-28 @ 17:44:25-0800: Maybe I am not saying it right. Ill try again. I am looking to be able to get source of a file that is installed in the site-packages directory. Instead of opening the file and finding where it is in the package I want to be able to do :PySource

Re: Vim Script that displays site-packages source python

Taylor Hedberg, Tue 2012-02-28 @ 22:34:47-0500: Colin Wood, Tue 2012-02-28 @ 17:44:25-0800: Maybe I am not saying it right. Ill try again. I am looking to be able to get source of a file that is installed in the site-packages directory. Instead of opening the file and finding where

Re: Vim Script that displays site-packages source python

/', 'g') execute 'view /usr/lib/python2.7/site-packages/' . \ substitute(path, '/\w\+$', '', '') . \ '.py' execute '/\%(class\|def\)' substitute(path, '\v.*/(\w+)$', '\1', '') endfunction command! -nargs=1 PySource call s:PySource('args

Vim Script that displays site-packages source python

Looking for a plugin that will show a site-package or python code for a import. Anyone know of any or got any suggestions I knew about pyref but that just sends me ot the docs and pydoc but Id like to just view the code itself. Thanks, Colin -- You received this message from the vim_use

Re: Ubuntu packages of latest Vim? (to fix bug)

On Monday, 7 November 2011 01:59:44 UTC+1, John Little wrote: In short, Oneiric's gVim ... doesn't show the menu bar at all. Not showing the menu bar is a Unity thing, not vim's fault. Mousing over the bar at the top of the screen (not the vim window) might, depending

Re: Ubuntu packages of latest Vim? (to fix bug)

On Saturday, 5 November 2011 04:03:46 UTC+1, John Little wrote: In short, Oneiric's gVim ... doesn't show the menu bar at all. Not showing the menu bar is a Unity thing, not vim's fault. Mousing over the bar at the top of the screen (not the vim window) might, depending on the

Re: Ubuntu packages of latest Vim? (to fix bug)

In short, Oneiric's gVim ... doesn't show the menu bar at all. Not showing the menu bar is a Unity thing, not vim's fault.  Mousing over the bar at the top of the screen (not the vim window) might, depending on the invocation of gvim, show you vim's menu bar there. In fact this

Re: Ubuntu packages of latest Vim? (to fix bug)

On Fri, Nov 4, 2011 at 7:52 PM, Szabolcs szhor...@gmail.com wrote: The one that comes with Oneiric has bugs that make gVim practically unusable if one has a Chinese input method installed, and I'd rather not have to mess with installing a self-compiled version. That is very tidy, not mess.

Ubuntu packages of latest Vim? (to fix bug)

Does anyone have packages for Ubuntu Oneiric of the latest Vim? The one that comes with Oneiric has bugs that make gVim practically unusable if one has a Chinese input method installed, and I'd rather not have to mess with installing a self-compiled version. https://bugs.launchpad.net/ubuntu

Re: Ubuntu packages of latest Vim? (to fix bug)

Hi, Szabolcs schrieb am 04.11.2011 12:52:47: […], and I'd rather not have to mess with installing a self-compiled version. That’s less hard than you might think! Package it to a *.deb and set a high version number, so it won’t be upgraded unless you want. (or see apt pining) C.M. -- You

Re: Ubuntu packages of latest Vim? (to fix bug)

Does anyone have packages for Ubuntu Oneiric of the latest Vim? Building your own vim from the Mecurial repository is much easier than you might expect. For Ubuntu start with sudo apt-get build-dep vim-gnome then follow Tony's instructions at http://users.skynet.be/antoine.mechelynck/vim

Re: Ubuntu packages of latest Vim? (to fix bug)

On 05/11/11 04:03, John Little wrote: Does anyone have packages for Ubuntu Oneiric of the latest Vim? Building your own vim from the Mecurial repository is much easier than you might expect. For Ubuntu start with sudo apt-get build-dep vim-gnome then follow Tony's instructions

taglist.vim and Perl packages

Hello there! I'm playing around with the taglist plugin and I'm wondering if it is possible to show the perl packages also in the taglist. Either as new fold or in front of each variable and function shown in the taglist window. Thank you for any hints! -- Matthias smime.p7s Description: S

Re: taglist.vim and Perl packages

On Fri, May 29, 2009 at 5:03 AM, Matthias Pitzl m.pi...@gmx.net wrote: Hello there! I'm playing around with the taglist plugin and I'm wondering if it is possible to show the perl packages also in the taglist. Either as new fold or in front of each variable and function shown in the taglist

Updates to private Vim packages for Ubuntu

Hi everyone, I have up-to-date packages of Vim, recompiled from the packages in Debian Sid, for Ubuntu Hardy, Intrepid and Jaunty, in my personal package archive. If you want to use them, you need to edit your /etc/apt/sources.list file, and add this on its own line (if appropriate, replace

Re: Vim 7.2 packages for Ubuntu Intrepid

On 13/02/09 08:43, Raúl Núñez de Arenas Coronado wrote: Saluton J.A.J. :) On Thu, 12 Feb 2009 21:17:07 +0100, J.A.J. Pater dixit: Raúl Núñez de Arenas Coronado schreef: Anyway, I don't think that plugins is a good way of adding power to an editor. If only gedit was programmable in the same

  1   2   >