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

[skeept]

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"

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?

Thank you,
Jorge Rodrigues

[Tony Mechelynck]

On Tue, Aug 15, 2017 at 5:44 AM, skeept <ske...@gmail.com> 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.

[skeept]

On Monday, August 14, 2017 at 11:16:50 PM UTC-5, Tony Mechelynck wrote:

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.

[Tony Mechelynck]

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.

[Bram Moolenaar]

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 -- Br...@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 ///

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

[Bram Moolenaar]

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

[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!