Re: [bug] read heap overflow in do_pending_operator()

[Dominique Pellé]

Dominique Pellé wrote:

> Hi
>
> Here is one more bug found by afl-fuzz in vim-7.4.2330
> an older:
>
> $ cat bug.vim
> new
> call append(0, [" a", "b"])
> norm kVdggViw
> bw!
> %d
>
> $ valgrind --num-callers=20 vim -u NONE -S bug.vim -c q 2> log
>
> $ cat log
> ==7787== Memcheck, a memory error detector
> ==7787== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==7787== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==7787== Command: vim -u NONE -S bug.vim -c q
> ==7787==
> ==7787== Invalid read of size 1
> ==7787==at 0x4D881C: do_pending_operator (normal.c:1700)
> ==7787==by 0x4E39F8: clip_get_selection (ops.c:6428)
> ==7787==by 0x59F800: clip_copy_selection (ui.c:544)
> ==7787==by 0x59F7A3: clip_auto_select (ui.c:614)
> ==7787==by 0x4D7E06: end_visual_mode (normal.c:3281)
> ==7787==by 0x465A6E: ex_operators (ex_docmd.c:9243)
> ==7787==by 0x45EC77: do_one_cmd (ex_docmd.c:2962)
> ==7787==by 0x45A9F2: do_cmdline (ex_docmd.c:1110)
> ==7787==by 0x458ADC: do_source (ex_cmds2.c:4097)
> ==7787==by 0x4582D3: cmd_source (ex_cmds2.c:3710)
> ==7787==by 0x45EC77: do_one_cmd (ex_docmd.c:2962)
> ==7787==by 0x45A9F2: do_cmdline (ex_docmd.c:1110)
> ==7787==by 0x5CEEEC: exe_commands (main.c:2896)
> ==7787==by 0x5CEEEC: vim_main2 (main.c:781)
> ==7787==by 0x5CD91C: main (main.c:415)
> ==7787==  Address 0x76b0b80 is 0 bytes after a block of size 4,096 alloc'd
> ==7787==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==7787==by 0x4C81D7: lalloc (misc2.c:942)
> ==7787==by 0x5D127E: mf_alloc_bhdr (memfile.c:907)
> ==7787==by 0x5D127E: mf_new (memfile.c:381)
> ==7787==by 0x4AC6F1: ml_new_data (memline.c:3513)
> ==7787==by 0x4AC6F1: ml_open (memline.c:400)
> ==7787==by 0x406373: open_buffer (buffer.c:160)
> ==7787==by 0x5CEA44: create_windows (main.c:2668)
> ==7787==by 0x5CEA44: vim_main2 (main.c:704)
> ==7787==by 0x5CD91C: main (main.c:415)
>
> Regards
> Dominique


Patch 7.4.2347 fixed this bug.  Good.
Bug was still happening up to patch 7.4.2346.

Thanks!
Dominique

-- 
-- 
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: callback is not called when job exit immediately.

[mattn]

okay, will look into it soon.

-- 
-- 
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.2347

[Bram Moolenaar]

Patch 7.4.2347
Problem:Crash when closing a buffer while Visual mode is active.
(Dominique Pelle)
Solution:   Adjust the position before computing the number of lines.
When closing the current buffer stop Visual mode.
Files:  src/buffer.c, src/normal.c, src/testdir/test_normal.vim


*** ../vim-7.4.2346/src/buffer.c2016-09-04 23:41:36.973433429 +0200
--- src/buffer.c2016-09-08 23:31:18.260925052 +0200
***
*** 578,583 
--- 578,588 
  if (buf->b_ffname == NULL)
del_buf = TRUE;
  
+ /* When closing the current buffer stop Visual mode before freeing
+  * anything. */
+ if (buf == curbuf)
+   end_visual_mode();
+ 
  /*
   * Free all things allocated for this buffer.
   * Also calls the "BufDelete" autocommands when del_buf is TRUE.
***
*** 1379,1384 
--- 1384,1393 
}
}
  
+   /* When closing the current buffer stop Visual mode. */
+   if (buf == curbuf)
+   end_visual_mode();
+ 
/*
 * If deleting the last (listed) buffer, make it empty.
 * The last (listed) buffer cannot be unloaded.
*** ../vim-7.4.2346/src/normal.c2016-09-04 20:34:55.763537404 +0200
--- src/normal.c2016-09-08 23:35:06.131082221 +0200
***
*** 1609,1614 
--- 1609,1616 
oap->start = curwin->w_cursor;
}
  
+   /* Just in case lines were deleted that make the position invalid. */
+   check_pos(curwin->w_buffer, >end);
oap->line_count = oap->end.lnum - oap->start.lnum + 1;
  
  #ifdef FEAT_VIRTUALEDIT
***
*** 9451,9460 
  #ifdef FEAT_MBYTE
  /* prevent from moving onto a trail byte */
  if (has_mbyte)
- {
-   check_pos(curwin->w_buffer, >end);
mb_adjustpos(curwin->w_buffer, >end);
- }
  #endif
  
  getvvcol(curwin, &(oap->start), >start_vcol, NULL, >end_vcol);
--- 9453,9459 
*** ../vim-7.4.2346/src/testdir/test_normal.vim 2016-09-06 20:37:38.206149358 
+0200
--- src/testdir/test_normal.vim 2016-09-08 23:23:15.304888249 +0200
***
*** 1998,2000 
--- 1998,2014 
" clean up
bw!
  endfu
+ 
+ func! Test_normal47_visual_buf_wipe()
+   " This was causing a crash or ml_get error.
+   enew!
+   call setline(1,'xxx')
+   normal $
+   new
+   call setline(1, range(1,2))
+   2
+   exe "norm \$"
+   bw!
+   norm yp
+   set nomodified
+ endfu
*** ../vim-7.4.2346/src/version.c   2016-09-08 22:10:04.753618339 +0200
--- src/version.c   2016-09-08 23:34:18.543465683 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2347,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
205. You're constantly yelling at your spouse, family, roommate, whatever,
 for using the phone for stupid things...like talking.

 /// 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] fixed crash: do_put() calls STRLEN with NULL pointer

[Bram Moolenaar]

Dominique wrote:

> The attached bug.vim script causes a crash in Vim-7.4.2343:
> 
> $ vim -u NONE -N -S bug.vim
> Vim: Caught deadly signal SEGV
> Segmentation fault (core dumped)
> 
> The crash was introduced by recent patch Vim-7.4.2326:
> 
> ===
> commit d5824ce1b5491df7d2eb0b66189d366fa67b4585
> Author: Bram Moolenaar 
> Date:   Sun Sep 4 20:35:01 2016 +0200
> 
> patch 7.4.2326
> Problem:Illegal memory access when Visual selection starts in invalid
> position. (Dominique Pelle)
> Solution:   Correct position when needed.
> ===
> 
> However, prior to this patch, it was barely better anyway
> because vim-7.4.2325 and older were giving ml_get internal
> errors on that same bug.vim script:
> 
> $ vim -u NONE -N -S bug.vim
> Error detected while processing /tmp/vim/src/c.vim:
> line6:
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> E315: ml_get: invalid lnum: 2
> Press ENTER or type command to continue

I cannot reproduce the problem.  I also see nothing in valgrid.

I assume the line "normal <11>" should be "normal <16>", where <16> is
CTRL-V.  This starts Visual block mode.  CTRL-Q does not work here.

But then the "bw!" command does not appear to work.  The trailing CTRL-V
consumes it.  Hmm, it gets closer when I use:

new
call setline(1,range(1,2))
2
exe "norm \"
bw!
norm yp

But still no error.  In a debugger I can see it never yanks, because the
region is empty.  OK, let's add some text before splitting:

call setline(1,'xxx')
normal $
new
call setline(1,range(1,2))
2
exe "norm \$"
bw!
norm yp

That triggers the crash.

I think we should check the operator end position before the first time
line_count is computed, thus much earlier than where it was before.
And also when use_mbyte is false.

But really, leaving Visual mode active when closing the buffer is not
good.  Let's just stop it.


-- 
hundred-and-one symptoms of being an internet addict:
204. You're being audited because you mailed your tax return to the IRC.

 /// 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.2346

[Bram Moolenaar]

Patch 7.4.2346
Problem:Autocommand test fails when run directly, passes when run as part
of test_alot.
Solution:   Add command to make the cursor move.  Close a tab page.
Files:  src/testdir/test_autocmd.vim


*** ../vim-7.4.2345/src/testdir/test_autocmd.vim2016-09-06 
22:15:04.753077591 +0200
--- src/testdir/test_autocmd.vim2016-09-08 22:06:01.039674235 +0200
***
*** 13,18 
--- 13,21 
endfunc
  
func Test_cursorhold_insert()
+ " Need to move the cursor.
+ call feedkeys("ggG", "xt")
+ 
  let g:triggered = 0
  au CursorHoldI * let g:triggered += 1
  set updatetime=20
***
*** 93,98 
--- 96,102 
augroup END
call setline(1, ['a', 'b', 'c'])
edit! a.txt
+   tabclose
  endfunc
  
  " SEGV occurs in older versions.  (At least 7.4.2321 or older)
*** ../vim-7.4.2345/src/version.c   2016-09-08 20:28:42.196597755 +0200
--- src/version.c   2016-09-08 22:08:51.410236915 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2346,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
203. You're an active member of more than 20 newsgroups.

 /// 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] Add columnspace option (#1011)

['Andy Wokula' via vim_dev]

Am 08.09.2016 um 16:41 schrieb Christian Brabandt (Vim Github Repository):

what problem does this solve?


Probably the same problem partly solved with 'linespace'.

--
Andy

--
--
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: some improvements for feedkeys()

['Andy Wokula' via vim_dev]

Am 06.09.2016 um 20:42 schrieb Christian Brabandt:

Bram,
if in a test we do this:
 call feedkeys('d1', 'x!')
 call feedkeys('2l', 'x')

Vim will stay in the first feedkeys() call and wait for input.

I'd like to have feedkeys() return after CursorHold triggered,


You say Vim waits for input ... how does it trigger CursorHold then?


but have it not finished/aborted the first call, so that in the end
this command is executed:
d12l where a cursorhold command triggered after the 1


except you don't get a CursorHold ... (?)


Does that sound possible or should we not worry about those special case
(see normal.c:602)


--
Andy

--
--
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] Static analysis report (#1049)

[Dominique Pellé]

Bram Moolenaar  wrote:

> This is not in a useful format.

The format looks OK to me.  Just unzip the file and open the index.html
file in a browser. I have not had the time to look at the reports yet though,
but I will look later.

Dominique

-- 
-- 
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: callback is not called when job exit immediately.

[Bram Moolenaar]

I wrote:

> Yasuhiro Matsumoto wrote:
> 
> > behavior is I expected. but tests are failing with my patch.
> > 
> > From test_channel.vim:
> > Found errors in Test_out_close_cb():
> > function RunTheTest[9]..Test_out_close_cb line 26: Expected 2 but got 0
> > Found errors in Test_pipe_to_buffer_name():
> > function 
> > RunTheTest[9]..Test_pipe_to_buffer_name[1]..Run_test_pipe_to_buffer line 
> > 35: Expected 'yes' but got 'no'
> > Found errors in Test_pipe_to_buffer_name_nomod():
> > Caught exception in Test_pipe_to_buffer_name_nomod(): Vim(sleep):E117: 
> > Unknown function: CloseHandler @ function 
> > RunTheTest[9]..Test_pipe_to_buffer_name_nomod[1]..Run_test_pipe_to_buffer[28]..WaitFor,
> >  line 20
> > Found errors in Test_read_in_close_cb():
> > function RunTheTest[9]..Test_read_in_close_cb line 15: Expected 'quit' but 
> > got ''
> 
> Maybe PeekNamedPipe() is not the right function to use?
> How about doing a non-blocking read?

Any progress on this?  I really want to make the Vim 8 release.

-- 
$ echo pizza > /dev/oven

 /// 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.2340

[Bram Moolenaar]

Ken Takata wrote:

> 2016/9/7 Wed 17:45:36 UTC+9 Bram Moolenaar wrote:
> > Ken Takata wrote:
> > 
> > > 2016/9/7 Wed 5:07:10 UTC+9 Bram Moolenaar wrote:
> > > > Patch 7.4.2340
> > > > Problem:MS-Windows: Building with Ruby uses old version.
> > > > Solution:   Update to 2.2.X. Use clearer name for the API version. (Ken
> > > > Takata)
> > > > Files:  Makefile, src/INSTALLpc.txt, src/Make_cyg_ming.mak,
> > > > src/Make_mvc.mak, src/bigvim.bat
> > > 
> > > Sorry, I found a mistake in this patch. The following line (L370) in
> > > Make_cyg_ming.mak:
> > > 
> > > > ! RUBY_API_VER_LONG = $(RUBY_API_VER_LONG)
> > > 
> > > should have been:
> > > 
> > > RUBY_API_VER_LONG = $(RUBY_VER_LONG)
> > > 
> > > Make_mvc.mak doesn't have this mistake.
> > 
> > I'll change that.
> > 
> > > BTW, some of the default interfaces version specified in Make_mvc.mak and
> > > Make_cyg_ming.mak are very old:
> > > 
> > > * Lua 5.1
> > >   Not so old. But the latest is 5.3.
> > > * MzScheme 2.05
> > >   The latest is Racket 6.6. Vim-win32-installer uses 6.4.
> > > * Perl 5.6
> > >   The latest is 5.24.
> > > * Python 2.2
> > >   The latest is 2.7.
> > > * Python3 3.1
> > >   The latest is 3.5.
> > > * Ruby 2.2
> > >   The latest is 2.3, but 2.2 would be okay.
> > > * Tcl 8.3
> > >   The latest is 8.6.
> > > 
> > > Shouldn't we update them?
> > 
> > Using the latest stable version is good.  I tried to build with them for
> > the distributed self-installing exe.  Managed to make Ruby 2.2 work.
> > Don't have the version numbers at hand.
> 
> Those versions are all stable, I think.
> Attached patch updates the default interface versions. (except Ruby.)

Thanks.

-- 
hundred-and-one symptoms of being an internet addict:
197. Your desk collapses under the weight of your computer peripherals.

 /// 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: [doc][patch] trivial fix

[Bram Moolenaar]

Ken Takata wrote:

> Here is a trivial fix for the document:
> 
> --- a/runtime/doc/version8.txt
> +++ b/runtime/doc/version8.txt
> @@ -6109,7 +6109,7 @@ Files:  src/eval.c
>  
>  Patch 7.4.951
>  Problem:Sorting number strings does not work as expected. (Luc Hermitte)
> -Solution:   Add the 'N" argument to sort()
> +Solution:   Add the "N" argument to sort()
>  Files:  src/eval.c, runtime/doc/eval.txt, src/testdir/test_alot.vim,
>  src/testdir/test_sort.vim, src/testdir/Makefile

Thanks.

-- 
Some of the well known MS-Windows errors:
ETIME   Wrong time, wait a little while
ECRASH  Try again...
EDETECT Unable to detect errors
EOVER   You lost!  Play another game?
ENOCLUE Eh, what did you want?

 /// 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.2345

[Bram Moolenaar]

Patch 7.4.2345 (after 7.4.2340)
Problem:For MinGW RUBY_API_VER_LONG isn't set correctly.  Many default
version numbers are outdated.
Solution:   Set RUBY_API_VER_LONG to RUBY_VER_LONG. Use latest stable releases
for defaults. (Ken Takata)
Files:  src/Make_cyg_ming.mak, src/Make_mvc.mak


*** ../vim-7.4.2344/src/Make_cyg_ming.mak   2016-09-06 22:06:31.321534161 
+0200
--- src/Make_cyg_ming.mak   2016-09-08 20:25:34.566137227 +0200
***
*** 156,165 
  # Perl interface:
  #   PERL=[Path to Perl directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_PERL=yes (to load the Perl DLL dynamically)
! #   PERL_VER=[Perl version, eg 56, 58, 510] (default is 56)
  ifdef PERL
  ifndef PERL_VER
! PERL_VER=56
  endif
  ifndef DYNAMIC_PERL
  DYNAMIC_PERL=yes
--- 156,165 
  # Perl interface:
  #   PERL=[Path to Perl directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_PERL=yes (to load the Perl DLL dynamically)
! #   PERL_VER=[Perl version, eg 56, 58, 510] (default is 524)
  ifdef PERL
  ifndef PERL_VER
! PERL_VER=524
  endif
  ifndef DYNAMIC_PERL
  DYNAMIC_PERL=yes
***
*** 188,201 
  # Lua interface:
  #   LUA=[Path to Lua directory] (Set inside Make_cyg.mak or Make_ming.mak)
  #   DYNAMIC_LUA=yes (to load the Lua DLL dynamically)
! #   LUA_VER=[Lua version, eg 51, 52] (default is 51)
  ifdef LUA
  ifndef DYNAMIC_LUA
  DYNAMIC_LUA=yes
  endif
  
  ifndef LUA_VER
! LUA_VER=51
  endif
  
  ifeq (no,$(DYNAMIC_LUA))
--- 188,201 
  # Lua interface:
  #   LUA=[Path to Lua directory] (Set inside Make_cyg.mak or Make_ming.mak)
  #   DYNAMIC_LUA=yes (to load the Lua DLL dynamically)
! #   LUA_VER=[Lua version, eg 51, 52] (default is 53)
  ifdef LUA
  ifndef DYNAMIC_LUA
  DYNAMIC_LUA=yes
  endif
  
  ifndef LUA_VER
! LUA_VER=53
  endif
  
  ifeq (no,$(DYNAMIC_LUA))
***
*** 207,213 
  # MzScheme interface:
  #   MZSCHEME=[Path to MzScheme directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_MZSCHEME=yes (to load the MzScheme DLL dynamically)
! #   MZSCHEME_VER=[MzScheme version] (default is 205_000)
  #   MZSCHEME_DEBUG=no
  ifdef MZSCHEME
  ifndef DYNAMIC_MZSCHEME
--- 207,213 
  # MzScheme interface:
  #   MZSCHEME=[Path to MzScheme directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_MZSCHEME=yes (to load the MzScheme DLL dynamically)
! #   MZSCHEME_VER=[MzScheme version] (default is 3m_a0solc (6.6))
  #   MZSCHEME_DEBUG=no
  ifdef MZSCHEME
  ifndef DYNAMIC_MZSCHEME
***
*** 215,221 
  endif
  
  ifndef MZSCHEME_VER
! MZSCHEME_VER=205_000
  endif
  
  # for version 4.x we need to generate byte-code for Scheme base
--- 215,221 
  endif
  
  ifndef MZSCHEME_VER
! MZSCHEME_VER=3m_a0solc
  endif
  
  # for version 4.x we need to generate byte-code for Scheme base
***
*** 263,269 
  # Python interface:
  #   PYTHON=[Path to Python directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_PYTHON=yes (to load the Python DLL dynamically)
! #   PYTHON_VER=[Python version, eg 22, 23, ..., 27] (default is 22)
  ifdef PYTHON
  ifndef DYNAMIC_PYTHON
  DYNAMIC_PYTHON=yes
--- 263,269 
  # Python interface:
  #   PYTHON=[Path to Python directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_PYTHON=yes (to load the Python DLL dynamically)
! #   PYTHON_VER=[Python version, eg 22, 23, ..., 27] (default is 27)
  ifdef PYTHON
  ifndef DYNAMIC_PYTHON
  DYNAMIC_PYTHON=yes
***
*** 296,309 
  # Python3 interface:
  #   PYTHON3=[Path to Python3 directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_PYTHON3=yes (to load the Python3 DLL dynamically)
! #   PYTHON3_VER=[Python3 version, eg 31, 32] (default is 31)
  ifdef PYTHON3
  ifndef DYNAMIC_PYTHON3
  DYNAMIC_PYTHON3=yes
  endif
  
  ifndef PYTHON3_VER
! PYTHON3_VER=31
  endif
  ifndef DYNAMIC_PYTHON3_DLL
  DYNAMIC_PYTHON3_DLL=python$(PYTHON3_VER).dll
--- 296,309 
  # Python3 interface:
  #   PYTHON3=[Path to Python3 directory] (Set inside Make_cyg.mak or 
Make_ming.mak)
  #   DYNAMIC_PYTHON3=yes (to load the Python3 DLL dynamically)
! #   PYTHON3_VER=[Python3 version, eg 31, 32] (default is 35)
  ifdef PYTHON3
  ifndef DYNAMIC_PYTHON3
  DYNAMIC_PYTHON3=yes
  endif
  
  ifndef PYTHON3_VER
! PYTHON3_VER=35
  endif
  ifndef DYNAMIC_PYTHON3_DLL
  DYNAMIC_PYTHON3_DLL=python$(PYTHON3_VER).dll
***
*** 328,345 
  # TCL interface:
  #   TCL=[Path to TCL directory] (Set inside Make_cyg.mak or Make_ming.mak)
  #   DYNAMIC_TCL=yes (to load the TCL DLL dynamically)
! #   TCL_VER=[TCL version, eg 83, 84] (default is 83)
! #   TCL_VER_LONG=[Tcl version, eg 8.3] (default is 8.3)
  # You must set TCL_VER_LONG when you set TCL_VER.
  ifdef TCL
  ifndef 

Re: [patch] :make doesn't support encoding conversion

[Ken Takata]

Hi,

2016/9/7 Wed 3:08:50 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2016/8/23 Tue 20:00:50 UTC+9 Ken Takata wrote:
> > > Hi Bram,
> > > 
> > > 2016/8/22 Mon 2:29:28 UTC+9 Bram Moolenaar wrote:
> > > > Ken Takata wrote:
> > > > 
> > > > > > > > > I wrote a patch for the following todo item:
> > > > > > > > > 
> > > > > > > > > > Win32: When running ":make" and 'encoding' differs from the 
> > > > > > > > > > system locale, the
> > > > > > > > > > output should be converted.  Esp. when 'encoding' is 
> > > > > > > > > > "utf-8". (Yongwei Wu)
> > > > > > > > > > Should we use 'termencoding' for this?
> > > > > > > > > 
> > > > > > > > > I think using 'termencoding' for this is not so good.  
> > > > > > > > > Normally
> > > > > > > > > the encoding of a command output is the same as the encoding 
> > > > > > > > > of
> > > > > > > > > the terminal, but not always the same.  I hear that some 
> > > > > > > > > commands
> > > > > > > > > on Windows use utf-8 instead of the current codepage.  So I 
> > > > > > > > > added
> > > > > > > > > a new option 'cmdencoding' ('cenc').
> > > > > > > > > What do you think of this?
> > > > > > > > 
> > > > > > > > Seems reasonable.  It's not nice that it's yet another option.  
> > > > > > > > But in
> > > > > > > > case you know the compiler output is in a certain encoding it's 
> > > > > > > > the only
> > > > > > > > way to make it work.
> > > > > > > > 
> > > > > > > > Why they "char" value?  It's using the system locale, wouldn't 
> > > > > > > > "system"
> > > > > > > > be better?  Hmm, I don't see where "char" is recognized.
> > > > > > > 
> > > > > > > At least, GNU libiconv supports "char".
> > > > > > > 
> > > > > > > See: https://www.gnu.org/software/libiconv/
> > > > > > > | Locale dependent, in terms of `char' or `wchar_t' (with machine 
> > > > > > > dependent
> > > > > > > | endianness and alignment, and with OS and locale dependent 
> > > > > > > semantics)
> > > > > > > | char, wchar_t
> > > > > > > | The empty encoding name "" is equivalent to "char": it 
> > > > > > > denotes the locale
> > > > > > > | dependent character encoding.
> > > > > > > 
> > > > > > > I don't know about other iconv implementations.
> > > > > > 
> > > > > > I found a few, but they all say that the name supported are system
> > > > > > dependent.  Perhaps someone can dig deeper?
> > > > > 
> > > > > I hear that the "char" encoding would be a GNU extension. So the 
> > > > > description
> > > > > in options.txt would be:
> > > > > 
> > > > >   This would be mostly useful when you use MS-Windows and set 
> > > > > 'encoding'
> > > > >   to "utf-8".  If GNU libiconv is available, setting 
> > > > > 'cmdencoding' to
> > > > >   "char" has the same effect as setting to the system locale 
> > > > > encoding.
> > > > >   Example: >
> > > > >   :set encoding=utf-8
> > > > >   :set cmdencoding=char   " system locale is used
> > > > > 
> > > > > On Japanese Windows, `set cenc=char` has the same effect as `set 
> > > > > cenc=cp932`.
> > > > > (I suppose the Vim 8.0 win32 installer will contain GNU libiconv.)
> > > > 
> > > > Looking at this patch, I think it also applies the conversion to
> > > > ":cbuffer".  That should not happen.  Also ":cexpr".
> > > 
> > > No, the conversion will not be applied to `:cbuffer` and `:cexpr`.
> > > As I wrote in the help, it will be applied to:
> > >   `:make`, `:lmake`, `:grep`, `:lgrep`, `:grepadd`, `:lgrepadd`,
> > >   `:cfile`, `:cgetfile`, `:caddfile`, `:lfile`, `:lgetfile`, and
> > >   `:laddfile`.
> > > (Oh, I didn't mention 'cenc' in each of them, only in `:make` and 
> > > `:lmake`.)
> > > 
> > > My patch only adds the conversion to the function qf_get_next_file_line()
> > > which is used only when reading from a file. (Note that `:make` and 
> > > `:grep`
> > > also use a file.)
> > > Hm, is it confusing that 'cmdencoding' also applies to `:[cl].*file`?
> > > 
> > > `:cbuffer` calls qf_get_next_buf_line(), I think.
> > > 
> > > 
> > > > In general, whether the conversion is needed depends on the command
> > > > used.  E.g. for :grep and :make it might be different.  Not sure how to
> > > > deal with that.
> > > 
> > > Do you mean `:grep` and `:make` should have different encoding options?
> > > Maybe a user can create wrapper commands which set 'cenc' before executing
> > > `:grep` or `:make`.
> > > Of course, it would be nice if Vim supports it natively, but I have no 
> > > idea
> > > how to implement it.
> > 
> > I'm thinking this issue again.
> > Maybe we can do this by adding an parameter for encoding to qf_init() in
> > quickfix.c. I think we can use three options instead of 'cenc':
> > 
> > 1. 'makeencoding', 'menc':
> >Option for `:make` and `:lmake`.
> > 2. 'grepencoding', 'genc':
> >Option for `:grep`, `:grepadd`, `:lgrep` and `:lgrepadd`.
> > 3. 'errfileencoding', 'eenc':
> >Option for `:cfile`, `:cgetfile`, `:caddfile`, `:lfile`, `:lgetfile`,
> >and 

Re: Patch 7.4.2340

[Ken Takata]

Hi Bram,

2016/9/7 Wed 17:45:36 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2016/9/7 Wed 5:07:10 UTC+9 Bram Moolenaar wrote:
> > > Patch 7.4.2340
> > > Problem:MS-Windows: Building with Ruby uses old version.
> > > Solution:   Update to 2.2.X. Use clearer name for the API version. (Ken
> > > Takata)
> > > Files:  Makefile, src/INSTALLpc.txt, src/Make_cyg_ming.mak,
> > > src/Make_mvc.mak, src/bigvim.bat
> > 
> > Sorry, I found a mistake in this patch. The following line (L370) in
> > Make_cyg_ming.mak:
> > 
> > > ! RUBY_API_VER_LONG = $(RUBY_API_VER_LONG)
> > 
> > should have been:
> > 
> > RUBY_API_VER_LONG = $(RUBY_VER_LONG)
> > 
> > Make_mvc.mak doesn't have this mistake.
> 
> I'll change that.
> 
> > BTW, some of the default interfaces version specified in Make_mvc.mak and
> > Make_cyg_ming.mak are very old:
> > 
> > * Lua 5.1
> >   Not so old. But the latest is 5.3.
> > * MzScheme 2.05
> >   The latest is Racket 6.6. Vim-win32-installer uses 6.4.
> > * Perl 5.6
> >   The latest is 5.24.
> > * Python 2.2
> >   The latest is 2.7.
> > * Python3 3.1
> >   The latest is 3.5.
> > * Ruby 2.2
> >   The latest is 2.3, but 2.2 would be okay.
> > * Tcl 8.3
> >   The latest is 8.6.
> > 
> > Shouldn't we update them?
> 
> Using the latest stable version is good.  I tried to build with them for
> the distributed self-installing exe.  Managed to make Ruby 2.2 work.
> Don't have the version numbers at hand.

Those versions are all stable, I think.
Attached patch updates the default interface versions. (except Ruby.)

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.
# HG changeset patch
# Parent  57f4e4f7840802cfb41c02c0dc255ba535ad4d9f

diff --git a/src/Make_cyg_ming.mak b/src/Make_cyg_ming.mak
--- a/src/Make_cyg_ming.mak
+++ b/src/Make_cyg_ming.mak
@@ -156,10 +156,10 @@ endif
 #	Perl interface:
 #	  PERL=[Path to Perl directory] (Set inside Make_cyg.mak or Make_ming.mak)
 #	  DYNAMIC_PERL=yes (to load the Perl DLL dynamically)
-#	  PERL_VER=[Perl version, eg 56, 58, 510] (default is 56)
+#	  PERL_VER=[Perl version, eg 56, 58, 510] (default is 524)
 ifdef PERL
 ifndef PERL_VER
-PERL_VER=56
+PERL_VER=524
 endif
 ifndef DYNAMIC_PERL
 DYNAMIC_PERL=yes
@@ -188,14 +188,14 @@ endif
 #	Lua interface:
 #	  LUA=[Path to Lua directory] (Set inside Make_cyg.mak or Make_ming.mak)
 #	  DYNAMIC_LUA=yes (to load the Lua DLL dynamically)
-#	  LUA_VER=[Lua version, eg 51, 52] (default is 51)
+#	  LUA_VER=[Lua version, eg 51, 52] (default is 53)
 ifdef LUA
 ifndef DYNAMIC_LUA
 DYNAMIC_LUA=yes
 endif
 
 ifndef LUA_VER
-LUA_VER=51
+LUA_VER=53
 endif
 
 ifeq (no,$(DYNAMIC_LUA))
@@ -207,7 +207,7 @@ endif
 #	MzScheme interface:
 #	  MZSCHEME=[Path to MzScheme directory] (Set inside Make_cyg.mak or Make_ming.mak)
 #	  DYNAMIC_MZSCHEME=yes (to load the MzScheme DLL dynamically)
-#	  MZSCHEME_VER=[MzScheme version] (default is 205_000)
+#	  MZSCHEME_VER=[MzScheme version] (default is 3m_a0solc (6.6))
 #	  MZSCHEME_DEBUG=no
 ifdef MZSCHEME
 ifndef DYNAMIC_MZSCHEME
@@ -215,7 +215,7 @@ DYNAMIC_MZSCHEME=yes
 endif
 
 ifndef MZSCHEME_VER
-MZSCHEME_VER=205_000
+MZSCHEME_VER=3m_a0solc
 endif
 
 # for version 4.x we need to generate byte-code for Scheme base
@@ -263,7 +263,7 @@ endif
 #	Python interface:
 #	  PYTHON=[Path to Python directory] (Set inside Make_cyg.mak or Make_ming.mak)
 #	  DYNAMIC_PYTHON=yes (to load the Python DLL dynamically)
-#	  PYTHON_VER=[Python version, eg 22, 23, ..., 27] (default is 22)
+#	  PYTHON_VER=[Python version, eg 22, 23, ..., 27] (default is 27)
 ifdef PYTHON
 ifndef DYNAMIC_PYTHON
 DYNAMIC_PYTHON=yes
@@ -296,14 +296,14 @@ endif
 #	Python3 interface:
 #	  PYTHON3=[Path to Python3 directory] (Set inside Make_cyg.mak or Make_ming.mak)
 #	  DYNAMIC_PYTHON3=yes (to load the Python3 DLL dynamically)
-#	  PYTHON3_VER=[Python3 version, eg 31, 32] (default is 31)
+#	  PYTHON3_VER=[Python3 version, eg 31, 32] (default is 35)
 ifdef PYTHON3
 ifndef DYNAMIC_PYTHON3
 DYNAMIC_PYTHON3=yes
 endif
 
 ifndef PYTHON3_VER
-PYTHON3_VER=31
+PYTHON3_VER=35
 endif
 ifndef DYNAMIC_PYTHON3_DLL
 DYNAMIC_PYTHON3_DLL=python$(PYTHON3_VER).dll
@@ -328,18 +328,18 @@ endif
 #	TCL interface:
 #	  TCL=[Path to TCL directory] (Set inside Make_cyg.mak or Make_ming.mak)
 #	  DYNAMIC_TCL=yes (to load the TCL DLL dynamically)
-#	  TCL_VER=[TCL version, eg 83, 84] (default is 83)
-#	  TCL_VER_LONG=[Tcl version, eg 8.3] (default is 8.3)
+#	  TCL_VER=[TCL version, eg 83, 84] (default is 86)
+#	  TCL_VER_LONG=[Tcl version, eg 8.3] (default is 8.6)
 #	You must set TCL_VER_LONG 

[doc][patch] trivial fix

[Ken Takata]

Hi Bram,

Here is a trivial fix for the document:

--- a/runtime/doc/version8.txt
+++ b/runtime/doc/version8.txt
@@ -6109,7 +6109,7 @@ Files:  src/eval.c
 
 Patch 7.4.951
 Problem:Sorting number strings does not work as expected. (Luc Hermitte)
-Solution:   Add the 'N" argument to sort()
+Solution:   Add the "N" argument to sort()
 Files:  src/eval.c, runtime/doc/eval.txt, src/testdir/test_alot.vim,
 src/testdir/test_sort.vim, src/testdir/Makefile
 

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: YML formatting inconsistent bug

[Christian Brabandt]

Am 2016-09-08 14:28, schrieb Kai Hendry:

Bizarrely 7.4.2334 seems to fix the issue. I did report the issue to
the script writers but they never responded btw.

Surely in future Github is a better bet?
https://github.com/vim/vim/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20yml


For runtime file bugs, it is recommended to contact the maintainer
first.

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: YML formatting inconsistent bug

[Kai Hendry]

Bizarrely 7.4.2334 seems to fix the issue. I did report the issue to the script 
writers but they never responded btw.

Surely in future Github is a better bet? 
https://github.com/vim/vim/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20yml

-- 
-- 
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: Erroneous positioning of cursor with multibyte characters

[Eric Pruitt]

On Thu, Sep 08, 2016 at 07:51:20AM +0200, Tony Mechelynck wrote:
> In gvim, I see this glyph centered over two screen cells, and my
> 'guifont' is set to "Bitstream Vera Sans Mono 8"; however, it is a
> GTK3/pangocairo build and it will look up other font faces of the same
> height and width if the requested font lacks the desired glyph.
>
> In Console Vim, I have tried a couple of fonts, and they all display
> the glyph in the left half of a two-cell space.
>
> After constructing the attached HTML file based on your example, I
> opened it in my browser (also built with cairo-gtk3), which says that
> the font faces actually used for the  element containing the glyph
> are FreeMono and FreeSerif; here, the glyph appears right-justified in
> a double-width character area.

Thanks, I will give that a shot.

Eric

-- 
-- 
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.