Re: Changing the defaults with Vim 8

[Tony Mechelynck]

"map Q gq" has long been part of the vimrc_example.vim. Now it is
moved to defaults.vim which vimrc_example.vim sources. So if you have
a vimrc you won't be affected, even if your own vimrc sources the
vimrc_example.vim, because in that case you already had it and will
keep it. If, like me, you don't like this mapping, you'll do what I've
long been doing: unmap Q at some point after sourcing the
vimrc_example.vim.

This mapping will, in fact, only apply to you if you were relying on
the absence of a vimrc to get a legacy-vi-like 'compatible'
environment. In that case it might be time to set up an empty exrc
file, which IIUC will also leave 'compatible' set, avoid sourcing
defaults.vim, and do nothing else.


Best regards,
Tony.

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

[Ken Takata]

Hi Bram,

2016/7/29 Fri 5:24:37 UTC+9 Bram Moolenaar wrote:
> Patch 7.4.2111
> Problem:Defaults are very conservative.
> Solution:   Move settings from vimrc_example.vim to defaults.vim.  Load
> defaults.vim if no .vimrc was found.
> Files:  src/main.c, src/version.c, src/os_amiga.h, src/os_dos.h,
> src/os_mac.h, src/os_unix.h, src/feature.h, src/Makefile,
> runtime/vimrc_example.vim, runtime/defaults.vim,
> runtime/evim.vim, Filelist, runtime/doc/starting.txt

I found a typo in this patch:

--- a/runtime/doc/starting.txt
+++ b/runtime/doc/starting.txt
@@ -979,7 +979,7 @@ This has the side effect of setting or r
 changed.  This has the same effect like the value of 'compatible' had this
 value when starting Vim.
 
-'compatible is NOT reset, and |defaults.vim| is not loaded:
+'compatible' is NOT reset, and |defaults.vim| is not loaded:
 - when Vim was started with the |-u| command line argument, especially with
   "-u NONE", or
 - when started with the |-C| command line argument, or


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.

Patch 7.4.2112

[Bram Moolenaar]

Patch 7.4.2112
Problem:getcompletion(.., 'dir') returns a match with trailing "*" when
there are no matches. (Chdiza)
Solution:   Return an empty list when there are no matches.  Add a trailing
slash to directories. (Yegappan Lakshmanan)  Add tests for no
matches. (closes #947)
Files:  src/evalfunc.c, src/testdir/test_cmdline.vim


*** ../vim-7.4.2111/src/evalfunc.c  2016-07-24 21:58:39.696057708 +0200
--- src/evalfunc.c  2016-07-28 22:39:54.940632865 +0200
***
*** 4164,4171 
  {
  char_u*pat;
  expand_T  xpc;
! int   options = WILD_KEEP_ALL | WILD_SILENT | WILD_USE_NL
! | WILD_LIST_NOTFOUND | WILD_NO_BEEP;
  
  if (p_wic)
options |= WILD_ICASE;
--- 4164,4171 
  {
  char_u*pat;
  expand_T  xpc;
! int   options = WILD_SILENT | WILD_USE_NL | WILD_ADD_SLASH
!   | WILD_NO_BEEP;
  
  if (p_wic)
options |= WILD_ICASE;
***
*** 4194,4200 
  pat = addstar(xpc.xp_pattern, xpc.xp_pattern_len, xpc.xp_context);
  if ((rettv_list_alloc(rettv) != FAIL) && (pat != NULL))
  {
!   int i;
  
ExpandOne(, pat, NULL, options, WILD_ALL_KEEP);
  
--- 4194,4200 
  pat = addstar(xpc.xp_pattern, xpc.xp_pattern_len, xpc.xp_context);
  if ((rettv_list_alloc(rettv) != FAIL) && (pat != NULL))
  {
!   int i;
  
ExpandOne(, pat, NULL, options, WILD_ALL_KEEP);
  
*** ../vim-7.4.2111/src/testdir/test_cmdline.vim2016-07-23 
15:47:29.042684295 +0200
--- src/testdir/test_cmdline.vim2016-07-28 22:49:43.523181542 +0200
***
*** 47,99 
  
let l = getcompletion('v:n', 'var')
call assert_true(index(l, 'v:null') >= 0)
  
let l = getcompletion('', 'augroup')
call assert_true(index(l, 'END') >= 0)
  
let l = getcompletion('', 'behave')
call assert_true(index(l, 'mswin') >= 0)
  
let l = getcompletion('', 'color')
call assert_true(index(l, 'default') >= 0)
  
let l = getcompletion('', 'command')
call assert_true(index(l, 'sleep') >= 0)
  
let l = getcompletion('', 'dir')
!   call assert_true(index(l, 'samples') >= 0)
  
let l = getcompletion('exe', 'expression')
call assert_true(index(l, 'executable(') >= 0)
  
let l = getcompletion('tag', 'function')
call assert_true(index(l, 'taglist(') >= 0)
  
let Flambda = {-> 'hello'}
let l = getcompletion('', 'function')
let l = filter(l, {i, v -> v =~ 'lambda'})
!   call assert_equal(0, len(l))
  
let l = getcompletion('run', 'file')
call assert_true(index(l, 'runtest.vim') >= 0)
  
let l = getcompletion('ha', 'filetype')
call assert_true(index(l, 'hamster') >= 0)
  
let l = getcompletion('z', 'syntax')
call assert_true(index(l, 'zimbu') >= 0)
  
let l = getcompletion('jikes', 'compiler')
call assert_true(index(l, 'jikes') >= 0)
  
let l = getcompletion('last', 'help')
call assert_true(index(l, ':tablast') >= 0)
  
let l = getcompletion('time', 'option')
call assert_true(index(l, 'timeoutlen') >= 0)
  
let l = getcompletion('er', 'highlight')
call assert_true(index(l, 'ErrorMsg') >= 0)
  
" For others test if the name is recognized.
let names = ['buffer', 'environment', 'file_in_path',
--- 47,129 
  
let l = getcompletion('v:n', 'var')
call assert_true(index(l, 'v:null') >= 0)
+   let l = getcompletion('v:notexists', 'var')
+   call assert_equal([], l)
  
let l = getcompletion('', 'augroup')
call assert_true(index(l, 'END') >= 0)
+   let l = getcompletion('blahblah', 'augroup')
+   call assert_equal([], l)
  
let l = getcompletion('', 'behave')
call assert_true(index(l, 'mswin') >= 0)
+   let l = getcompletion('not', 'behave')
+   call assert_equal([], l)
  
let l = getcompletion('', 'color')
call assert_true(index(l, 'default') >= 0)
+   let l = getcompletion('dirty', 'color')
+   call assert_equal([], l)
  
let l = getcompletion('', 'command')
call assert_true(index(l, 'sleep') >= 0)
+   let l = getcompletion('awake', 'command')
+   call assert_equal([], l)
  
let l = getcompletion('', 'dir')
!   call assert_true(index(l, 'samples/') >= 0)
!   let l = getcompletion('NoMatch', 'dir')
!   call assert_equal([], l)
  
let l = getcompletion('exe', 'expression')
call assert_true(index(l, 'executable(') >= 0)
+   let l = getcompletion('kill', 'expression')
+   call assert_equal([], l)
  
let l = getcompletion('tag', 'function')
call assert_true(index(l, 'taglist(') >= 0)
+   let l = getcompletion('paint', 'function')
+   call assert_equal([], l)
  
let Flambda = {-> 'hello'}
let l = getcompletion('', 'function')
let l = filter(l, {i, v -> v =~ 'lambda'})
!   call assert_equal([], l)
  
let l = getcompletion('run', 'file')
call assert_true(index(l, 'runtest.vim') >= 0)
+   

Re: Changing the defaults with Vim 8

[Martin Lundberg]

On Thursday, July 28, 2016 at 4:32:31 PM UTC+2, ZyX wrote:
> You can’t. “At the same time” may mean both “ pressed slightly
> after  press  after  is in par with `Q`: `g` and `q` use different fingers and they need to
> be pressed in specific sequence as well. `Q` may actually be worse if
> you are trying to press this as fast as possible: you must release  after pressing , but it does not matter when you release  and
> , only when you press them matters.
> 
> Also depends on keyboard and layout: dvorak has  and  on
> different hands, while  and  is harder to use on my keyboard because it has <\> before it which is
> not uncommon, so I tend to avoid it, mostly using for `":<>` (us:
> `ZQWE`), even A (us: A, one of two keys which match in us and dvorak
> layouts) is typed using left shift).
> 
> Note: unlike @Martin Lundberg I see that typing `gq` using *two* hands
> is *faster* then typing `Q` using *one*. I tried and can type `Q` with
> two hands faster then with one, but this makes following text slower
> (both because I am not used and because restoring little finger
> position from far  text follows `Q`).
> 
> And, if I am not mistaking, requirement to *switch* hands for common
> letter combinations is one of the reasons why typing with dvorak is
> *faster*. So “involving two hands” could be a word for `Q`, not for me
> though due to my far right shift.

It's also not just about hitting gq or Shift-Q but being ready for the motion 
too. I mostyly do gqj, gqip, etc and that is a lot faster when not moving for 
SHIFT. However as Bram said, people who has a .vimrc won't be affected and if 
I'm the only one feeling like this then nevermind :)

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

[Bram Moolenaar]

Patch 7.4.2111
Problem:Defaults are very conservative.
Solution:   Move settings from vimrc_example.vim to defaults.vim.  Load
defaults.vim if no .vimrc was found.
Files:  src/main.c, src/version.c, src/os_amiga.h, src/os_dos.h,
src/os_mac.h, src/os_unix.h, src/feature.h, src/Makefile,
runtime/vimrc_example.vim, runtime/defaults.vim,
runtime/evim.vim, Filelist, runtime/doc/starting.txt


*** ../vim-7.4.2110/src/main.c  2016-07-24 21:58:39.708057598 +0200
--- src/main.c  2016-07-28 21:07:56.144272774 +0200
***
*** 2997,3007 
   DOSO_VIMRC) == FAIL
  #endif
&& process_env((char_u *)"EXINIT", FALSE) == FAIL
!   && do_source((char_u *)USR_EXRC_FILE, FALSE, DOSO_NONE) == FAIL)
!   {
  #ifdef USR_EXRC_FILE2
!   (void)do_source((char_u *)USR_EXRC_FILE2, FALSE, DOSO_NONE);
  #endif
}
}
  
--- 2997,3010 
   DOSO_VIMRC) == FAIL
  #endif
&& process_env((char_u *)"EXINIT", FALSE) == FAIL
!   && do_source((char_u *)USR_EXRC_FILE, FALSE, DOSO_NONE) == FAIL
  #ifdef USR_EXRC_FILE2
!   && do_source((char_u *)USR_EXRC_FILE2, FALSE, DOSO_NONE) == FAIL
  #endif
+   )
+   {
+   /* When no .vimrc file was found: source defaults.vim. */
+   do_source((char_u *)VIM_DEFAULTS_FILE, FALSE, DOSO_NONE);
}
}
  
***
*** 3009,3015 
 * Read initialization commands from ".vimrc" or ".exrc" in current
 * directory.  This is only done if the 'exrc' option is set.
 * Because of security reasons we disallow shell and write commands
!* now, except for unix if the file is owned by the user or 'secure'
 * option has been reset in environment of global ".exrc" or ".vimrc".
 * Only do this if VIMRC_FILE is not the same as USR_VIMRC_FILE or
 * SYS_VIMRC_FILE.
--- 3012,3018 
 * Read initialization commands from ".vimrc" or ".exrc" in current
 * directory.  This is only done if the 'exrc' option is set.
 * Because of security reasons we disallow shell and write commands
!* now, except for Unix if the file is owned by the user or 'secure'
 * option has been reset in environment of global ".exrc" or ".vimrc".
 * Only do this if VIMRC_FILE is not the same as USR_VIMRC_FILE or
 * SYS_VIMRC_FILE.
*** ../vim-7.4.2110/src/version.c   2016-07-28 22:08:18.682287202 +0200
--- src/version.c   2016-07-28 22:17:04.565351251 +0200
***
*** 5349,5354 
--- 5351,5359 
  version_msg("\"\n");
  # endif
  #endif
+ version_msg(_("   defaults file: \""));
+ version_msg(VIM_DEFAULTS_FILE);
+ version_msg("\"\n");
  #ifdef FEAT_GUI
  # ifdef SYS_MENU_FILE
  version_msg(_("system menu file: \""));
*** ../vim-7.4.2110/src/os_amiga.h  2016-01-30 21:48:44.329034406 +0100
--- src/os_amiga.h  2016-07-28 21:11:30.538260666 +0200
***
*** 160,165 
--- 160,168 
  #ifndef USR_VIMRC_FILE4
  # define USR_VIMRC_FILE4 "$VIM/.vimrc"
  #endif
+ #ifndef VIM_DEFAULTS_FILE
+ # define VIM_DEFAULTS_FILE "$VIMRUNTIME/defaults.vim"
+ #endif
  #ifndef EVIM_FILE
  # define EVIM_FILE"$VIMRUNTIME/evim.vim"
  #endif
*** ../vim-7.4.2110/src/os_dos.h2013-12-07 14:32:04.0 +0100
--- src/os_dos.h2016-07-28 21:12:03.717949346 +0200
***
*** 25,30 
--- 25,33 
  #ifndef USR_VIMRC_FILE3
  # define USR_VIMRC_FILE3  "$VIM\\_vimrc"
  #endif
+ #ifndef VIM_DEFAULTS_FILE
+ # define VIM_DEFAULTS_FILE"$VIMRUNTIME\\defaults.vim"
+ #endif
  #ifndef EVIM_FILE
  # define EVIM_FILE"$VIMRUNTIME\\evim.vim"
  #endif
*** ../vim-7.4.2110/src/os_mac.h2013-11-02 21:04:32.0 +0100
--- src/os_mac.h2016-07-28 21:12:31.245691072 +0200
***
*** 139,144 
--- 139,147 
  #ifndef SYS_OPTWIN_FILE
  #  define SYS_OPTWIN_FILE "$VIMRUNTIME/optwin.vim"
  #endif
+ #ifndef VIM_DEFAULTS_FILE
+ #  define VIM_DEFAULTS_FILE "$VIMRUNTIME/defaults.vim"
+ #endif
  #ifndef EVIM_FILE
  #  define EVIM_FILE   "$VIMRUNTIME/evim.vim"
  #endif
*** ../vim-7.4.2110/src/os_unix.h   2016-07-16 14:46:51.135240543 +0200
--- src/os_unix.h   2016-07-28 21:13:02.849394574 +0200
***
*** 303,308 
--- 303,312 
  # endif
  #endif
  
+ #ifndef VIM_DEFAULTS_FILE
+ # define VIM_DEFAULTS_FILE "$VIMRUNTIME/defaults.vim"
+ #endif
+ 
  #ifndef EVIM_FILE
  # define EVIM_FILE"$VIMRUNTIME/evim.vim"
  #endif
*** ../vim-7.4.2110/src/feature.h   2016-07-16 14:46:51.123240668 +0200
--- src/feature.h   2016-07-28 21:13:53.260921660 +0200
***
*** 906,911 
--- 906,916 
  /* #define USR_VIMRC_FILE3"$VIM/.vimrc" */
  
  /*
+  * VIM_DEFAULTS_FILE  Name of 

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

I wrote:

[...]

> Another solution: When there is a .vimrc, then don't load startup.vim.
> Rely on the user already have his preferences in the .vimrc.
> Thus only apply these better defaults when the user doesn't have his own
> settings.  Ah, I see Ben also had this idea.
> 
> The more I think about it, the more this seems like a good solution:
> - If the user has a .vimrc, use that.
> - If there is no .vimrc, use the default .vimrc.
> - When a new user creates a .vimrc, he can source the default one or
>   copy it.  It's possible to do settings before this, such as adding 'M'
>   to 'guioptions'.
> 
> That way anybody which already has a .vimrc isn't bothered by different
> defaults.  100% backwards compatible.
> 
> New users will get better defaults.  When using Vim on a new system it
> also has better defaults.
> 
> Only those who really want the Vi defaults or the Vim 7 defaults would
> need to create a .vimrc and set 'compatible' or 'nocompatible'.
> 
> There is some confusion for users who create their .vimrc for the
> first time and don't know about the default vimrc.  That can be
> documented and once discovered it's easy to fix.

I haven't heard negative comments for this idea, I'll interpret that as a
positive response.  I suppose all of the readers here have a .vimrc,
thus won't be affected by the change.  And new users will like (most of)
the new defaults.

I'll send out a patch to do it this way.  We can fine tune after that.

-- 
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]

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

[Bram Moolenaar]

Patch 7.4.2110
Problem:When there is an CmdUndefined autocmd then the error for a missing
command is E464 instead of E492. (Manuel Ortega)
Solution:   Don't let the pointer be NULL.
Files:  src/ex_docmd.c, src/testdir/test_usercommands.vim


*** ../vim-7.4.2109/src/ex_docmd.c  2016-07-24 21:58:39.700057671 +0200
--- src/ex_docmd.c  2016-07-28 20:29:58.821512097 +0200
***
*** 2343,2349 
vim_free(p);
/* If the autocommands did something and didn't cause an error, try
 * finding the command again. */
!   p = (ret && !aborting()) ? find_command(, NULL) : NULL;
  }
  #endif
  
--- 2343,2349 
vim_free(p);
/* If the autocommands did something and didn't cause an error, try
 * finding the command again. */
!   p = (ret && !aborting()) ? find_command(, NULL) : ea.cmd;
  }
  #endif
  
*** ../vim-7.4.2109/src/testdir/test_usercommands.vim   2016-06-04 
22:08:38.881905472 +0200
--- src/testdir/test_usercommands.vim   2016-07-28 22:06:38.231231588 +0200
***
*** 46,48 
--- 46,78 
delcommand MyQCmd
unlet g:mods
  endfunction
+ 
+ func Test_Ambiguous()
+   command Doit let g:didit = 'yes'
+   command Dothat let g:didthat = 'also'
+   call assert_fails('Do', 'E464:')
+   Doit
+   call assert_equal('yes', g:didit)
+   Dothat
+   call assert_equal('also', g:didthat)
+   unlet g:didit
+   unlet g:didthat
+ 
+   delcommand Doit
+   Do
+   call assert_equal('also', g:didthat)
+   delcommand Dothat
+ endfunc
+ 
+ func Test_CmdUndefined()
+   call assert_fails('Doit', 'E492:')
+   au CmdUndefined Doit :command Doit let g:didit = 'yes'
+   Doit
+   call assert_equal('yes', g:didit)
+   delcommand Doit
+ 
+   call assert_fails('Dothat', 'E492:')
+   au CmdUndefined * let g:didnot = 'yes'
+   call assert_fails('Dothat', 'E492:')
+   call assert_equal('yes', g:didnot)
+ endfunc
*** ../vim-7.4.2109/src/version.c   2016-07-27 23:26:00.78261 +0200
--- src/version.c   2016-07-28 22:07:35.786690465 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2110,
  /**/

-- 
A special law prohibits unmarried women from parachuting on Sunday or she
shall risk arrest, fine, and/or jailing.
[real standing law in Florida, United States of America]

 /// 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: Wish list for a more powerful search in Vim

[Bram Moolenaar]

Christian Brabandt wrote:

> Hi Yegappan,
> attached is an updated patch, that fixes a couple of bugs. Especially, 
> using a pattern that uses the \? atom and then jumping backwards did not 
> work. This is fixed now.
> 
> On Di, 26 Jul 2016, Yegappan Lakshmanan wrote:
> 
> > 1. When pressing CTRL-N or CTRL-P to jump to the next/previous match,
> >the 'nowrapscan' setting is ignored and the search wraps around
> >the file.
> 
> not fixed, because I am not sure it should really consider the wrapscan 
> setting.

I think it should.  Most users will have 'wrapscan' on, since it is the
default.  If someone switches it off he must have a reason for it.

> > 2. After pressing CTRL-N couple of times, erasing the entire search pattern
> >and typing a new pattern doesn't search from the original cursor
> >position. Instead the search starts from the last matched position.
> 
> should be fixed now.
> 
> > 3. Searching for a pattern, pressing CTRL-N (which doesn't find a
> >next match) and then pressing CTRL-L to copy the next character
> >from under the cursor doesn't work and also the search highlighting
> >is removed.
> 
> I don't understand that problem or I cannot reproduce it. Can you give 
> me a reproducible example, together with the buffer contents?

-- 
You can be stopped by the police for biking over 65 miles per hour.
You are not allowed to walk across a street on your hands.
[real standing laws in Connecticut, United States of America]

 /// 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: Wish list for a more powerful search in Vim

[Christian Brabandt]

Hi Yegappan,
attached is an updated patch, that fixes a couple of bugs. Especially, 
using a pattern that uses the \? atom and then jumping backwards did not 
work. This is fixed now.

On Di, 26 Jul 2016, Yegappan Lakshmanan wrote:

> 1. When pressing CTRL-N or CTRL-P to jump to the next/previous match,
>the 'nowrapscan' setting is ignored and the search wraps around
>the file.

not fixed, because I am not sure it should really consider the wrapscan 
setting.

> 2. After pressing CTRL-N couple of times, erasing the entire search pattern
>and typing a new pattern doesn't search from the original cursor
>position. Instead the search starts from the last matched position.

should be fixed now.

> 3. Searching for a pattern, pressing CTRL-N (which doesn't find a
>next match) and then pressing CTRL-L to copy the next character
>from under the cursor doesn't work and also the search highlighting
>is removed.

I don't understand that problem or I cannot reproduce it. Can you give 
me a reproducible example, together with the buffer contents?

Best,
Christian
-- 
Wir sind die Menschen, vor denen uns unsere Eltern gewarnt haben.

-- 
-- 
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 1bacaae1141826ebb6e2611f423aedee2854febc Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Tue, 26 Jul 2016 11:18:51 +0200
Subject: [PATCH] Make Ctrl-N/P jump to next/previous search match

Currently, you cannot move from one match to the next match
when doing a search '/' or '?'.
This patch adds the functionality to use 'Ctrl-N' to move the
cursor to the next match, if 'insearch' is set. Similarily 'Ctrl-P' will
move to the previous match.

Also c_CTRL-N and c_CTRL-P are already used to move within in history of
search patterns, I have for now made them something different in search
mode, when incsearch is set. This is because c_CTRL-L already does
something useful in search mode and second, because Ctrl-N and
Ctrl-P are already used to select next/previous match in completion mode
so it seems logically to also extend their use in search mode.

Bugfixes: - works correctly with Ctrl-P after ? search
  - after clearing the search command line, starts searching
	back at the original position
	  - works correctly, when using \? in a forward search / and
	then jumping backwards using Ctrl-P
---
 runtime/doc/cmdline.txt |  9 +
 src/ex_getln.c  | 97 -
 2 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/runtime/doc/cmdline.txt b/runtime/doc/cmdline.txt
index 8186678..83bec9e 100644
--- a/runtime/doc/cmdline.txt
+++ b/runtime/doc/cmdline.txt
@@ -409,11 +409,19 @@ CTRL-D		List names that match the pattern in front of the cursor.
 			*c_CTRL-N*
 CTRL-N		After using 'wildchar' which got multiple matches, go to next
 		match.  Otherwise recall more recent command-line from history.
+		*/_CTRL-N*
+		When 'incsearch' is set, entering a search pattern for "/" or
+		"?" and the current match is displayed then CTRL-N will move
+		to the next match (does not take |search-offset| into account)
 			*c_CTRL-P* *c_*
 CTRL-P		After using 'wildchar' which got multiple matches, go to
 		previous match.  Otherwise recall older command-line from
 		history.   only works with the GUI, on the Amiga and
 		with MS-DOS.
+		*/_CTRL-P*
+		When 'incsearch' is set, entering a search pattern for "/" or
+		"?" and the current match is displayed then CTRL-N will move
+		to the previous match (does not take |search-offset| into account).
 			*c_CTRL-A*
 CTRL-A		All names that match the pattern in front of the cursor are
 		inserted.
@@ -423,6 +431,7 @@ CTRL-L		A match is done on the pattern in front of the cursor.  If
 		If there are multiple matches the longest common part is
 		inserted in place of the pattern.  If the result is shorter
 		than the pattern, no completion is done.
+			*/_CTRL-L*
 		When 'incsearch' is set, entering a search pattern for "/" or
 		"?" and the current match is displayed then CTRL-L will add
 		one character from the end of the current match.  If
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 642e090..1c1e421 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -178,6 +178,8 @@ getcmdline(
 colnr_T	old_curswant;
 colnr_T	old_leftcol;
 linenr_T	old_topline;
+int		did_incs_move = FALSE;
+pos_T   cursor_start;
 # ifdef FEAT_DIFF
 int		old_topfill;
 # endif
@@ 

Re: Got E121: Undefined variable in lambda function

[Bram Moolenaar]

Ken Takata wrote:

> 2016/7/28 Thu 7:06:31 UTC+9 Ken Takata wrote:
> > Hi,
> > 
> > 2016/7/28 Thu 0:57:53 UTC+9 Bram Moolenaar wrote:
> > > Ken Takata wrote:
> > > 
> > > > 2016/7/25 Mon 23:02:25 UTC+9 Ken Takata wrote:
> > > > > Hi,
> > > > > 
> > > > > 2016/7/25 Mon 3:47:51 UTC+9 Ken Takata wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > 2016/7/22 Fri 22:29:33 UTC+9 Ken Takata wrote:
> > > > > > > Hi ZyX,
> > > > > > > 
> > > > > > > 2016/7/22 Fri 20:15:33 UTC+9 ZyX wrote:
> > > > > > > > >> I was wrong regarding the consequences and why you should 
> > > > > > > > >> alter the
> > > > > > > > >> GC: it is not memory leak because cycle is not GC’d. It is 
> > > > > > > > >> *crash*
> > > > > > > > >> because Vim does not know that dictionary is referenced:
> > > > > > > > >>
> > > > > > > > >> ```VimL
> > > > > > > > >> function F()
> > > > > > > > >> let d = {}
> > > > > > > > >> return {-> d}
> > > > > > > > >> endfunction
> > > > > > > > >> let L = F()
> > > > > > > > >> call garbagecollect(1)
> > > > > > > > >> call feedkeys(":echo L()\n", 'n')
> > > > > > > > >> ```
> > > > > > > > >>
> > > > > > > > >> Save to `test.vim` and run as `vim -u NONE -i NONE -N -S 
> > > > > > > > >> test.vim`.
> > > > > > > > >> When I use it in Vim with optimizations it crashes 
> > > > > > > > >> immediately:
> > > > > > > 
> > > > > > > Yes, I also noticed this. I tested with the following script:
> > > > > > > 
> > > > > > >   function! Test_lambda_closure()
> > > > > > > function! s:foo()
> > > > > > >   let x = [0]
> > > > > > >   return {-> [execute("let x[0] += 1"), x[0]][-1]}
> > > > > > > endfunction
> > > > > > >   
> > > > > > > let l:F = s:foo()
> > > > > > > call test_garbagecollect_now()
> > > > > > > call assert_equal(1, l:F())
> > > > > > > call assert_equal(2, l:F())
> > > > > > > call assert_equal(3, l:F())
> > > > > > > call assert_equal(4, l:F())
> > > > > > >   endfunction
> > > > > > > 
> > > > > > > I have updated the patch:
> > > > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/52c8d4fd0af2dd8bd2c79204dbbedd9ded874439/lambda-update.patch?at=default
> > > > > > > 
> > > > > > > Now it deals with GC. Also add some tests, reduce memory when 
> > > > > > > local variables
> > > > > > > or arguments are not used.
> > > > > > 
> > > > > > I have slightly updated the tests:
> > > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/5f8f4f212a09b1fa58a939f34559c7b3c88bb616/lambda-update.patch?at=default
> > > > > > 
> > > > > > It seems work well. BTW, I'm thinking the implementation again.
> > > > > > I thought that capture by value is easier to implement, but it is 
> > > > > > harder to
> > > > > > apply to normal functions inside a function. Capture by reference 
> > > > > > seems easier
> > > > > > to apply to normal functions.
> > > > > > 
> > > > > > I read the comment for mattn's implementation by Bram again:
> > > > > > 
> > > > > > > In the implementation it seems the dictionary storing the 
> > > > > > > function-local
> > > > > > > variables is kept for a very long time. This relies on the garbage
> > > > > > > collector. It's better to use reference counting to be able to 
> > > > > > > free the
> > > > > > > dictionary as soon as it's unused.
> > > > > > > 
> > > > > > > Also, the lambda always keeps the function-local variable dict, 
> > > > > > > even
> > > > > > > when it's not actually used. That makes lambdas a expensive.
> > > > > > > It would be better to explicitly state the lambda is using its 
> > > > > > > context.
> > > > > > > Then we can also do that with ":function", so that we are not 
> > > > > > > forced to
> > > > > > > use a lambda if we want a closure.
> > > > > > 
> > > > > > Checking if a lambda is a closure is now available with my patch.
> > > > > > So I tried to implement reference counting based on mattn's patch.
> > > > > > Unfortunately it doesn't work well yet. I need help for this.
> > > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/5f8f4f212a09b1fa58a939f34559c7b3c88bb616/lambda-capture_by_reference-temp.patch?at=default
> > > > > > (This patch should be applied after the above patch 
> > > > > > (lambda-update.patch).)
> > > > > > Test_circular_reference() in test_lambda.vim doesn't work well.
> > > > > > 
> > > > > > Which is better, capture by value or by reference?
> > > > > 
> > > > > I have updated the patches.
> > > > > 
> > > > > Capture by value:
> > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/05cb2721d17d4b1c52b603037e3ec65e523b472d/lambda-update.patch?at=default
> > > > > 
> > > > > Capture by reference:
> > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/05cb2721d17d4b1c52b603037e3ec65e523b472d/lambda-capture_by_reference.patch?at=default
> > > > > (Apply on top of lambda-update.patch)
> > > > > 
> > > > > Now both seem to work almost good.
> > > > > And I wrote another patch to support closure with normal functions:
> > > > > 

Re: Bug in CmdUndefined re error messages

[Bram Moolenaar]

Manuel Ortega wrote:

> If you try to run a nonexistent user command while there is an
> installed CmdUndefined autocmd, Vim will show the wrong error message.
> It shows E464 instead of E492.  Here is a minimal example.
> 
> $ vim -u NONE -N
> 
> Now do:
> 
>   au CmdUndefined Snowflake echo "FOO"
> 
> Now do:
> 
>   :Hanky
> 
> What I expect to see is "E492: Not an editor command: Hanky".  This
> is, of course, what would be shown had I not made a CmdUndefined
> autocmd.
> 
> What I actually see is: "E464: Ambiguous use of user-defined command",
> which seems wrong.  "Hanky" is not ambiguous between multiple
> user-defined commands, as there are no user-defined commands.  "Hanky"
> is also not a substring of "Snowflake", either, nor did I hit ,
> so I don't see why there would be any autocompletion issues to worry
> about.

Yes, that is wrong.  I also don't see a test for CmdUndefined.

-- 
Every person is responsible for the choices he makes.

 /// 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: Changing the defaults with Vim 8

[Nikolay Aleksandrovich Pavlov]

2016-07-28 16:58 GMT+03:00 Bram Moolenaar :
>
> Martin Lundberg wrote:
>
>> On Tuesday, July 26, 2016 at 11:18:01 PM UTC+2, Bram Moolenaar wrote:
>> > " Don't use Ex mode, use Q for formatting
>> > map Q gq
>>
>> What's the reason for doing this change when the new mapping has just
>> as much key presses? For me it actually feels like it's slower than gq
>> since I need to involve and move both hands.
>>
>> I can see in the help for gq that Q actually did gq before which could
>> be a reason to change it back but I guess there was a reason for
>> changing it to gq too?
>
> It's an old alias for formatting.  "Q" was made Posix compatible at some
> point to make it pass some tests.
>
> I don't see Q as two key strokes, I have two fingers that I can use at
> the same time.

You can’t. “At the same time” may mean both “ pressed slightly
after ` (us:
`ZQWE`), even A (us: A, one of two keys which match in us and dvorak
layouts) is typed using left shift).

Note: unlike @Martin Lundberg I see that typing `gq` using *two* hands
is *faster* then typing `Q` using *one*. I tried and can type `Q` with
two hands faster then with one, but this makes following text slower
(both because I am not used and because restoring little finger
position from far 
> --
> BEDEVERE: How do you know so much about swallows?
> ARTHUR:   Well you have to know these things when you're a king, you know.
>  "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.

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