date:20160427

Re: [vim/vim] Vim is unable to automatically detect my Python version (#419)

2016-04-27 Fir de Conversatie Nikolay Aleksandrovich Pavlov

2016-04-27 18:30 GMT+03:00 Jacky Liu :
> On Tuesday, April 26, 2016 at 4:29:07 PM UTC+8, Markus Meskanen wrote:
>> While I don't expect Vim to become an easy-to-use text editor for beginners 
>> or anything, the current Python support simply isn't enough for a standard 
>> coder. Vim doesn't support multiple Python versions, so you have to compile 
>> multiple versions of Vim. And every time you update your Python, you must 
>> recompile Vim. Other editors simply do Python better.
>>
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly or view it on GitHub
>
> -
>
> You can have the full power of Python from within your Vim only if Vim and 
> Python can run *in the same thread with the same memory space*, this can only 
> be achieved by *embedding* Python into Vim, not invoking it.
>
> The dynamic run-time solution you mentioned is awfully slow and inefficient. 
> Can you imagine an application's UI starts its back-end as an external 
> process and then use a pipe or socket to communicate with it later? Its 
> awful. UI and the back-end should be within the same process. Emacs even try 
> to do data translation between Python and Elisp with its Pymacs, again, its 
> awful, hopeless. Vim should never do that.

Both works well enough in Neovim. Though terminal UI is *now* part of
the same executable (will be different one later), Python communicates
through msgpack over a socket. This thing is obviously slower and in
some cases people need to do optimizations, but most of time this is
good enough. Also there are UIs other then terminal one and they all
use pipes or sockets. Unlike for Python support I did not hear about
problems with UI lags (though maybe because +python users are more
common here then GUI users; on the other side UI authors did not raise
issues regarding communication protocol speed so at least they think
that nothing can be done to speed up, at most they know how to write
their UI without it lagging).

Also this is how most web applications work. UI is in browser. Backend
is on server. And between them you have lots of routers which makes
the whole thing much slower then if UI communicates with Neovim
through msgpack. Still they work, using different hacks for different
situations (from having most of the code on the frontend, only sending
a few commands like “save {big blob}” to the backend once in a while,
to requiring client have his own server with controlled latency).

>
> I suppose Python itself doesn't have good support for multiple versions 
> within the same environment, try creating a Py2 list inside Py3. You can 
> build a py3-enabled Vim and run py2 as an external process, or vice versa. 
> You can have both Vims on your system and choose between them each time 
> accordingly, I suppose you won't definitely need one project of yours half in 
> Py2 and half in Py3.

Python itself (though not Python, but dynamic library loader,
ld-linux.so) has fine support here. Just distribution maintainers do
not bother compiling Python with --enable-shared, so python2 and
python3 effectively cannot be used together unless you go compile them
yourself.

On Gentoo --enable-shared is used, so no such problems here.

Note though that even if you have +python/dyn and +python3/dyn working
at the same time this does not mean that you can use single PyObject
in both interpreters. In this case :python environment is just as
isolated from :python3 as :lua is. So with vim.bindeval the fastest
way of transferring data is using Vim container objects (lists,
dictionaries, but not partials: last is read-only after creation but
still is a container (using list or dictionary should be faster
though)).

>
> --
> --
> You received this message from the "vim_dev" 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_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1770

2016-04-27 Fir de Conversatie Charles E Campbell

Charles Campbell wrote:
> Bram Moolenaar wrote:
>> Charles Campbell wrote:
>>
>>> Bram Moolenaar wrote:
 Patch 7.4.1770
 Problem:Cannot use true color in the terminal.
 Solution:   Add the 'guicolors' option. (Nikolai Pavlov)
 Files:  runtime/doc/options.txt, runtime/doc/term.txt,
 runtime/doc/various.txt, src/auto/configure, src/config.h.in,
 src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c,
 src/option.c, src/option.h, src/proto/term.pro, src/screen.c,
 src/structs.h, src/syntax.c, src/term.c, src/term.h,
 src/version.c, src/vim.h
>>> One unwanted side effect that I've noticed so far: Ignore highlighting
>>> is no longer ignored.
>> What do you mean with "Ignore highlighting", what is used in the help
>> file?  How can it be reproduced?
>>
> Hello:
>
> Here's how to reproduce the problem: (after using bunzip2 and tar xf, of
> course)
>
> 1. vim -u gcol.vimrc junk
>:so junksyn.vim
>
>As attached, gcol.vimrc uses the gcol option.  Note that the trailing
> ~123 does not get Ignore'd.
>
> 2. To see what it should have done: comment out the set gcol line in
>
I need to further mention that when I did this example I had not
configured with  --enable-termtruecolor .  After having done so, the
~123 which should be Ignore'd is not Ignore'd either with or without set
gcol.

Regards,
Chip Campbell

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Kazunobu Kuriyama

When a 'make test' fails, the subsequent 'make test' often succeeds.

Though I'm not sure  the comparison between those two cases could be
helpful, I'm sending you two channellogs ---  the first 'make test' failed
(channellog.failed) but the second 'make test' succeeded
(channellog.success)

2016-04-28 5:04 GMT+09:00 Kazunobu Kuriyama :

> 2016-04-28 4:47 GMT+09:00 Bram Moolenaar :
>
>>
>> Kazunobu Kuriyama wrote:
>>
>> > 2016-04-28 0:42 GMT+09:00 Bram Moolenaar :
>> >
>> > >
>> > > Kazunobu Kuriyama wrote:
>> > >
>> > > > 2016-04-27 17:51 GMT+09:00 Bram Moolenaar :
>> > > >
>> > > > >
>> > > > > Christian Brabandt wrote:
>> > > > >
>> > > > > > Am 2016-04-26 19:01, schrieb Bram Moolenaar:
>> > > > > > > Patch 7.4.1789
>> > > > > >
>> > > > > > I think this patch broke the vim-win32-installer build
>> > > > > >
>> > > > > >   From test_channel.vim:
>> > > > > > Found errors in Test_out_close_cb():
>> > > > > > function RunTheTest[9]..Test_out_close_cb line 23: Expected 1
>> but
>> > > got 2
>> > > > > > function RunTheTest[9]..Test_out_close_cb line 24: Expected 2
>> but
>> > > got 3
>> > > > > > TEST FAILURE
>> > > > > > NMAKE : fatal error U1077: 'if' : return code '0x1'
>> > > > > > Stop.
>> > > > > > Command exited with code 1
>> > > > > >
>> > > > > >
>> > > > >
>> > >
>> https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous
>> > > > >
>> > > > > I noticed the travis build also failed with this error, but then
>> passed
>> > > > > later.  For me it always passes, thus it's hard to find out why it
>> > > would
>> > > > > sometimes fail.  It looks like the callback is invoked twice, but
>> I
>> > > > > don't know why/when that happens.  Any idea?
>> > > > >
>> > > >
>> > > > On OS X, the same error happens occasionally.
>> > > >
>> > > > Since it didn't always happen, I had put it on probation and
>> refrained
>> > > from
>> > > > accusing it of the failure. :)
>> > > >
>> > > > Having done 'make test' five or six times with ch_logfile of
>> > > > test_channel.vim enabled, I finally caught it.
>> > > >
>> > > > Attached are the waring message of the failure (warning.txt) and
>> > > > testdir/channellog when it happened.
>> > > >
>> > > > Hopefully, this could be helpful for you.
>> > >
>> > > Unfortunately the channellog is truncated before the interesting part.
>> > > Perhaps you can start the log in the Test_out_close_cb function.
>> > >
>> >
>> > I added call
>> >
>> > ch_log('Test_out_close_cb()')
>> >
>> > just after test_channel.vim:1055, and the attached file is the result.
>>
>> That line was already there.  do you mean you added ch_logfile()?
>>
>
> Exactly.  More precisely,
>
> diff --git a/src/testdir/test_channel.vim b/src/testdir/test_channel.vim
> index 6eb3c1f..1e6db68 100644
> --- a/src/testdir/test_channel.vim
> +++ b/src/testdir/test_channel.vim
> @@ -1052,6 +1052,7 @@ func Test_out_close_cb()
>if !has('job')
>  return
>endif
> +  call ch_logfile('channellog', 'w')
>call ch_log('Test_out_close_cb()')
>
>let s:counter = 1
>
>
>> > Does this contain the part you need?
>>
>> This is what I see:
>>
>>  start log session 
>>   0.15 : Test_out_close_cb()
>>   0.000114 : Starting job: python  test_channel_pipe.py  quit  now
>>   0.000148 on 26: Created channel
>>   0.012371 ERR on 25: channel_select_check(): Cannot read from
>> channel
>>   0.012463 on 25: Closing channel
>>
>> 25 is from the previous test, we can ignore that.
>>
>>   0.012479 : looking for messages on channels
>>   0.038454 RECV on 26: 'quit
>> '
>>   0.038475 on 26: Invoking channel callback OutHandler
>>
>> First call to OutHandler
>>
>>   0.049656 ERR on 26: channel_select_check(): Cannot read from
>> channel
>>   0.049742 PUT on 26: 'DETACH
>> '
>>   0.049750 on 26: Closing channel
>>   0.049805 on 26: Invoking channel callback OutHandler
>>
>> Second call to OutHandler
>>
>>   0.049953 on 26: Invoking close callback CloseHandler
>>
>> Hmm, it does appear to call OutHandler twice.
>> In my case the first call isn't there.
>> I suppose what happens is that the DETACH is received separately.
>> That is actually what should happen, so why is that message dropped in
>> my case?  Requires some more debugging...
>>
>
> If you need more experiments, or something I can do for you, let me know.
>
>>
>> --
>> ARTHUR: Charge!
>>[They all charge with swords drawn towards the RABBIT.  A tremendous
>> twenty
>>second fight with Peckinpahish shots and borrowing heavily also on the
>>Kung Fu and karate-type films ensues, in which some four KNIGHTS are
>>comprehensively killed.]
>> ARTHUR: Run away!  Run away!
>>  "Monty Python and the Holy Grail" PYTHON (MONTY)
>> PICTURES LTD
>>
>>  /// Bram Moolenaar --

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Kazunobu Kuriyama

2016-04-28 4:47 GMT+09:00 Bram Moolenaar :

>
> Kazunobu Kuriyama wrote:
>
> > 2016-04-28 0:42 GMT+09:00 Bram Moolenaar :
> >
> > >
> > > Kazunobu Kuriyama wrote:
> > >
> > > > 2016-04-27 17:51 GMT+09:00 Bram Moolenaar :
> > > >
> > > > >
> > > > > Christian Brabandt wrote:
> > > > >
> > > > > > Am 2016-04-26 19:01, schrieb Bram Moolenaar:
> > > > > > > Patch 7.4.1789
> > > > > >
> > > > > > I think this patch broke the vim-win32-installer build
> > > > > >
> > > > > >   From test_channel.vim:
> > > > > > Found errors in Test_out_close_cb():
> > > > > > function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but
> > > got 2
> > > > > > function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but
> > > got 3
> > > > > > TEST FAILURE
> > > > > > NMAKE : fatal error U1077: 'if' : return code '0x1'
> > > > > > Stop.
> > > > > > Command exited with code 1
> > > > > >
> > > > > >
> > > > >
> > >
> https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous
> > > > >
> > > > > I noticed the travis build also failed with this error, but then
> passed
> > > > > later.  For me it always passes, thus it's hard to find out why it
> > > would
> > > > > sometimes fail.  It looks like the callback is invoked twice, but I
> > > > > don't know why/when that happens.  Any idea?
> > > > >
> > > >
> > > > On OS X, the same error happens occasionally.
> > > >
> > > > Since it didn't always happen, I had put it on probation and
> refrained
> > > from
> > > > accusing it of the failure. :)
> > > >
> > > > Having done 'make test' five or six times with ch_logfile of
> > > > test_channel.vim enabled, I finally caught it.
> > > >
> > > > Attached are the waring message of the failure (warning.txt) and
> > > > testdir/channellog when it happened.
> > > >
> > > > Hopefully, this could be helpful for you.
> > >
> > > Unfortunately the channellog is truncated before the interesting part.
> > > Perhaps you can start the log in the Test_out_close_cb function.
> > >
> >
> > I added call
> >
> > ch_log('Test_out_close_cb()')
> >
> > just after test_channel.vim:1055, and the attached file is the result.
>
> That line was already there.  do you mean you added ch_logfile()?
>

Exactly.  More precisely,

diff --git a/src/testdir/test_channel.vim b/src/testdir/test_channel.vim
index 6eb3c1f..1e6db68 100644
--- a/src/testdir/test_channel.vim
+++ b/src/testdir/test_channel.vim
@@ -1052,6 +1052,7 @@ func Test_out_close_cb()
   if !has('job')
 return
   endif
+  call ch_logfile('channellog', 'w')
   call ch_log('Test_out_close_cb()')

   let s:counter = 1


> > Does this contain the part you need?
>
> This is what I see:
>
>  start log session 
>   0.15 : Test_out_close_cb()
>   0.000114 : Starting job: python  test_channel_pipe.py  quit  now
>   0.000148 on 26: Created channel
>   0.012371 ERR on 25: channel_select_check(): Cannot read from
> channel
>   0.012463 on 25: Closing channel
>
> 25 is from the previous test, we can ignore that.
>
>   0.012479 : looking for messages on channels
>   0.038454 RECV on 26: 'quit
> '
>   0.038475 on 26: Invoking channel callback OutHandler
>
> First call to OutHandler
>
>   0.049656 ERR on 26: channel_select_check(): Cannot read from
> channel
>   0.049742 PUT on 26: 'DETACH
> '
>   0.049750 on 26: Closing channel
>   0.049805 on 26: Invoking channel callback OutHandler
>
> Second call to OutHandler
>
>   0.049953 on 26: Invoking close callback CloseHandler
>
> Hmm, it does appear to call OutHandler twice.
> In my case the first call isn't there.
> I suppose what happens is that the DETACH is received separately.
> That is actually what should happen, so why is that message dropped in
> my case?  Requires some more debugging...
>

If you need more experiments, or something I can do for you, let me know.

>
> --
> ARTHUR: Charge!
>[They all charge with swords drawn towards the RABBIT.  A tremendous
> twenty
>second fight with Peckinpahish shots and borrowing heavily also on the
>Kung Fu and karate-type films ensues, in which some four KNIGHTS are
>comprehensively killed.]
> ARTHUR: Run away!  Run away!
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES
> LTD
>
>  /// Bram Moolenaar -- b...@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_dev" 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

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Bram Moolenaar


Kazunobu Kuriyama wrote:

> 2016-04-28 0:42 GMT+09:00 Bram Moolenaar :
> 
> >
> > Kazunobu Kuriyama wrote:
> >
> > > 2016-04-27 17:51 GMT+09:00 Bram Moolenaar :
> > >
> > > >
> > > > Christian Brabandt wrote:
> > > >
> > > > > Am 2016-04-26 19:01, schrieb Bram Moolenaar:
> > > > > > Patch 7.4.1789
> > > > >
> > > > > I think this patch broke the vim-win32-installer build
> > > > >
> > > > >   From test_channel.vim:
> > > > > Found errors in Test_out_close_cb():
> > > > > function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but
> > got 2
> > > > > function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but
> > got 3
> > > > > TEST FAILURE
> > > > > NMAKE : fatal error U1077: 'if' : return code '0x1'
> > > > > Stop.
> > > > > Command exited with code 1
> > > > >
> > > > >
> > > >
> > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous
> > > >
> > > > I noticed the travis build also failed with this error, but then passed
> > > > later.  For me it always passes, thus it's hard to find out why it
> > would
> > > > sometimes fail.  It looks like the callback is invoked twice, but I
> > > > don't know why/when that happens.  Any idea?
> > > >
> > >
> > > On OS X, the same error happens occasionally.
> > >
> > > Since it didn't always happen, I had put it on probation and refrained
> > from
> > > accusing it of the failure. :)
> > >
> > > Having done 'make test' five or six times with ch_logfile of
> > > test_channel.vim enabled, I finally caught it.
> > >
> > > Attached are the waring message of the failure (warning.txt) and
> > > testdir/channellog when it happened.
> > >
> > > Hopefully, this could be helpful for you.
> >
> > Unfortunately the channellog is truncated before the interesting part.
> > Perhaps you can start the log in the Test_out_close_cb function.
> >
> 
> I added call
> 
> ch_log('Test_out_close_cb()')
> 
> just after test_channel.vim:1055, and the attached file is the result.

That line was already there.  do you mean you added ch_logfile()?

> Does this contain the part you need?

This is what I see:

 start log session 
  0.15 : Test_out_close_cb()
  0.000114 : Starting job: python  test_channel_pipe.py  quit  now
  0.000148 on 26: Created channel
  0.012371 ERR on 25: channel_select_check(): Cannot read from channel
  0.012463 on 25: Closing channel

25 is from the previous test, we can ignore that.

  0.012479 : looking for messages on channels
  0.038454 RECV on 26: 'quit
'
  0.038475 on 26: Invoking channel callback OutHandler

First call to OutHandler

  0.049656 ERR on 26: channel_select_check(): Cannot read from channel
  0.049742 PUT on 26: 'DETACH
'
  0.049750 on 26: Closing channel
  0.049805 on 26: Invoking channel callback OutHandler

Second call to OutHandler

  0.049953 on 26: Invoking close callback CloseHandler

Hmm, it does appear to call OutHandler twice.
In my case the first call isn't there.
I suppose what happens is that the DETACH is received separately.
That is actually what should happen, so why is that message dropped in
my case?  Requires some more debugging...

-- 
ARTHUR: Charge!
   [They all charge with swords drawn towards the RABBIT.  A tremendous twenty
   second fight with Peckinpahish shots and borrowing heavily also on the
   Kung Fu and karate-type films ensues, in which some four KNIGHTS are
   comprehensively killed.]
ARTHUR: Run away!  Run away!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows: After Patch 7.4.1792 colors completely wrong

2016-04-27 Fir de Conversatie Bram Moolenaar


Ken Takata wrote:

> 2016/4/27 Wed 5:48:41 UTC+9 Heptite wrote:
> > Something went wrong with this patch. Most of my colors are wrong.
> > 
> > How it looks now: 
> > https://www.dropbox.com/s/q8wc4vzkg8r0uj2/vimwrongcolors.png?dl=0
> > 
> > How it should look:
> > https://www.dropbox.com/s/3of53y3qdiz1xcm/vimcorrectcolors.png?dl=0
> 
> Attached patch should fix the problem.

Thanks!

-- 
TIM:   That is not an ordinary rabbit ... 'tis the most foul cruel and
   bad-tempered thing you ever set eyes on.
ROBIN: You tit.  I soiled my armour I was so scared!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch 7.4.1796

2016-04-27 Fir de Conversatie Bram Moolenaar


Patch 7.4.1796 (after 7.4.1795)
Problem:Colors are wrong on MS-Windows. (Christian Robinson)
Solution:   Use existing RGB macro if it exists. (Ken Takata)
Files:  src/term.c


*** ../vim-7.4.1795/src/term.c  2016-04-26 22:33:11.913443804 +0200
--- src/term.c  2016-04-27 20:35:31.865622983 +0200
***
*** 6068,6075 
  guicolor_T
  gui_get_color_cmn(char_u *name)
  {
! #define TORGB(r, g, b) ((r<<16) | (g<<8) | (b))
! #define LINE_LEN 100
  FILE  *fd;
  char  line[LINE_LEN];
  char_u*fname;
--- 6068,6079 
  guicolor_T
  gui_get_color_cmn(char_u *name)
  {
! /* On MS-Windows an RGB macro is available and it's different from ours,
!  * but does what is needed. */
! # ifndef RGB
! #  define RGB(r, g, b)((r<<16) | (g<<8) | (b))
! # endif
! # define LINE_LEN 100
  FILE  *fd;
  char  line[LINE_LEN];
  char_u*fname;
***
*** 6082,6144 
  };
  
  static struct rgbcolor_table_S rgb_table[] = {
!   {(char_u *)"black", TORGB(0x00, 0x00, 0x00)},
!   {(char_u *)"blue",  TORGB(0x00, 0x00, 0xFF)},
!   {(char_u *)"brown", TORGB(0xA5, 0x2A, 0x2A)},
!   {(char_u *)"cyan",  TORGB(0x00, 0xFF, 0xFF)},
!   {(char_u *)"darkblue",  TORGB(0x00, 0x00, 0x8B)},
!   {(char_u *)"darkcyan",  TORGB(0x00, 0x8B, 0x8B)},
!   {(char_u *)"darkgray",  TORGB(0xA9, 0xA9, 0xA9)},
!   {(char_u *)"darkgreen", TORGB(0x00, 0x64, 0x00)},
!   {(char_u *)"darkgrey",  TORGB(0xA9, 0xA9, 0xA9)},
!   {(char_u *)"darkmagenta",   TORGB(0x8B, 0x00, 0x8B)},
!   {(char_u *)"darkred",   TORGB(0x8B, 0x00, 0x00)},
!   {(char_u *)"darkyellow",TORGB(0x8B, 0x8B, 0x00)}, /* No X11 */
!   {(char_u *)"gray",  TORGB(0xBE, 0xBE, 0xBE)},
!   {(char_u *)"gray10",TORGB(0x1A, 0x1A, 0x1A)},
!   {(char_u *)"gray20",TORGB(0x33, 0x33, 0x33)},
!   {(char_u *)"gray30",TORGB(0x4D, 0x4D, 0x4D)},
!   {(char_u *)"gray40",TORGB(0x66, 0x66, 0x66)},
!   {(char_u *)"gray50",TORGB(0x7F, 0x7F, 0x7F)},
!   {(char_u *)"gray60",TORGB(0x99, 0x99, 0x99)},
!   {(char_u *)"gray70",TORGB(0xB3, 0xB3, 0xB3)},
!   {(char_u *)"gray80",TORGB(0xCC, 0xCC, 0xCC)},
!   {(char_u *)"gray90",TORGB(0xE5, 0xE5, 0xE5)},
!   {(char_u *)"green", TORGB(0x00, 0xFF, 0x00)},
!   {(char_u *)"grey",  TORGB(0xBE, 0xBE, 0xBE)},
!   {(char_u *)"grey10",TORGB(0x1A, 0x1A, 0x1A)},
!   {(char_u *)"grey20",TORGB(0x33, 0x33, 0x33)},
!   {(char_u *)"grey30",TORGB(0x4D, 0x4D, 0x4D)},
!   {(char_u *)"grey40",TORGB(0x66, 0x66, 0x66)},
!   {(char_u *)"grey50",TORGB(0x7F, 0x7F, 0x7F)},
!   {(char_u *)"grey60",TORGB(0x99, 0x99, 0x99)},
!   {(char_u *)"grey70",TORGB(0xB3, 0xB3, 0xB3)},
!   {(char_u *)"grey80",TORGB(0xCC, 0xCC, 0xCC)},
!   {(char_u *)"grey90",TORGB(0xE5, 0xE5, 0xE5)},
!   {(char_u *)"lightblue", TORGB(0xAD, 0xD8, 0xE6)},
!   {(char_u *)"lightcyan", TORGB(0xE0, 0xFF, 0xFF)},
!   {(char_u *)"lightgray", TORGB(0xD3, 0xD3, 0xD3)},
!   {(char_u *)"lightgreen",TORGB(0x90, 0xEE, 0x90)},
!   {(char_u *)"lightgrey", TORGB(0xD3, 0xD3, 0xD3)},
!   {(char_u *)"lightmagenta",  TORGB(0xFF, 0x8B, 0xFF)}, /* No X11 */
!   {(char_u *)"lightred",  TORGB(0xFF, 0x8B, 0x8B)}, /* No X11 */
!   {(char_u *)"lightyellow",   TORGB(0xFF, 0xFF, 0xE0)},
!   {(char_u *)"magenta",   TORGB(0xFF, 0x00, 0xFF)},
!   {(char_u *)"orange",TORGB(0xFF, 0xA5, 0x00)},
!   {(char_u *)"purple",TORGB(0xA0, 0x20, 0xF0)},
!   {(char_u *)"red",   TORGB(0xFF, 0x00, 0x00)},
!   {(char_u *)"seagreen",  TORGB(0x2E, 0x8B, 0x57)},
!   {(char_u *)"slateblue", TORGB(0x6A, 0x5A, 0xCD)},
!   {(char_u *)"violet",TORGB(0xEE, 0x82, 0xEE)},
!   {(char_u *)"white", TORGB(0xFF, 0xFF, 0xFF)},
!   {(char_u *)"yellow",TORGB(0xFF, 0xFF, 0x00)},
  };
  
  
  if (name[0] == '#' && STRLEN(name) == 7)
  {
/* Name is in "#rrggbb" format */
!   color = TORGB(((hex_digit(name[1]) << 4) + hex_digit(name[2])),
((hex_digit(name[3]) << 4) + hex_digit(name[4])),
((hex_digit(name[5]) << 4) + hex_digit(name[6])));
if (color > 0xff)
--- 6086,6148 
  };
  
  static struct rgbcolor_table_S rgb_table[] = {
!   {(char_u *)"black", RGB(0x00, 0x00, 0x00)},
!   {(char_u *)"blue",  RGB(0x00, 0x00, 0xFF)},
!   {(char_u *)"brown", RGB(0xA5, 0x2A, 0x2A)},
!

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Christian Brabandt

Hi Bram!

On Mi, 27 Apr 2016, Bram Moolenaar wrote:

> I noticed the travis build also failed with this error, but then passed
> later.  For me it always passes, thus it's hard to find out why it would
> sometimes fail.  It looks like the callback is invoked twice, but I
> don't know why/when that happens.  Any idea?

Thanks, restarting did work. I saw it also only once on my local 
machine. I started test_channel.vim in a loop and did run it for a 
while, but did not notice any problems. Smells like a race condition 
however.

Best,
Christian
-- 
Ein Dutzend verlogener Komplimente ist leichter zu ertragen als ein
einziger aufrichtiger Tadel.
-- Mark Twain (eigl. Samuel Langhorne Clemens)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Kazunobu Kuriyama

2016-04-28 0:42 GMT+09:00 Bram Moolenaar :

>
> Kazunobu Kuriyama wrote:
>
> > 2016-04-27 17:51 GMT+09:00 Bram Moolenaar :
> >
> > >
> > > Christian Brabandt wrote:
> > >
> > > > Am 2016-04-26 19:01, schrieb Bram Moolenaar:
> > > > > Patch 7.4.1789
> > > >
> > > > I think this patch broke the vim-win32-installer build
> > > >
> > > >   From test_channel.vim:
> > > > Found errors in Test_out_close_cb():
> > > > function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but
> got 2
> > > > function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but
> got 3
> > > > TEST FAILURE
> > > > NMAKE : fatal error U1077: 'if' : return code '0x1'
> > > > Stop.
> > > > Command exited with code 1
> > > >
> > > >
> > >
> https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous
> > >
> > > I noticed the travis build also failed with this error, but then passed
> > > later.  For me it always passes, thus it's hard to find out why it
> would
> > > sometimes fail.  It looks like the callback is invoked twice, but I
> > > don't know why/when that happens.  Any idea?
> > >
> >
> > On OS X, the same error happens occasionally.
> >
> > Since it didn't always happen, I had put it on probation and refrained
> from
> > accusing it of the failure. :)
> >
> > Having done 'make test' five or six times with ch_logfile of
> > test_channel.vim enabled, I finally caught it.
> >
> > Attached are the waring message of the failure (warning.txt) and
> > testdir/channellog when it happened.
> >
> > Hopefully, this could be helpful for you.
>
> Unfortunately the channellog is truncated before the interesting part.
> Perhaps you can start the log in the Test_out_close_cb function.
>

I added call

ch_log('Test_out_close_cb()')

just after test_channel.vim:1055, and the attached file is the result.

Does this contain the part you need?

>
> --
> If cars evolved at the same rate as computers have, they'd cost five euro,
> run for a year on a couple of liters of petrol, and explode once a day.
>
>  /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


channellog
Description: Binary data

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Bram Moolenaar


Kazunobu Kuriyama wrote:

> 2016-04-27 17:51 GMT+09:00 Bram Moolenaar :
> 
> >
> > Christian Brabandt wrote:
> >
> > > Am 2016-04-26 19:01, schrieb Bram Moolenaar:
> > > > Patch 7.4.1789
> > >
> > > I think this patch broke the vim-win32-installer build
> > >
> > >   From test_channel.vim:
> > > Found errors in Test_out_close_cb():
> > > function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
> > > function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3
> > > TEST FAILURE
> > > NMAKE : fatal error U1077: 'if' : return code '0x1'
> > > Stop.
> > > Command exited with code 1
> > >
> > >
> > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous
> >
> > I noticed the travis build also failed with this error, but then passed
> > later.  For me it always passes, thus it's hard to find out why it would
> > sometimes fail.  It looks like the callback is invoked twice, but I
> > don't know why/when that happens.  Any idea?
> >
> 
> On OS X, the same error happens occasionally.
> 
> Since it didn't always happen, I had put it on probation and refrained from
> accusing it of the failure. :)
> 
> Having done 'make test' five or six times with ch_logfile of
> test_channel.vim enabled, I finally caught it.
> 
> Attached are the waring message of the failure (warning.txt) and
> testdir/channellog when it happened.
> 
> Hopefully, this could be helpful for you.

Unfortunately the channellog is truncated before the interesting part.
Perhaps you can start the log in the Test_out_close_cb function.

-- 
If cars evolved at the same rate as computers have, they'd cost five euro, 
run for a year on a couple of liters of petrol, and explode once a day.

 /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Vim is unable to automatically detect my Python version (#419)

2016-04-27 Fir de Conversatie Jacky Liu

On Tuesday, April 26, 2016 at 4:29:07 PM UTC+8, Markus Meskanen wrote:
> While I don't expect Vim to become an easy-to-use text editor for beginners 
> or anything, the current Python support simply isn't enough for a standard 
> coder. Vim doesn't support multiple Python versions, so you have to compile 
> multiple versions of Vim. And every time you update your Python, you must 
> recompile Vim. Other editors simply do Python better.
> 
> 
> —
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub

-

You can have the full power of Python from within your Vim only if Vim and 
Python can run *in the same thread with the same memory space*, this can only 
be achieved by *embedding* Python into Vim, not invoking it.

The dynamic run-time solution you mentioned is awfully slow and inefficient. 
Can you imagine an application's UI starts its back-end as an external process 
and then use a pipe or socket to communicate with it later? Its awful. UI and 
the back-end should be within the same process. Emacs even try to do data 
translation between Python and Elisp with its Pymacs, again, its awful, 
hopeless. Vim should never do that.

I suppose Python itself doesn't have good support for multiple versions within 
the same environment, try creating a Py2 list inside Py3. You can build a 
py3-enabled Vim and run py2 as an external process, or vice versa. You can have 
both Vims on your system and choose between them each time accordingly, I 
suppose you won't definitely need one project of yours half in Py2 and half in 
Py3.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1770

2016-04-27 Fir de Conversatie Charles Campbell

Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>> Bram Moolenaar wrote:
>>> Patch 7.4.1770
>>> Problem:Cannot use true color in the terminal.
>>> Solution:   Add the 'guicolors' option. (Nikolai Pavlov)
>>> Files:  runtime/doc/options.txt, runtime/doc/term.txt,
>>> runtime/doc/various.txt, src/auto/configure, src/config.h.in,
>>> src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c,
>>> src/option.c, src/option.h, src/proto/term.pro, src/screen.c,
>>> src/structs.h, src/syntax.c, src/term.c, src/term.h,
>>> src/version.c, src/vim.h
>> One unwanted side effect that I've noticed so far: Ignore highlighting
>> is no longer ignored.
> What do you mean with "Ignore highlighting", what is used in the help
> file?  How can it be reproduced?
>
Hello:

Here's how to reproduce the problem: (after using bunzip2 and tar xf, of
course)

1. vim -u gcol.vimrc junk
   :so junksyn.vim

   As attached, gcol.vimrc uses the gcol option.  Note that the trailing
~123 does not get Ignore'd.

2. To see what it should have done: comment out the set gcol line in
gcol.vimrc and repeat.

Regards,
Chip Campbell

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


gcolprblm.tar.bz2
Description: BZip2 compressed data

Re: How to run a job asynchronously?

2016-04-27 Fir de Conversatie Andrew Stewart

> On 26 Apr 2016, at 8:38 pm, Bram Moolenaar  wrote:
> 
> You can now use ch_status() for that.  If it returns "open" or
> "buffered" there may be more to read.  When "closed" then it's done.
> 
> I have added this example in the help:
> 
>   func! CloseHandler(channel)
> while ch_status(a:channel) == 'buffered'
>   echomsg ch_read(a:channel)
> endwhile
>   endfunc
>   let job = job_start(command, {'close_cb': 'CloseHandler'})

Should the condition be `while ch_status(a:channel) == 'buffered' || 
ch_status(a:channel) == 'open'` as per the description?

I upgraded to 7.4.1795 and tried out the example as is.

I couldn't find the example in the help.

Every few callbacks the screen needed a `:redraw!` to:

- display the correct signs (my handler updates them)
- display the cursor in the correct position (getpos('.') showed the right 
coordinates but the cursor was displayed elsewhere).

I haven't been able to reproduce this consistently.  I tried adding a 
`redraw`/`redraw!` as the last line of my handler but it didn't make any 
difference.

Every few dozen callbacks `ch_read(a:channel)` threw an E906 error, though 
again I'm not able to reproduce it consistently.  Perhaps there is a race 
condition where the channel is closed between checking its status and reading 
from it?  I modified my handler to:

function! CloseHandler(channel)
  let output = ''
  try
while ch_status(a:channel) == 'buffered'
let line = ch_read(a:channel)
if line !=# 'DETACH'
  let output .= line."\n"
endif
  endwhile
  echom output
endfunction

...which seemed to work well, at least until Vim crashed:

Vim: Caught deadly signal SEGV
Vim(85664,0x7fff7a952000) malloc: *** error for object 0x7ff2106739e8: 
incorrect checksum for freed object - object was probably modified after being 
freed.
  *** set a breakpoint in 
malloc_error_break to debug

   Vim: Finished.
Vim: Double signal, exiting
Abort trap: 6

I don't know how to set a breakpoint in malloc_error_break so I wasn't able to 
debug this, sorry.  When it happened there was nothing unusual in the channel 
log.

I also implemented my job_start using an out_cb handler again instead of a 
close_cb handler.  The occasional-missing-callback problem has disappeared and 
it all worked perfectly.  Thanks!

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Kazunobu Kuriyama

2016-04-27 17:51 GMT+09:00 Bram Moolenaar :

>
> Christian Brabandt wrote:
>
> > Am 2016-04-26 19:01, schrieb Bram Moolenaar:
> > > Patch 7.4.1789
> >
> > I think this patch broke the vim-win32-installer build
> >
> >   From test_channel.vim:
> > Found errors in Test_out_close_cb():
> > function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
> > function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3
> > TEST FAILURE
> > NMAKE : fatal error U1077: 'if' : return code '0x1'
> > Stop.
> > Command exited with code 1
> >
> >
> https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous
>
> I noticed the travis build also failed with this error, but then passed
> later.  For me it always passes, thus it's hard to find out why it would
> sometimes fail.  It looks like the callback is invoked twice, but I
> don't know why/when that happens.  Any idea?
>

On OS X, the same error happens occasionally.

Since it didn't always happen, I had put it on probation and refrained from
accusing it of the failure. :)

Having done 'make test' five or six times with ch_logfile of
test_channel.vim enabled, I finally caught it.

Attached are the waring message of the failure (warning.txt) and
testdir/channellog when it happened.

Hopefully, this could be helpful for you.

Best regards,
Kazunobu Kuriyama

>
> --
> Why isn't there mouse-flavored cat food?
>
>  /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From test_channel.vim:
Executing Test_call()
Executing Test_channel_handler()
Executing Test_close_callback()
Executing Test_close_handle()
Executing Test_close_partial()
Executing Test_communicate()
Executing Test_connect_waittime()
Executing Test_exit_callback()
Executing Test_job_start_invalid()
Executing Test_nl_err_to_out_pipe()
Executing Test_nl_pipe()
Executing Test_nl_read_file()
Executing Test_nl_write_both_file()
Executing Test_nl_write_err_file()
Executing Test_nl_write_out_file()
Executing Test_open_delay()
Executing Test_open_fail()
Executing Test_out_cb()
Executing Test_out_close_cb()
Executing Test_partial_in_channel_cycle()
Executing Test_pipe_both_to_buffer()
Executing Test_pipe_err_to_buffer_name()
Executing Test_pipe_err_to_buffer_nr()
Executing Test_pipe_from_buffer_name()
Executing Test_pipe_from_buffer_nr()
Executing Test_pipe_io_one_buffer()
Executing Test_pipe_io_two_buffers()
Executing Test_pipe_null()
Executing Test_pipe_to_buffer_json()
Executing Test_pipe_to_buffer_name()
Executing Test_pipe_to_buffer_nr()
Executing Test_pipe_to_nameless_buffer()
Executing Test_raw_one_time_callback()
Executing Test_raw_pipe()
Executing Test_read_in_close_cb()
Executing Test_reuse_channel()
Executing Test_server_crash()
Executing Test_two_channels()
Executing Test_unlet_handle()
Executing Test_using_freed_memory()
Executing Test_zero_reply()
Executed 41 tests
1 FAILED:
Found errors in Test_out_close_cb():
function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3


From test_channel.vim:
Found errors in Test_out_close_cb():
function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3

Test results:


From test_channel.vim:
Found errors in Test_out_close_cb():
function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3
TEST FAILURE
make[1]: *** [report] Error 1
make: *** [check] Error 2


channellog
Description: Binary data

Re: Patch 7.4.1770

2016-04-27 Fir de Conversatie Bram Moolenaar


Charles Campbell wrote:

> Bram Moolenaar wrote:
> > Patch 7.4.1770
> > Problem:Cannot use true color in the terminal.
> > Solution:   Add the 'guicolors' option. (Nikolai Pavlov)
> > Files:  runtime/doc/options.txt, runtime/doc/term.txt,
> > runtime/doc/various.txt, src/auto/configure, src/config.h.in,
> > src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c,
> > src/option.c, src/option.h, src/proto/term.pro, src/screen.c,
> > src/structs.h, src/syntax.c, src/term.c, src/term.h,
> > src/version.c, src/vim.h
> 
> One unwanted side effect that I've noticed so far: Ignore highlighting
> is no longer ignored.

What do you mean with "Ignore highlighting", what is used in the help
file?  How can it be reproduced?

-- 
In Africa some of the native tribes have a custom of beating the ground
with clubs and uttering spine chilling cries.  Anthropologists call
this a form of primitive self-expression.  In America we call it golf.

 /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Bram Moolenaar


Christian Brabandt wrote:

> Am 2016-04-26 19:01, schrieb Bram Moolenaar:
> > Patch 7.4.1789
> 
> I think this patch broke the vim-win32-installer build
> 
>   From test_channel.vim:
> Found errors in Test_out_close_cb():
> function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
> function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3
> TEST FAILURE
> NMAKE : fatal error U1077: 'if' : return code '0x1'
> Stop.
> Command exited with code 1
> 
> https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous

I noticed the travis build also failed with this error, but then passed
later.  For me it always passes, thus it's hard to find out why it would
sometimes fail.  It looks like the callback is invoked twice, but I
don't know why/when that happens.  Any idea?

-- 
Why isn't there mouse-flavored cat food?

 /// Bram Moolenaar -- b...@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_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] 'guicolors' option name does not intuitive.

2016-04-27 Fir de Conversatie h_east

Hi Bram, Ken and list,

2016-4-25(Mon) 19:04:59 UTC+9 h_east:
> Hi Ken!
> 
> 2016-4-25(Mon) 18:58:05 UTC+9 Ken Takata:
> > Hi h_east,
> > 
> > 2016/4/25 Mon 6:51:36 UTC+9 h_east wrote:
> > > Hi Bram and List!
> > > 
> > > 2016-4-25(Mon) 5:03:24 UTC+9 Bram Moolenaar:
> > > > Hirohito Higashi wrote:
> > > > 
> > > > > I think that 'guicolors' option name does not intuitive.
> > > > > This option for terminal, but prefix is 'gui'
> > > > > I think it's unnatural.
> > > > > 
> > > > > I propose to rename option name to 'termtruecolor'.  (Short name is 
> > > > > 'ttc')
> > > > > How about this?
> > > > > 
> > > > > NOTE:
> > > > >   This has been first proposed by Ken Takada.
> > > > > 
> > > > > Patch attached.
> > > > > Please check this.
> > > > 
> > > > Yes, I was wondering what users think of when seeing 'guicolors'.  The
> > > > main thing it does is using the GUI colors for the terminal.  Whether
> > > > it's actually true colors depends on the terminal.
> > > > 
> > > > So, how about 'termguicolors'?
> > > > 
> > > > Ah, I see Nikolai also suggested this.
> > > 
> > > Yes, patch update.
> > > 
> > >   guicolors --> termguicolors
> > >   gcol --> tgc
> > >   termtruecolor --> termguicolors
> > >   FEAT_TERMTRUECOLOR --> FEAT_TERMGUICOLORS
> > 
> > I think it's also better to change function names.
> 
> Nice catch! Thanks.

I update a patch.
- Ready for 7.4.1795
- Merge Ken's patch
  https://groups.google.com/d/msg/vim_dev/q2LuLFueRbE/b848hy1jAgAJ

Please check this.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index 8310a68..e42116d 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -3477,18 +3477,6 @@ A jump table for the options with a short description can be found at |Q_op|.
 	This option cannot be set from a |modeline| or in the |sandbox|, for
 	security reasons.
 
-		*'guicolors'* *'gcol'*
-'guicolors' 'gcol'	boolean (default off)
-			global
-			{not in Vi}
-			{not available when compiled without the 
-			|+termtruecolor| feature}
-	When on, uses |highlight-guifg| and |highlight-guibg| attributes in 
-	the terminal (thus using 24-bit color). Requires a ISO-8613-3
-	compatible terminal.
-	If setting this option does not work (produces a colorless UI) 
-	reading |xterm-true-color| might help.
-
 			*'guicursor'* *'gcr'* *E545* *E546* *E548* *E549*
 'guicursor' 'gcr'	string	(default "n-v-c:block-Cursor/lCursor,
 	ve:ver35-Cursor,
@@ -7551,6 +7539,18 @@ A jump table for the options with a short description can be found at |Q_op|.
 		:set encoding=utf-8
 <	You need to do this when your system has no locale support for UTF-8.
 
+		*'termguicolors'* *'tgc'*
+'termguicolors' 'tgc'	boolean (default off)
+			global
+			{not in Vi}
+			{not available when compiled without the
+			|+termguicolors| feature}
+	When on, uses |highlight-guifg| and |highlight-guibg| attributes in
+	the terminal (thus using 24-bit color). Requires a ISO-8613-3
+	compatible terminal.
+	If setting this option does not work (produces a colorless UI)
+	reading |xterm-true-color| might help.
+
 		*'terse'* *'noterse'*
 'terse'			boolean	(default off)
 			global
diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
index 0ac5b41..69cf5f0 100644
--- a/runtime/doc/term.txt
+++ b/runtime/doc/term.txt
@@ -426,10 +426,10 @@ Vim has started, the escape sequences may not be recognized anymore.
 			*xterm-true-color*
 Vim supports using true colors in the terminal (taken from |highlight-guifg|
 and |highlight-guibg|), given that terminal supports this. To make this 
-work, 'guicolors' option needs to be set.
+work, 'termguicolors' option needs to be set.
 
-Sometimes setting 'guicolors' is not enough and one has to set the |t_8f| and
-|t_8b| options explicitly. Default values of these options are
+Sometimes setting 'termguicolors' is not enough and one has to set the |t_8f|
+and |t_8b| options explicitly. Default values of these options are
 `^[[38;2;%lu;%lu;%lum` and `^[[48;2;%lu;%lu;%lum` (replace `^[` with real
 escape) respectively, but it is only set when `$TERM` is `xterm`. Some
 terminals accept the same sequences, but with all semicolons replaced by
diff --git a/runtime/doc/various.txt b/runtime/doc/various.txt
index b73949f..8565a88 100644
--- a/runtime/doc/various.txt
+++ b/runtime/doc/various.txt
@@ -424,7 +424,7 @@ m  *+tcl*		Tcl interface |tcl|
 m  *+tcl/dyn*		Tcl interface |tcl-dynamic| |/dyn|
*+terminfo*		uses |terminfo| instead of termcap
 N

Re: Patch 7.4.1789

2016-04-27 Fir de Conversatie Christian Brabandt


Am 2016-04-26 19:01, schrieb Bram Moolenaar:

Patch 7.4.1789


I think this patch broke the vim-win32-installer build

 From test_channel.vim:
Found errors in Test_out_close_cb():
function RunTheTest[9]..Test_out_close_cb line 23: Expected 1 but got 2
function RunTheTest[9]..Test_out_close_cb line 24: Expected 2 but got 3
TEST FAILURE
NMAKE : fatal error U1077: 'if' : return code '0x1'
Stop.
Command exited with code 1

https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/94/job/ah9t0xb7hkh14ous

Best,
Christian

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows: After Patch 7.4.1792 colors completely wrong

2016-04-27 Fir de Conversatie Christian Brabandt


Am 2016-04-27 08:33, schrieb Kazunobu Kuriyama:

On Windows 2000 or later, there has already been a macro called RGB
[1], which conflicts with ours in term.c.

This caused a compiler warning on Windows as reported by John
Marriott.

Thus Patch 1795 renamed ours from RGB to TORGB to avoid the name
conflict.

Now we have wrong colors on Windows as reported by Christian J.
Robinson.

This is because, while our macro places RGB color intensities into a
32-bit integer in the order of 0x00RRGGBB, Windows' macro does it with
the partially reversed order 0x00BBGGRR [2], thus causing the glitch.

[1]
https://msdn.microsoft.com//library/windows/desktop/dd162937(v=vs.85).aspx
[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183449(v=vs.85).aspx


Yes and Ken has already provided a patch for this.

Best,
Christian

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows: After Patch 7.4.1792 colors completely wrong

2016-04-27 Fir de Conversatie Kazunobu Kuriyama

On Windows 2000 or later, there has already been a macro called RGB [1],
which conflicts with ours in term.c.

This caused a compiler warning on Windows as reported by John Marriott.

Thus Patch 1795 renamed ours from RGB to TORGB to avoid the name conflict.

Now we have wrong colors on Windows as reported by Christian J. Robinson.

This is because, while our macro places RGB color intensities into a 32-bit
integer in the order of 0x00RRGGBB, Windows' macro does it with the
partially reversed order 0x00BBGGRR [2], thus causing the glitch.

[1]
https://msdn.microsoft.com//library/windows/desktop/dd162937(v=vs.85).aspx
[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183449(v=vs.85).aspx

2016-04-27 15:15 GMT+09:00 Ken Takata :

> Hi,
>
> 2016/4/27 Wed 15:03:06 UTC+9 Marius Gedminas wrote:
> > On Tue, Apr 26, 2016 at 02:48:48PM -0600, Christian J. Robinson wrote:
> > >
> > > Something went wrong with this patch. Most of my colors are wrong.
> > >
> > > How it looks now:
> > > https://www.dropbox.com/s/q8wc4vzkg8r0uj2/vimwrongcolors.png?dl=0
> > >
> > > How it should look:
> > > https://www.dropbox.com/s/3of53y3qdiz1xcm/vimcorrectcolors.png?dl=0
> >
> > Does 7.4.1795 fix this?
>
> No, it doesn't.
>
> Regards,
> Ken Takata
>
> --
> --
> You received this message from the "vim_dev" 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_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows: After Patch 7.4.1792 colors completely wrong

2016-04-27 Fir de Conversatie Ken Takata

Hi,

2016/4/27 Wed 15:03:06 UTC+9 Marius Gedminas wrote:
> On Tue, Apr 26, 2016 at 02:48:48PM -0600, Christian J. Robinson wrote:
> > 
> > Something went wrong with this patch. Most of my colors are wrong.
> > 
> > How it looks now:
> > https://www.dropbox.com/s/q8wc4vzkg8r0uj2/vimwrongcolors.png?dl=0
> > 
> > How it should look:
> > https://www.dropbox.com/s/3of53y3qdiz1xcm/vimcorrectcolors.png?dl=0
> 
> Does 7.4.1795 fix this?

No, it doesn't.

Regards,
Ken Takata

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows: After Patch 7.4.1792 colors completely wrong

2016-04-27 Fir de Conversatie Marius Gedminas

On Tue, Apr 26, 2016 at 02:48:48PM -0600, Christian J. Robinson wrote:
> 
> Something went wrong with this patch. Most of my colors are wrong.
> 
> How it looks now:
> https://www.dropbox.com/s/q8wc4vzkg8r0uj2/vimwrongcolors.png?dl=0
> 
> How it should look:
> https://www.dropbox.com/s/3of53y3qdiz1xcm/vimcorrectcolors.png?dl=0

Does 7.4.1795 fix this?

Marius Gedminas
-- 
Just to be extra clear about this: yes, it is morally wrong for us to have
written RetchMail, and it is morally wrong for you to use it. But try it, it's
really fast!
-- http://alumnit.ca/wiki/index.php?page=RetchMail

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [vim/vim] Vim is unable to automatically detect my Python version (#419)

Re: Patch 7.4.1770

Re: Patch 7.4.1789

Re: Patch 7.4.1789

Re: Patch 7.4.1789

Re: Windows: After Patch 7.4.1792 colors completely wrong

Patch 7.4.1796

Re: Patch 7.4.1789

Re: Patch 7.4.1789

Re: Patch 7.4.1789

Re: [vim/vim] Vim is unable to automatically detect my Python version (#419)

Re: Patch 7.4.1770

Re: How to run a job asynchronously?

Re: Patch 7.4.1789

Re: Patch 7.4.1770

Re: Patch 7.4.1789

Re: [patch] 'guicolors' option name does not intuitive.

Re: Patch 7.4.1789

Re: Windows: After Patch 7.4.1792 colors completely wrong

Re: Windows: After Patch 7.4.1792 colors completely wrong

Re: Windows: After Patch 7.4.1792 colors completely wrong

Re: Windows: After Patch 7.4.1792 colors completely wrong

22 matches

Site Navigation

Mail list logo

Footer information