Advice on opening large/huge files

From time to time, I need to edit large files (~10^2-10^3 MB).
In my tests, Vim loads large files relatively quickly (~100MB/s).
It's (some) filetype plugins that hog Vim.

For instance, take any large file and change its suffix to have
it recognized as Markdown. After Vim has read it (you'll see
the line/char count in the command line), it gets stuck.

I have tried the LargeFile plugin, but I haven't noticed any
difference.

Any suggestions?

Thanks,
Life.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: standard way include plugin as a dependency of another plugin

I've made a small (pathname) error in my answer, see the correction below.

----- Mail original -----
> De: "Luc Hermitte" <hermitte@free.fr>
> À: "vim use" <vim_use@googlegroups.com>
> Envoyé: Mardi 1 Août 2017 13:33:17
> Objet: Re: standard way include plugin as a dependency of another plugin
>
> Hi,
>
> (Sorry, it seems I've deleted the original message, and I'm not
> answering to the mail I should be answering to).
>
> > On 30/07/2017 04:40, sashang@gmail.com wrote:
> > > I'm writing a plugin and want it to depend on another plugin
> > > installed. At the moment I just have a line
> > >
> > > source <path to plugin>
> > >
> > > in my plugin that pulls in that plugin. Is there a standard way
> > > of
> > > doing this or do plugin authors just invent their own way? Could
> > > I
> > > use Vundle here instead?
>
>
> There is no standard way of proceeding. Also there are two sides to
> the question:
> 1- making sure what we depend upon is installed;
> 2- making sure what we depend upon is defined.
>
> Beside the actual answer will depend on what you are actually
> depending upon.
>
> 1- Regarding availability
> a- Most people simply document the dependency(/ies), and it's up to
> the end-users to make sure every dependency is properly installed.
> In all cases, I consider that **documenting is mandatory**.
>
>
> b- Some will use git submodules to make this as simple as possible.
> The only, and main disadvantage, as Lifepillar said, is that a plugin
> may be installed several times. An incorrectly written plugin may
> even duplicate events. We could also experience very tricky bugs
> when several versions of a same plugin are installed.
>
> IMO, this is not a good solution.
>
>
> c- A few of us are specifying the dependencies for the only two
> plugin managers that support dependencies. I even go further and
> advocate their use. Unfortunately, the popular plugin managers are
> the simple ones, which don't understand dependencies so far.
>
> The only two plugin managers that support dependencies (and that I'm
> aware of at this moment) are:
> - VAM: https://github.com/MarcWeber/vim-addon-manager (through
> vim-py)
> - VimFlavor: https://github.com/kana/vim-flavor
>
> Even if you're not using them, nor expect to ever use them, I highly
> recommend that you specify the dependencies of your plugin for these
> two plugin managers. IOW, you'll have to define an addon-info.json
> file and a VimFlavor file -- unfortunately they don't share a common
> syntax. :(
>
> You'll find plenty examples in my plugins. See for instance:
> https://github.com/LucHermitte/lh-brackets
>
>
> d- Vim 8 packages don't solve anything. We can still have multiple
> versions of a same plugin installed (which is clumsy and bad), and
> they are not able to automatically install the dependencies.
>
> If there was a notion of "environment" like we have in Python or
> conda, or of "sandbox" like with Haskell or nix, then may be we
> could have multiple packages that contain different versions of a
> same plugin. So far and AFAIK, this is not the case. Hence my
> current stance.
>
>
>
> 2- Regarding "sourcing"
>
> a- Before Vim7, we had to source plugins where global functions,
> mappings, abbreviations, command, etc. were defined.
>
> A simple way was to check for something we need, and if it isn't
> detected as defined, then we explicitly source the dependency.
>
> if ! exists('*SomeGlobalFunction')
> runtime plugin/MyDependencyThatDefineSomeGlobalFunction.vim
> if ! exists('*SomeGlobalFunction')
> echoerr "WARNING: MyDependencyThatDefineSomeGlobalFunction
> isn't installed. MyFooBar plugin is disabled. Please see xxxx"
> endif
> endif
>
> Or if you don't care about sourcing something that may have already
> been sourced, you could simply type:
>
> runtime plugin/MyDependencyThatDefineSomeGlobalFunction.vim
> if ! exists('*SomeGlobalFunction')
> echoerr "WARNING: MyDependencyThatDefineSomeGlobalFunction isn't
> installed. MyFooBar plugin is disabled. Please see xxxx"
> endif
>
> You could also check the plugin version in case it stores its version
> number in its `g:loaded_MyDependencyThatDefineSomeGlobalFunction`
> header-gate variable. This has been described in another answer.
>
>
> (In case of definitions done in filetype plugins, what we had to do
> was a little bit trickier)
>
>
> b- Now, we are past Vim 7. Vim 7 has introduced autoload plugins and
> their autoloaded functions.
> Modern plugins will use autoload plugin files to store their
> functions. Most of the time this is just to speedup the starting
> time. Sometimes, this is because some of us are aware this is the
> best way to define libraries.
>
> This time instead of checking whether a particular symbol is defined
> in order to source on the fly, we simply call the autoloaded
> functions. Given their name, foo#bar#func(), Vim will know that if
> the function doesn't exist then it must execute
> `:runtime foo/bar.vim`.

(EDIT: this is what is executed by Vim)
`:runtime autoload/foo/bar.vim`

> If the function still doesn't exist, Vim will issue an
> error message.
> Sometimes, you'll see a few issues from the users, of your plugin,
> that have skipped the installation procedure you have described in
> your plugin documentation.
>
>
> Of course if you're not trying to execute a function defined in an
> autoload plugin file, you're back to square 2.a-.
>
> Regards,
> --
> Luc Hermitte
>
> --
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: map in diffexpr

On Di, 01 Aug 2017, Ben Fritz wrote:

> On Sunday, July 23, 2017 at 11:57:24 PM UTC-5, akria wrote:
> > Hi,
> > I use my diffexpr to do diff, and map different hotkey in different window.
> > In vim74, it could work correctly.
> > But in vim80, my diffexpr will fail to move to other windows, so the following map fail too.
> >
> > How should I do this job in vim80?
> >
> > Thanks.
>
> Perhaps add an "OptionSet" autocmd on the 'diff' option. Not sure whether it will work.

The OptionSet on the 'diff' option only triggers since a couple of
patches. And even then, it is not allowed to switch buffers/windows.


Best,
Christian
--
Willst du den Wert des Geldes kennenlernen, geh und versuche dir
welches zu borgen.
-- Benjamin Franklin

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: map in diffexpr

On Sunday, July 23, 2017 at 11:57:24 PM UTC-5, akria wrote:
> Hi,
> I use my diffexpr to do diff, and map different hotkey in different window.
> In vim74, it could work correctly.
> But in vim80, my diffexpr will fail to move to other windows, so the following map fail too.
>
> How should I do this job in vim80?
>
> Thanks.

Perhaps add an "OptionSet" autocmd on the 'diff' option. Not sure whether it will work.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Which file control the action of indent?

On Saturday, July 22, 2017 at 8:54:36 PM UTC-5, Shawn H Corey wrote:
> On Sat, 22 Jul 2017 18:09:32 -0700 (PDT)
> Length Power <elearn2014@gmail.com> wrote:
>
> > Which file will be changed when to customize indent action?
>
> Add a file `~/.vim/after/ftplugin/python.vim` and make your changes
> there.The `after/` directory means it will be run after the regular
> `python.vim` And this will protect your changes from any updates to the
> regular file.
>
>

Wouldn't you want it in an "indent" directory instead of an "ftplugin" directory?

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: standard way include plugin as a dependency of another plugin

Hi,

(Sorry, it seems I've deleted the original message, and I'm not answering to the mail I should be answering to).

> On 30/07/2017 04:40, sashang@gmail.com wrote:
> > I'm writing a plugin and want it to depend on another plugin
> > installed. At the moment I just have a line
> >
> > source <path to plugin>
> >
> > in my plugin that pulls in that plugin. Is there a standard way of
> > doing this or do plugin authors just invent their own way? Could I
> > use Vundle here instead?


There is no standard way of proceeding. Also there are two sides to the question:
1- making sure what we depend upon is installed;
2- making sure what we depend upon is defined.

Beside the actual answer will depend on what you are actually depending upon.

1- Regarding availability
a- Most people simply document the dependency(/ies), and it's up to the end-users to make sure every dependency is properly installed.
In all cases, I consider that **documenting is mandatory**.


b- Some will use git submodules to make this as simple as possible.
The only, and main disadvantage, as Lifepillar said, is that a plugin may be installed several times. An incorrectly written plugin may even duplicate events. We could also experience very tricky bugs when several versions of a same plugin are installed.

IMO, this is not a good solution.


c- A few of us are specifying the dependencies for the only two plugin managers that support dependencies. I even go further and advocate their use. Unfortunately, the popular plugin managers are the simple ones, which don't understand dependencies so far.

The only two plugin managers that support dependencies (and that I'm aware of at this moment) are:
- VAM: https://github.com/MarcWeber/vim-addon-manager (through vim-py)
- VimFlavor: https://github.com/kana/vim-flavor

Even if you're not using them, nor expect to ever use them, I highly recommend that you specify the dependencies of your plugin for these two plugin managers. IOW, you'll have to define an addon-info.json file and a VimFlavor file -- unfortunately they don't share a common syntax. :(

You'll find plenty examples in my plugins. See for instance: https://github.com/LucHermitte/lh-brackets


d- Vim 8 packages don't solve anything. We can still have multiple versions of a same plugin installed (which is clumsy and bad), and they are not able to automatically install the dependencies.

If there was a notion of "environment" like we have in Python or conda, or of "sandbox" like with Haskell or nix, then may be we could have multiple packages that contain different versions of a same plugin. So far and AFAIK, this is not the case. Hence my current stance.



2- Regarding "sourcing"

a- Before Vim7, we had to source plugins where global functions, mappings, abbreviations, command, etc. were defined.

A simple way was to check for something we need, and if it isn't detected as defined, then we explicitly source the dependency.

if ! exists('*SomeGlobalFunction')
runtime plugin/MyDependencyThatDefineSomeGlobalFunction.vim
if ! exists('*SomeGlobalFunction')
echoerr "WARNING: MyDependencyThatDefineSomeGlobalFunction isn't installed. MyFooBar plugin is disabled. Please see xxxx"
endif
endif

Or if you don't care about sourcing something that may have already been sourced, you could simply type:

runtime plugin/MyDependencyThatDefineSomeGlobalFunction.vim
if ! exists('*SomeGlobalFunction')
echoerr "WARNING: MyDependencyThatDefineSomeGlobalFunction isn't installed. MyFooBar plugin is disabled. Please see xxxx"
endif

You could also check the plugin version in case it stores its version number in its `g:loaded_MyDependencyThatDefineSomeGlobalFunction` header-gate variable. This has been described in another answer.


(In case of definitions done in filetype plugins, what we had to do was a little bit trickier)


b- Now, we are past Vim 7. Vim 7 has introduced autoload plugins and their autoloaded functions.
Modern plugins will use autoload plugin files to store their functions. Most of the time this is just to speedup the starting time. Sometimes, this is because some of us are aware this is the best way to define libraries.

This time instead of checking whether a particular symbol is defined in order to source on the fly, we simply call the autoloaded functions. Given their name, foo#bar#func(), Vim will know that if the function doesn't exist then it must execute `:runtime foo/bar.vim`. If the function still doesn't exist, Vim will issue an error message.
Sometimes, you'll see a few issues from the users, of your plugin, that have skipped the installation procedure you have described in your plugin documentation.


Of course if you're not trying to execute a function defined in an autoload plugin file, you're back to square 2.a-.

Regards,
--
Luc Hermitte

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: standard way include plugin as a dependency of another plugin

> I'm writing a plugin and want it to depend on another plugin installed. At the moment I just have a line
>
> source <path to plugin>

I sometimes use something like this:

if !exists('g:loaded_DEPENDENCY') || g:loaded_DEPENDENCY < 100
runtime plugin/DEPENDENCY.vim
if !exists('g:loaded_DEPENDENCY') || g:loaded_DEPENDENCY < 100
echoerr 'DEPENDENCY >= 1.00 is required'
finish
endif
endif

This makes sure plugin/DEPENDENCY.vim is loaded. The file has to be in the runtimepath. This solution is suboptimal if g:loaded_DEPENDENCY < 100 though.

Regards

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.