> On Nov 25, 2023, at 08:20, Lifepillar <lifepillar@lifepillar.me> wrote:
>
> What is the use case for an autoload mechanism when plugins have been
> turned off? Are you talking about `import autoload` statements in
> a vimrc file?
I have a makefile that tests Vim plugins, each test in a dedicated vim --clean. I don't need autoload per se here, I can explicitly source the autoload scripts, but a plugin script would fail if its import fails. So a plugin's import autoload has to work even if the plugin isn't loaded at Vim startup.
>> , when is it a good time to use it?
>
> It's just a matter of personal preference. In most cases the difference
> won't be noticeable. I'd stick with relative paths to avoid potential,
> although probably rare, name conflicts.
Thank you, that helps.
Matan
--
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/14B2DEF4-FAAD-48D3-B104-4BE14C0058C1%40gmail.com.
Saturday, November 25, 2023
Re: Rely on ‘runtimeparh’ in import autoload
On Sat, Nov 25, 2023 at 2:20 PM Lifepillar <lifepillar@lifepillar.me> wrote:
>
> On 2023-11-24, Matan Nassau <matan.nassau@gmail.com> wrote:
> > When is it good practice to use the import autoload form that relies
> > on 'runtimepath'?
> >
> > import autoload 'foo.vim'
> >
> > I think plugins generally know where their autoload stuff is, and can
> > gain a few milliseconds by pointing the import directly at it with
> > a relative path.
> >
> > And, the runtimepath form generally won't work when 'loadplugins'
> > isn't set (when starting Vim with --clean for example).
>
> What is the use case for an autoload mechanism when plugins have been
> turned off? Are you talking about `import autoload` statements in
> a vimrc file?
>
> > So what is the feature for
>
> Vim 9 script inherits the autoload mechanism from Vim legacy script,
> where runtimepath is used. I think that is the main reason for that
> behaviour.
>
> >, when is it a good time to use it?
>
> It's just a matter of personal preference. In most cases the difference
> won't be noticeable. I'd stick with relative paths to avoid potential,
> although probably rare, name conflicts.
>
> Life.
The advantage of using 'runtimepath' (not 'runtimeparh') is that the
sysadmin and the user can to some extent customize the plugin by
adding their own scripts in other directories than those located under
$VIMRUNTIME (which is reserved for scripts distributed together with
Vim). For instance, if a sysadmin loads a set of scripts for all users
of a given system under $VIM/vimfiles/… a user who knows what (s)he's
doing can customize it by means of additional scripts of the same name
and path below (on Unix) $HOME/.vim/after/… or (on Windows but in Vim
notation) $HOME/vimfiles/after/…
Also, if a third-party plugin (installed under $VIM/vimfiles/… or
$HOME/.vim/… etc.) becomes an "official plugin" distributed with Vim
(as happened in the past for matchit, netrw, VimBall, and others), its
scripts will change location and come under $VIMRUNTIME/… By using
'runtimepath' the plugin will continue functioning in exactly the same
way regardless of under which of the 'runtimepath' directories its
scripts are installed.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXtRsRjF7zqp8d5SBkFXMwCbLqoMK2DEAkpREh7xbijHaQ%40mail.gmail.com.
>
> On 2023-11-24, Matan Nassau <matan.nassau@gmail.com> wrote:
> > When is it good practice to use the import autoload form that relies
> > on 'runtimepath'?
> >
> > import autoload 'foo.vim'
> >
> > I think plugins generally know where their autoload stuff is, and can
> > gain a few milliseconds by pointing the import directly at it with
> > a relative path.
> >
> > And, the runtimepath form generally won't work when 'loadplugins'
> > isn't set (when starting Vim with --clean for example).
>
> What is the use case for an autoload mechanism when plugins have been
> turned off? Are you talking about `import autoload` statements in
> a vimrc file?
>
> > So what is the feature for
>
> Vim 9 script inherits the autoload mechanism from Vim legacy script,
> where runtimepath is used. I think that is the main reason for that
> behaviour.
>
> >, when is it a good time to use it?
>
> It's just a matter of personal preference. In most cases the difference
> won't be noticeable. I'd stick with relative paths to avoid potential,
> although probably rare, name conflicts.
>
> Life.
The advantage of using 'runtimepath' (not 'runtimeparh') is that the
sysadmin and the user can to some extent customize the plugin by
adding their own scripts in other directories than those located under
$VIMRUNTIME (which is reserved for scripts distributed together with
Vim). For instance, if a sysadmin loads a set of scripts for all users
of a given system under $VIM/vimfiles/… a user who knows what (s)he's
doing can customize it by means of additional scripts of the same name
and path below (on Unix) $HOME/.vim/after/… or (on Windows but in Vim
notation) $HOME/vimfiles/after/…
Also, if a third-party plugin (installed under $VIM/vimfiles/… or
$HOME/.vim/… etc.) becomes an "official plugin" distributed with Vim
(as happened in the past for matchit, netrw, VimBall, and others), its
scripts will change location and come under $VIMRUNTIME/… By using
'runtimepath' the plugin will continue functioning in exactly the same
way regardless of under which of the 'runtimepath' directories its
scripts are installed.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXtRsRjF7zqp8d5SBkFXMwCbLqoMK2DEAkpREh7xbijHaQ%40mail.gmail.com.
Re: Rely on ‘runtimeparh’ in import autoload
On 2023-11-24, Matan Nassau <matan.nassau@gmail.com> wrote:
> When is it good practice to use the import autoload form that relies
> on 'runtimepath'?
>
> import autoload 'foo.vim'
>
> I think plugins generally know where their autoload stuff is, and can
> gain a few milliseconds by pointing the import directly at it with
> a relative path.
>
> And, the runtimepath form generally won't work when 'loadplugins'
> isn't set (when starting Vim with --clean for example).
What is the use case for an autoload mechanism when plugins have been
turned off? Are you talking about `import autoload` statements in
a vimrc file?
> So what is the feature for
Vim 9 script inherits the autoload mechanism from Vim legacy script,
where runtimepath is used. I think that is the main reason for that
behaviour.
>, when is it a good time to use it?
It's just a matter of personal preference. In most cases the difference
won't be noticeable. I'd stick with relative paths to avoid potential,
although probably rare, name conflicts.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ujssak%24157a%241%40ciao.gmane.io.
> When is it good practice to use the import autoload form that relies
> on 'runtimepath'?
>
> import autoload 'foo.vim'
>
> I think plugins generally know where their autoload stuff is, and can
> gain a few milliseconds by pointing the import directly at it with
> a relative path.
>
> And, the runtimepath form generally won't work when 'loadplugins'
> isn't set (when starting Vim with --clean for example).
What is the use case for an autoload mechanism when plugins have been
turned off? Are you talking about `import autoload` statements in
a vimrc file?
> So what is the feature for
Vim 9 script inherits the autoload mechanism from Vim legacy script,
where runtimepath is used. I think that is the main reason for that
behaviour.
>, when is it a good time to use it?
It's just a matter of personal preference. In most cases the difference
won't be noticeable. I'd stick with relative paths to avoid potential,
although probably rare, name conflicts.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ujssak%24157a%241%40ciao.gmane.io.
Thursday, November 23, 2023
Rely on ‘runtimeparh’ in import autoload
Hello.
When is it good practice to use the import autoload form that relies on 'runtimepath'?
import autoload 'foo.vim'
I think plugins generally know where their autoload stuff is, and can gain a few milliseconds by pointing the import directly at it with a relative path.
And, the runtimepath form generally won't work when 'loadplugins' isn't set (when starting Vim with --clean for example).
So what is the feature for, when is it a good time to use it?
Matan
--
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/FF19CA0E-D69B-4BFB-B37A-5CB50A43421E%40gmail.com.
When is it good practice to use the import autoload form that relies on 'runtimepath'?
import autoload 'foo.vim'
I think plugins generally know where their autoload stuff is, and can gain a few milliseconds by pointing the import directly at it with a relative path.
And, the runtimepath form generally won't work when 'loadplugins' isn't set (when starting Vim with --clean for example).
So what is the feature for, when is it a good time to use it?
Matan
--
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/FF19CA0E-D69B-4BFB-B37A-5CB50A43421E%40gmail.com.
Wednesday, November 22, 2023
Re: How do you set options in the _vimrc file?
On 2023-11-22 19:53, Christian Castro wrote:
> Weird thing, Windows doesn???t show that it's write protected
> and there is no Windows service for VIM nor is there a VIM
> program running as per Task Manager, so I have no idea why
> Windows is saying it's not editable, unless VIM has done
> something fancy in the registry somehow.
>
> Any advice on how to unlock the _vimrc file in C:\Program Files (x86)\Vim\ ?
That sounds like a suspect location, as a system-install location.
Usually it should be something like
C:\Users\ccastro\_vimrc
-tim
--
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZV5mAYfhWQGkPBcR%40thechases.com.
> Weird thing, Windows doesn???t show that it's write protected
> and there is no Windows service for VIM nor is there a VIM
> program running as per Task Manager, so I have no idea why
> Windows is saying it's not editable, unless VIM has done
> something fancy in the registry somehow.
>
> Any advice on how to unlock the _vimrc file in C:\Program Files (x86)\Vim\ ?
That sounds like a suspect location, as a system-install location.
Usually it should be something like
C:\Users\ccastro\_vimrc
-tim
--
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZV5mAYfhWQGkPBcR%40thechases.com.
RE: How do you set options in the _vimrc file?
Silly question but when I try to edit the file it comes back that it's not editable.
Weird thing, Windows doesn't show that it's write protected and there is no Windows service for VIM nor is there a VIM program running as per Task Manager, so I have no idea why Windows is saying it's not editable, unless VIM has done something fancy in the registry somehow.
Any advice on how to unlock the _vimrc file in C:\Program Files (x86)\Vim\ ?
Thanks
-----Original Message-----
From: vim_use@googlegroups.com <vim_use@googlegroups.com> On Behalf Of Tony Mechelynck
Sent: Monday, November 20, 2023 8:21 PM
To: vim_use@googlegroups.com
Subject: Re: How do you set options in the _vimrc file?
On Tue, Nov 21, 2023 at 2:03 AM Tim Chase <vim@tim.thechases.com> wrote:
>
> On 2023-11-21 00:37, Christian Castro wrote:
> > How do you change the options in the _vimrc file?
>
> It's just a text-file, so you can put in the settings you want.
> So you can just put these commands in that file:
>
> set nohlo
> set ts=4
> set sw=4
>
> > Please let me know if the _vimrc file is editable from gVim or am I
> > going about this the wrong way (and what the right way is).
>
> So yes, you should be able to edit it like any other file. It even
> comes with a handy built-in variable, so within vim you can
>
> :e $MYVIMRC
>
> and it will open the appropriate file.
>
> Alternatively, you can use the
>
> :mkvimrc
>
> command to take whatever your current settings are and write them to
> your vimrc file.
>
> -tim
>
> :help $MYVIMRC
> :help :mkvimrc
IIUC, :mkvimrc can create a vimrc but not modify an existing one.
The vimrc (i.e. the .vimrc or _vimrc) is a plain text file: it is made to be editable, typically with Vim. I recommend to start with a vimrc containing
:runtime vimrc_example.vim
and then add below that (or rarely above it) whatever suits your fancy to add settings not set by the vimrc_example.vim (and the defauts.vim which it sources) or to override those they do set.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsYEEzPgLQjeLh%2BtWzZBVd1zLku4x2t0m0KqzG46Ov%2BLA%40mail.gmail.com.
****WARNING**** This email message (including any attachments) are to be treated as confidential/proprietary and may contain copyrighted or other legally protected information. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this information in error, please destroy the information and notify the sender of the error. 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/MN2PR13MB3326366B037350BFCDB63F679CBAA%40MN2PR13MB3326.namprd13.prod.outlook.com.
Weird thing, Windows doesn't show that it's write protected and there is no Windows service for VIM nor is there a VIM program running as per Task Manager, so I have no idea why Windows is saying it's not editable, unless VIM has done something fancy in the registry somehow.
Any advice on how to unlock the _vimrc file in C:\Program Files (x86)\Vim\ ?
Thanks
-----Original Message-----
From: vim_use@googlegroups.com <vim_use@googlegroups.com> On Behalf Of Tony Mechelynck
Sent: Monday, November 20, 2023 8:21 PM
To: vim_use@googlegroups.com
Subject: Re: How do you set options in the _vimrc file?
On Tue, Nov 21, 2023 at 2:03 AM Tim Chase <vim@tim.thechases.com> wrote:
>
> On 2023-11-21 00:37, Christian Castro wrote:
> > How do you change the options in the _vimrc file?
>
> It's just a text-file, so you can put in the settings you want.
> So you can just put these commands in that file:
>
> set nohlo
> set ts=4
> set sw=4
>
> > Please let me know if the _vimrc file is editable from gVim or am I
> > going about this the wrong way (and what the right way is).
>
> So yes, you should be able to edit it like any other file. It even
> comes with a handy built-in variable, so within vim you can
>
> :e $MYVIMRC
>
> and it will open the appropriate file.
>
> Alternatively, you can use the
>
> :mkvimrc
>
> command to take whatever your current settings are and write them to
> your vimrc file.
>
> -tim
>
> :help $MYVIMRC
> :help :mkvimrc
IIUC, :mkvimrc can create a vimrc but not modify an existing one.
The vimrc (i.e. the .vimrc or _vimrc) is a plain text file: it is made to be editable, typically with Vim. I recommend to start with a vimrc containing
:runtime vimrc_example.vim
and then add below that (or rarely above it) whatever suits your fancy to add settings not set by the vimrc_example.vim (and the defauts.vim which it sources) or to override those they do set.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsYEEzPgLQjeLh%2BtWzZBVd1zLku4x2t0m0KqzG46Ov%2BLA%40mail.gmail.com.
****WARNING**** This email message (including any attachments) are to be treated as confidential/proprietary and may contain copyrighted or other legally protected information. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this information in error, please destroy the information and notify the sender of the error. 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/MN2PR13MB3326366B037350BFCDB63F679CBAA%40MN2PR13MB3326.namprd13.prod.outlook.com.
Re: Can virtual text overwrite existing text?
On Wed, Nov 22, 2023 at 7:29 PM Girish <girishji@gmail.com> wrote:
>
> When I add 1 letter of virtual text through prop_add() it shifts the remaining text on the line by one character. Is it possible to make it overwrite existing text so there is no shifting of characters?
> Thank you
> girish
>
This is documented at ":help virtual-text". Depending on how you call
prop_add() your virtual text, which IIUC can be more than one
character long, pushes whatever is after it either horizontally or
vertically. If you want no shifting of characters it is possible to
display the virtual text "in column zero" and in that case "it will be
displayed above, below or after the actual text" depending on the
"text_align" and "text_wrap" arguments. Since the virtual text is not
editable it is not possible to place the cursor on it.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXv_Tvs2-Cu8RXMVd9NxPphPRhd6ucr-F814gaCR67Au0g%40mail.gmail.com.
>
> When I add 1 letter of virtual text through prop_add() it shifts the remaining text on the line by one character. Is it possible to make it overwrite existing text so there is no shifting of characters?
> Thank you
> girish
>
This is documented at ":help virtual-text". Depending on how you call
prop_add() your virtual text, which IIUC can be more than one
character long, pushes whatever is after it either horizontally or
vertically. If you want no shifting of characters it is possible to
display the virtual text "in column zero" and in that case "it will be
displayed above, below or after the actual text" depending on the
"text_align" and "text_wrap" arguments. Since the virtual text is not
editable it is not possible to place the cursor on it.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXv_Tvs2-Cu8RXMVd9NxPphPRhd6ucr-F814gaCR67Au0g%40mail.gmail.com.
Subscribe to:
Posts (Atom)