Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[skeept]

> 
> That is a reasonable request.  If the "start" packages were not loaded
> then :packadd can also look there.
> 


When I saw these replies I thought, "well now I have some vacation days, this 
is a good time to try to go and implement this".

But I see Bram already added it himself, so Thank You!

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[Bram Moolenaar]

Alejandro Hernandez wrote:

> Testing plugins in isolation is frequently done. Under the current
> system, all
> plugins one wants to test have to be moved under `opt` to be able to
> use `:packadd`. Relying on `:runtime` is both error-prone and
> cumbersome. There's no need for the user to replicate `:packadd`
> functionality using `:runtime`, because there are things one needs to
> take into account (sourcing all plugin files, adding to runtimepath),
> which would be better done by `:packadd`.
> 
> I propose changing `:packadd` behavior to load ANY plugin, whether
> it's in `opt` or `start`, defaulting to doing nothing if it was added
> already. This idempotent and least-surprise behavior is what I
> expected from `:packadd` before I read the documentation.
> 
> Adding an argument to `:packadd` is also fine, although a bit more
> "surpriseful".

That is a reasonable request.  If the "start" packages were not loaded
then :packadd can also look there.

-- 
hundred-and-one symptoms of being an internet addict:
114. You are counting items, you go "0,1,2,3,4,5,6,7,8,9,A,B,C,D...".

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[Alejandro Hernandez]

Testing plugins in isolation is frequently done. Under the current system, all
plugins one wants to test have to be moved under `opt` to be able to use
`:packadd`. Relying on `:runtime` is both error-prone and cumbersome. There's no
need for the user to replicate `:packadd` functionality using `:runtime`,
because there are things one needs to take into account (sourcing all plugin
files, adding to runtimepath), which would be better done by `:packadd`.

I propose changing `:packadd` behavior to load ANY plugin, whether it's in `opt`
or `start`, defaulting to doing nothing if it was added already. This idempotent
and least-surprise behavior is what I expected from `:packadd` before I read the
documentation.

Adding an argument to `:packadd` is also fine, although a bit more 
"surpriseful".

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[Bram Moolenaar]

skeept wrote:

> On Monday, August 14, 2017 at 11:16:50 PM UTC-5, Tony Mechelynck wrote:
> > On Tue, Aug 15, 2017 at 5:44 AM, skeept wrote:
> > > I have some plugins in the locations:
> > >
> > >
> > > ~/.vim/pack/bundle/start
> > > ~/.vim/pack/bundle/opt
> > >
> > > if I start vim with
> > > vim --noplugins
> > > vim -u NONE
> > >
> > > then I can load plugins from opt but not from start.
> > > So if a plugin say, unimpaired is in
> > >
> > > ~/.vim/pack/bundle/opt
> > >
> > > I can load it with
> > > packadd unimpaired
> > > (and completion works too).
> > > However if it is under start, no completion and if I try to load it 
> > > explicitly I get the error:
> > >
> > > E919: Directory not found in 'packpath': "pack/*/opt/unimpaired"
> > 
> > That is intentional, see :help :packadd
> > >
> > >
> > > Would it be possible to change the behavior to make it load the plugins 
> > > on demand present in start when one of these 2 options are passed?
> > 
> > No need. To load ~/.vim/pack/bundle/start/unimpaired.vim
> > 
> > just do
> > :runtime pack/bundle/start/unimpaired.vim
> > 
> > see :help :runtime
> > 
> > >
> > > Thank you,
> > > Jorge Rodrigues
> > 
> > Best regards,
> > Tony.
> 
> Thanks Tony,
> 
> I understand that this is the implemented behavior but I am trying to argue 
> that in this case the behavior should be changed to allow to add plugins from 
> start when those options are passed from the command line.
> 
> :runtime pack/bundle/start/unimpaired.vim
> 
> in my opinion is not practical, packadd is a lot more practical as you don't 
> need to specify the path, just the package name, and also completion is 
> offered.
> 
> I am not very familiar with vim's code base, although I compile it often for 
> windows and cygwin.
> 
> If in the author/maintainers opinion this behavior would be accepted I will 
> try to submit a patch for this. I would not be able to do it immediately but 
> within a month time.
> 
> Please let me know if there is interest in doing this or not.
> 

For :runtime we have the START argument, which makes it look under
under "start" in 'packpath'.  We could make :packadd START {name} look
in /start/ instead of /opt/.


-- 
We apologise again for the fault in the subtitles.  Those responsible for
sacking the people who have just been sacked have been sacked.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[Tony Mechelynck]

On Tue, Aug 15, 2017 at 6:14 PM, skeept  wrote:
> On Monday, August 14, 2017 at 11:16:50 PM UTC-5, Tony Mechelynck wrote:
>> On Tue, Aug 15, 2017 at 5:44 AM, skeept wrote:
>> > I have some plugins in the locations:
>> >
>> >
>> > ~/.vim/pack/bundle/start
>> > ~/.vim/pack/bundle/opt
>> >
>> > if I start vim with
>> > vim --noplugins
>> > vim -u NONE
>> >
>> > then I can load plugins from opt but not from start.
>> > So if a plugin say, unimpaired is in
>> >
>> > ~/.vim/pack/bundle/opt
>> >
>> > I can load it with
>> > packadd unimpaired
>> > (and completion works too).
>> > However if it is under start, no completion and if I try to load it 
>> > explicitly I get the error:
>> >
>> > E919: Directory not found in 'packpath': "pack/*/opt/unimpaired"
>>
>> That is intentional, see :help :packadd
>> >
>> >
>> > Would it be possible to change the behavior to make it load the plugins on 
>> > demand present in start when one of these 2 options are passed?
>>
>> No need. To load ~/.vim/pack/bundle/start/unimpaired.vim
>>
>> just do
>> :runtime pack/bundle/start/unimpaired.vim
>>
>> see :help :runtime
>>
>> >
>> > Thank you,
>> > Jorge Rodrigues
>>
>> Best regards,
>> Tony.
>
> Thanks Tony,
>
> I understand that this is the implemented behavior but I am trying to argue 
> that in this case the behavior should be changed to allow to add plugins from 
> start when those options are passed from the command line.
>
> :runtime pack/bundle/start/unimpaired.vim
>
> in my opinion is not practical, packadd is a lot more practical as you don't 
> need to specify the path, just the package name, and also completion is 
> offered.
>
> I am not very familiar with vim's code base, although I compile it often for 
> windows and cygwin.
>
> If in the author/maintainers opinion this behavior would be accepted I will 
> try to submit a patch for this. I would not be able to do it immediately but 
> within a month time.
>
> Please let me know if there is interest in doing this or not.
>
> Thank you.

Since my previous reply, I actually checked the help, which you also
ought to have done; and IIUC

:runtime! ALL unimpaired/*.vim

will do exactly what you want, loading all unimpaired/*.vim files
under the 'runtimepath' directories and also under the opt and start
package directories.

Best regards,
Tony.

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[skeept]

On Monday, August 14, 2017 at 11:16:50 PM UTC-5, Tony Mechelynck wrote:
> On Tue, Aug 15, 2017 at 5:44 AM, skeept wrote:
> > I have some plugins in the locations:
> >
> >
> > ~/.vim/pack/bundle/start
> > ~/.vim/pack/bundle/opt
> >
> > if I start vim with
> > vim --noplugins
> > vim -u NONE
> >
> > then I can load plugins from opt but not from start.
> > So if a plugin say, unimpaired is in
> >
> > ~/.vim/pack/bundle/opt
> >
> > I can load it with
> > packadd unimpaired
> > (and completion works too).
> > However if it is under start, no completion and if I try to load it 
> > explicitly I get the error:
> >
> > E919: Directory not found in 'packpath': "pack/*/opt/unimpaired"
> 
> That is intentional, see :help :packadd
> >
> >
> > Would it be possible to change the behavior to make it load the plugins on 
> > demand present in start when one of these 2 options are passed?
> 
> No need. To load ~/.vim/pack/bundle/start/unimpaired.vim
> 
> just do
> :runtime pack/bundle/start/unimpaired.vim
> 
> see :help :runtime
> 
> >
> > Thank you,
> > Jorge Rodrigues
> 
> Best regards,
> Tony.

Thanks Tony,

I understand that this is the implemented behavior but I am trying to argue 
that in this case the behavior should be changed to allow to add plugins from 
start when those options are passed from the command line.

:runtime pack/bundle/start/unimpaired.vim

in my opinion is not practical, packadd is a lot more practical as you don't 
need to specify the path, just the package name, and also completion is offered.

I am not very familiar with vim's code base, although I compile it often for 
windows and cygwin.

If in the author/maintainers opinion this behavior would be accepted I will try 
to submit a patch for this. I would not be able to do it immediately but within 
a month time.

Please let me know if there is interest in doing this or not.

Thank you.
 

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

[Tony Mechelynck]

On Tue, Aug 15, 2017 at 5:44 AM, skeept  wrote:
> I have some plugins in the locations:
>
>
> ~/.vim/pack/bundle/start
> ~/.vim/pack/bundle/opt
>
> if I start vim with
> vim --noplugins
> vim -u NONE
>
> then I can load plugins from opt but not from start.
> So if a plugin say, unimpaired is in
>
> ~/.vim/pack/bundle/opt
>
> I can load it with
> packadd unimpaired
> (and completion works too).
> However if it is under start, no completion and if I try to load it 
> explicitly I get the error:
>
> E919: Directory not found in 'packpath': "pack/*/opt/unimpaired"

That is intentional, see :help :packadd
>
>
> Would it be possible to change the behavior to make it load the plugins on 
> demand present in start when one of these 2 options are passed?

No need. To load ~/.vim/pack/bundle/start/unimpaired.vim

just do
:runtime pack/bundle/start/unimpaired.vim

see :help :runtime

>
> Thank you,
> Jorge Rodrigues

Best regards,
Tony.

-- 
-- 
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 received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.