Re: [bug] invalid memory access with normal commands

[Christian Brabandt]

Hi Dominique!

On Di, 14 Feb 2017, Dominique Pellé wrote:

> Hi
> 
> afl-fuzz found another command that causes access to
> invalid memory in Vim-8.0.329. It's not a recent regression
> since bug is present in at least Vim-7.4.52 that comes
> with ubuntu-14.04.
> 
> I have not been able to find a fix yet.
> 
> Step to reproduce:
> 
> $ valgrind vim -u NONE -c'norm oxx' -c'norm vapo' -c'q!' 2>vg.log
> 
> And vg.log contains:
> 
> ==4259== Memcheck, a memory error detector
> ==4259== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==4259== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==4259== Command: vim -u NONE -cnorm\ oxx -cnorm\ vapo -cq!
> ==4259==
> ==4259== Invalid read of size 1
> ==4259==at 0x4CF4A0: utf_head_off (mbyte.c:3746)
> ==4259==by 0x4D094C: mb_adjustpos (mbyte.c:4028)
> ==4259==by 0x4E11C9: normal_cmd (normal.c:1292)
> ==4259==by 0x468F25: exec_normal (ex_docmd.c:10418)
> ==4259==by 0x469076: ex_normal (ex_docmd.c:10310)
> ==4259==by 0x46B734: do_one_cmd (ex_docmd.c:2981)
> ==4259==by 0x46B734: do_cmdline (ex_docmd.c:1120)
> ==4259==by 0x5BFC2B: exe_commands (main.c:2905)
> ==4259==by 0x5BFC2B: vim_main2 (main.c:781)
> ==4259==by 0x40C3D3: main (main.c:415)
> ==4259==  Address 0xa95bc50 is 0 bytes after a block of size 4,096 alloc'd
> ==4259==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==4259==by 0x4C4D0B: lalloc (misc2.c:942)
> ==4259==by 0x5C0830: mf_alloc_bhdr.isra.3 (memfile.c:907)
> ==4259==by 0x5C1546: mf_new (memfile.c:381)
> ==4259==by 0x4AC6FF: ml_new_data (memline.c:3513)
> ==4259==by 0x4AF0FC: ml_open (memline.c:400)
> ==4259==by 0x414DD6: open_buffer (buffer.c:163)
> ==4259==by 0x5BF891: create_windows (main.c:2677)
> ==4259==by 0x5BF891: vim_main2 (main.c:704)
> ==4259==by 0x40C3D3: main (main.c:415)
> 
> Possibly related to this, the following command does not
> seem to behave correctly, even if it does not trigger invalid
> memory:
> 
> $ echo "foo bar" | vim -u NONE -c'norm wvapo' -
> 
> Then press  o  multiple times and observe that cursor
> alternates between the beginning of the visual block
> and the *middle* of the visual block.  I would expect it to
> alternate between the beginning and the *end* of the
> visual block.

Interesting. The second issue happens, because current_par does 
internally switch to visual line mode, but does not reset the VIsual 
column correctly. This patch fixes it:

diff --git a/src/search.c b/src/search.c
index 36410e50f..ffda65837 100644
--- a/src/search.c
+++ b/src/search.c
@@ -4241,6 +4241,7 @@ extend:
 * line, we get stuck there.  Trap this here. */
if (VIsual_mode == 'V' && start_lnum == curwin->w_cursor.lnum)
goto extend;
+   VIsual.col  = 0;
VIsual.lnum = start_lnum;
VIsual_mode = 'V';
redraw_curbuf_later(INVERTED);  /* update the inversion */

As a side effect this also disables switching cursor position using 'o' 
which is currently a no-op when only a single line is selected (since it 
effectively switches positions between the start of line and the start 
of line).

Interestingly, I never noticed that this does nothing currently if a 
single visual line is selected.

As it stands, I think this also fixes the invalid read mentioned above. 
I just wanted to take a look at that issue, when I noticed that this 
patch does not exhibit this behaviour, so I didn't check very closely 
why it works.

I tried to add a test, to verify that this is fixed, but whatever I do, 
I always get back col 0 for the visual mode. I think this is because in 
getmark_buf_fnum() (mark.c:417) the column is explicitly set to zero for 
visual line mode and also using getpos('v') does not work, since by the 
time I run it, Visual mode is no longer active, so I cannot verify that 
this works in vimscript.

Best,
Christian
-- 
Mein Freund, ich brauche dich - wie eine Höhe, in der man anders
atmet.
-- Antoine de Saint-Exupéry

-- 
-- 
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: _UI64_MAX build error

[Steve Hall]

On Tue, Feb 14, 2017 at 10:29 PM, Ken Takata  wrote:
> 2017/2/15 Wed 11:05:21 UTC+9 Steve Hall wrote:
> >
> > i686-pc-mingw32-gcc -c -Iproto -DWIN32 -DWINVER=0x0501
>
> This shows that the setting of CROSS_COMPILE is not overwritten. I
> think that setting a variable in a makefile has a higher priority
> than setting in an environment variable. And setting a variable in a
> command line has a higher priority than setting in a makefile.
> Therefore, this works as expected:
>
>   make -f Make_cyg.mak CROSS_COMPILE=x86_64-w64-mingw32-

Works for me, I'll forego the environment for now.

Thanks for all the help!


-- 
Steve Hall  [ digitect dancingpaper com ]
Cream for Vim  http://cream.SourceForge.net

-- 
-- 
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: _UI64_MAX build error

[Ken Takata]

Hi,

2017/2/15 Wed 11:05:21 UTC+9 Steve Hall wrote:
> On Tue, Feb 14, 2017 at 6:56 PM, Ken Takata  wrote:
> > 2017/2/15 Wed 5:43:08 UTC+9 Steve Hall wrote:
> > >
> > > I'm setting the environment elsewhere now. So the only other thing in
> > > Make_cyg is UNDER_CYGWIN = yes. Not sure what that does, is it
> > > important?
> > 
> > It is used for setting the default name of windres command, and also used 
> > for
> > converting Cygwin style paths and Windows style paths where needed.
> > Without setting it, wrong version of windres might be used and causes link
> > error. Also compiling with if_perl and if_mzsch might fail.
> 
> 
> Thanks for the continued diagnosis. I've confirmed this to be true
> for if_perl.
> 
> 
> But Make_cyg.mak is still broken for with the same errors. It
> doesn't matter if I force either CROSS_COMPILE or ARCH:
> 
> 
> set CROSS_COMPILE=x86_64-w64-mingw32-
> set ARCH=x86-64
> 
> 
> Interestingly, without ARCH forced, make -f shows
> 
> 
> i686-pc-mingw32-gcc -c -Iproto -DWIN32 -DWINVER=0x0501

This shows that the setting of CROSS_COMPILE is not overwritten.
I think that setting a variable in a makefile has a higher priority than
setting in an environment variable.  And setting a variable in a command
line has a higher priority than setting in a makefile.  Therefore, this
works as expected:

  make -f Make_cyg.mak CROSS_COMPILE=x86_64-w64-mingw32-


> I'm over my head trying to find where _UI64_MAX is being passed, that
> doesn't show up anywhere in the source that I can grep.

You can find the definition of _UI64_MAX in limits.h.  E.g.:

  For x86: C:\cygwin64\usr\i686-w64-mingw32\sys-root\mingw\include\limits.h
  For x64: C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\include\limits.h

i686-pc-mingw32-gcc's limits.h might not have the definition, because it is old.


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: _UI64_MAX build error

[Steve Hall]

On Tue, Feb 14, 2017 at 6:56 PM, Ken Takata  wrote:
> 2017/2/15 Wed 5:43:08 UTC+9 Steve Hall wrote:
> >
> > I'm setting the environment elsewhere now. So the only other thing in
> > Make_cyg is UNDER_CYGWIN = yes. Not sure what that does, is it
> > important?
>
> It is used for setting the default name of windres command, and also used
for
> converting Cygwin style paths and Windows style paths where needed.
> Without setting it, wrong version of windres might be used and causes link
> error. Also compiling with if_perl and if_mzsch might fail.

Thanks for the continued diagnosis. I've confirmed this to be true
for if_perl.

But Make_cyg.mak is still broken for with the same errors. It
doesn't matter if I force either CROSS_COMPILE or ARCH:

set CROSS_COMPILE=x86_64-w64-mingw32-
set ARCH=x86-64

Interestingly, without ARCH forced, make -f shows

i686-pc-mingw32-gcc -c -Iproto -DWIN32 -DWINVER=0x0501
-D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H
-DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE
-DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_GUI_W32
-DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -pipe -march=i686 -Wall
-I/cygdrive/c/strawberry/perl/lib/Core -DFEAT_PERL
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL
-DDYNAMIC_PERL_DLL=\"perl524.dll\"
-I/cygdrive/c/PROGRA~2/Lua/5.1/include -I/cygdrive/c/PROGRA~2/Lua/5.1
-DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua51.dll\" -DFEAT_RUBY
-I /cygdrive/c/Ruby23-x64/lib/ruby/2.3.3/i386-mswin32 -I
/cygdrive/c/Ruby23-x64/include/ruby-2.3.3 -I
/cygdrive/c/Ruby23-x64/include/ruby-2.3.3/i386-mswin32 -DDYNAMIC_RUBY
-DDYNAMIC_RUBY_DLL=\"msvcrt-ruby233.dll\" -DDYNAMIC_RUBY_VER=23
-DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\"
-DFEAT_PYTHON3 -DDYNAMIC_PYTHON3
-DDYNAMIC_PYTHON3_DLL=\"python35.dll\" -O3 -fomit-frame-pointer
-freg-struct-return -s charset.c -o gobji686/charset.o

And the environment (build aborted immediately after error) shows no
variable for ARCH.

With ARCH forced:

i686-pc-mingw32-gcc -c -Iproto -DWIN32 -DWINVER=0x0501
-D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H
-DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT
-DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_GUI_W32
-DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -pipe -march=x86-64 -Wall
-I/cygdrive/c/strawberry/perl/lib/Core -DFEAT_PERL
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL
-DDYNAMIC_PERL_DLL=\"perl524.dll\"
-I/cygdrive/c/PROGRA~2/Lua/5.1/include -I/cygdrive/c/PROGRA~2/Lua/5.1
-DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua51.dll\" -DFEAT_RUBY
-I /cygdrive/c/Ruby23-x64/lib/ruby/2.3.3/i386-mswin32 -I
/cygdrive/c/Ruby23-x64/include/ruby-2.3.3 -I
/cygdrive/c/Ruby23-x64/include/ruby-2.3.3/i386-mswin32 -DDYNAMIC_RUBY
-DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby233.dll\" -DDYNAMIC_RUBY_VER=23
-DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\"
-DFEAT_PYTHON3 -DDYNAMIC_PYTHON3
-DDYNAMIC_PYTHON3_DLL=\"python35.dll\" -O3 -fomit-frame-pointer
-freg-struct-return -s charset.c -o gobjx86-64/charset.o

And ARCH=x86-64

Both produce the same errors:

charset.c: In function 'vim_str2nr':
charset.c:1915:15: error: '_UI64_MAX' undeclared (first use in this
function)
charset.c:1915:15: note: each undeclared identifier is reported only once
for each function it appears in
charset.c:1981:15: error: '_I64_MAX' undeclared (first use in this function)
charset.c:1982:11: error: '_I64_MIN' undeclared (first use in this function)
make: *** [Make_cyg_ming.mak:887: gobjx86-64/charset.o] Error 1

I'm over my head trying to find where _UI64_MAX is being passed, that
doesn't show up anywhere in the source that I can grep.


-- 
Steve Hall  [ digitect dancingpaper com ]
Cream for Vim  http://cream.SourceForge.net

-- 
-- 
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] open grep result directly (#1473)

[Yegappan Lakshmanan]

Hi Bram,

On Tue, Feb 14, 2017 at 2:50 PM, Bram Moolenaar  wrote:
>
> Yegappan Lakshmanan wrote:
>
>> On Mon, Feb 13, 2017 at 3:22 PM, Bram Moolenaar
>>  wrote:
>> > It's possible in various ways, but still requires the user to add a mapping
>> > or autocommand.
>> > Problem is always that a file name could actually end in :{number}.
>> >
>> > I also wanted to make "gf" jump to the right line number, very useful when
>> > looking in the output of a compilation command (and not using quickfix for
>> > whatever reason). That should be possible, so long as the : character is 
>> > not
>> > in 'isfname'.
>> >
>>
>> The "gF" command jumps to the line number following the file name.
>
> I guess I should read the help (instead of just writing it :-).
>

:-). This feature was added for the Vim7 release and some more related
commands are:

CTRL-W F - Open the file in a new window and jump to the line number
following the file name.
CTRL-W gF - Open the file in a new tab page and jump to the line number
following the file name.

- Yegappan

-- 
-- 
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: _UI64_MAX build error

[Ken Takata]

Hi,

2017/2/15 Wed 5:43:08 UTC+9 Steve Hall wrote:
> On Tue, Feb 14, 2017 at 9:58 AM, Ken Takata  wrote:
> 
> > 2017/2/14 Tue 22:58:45 UTC+9 Steve Hall wrote:
> > >
> > > I'm was simply using "make -f Make_cyg.mak", that was the default.
> > 
> > Hmm, did you set 'ARCH=x86-64' manually?
> > The command line you pasted has '-march=x86-64'. This is for 64-bit build.
> 
> 
> I had ARCH set to try and force it but it didn't work via
> Make_cyg.mak without the CROSS_COMPILE.
> 
> 
> 
> 
> > > Looks like Make_cyg.mak forces w32. So I referenced Make_cyg_ming.mak
> > > instead with your CROSS_COMPILE set and all is good.
> > 
> > You can use the following command to overwrite the CROSS_COMPILE setting:
> > 
> >   make -f Make_cyg.mak CROSS_COMPILE=x86_64-w64-mingw32-
> 
> 
> I'm setting the environment elsewhere now. So the only other thing in
> Make_cyg is UNDER_CYGWIN = yes. Not sure what that does, is it
> important?

It is used for setting the default name of windres command, and also used for
converting Cygwin style paths and Windows style paths where needed.
Without setting it, wrong version of windres might be used and causes link
error. Also compiling with if_perl and if_mzsch might fail.

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: [patch] Remove "VimL" and like word from Vim source tree

[Bram Moolenaar]

Hirohito Higashi wrote:

> Hi Bram, Dr.Chip and list,
> 
> I removed "VimL" and like word from Vim source tree.
> 
> Related comment:
> https://groups.google.com/d/msg/vim_dev/3Z5yM8KER2w/wAqws0QSEAAJ
> 
> Please check an attached patch.

Thanks!  Didn't realize we had so many of these already.


-- 
ARTHUR:   You are indeed brave Sir knight, but the fight is mine.
BLACK KNIGHT: Had enough?
ARTHUR:   You stupid bastard.  You havn't got any arms left.
 "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: [vim/vim] open grep result directly (#1473)

[Bram Moolenaar]

Yegappan Lakshmanan wrote:

> On Mon, Feb 13, 2017 at 3:22 PM, Bram Moolenaar
>  wrote:
> > It's possible in various ways, but still requires the user to add a mapping
> > or autocommand.
> > Problem is always that a file name could actually end in :{number}.
> >
> > I also wanted to make "gf" jump to the right line number, very useful when
> > looking in the output of a compilation command (and not using quickfix for
> > whatever reason). That should be possible, so long as the : character is not
> > in 'isfname'.
> >
> 
> The "gF" command jumps to the line number following the file name.

I guess I should read the help (instead of just writing it :-).

-- 
BLACK KNIGHT: I'm invincible!
ARTHUR:   You're a looney.
 "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: Patch 8.0.0329

[Kazunobu Kuriyama]

2017-02-15 4:48 GMT+09:00 Bram Moolenaar :

>
> Kazunobu Kuriyama wrote:
>
> > > Dominique wrote:
> > >
> > > > Bram Moolenaar wrote:
> > > >
> > > > > Patch 8.0.0329
> > > > > Problem:Xfontset and guifontwide are not tested.
> > > > > Solution:   Add tests. (Kazunobu Kuriyama)
> > > > > Files:  src/testdir/test_gui.vim
> > > >
> > > > A test introduced by above patch fails when I configure vim-8.0.329
> with:
> > > >
> > > > $ configure --with-features=huge --enable-gui=motif
> > > >
> > > > ===
> > > > Test results:
> > > >
> > > >
> > > > >From test_gui.vim:
> > > > Found errors in Test_set_guifontset():
> > > > Caught exception in Test_set_guifontset(): Vim(language):E197: Cannot
> > > > set language to "ja_JP.eucJP" @ function
> > > > RunTheTest[21]..Test_set_guifontset, line 13
> > > > TEST FAILURE
> > > > make: *** [report] Error 1
> > > > ===
> > > >
> > > > With --enable-gui=gtk2, all tests pass.
> > > >
> > > > Line 13 in Test_set_guifontset is:
> > > >
> > > >language ctype ja_JP.eucJP
> > > >
> > > > I don't have time to investigate now.  Maybe it happens because
> > > > I don't have the Japanese locale installed. Or maybe it's a
> limitation
> > > > of the Motif GUI, since all tests pass when using the gtk2 GUI.
> > >
> > > It might be that this just doesn't always work.  We could put a
> > > try/catch around it and ignore the error if it's E197.
> > >
> >
> > OK, I wrote a patch along that line.  Please have a look at the patch
> > attached.
> >
> > I actually like the suggested idea because it definitely makes my life
> > easier :)
> >
> > The patch also includes some improvements and changes in preparation for
> > the script's getting larger in the feature.
>
> Thanks.  I find the solution with the array of messages a bit too much.
> Why not have some script-local variables for the messages?
>
> let s:skip_for_wrong_gui = 'Skipped: wrong gui'
> let s:skip_for_another_reason = 'Skipped: another reason'
>
>
> func Test_something()
>   let skipped = ''
>
>   if wrong gui
> let skipped = l:skip_for_wrong_gui
>   else
> try
>   something
> catch
>   let skipped = sk:skip_for_another_reason
> endtry
>   endif
>   if skipped
>  throw skipped
>   endif
>
>
> Something like that.
>

Hi Bram

Ah, you're right.  Looks I was bound to the original type of the variable
too much.  Maybe I've been strongly typed equal to or more than C but
absolutely less than Vim scripts. I'll try to change that.

I also see a structure in the pseudo-code suggesting that putting
error/exception handling immediately below the IF rather than at the bottom
of the whole block, makes code much neater.

Thank you for the suggestions.  I'll see to them all and soon send you a
patch which also addresses the issue raised by Dominique.

Regards,
Kazunobu

>
> --
> ARTHUR:   Now stand aside worthy adversary.
> BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
> ARTHUR:   A scratch?  Your arm's off.
>  "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: Patch 8.0.0329

[Kazunobu Kuriyama]

2017-02-15 4:10 GMT+09:00 Dominique Pellé :

> Kazunobu Kuriyama wrote:
>
> > 2017-02-14 5:43 GMT+09:00 Dominique Pellé :
> >>
> >> Bram Moolenaar wrote:
> >>
> >> > Patch 8.0.0329
> >> > Problem:Xfontset and guifontwide are not tested.
> >> > Solution:   Add tests. (Kazunobu Kuriyama)
> >> > Files:  src/testdir/test_gui.vim
> >>
> >> A test introduced by above patch fails when I configure vim-8.0.329
> with:
> >>
> >> $ configure --with-features=huge --enable-gui=motif
> >>
> >> ===
> >> Test results:
> >>
> >>
> >> From test_gui.vim:
> >> Found errors in Test_set_guifontset():
> >> Caught exception in Test_set_guifontset(): Vim(language):E197: Cannot
> >> set language to "ja_JP.eucJP" @ function
> >> RunTheTest[21]..Test_set_guifontset, line 13
> >> TEST FAILURE
> >> make: *** [report] Error 1
> >> ===
> >>
> >> With --enable-gui=gtk2, all tests pass.
> >>
> >> Line 13 in Test_set_guifontset is:
> >>
> >>language ctype ja_JP.eucJP
> >>
> >> I don't have time to investigate now.  Maybe it happens because
> >> I don't have the Japanese locale installed.
> >
> >
> > Hi, Dominique
> >
> > Thank you for the report.
> >
> > As locale is libc proper, I never imaged that could happen.
> >
> > So, I need to begin with things to ask you.  Since you;re looking busy
> now,
> > I'd be happy if you could reply when you find it convenient.
> >
> > Could you do '/usr/share/locale | grep ^ja' and check if there's a
> directory
> > named 'ja_JP.eucJP/'?
> >
> > In case there's no such a directory, could you do 'grep ^ja
> > /usr/share/locale/locale.alias'?  If you find any of Japanese locales
> and
> > their aliases there, and if you have the directories corresponding to
> them,
> > we might change test_gui accordingly.
> >
> >> Or maybe it's a limitation
> >> of the Motif GUI, since all tests pass when using the gtk2 GUI.
> >
> >
> > The GTK GUIs don't support 'guifontset' and thus the test is skipped.
> >>
> >>
> >> Regards
> >> Dominique
> >
> >
> > Regards,
> > Kazunobu
>
>
> Hi Kazunobu
>
> I saw that you already sent another patch, so I'm not sure
> it matters a lot if I respond to the above questions any more.
>
> I did this:
>
> $ sudo apt-get install language-pack-ja
> I now see ja_JP.UTF-8 in the output of locale -a.
> But the test still fails in the same way.
>
> Output of "locale -a":
>
> $ locale -a
> br_FR.utf8
> C
> C.UTF-8
> en_AG
> en_AG.utf8
> en_AU.utf8
> en_BW.utf8
> en_CA.utf8
> en_DK.utf8
> en_GB.utf8
> en_HK.utf8
> en_IE.utf8
> en_IN
> en_IN.utf8
> en_NG
> en_NG.utf8
> en_NZ.utf8
> en_PH.utf8
> en_SG.utf8
> en_US.utf8
> en_ZA.utf8
> en_ZM
> en_ZM.utf8
> en_ZW.utf8
> eo_US.utf8
> eo.utf8
> fr_BE.utf8
> fr_CA.utf8
> fr_CH.utf8
> fr_FR.utf8
> fr_LU.utf8
> it_CH.utf8
> it_IT.utf8
> ja_JP.utf8
> nl_AW
> nl_AW.utf8
> nl_BE.utf8
> nl_NL.utf8
> POSIX
>
> Output that you requested:
>
> $ ls /usr/share/locale | grep ^ja
> ja
>
> $ grep ^ja /usr/share/locale/locale.alias
> japaneseja_JP.eucJP
> japanese.eucja_JP.eucJP
> ja_JPja_JP.eucJP
> ja_JP.ujisja_JP.eucJP
> japanese.sjisja_JP.SJIS
>
>
> Ah, I just see that all tests pass if I do this:
>
> $ git diff
> diff --git a/src/testdir/test_gui.vim b/src/testdir/test_gui.vim
> index 49bc026..9e5408a 100644
> --- a/src/testdir/test_gui.vim
> +++ b/src/testdir/test_gui.vim
> @@ -144,7 +144,7 @@ func Test_set_guifontset()
>  " job done.  To make the test meaningful for a wide variety of hosts,
> we
>  " confine ourselves to the following locale for which X11
> historically has
>  " the fonts to use with.
> -language ctype ja_JP.eucJP
> +language ctype ja_JP.UTF-8
>
>  " Since XCreateFontSet(3) is very sensitive to locale, fonts must be
>  " chosen meticulously.
>
> Hi Dominique,

Thank you for the very interesting result.  I got it.

It looks that the xubuntu is made specialized in UTF-8 locales, and that
fonts are chosen accordingly to support them well.  It adopts a modern
locale handling, although there still remain some remnants of the
pre-unicode era in locale.alias.

Meanwhile, as for my OS X, there're still many pre-unicode era encodings in
/usr/share/locale, and XQuartz, an X11 implementation for OS X, is a bare
minimum X11; there's no GTK+, Qt, Gnome nor KDE; you have only twm and
xterm there :)  Although it actually supports UTF-8 locales and encodings,
there're many fonts in /opt/X11/lib/X11/fonts/misc to support locales of
old encodings.

In addition to the difference in installed fonts between the modern and the
traditional systems, XCreateFontSet(), which creates a font list out of a
given XLFD list and the current locale, is very sensitive to font paths as
well as the current locale when the XLFDs in the list have wild cards.
Different font paths can yield different font lists for the same XLFD list.

All those factors explain why I found a difficulty in writing a test with a
UTF-8 locale-encoding while you succeeded in that (quite 

Re: _UI64_MAX build error

[Steve Hall]

On Tue, Feb 14, 2017 at 9:58 AM, Ken Takata  wrote:
> 2017/2/14 Tue 22:58:45 UTC+9 Steve Hall wrote:
> >
> > I'm was simply using "make -f Make_cyg.mak", that was the default.
>
> Hmm, did you set 'ARCH=x86-64' manually?
> The command line you pasted has '-march=x86-64'. This is for 64-bit build.

I had ARCH set to try and force it but it didn't work via
Make_cyg.mak without the CROSS_COMPILE.


> > Looks like Make_cyg.mak forces w32. So I referenced Make_cyg_ming.mak
> > instead with your CROSS_COMPILE set and all is good.
>
> You can use the following command to overwrite the CROSS_COMPILE setting:
>
>   make -f Make_cyg.mak CROSS_COMPILE=x86_64-w64-mingw32-

I'm setting the environment elsewhere now. So the only other thing in
Make_cyg is UNDER_CYGWIN = yes. Not sure what that does, is it
important?


> BTW, Cygwin has three MinGW cross compiler packages.
>
> 1. i686-pc-mingw32-gcc: The original version of 32-bit MinGW.
> 2. i686-w64-mingw32-gcc: 32-bit version of MinGW-w64.
> 3. x86_64-w64-mingw32-gcc: 64-bit version of MinGW-w64.
>
> When I refactored Make_cyg.mak in v7.4.496, I set #1 as default, but it
seems
> that #1 is almost dead.  I haven't checked, but maybe v8.0.219 or later
cannot
> be compiled by #1.  I think #2 should be default now.

Makes sense. From here on, I'll only build/post w64 versions. But the
build is automated so I can build a w32 if someone specifically asks.

Thanks, again.


-- 
Steve Hall  [ digitect dancingpaper com ]
Cream for Vim  http://cream.SourceForge.net

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

[bug] invalid memory access with normal commands

[Dominique Pellé]

Hi

afl-fuzz found another command that causes access to
invalid memory in Vim-8.0.329. It's not a recent regression
since bug is present in at least Vim-7.4.52 that comes
with ubuntu-14.04.

I have not been able to find a fix yet.

Step to reproduce:

$ valgrind vim -u NONE -c'norm oxx' -c'norm vapo' -c'q!' 2>vg.log

And vg.log contains:

==4259== Memcheck, a memory error detector
==4259== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4259== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==4259== Command: vim -u NONE -cnorm\ oxx -cnorm\ vapo -cq!
==4259==
==4259== Invalid read of size 1
==4259==at 0x4CF4A0: utf_head_off (mbyte.c:3746)
==4259==by 0x4D094C: mb_adjustpos (mbyte.c:4028)
==4259==by 0x4E11C9: normal_cmd (normal.c:1292)
==4259==by 0x468F25: exec_normal (ex_docmd.c:10418)
==4259==by 0x469076: ex_normal (ex_docmd.c:10310)
==4259==by 0x46B734: do_one_cmd (ex_docmd.c:2981)
==4259==by 0x46B734: do_cmdline (ex_docmd.c:1120)
==4259==by 0x5BFC2B: exe_commands (main.c:2905)
==4259==by 0x5BFC2B: vim_main2 (main.c:781)
==4259==by 0x40C3D3: main (main.c:415)
==4259==  Address 0xa95bc50 is 0 bytes after a block of size 4,096 alloc'd
==4259==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
==4259==by 0x4C4D0B: lalloc (misc2.c:942)
==4259==by 0x5C0830: mf_alloc_bhdr.isra.3 (memfile.c:907)
==4259==by 0x5C1546: mf_new (memfile.c:381)
==4259==by 0x4AC6FF: ml_new_data (memline.c:3513)
==4259==by 0x4AF0FC: ml_open (memline.c:400)
==4259==by 0x414DD6: open_buffer (buffer.c:163)
==4259==by 0x5BF891: create_windows (main.c:2677)
==4259==by 0x5BF891: vim_main2 (main.c:704)
==4259==by 0x40C3D3: main (main.c:415)

Possibly related to this, the following command does not
seem to behave correctly, even if it does not trigger invalid
memory:

$ echo "foo bar" | vim -u NONE -c'norm wvapo' -

Then press  o  multiple times and observe that cursor
alternates between the beginning of the visual block
and the *middle* of the visual block.  I would expect it to
alternate between the beginning and the *end* of the
visual block.

Regards
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: Patch 8.0.0329

[Bram Moolenaar]

Kazunobu Kuriyama wrote:

> > Dominique wrote:
> >
> > > Bram Moolenaar wrote:
> > >
> > > > Patch 8.0.0329
> > > > Problem:Xfontset and guifontwide are not tested.
> > > > Solution:   Add tests. (Kazunobu Kuriyama)
> > > > Files:  src/testdir/test_gui.vim
> > >
> > > A test introduced by above patch fails when I configure vim-8.0.329 with:
> > >
> > > $ configure --with-features=huge --enable-gui=motif
> > >
> > > ===
> > > Test results:
> > >
> > >
> > > >From test_gui.vim:
> > > Found errors in Test_set_guifontset():
> > > Caught exception in Test_set_guifontset(): Vim(language):E197: Cannot
> > > set language to "ja_JP.eucJP" @ function
> > > RunTheTest[21]..Test_set_guifontset, line 13
> > > TEST FAILURE
> > > make: *** [report] Error 1
> > > ===
> > >
> > > With --enable-gui=gtk2, all tests pass.
> > >
> > > Line 13 in Test_set_guifontset is:
> > >
> > >language ctype ja_JP.eucJP
> > >
> > > I don't have time to investigate now.  Maybe it happens because
> > > I don't have the Japanese locale installed. Or maybe it's a limitation
> > > of the Motif GUI, since all tests pass when using the gtk2 GUI.
> >
> > It might be that this just doesn't always work.  We could put a
> > try/catch around it and ignore the error if it's E197.
> >
> 
> OK, I wrote a patch along that line.  Please have a look at the patch
> attached.
> 
> I actually like the suggested idea because it definitely makes my life
> easier :)
> 
> The patch also includes some improvements and changes in preparation for
> the script's getting larger in the feature.

Thanks.  I find the solution with the array of messages a bit too much.
Why not have some script-local variables for the messages?

let s:skip_for_wrong_gui = 'Skipped: wrong gui'
let s:skip_for_another_reason = 'Skipped: another reason'


func Test_something()
  let skipped = ''

  if wrong gui
let skipped = l:skip_for_wrong_gui
  else
try
  something
catch
  let skipped = sk:skip_for_another_reason
endtry
  endif
  if skipped
 throw skipped
  endif


Something like that.

-- 
ARTHUR:   Now stand aside worthy adversary.
BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
ARTHUR:   A scratch?  Your arm's off.
 "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: [patch] Remove "VimL" and like word from Vim source tree

[Charles E Campbell]

h_east wrote:
> Hi Bram, Dr.Chip and list,
>
> I removed "VimL" and like word from Vim source tree.
>
> Related comment:
> https://groups.google.com/d/msg/vim_dev/3Z5yM8KER2w/wAqws0QSEAAJ
>
> Please check an attached patch.
>
>
>> Dr.Chip  (as a netrw author)
> There is also a "VimL" word in the help of netrw.
> I hope you accept the following changes.
>
> diff --git a/runtime/doc/pi_netrw.txt b/runtime/doc/pi_netrw.txt
> index 914c576..633dc87 100644
> --- a/runtime/doc/pi_netrw.txt
> +++ b/runtime/doc/pi_netrw.txt
> @@ -479,7 +479,7 @@ file using root-relative paths, use the full path:
>  
> ==
>  4. Network-Oriented File Transfer*netrw-xfer* {{{1
>  
> -Network-oriented file transfer under Vim is implemented by a VimL-based 
> script
> +Network-oriented file transfer under Vim is implemented by a Vim script
>  () using plugin techniques.  It currently supports both reading 
> and
>  writing across networks using rcp, scp, ftp or ftp+<.netrc>, scp, fetch,
>  dav/cadaver, rsync, or sftp.
>
>
Thank you -- but I'd already changed it.  Haven't posted it yet, though.
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: [vim/vim] open grep result directly (#1473)

[Yegappan Lakshmanan]

Hi,

On Mon, Feb 13, 2017 at 2:13 AM, was  wrote:
> Thanks @chrisbra, I did not even hear of quickfix/location, I need some more
> googling and reading.
>
> I used to:
>
> git grep -n foo
> no results found or not what I expect, then git grep -n bar
> use vim for a quick view on a certain line
>
> It seems that quickfix/location requires an already opened vim buffer?
>

Different quickfix/location list commands are available to process the
output from a command. Some of them are listed below:

1. Redirect the output from a command to a file and pass it onto Vim.

  $ grep -Hn abc *.log > output.txt
  $ vim -q output.txt

2. Run the command directly from Vim and populate the quickfix list.

 $ vim
 :cexpr system('grep -Hn abc *.log')

3. Read the output of the command into a Vim buffer (or paste the
output of the command into a buffer) and populate the quickfix list.
Note that you can use an unnamed/scratch buffer for this.

$ vim
:r! grep -Hn abc *.log
:cgetbuffer

The above 'cgetbuffer' command processes the entire buffer. You can
also process only selected lines by passing a range to the command.

4. Use the ":grep" command to invoke an external command
 set in the 'grepprg' option.

 $ vim
 :grep -Hn abc *.log

5. Use the internal ":vimgrep" command:

 $ vim
  :vimgrep abc *.log

Once the quickfix list is populated, you can use the various quickfix commands
to browse the result.

There are also similar commands available for using the location list.

- Yegappan

> And how to jump to, for example, the 5th(and most of time it's hard to tell
> vim the number) result? Or, if no one expected, how can I just close it?
>
> $ vim -c ":grep blabla *.log"
>
> grep.log:1:1 blabla
> grep.log:2:2 blabla
> grep.log:3:3 blabla
> grep.log:4:4 blabla
> grep.log:5:5 blabla
> grep.log:6:6 blabla
> grep.log:7:7 blabla
> grep.log:8:8 blabla
> grep.log:9:9 blabla
> grep.log:10:10 blabla
>
> Press ENTER or type command to continue
>

-- 
-- 
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: _UI64_MAX build error

[Ken Takata]

Hi,

2017/2/14 Tue 22:58:45 UTC+9 Steve Hall wrote:
> On Mon, Feb 13, 2017 at 6:15 PM, Ken Takata  wrote:
> > 
> > Are you really using i686-pc-mingw32-gcc for x64 build?
> 
> 
> I'm was simply using "make -f Make_cyg.mak", that was the default. 

Hmm, did you set 'ARCH=x86-64' manually?
The command line you pasted has '-march=x86-64'. This is for 64-bit build.


> > It is a compiler for x86 build. You should use
> > x86_64-w64-mingw32-gcc for x64 build. Set
> > 'CROSS_COMPILE=x86_64-w64-mingw32-' to use it. Additionally, you
> > don't need to set ARCH=x86-64 manually after v7.4.2034. Normally,
> > ARCH will be automatically detected after that.
> 
> 
> Looks like Make_cyg.mak forces w32. So I referenced Make_cyg_ming.mak
> instead with your CROSS_COMPILE set and all is good.

You can use the following command to overwrite the CROSS_COMPILE setting:

  make -f Make_cyg.mak CROSS_COMPILE=x86_64-w64-mingw32-


BTW, Cygwin has three MinGW cross compiler packages.

1. i686-pc-mingw32-gcc: The original version of 32-bit MinGW.
2. i686-w64-mingw32-gcc: 32-bit version of MinGW-w64.
3. x86_64-w64-mingw32-gcc: 64-bit version of MinGW-w64.

When I refactored Make_cyg.mak in v7.4.496, I set #1 as default, but it seems
that #1 is almost dead.  I haven't checked, but maybe v8.0.219 or later cannot
be compiled by #1.  I think #2 should be default now.

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: _UI64_MAX build error

[Steve Hall]

On Mon, Feb 13, 2017 at 6:15 PM, Ken Takata  wrote:
>
> Are you really using i686-pc-mingw32-gcc for x64 build?

I'm was simply using "make -f Make_cyg.mak", that was the default.

> It is a compiler for x86 build. You should use
> x86_64-w64-mingw32-gcc for x64 build. Set
> 'CROSS_COMPILE=x86_64-w64-mingw32-' to use it. Additionally, you
> don't need to set ARCH=x86-64 manually after v7.4.2034. Normally,
> ARCH will be automatically detected after that.

Looks like Make_cyg.mak forces w32. So I referenced Make_cyg_ming.mak
instead with your CROSS_COMPILE set and all is good.

I'm curious how many folks out there still need a w32? Not that anyone
needs my builds anymore (hmm, 6k downloads of previous installer), but
I wonder if it

-- 
Steve Hall  [ digitect dancingpaper com ]
Cream for Vim  http://cream.SourceForge.net

-- 
-- 
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] The scroll does not keep up the cursor on some situation. (#1474)

[Matěj Cepl]

On 2017-02-13, 23:41 GMT, Bram Moolenaar wrote:
> I think what you are seeing here is intentional.  When you 
> type exactly the characters that fit, Vim won't scroll the 
> display up until you type another character.  It's not really 
> a problem, right?

I am not sure whether it is the same, but I have here with 
8.0-324 and Gtk3 GUI repeated problems with vim skipping letters 
when writing a longer text (ft=rst). When I write a longer 
sentence, sometimes only few letters remain in the buffer.

Is it a known problem?

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
He can compress the most words into the smallest idea of any man
I know.
  -- Abraham Lincoln

-- 
-- 
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] Remove "VimL" and like word from Vim source tree

[h_east]

Hi Bram, Dr.Chip and list,

I removed "VimL" and like word from Vim source tree.

Related comment:
https://groups.google.com/d/msg/vim_dev/3Z5yM8KER2w/wAqws0QSEAAJ

Please check an attached patch.


> Dr.Chip  (as a netrw author)
There is also a "VimL" word in the help of netrw.
I hope you accept the following changes.

diff --git a/runtime/doc/pi_netrw.txt b/runtime/doc/pi_netrw.txt
index 914c576..633dc87 100644
--- a/runtime/doc/pi_netrw.txt
+++ b/runtime/doc/pi_netrw.txt
@@ -479,7 +479,7 @@ file using root-relative paths, use the full path:
 ==
 4. Network-Oriented File Transfer  *netrw-xfer* {{{1
 
-Network-oriented file transfer under Vim is implemented by a VimL-based script
+Network-oriented file transfer under Vim is implemented by a Vim script
 () using plugin techniques.  It currently supports both reading and
 writing across networks using rcp, scp, ftp or ftp+<.netrc>, scp, fetch,
 dav/cadaver, rsync, or sftp.


--
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/if_mzsch.txt b/runtime/doc/if_mzsch.txt
index 9ef6c3d..7e206f5 100644
--- a/runtime/doc/if_mzsch.txt
+++ b/runtime/doc/if_mzsch.txt
@@ -249,7 +249,7 @@ Windows			*mzscheme-window*
 5. mzeval() Vim function*mzscheme-mzeval*
 
 To facilitate bi-directional interface, you can use |mzeval()| function to
-evaluate MzScheme expressions and pass their values to VimL.
+evaluate MzScheme expressions and pass their values to Vim script.
 
 ==
 6. Using Function references*mzscheme-funcref*
diff --git a/runtime/doc/if_pyth.txt b/runtime/doc/if_pyth.txt
index 2016e33..72ed7b0 100644
--- a/runtime/doc/if_pyth.txt
+++ b/runtime/doc/if_pyth.txt
@@ -676,11 +676,11 @@ vim.Function object*python-Function*
  dictionary. Note that explicit `self` keyword used when 
  calling resulting object overrides this attribute.
 auto_rebind  Boolean. True if partial created from this Python object 
- and stored in the VimL dictionary should be automatically 
- rebound to the dictionary it is stored in when this 
- dictionary is indexed. Exposes Vim internal difference 
- between `dict.func` (auto_rebind=True) and 
- `function(dict.func,dict)` (auto_rebind=False). This 
+ and stored in the Vim script dictionary should be
+ automatically rebound to the dictionary it is stored in
+ when this dictionary is indexed. Exposes Vim internal
+ difference between `dict.func` (auto_rebind=True) and
+ `function(dict.func,dict)` (auto_rebind=False). This
  attribute makes no sense if `self` attribute is `None`.
 
 Constructor additionally accepts `args`, `self` and `auto_rebind` 
@@ -711,7 +711,7 @@ vim.Function object*python-Function*
 8. pyeval() and py3eval() Vim functions			*python-pyeval*
 
 To facilitate bi-directional interface, you can use |pyeval()| and |py3eval()| 
-functions to evaluate Python expressions and pass their values to VimL.
+functions to evaluate Python expressions and pass their values to Vim script.
 |pyxeval()| is also available.
 
 ==
diff --git a/runtime/doc/syntax.txt b/runtime/doc/syntax.txt
index e300983..7feedd0 100644
--- a/runtime/doc/syntax.txt
+++ b/runtime/doc/syntax.txt
@@ -3320,8 +3320,8 @@ Some folding is now supported with syntax/vim.vim: >
g:vimsyn_folding =~ 't' : fold tcl  script
 <
 			*g:vimsyn_noerror*
-Not all error highlighting that syntax/vim.vim does may be correct; VimL is a
-difficult language to highlight correctly.  A way to suppress error
+Not all error highlighting that syntax/vim.vim does may be correct; Vim script
+is a difficult language to highlight correctly.  A way to suppress error
 highlighting is to put the following line in your |vimrc|: >
 
 	let g:vimsyn_noerror = 1
diff --git a/runtime/doc/usr_02.txt b/runtime/doc/usr_02.txt
index 48dede8..3c68943 100644
--- a/runtime/doc/usr_02.txt
+++ b/runtime/doc/usr_02.txt
@@ -589,7 +589,7 @@ Summary: 	*help-summary*  >
 register: >
	:help quote:
 
-13) Vim Script (VimL) is available at >
+13) Vim script is available at 

Re: Patch 8.0.0329

[Kazunobu Kuriyama]

2017-02-14 8:42 GMT+09:00 Bram Moolenaar :

>
> Dominique wrote:
>
> > Bram Moolenaar wrote:
> >
> > > Patch 8.0.0329
> > > Problem:Xfontset and guifontwide are not tested.
> > > Solution:   Add tests. (Kazunobu Kuriyama)
> > > Files:  src/testdir/test_gui.vim
> >
> > A test introduced by above patch fails when I configure vim-8.0.329 with:
> >
> > $ configure --with-features=huge --enable-gui=motif
> >
> > ===
> > Test results:
> >
> >
> > >From test_gui.vim:
> > Found errors in Test_set_guifontset():
> > Caught exception in Test_set_guifontset(): Vim(language):E197: Cannot
> > set language to "ja_JP.eucJP" @ function
> > RunTheTest[21]..Test_set_guifontset, line 13
> > TEST FAILURE
> > make: *** [report] Error 1
> > ===
> >
> > With --enable-gui=gtk2, all tests pass.
> >
> > Line 13 in Test_set_guifontset is:
> >
> >language ctype ja_JP.eucJP
> >
> > I don't have time to investigate now.  Maybe it happens because
> > I don't have the Japanese locale installed. Or maybe it's a limitation
> > of the Motif GUI, since all tests pass when using the gtk2 GUI.
>
> It might be that this just doesn't always work.  We could put a
> try/catch around it and ignore the error if it's E197.
>

OK, I wrote a patch along that line.  Please have a look at the patch
attached.

I actually like the suggested idea because it definitely makes my life
easier :)

The patch also includes some improvements and changes in preparation for
the script's getting larger in the feature.

Regards,
Kazunobu

>
> --
> DENNIS: You can't expect to wield supreme executive power just 'cause some
> watery tart threw a sword at you!
>  "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.


fix_Test_set_guifontset.patch
Description: Binary data