On 2020-10-02, ping song wrote:
> experts:
> I found in centos 7 there is /usr/bin/vi and /usr/bin/vim, with same version,
> patches.
> but vi is the "small" version and "vim" is the huge one.
> obviously both will use same .vimrc, and when vi is used a lot of errors pop up
> because of the much less features compiled.
> how do I differ these two in my .vimrc file?
Unfortunately, the small version does not include the +eval feature,
which means that you can't use :if/:else/:endif along with has() in
the usual manner to skip features in your vimrc that your vim
doesn't support. However, without the +eval feature, vim will
simply skip over any :if/:endif construct it finds. Therefore, you
can still use :if/:endif to avoid commands and options that the
small version doesn't understand. (You can't use :else here.
Without the +eval feature, vim will also skip over :else blocks.)
For example:
if eval
set some_option_not_in_small_version
endif
See
:help :version
:help :if
Regards,
Gary
--
--
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/20201002170426.GA17599%40phoenix.
Friday, October 2, 2020
Re: vimrc: identify "small" version vs "huge" version
On Friday, October 2, 2020 at 11:34:49 AM UTC-4, ping wrote:
experts:I found in centos 7 there is /usr/bin/vi and /usr/bin/vim, with same version, patches.but vi is the "small" version and "vim" is the huge one.obviously both will use same .vimrc, and when vi is used a lot of errors pop up because of the much less features compiled.how do I differ these two in my .vimrc file?thanks.
Does
show a different result?
--
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/96d6d9c0-0373-43be-871e-24baf4981f99o%40googlegroups.com.
Re: vimrc: identify "small" version vs "huge" version
On Friday, October 2, 2020 at 11:34:49 AM UTC-4, ping wrote:
experts:I found in centos 7 there is /usr/bin/vi and /usr/bin/vim, with same version, patches.but vi is the "small" version and "vim" is the huge one.obviously both will use same .vimrc, and when vi is used a lot of errors pop up because of the much less features compiled.how do I differ these two in my .vimrc file?thanks.
Does:
:echo v:progname
show a different answer between the two?
--
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/41c054cd-7e49-436f-944e-900eb26fb61do%40googlegroups.com.
vimrc: identify "small" version vs "huge" version
experts:
-- I found in centos 7 there is /usr/bin/vi and /usr/bin/vim, with same version, patches.
but vi is the "small" version and "vim" is the huge one.
obviously both will use same .vimrc, and when vi is used a lot of errors pop up because of the much less features compiled.
how do I differ these two in my .vimrc file?
thanks.
--
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/CAHyaFsVi_K3Xf_6pwGXyYHxu1d-PV3ahP_m5Mkt6BOuqjkxXSg%40mail.gmail.com.
Status line error with latest build
Hello,
-- I switched to GVim 8.2.1783 on Windows 10 yesterday. Since then, any changes to the color scheme outside the vimrc cause the status line to have no syntax highlighting for the active window. The other windows look fine until I switch to make one them the active.
To duplicate (must have syntax highlighting on):
1. Have a color scheme command in your vimrc (peachpuff, for example).
2. Have a few windows open and move between them. Everything should look fine.
3. Manually change the color scheme to something else. Actually, even changing it to the same color scheme did it for me.
4. Move around and observe the status line of the current window as you do.
Admittedly, my last build was a few hundred patches ago, but I was wondering if anybody else had seen this, also.
Thank you.
--
Salman
Salman
--
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/CANuxnEcncEV5xPUw5Ndd6rXHvsRp9cwaoopiwf%2BERvL3OO8oiQ%40mail.gmail.com.
Thursday, October 1, 2020
Re: `set t_Co=16` in vimrc file has no effect
Christian wrote:
> On Mi, 30 Sep 2020, Bram Moolenaar wrote:
>
> > > As I recall, VimEnter is too early.
>
> Would a timer work?
>
> > > I often work remotely, with a terminal on my desktop at home or in
> > > an office and the host on which Vim is running many miles away,
> > > often through a relatively slow network. For a while, after either
> > > my xterm changed or Vim changed so that t_Co was reset after
> > > receiving the termresponse, my vim screen would flash at startup
> > > because it would first be drawn using t_Co=16 as set in my vimrc,
> > > then be redrawn a moment later at t_Co=256 when the termresponse was
> > > received.
> >
> > That's why I was thinking of disabling the mechanism, to avoid the
> > flicker. Of course you then need to manually set the value.
>
> Do you mean, if the option is set manually in vimrc, disable the
> termresponse? That would be a good compromise, I think.
Not the termresponse, it is used for several other things, but disabling
the mechanism to fetch the values from xterm, which is what causes t_Co
to change later, at an unpredictable time.
--
Don't Panic!
-- The Hitchhiker's Guide to the Galaxy
/// Bram Moolenaar -- Bram@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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202010011437.091EbrpN1272303%40masaka.moolenaar.net.
> On Mi, 30 Sep 2020, Bram Moolenaar wrote:
>
> > > As I recall, VimEnter is too early.
>
> Would a timer work?
>
> > > I often work remotely, with a terminal on my desktop at home or in
> > > an office and the host on which Vim is running many miles away,
> > > often through a relatively slow network. For a while, after either
> > > my xterm changed or Vim changed so that t_Co was reset after
> > > receiving the termresponse, my vim screen would flash at startup
> > > because it would first be drawn using t_Co=16 as set in my vimrc,
> > > then be redrawn a moment later at t_Co=256 when the termresponse was
> > > received.
> >
> > That's why I was thinking of disabling the mechanism, to avoid the
> > flicker. Of course you then need to manually set the value.
>
> Do you mean, if the option is set manually in vimrc, disable the
> termresponse? That would be a good compromise, I think.
Not the termresponse, it is used for several other things, but disabling
the mechanism to fetch the values from xterm, which is what causes t_Co
to change later, at an unpredictable time.
--
Don't Panic!
-- The Hitchhiker's Guide to the Galaxy
/// Bram Moolenaar -- Bram@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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202010011437.091EbrpN1272303%40masaka.moolenaar.net.
Re: `set t_Co=16` in vimrc file has no effect
On 2020-10-01, Christian Brabandt wrote:
> On Mi, 30 Sep 2020, Bram Moolenaar wrote:
>
> > > As I recall, VimEnter is too early.
>
> Would a timer work?
Perhaps. And it might be better than nothing. But timers carry the
risk that you wait too long on fast systems/connections and not long
enough on slow systems/connections.
> > > I often work remotely, with a terminal on my desktop at home or in
> > > an office and the host on which Vim is running many miles away,
> > > often through a relatively slow network. For a while, after either
> > > my xterm changed or Vim changed so that t_Co was reset after
> > > receiving the termresponse, my vim screen would flash at startup
> > > because it would first be drawn using t_Co=16 as set in my vimrc,
> > > then be redrawn a moment later at t_Co=256 when the termresponse was
> > > received.
> >
> > That's why I was thinking of disabling the mechanism, to avoid the
> > flicker. Of course you then need to manually set the value.
>
> Do you mean, if the option is set manually in vimrc, disable the
> termresponse? That would be a good compromise, I think.
The problem is, in my case, that I use a variety of terminals
running in a variety of operating systems to access vim on a variety
of hosts. Sometimes I run vim locally while at other times I run it
over an ssh connection. TERM is unreliable--almost every terminal
claims it's an xterm. The termresponse has been for me an excellent
means of determining the terminal type. It's just a little slow.
Disabling it would leave me as if back in pre-termresponse days with
terminal-dependent settings that weren't optimum and colors that
were often unreadable.
What I would like to be able to do--although I haven't tried this so
I might not like it after all--is to send t_RV at the start of my
vimrc, wait for the response (with a timeout), let Vim do what it
normally does upon receiving a termresponse, then continue with
the processing of the rest of my vimrc. The termresponse exchange
normally happens in a fraction of a second, before I can type my
first keystroke anyway, and in less time than it takes to start Vim
on Windows, and the delay would prevent the flickering of a second
display refresh.
Regards,
Gary
--
--
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/20201001080636.GD31849%40phoenix.
> On Mi, 30 Sep 2020, Bram Moolenaar wrote:
>
> > > As I recall, VimEnter is too early.
>
> Would a timer work?
Perhaps. And it might be better than nothing. But timers carry the
risk that you wait too long on fast systems/connections and not long
enough on slow systems/connections.
> > > I often work remotely, with a terminal on my desktop at home or in
> > > an office and the host on which Vim is running many miles away,
> > > often through a relatively slow network. For a while, after either
> > > my xterm changed or Vim changed so that t_Co was reset after
> > > receiving the termresponse, my vim screen would flash at startup
> > > because it would first be drawn using t_Co=16 as set in my vimrc,
> > > then be redrawn a moment later at t_Co=256 when the termresponse was
> > > received.
> >
> > That's why I was thinking of disabling the mechanism, to avoid the
> > flicker. Of course you then need to manually set the value.
>
> Do you mean, if the option is set manually in vimrc, disable the
> termresponse? That would be a good compromise, I think.
The problem is, in my case, that I use a variety of terminals
running in a variety of operating systems to access vim on a variety
of hosts. Sometimes I run vim locally while at other times I run it
over an ssh connection. TERM is unreliable--almost every terminal
claims it's an xterm. The termresponse has been for me an excellent
means of determining the terminal type. It's just a little slow.
Disabling it would leave me as if back in pre-termresponse days with
terminal-dependent settings that weren't optimum and colors that
were often unreadable.
What I would like to be able to do--although I haven't tried this so
I might not like it after all--is to send t_RV at the start of my
vimrc, wait for the response (with a timeout), let Vim do what it
normally does upon receiving a termresponse, then continue with
the processing of the rest of my vimrc. The termresponse exchange
normally happens in a fraction of a second, before I can type my
first keystroke anyway, and in less time than it takes to start Vim
on Windows, and the delay would prevent the flickering of a second
display refresh.
Regards,
Gary
--
--
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/20201001080636.GD31849%40phoenix.
Subscribe to:
Posts (Atom)