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.
Mit freundlichen Grüßen
Christian
--
Man kann alle Leute einige Zeit zum Narren halten und einige Leute allezeit,
aber alle Leute allezeit zum Narren halten kann man nicht.
-- Abraham Lincoln
--
--
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/20201001064824.GE1002%40256bit.org.
Wednesday, September 30, 2020
Re: `set t_Co=16` in vimrc file has no effect
Gary Johnson wrote:
> On 2020-09-30, Christian Brabandt wrote:
> > On Di, 29 Sep 2020, Gary Johnson wrote:
> >
> > > I'm too busy at the moment to give this a very thoughtful response,
> > > and it was a while ago that I looked at that code, but it seems that
> > > there were several things done in response to receiving the
> > > termresponse, so I don't know that one option would serve all needs.
> > > In the present case, the only problem seems to be the setting of
> > > t_Co.
> > >
> > > The problem I've had is that I want to set various options and
> > > highlights depending on the terminal type, but the type is not
> > > accurately known when vimrc is read, and when the TermResponse event
> > > is triggered, not everything can be set correctly.
> > >
> > > I've resorted to having the termresponse queried in my ~/.bashrc,
> > > which sets an environment variable that vimrc can then read. It
> > > works very well for making terminal-dependent settings in my vimrc
> > > and colorscheme files. When vim queries and receives the
> > > termresponse itself, it then makes the additional settings you
> > > mentioned. It would be nice, though, if this could all be done
> > > within Vim.
> > >
> > > I think maybe the whole termresponse behavior should be thought
> > > through and made more useful, perhaps by adding a later
> > > TermResponse-like event. I'll try to find some time.
> >
> > I think this was suggested before. Also the todo file contains a couple
> > of statements regarding termresponse, e.g.
> >
> > ,----
> > | Add another autocommand like TermResponse that is fired for the other terminal
> > | responses, such as bg and fg. Use "bg", "fg", "blink", etc. for the name.
> > `----
> >
> > I think Bram also suggested to add additional TermResponse<Event> for
> > the various term events before.
> >
> > BTW: Why wouldn't the VimEnter autocommand work? Is that, because
> > changing terminal options would then require some more initialization or
> > is that triggered too early?
>
> Thanks for the pointers.
>
> I had been thinking of having a single TermResponsePost event, but
> having multiple events might be better, especially if each of the
> other responses is sent separately.
>
> As I recall, VimEnter is too early.
Talking back and forth with xterm can take some time. I have thought of
another mechanism that would exchange a hash code of all the codes. If
Vim recognizes it (cashed response) it's done quickly. If not then Vim
would request the termcap/terminfo settings from the terminal. This way
you have a delay only once and accurate codes all the time. But no work
has been done for it, and it would require talking to xterm clones and
other program authors to get it widely accepted.
> 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.
> I am currently working from home and all my Vim sessions are local
> or within my home network, so I don't have the delay problem. I'll
> have to determine which of the VimEnter and TermResponse events
> occurs first, but a general solution should assume that TermResponse
> occurs later.
It's possible, but the flicker would still happen.
--
Q: What is the difference between open-source and commercial software?
A: If you have a problem with commercial software you can call a phone
number and they will tell you it might be solved in a future version.
For open-source software there isn't a phone number to call, but you
get the solution within a day.
/// 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/202009302050.08UKo8341065768%40masaka.moolenaar.net.
> On 2020-09-30, Christian Brabandt wrote:
> > On Di, 29 Sep 2020, Gary Johnson wrote:
> >
> > > I'm too busy at the moment to give this a very thoughtful response,
> > > and it was a while ago that I looked at that code, but it seems that
> > > there were several things done in response to receiving the
> > > termresponse, so I don't know that one option would serve all needs.
> > > In the present case, the only problem seems to be the setting of
> > > t_Co.
> > >
> > > The problem I've had is that I want to set various options and
> > > highlights depending on the terminal type, but the type is not
> > > accurately known when vimrc is read, and when the TermResponse event
> > > is triggered, not everything can be set correctly.
> > >
> > > I've resorted to having the termresponse queried in my ~/.bashrc,
> > > which sets an environment variable that vimrc can then read. It
> > > works very well for making terminal-dependent settings in my vimrc
> > > and colorscheme files. When vim queries and receives the
> > > termresponse itself, it then makes the additional settings you
> > > mentioned. It would be nice, though, if this could all be done
> > > within Vim.
> > >
> > > I think maybe the whole termresponse behavior should be thought
> > > through and made more useful, perhaps by adding a later
> > > TermResponse-like event. I'll try to find some time.
> >
> > I think this was suggested before. Also the todo file contains a couple
> > of statements regarding termresponse, e.g.
> >
> > ,----
> > | Add another autocommand like TermResponse that is fired for the other terminal
> > | responses, such as bg and fg. Use "bg", "fg", "blink", etc. for the name.
> > `----
> >
> > I think Bram also suggested to add additional TermResponse<Event> for
> > the various term events before.
> >
> > BTW: Why wouldn't the VimEnter autocommand work? Is that, because
> > changing terminal options would then require some more initialization or
> > is that triggered too early?
>
> Thanks for the pointers.
>
> I had been thinking of having a single TermResponsePost event, but
> having multiple events might be better, especially if each of the
> other responses is sent separately.
>
> As I recall, VimEnter is too early.
Talking back and forth with xterm can take some time. I have thought of
another mechanism that would exchange a hash code of all the codes. If
Vim recognizes it (cashed response) it's done quickly. If not then Vim
would request the termcap/terminfo settings from the terminal. This way
you have a delay only once and accurate codes all the time. But no work
has been done for it, and it would require talking to xterm clones and
other program authors to get it widely accepted.
> 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.
> I am currently working from home and all my Vim sessions are local
> or within my home network, so I don't have the delay problem. I'll
> have to determine which of the VimEnter and TermResponse events
> occurs first, but a general solution should assume that TermResponse
> occurs later.
It's possible, but the flicker would still happen.
--
Q: What is the difference between open-source and commercial software?
A: If you have a problem with commercial software you can call a phone
number and they will tell you it might be solved in a future version.
For open-source software there isn't a phone number to call, but you
get the solution within a day.
/// 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/202009302050.08UKo8341065768%40masaka.moolenaar.net.
Re: `set t_Co=16` in vimrc file has no effect
On 2020-09-30, Christian Brabandt wrote:
> On Di, 29 Sep 2020, Gary Johnson wrote:
>
> > I'm too busy at the moment to give this a very thoughtful response,
> > and it was a while ago that I looked at that code, but it seems that
> > there were several things done in response to receiving the
> > termresponse, so I don't know that one option would serve all needs.
> > In the present case, the only problem seems to be the setting of
> > t_Co.
> >
> > The problem I've had is that I want to set various options and
> > highlights depending on the terminal type, but the type is not
> > accurately known when vimrc is read, and when the TermResponse event
> > is triggered, not everything can be set correctly.
> >
> > I've resorted to having the termresponse queried in my ~/.bashrc,
> > which sets an environment variable that vimrc can then read. It
> > works very well for making terminal-dependent settings in my vimrc
> > and colorscheme files. When vim queries and receives the
> > termresponse itself, it then makes the additional settings you
> > mentioned. It would be nice, though, if this could all be done
> > within Vim.
> >
> > I think maybe the whole termresponse behavior should be thought
> > through and made more useful, perhaps by adding a later
> > TermResponse-like event. I'll try to find some time.
>
> I think this was suggested before. Also the todo file contains a couple
> of statements regarding termresponse, e.g.
>
> ,----
> | Add another autocommand like TermResponse that is fired for the other terminal
> | responses, such as bg and fg. Use "bg", "fg", "blink", etc. for the name.
> `----
>
> I think Bram also suggested to add additional TermResponse<Event> for
> the various term events before.
>
> BTW: Why wouldn't the VimEnter autocommand work? Is that, because
> changing terminal options would then require some more initialization or
> is that triggered too early?
Thanks for the pointers.
I had been thinking of having a single TermResponsePost event, but
having multiple events might be better, especially if each of the
other responses is sent separately.
As I recall, VimEnter is too early.
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.
I am currently working from home and all my Vim sessions are local
or within my home network, so I don't have the delay problem. I'll
have to determine which of the VimEnter and TermResponse events
occurs first, but a general solution should assume that TermResponse
occurs later.
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/20200930172356.GC31849%40phoenix.
> On Di, 29 Sep 2020, Gary Johnson wrote:
>
> > I'm too busy at the moment to give this a very thoughtful response,
> > and it was a while ago that I looked at that code, but it seems that
> > there were several things done in response to receiving the
> > termresponse, so I don't know that one option would serve all needs.
> > In the present case, the only problem seems to be the setting of
> > t_Co.
> >
> > The problem I've had is that I want to set various options and
> > highlights depending on the terminal type, but the type is not
> > accurately known when vimrc is read, and when the TermResponse event
> > is triggered, not everything can be set correctly.
> >
> > I've resorted to having the termresponse queried in my ~/.bashrc,
> > which sets an environment variable that vimrc can then read. It
> > works very well for making terminal-dependent settings in my vimrc
> > and colorscheme files. When vim queries and receives the
> > termresponse itself, it then makes the additional settings you
> > mentioned. It would be nice, though, if this could all be done
> > within Vim.
> >
> > I think maybe the whole termresponse behavior should be thought
> > through and made more useful, perhaps by adding a later
> > TermResponse-like event. I'll try to find some time.
>
> I think this was suggested before. Also the todo file contains a couple
> of statements regarding termresponse, e.g.
>
> ,----
> | Add another autocommand like TermResponse that is fired for the other terminal
> | responses, such as bg and fg. Use "bg", "fg", "blink", etc. for the name.
> `----
>
> I think Bram also suggested to add additional TermResponse<Event> for
> the various term events before.
>
> BTW: Why wouldn't the VimEnter autocommand work? Is that, because
> changing terminal options would then require some more initialization or
> is that triggered too early?
Thanks for the pointers.
I had been thinking of having a single TermResponsePost event, but
having multiple events might be better, especially if each of the
other responses is sent separately.
As I recall, VimEnter is too early.
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.
I am currently working from home and all my Vim sessions are local
or within my home network, so I don't have the delay problem. I'll
have to determine which of the VimEnter and TermResponse events
occurs first, but a general solution should assume that TermResponse
occurs later.
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/20200930172356.GC31849%40phoenix.
Re: `set t_Co=16` in vimrc file has no effect
On Di, 29 Sep 2020, Gary Johnson wrote:
> I'm too busy at the moment to give this a very thoughtful response,
> and it was a while ago that I looked at that code, but it seems that
> there were several things done in response to receiving the
> termresponse, so I don't know that one option would serve all needs.
> In the present case, the only problem seems to be the setting of
> t_Co.
>
> The problem I've had is that I want to set various options and
> highlights depending on the terminal type, but the type is not
> accurately known when vimrc is read, and when the TermResponse event
> is triggered, not everything can be set correctly.
>
> I've resorted to having the termresponse queried in my ~/.bashrc,
> which sets an environment variable that vimrc can then read. It
> works very well for making terminal-dependent settings in my vimrc
> and colorscheme files. When vim queries and receives the
> termresponse itself, it then makes the additional settings you
> mentioned. It would be nice, though, if this could all be done
> within Vim.
>
> I think maybe the whole termresponse behavior should be thought
> through and made more useful, perhaps by adding a later
> TermResponse-like event. I'll try to find some time.
I think this was suggested before. Also the todo file contains a couple
of statements regarding termresponse, e.g.
,----
| Add another autocommand like TermResponse that is fired for the other terminal
| responses, such as bg and fg. Use "bg", "fg", "blink", etc. for the name.
`----
I think Bram also suggested to add additional TermResponse<Event> for
the various term events before.
BTW: Why wouldn't the VimEnter autocommand work? Is that, because
changing terminal options would then require some more initialization or
is that triggered too early?
Best,
Christian
--
Nie in die ferne Zeit verliere dich! Den Augenblick ergreife! Der ist dein.
-- Friedrich Schiller
--
--
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/20200930082632.GD1002%40256bit.org.
> I'm too busy at the moment to give this a very thoughtful response,
> and it was a while ago that I looked at that code, but it seems that
> there were several things done in response to receiving the
> termresponse, so I don't know that one option would serve all needs.
> In the present case, the only problem seems to be the setting of
> t_Co.
>
> The problem I've had is that I want to set various options and
> highlights depending on the terminal type, but the type is not
> accurately known when vimrc is read, and when the TermResponse event
> is triggered, not everything can be set correctly.
>
> I've resorted to having the termresponse queried in my ~/.bashrc,
> which sets an environment variable that vimrc can then read. It
> works very well for making terminal-dependent settings in my vimrc
> and colorscheme files. When vim queries and receives the
> termresponse itself, it then makes the additional settings you
> mentioned. It would be nice, though, if this could all be done
> within Vim.
>
> I think maybe the whole termresponse behavior should be thought
> through and made more useful, perhaps by adding a later
> TermResponse-like event. I'll try to find some time.
I think this was suggested before. Also the todo file contains a couple
of statements regarding termresponse, e.g.
,----
| Add another autocommand like TermResponse that is fired for the other terminal
| responses, such as bg and fg. Use "bg", "fg", "blink", etc. for the name.
`----
I think Bram also suggested to add additional TermResponse<Event> for
the various term events before.
BTW: Why wouldn't the VimEnter autocommand work? Is that, because
changing terminal options would then require some more initialization or
is that triggered too early?
Best,
Christian
--
Nie in die ferne Zeit verliere dich! Den Augenblick ergreife! Der ist dein.
-- Friedrich Schiller
--
--
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/20200930082632.GD1002%40256bit.org.
Tuesday, September 29, 2020
Re: how to extend search-for-word-under-cursor
On Tuesday, September 29, 2020 at 4:24:56 PM UTC-4, Tim Chase wrote:
On 2020-09-29 13:05, Richard Mitchell wrote:
> Can a search-for-word-under-cursor be extended to search
> for both that word and the same word with a specific leading
> character?
>
> For example, when sitting on "foo", I want to find both "foo"
> and "_foo", but not anything else.
I don't do it regularly, but a couple ideas for you to play with.
1) relax your requirements such that "g*" and "g#" will also find
these matches (":help g*"). However, they find any match, even
non-whole-word matches
2) Pull the current word into a manual search:
/\<_\=<c-r><c-w>\>
This does a search requiring that a word start here ("\<"), has an
optional ("\=") leading underscore, then pulls in the Word under
the cursor with control+R followed by control+W, then finally
requires that the word end here ("\>"). This can be wrapped up in
a mapping (as long as you use proper escaping) if you do it
frequently enough to warrent. Something like this untested
:nnoremap <f2> /<bslash><lt>=<c-r><c-w><bslash>><cr>
might do the trick.
-tim
Thanks!
Using ctrl-s instead, this does exactly what I asked:
However, I may not have asked the right question.
I use various plugins to extend searching, such as:
vim-scripts/Add-to-Word-Search and inkarkat/vim-SearchHighlighting
Ideally I'd like these to automagically inherit the modified search.
I'm just being greedy.
Thanks again!
--
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/868e98b2-9b4a-4f00-8cc5-ab9dedfad0f0o%40googlegroups.com.
Re: how to extend search-for-word-under-cursor
On 2020-09-29 13:05, Richard Mitchell wrote:
> Can a search-for-word-under-cursor be extended to search
> for both that word and the same word with a specific leading
> character?
>
> For example, when sitting on "foo", I want to find both "foo"
> and "_foo", but not anything else.
I don't do it regularly, but a couple ideas for you to play with.
1) relax your requirements such that "g*" and "g#" will also find
these matches (":help g*"). However, they find any match, even
non-whole-word matches
2) Pull the current word into a manual search:
/\<_\=<c-r><c-w>\>
This does a search requiring that a word start here ("\<"), has an
optional ("\=") leading underscore, then pulls in the Word under
the cursor with control+R followed by control+W, then finally
requires that the word end here ("\>"). This can be wrapped up in
a mapping (as long as you use proper escaping) if you do it
frequently enough to warrent. Something like this untested
:nnoremap <f2> /<bslash><lt>=<c-r><c-w><bslash>><cr>
might do the trick.
-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/20200929152444.3b191117%40bigbox.attlocal.net.
> Can a search-for-word-under-cursor be extended to search
> for both that word and the same word with a specific leading
> character?
>
> For example, when sitting on "foo", I want to find both "foo"
> and "_foo", but not anything else.
I don't do it regularly, but a couple ideas for you to play with.
1) relax your requirements such that "g*" and "g#" will also find
these matches (":help g*"). However, they find any match, even
non-whole-word matches
2) Pull the current word into a manual search:
/\<_\=<c-r><c-w>\>
This does a search requiring that a word start here ("\<"), has an
optional ("\=") leading underscore, then pulls in the Word under
the cursor with control+R followed by control+W, then finally
requires that the word end here ("\>"). This can be wrapped up in
a mapping (as long as you use proper escaping) if you do it
frequently enough to warrent. Something like this untested
:nnoremap <f2> /<bslash><lt>=<c-r><c-w><bslash>><cr>
might do the trick.
-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/20200929152444.3b191117%40bigbox.attlocal.net.
how to extend search-for-word-under-cursor
Can a search-for-word-under-cursor be extended to search
for both that word and the same word with a specific leading
character?
For example, when sitting on "foo", I want to find both "foo"
and "_foo", but not anything else.
--
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/020b70db-0d9e-4749-be8b-ccda1bd07300o%40googlegroups.com.
Re: `set t_Co=16` in vimrc file has no effect
On 2020-09-29, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > On 2020-09-26, Nikolay Belikov wrote:
> > > Hello all,
> > >
> > > I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> > > variable. This might be a bug, but more probably is just a case of
> > > PEBCAK, so maybe someone could point me towards what I'm doing wrong.
> > >
> > > Background: I want to use my terminal emulator (which is plain old
> > > `xterm`) color scheme across all TUI programs, including Vim. I've
> > > added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> > > itself to 16 base colors (at least this is what all sources on Internet
> > > say to do, which I managed to find). However, it appears that Vim does
> > > not honor my will and resets `t_Co` to 256, unless I manually type `:set
> > > t_Co=16` in command-line mode.
> > >
> > > I reduced my `vimrc` to the bare minimum needed to reproduce the
> > > problem, and now it contains a single line:
> > >
> > > set t_Co=16
> > >
> > > At this point I'm unsure what to do and ask for your assistance. I
> > > attach a log captured by running `vim -V100vim.log` as well as version
> > > info (`vim --version >vim.version`), and I'm willing to provide any
> > > other info that may be of help.
> >
> > Vim may change t_Co when it receives a terminal's termresponse.
> > I noticed the same strange behavior some years ago with Vim setting
> > t_Co to 256 in an xterm. See
> >
> > :help v:termresponse
> > :help t_RV
> > :helpgrep termresponse
> >
> > You can test this by adding this to your vimrc,
> >
> > set t_RV=
> >
> > and seeing if t_Co is still mysteriously reset to 256.
> >
> > You may be able to reset t_Co to 16 with this in your vimrc:
> >
> > autocmd TermResponse * set t_Co=16
> >
> > I say "may" because I've found that not everything works as I would
> > expect it to in the environment of a TermResponse autocommand.
> >
> > See
> >
> > :help TermResponse
>
> Vim has a special mechanism to request the actual termcap codes from
> xterm. This happens after receiving the termresponse. Using the
> TermResponse autocommand may do this too early.
>
> There is actually no way to disable this mechanism without also
> disabling some other stuff. It might be helpful to add an option to
> disable the mechanism. 'termgetcodes', default on?
> The function that sends the requests is req_more_codes_from_term().
I'm too busy at the moment to give this a very thoughtful response,
and it was a while ago that I looked at that code, but it seems that
there were several things done in response to receiving the
termresponse, so I don't know that one option would serve all needs.
In the present case, the only problem seems to be the setting of
t_Co.
The problem I've had is that I want to set various options and
highlights depending on the terminal type, but the type is not
accurately known when vimrc is read, and when the TermResponse event
is triggered, not everything can be set correctly.
I've resorted to having the termresponse queried in my ~/.bashrc,
which sets an environment variable that vimrc can then read. It
works very well for making terminal-dependent settings in my vimrc
and colorscheme files. When vim queries and receives the
termresponse itself, it then makes the additional settings you
mentioned. It would be nice, though, if this could all be done
within Vim.
I think maybe the whole termresponse behavior should be thought
through and made more useful, perhaps by adding a later
TermResponse-like event. I'll try to find some time.
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/20200929192640.GB31849%40phoenix.
> Gary Johnson wrote:
>
> > On 2020-09-26, Nikolay Belikov wrote:
> > > Hello all,
> > >
> > > I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> > > variable. This might be a bug, but more probably is just a case of
> > > PEBCAK, so maybe someone could point me towards what I'm doing wrong.
> > >
> > > Background: I want to use my terminal emulator (which is plain old
> > > `xterm`) color scheme across all TUI programs, including Vim. I've
> > > added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> > > itself to 16 base colors (at least this is what all sources on Internet
> > > say to do, which I managed to find). However, it appears that Vim does
> > > not honor my will and resets `t_Co` to 256, unless I manually type `:set
> > > t_Co=16` in command-line mode.
> > >
> > > I reduced my `vimrc` to the bare minimum needed to reproduce the
> > > problem, and now it contains a single line:
> > >
> > > set t_Co=16
> > >
> > > At this point I'm unsure what to do and ask for your assistance. I
> > > attach a log captured by running `vim -V100vim.log` as well as version
> > > info (`vim --version >vim.version`), and I'm willing to provide any
> > > other info that may be of help.
> >
> > Vim may change t_Co when it receives a terminal's termresponse.
> > I noticed the same strange behavior some years ago with Vim setting
> > t_Co to 256 in an xterm. See
> >
> > :help v:termresponse
> > :help t_RV
> > :helpgrep termresponse
> >
> > You can test this by adding this to your vimrc,
> >
> > set t_RV=
> >
> > and seeing if t_Co is still mysteriously reset to 256.
> >
> > You may be able to reset t_Co to 16 with this in your vimrc:
> >
> > autocmd TermResponse * set t_Co=16
> >
> > I say "may" because I've found that not everything works as I would
> > expect it to in the environment of a TermResponse autocommand.
> >
> > See
> >
> > :help TermResponse
>
> Vim has a special mechanism to request the actual termcap codes from
> xterm. This happens after receiving the termresponse. Using the
> TermResponse autocommand may do this too early.
>
> There is actually no way to disable this mechanism without also
> disabling some other stuff. It might be helpful to add an option to
> disable the mechanism. 'termgetcodes', default on?
> The function that sends the requests is req_more_codes_from_term().
I'm too busy at the moment to give this a very thoughtful response,
and it was a while ago that I looked at that code, but it seems that
there were several things done in response to receiving the
termresponse, so I don't know that one option would serve all needs.
In the present case, the only problem seems to be the setting of
t_Co.
The problem I've had is that I want to set various options and
highlights depending on the terminal type, but the type is not
accurately known when vimrc is read, and when the TermResponse event
is triggered, not everything can be set correctly.
I've resorted to having the termresponse queried in my ~/.bashrc,
which sets an environment variable that vimrc can then read. It
works very well for making terminal-dependent settings in my vimrc
and colorscheme files. When vim queries and receives the
termresponse itself, it then makes the additional settings you
mentioned. It would be nice, though, if this could all be done
within Vim.
I think maybe the whole termresponse behavior should be thought
through and made more useful, perhaps by adding a later
TermResponse-like event. I'll try to find some time.
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/20200929192640.GB31849%40phoenix.
Re: `set t_Co=16` in vimrc file has no effect
Gary Johnson wrote:
> On 2020-09-26, Nikolay Belikov wrote:
> > Hello all,
> >
> > I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> > variable. This might be a bug, but more probably is just a case of
> > PEBCAK, so maybe someone could point me towards what I'm doing wrong.
> >
> > Background: I want to use my terminal emulator (which is plain old
> > `xterm`) color scheme across all TUI programs, including Vim. I've
> > added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> > itself to 16 base colors (at least this is what all sources on Internet
> > say to do, which I managed to find). However, it appears that Vim does
> > not honor my will and resets `t_Co` to 256, unless I manually type `:set
> > t_Co=16` in command-line mode.
> >
> > I reduced my `vimrc` to the bare minimum needed to reproduce the
> > problem, and now it contains a single line:
> >
> > set t_Co=16
> >
> > At this point I'm unsure what to do and ask for your assistance. I
> > attach a log captured by running `vim -V100vim.log` as well as version
> > info (`vim --version >vim.version`), and I'm willing to provide any
> > other info that may be of help.
>
> Vim may change t_Co when it receives a terminal's termresponse.
> I noticed the same strange behavior some years ago with Vim setting
> t_Co to 256 in an xterm. See
>
> :help v:termresponse
> :help t_RV
> :helpgrep termresponse
>
> You can test this by adding this to your vimrc,
>
> set t_RV=
>
> and seeing if t_Co is still mysteriously reset to 256.
>
> You may be able to reset t_Co to 16 with this in your vimrc:
>
> autocmd TermResponse * set t_Co=16
>
> I say "may" because I've found that not everything works as I would
> expect it to in the environment of a TermResponse autocommand.
>
> See
>
> :help TermResponse
Vim has a special mechanism to request the actual termcap codes from
xterm. This happens after receiving the termresponse. Using the
TermResponse autocommand may do this too early.
There is actually no way to disable this mechanism without also
disabling some other stuff. It might be helpful to add an option to
disable the mechanism. 'termgetcodes', default on?
The function that sends the requests is req_more_codes_from_term().
--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
site address in print or on TV, even though you've never had heart
problems before.
/// 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/202009291834.08TIYxSX757996%40masaka.moolenaar.net.
> On 2020-09-26, Nikolay Belikov wrote:
> > Hello all,
> >
> > I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> > variable. This might be a bug, but more probably is just a case of
> > PEBCAK, so maybe someone could point me towards what I'm doing wrong.
> >
> > Background: I want to use my terminal emulator (which is plain old
> > `xterm`) color scheme across all TUI programs, including Vim. I've
> > added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> > itself to 16 base colors (at least this is what all sources on Internet
> > say to do, which I managed to find). However, it appears that Vim does
> > not honor my will and resets `t_Co` to 256, unless I manually type `:set
> > t_Co=16` in command-line mode.
> >
> > I reduced my `vimrc` to the bare minimum needed to reproduce the
> > problem, and now it contains a single line:
> >
> > set t_Co=16
> >
> > At this point I'm unsure what to do and ask for your assistance. I
> > attach a log captured by running `vim -V100vim.log` as well as version
> > info (`vim --version >vim.version`), and I'm willing to provide any
> > other info that may be of help.
>
> Vim may change t_Co when it receives a terminal's termresponse.
> I noticed the same strange behavior some years ago with Vim setting
> t_Co to 256 in an xterm. See
>
> :help v:termresponse
> :help t_RV
> :helpgrep termresponse
>
> You can test this by adding this to your vimrc,
>
> set t_RV=
>
> and seeing if t_Co is still mysteriously reset to 256.
>
> You may be able to reset t_Co to 16 with this in your vimrc:
>
> autocmd TermResponse * set t_Co=16
>
> I say "may" because I've found that not everything works as I would
> expect it to in the environment of a TermResponse autocommand.
>
> See
>
> :help TermResponse
Vim has a special mechanism to request the actual termcap codes from
xterm. This happens after receiving the termresponse. Using the
TermResponse autocommand may do this too early.
There is actually no way to disable this mechanism without also
disabling some other stuff. It might be helpful to add an option to
disable the mechanism. 'termgetcodes', default on?
The function that sends the requests is req_more_codes_from_term().
--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
site address in print or on TV, even though you've never had heart
problems before.
/// 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/202009291834.08TIYxSX757996%40masaka.moolenaar.net.
Re: `set t_Co=16` in vimrc file has no effect
On 2020-09-26, Nikolay Belikov wrote:
> Hello all,
>
> I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> variable. This might be a bug, but more probably is just a case of
> PEBCAK, so maybe someone could point me towards what I'm doing wrong.
>
> Background: I want to use my terminal emulator (which is plain old
> `xterm`) color scheme across all TUI programs, including Vim. I've
> added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> itself to 16 base colors (at least this is what all sources on Internet
> say to do, which I managed to find). However, it appears that Vim does
> not honor my will and resets `t_Co` to 256, unless I manually type `:set
> t_Co=16` in command-line mode.
>
> I reduced my `vimrc` to the bare minimum needed to reproduce the
> problem, and now it contains a single line:
>
> set t_Co=16
>
> At this point I'm unsure what to do and ask for your assistance. I
> attach a log captured by running `vim -V100vim.log` as well as version
> info (`vim --version >vim.version`), and I'm willing to provide any
> other info that may be of help.
Vim may change t_Co when it receives a terminal's termresponse.
I noticed the same strange behavior some years ago with Vim setting
t_Co to 256 in an xterm. See
:help v:termresponse
:help t_RV
:helpgrep termresponse
You can test this by adding this to your vimrc,
set t_RV=
and seeing if t_Co is still mysteriously reset to 256.
You may be able to reset t_Co to 16 with this in your vimrc:
autocmd TermResponse * set t_Co=16
I say "may" because I've found that not everything works as I would
expect it to in the environment of a TermResponse autocommand.
See
:help TermResponse
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/20200929150547.GA31849%40phoenix.
> Hello all,
>
> I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
> variable. This might be a bug, but more probably is just a case of
> PEBCAK, so maybe someone could point me towards what I'm doing wrong.
>
> Background: I want to use my terminal emulator (which is plain old
> `xterm`) color scheme across all TUI programs, including Vim. I've
> added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
> itself to 16 base colors (at least this is what all sources on Internet
> say to do, which I managed to find). However, it appears that Vim does
> not honor my will and resets `t_Co` to 256, unless I manually type `:set
> t_Co=16` in command-line mode.
>
> I reduced my `vimrc` to the bare minimum needed to reproduce the
> problem, and now it contains a single line:
>
> set t_Co=16
>
> At this point I'm unsure what to do and ask for your assistance. I
> attach a log captured by running `vim -V100vim.log` as well as version
> info (`vim --version >vim.version`), and I'm willing to provide any
> other info that may be of help.
Vim may change t_Co when it receives a terminal's termresponse.
I noticed the same strange behavior some years ago with Vim setting
t_Co to 256 in an xterm. See
:help v:termresponse
:help t_RV
:helpgrep termresponse
You can test this by adding this to your vimrc,
set t_RV=
and seeing if t_Co is still mysteriously reset to 256.
You may be able to reset t_Co to 16 with this in your vimrc:
autocmd TermResponse * set t_Co=16
I say "may" because I've found that not everything works as I would
expect it to in the environment of a TermResponse autocommand.
See
:help TermResponse
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/20200929150547.GA31849%40phoenix.
Monday, September 28, 2020
Re: `set t_Co=16` in vimrc file has no effect
On Tuesday, September 29, 2020 at 12:32:24 AM UTC+2, Nikolay Belikov wrote:
Hello all,
I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
variable. This might be a bug, but more probably is just a case of
PEBCAK, so maybe someone could point me towards what I'm doing wrong.
Background: I want to use my terminal emulator (which is plain old
`xterm`) color scheme across all TUI programs, including Vim. I've
added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
itself to 16 base colors (at least this is what all sources on Internet
say to do, which I managed to find). However, it appears that Vim does
not honor my will and resets `t_Co` to 256, unless I manually type `:set
t_Co=16` in command-line mode.
I reduced my `vimrc` to the bare minimum needed to reproduce the
problem, and now it contains a single line:
set t_Co=16
At this point I'm unsure what to do and ask for your assistance. I
attach a log captured by running `vim -V100vim.log` as well as version
info (`vim --version >vim.version`), and I'm willing to provide any
other info that may be of help.
Best regards,
NB
I wouldn't expect Vim to overide that setting, but maybe some script (for instance some "system vimrc" installed by your sysadmin or your software distributor) does it behind your back.
The command
:verbose set t_Co?
should tell you both the current value and where it was set.
If that still doesn't help you, you might try to replace your "set t_Co=16" statement by
if has('autocmd') && !has('gui_running')
au VimEnter set t_Co=16 | syntax enable
endif
(which would set that setting at the very end of startup, except in gvim which uses 16777216 colours no matter what you set t_Co to) and see if it changes anything.
Best regards,
Tony.
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/6bdaaf85-1ca1-420e-8ed3-b02b8fc6498eo%40googlegroups.com.
Sunday, September 27, 2020
Re: Lambdas and "typedefs" in Vim9
On 2020-09-27, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
>> Filter(x, { v -> v =~ '^b' })
>> # E1013
>
> Well, in a sense that is correct. The Filter() functions accepts a
> function reference with a specific type, and what is passed in is a
> function reference without any known type.
Ok, that might be expected, but the above call fails also when
Filter()'s argument is defined simply as `func`, which, according to the
documentation, is the type for arguments that are "any kind of function
reference, no type checking for arguments or return value".
But I'd rather have strict type checking anyway, so what you propose
below would be perfect. Unfortunately, I am not into the implementation
details enough to be helpful. Looking forward to seeing progress in this
area as well!
Life.
> This works:
>
> def Func()
> Filter(x, { v -> v =~ '^b' })
> enddef
> Func()
>
> Because the lambda is compiled.
>
> I suppose what we could do is that when an argument is a lambda, first
> compile it, so that we have the type. This would also make execution
> faster. It gets a bit more complicated if it's a nested structure, e.g.
> dict with a lambda.
>
> --
> A)bort, R)etry, B)ang it with a large hammer
>
> /// 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/rkqgue%241385%241%40ciao.gmane.io.
>
>> Filter(x, { v -> v =~ '^b' })
>> # E1013
>
> Well, in a sense that is correct. The Filter() functions accepts a
> function reference with a specific type, and what is passed in is a
> function reference without any known type.
Ok, that might be expected, but the above call fails also when
Filter()'s argument is defined simply as `func`, which, according to the
documentation, is the type for arguments that are "any kind of function
reference, no type checking for arguments or return value".
But I'd rather have strict type checking anyway, so what you propose
below would be perfect. Unfortunately, I am not into the implementation
details enough to be helpful. Looking forward to seeing progress in this
area as well!
Life.
> This works:
>
> def Func()
> Filter(x, { v -> v =~ '^b' })
> enddef
> Func()
>
> Because the lambda is compiled.
>
> I suppose what we could do is that when an argument is a lambda, first
> compile it, so that we have the type. This would also make execution
> faster. It gets a bit more complicated if it's a nested structure, e.g.
> dict with a lambda.
>
> --
> A)bort, R)etry, B)ang it with a large hammer
>
> /// 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/rkqgue%241385%241%40ciao.gmane.io.
Re: Lambdas and "typedefs" in Vim9
> This is what I have tried:
>
> vim9script
>
> def Filter(l: list<string>, Cond: func(string): bool): list<string>
> let res = []
> for item in l
> if Cond(item)
> add(res, item)
> endif
> endfor
> return res
> enddef
>
> def Filter2(l: list<string>, Cond: func(string): bool): list<string>
> return filter(copy(l), Cond)
> enddef
>
> def MyCond(v: string): bool
> return v =~ '^a'
> enddef
>
> let x = ['a', 'b', 'c']
>
> Filter(x, MyCond)
> # OK
>
> Filter(x, funcref(MyCond))
> # OK
>
> Filter(x, { v -> v =~ '^b' })
> # E1013
Well, in a sense that is correct. The Filter() functions accepts a
function reference with a specific type, and what is passed in is a
function reference without any known type. Using that function
reference might fail, thus requires a runtime check, which is what we
want to avoid in a compiled function.
This works:
def Func()
Filter(x, { v -> v =~ '^b' })
enddef
Func()
Because the lambda is compiled.
I suppose what we could do is that when an argument is a lambda, first
compile it, so that we have the type. This would also make execution
faster. It gets a bit more complicated if it's a nested structure, e.g.
dict with a lambda.
--
A)bort, R)etry, B)ang it with a large hammer
/// 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/202009271545.08RFjj4L186795%40masaka.moolenaar.net.
>
> vim9script
>
> def Filter(l: list<string>, Cond: func(string): bool): list<string>
> let res = []
> for item in l
> if Cond(item)
> add(res, item)
> endif
> endfor
> return res
> enddef
>
> def Filter2(l: list<string>, Cond: func(string): bool): list<string>
> return filter(copy(l), Cond)
> enddef
>
> def MyCond(v: string): bool
> return v =~ '^a'
> enddef
>
> let x = ['a', 'b', 'c']
>
> Filter(x, MyCond)
> # OK
>
> Filter(x, funcref(MyCond))
> # OK
>
> Filter(x, { v -> v =~ '^b' })
> # E1013
Well, in a sense that is correct. The Filter() functions accepts a
function reference with a specific type, and what is passed in is a
function reference without any known type. Using that function
reference might fail, thus requires a runtime check, which is what we
want to avoid in a compiled function.
This works:
def Func()
Filter(x, { v -> v =~ '^b' })
enddef
Func()
Because the lambda is compiled.
I suppose what we could do is that when an argument is a lambda, first
compile it, so that we have the type. This would also make execution
faster. It gets a bit more complicated if it's a nested structure, e.g.
dict with a lambda.
--
A)bort, R)etry, B)ang it with a large hammer
/// 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/202009271545.08RFjj4L186795%40masaka.moolenaar.net.
Re: Lambdas and "typedefs" in Vim9
On 2020-09-27, Bram Moolenaar <Bram@moolenaar.net> wrote:
>> I have two questions/curiosities:
>>
>> 1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
>> be supported?
>
> Can you give an example of what does not work?
This is what I have tried:
vim9script
def Filter(l: list<string>, Cond: func(string): bool): list<string>
let res = []
for item in l
if Cond(item)
add(res, item)
endif
endfor
return res
enddef
def Filter2(l: list<string>, Cond: func(string): bool): list<string>
return filter(copy(l), Cond)
enddef
def MyCond(v: string): bool
return v =~ '^a'
enddef
let x = ['a', 'b', 'c']
Filter(x, MyCond)
# OK
Filter(x, funcref(MyCond))
# OK
Filter(x, { v -> v =~ '^b' })
# E1013
Filter2(x, { v -> v =~ '^b' })
# Ditto
I have tried other variations of the signatures, such as 'func', but
without luck. Also tried to add types to the lambda, as in:
{ v: string -> ... }
but that gives E720 (not that I expected it to work).
>> 2. Has a type aliasing or "typedef" mechanism been considered or,
>> perhaps, already planned? My use case is defining a library of opaque
>> types, which I can change without the need to modify client code.
>
> Yes, typedefs are planned to be added at some point. We can make
> everything work without it, so it's for later.
That's great!
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/rkq4el%24p4m%241%40ciao.gmane.io.
>> I have two questions/curiosities:
>>
>> 1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
>> be supported?
>
> Can you give an example of what does not work?
This is what I have tried:
vim9script
def Filter(l: list<string>, Cond: func(string): bool): list<string>
let res = []
for item in l
if Cond(item)
add(res, item)
endif
endfor
return res
enddef
def Filter2(l: list<string>, Cond: func(string): bool): list<string>
return filter(copy(l), Cond)
enddef
def MyCond(v: string): bool
return v =~ '^a'
enddef
let x = ['a', 'b', 'c']
Filter(x, MyCond)
# OK
Filter(x, funcref(MyCond))
# OK
Filter(x, { v -> v =~ '^b' })
# E1013
Filter2(x, { v -> v =~ '^b' })
# Ditto
I have tried other variations of the signatures, such as 'func', but
without luck. Also tried to add types to the lambda, as in:
{ v: string -> ... }
but that gives E720 (not that I expected it to work).
>> 2. Has a type aliasing or "typedef" mechanism been considered or,
>> perhaps, already planned? My use case is defining a library of opaque
>> types, which I can change without the need to modify client code.
>
> Yes, typedefs are planned to be added at some point. We can make
> everything work without it, so it's for later.
That's great!
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/rkq4el%24p4m%241%40ciao.gmane.io.
Re: Lambdas and "typedefs" in Vim9
> I have not followed the development of Vim9 script closely, but
> yesterday I have started to play with it. I was pleasantly surprised to
> see how far it's got already: I could convert some scripts of mine
> without much effort and make them run just fine!
Glad to hear. Note that some things still change.
> I have two questions/curiosities:
>
> 1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
> be supported?
Can you give an example of what does not work?
> 2. Has a type aliasing or "typedef" mechanism been considered or,
> perhaps, already planned? My use case is defining a library of opaque
> types, which I can change without the need to modify client code.
Yes, typedefs are planned to be added at some point. We can make
everything work without it, so it's for later.
--
The average life of an organization chart is six months. You can safely
ignore any order from your boss that would take six months to complete.
(Scott Adams - The Dilbert principle)
/// 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/202009271151.08RBpfkI137035%40masaka.moolenaar.net.
> yesterday I have started to play with it. I was pleasantly surprised to
> see how far it's got already: I could convert some scripts of mine
> without much effort and make them run just fine!
Glad to hear. Note that some things still change.
> I have two questions/curiosities:
>
> 1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
> be supported?
Can you give an example of what does not work?
> 2. Has a type aliasing or "typedef" mechanism been considered or,
> perhaps, already planned? My use case is defining a library of opaque
> types, which I can change without the need to modify client code.
Yes, typedefs are planned to be added at some point. We can make
everything work without it, so it's for later.
--
The average life of an organization chart is six months. You can safely
ignore any order from your boss that would take six months to complete.
(Scott Adams - The Dilbert principle)
/// 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/202009271151.08RBpfkI137035%40masaka.moolenaar.net.
Lambdas and "typedefs" in Vim9
I have not followed the development of Vim9 script closely, but
yesterday I have started to play with it. I was pleasantly surprised to
see how far it's got already: I could convert some scripts of mine
without much effort and make them run just fine!
I have two questions/curiosities:
1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
be supported?
2. Has a type aliasing or "typedef" mechanism been considered or,
perhaps, already planned? My use case is defining a library of opaque
types, which I can change without the need to modify client code.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/rkplkd%24o98%241%40ciao.gmane.io.
yesterday I have started to play with it. I was pleasantly surprised to
see how far it's got already: I could convert some scripts of mine
without much effort and make them run just fine!
I have two questions/curiosities:
1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
be supported?
2. Has a type aliasing or "typedef" mechanism been considered or,
perhaps, already planned? My use case is defining a library of opaque
types, which I can change without the need to modify client code.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/rkplkd%24o98%241%40ciao.gmane.io.
Re: Vim online conference - downloading talks from playlist
https://nitter.net/guckes/status/1303443706368929792#m
# download playlist of #VimConf 2020:
LIST='https://www.youtube.com/playlist?list=PLcTu2VkAIIWzD2kicFNHN2c35XQCeZdsv'
TEMPLATE='%(upload_date)s.%(id)s.%(duration)s.%(title)s.%(ext)s'
youtube-dl -f 18 --restrict-filenames -o $TEMPLATE $LIST
worked for me :)
Sven
--
--
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/20200927090930.p4ctry67pbliwqtj%40guckes.net.
# download playlist of #VimConf 2020:
LIST='https://www.youtube.com/playlist?list=PLcTu2VkAIIWzD2kicFNHN2c35XQCeZdsv'
TEMPLATE='%(upload_date)s.%(id)s.%(duration)s.%(title)s.%(ext)s'
youtube-dl -f 18 --restrict-filenames -o $TEMPLATE $LIST
worked for me :)
Sven
--
--
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/20200927090930.p4ctry67pbliwqtj%40guckes.net.
Saturday, September 26, 2020
Re: Vim online conference - hopin.to account required
I think that works as well as the other responses1
-- Thanks!!!
Russ
-----Original Message-----
From: Richard Mitchell <rwmitchell@gmail.com>
To: vim_use <vim_use@googlegroups.com>
Sent: Sat, Sep 26, 2020 2:16 pm
Subject: Re: Vim online conference - hopin.to account required
On Saturday, September 26, 2020 at 2:51:39 PM UTC-4, russur wrote:
From: Richard Mitchell <rwmitchell@gmail.com>
To: vim_use <vim_use@googlegroups.com>
Sent: Sat, Sep 26, 2020 2:16 pm
Subject: Re: Vim online conference - hopin.to account required
On Saturday, September 26, 2020 at 2:51:39 PM UTC-4, russur wrote:
Where are all the Vim Conference videos. They look like they have all been taken down?
Thanks,
Russ
Try going to:
https://www.youtube.com/playlist?list=PLcTu2VkAIIWzD2kicFNHN2c35XQCeZdsv
If that doesn't work, goto youtube and search for VimConf 2020.
I think there was an ownership issue with having videos posted elsewhere, the solution was for presenters to post their videos directly on youtube.
I was only half paying attention, so that may bear no resemblance to reality.
-----Original Message-----
From: Tekki <te...@tekki.ch>
To: vim_use <vim...@googlegroups.com>
Sent: Sun, Sep 6, 2020 2:50 am
Subject: Re: Vim online conference - hopin.to account required
They will upload all sessions to vimconf.live after the event.
Bram Moolenaar schrieb am Samstag, 5. September 2020 um 17:04:22 UTC+2:
Sven wrote:
> * Bram Moolenaar <Br...@moolenaar.net> [2020-09-05 14:00]:
> > Sven wrote:
> > > here are some more links to the vimconf:
> > > homepage: https://www.vimconf.live/
> > > webpage: https://hopin.to/events/ vimconf-live
> > That works, but there are no links in the events.
>
> i dont think the talks can be linked individually at all. :-/
> in case i am missing these - please let me know so i can add them
I can't find links to individual talks, best I could find is a link to
the agenda: https://www.vimconf.live/# agenda
> > Is it possible to just watch without registering?
> > The Terms & Conditions take some time to read...
>
> official word:
>
> ABD Today at 3:39 PM:
> @guckes unfortunately not, you need to register
> for hopin.to's service to enter the conference
> it's free of course, but unfortunately
> you do need an account
>
> by the way:
>
> Vimconf.live
> Sep 5, 6:00PM to Sep 6, 6:00PM CEST
> 949 people attending
>
> join us! :)
I'm probably not the only one who can't watch live.
I would prefer a recording, so I can watch at a time my own choice.
Hopefully the recordings will be made available, e.g. on youtube, which
doesn't require an account.
Having the presentation slides available would also be nice.
Anyway, I appreciate setting up the conference!
--
ARTHUR: Bloody peasant!
DENNIS: Oh, what a give away. Did you hear that, did you hear that, eh?
That's what I'm on about -- did you see him repressing me, you saw it
didn't you?
The Quest for the Holy Grail (Monty Python)
/// 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 ///--
--
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...@ googlegroups.com.
To view this discussion on the web visit
--
--
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/af7ec1be-3697-498f-b4af-ed9012e498f5o%40googlegroups.com --
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
.
--
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/319054587.908383.1601151253850%40mail.yahoo.com.
Re: Vim online conference - hopin.to account required
On Saturday, September 26, 2020 at 2:51:39 PM UTC-4, russur wrote:
Where are all the Vim Conference videos. They look like they have all been taken down?
Thanks,
Russ
Try going to:
https://www.youtube.com/playlist?list=PLcTu2VkAIIWzD2kicFNHN2c35XQCeZdsv
If that doesn't work, goto youtube and search for VimConf 2020.
I think there was an ownership issue with having videos posted elsewhere, the solution was for presenters to post their videos directly on youtube.
I was only half paying attention, so that may bear no resemblance to reality.
-----Original Message-----
From: Tekki <te...@tekki.ch>
To: vim_use <vim...@googlegroups.com>
Sent: Sun, Sep 6, 2020 2:50 am
Subject: Re: Vim online conference - hopin.to account required
They will upload all sessions to vimconf.live after the event.
Bram Moolenaar schrieb am Samstag, 5. September 2020 um 17:04:22 UTC+2:
Sven wrote:
> * Bram Moolenaar <Br...@moolenaar.net> [2020-09-05 14:00]:
> > Sven wrote:
> > > here are some more links to the vimconf:
> > > homepage: https://www.vimconf.live/
> > > webpage: https://hopin.to/events/vimconf-live
> > That works, but there are no links in the events.
>
> i dont think the talks can be linked individually at all. :-/
> in case i am missing these - please let me know so i can add them
I can't find links to individual talks, best I could find is a link to
the agenda: https://www.vimconf.live/#agenda
> > Is it possible to just watch without registering?
> > The Terms & Conditions take some time to read...
>
> official word:
>
> ABD Today at 3:39 PM:
> @guckes unfortunately not, you need to register
> for hopin.to's service to enter the conference
> it's free of course, but unfortunately
> you do need an account
>
> by the way:
>
> Vimconf.live
> Sep 5, 6:00PM to Sep 6, 6:00PM CEST
> 949 people attending
>
> join us! :)
I'm probably not the only one who can't watch live.
I would prefer a recording, so I can watch at a time my own choice.
Hopefully the recordings will be made available, e.g. on youtube, which
doesn't require an account.
Having the presentation slides available would also be nice.
Anyway, I appreciate setting up the conference!
--
ARTHUR: Bloody peasant!
DENNIS: Oh, what a give away. Did you hear that, did you hear that, eh?
That's what I'm on about -- did you see him repressing me, you saw it
didn't you?
The Quest for the Holy Grail (Monty Python)
/// 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 ///--https://groups.google.com/d/
--
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...@googlegroups.com .
To view this discussion on the web visitmsgid/vim_use/bcd44349-03d8- 40ae-b480-06d399ebdd85n% 40googlegroups.com .
--
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/af7ec1be-3697-498f-b4af-ed9012e498f5o%40googlegroups.com.
Re: Vim online conference - hopin.to account required
Where are all the Vim Conference videos. They look like they have all been taken down?
-- Thanks,
Russ
-----Original Message-----
From: Tekki <tekki@tekki.ch>
To: vim_use <vim_use@googlegroups.com>
Sent: Sun, Sep 6, 2020 2:50 am
Subject: Re: Vim online conference - hopin.to account required
From: Tekki <tekki@tekki.ch>
To: vim_use <vim_use@googlegroups.com>
Sent: Sun, Sep 6, 2020 2:50 am
Subject: Re: Vim online conference - hopin.to account required
They will upload all sessions to vimconf.live after the event.
Bram Moolenaar schrieb am Samstag, 5. September 2020 um 17:04:22 UTC+2:
Sven wrote:
> * Bram Moolenaar <Br...@moolenaar.net> [2020-09-05 14:00]:
> > Sven wrote:
> > > here are some more links to the vimconf:
> > > homepage: https://www.vimconf.live/
> > > webpage: https://hopin.to/events/vimconf-live
> > That works, but there are no links in the events.
>
> i dont think the talks can be linked individually at all. :-/
> in case i am missing these - please let me know so i can add them
I can't find links to individual talks, best I could find is a link to
the agenda: https://www.vimconf.live/#agenda
> > Is it possible to just watch without registering?
> > The Terms & Conditions take some time to read...
>
> official word:
>
> ABD Today at 3:39 PM:
> @guckes unfortunately not, you need to register
> for hopin.to's service to enter the conference
> it's free of course, but unfortunately
> you do need an account
>
> by the way:
>
> Vimconf.live
> Sep 5, 6:00PM to Sep 6, 6:00PM CEST
> 949 people attending
>
> join us! :)
I'm probably not the only one who can't watch live.
I would prefer a recording, so I can watch at a time my own choice.
Hopefully the recordings will be made available, e.g. on youtube, which
doesn't require an account.
Having the presentation slides available would also be nice.
Anyway, I appreciate setting up the conference!
--
ARTHUR: Bloody peasant!
DENNIS: Oh, what a give away. Did you hear that, did you hear that, eh?
That's what I'm on about -- did you see him repressing me, you saw it
didn't you?
The Quest for the Holy Grail (Monty Python)
/// 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 ///
--
--
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/bcd44349-03d8-40ae-b480-06d399ebdd85n%40googlegroups.com --
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
.
--
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/1683188523.886516.1601146286511%40mail.yahoo.com.
`set t_Co=16` in vimrc file has no effect
Hello all,
I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
variable. This might be a bug, but more probably is just a case of
PEBCAK, so maybe someone could point me towards what I'm doing wrong.
Background: I want to use my terminal emulator (which is plain old
`xterm`) color scheme across all TUI programs, including Vim. I've
added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
itself to 16 base colors (at least this is what all sources on Internet
say to do, which I managed to find). However, it appears that Vim does
not honor my will and resets `t_Co` to 256, unless I manually type `:set
t_Co=16` in command-line mode.
I reduced my `vimrc` to the bare minimum needed to reproduce the
problem, and now it contains a single line:
set t_Co=16
At this point I'm unsure what to do and ask for your assistance. I
attach a log captured by running `vim -V100vim.log` as well as version
info (`vim --version >vim.version`), and I'm willing to provide any
other info that may be of help.
Best regards,
NB
--
--
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/20200926110852.GC3828%40void.
I've stumbled upon strange behavior in Vim 8.2 regarding `t_Co`
variable. This might be a bug, but more probably is just a case of
PEBCAK, so maybe someone could point me towards what I'm doing wrong.
Background: I want to use my terminal emulator (which is plain old
`xterm`) color scheme across all TUI programs, including Vim. I've
added `set t_Co=16` to my `.vim/vimrc` file and expected Vim to limit
itself to 16 base colors (at least this is what all sources on Internet
say to do, which I managed to find). However, it appears that Vim does
not honor my will and resets `t_Co` to 256, unless I manually type `:set
t_Co=16` in command-line mode.
I reduced my `vimrc` to the bare minimum needed to reproduce the
problem, and now it contains a single line:
set t_Co=16
At this point I'm unsure what to do and ask for your assistance. I
attach a log captured by running `vim -V100vim.log` as well as version
info (`vim --version >vim.version`), and I'm willing to provide any
other info that may be of help.
Best regards,
NB
--
--
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/20200926110852.GC3828%40void.
Thursday, September 24, 2020
Re: [vim colours + iTerm2 colours]
On 2020-09-24, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:
>
> Thank you very much for your thorough explanations! Now we are very
> close to the solution. My end goal is the opposite. I would like to
> _disable_ iTerm2 colours, when I use Vim. I would like to use _pure_
> Vim colour scheme, without the interference or overlap with the iTerm2
> colour profile. I think I will need to replace the "set termguicolors"
> with the "unset termguicolors" in your snippet to reach my goal. Thank
> you and have a good day ahead!
Every 0/1 option in Vim can be "unset" by prepending "no", e.g.:
:set notermguicolors
With termguicolors disabled, however, you will *not* disable your
terminal colors; rather, the opposite.
I am guessing, because you didn't tell us which color scheme you are
using: your color scheme might be based on ANSI colors (in the range
0-15, or names as in `:help cterm-colors`), in which case the colors you
see necessarily depend on your terminal's settings.
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/rkij7c%24j2u%241%40ciao.gmane.io.
>
> Thank you very much for your thorough explanations! Now we are very
> close to the solution. My end goal is the opposite. I would like to
> _disable_ iTerm2 colours, when I use Vim. I would like to use _pure_
> Vim colour scheme, without the interference or overlap with the iTerm2
> colour profile. I think I will need to replace the "set termguicolors"
> with the "unset termguicolors" in your snippet to reach my goal. Thank
> you and have a good day ahead!
Every 0/1 option in Vim can be "unset" by prepending "no", e.g.:
:set notermguicolors
With termguicolors disabled, however, you will *not* disable your
terminal colors; rather, the opposite.
I am guessing, because you didn't tell us which color scheme you are
using: your color scheme might be based on ANSI colors (in the range
0-15, or names as in `:help cterm-colors`), in which case the colors you
see necessarily depend on your terminal's settings.
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/rkij7c%24j2u%241%40ciao.gmane.io.
Re: [vim colours + iTerm2 colours]
On 24 Sep 2020, at 12:05, Lifepillar <lifepillar@lifepillar.me> wrote:On 2020-09-23, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:Thank you for your reply. I will check. I'm not certain about the "gui"
part of the command. I'm not using Gvim.
The termguicolors option is specifically for terminals supporting
millions of colors, such as iTerm2. It tells Vim to use the "gui" color
specifications of the color scheme you are using (as opposed to the
"cterm" color specifications). Provided that your color scheme defines
guifg and guibg colors for each highlight group (and most color schemes
do), Vim will use such colors, independent of which colors your terminal
is set to display. See `:help termguicolors`, `:help highlight-guifg`,
`:help highlight-ctermfg`.
Some terminals define an environment variable called $COLORTERM to
advertise their color capabilities. Although that is not standard or
universal, it works with iTerm2. So, if you put this snippet in your
vimrc:
if has('termguicolors') && $COLORTERM ==# 'truecolor'
set termguicolors
endif
then termguicolors will be set automatically when you open Vim in
iTerm2.
Dear Life et al.,
Thank you very much for your thorough explanations! Now we are very close to the solution. My end goal is the opposite. I would like to _disable_ iTerm2 colours, when I use Vim. I would like to use _pure_ Vim colour scheme, without the interference or overlap with the iTerm2 colour profile. I think I will need to replace the "set termguicolors" with the "unset termguicolors" in your snippet to reach my goal. Thank you and have a good day ahead!
—
Best wishes,
Maxim
Re: [vim colours + iTerm2 colours]
On 2020-09-23, 'Grant Taylor' via vim_use <vim_use@googlegroups.com> wrote:
> On 9/22/20 7:33 AM, Maxim Abalenkov wrote:
>> I tend to use both vim colours and iTerm2 colour scheme. If I understand
>> correctly, the resulting colours that I see are a mixture of both Vim
>> and iTerm2 colour profiles superimposed. Therefore, my question is how
>> do I tell Vim to use only Vim colour settings and ignore the iTerm2
>> colours? Thank you very much and have a productive day ahead!
>
> Doesn't vim just specify the color number / index (0-7 / 0-15 / 0-255)
> that it wants used for specific characters and then rely on the terminal
> (emulator) to set the actual colors used for any given color number / index?
Not when termguicolors is set to 1.
> I don't think there is any (good*) way for vim to know that you're using
> iTerm2 and adjust it's behavior accordingly. I think this is all in
> iTerm2's control.
iTerm2 defines $TERM_PROGRAM to 'iTerm.app' and $LC_TERMINAL to
'iTerm2'.
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/rkhnsp%24120d%243%40ciao.gmane.io.
> On 9/22/20 7:33 AM, Maxim Abalenkov wrote:
>> I tend to use both vim colours and iTerm2 colour scheme. If I understand
>> correctly, the resulting colours that I see are a mixture of both Vim
>> and iTerm2 colour profiles superimposed. Therefore, my question is how
>> do I tell Vim to use only Vim colour settings and ignore the iTerm2
>> colours? Thank you very much and have a productive day ahead!
>
> Doesn't vim just specify the color number / index (0-7 / 0-15 / 0-255)
> that it wants used for specific characters and then rely on the terminal
> (emulator) to set the actual colors used for any given color number / index?
Not when termguicolors is set to 1.
> I don't think there is any (good*) way for vim to know that you're using
> iTerm2 and adjust it's behavior accordingly. I think this is all in
> iTerm2's control.
iTerm2 defines $TERM_PROGRAM to 'iTerm.app' and $LC_TERMINAL to
'iTerm2'.
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/rkhnsp%24120d%243%40ciao.gmane.io.
Re: [vim colours + iTerm2 colours]
On 2020-09-23, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:
> Thank you for your reply. I will check. I'm not certain about the "gui"
> part of the command. I'm not using Gvim.
The termguicolors option is specifically for terminals supporting
millions of colors, such as iTerm2. It tells Vim to use the "gui" color
specifications of the color scheme you are using (as opposed to the
"cterm" color specifications). Provided that your color scheme defines
guifg and guibg colors for each highlight group (and most color schemes
do), Vim will use such colors, independent of which colors your terminal
is set to display. See `:help termguicolors`, `:help highlight-guifg`,
`:help highlight-ctermfg`.
Some terminals define an environment variable called $COLORTERM to
advertise their color capabilities. Although that is not standard or
universal, it works with iTerm2. So, if you put this snippet in your
vimrc:
if has('termguicolors') && $COLORTERM ==# 'truecolor'
set termguicolors
endif
then termguicolors will be set automatically when you open Vim in
iTerm2.
Hope this helps,
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/rkhnge%24120d%241%40ciao.gmane.io.
> Thank you for your reply. I will check. I'm not certain about the "gui"
> part of the command. I'm not using Gvim.
The termguicolors option is specifically for terminals supporting
millions of colors, such as iTerm2. It tells Vim to use the "gui" color
specifications of the color scheme you are using (as opposed to the
"cterm" color specifications). Provided that your color scheme defines
guifg and guibg colors for each highlight group (and most color schemes
do), Vim will use such colors, independent of which colors your terminal
is set to display. See `:help termguicolors`, `:help highlight-guifg`,
`:help highlight-ctermfg`.
Some terminals define an environment variable called $COLORTERM to
advertise their color capabilities. Although that is not standard or
universal, it works with iTerm2. So, if you put this snippet in your
vimrc:
if has('termguicolors') && $COLORTERM ==# 'truecolor'
set termguicolors
endif
then termguicolors will be set automatically when you open Vim in
iTerm2.
Hope this helps,
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/rkhnge%24120d%241%40ciao.gmane.io.
Wednesday, September 23, 2020
Re: [vim colours + iTerm2 colours]
On 9/22/20 7:33 AM, Maxim Abalenkov wrote:
> I tend to use both vim colours and iTerm2 colour scheme. If I understand
> correctly, the resulting colours that I see are a mixture of both Vim
> and iTerm2 colour profiles superimposed. Therefore, my question is how
> do I tell Vim to use only Vim colour settings and ignore the iTerm2
> colours? Thank you very much and have a productive day ahead!
Doesn't vim just specify the color number / index (0-7 / 0-15 / 0-255)
that it wants used for specific characters and then rely on the terminal
(emulator) to set the actual colors used for any given color number / index?
I don't think there is any (good*) way for vim to know that you're using
iTerm2 and adjust it's behavior accordingly. I think this is all in
iTerm2's control.
*Shell ~> vim may be able to deduce from the TERM environment variable
(and possibly answer back) what the terminal is. But there usually is
not a one-to-one correlation. Further many terminal emulators tend to
lie and say they are a different terminal; ANSI and VT100 are common. I
don't remember what iTerm2 does by default.
--
Grant. . . .
unix || die
--
--
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/2ce2173e-e077-8905-5aa3-e0a70f83d3e4%40spamtrap.tnetconsulting.net.
> I tend to use both vim colours and iTerm2 colour scheme. If I understand
> correctly, the resulting colours that I see are a mixture of both Vim
> and iTerm2 colour profiles superimposed. Therefore, my question is how
> do I tell Vim to use only Vim colour settings and ignore the iTerm2
> colours? Thank you very much and have a productive day ahead!
Doesn't vim just specify the color number / index (0-7 / 0-15 / 0-255)
that it wants used for specific characters and then rely on the terminal
(emulator) to set the actual colors used for any given color number / index?
I don't think there is any (good*) way for vim to know that you're using
iTerm2 and adjust it's behavior accordingly. I think this is all in
iTerm2's control.
*Shell ~> vim may be able to deduce from the TERM environment variable
(and possibly answer back) what the terminal is. But there usually is
not a one-to-one correlation. Further many terminal emulators tend to
lie and say they are a different terminal; ANSI and VT100 are common. I
don't remember what iTerm2 does by default.
--
Grant. . . .
unix || die
--
--
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/2ce2173e-e077-8905-5aa3-e0a70f83d3e4%40spamtrap.tnetconsulting.net.
Re: [vim colours + iTerm2 colours]
Thank you for your reply. I will check. I'm not certain about the "gui" part of the command. I'm not using Gvim.
On Wed, Sep 23, 2020, 21:38 Lifepillar <lifepillar@lifepillar.me> wrote:
On 2020-09-22, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:
> Dear all,
>
> How are you? Potentially, I have another very simple question for you,
> vim experts. My usual working environment is Vim running in an iTerm2
> session. I tend to use both vim colours and iTerm2 colour scheme. If
> I understand correctly, the resulting colours that I see are a mixture
> of both Vim and iTerm2 colour profiles superimposed. Therefore, my
> question is how do I tell Vim to use only Vim colour settings and
> ignore the iTerm2 colours? Thank you very much and have a productive
> day ahead!
Does
:set termguicolors
solve your problem?
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/rkg4m0%24944%241%40ciao.gmane.io.
--
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/CANDEscqa_UChhQ060svJhxpRGnMcojR9WbMduik%3D08ZuiJkp2w%40mail.gmail.com.
Re: [vim colours + iTerm2 colours]
On 2020-09-22, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:
> Dear all,
>
> How are you? Potentially, I have another very simple question for you,
> vim experts. My usual working environment is Vim running in an iTerm2
> session. I tend to use both vim colours and iTerm2 colour scheme. If
> I understand correctly, the resulting colours that I see are a mixture
> of both Vim and iTerm2 colour profiles superimposed. Therefore, my
> question is how do I tell Vim to use only Vim colour settings and
> ignore the iTerm2 colours? Thank you very much and have a productive
> day ahead!
Does
:set termguicolors
solve your problem?
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/rkg4m0%24944%241%40ciao.gmane.io.
> Dear all,
>
> How are you? Potentially, I have another very simple question for you,
> vim experts. My usual working environment is Vim running in an iTerm2
> session. I tend to use both vim colours and iTerm2 colour scheme. If
> I understand correctly, the resulting colours that I see are a mixture
> of both Vim and iTerm2 colour profiles superimposed. Therefore, my
> question is how do I tell Vim to use only Vim colour settings and
> ignore the iTerm2 colours? Thank you very much and have a productive
> day ahead!
Does
:set termguicolors
solve your problem?
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/rkg4m0%24944%241%40ciao.gmane.io.