On Fri, Sep 23, 2016 at 4:26 AM, KiYugadgeter <zyouhousikaku@gmail.com> wrote:
> Is vim supporting 24 bit colors?
>
> I want to use vim on windows10 bash.
>
> windows 10 bash is supporting 24bit colors on beta version.
>
> Will vim support 24bit colors?
Vim supports between 2 (2^1) and 16777216 (2^24) colors, depending on
how many _it can tell that_ your terminal supports. This is set by the
termcap variable t_Co or by the equivalent terminfo setting, and these
settings depend in turn on the 'term' setting (q.v.) If $TERM is not
set, and Vim has no way of knowing otherwise, it will set an
OS-dependent 'term' default: for 32- or 64-bit Windows, 'term'
defaults to "win32". To see the number of colours Vim thinks that your
terminal supports, use
:set t_Co?
For me, 256 colors are good enough, and once I set up my vimrc to make
Vim use (as closely as possible) the same colors in a console and in
the GUI, I can't tell the difference by the naked eye. See
http://vim.wikia.com/wiki/Using_GUI_color_settings_in_a_terminal
See also ":help term.txt", especially the first two sections.
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.
For more options, visit https://groups.google.com/d/optout.
Friday, September 23, 2016
Re: surprising behavior with -u: variable defaults not set?
On Fri, Sep 23, 2016 at 09:27:24PM +0200, Dominique Pellé wrote:
>
> That's probably because when using ~/.vimrc file, it implies
> that vim runs with 'nocompatible' mode, whereas when you
> use vim -u ... it runs in 'compatible' mode.
>
> See :help 'compatible' and :help -u
>
> If you add "set compatible" in your ~/.vimrc near the top,
> before moving it, then I'd expect vim -u /tmp/.vimrc to work
> as when using the default ~/.vimrc.
Exactly so. Thanks for clearing that up for me.
Danek
--
--
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.
>
> That's probably because when using ~/.vimrc file, it implies
> that vim runs with 'nocompatible' mode, whereas when you
> use vim -u ... it runs in 'compatible' mode.
>
> See :help 'compatible' and :help -u
>
> If you add "set compatible" in your ~/.vimrc near the top,
> before moving it, then I'd expect vim -u /tmp/.vimrc to work
> as when using the default ~/.vimrc.
Exactly so. Thanks for clearing that up for me.
Danek
--
--
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: surprising behavior with -u: variable defaults not set?
Danek Duvall <duvall@comfychair.org> wrote:
> I copied my .vimrc to a different location, and started vim with -u
> /tmp/.vimrc. I would have expected the same behavior as I get by just
> running vim normally, but I get a few errors:
>
> E528: Must specify a ' value: viminfo+=r/var/tmp/dduvall/mutt-
> E117: Unknown function: pathogen#infect
>
> Neither of which make much sense to me. viminfo is supposed to have a
> default that includes a ' value, and that line works just fine when running
> vim normally. I looked around in :help startup, but didn't see anything
> about -u skipping variable initializations. The first part of section 3
> says that all the rest of section 3 is skipped if -u is used, but a, b, and
> d don't apply to me, and c refers again to .vimrc (which is a little
> confusing). Nowhere does it say anything about internal variable defaults
> as a thing to be skipped or reordered or whatever.
>
> The second one could be similar -- I don't know why autoloaded functions
> wouldn't be found.
>
> I saw this first with 8.0 (trying to track down a weird behavior that's
> reasonably new), but this happens with 7.4, too, so I suspect I'm just
> missing something.
>
> Thanks,
> Danek
Hi
That's probably because when using ~/.vimrc file, it implies
that vim runs with 'nocompatible' mode, whereas when you
use vim -u ... it runs in 'compatible' mode.
See :help 'compatible' and :help -u
If you add "set compatible" in your ~/.vimrc near the top,
before moving it, then I'd expect vim -u /tmp/.vimrc to work
as when using the default ~/.vimrc.
Regards
Dominique
--
--
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.
> I copied my .vimrc to a different location, and started vim with -u
> /tmp/.vimrc. I would have expected the same behavior as I get by just
> running vim normally, but I get a few errors:
>
> E528: Must specify a ' value: viminfo+=r/var/tmp/dduvall/mutt-
> E117: Unknown function: pathogen#infect
>
> Neither of which make much sense to me. viminfo is supposed to have a
> default that includes a ' value, and that line works just fine when running
> vim normally. I looked around in :help startup, but didn't see anything
> about -u skipping variable initializations. The first part of section 3
> says that all the rest of section 3 is skipped if -u is used, but a, b, and
> d don't apply to me, and c refers again to .vimrc (which is a little
> confusing). Nowhere does it say anything about internal variable defaults
> as a thing to be skipped or reordered or whatever.
>
> The second one could be similar -- I don't know why autoloaded functions
> wouldn't be found.
>
> I saw this first with 8.0 (trying to track down a weird behavior that's
> reasonably new), but this happens with 7.4, too, so I suspect I'm just
> missing something.
>
> Thanks,
> Danek
Hi
That's probably because when using ~/.vimrc file, it implies
that vim runs with 'nocompatible' mode, whereas when you
use vim -u ... it runs in 'compatible' mode.
See :help 'compatible' and :help -u
If you add "set compatible" in your ~/.vimrc near the top,
before moving it, then I'd expect vim -u /tmp/.vimrc to work
as when using the default ~/.vimrc.
Regards
Dominique
--
--
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: Is vim supporting 24 bit colors?
Hi,
2016/9/23 Fri 16:04:25 UTC+9 Christian Brabandt wrote:
> Hi KiYugadgeter!
>
> On Do, 22 Sep 2016, KiYugadgeter wrote:
>
> > Is vim supporting 24 bit colors?
>
> Yes, see :h 'termguicolors'
>
> > I want to use vim on windows10 bash.
> >
> > windows 10 bash is supporting 24bit colors on beta version.
>
> Are you sure?
See this:
https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/
Regards,
Ken Takata
--
--
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.
2016/9/23 Fri 16:04:25 UTC+9 Christian Brabandt wrote:
> Hi KiYugadgeter!
>
> On Do, 22 Sep 2016, KiYugadgeter wrote:
>
> > Is vim supporting 24 bit colors?
>
> Yes, see :h 'termguicolors'
>
> > I want to use vim on windows10 bash.
> >
> > windows 10 bash is supporting 24bit colors on beta version.
>
> Are you sure?
See this:
https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/
Regards,
Ken Takata
--
--
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: vimrc cannot be load
Hi ibear,
2016/9/23 Fri 22:46:50 UTC+9 Christian Brabandt wrote:
> Hi ibear!
>
> On Fr, 23 Sep 2016, ibear wrote:
>
> > I build a x64 version of vim from git, copy the new gvim.exe to "d:\vim\vim80"(this folder is renamed from my old vim74), create a vimrc of "d:\vim\vim80\vimrc", run gvim.exe, but vimrc can not be load!
> >
> > But I rename "d:\vim\vim80" to "d:\vim\vim8", run gvim.exe again, now vimrc can be load.
> >
> > Does anybody have meeted the same problem?
>
> In gvim do :version and check the path of 1st-3rd user vimrc. Those
> should be used.
And also try `:echo $VIM` in gvim.
Then, as I wrote in GitHub, read the help (:help $VIM).
Important part is here:
https://github.com/vim/vim/blob/50ba526fbf3e9e5e0e6b0b3086a4d5df581ebc7e/runtime/doc/starting.txt#L1132-L1133
Regards,
Ken Takata
--
--
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.
2016/9/23 Fri 22:46:50 UTC+9 Christian Brabandt wrote:
> Hi ibear!
>
> On Fr, 23 Sep 2016, ibear wrote:
>
> > I build a x64 version of vim from git, copy the new gvim.exe to "d:\vim\vim80"(this folder is renamed from my old vim74), create a vimrc of "d:\vim\vim80\vimrc", run gvim.exe, but vimrc can not be load!
> >
> > But I rename "d:\vim\vim80" to "d:\vim\vim8", run gvim.exe again, now vimrc can be load.
> >
> > Does anybody have meeted the same problem?
>
> In gvim do :version and check the path of 1st-3rd user vimrc. Those
> should be used.
And also try `:echo $VIM` in gvim.
Then, as I wrote in GitHub, read the help (:help $VIM).
Important part is here:
https://github.com/vim/vim/blob/50ba526fbf3e9e5e0e6b0b3086a4d5df581ebc7e/runtime/doc/starting.txt#L1132-L1133
Regards,
Ken Takata
--
--
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.
surprising behavior with -u: variable defaults not set?
I copied my .vimrc to a different location, and started vim with -u
/tmp/.vimrc. I would have expected the same behavior as I get by just
running vim normally, but I get a few errors:
E528: Must specify a ' value: viminfo+=r/var/tmp/dduvall/mutt-
E117: Unknown function: pathogen#infect
Neither of which make much sense to me. viminfo is supposed to have a
default that includes a ' value, and that line works just fine when running
vim normally. I looked around in :help startup, but didn't see anything
about -u skipping variable initializations. The first part of section 3
says that all the rest of section 3 is skipped if -u is used, but a, b, and
d don't apply to me, and c refers again to .vimrc (which is a little
confusing). Nowhere does it say anything about internal variable defaults
as a thing to be skipped or reordered or whatever.
The second one could be similar -- I don't know why autoloaded functions
wouldn't be found.
I saw this first with 8.0 (trying to track down a weird behavior that's
reasonably new), but this happens with 7.4, too, so I suspect I'm just
missing something.
Thanks,
Danek
--
--
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.
/tmp/.vimrc. I would have expected the same behavior as I get by just
running vim normally, but I get a few errors:
E528: Must specify a ' value: viminfo+=r/var/tmp/dduvall/mutt-
E117: Unknown function: pathogen#infect
Neither of which make much sense to me. viminfo is supposed to have a
default that includes a ' value, and that line works just fine when running
vim normally. I looked around in :help startup, but didn't see anything
about -u skipping variable initializations. The first part of section 3
says that all the rest of section 3 is skipped if -u is used, but a, b, and
d don't apply to me, and c refers again to .vimrc (which is a little
confusing). Nowhere does it say anything about internal variable defaults
as a thing to be skipped or reordered or whatever.
The second one could be similar -- I don't know why autoloaded functions
wouldn't be found.
I saw this first with 8.0 (trying to track down a weird behavior that's
reasonably new), but this happens with 7.4, too, so I suspect I'm just
missing something.
Thanks,
Danek
--
--
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: Sandboxing (Was: Searching for a typing game)
Great stuff!
Thanks everyone for your answers and your patience with my beginner
questions.
Best,
Fernando
--
--
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.
Thanks everyone for your answers and your patience with my beginner
questions.
Best,
Fernando
--
--
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.
Subscribe to:
Posts (Atom)