Re: E16 for invalid regex range is not intuitive

[itchyny]

2017年5月16日火曜日 21時14分32秒 UTC+9 itc...@hatena.ne.jp:
> 2017年5月16日火曜日 14時36分04秒 UTC+9 Bram Moolenaar:
> > > 2017年5月11日木曜日 21時52分48秒 UTC+9 Bram Moolenaar:
> > > > Ken Hamada wrote:
> > > > 
> > > > > Hi list, I noticed that E16 occurs with regexp.
> > > > > 
> > > > > set re=1
> > > > > echo '' =~# '[\uff-\uf0]'
> > > > > E16: Invalid range
> > > > > echo '' =~# '[\u3000-\u4000]'
> > > > > E16: Invalid range
> > > > > 
> > > > > I think this is unintuitive error message because E16 reminds us the 
> > > > > range of
> > > > > commands (for example :0buffer). So I suggest two exclusive options:
> > > > > 
> > > > > - Add a note that the error can occur with regexp at :h E16.
> > > > > - Change the error message and number.
> > > > 
> > > > From the old days a bit of memory was saved by limiting the number of
> > > > error messages.  Now that we are more interested in useful errors,
> > > > splitting off specific cases is useful.
> > > > 
> > > > > BTW the behaviour *Limit to a range of 256 chars* differs due to the
> > > > > regex engine version.
> > > > > I could not tell the difference until I dived into the source code. I
> > > > > would like some warning to be written regarding this topic around :h
> > > > > /[.
> > > > 
> > > > I thought this was mentioned somewhere, but can't find it right now.
> > > > Please suggest an improvement.
> > > 
> > > Thank you Bram and Ken Tanaka.
> > > 
> > > I think creating a new error number will be better.
> > > Here's the patch. What do you think?
> > 
> > Now that we are at it, we can make it more specific: One error for the
> > reverse range and one for a too large range.
> > 
> > It's also nice to have a test for these.
> 
> Thank you Bram for your advice.
> 
> I updated the patch and added some tests.
> 
> diff --git a/runtime/doc/pattern.txt b/runtime/doc/pattern.txt
> index d6764096a..d487a3d65 100644
> --- a/runtime/doc/pattern.txt
> +++ b/runtime/doc/pattern.txt
> @@ -1075,13 +1075,16 @@ x A single character, with no special meaning, 
> matches itself
>   `:substitute` command the whole command becomes the pattern.  E.g.
>   ":s/[/x/" searches for "[/x" and replaces it with nothing.  It does
>   not search for "[" and replaces it with "x"!
> -
> + *E944* *E945*
>   If the sequence begins with "^", it matches any single character NOT
>   in the collection: "[^xyz]" matches anything but 'x', 'y' and 'z'.
>   - If two characters in the sequence are separated by '-', this is
> shorthand for the full list of ASCII characters between them.  E.g.,
> -   "[0-9]" matches any decimal digit.  Non-ASCII characters can be
> -   used, but the character values must not be more than 256 apart.
> +   "[0-9]" matches any decimal digit. If the starting character exceeds
> +   the ending character like [c-a], E944 occurs. Non-ASCII characters
> +   can be used, but the character values must not be more than 256 apart
> +   in the old regexp engine. For example, searching by [\u3000-\u4000]
> +   after setting re=1 emits E945 error. Prepending \%#=2 will fix it.
>   - A character class expression is evaluated to the set of characters
> belonging to that character class.  The following character classes
> are supported:
> diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
> index 0736ada58..3b9356073 100644
> --- a/runtime/doc/todo.txt
> +++ b/runtime/doc/todo.txt
> @@ -930,8 +930,6 @@ Patch to handle integer overflow. (Aaron Burrow, 2013 Dec 
> 12)
>  Patch to add "ntab" item in 'listchars' to repeat first character. (Nathaniel
>  Braun, pragm, 2013 Oct 13)  A better solution 2014 Mar 5.
>  
> -/[b-a] gives error E16, should probably be E769.
> -
>  7   Windows XP: When using "ClearType" for text smoothing, a column of yellow
>  pixels remains when typing spaces in front of a "D" ('guifont' set to
>  "lucida_console:h8").
> diff --git a/src/regexp.c b/src/regexp.c
> index e1f6484c0..93507a73a 100644
> --- a/src/regexp.c
> +++ b/src/regexp.c
> @@ -358,6 +358,8 @@ static char_u *regprop(char_u *);
>  static int re_mult_next(char *what);
>  
>  static char_u e_missingbracket[] = N_("E769: Missing ] after %s[");
> +static char_u e_reversed_range[] = N_("E944: Reversed range in character 
> class");
> +static char_u e_large_class[] = N_("E945: Too large range in character 
> class");
>  static char_u e_unmatchedpp[] = N_("E53: Unmatched %s%%(");
>  static char_u e_unmatchedp[] = N_("E54: Unmatched %s(");
>  static char_u e_unmatchedpar[] = N_("E55: Unmatched %s)");
> @@ -2426,14 +2428,14 @@ collection:
>   endc = coll_get_char();
>  
>   if (startc > endc)
> - EMSG_RET_NULL(_(e_invrange));
> + EMSG_RET_NULL(_(e_reversed_range));
>  #ifdef FEAT_MBYTE
>   if (has_mbyte && ((*mb_char2len)(startc) > 1
> 

Re: E16 for invalid regex range is not intuitive

[itchyny]

2017年5月16日火曜日 14時36分04秒 UTC+9 Bram Moolenaar:
> > 2017年5月11日木曜日 21時52分48秒 UTC+9 Bram Moolenaar:
> > > Ken Hamada wrote:
> > > 
> > > > Hi list, I noticed that E16 occurs with regexp.
> > > > 
> > > > set re=1
> > > > echo '' =~# '[\uff-\uf0]'
> > > > E16: Invalid range
> > > > echo '' =~# '[\u3000-\u4000]'
> > > > E16: Invalid range
> > > > 
> > > > I think this is unintuitive error message because E16 reminds us the 
> > > > range of
> > > > commands (for example :0buffer). So I suggest two exclusive options:
> > > > 
> > > > - Add a note that the error can occur with regexp at :h E16.
> > > > - Change the error message and number.
> > > 
> > > From the old days a bit of memory was saved by limiting the number of
> > > error messages.  Now that we are more interested in useful errors,
> > > splitting off specific cases is useful.
> > > 
> > > > BTW the behaviour *Limit to a range of 256 chars* differs due to the
> > > > regex engine version.
> > > > I could not tell the difference until I dived into the source code. I
> > > > would like some warning to be written regarding this topic around :h
> > > > /[.
> > > 
> > > I thought this was mentioned somewhere, but can't find it right now.
> > > Please suggest an improvement.
> > 
> > Thank you Bram and Ken Tanaka.
> > 
> > I think creating a new error number will be better.
> > Here's the patch. What do you think?
> 
> Now that we are at it, we can make it more specific: One error for the
> reverse range and one for a too large range.
> 
> It's also nice to have a test for these.

Thank you Bram for your advice.

I updated the patch and added some tests.

diff --git a/runtime/doc/pattern.txt b/runtime/doc/pattern.txt
index d6764096a..d487a3d65 100644
--- a/runtime/doc/pattern.txt
+++ b/runtime/doc/pattern.txt
@@ -1075,13 +1075,16 @@ x   A single character, with no special meaning, 
matches itself
`:substitute` command the whole command becomes the pattern.  E.g.
":s/[/x/" searches for "[/x" and replaces it with nothing.  It does
not search for "[" and replaces it with "x"!
-
+   *E944* *E945*
If the sequence begins with "^", it matches any single character NOT
in the collection: "[^xyz]" matches anything but 'x', 'y' and 'z'.
- If two characters in the sequence are separated by '-', this is
  shorthand for the full list of ASCII characters between them.  E.g.,
- "[0-9]" matches any decimal digit.  Non-ASCII characters can be
- used, but the character values must not be more than 256 apart.
+ "[0-9]" matches any decimal digit. If the starting character exceeds
+ the ending character like [c-a], E944 occurs. Non-ASCII characters
+ can be used, but the character values must not be more than 256 apart
+ in the old regexp engine. For example, searching by [\u3000-\u4000]
+ after setting re=1 emits E945 error. Prepending \%#=2 will fix it.
- A character class expression is evaluated to the set of characters
  belonging to that character class.  The following character classes
  are supported:
diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
index 0736ada58..3b9356073 100644
--- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -930,8 +930,6 @@ Patch to handle integer overflow. (Aaron Burrow, 2013 Dec 
12)
 Patch to add "ntab" item in 'listchars' to repeat first character. (Nathaniel
 Braun, pragm, 2013 Oct 13)  A better solution 2014 Mar 5.
 
-/[b-a] gives error E16, should probably be E769.
-
 7   Windows XP: When using "ClearType" for text smoothing, a column of yellow
 pixels remains when typing spaces in front of a "D" ('guifont' set to
 "lucida_console:h8").
diff --git a/src/regexp.c b/src/regexp.c
index e1f6484c0..93507a73a 100644
--- a/src/regexp.c
+++ b/src/regexp.c
@@ -358,6 +358,8 @@ static char_u   *regprop(char_u *);
 static int re_mult_next(char *what);
 
 static char_u e_missingbracket[] = N_("E769: Missing ] after %s[");
+static char_u e_reversed_range[] = N_("E944: Reversed range in character 
class");
+static char_u e_large_class[] = N_("E945: Too large range in character class");
 static char_u e_unmatchedpp[] = N_("E53: Unmatched %s%%(");
 static char_u e_unmatchedp[] = N_("E54: Unmatched %s(");
 static char_u e_unmatchedpar[] = N_("E55: Unmatched %s)");
@@ -2426,14 +2428,14 @@ collection:
endc = coll_get_char();
 
if (startc > endc)
-   EMSG_RET_NULL(_(e_invrange));
+   EMSG_RET_NULL(_(e_reversed_range));
 #ifdef FEAT_MBYTE
if (has_mbyte && ((*mb_char2len)(startc) > 1
 || (*mb_char2len)(endc) > 1))
{
/* Limit to a range of 256 chars */
if (endc > 

Re: E16 for invalid regex range is not intuitive

[itchyny]

2017年5月11日木曜日 21時52分48秒 UTC+9 Bram Moolenaar:
> Ken Hamada wrote:
> 
> > Hi list, I noticed that E16 occurs with regexp.
> > 
> > set re=1
> > echo '' =~# '[\uff-\uf0]'
> > E16: Invalid range
> > echo '' =~# '[\u3000-\u4000]'
> > E16: Invalid range
> > 
> > I think this is unintuitive error message because E16 reminds us the range 
> > of
> > commands (for example :0buffer). So I suggest two exclusive options:
> > 
> > - Add a note that the error can occur with regexp at :h E16.
> > - Change the error message and number.
> 
> From the old days a bit of memory was saved by limiting the number of
> error messages.  Now that we are more interested in useful errors,
> splitting off specific cases is useful.
> 
> > BTW the behaviour *Limit to a range of 256 chars* differs due to the
> > regex engine version.
> > I could not tell the difference until I dived into the source code. I
> > would like some warning to be written regarding this topic around :h
> > /[.
> 
> I thought this was mentioned somewhere, but can't find it right now.
> Please suggest an improvement.

Thank you Bram and Ken Tanaka.

I think creating a new error number will be better.
Here's the patch. What do you think?

diff --git a/runtime/doc/pattern.txt b/runtime/doc/pattern.txt
index d6764096a..6b7ee46c6 100644
--- a/runtime/doc/pattern.txt
+++ b/runtime/doc/pattern.txt
@@ -1075,13 +1075,15 @@ x   A single character, with no special meaning, 
matches itself
`:substitute` command the whole command becomes the pattern.  E.g.
":s/[/x/" searches for "[/x" and replaces it with nothing.  It does
not search for "[" and replaces it with "x"!
-
+   *E944*
If the sequence begins with "^", it matches any single character NOT
in the collection: "[^xyz]" matches anything but 'x', 'y' and 'z'.
- If two characters in the sequence are separated by '-', this is
  shorthand for the full list of ASCII characters between them.  E.g.,
- "[0-9]" matches any decimal digit.  Non-ASCII characters can be
- used, but the character values must not be more than 256 apart.
+ "[0-9]" matches any decimal digit. If the starting character exceeds
+ the ending character like [c-a], E769 occurs. Non-ASCII characters
+ can be used, but the character values must not be more than 256 apart
+ in the old regexp engine.
- A character class expression is evaluated to the set of characters
  belonging to that character class.  The following character classes
  are supported:
diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
index 0736ada58..3b9356073 100644
--- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -930,8 +930,6 @@ Patch to handle integer overflow. (Aaron Burrow, 2013 Dec 
12)
 Patch to add "ntab" item in 'listchars' to repeat first character. (Nathaniel
 Braun, pragm, 2013 Oct 13)  A better solution 2014 Mar 5.
 
-/[b-a] gives error E16, should probably be E769.
-
 7   Windows XP: When using "ClearType" for text smoothing, a column of yellow
 pixels remains when typing spaces in front of a "D" ('guifont' set to
 "lucida_console:h8").
diff --git a/src/regexp.c b/src/regexp.c
index e1f6484c0..8574fc6f2 100644
--- a/src/regexp.c
+++ b/src/regexp.c
@@ -358,6 +358,7 @@ static char_u   *regprop(char_u *);
 static int re_mult_next(char *what);
 
 static char_u e_missingbracket[] = N_("E769: Missing ] after %s[");
+static char_u e_invalidclass[] = N_("E944: Invalid character class");
 static char_u e_unmatchedpp[] = N_("E53: Unmatched %s%%(");
 static char_u e_unmatchedp[] = N_("E54: Unmatched %s(");
 static char_u e_unmatchedpar[] = N_("E55: Unmatched %s)");
@@ -2426,14 +2427,14 @@ collection:
endc = coll_get_char();
 
if (startc > endc)
-   EMSG_RET_NULL(_(e_invrange));
+   EMSG_RET_NULL(_(e_invalidclass));
 #ifdef FEAT_MBYTE
if (has_mbyte && ((*mb_char2len)(startc) > 1
 || (*mb_char2len)(endc) > 1))
{
/* Limit to a range of 256 chars */
if (endc > startc + 256)
-   EMSG_RET_NULL(_(e_invrange));
+   EMSG_RET_NULL(_(e_invalidclass));
while (++startc <= endc)
regmbc(startc);
}
diff --git a/src/regexp_nfa.c b/src/regexp_nfa.c
index 120861a46..65df8ca78 100644
--- a/src/regexp_nfa.c
+++ b/src/regexp_nfa.c
@@ -1851,7 +1851,7 @@ collection:
endc = startc;
startc = oldstartc;
if (startc > endc)
-   EMSG_RET_FAIL(_(e_invrange));
+

Re: E16 for invalid regex range is not intuitive

[itchyny]

On Thursday, May 11, 2017 at 2:17:40 PM UTC+9, itchyny wrote:
> Hi list, I noticed that E16 occurs with regexp.
> 
> set re=1
> echo '' =~# '[\uff-\uf0]'
> E16: Invalid range

Oops, I mean

echo '' =~# '[\xff-\xf0]'

-- 
-- 
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: E16 for invalid regex range is not intuitive

[itchyny]

2017年5月11日木曜日 14時17分40秒 UTC+9 itchyny:
> Hi list, I noticed that E16 occurs with regexp.
> 
> set re=1
> echo '' =~# '[\uff-\uf0]'

Oops, I mean:

echo '' =~# '[\xff-\xf0]'

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

E16 for invalid regex range is not intuitive

[itchyny]

Hi list, I noticed that E16 occurs with regexp.

set re=1
echo '' =~# '[\uff-\uf0]'
E16: Invalid range
echo '' =~# '[\u3000-\u4000]'
E16: Invalid range

I think this is unintuitive error message because E16 reminds us the range of
commands (for example :0buffer). So I suggest two exclusive options:

- Add a note that the error can occur with regexp at :h E16.
- Change the error message and number.

BTW the behaviour *Limit to a range of 256 chars* differs due to the regex 
engine version.
I could not tell the difference until I dived into the source code. I would 
like some warning
to be written regarding this topic around :h /[.

Thanks in advance,
Ken Hamada

-- 
-- 
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] Get the position of the first non-white character in the current line getpos('^'), col('^')

[itchyny]

Hi list, this is a small patch to grab the column number of the first non-white
character in the current line. I wrote because found in the todo list.

https://gist.github.com/itchyny/22e9871b15eec445ddb8c3a7451222af

Regards,
Ken Hamada (aka itchyny on GitHub)

-- 
-- 
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: stl, stlnc of fillchars are not always applied, depends on difference between StatusLine and StatusLineNC

[itchyny]

On Tuesday, December 13, 2016 at 1:26:30 AM UTC+9, Ozaki Kiichi wrote:
> It is better to add it for an unit test.
> 
> maka -C src test_fillchars


Thank you for your notice, it's surely useful.
Here is the latest patch.

https://gist.github.com/itchyny/936f5c7e7f6396bf2f6afbe246206d47

Regards,
Ken Hamada (aka itchyny)

-- 
-- 
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: stl, stlnc of fillchars are not always applied, depends on difference between StatusLine and StatusLineNC

[itchyny]

> Thank you Bram. I've got the point.
> How about this patch? 
> I noticed the note in syntax.txt but still believe that the patch solves the 
> strange behavior
> that most people will not configure what's going on until look into the 
> source code.
> 

Sorry, there's no need to add the test in Makefile because I added into 
test_alot.vim. I fixed the patch.


diff --git a/runtime/doc/syntax.txt b/runtime/doc/syntax.txt
index 2138f02..9da27a8 100644
--- a/runtime/doc/syntax.txt
+++ b/runtime/doc/syntax.txt
@@ -4991,8 +4991,6 @@ SpellRare Word that is recognized by the spellchecker as 
one that is
 StatusLine status line of current window
*hl-StatusLineNC*
 StatusLineNC   status lines of not-current windows
-   Note: if this is equal to "StatusLine" Vim will use "^^^" in
-   the status line of the current window.
*hl-TabLine*
 TabLinetab pages line, not active tab page label
*hl-TabLineFill*
diff --git a/src/globals.h b/src/globals.h
index 0b6abb0..81b0177 100644
--- a/src/globals.h
+++ b/src/globals.h
@@ -1190,8 +1190,8 @@ EXTERN intlcs_conceal INIT(= ' ');
 #if defined(FEAT_WINDOWS) || defined(FEAT_WILDMENU) || defined(FEAT_STL_OPT) \
|| defined(FEAT_FOLDING)
 /* Characters from 'fillchars' option */
-EXTERN int fill_stl INIT(= ' ');
-EXTERN int fill_stlnc INIT(= ' ');
+EXTERN int fill_stl INIT(= NUL);
+EXTERN int fill_stlnc INIT(= NUL);
 #endif
 #if defined(FEAT_WINDOWS) || defined(FEAT_FOLDING)
 EXTERN int fill_vert INIT(= ' ');
diff --git a/src/screen.c b/src/screen.c
index ee61a01..c4ec1a9 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -10532,13 +10532,11 @@ fillchar_status(int *attr, int is_curwin)
*attr = hl_attr(HLF_SNC);
fill = fill_stlnc;
 }
-/* Use fill when there is highlighting, and highlighting of current
- * window differs, or the fillchars differ, or this is not the
- * current window */
-if (*attr != 0 && ((hl_attr(HLF_S) != hl_attr(HLF_SNC)
-   || !is_curwin || ONE_WINDOW)
-   || (fill_stl != fill_stlnc)))
+/* Use fill when there is highlighting */
+if (fill != NUL && *attr != 0)
return fill;
+if (ONE_WINDOW)
+   return ' ';
 if (is_curwin)
return '^';
 return '=';
diff --git a/src/testdir/test_alot.vim b/src/testdir/test_alot.vim
index d24b97f..abee0eb 100644
--- a/src/testdir/test_alot.vim
+++ b/src/testdir/test_alot.vim
@@ -14,6 +14,7 @@ source test_expand_dllpath.vim
 source test_feedkeys.vim
 source test_file_perm.vim
 source test_fileformat.vim
+source test_fillchars.vim
 source test_filter_cmd.vim
 source test_filter_map.vim
 source test_fnamemodify.vim
diff --git a/src/testdir/test_fillchars.vim b/src/testdir/test_fillchars.vim
new file mode 100644
index 000..b8d5cde
--- /dev/null
+++ b/src/testdir/test_fillchars.vim
@@ -0,0 +1,38 @@
+function! Test_fillchars_stl_stlnc_vert()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_,vert:* nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=15 cterm=NONE guibg=#808080 
guifg=#ff gui=NONE
+  highlight StatusLineNC ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  only! | vnew
+  redrawstatus!
+  call assert_equal('~', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+  echo assert_equal('*', nr2char(screenchar(1, winwidth(0) + 1)))
+endfunction
+
+function! Test_fillchars_stl_stlnc_one_window()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_ nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=15 cterm=NONE guibg=#808080 
guifg=#ff gui=NONE
+  only!
+  redrawstatus!
+  call assert_equal('~', nr2char(screenchar(winheight(0) + 1, 2)))
+endfunction
+
+function! Test_fillchars_same_stl_stlnc_same_highlight()
+  set laststatus=2 statusline=\  fillchars=stl:_,stlnc:_ nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  highlight StatusLineNC ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  only! | vnew
+  redrawstatus!
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+endfunction
+
+function! Test_fillchars_stl_stlnc_highlights_cleared()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_ nosplitright
+  highlight clear StatusLine
+  highlight clear StatusLineNC
+  only! | vnew
+  redrawstatus!
+  call assert_equal('^', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('=', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+endfunction

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are re

Re: stl, stlnc of fillchars are not always applied, depends on difference between StatusLine and StatusLineNC

[itchyny]

termfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  only! | vnew
+  redrawstatus!
+  call assert_equal('~', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+  echo assert_equal('*', nr2char(screenchar(1, winwidth(0) + 1)))
+endfunction
+
+function! Test_fillchars_stl_stlnc_one_window()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_ nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=15 cterm=NONE guibg=#808080 
guifg=#ff gui=NONE
+  only!
+  redrawstatus!
+  call assert_equal('~', nr2char(screenchar(winheight(0) + 1, 2)))
+endfunction
+
+function! Test_fillchars_same_stl_stlnc_same_highlight()
+  set laststatus=2 statusline=\  fillchars=stl:_,stlnc:_ nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  highlight StatusLineNC ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  only! | vnew
+  redrawstatus!
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+endfunction
+
+function! Test_fillchars_stl_stlnc_highlights_cleared()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_ nosplitright
+  highlight clear StatusLine
+  highlight clear StatusLineNC
+  only! | vnew
+  redrawstatus!
+  call assert_equal('^', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('=', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+endfunction
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_,vert:* nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=15 cterm=NONE guibg=#808080 
guifg=#ff gui=NONE
+  highlight StatusLineNC ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  only! | vnew
+  redrawstatus!
+  call assert_equal('~', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+  echo assert_equal('*', nr2char(screenchar(1, winwidth(0) + 1)))
+endfunction
+
+function! Test_fillchars_stl_stlnc_one_window()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_ nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=15 cterm=NONE guibg=#808080 
guifg=#ff gui=NONE
+  only!
+  redrawstatus!
+  call assert_equal('~', nr2char(screenchar(winheight(0) + 1, 2)))
+endfunction
+
+function! Test_fillchars_same_stl_stlnc_same_highlight()
+  set laststatus=2 statusline=\  fillchars=stl:_,stlnc:_ nosplitright
+  highlight StatusLine ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  highlight StatusLineNC ctermbg=8 ctermfg=7 cterm=NONE guibg=#808080 
guifg=#c0c0c0 gui=NONE
+  only! | vnew
+  redrawstatus!
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('_', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+endfunction
+
+function! Test_fillchars_stl_stlnc_highlights_cleared()
+  set laststatus=2 statusline=\  fillchars=stl:~,stlnc:_ nosplitright
+  highlight clear StatusLine
+  highlight clear StatusLineNC
+  only! | vnew
+  redrawstatus!
+  call assert_equal('^', nr2char(screenchar(winheight(0) + 1, 2)))
+  call assert_equal('=', nr2char(screenchar(winheight(0) + 1, winwidth(0) + 
3)))
+endfunction


Sincerely,
Ken Hamada (aka itchyny on GitHub)

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

stl, stlnc of fillchars are not always applied, depends on difference between StatusLine and StatusLineNC

[itchyny]

Hi list. I found a strange behavior of fillchars and StatusLine.

vim -u NONE --cmd 'set fillchars=stl:\ ,stlnc:\ ' --cmd 'vnew'
I set both stl and stlnc space so that I don't see any ^ or = characters in the 
statusline.
But when I set the following highlights, Vim draws the statusline of the 
current window with ^.

hi StatusLine ctermbg=8 ctermfg=7 cterm=NONE guibg=NONE guifg=NONE gui=NONE
hi StatusLineNC ctermbg=8 ctermfg=7 cterm=NONE guibg=NONE guifg=NONE gui=NONE

I set both spaces in fillchars so I expect them applied regardless of highlight 
configurations.
Setting ctermfg=15 for StatusLine (I mean, make differences between the 
highlights),
Vim respects the value of fillchars again.

Apparently this behavior comes from 
https://github.com/vim/vim/blob/4c8980b717f73042f1d625ee255fa74eddb989ba/src/screen.c#L10535-L10540.
When stl and stlnc are same and StatusLine and StatusLineNC are same, the fill 
characters falls back to the defaults.
The help only mentions the case when there is highlighting or not.
The current behavior is not intuitive to me.

diff --git a/src/screen.c b/src/screen.c
index ee61a01..17f72cd 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -10532,12 +10532,8 @@ fillchar_status(int *attr, int is_curwin)
*attr = hl_attr(HLF_SNC);
fill = fill_stlnc;
 }
-/* Use fill when there is highlighting, and highlighting of current
- * window differs, or the fillchars differ, or this is not the
- * current window */
-if (*attr != 0 && ((hl_attr(HLF_S) != hl_attr(HLF_SNC)
-   || !is_curwin || ONE_WINDOW)
-   || (fill_stl != fill_stlnc)))
+/* Use fill when there is highlighting. */
+if (*attr != 0)
return fill;
 if (is_curwin)
return '^';


What do you think?

Sincerely,
Ken Hamada (aka itchyny on GitHub)

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

[itchyny]

2016年7月30日土曜日 3時51分08秒 UTC+9 Bram Moolenaar:
> Patch 7.4.2117
> Problem:Deleting an augroup that still has autocmds does not give a
> warning.  The next defined augroup takes its place.
> Solution:   Give a warning and prevent the index being used for another group
> name.
> Files:  src/fileio.c, src/testdir/test_autocmd.vim
> 
> 
> *** ../vim-7.4.2116/src/fileio.c  2016-07-26 20:43:37.016311805 +0200
> --- src/fileio.c  2016-07-29 20:39:53.537537790 +0200
> ***
> *** 7758,7763 
> --- 7758,7764 
>*/
>   static garray_T augroups = {0, 0, sizeof(char_u *), 10, NULL};
>   #define AUGROUP_NAME(i) (((char_u **)augroups.ga_data)[i])
> + static char_u *deleted_augroup = NULL;
>   
>   /*
>* The ID of the current group.  Group 0 is the default one.
> ***
> *** 7812,7818 
>   if (ap->group != AUGROUP_DEFAULT)
>   {
>   if (AUGROUP_NAME(ap->group) == NULL)
> ! msg_puts_attr((char_u *)_("--Deleted--"), hl_attr(HLF_E));
>   else
>   msg_puts_attr(AUGROUP_NAME(ap->group), hl_attr(HLF_T));
>   msg_puts((char_u *)"  ");
> --- 7813,7819 
>   if (ap->group != AUGROUP_DEFAULT)
>   {
>   if (AUGROUP_NAME(ap->group) == NULL)
> ! msg_puts_attr(deleted_augroup, hl_attr(HLF_E));
>   else
>   msg_puts_attr(AUGROUP_NAME(ap->group), hl_attr(HLF_T));
>   msg_puts((char_u *)"  ");
> ***
> *** 8009,8016 
>   EMSG2(_("E367: No such group: \"%s\""), name);
>   else
>   {
>   vim_free(AUGROUP_NAME(i));
> ! AUGROUP_NAME(i) = NULL;
>   }
>   }
>   
> --- 8010,8040 
>   EMSG2(_("E367: No such group: \"%s\""), name);
>   else
>   {
> + event_T event;
> + AutoPat *ap;
> + int in_use = FALSE;
> + 
> + for (event = (event_T)0; (int)event < (int)NUM_EVENTS;
> + event = (event_T)((int)event + 1))
> + {
> + for (ap = first_autopat[(int)event]; ap != NULL; ap = ap->next)
> + if (ap->group == i)
> + {
> + give_warning((char_u *)_("W19: Deleting augroup that is 
> still in use"), TRUE);
> + in_use = TRUE;
> + event = NUM_EVENTS;
> + break;
> + }
> + }
>   vim_free(AUGROUP_NAME(i));
> ! if (in_use)
> ! {
> ! if (deleted_augroup == NULL)
> ! deleted_augroup = (char_u *)_("--Deleted--");
> ! AUGROUP_NAME(i) = deleted_augroup;
> ! }
> ! else
> ! AUGROUP_NAME(i) = NULL;
>   }
>   }
>   
> ***
> *** 8024,8030 
>   int i;
>   
>   for (i = 0; i < augroups.ga_len; ++i)
> ! if (AUGROUP_NAME(i) != NULL && STRCMP(AUGROUP_NAME(i), name) == 0)
>   return i;
>   return AUGROUP_ERROR;
>   }
> --- 8048,8055 
>   int i;
>   
>   for (i = 0; i < augroups.ga_len; ++i)
> ! if (AUGROUP_NAME(i) != NULL && AUGROUP_NAME(i) != deleted_augroup
> ! && STRCMP(AUGROUP_NAME(i), name) == 0)
>   return i;
>   return AUGROUP_ERROR;
>   }
> ***
> *** 8081,8090 
>   void
>   free_all_autocmds(void)
>   {
>   for (current_augroup = -1; current_augroup < augroups.ga_len;
>   ++current_augroup)
>   do_autocmd((char_u *)"", TRUE);
> ! ga_clear_strings(&augroups);
>   }
>   #endif
>   
> --- 8106,8125 
>   void
>   free_all_autocmds(void)
>   {
> + int i;
> + char_u  *s;
> + 
>   for (current_augroup = -1; current_augroup < augroups.ga_len;
>   ++current_augroup)
>   do_autocmd((char_u *)"", TRUE);
> ! 
> ! for (i = 0; i < augroups.ga_len; ++i)
> ! {
> ! s = ((char_u **)(augroups.ga_data))[i];
> ! if (s != deleted_augroup)
> ! vim_free(s);
> ! }
> ! ga_clear(&augroups);
>   }
>   #endif
>   
> ***
> *** 9830,9836 
>   return (char_u *)"END";
>   if (idx >= augroups.ga_len) /* end of list */
>   return NULL;
> ! if (AUGROUP_NAME(idx) == NULL)  /* skip deleted entries */
>   return (char_u *)"";
>   return AUGROUP_NAME(idx);   /* return a name */
>   }
> --- 9865,9872 
>   return (char_u *)"END";
>   if (idx >= augroups.ga_len) /* end of list */
>   return NULL;
> ! if (AUGROUP_NAME(idx) == NULL || AUGROUP_NAME(idx) == deleted_augroup)
> ! /* skip deleted entries */
>   return (char_u *)"";
>   return AUGROUP_NAME(idx);   /* return a name */
>   }
> ***
> *** 9894,9900 
>   {
>   if (idx < augroups.ga_len)  /* First list group names, if 
> wanted */
>   {
> ! if (!include_groups || AUGROUP_NAME(idx) == NULL)
>   return (char_u *)"";/*

Re: Got E121: Undefined variable in lambda function

[itchyny]

I additionally submit another test case.

let Y = {f -> (({x -> f ({y -> x(x)(y)})}) ({x -> f ({y -> x(x)(y)})}))}
let Fact = {f -> {x -> (x == 0 ? 1 : x * f(x - 1))}}
echo Y(Fact)(5)

I expect this script prints 120 but I got E110: Missing ')' in 7.4.2049 (and 
also with the experimental patch).
Is there something wrong with the above code or is there some bug in the 
parsing code in eval.c?

Here are the counterparts in Python
Y = lambda f: (lambda x: f (lambda y: x(x)(y))) (lambda x: f (lambda y: 
x(x)(y)))
Fact = lambda f: lambda x: (1 if x == 0 else x * f(x - 1))
print Y(Fact)(5)

and in JavaScript
var Y = function(f){ return (function(x){ return f (function(y){ return 
x(x)(y); }); }) (function(x){ return f (function(y){ return x(x)(y); }); }); };
var Fact = function(f){ return function(x){ return (x == 0 ? 1 : x * f(x - 1)); 
}; };
console.log(Y(Fact)(5));

reference: 
https://en.wikipedia.org/wiki/Lambda_calculus#Recursion_and_fixed_points, 
https://en.wikipedia.org/wiki/Fixed-point_combinator#Fixed_point_combinators_in_lambda_calculus

Sincerely,
Ken Hamada

-- 
-- 
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: Got E121: Undefined variable in lambda function

[itchyny]

On Sunday, July 17, 2016 at 2:56:44 AM UTC+9, Bram Moolenaar wrote:
> Ken Hamada wrote:
> 
> > Hi Bram and Ken Takata.
> > 
> > I think there is some problem in variable substitution of lambda function.
> > 
> > echo ({y -> ({x -> x(y)(10)})({y -> y})})({z -> z})
> > 
> > yields an error `E121: Undefined variable: y`. I expect this expression 
> > yields 10. I tested on Vim 7.4.2048.
> > 
> > JavaScript:
> > (function(y){ return (function(x){ return x(y)(10); })(function(y){ return 
> > y; }); })(function(z){ return z; })
> > 
> > Python:
> > (lambda y: (lambda x: x(y)(10))(lambda y: y))(lambda z: z)
> > 
> > Ruby:
> > (lambda {|y| (lambda {|x| (x.call(y)).call(10)}).call(lambda {|y| 
> > y})}).call(lambda {|z| z})
> > 
> > All these expressions prints 10 as expected.
> 
> This is because Vim does not support a closure yet.  You are using this
> lambda:
>   {x -> x(y)(10)}
> You can see that "y" is not defined here.  It would come from the
> context, but that isn't supported.
> 

I see. Thanks for explanation.

Regards,
Ken Hamada

-- 
-- 
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: Got E121: Undefined variable in lambda function

[itchyny]

Sorry, I got E117, not E121.

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

Got E121: Undefined variable in lambda function

[itchyny]

Hi Bram and Ken Takata.

I think there is some problem in variable substitution of lambda function.

echo ({y -> ({x -> x(y)(10)})({y -> y})})({z -> z})

yields an error `E121: Undefined variable: y`. I expect this expression yields 
10. I tested on Vim 7.4.2048.

JavaScript:
(function(y){ return (function(x){ return x(y)(10); })(function(y){ return y; 
}); })(function(z){ return z; })

Python:
(lambda y: (lambda x: x(y)(10))(lambda y: y))(lambda z: z)

Ruby:
(lambda {|y| (lambda {|x| (x.call(y)).call(10)}).call(lambda {|y| 
y})}).call(lambda {|z| z})

All these expressions prints 10 as expected.

Anyway, 7.4.2044 is surely a great advance in the history of Vim script. Thanks.

Sincerely,
Ken Hamada

-- 
-- 
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: E749 on switching to buffer

[itchyny]

On Friday, July 31, 2015 at 11:07:24 PM UTC+9, h_east wrote:
> Hi itchyny,
> 
> 2015-7-26(Sun) 20:46:05 UTC+9 itchyny:
> > Vim warns E749 on switching to a buffer which used to be checked diff.
> > 
> > How to reproduce.
> > 1. vim -u NONE -N
> > 2. :e test | diffthis
> > 3. :vnew test2 | diffthis
> > 4. :e test3
> > 5. :buffer #
> > 
> > Error message
> > E749: empty buffer
> > 
> > What I expect
> > Vim opens the test2 with no error message.
> ...snip...
> > Hope it fixed. Thanks.
> 
> 
> I can reproduced.
> 
> Places that are output E749 is four. In this case it is output in the 
> following locations.
> 
> fileio.c (in function buf_write())
>  3167 if (buf->b_ml.ml_mfp == NULL)
>  3168 {
>  3169 /* This can happen during startup when there is a stray "w" in 
> the
>  3170  * vimrc file. */
>  3171 EMSG(_(e_emptybuf));
>  3172 return FAIL;
>  3173 }
> 
> And It's backtrace at this time. 
> (gdb) bt
> #0  buf_write (buf=0x1a961b0, fname=0x1a9d3c0 "/tmp/vCVByI3/4", sfname=0x0,
> start=1, end=1, eap=0x0, append=0, forceit=0, reset_changed=0, 
> filtering=1)
> at fileio.c:3171
> #1  0x00414743 in diff_write (buf=0x1a961b0,
> fname=0x1a9d3c0 "/tmp/vCVByI3/4") at diff.c:645
> #2  0x00414b21 in ex_diffupdate (eap=0x0) at diff.c:809
> #3  0x004160e3 in diff_check (wp=0x1a921b0, lnum=1) at diff.c:1520
> #4  0x0041463b in diff_redraw (dofold=1) at diff.c:618
> #5  0x00413868 in diff_buf_add (buf=0x1a961b0) at diff.c:137
> #6  0x00405d42 in enter_buffer (buf=0x1a961b0) at buffer.c:1542
> #7  0x00405c7d in set_curbuf (buf=0x1a961b0, action=0) at 
> buffer.c:1507
> #8  0x00405a16 in do_buffer (action=0, start=1, dir=1, count=2,
> forceit=0) at buffer.c:1403
> #9  0x00404bdb in goto_buffer (eap=0x7ffed7d77d30, start=1, dir=1,
> count=2) at buffer.c:775
> #10 0x0046c2fa in ex_buffer (eap=0x7ffed7d77d30) at ex_docmd.c:5494
> #11 0x0046795c in do_one_cmd (cmdlinep=0x7ffed7d783c8, sourcing=0,
> cstack=0x7ffed7d77f20, fgetline=0x47ce87 , cookie=0x0)
> at ex_docmd.c:2941
> #12 0x004647b7 in do_cmdline (cmdline=0x0,
> fgetline=0x47ce87 , cookie=0x0, flags=0) at ex_docmd.c:1133
> #13 0x004ec941 in nv_colon (cap=0x7ffed7d784f0) at normal.c:5405
> #14 0x004e5d8c in normal_cmd (oap=0x7ffed7d785d0, toplevel=1)
> 
> 
> The fileio.c:3169 comments do not know well to me.. ( ﾟдﾟ)
> However, I have taken measures so as not to come here when the 'diff'.
> 
> Please check attached patch.
> 
> --
> Best regards,
> Hirohito Higashi (a.k.a h_east)


Thank you so much, h_east-san.

I actually confirmed that your patch fixes the issue.
Bram, what do you think of this bug and the patch of 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.

E749 on switching to buffer

[itchyny]

Vim warns E749 on switching to a buffer which used to be checked diff.

How to reproduce.
1. vim -u NONE -N
2. :e test | diffthis
3. :vnew test2 | diffthis
4. :e test3
5. :buffer #

Error message
E749: empty buffer

What I expect
Vim opens the test2 with no error message.

Environment
Vim 7.4.796
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 23 2015 08:48:19)
MacOS X (unix) version
Included patches: 1-796
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl +cmdline_hist-dnd -footer  +lispindent 
 -mouse_jsbterm   +perl+scrollbind  -tcl 
+viminfo -xterm_save
+arabic  +cmdline_info-ebcdic  +fork()  +listcmds   
 +mouse_netterm   +persistent_undo +signs   +terminfo
+vreplace-xpm
+autocmd +comments+emacs_tags  -gettext +localmap   
 +mouse_sgr   +postscript  +smartindent +termresponse
+wildignore
-balloon_eval+conceal +eval-hangul_input+lua
 -mouse_sysmouse  +printer -sniff   +textobjects 
+wildmenu
-browse  +cryptv  +ex_extra+iconv   +menu   
 +mouse_urxvt +profile +startuptime +title   
+windows
++builtin_terms  +cscope  +extra_search+insert_expand   +mksession  
 +mouse_xterm +python  +statusline  -toolbar 
+writebackup
+byte_offset +cursorbind  +farsi   +jumplist
+modify_fname+multi_byte  -python3 -sun_workshop
+user_commands   -X11
+cindent +cursorshape +file_in_path+keymap  +mouse  
 +multi_lang  +quickfix+syntax  +vertsplit   
-xfontset
-clientserver+dialog_con  +find_in_path+langmap -mouseshape 
 -mzscheme+reltime +tag_binary  +virtualedit -xim
+clipboard   +diff+float   +libcall +mouse_dec  
 +netbeans_intg   +rightleft   +tag_old_static  +visual  -xsmp
+cmdline_compl   +digraphs+folding +linebreak   -mouse_gpm  
 +path_extra  +ruby-tag_any_white   +visualextra 
-xterm_clipboard
   system vimrc file: "$VIM/vimrc"
 user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
  user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  
-Os -w -pipe -march=core2 -msse4.1 -mmacosx-version-min=10.10 -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=1
Linking: /usr/bin/clang   -L. -L/usr/local/lib -L/usr/local/lib 
-Wl,-headerpad_max_install_names -o vim-lm  -lncurses -liconv 
-framework Cocoa  -pagezero_size 1 -image_base 1000
0 -L/usr/local/lib -lluajit-5.1 -fstack-protector  
-L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -framework 
Python   -lruby.2.0.0 -lobjc

Hope it fixed. Thanks.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.709

[itchyny]

Bram, thank you so much for including the patch.
Higashi-san, thank you so much for the patch fixing the behaviour of tabmove, 
as well as the document.
Using the latest version for a while, I noticed that the behaviour of tabm $ is 
a very intuitive.
... so much that I confirmed for several times that I can now use tabmove to 
the last ($), yep, it's consistent isn't it.

Thank you.

On Wednesday, April 22, 2015 at 1:09:12 AM UTC+9, Bram Moolenaar wrote:
> Patch 7.4.709
> Problem:":tabmove" does not work as documented.
> Solution:   Make it work consistently.  Update documentation and add tests.
> (Hirohito Higashi)
> Files:  src/window.c, runtime/doc/tabpage.txt, src/ex_docmd.c,
> src/testdir/test62.in, src/testdir/test62.ok
> 
> 
> *** ../vim-7.4.708/src/window.c   2015-04-21 15:43:00.338397578 +0200
> --- src/window.c  2015-04-21 18:05:36.180477302 +0200
> ***
> *** 4120,4137 
>   }
>   
>   /*
> !  * Move the current tab page to before tab page "nr".
>*/
>   void
>   tabpage_move(nr)
>   int nr;
>   {
> ! int n = nr;
> ! tabpage_T   *tp;
>   
>   if (first_tabpage->tp_next == NULL)
>   return;
>   
>   /* Remove the current tab page from the list of tab pages. */
>   if (curtab == first_tabpage)
>   first_tabpage = curtab->tp_next;
> --- 4120,4146 
>   }
>   
>   /*
> !  * Move the current tab page to after tab page "nr".
>*/
>   void
>   tabpage_move(nr)
>   int nr;
>   {
> ! int n = 1;
> ! tabpage_T   *tp, *tp_dst;
>   
>   if (first_tabpage->tp_next == NULL)
>   return;
>   
> + for (tp = first_tabpage; tp->tp_next != NULL && n < nr; tp = 
> tp->tp_next)
> + ++n;
> + 
> + if (tp == curtab || (nr > 0 && tp->tp_next != NULL
> + && tp->tp_next == curtab))
> + return;
> + 
> + tp_dst = tp;
> + 
>   /* Remove the current tab page from the list of tab pages. */
>   if (curtab == first_tabpage)
>   first_tabpage = curtab->tp_next;
> ***
> *** 4146,4162 
>   }
>   
>   /* Re-insert it at the specified position. */
> ! if (n <= 0)
>   {
>   curtab->tp_next = first_tabpage;
>   first_tabpage = curtab;
>   }
>   else
>   {
> ! for (tp = first_tabpage; tp->tp_next != NULL && n > 1; tp = tp->tp_next)
> ! --n;
> ! curtab->tp_next = tp->tp_next;
> ! tp->tp_next = curtab;
>   }
>   
>   /* Need to redraw the tabline.  Tab page contents doesn't change. */
> --- 4155,4169 
>   }
>   
>   /* Re-insert it at the specified position. */
> ! if (nr <= 0)
>   {
>   curtab->tp_next = first_tabpage;
>   first_tabpage = curtab;
>   }
>   else
>   {
> ! curtab->tp_next = tp_dst->tp_next;
> ! tp_dst->tp_next = curtab;
>   }
>   
>   /* Need to redraw the tabline.  Tab page contents doesn't change. */
> *** ../vim-7.4.708/runtime/doc/tabpage.txt2015-01-07 16:52:53.506792420 
> +0100
> --- runtime/doc/tabpage.txt   2015-04-21 18:01:53.042846350 +0200
> ***
> *** 202,224 
>   Move the current tab page to after tab page N.  Use zero to
>   make the current tab page the first one.  Without N the tab
>   page is made the last one. >
>   :-tabmove   " move the tab page to the left
> ! :tabmove" move the tab page to the right
> ! :.tabmove   " as above
> ! :+tabmove   " as above
>   :0tabmove   " move the tab page to the beginning of the tab
>   " list
> ! :$tabmove   " move the tab page to the end of the tab list
> ! <
>   
>   :tabm[ove] +[N]
>   :tabm[ove] -[N]
>   Move the current tab page N places to the right (with +) or to
> ! the left (with -).
>   
>   Note that although it is possible to move a tab behind the N-th one by using
> ! :Ntabmove, it is impossible to move it by N places by using :+Ntabmove. For
> ! clarification what +N means in this context see |[range]|.
>   
>   
>   LOOPING OVER TAB PAGES:
> --- 202,230 
>   Move the current tab page to after tab page N.  Use zero to
>   make the current tab page the first one.  Without N the tab
>   page is made the last one. >
> + :.tabmove   " do nothing
>   :-tabmove   " move the tab page to the left
> ! :+tabmove   " move the tab page to the right
>   :0tabmove   " move the tab page to the beginning of the tab
>   " list
> ! :tabmove 0  " as above
> ! :tabmove" move the tab page to the last
> ! :$tabmove   " as above
> ! :tabmove $  " as above
>   
>   :tabm[ove] +[N]
>   :tabm[o

Re: Weird behaviour of :tabmove and inconsistency between the actual behaviour and the document.

[itchyny]

Hello, Bram, Higashi-san and all.

I tried Higashi-san's patch with the latest version of Vim and confirmed that
all the behaviour of the range and the arguments for the :tabmove command works
well. Bram, would you please check and include the patch to the upstream?

Thank you Higashi-san for the patch.

On Friday, March 20, 2015 at 9:51:53 PM UTC+9, Bram Moolenaar wrote:
> Hirohito Higashi wrote:
> 
> > Hi Bram and itchyny and List,
> > 
> > 2015/3/15(Sun) 7:48:01 UTC+9 Bram Moolenaar:
> > > Hirohito Higashi wrote:
> > > 
> > > > Hi Bram and List,
> > > > 
> > > > 2015/3/11(Wed) 15:14:47 UTC+9 h_east:
> > > > > Hello itchyny and Bram,
> > > > > 
> > > > > 2015/3/11(Wed) 10:07:53 UTC+9 itchyny:
> > > > > > On Wednesday, March 11, 2015 at 6:59:12 AM UTC+9, Bram Moolenaar 
> > > > > > wrote:
> > > > > > > Hirohito Higashi wrote:
> > > > > > > 
> > > > > > > > Oops, I fixed patch and test :-)
> > > > > > > > 
> > > > > > > > (I could not attached patch, I paste Gist.)
> > > > > > > > https://gist.github.com/h-east/ffabb0cdd589a5f9acd2
> > > > > > > 
> > > > > > > Thanks!  I wonder if ":tabmove" should work as documented or that 
> > > > > > > the
> > > > > > > documentation needs to be adjusted.  Well, the documentation is 
> > > > > > > already
> > > > > > > inconsistant, it needs to be fixed anyway.
> > > > > > > 
> > > > > > > I suppose that since we have ":0tabmove" to move the tab page to 
> > > > > > > the
> > > > > > > first position, ":$tabmove" is the most logical to move to the 
> > > > > > > last
> > > > > > > position.  Then ":tabmove" without argument just moves it right.
> > > > > > > 
> > > > > > > I would expect ":.tabmove" to not do anything.  But that's not 
> > > > > > > actually
> > > > > > > useful.  So move it to the right, just like ":tabmove"?
> > > 
> > > > > > Hello, Bram.
> > > > > > 
> > > > > > I agree with the idea that `:.tabmove` should not move the tab 
> > > > > > page. The command `:.` does
> > > > > > not move the line, you know. If `:.tabmove` does not move the 
> > > > > > tabpage, the commands
> > > > > > `:.tabmove`, `:-tabmove`, `:+tabmove` will be consistent with `:.`, 
> > > > > > `:-`, `:+`.
> > > > > > 
> > > > > > The command `:tabmove` moves the tab page to the last in old Vim (I 
> > > > > > mean Vim before
> > > > > > 7.4.530). If you change the behaviour, it breaks backward 
> > > > > > compatibility. Some users may
> > > > > > use `:tabmove` in order to move the tab to the last.
> > > > > 
> > > > > Indeed. That's right.
> > > > > 
> > > > > I consider a specification that is consistent.
> > > > > 
> > > > > $ vim -N -u NONE -p 1 2 3 4 5 -c "tabnext"
> > > > > 
> > > > > LV : Latest Vim (7.4.658) behavior
> > > > > 
> > > > > 1 [2] 3 4 5   " Now tab page status. [ ] is current tab page.
> > > > >  (1) :tabm" 1 3 4 5 [2]   Backward compatibility ? LV:OK?
> > > > >  (2) :.tabm   " 1 [2] 3 4 5   Stay current tab page. LV:NG
> > > > >  (3) :.+tabm  " 1 3 [2] 4 5   Move to the right one. LV:NG
> > > > >  (4) :.+1tabm " Same as above. LV:NG
> > > > >  (5) :+tabm   " Same as above. LV:NG
> > > > >  (6) :+1tabm  " Same as above. LV:NG
> > > > >  (7) :tabm +  " Same as above. LV:NG(E474)
> > > > >  (8) :tabm +1 " Same as above. LV:OK
> > > > >  (9) :.-tabm  " [1] 2 3 4 5   Move to the left one.
> > > > > (10) :.-1tabm " Same as above
> > > > > (11) :-tabm   " Same as above. LV:NG
> > > > > (12) :-1tabm  " Same as above. LV:NG
> > > > > (13) :tabm -  " Same as above. LV:NG(E474)
> > > > > (14) :tabm -1 " S

Re: Weird behaviour of :tabmove and inconsistency between the actual behaviour and the document.

[itchyny]

On Wednesday, March 11, 2015 at 6:59:12 AM UTC+9, Bram Moolenaar wrote:
> Hirohito Higashi wrote:
> 
> > Oops, I fixed patch and test :-)
> > 
> > (I could not attached patch, I paste Gist.)
> > https://gist.github.com/h-east/ffabb0cdd589a5f9acd2
> 
> Thanks!  I wonder if ":tabmove" should work as documented or that the
> documentation needs to be adjusted.  Well, the documentation is already
> inconsistant, it needs to be fixed anyway.
> 
> I suppose that since we have ":0tabmove" to move the tab page to the
> first position, ":$tabmove" is the most logical to move to the last
> position.  Then ":tabmove" without argument just moves it right.
> 
> I would expect ":.tabmove" to not do anything.  But that's not actually
> useful.  So move it to the right, just like ":tabmove"?
> 
> -- 
> Q: How does a UNIX Guru do Sex ?
> A: unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
> 
>  /// 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///

Hello, Bram.

I agree with the idea that `:.tabmove` should not move the tab page. The 
command `:.` does
not move the line, you know. If `:.tabmove` does not move the tabpage, the 
commands
`:.tabmove`, `:-tabmove`, `:+tabmove` will be consistent with `:.`, `:-`, `:+`.

The command `:tabmove` moves the tab page to the last in old Vim (I mean Vim 
before
7.4.530). If you change the behaviour, it breaks backward compatibility. Some 
users may
use `:tabmove` in order to move the tab to the last.

By the way, :tabmove 0 and :0tabmove behaves the same, sometimes I mistake as 
:tabmove $. This command now throws invalid argument.

itchyny

-- 
-- 
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: Weird behaviour of :tabmove and inconsistency between the actual behaviour and the document.

[itchyny]

On Tuesday, March 10, 2015 at 4:59:33 PM UTC+9, h_east wrote:
> Oops, I fixed patch and test :-)
> 
> (I could not attached patch, I paste Gist.)
> https://gist.github.com/h-east/ffabb0cdd589a5f9acd2
> 
> Best regards,
> Hirohito Higashi (a.k.a h_east)

Hello, h_east.
Thank you for your patch!
I checked your patch and recompiled to find that the behaviour of `:-tabmove` 
and
`:+tabmove` are fixed. Great work and I hope it merged.

itchyny

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

Weird behaviour of :tabmove and inconsistency between the actual behaviour and the document.

[itchyny]

Hello, all.
I think that there are some problems for :tabmove. Firstly, see the document 
(:h :tabmove).

:tabm[ove] [N]  *:tabm* *:tabmove*
:[N]tabm[ove]
Move the current tab page to after tab page N.  Use zero to
make the current tab page the first one.  Without N the tab
page is made the last one. >
:-tabmove   " move the tab page to the left
:tabmove" move the tab page to the right
:.tabmove   " as above
:+tabmove   " as above
:0tabmove   " move the tab page to the beginning of the tab
" list
:$tabmove   " move the tab page to the end of the tab list

Let me explain some problems related to this command.

1. :tabmove
The :tabmove with no argument and with no range moves the tab page to the last 
place.
The help says that `Without N the tab page is made the last one` while it says
 `:tabmove " move the tab page to the right `. I think that this comment is 
mistaken.

2. :-tabmove
Within the latest Vim, the command :-tabmove does not move the tab page. The 
help says
that `:-tabmove " move the tab page to the left`. Which behaviour is correct?

3. :+tabmove
Within the latest Vim, the command :+tabmove moves the current tab page to the 
right position
of the right tab page (doubly right position). The help says `:+tabmove " as 
above`, which, 
I think, means that the same behaviour of `:.tabmove`. This is inconsistent 
with the actual behaviour.

Basically I do not think that the comments of examples in the help are correct. 
I also
noticed that there are no tests for `:.tabmove`, `:+tabmove`, `:-tabmove` and 
`:tabmove` in testdir/test62.in.
Hope it fixed.

Thanks.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [feature request] Highlight all the matches while searching

[itchyny]

On Saturday, February 7, 2015 at 10:39:05 PM UTC+9, Bram Moolenaar wrote:
> Itchyny wrote:
> 
> > The option 'incsearch' just jumps to the first matching place and
> > highlights it.
> > We then press enter, all the matches are get highlighted (if we set
> > hlsearch on).
> > If Vim highlights all the matching strings, it would be nice.
> > 
> > There's already an implementation in Vim script
> > (https://github.com/haya14busa/incsearch.vim).
> > However, this plugin uses its own command-line like interface thus
> > very limited and the code is too complicated.
> > 
> > If this feature will be implemented with a small patch, it would be
> > nice and I hope it merged.
> > 
> > Here's a simple patch I wrote.
> > I noticed that just removing the SEARCH_KEEP flag enables Vimt to
> > highlight the
> > matches while searching (search.c:L1149, ex_getln.c:L1795).
> > Of course, as you notice, the following patch overwrites the default 
> > behavior
> > and it must be fixed if the feature will be merged to Vim.
> > Does anyone get interested in implementing the followings?
> >   - new option ('incsearchhlall' or something like that)to highlight
> > all the matches 
> > while searching (disabled by default)
> >   - related documents and helps
> 
> We need different highlighting for the matches other than the one that
> the cursor would jump to.  If that's different enough then I don't think
> we need yet-another-option.  At least for me the search highlighting and
> the incsearch match highlighting are very different.
> 
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 191. You rate eating establishments not by the quality of the food,
>  but by the availability of electrical outlets for your PowerBook.
> 
>  /// 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///

Thank you, Bram and Ben.
However, Bram, I do not understand what you mean -- they are different _then_ 
you don't think we need yet-another-option.
I now understand that highlighting all the matches and incsearch are different, 
_therefore_
we need another option to enable highlighting all the matches while searching, 
right?
Of course the highlighting color should be different from both of Search and 
IncSearch.
Considering the reputation the existing plugin 
(https://github.com/haya14busa/incsearch.vim while the 
plugin name might be misleading) got, it is apparent that many people want the 
feature implemented in Vim.
(I again state that the existing plugin uses many dirty hacks (own cmdline-like 
interface
and getchar() loops) to implement the feature)

itchyny

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

[feature request] Highlight all the matches while searching

[itchyny]

The option 'incsearch' just jumps to the first matching place and highlights it.
We then press enter, all the matches are get highlighted (if we set hlsearch 
on).
If Vim highlights all the matching strings, it would be nice.

There's already an implementation in Vim script 
(https://github.com/haya14busa/incsearch.vim).
However, this plugin uses its own command-line like interface thus very limited 
and the code is too complicated.

If this feature will be implemented with a small patch, it would be nice and I 
hope it merged.

Here's a simple patch I wrote.
I noticed that just removing the SEARCH_KEEP flag enables Vimt to highlight the
matches while searching (search.c:L1149, ex_getln.c:L1795).
Of course, as you notice, the following patch overwrites the default behavior
and it must be fixed if the feature will be merged to Vim.
Does anyone get interested in implementing the followings?
  - new option ('incsearchhlall' or something like that)to highlight all the 
matches 
while searching (disabled by default)
  - related documents and helps

diff -r cd5eff09c1ae src/ex_getln.c
--- a/src/ex_getln.cThu Feb 05 20:29:59 2015 +0100
+++ b/src/ex_getln.cSat Feb 07 02:09:58 2015 +0900
@@ -1778,8 +1778,10 @@
curwin->w_cursor = old_cursor;  /* start at old position */
 
/* If there is no command line, don't do anything */
-   if (ccline.cmdlen == 0)
+   if (ccline.cmdlen == 0) {
i = 0;
+   SET_NO_HLSEARCH(TRUE);
+   }
else
{
cursor_off();   /* so the user knows we're busy */
@@ -1790,7 +1792,7 @@
profile_setlimit(500L, &tm);
 #endif
i = do_search(NULL, firstc, ccline.cmdbuff, count,
-   SEARCH_KEEP + SEARCH_OPT + SEARCH_NOOF + SEARCH_PEEK,
+   SEARCH_OPT + SEARCH_NOOF + SEARCH_PEEK,
 #ifdef FEAT_RELTIME
&tm

Regards, itchyny.
Thanks.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.530

[itchyny]

On Sunday, November 30, 2014 1:38:09 AM UTC+9, Marcin Szamotulski wrote:
> On 22:14 Fri 28 Nov , Bram Moolenaar wrote:
> > 
> > Itchyny wrote:
> > 
> > > Bram, the  is always 1 (probably after this patch).
> > > 
> > >   :command! Test echo 
> > > 
> > > try :Test and it always echoes 1.
> > 
> > I cannot reproduce this problem, I get the current line.
> > Anything else that matters?
> 
> I found some small issues, the attached patch solves them all.  It
> includes other small patches I send yesterday.
> 
> - fix SEGFAULT in compute_buffer_local_count
> - fix buf number returned by compute_buffer_local_count
> - `penultimate` in docs
> - check for CMD_USER in do_one_cmd
> 
> Best regards,
> Marcin

Marcin, thank you so much. I confirmed that the  problem is solved by 
your patch 7.4.539.

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

[itchyny]

Bram, the  is always 1 (probably after this patch).

  :command! Test echo 

try :Test and it always echoes 1.

-- 
-- 
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: [feature request] list all variables defined by `let`

[itchyny]

On Tuesday, July 8, 2014 3:43:00 PM UTC+9, Brook Hong wrote:
> It will be useful, if there is a function to get a list of all variables with 
> specific type.
> 
> For example,
> 
> let g:foo='foo'
> let g:bar='bar'
> 
> 
> call listvars('g')
> // return ['foo', 'bar']

Try :echo keys(g:).

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

breakindentopt is not applied soon

[itchyny]

To reproduce
vim -u NONE -N
500ia^
>>
set wrap breakindent
set breakindentopt=shift:10
hlhlhlwbwb
x

Problem
The indentation is not updated soon after we change breakindentopt.

Expected behaviour
The indentation is updated soon.

Environment
Vim 7.4 1-345

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

breakindent problem: unindenting with X does not update the indent

[itchyny]

To reproduce
vim -u NONE -N
500ia^
:set breakindent
>>
>>
>>
XXX

Problem
The second and the following lines are kept indented.

Expected behaviour
The indent level follows that of the first line.

Environment
On Vim 7.4 1-340, Ubuntu

-- 
-- 
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: sed: RE error: illegal byte sequence while installing the manuals

[itchyny]

> Can you check this: All places where sed is used in src/installman.sh,
> 
> prepend LC_ALL=C for every sed command (there are three).
> 

Right. Prepending LC_ALL=C for the three places fixes the "sed: RE error: 
illegal byte sequence" errors.

-- 
-- 
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: sed: RE error: illegal byte sequence while installing the manuals

[itchyny]

To fix, add `LC_ALL=C` before sed.
For example:

 $ export LC_ALL=ja_JP.UTF-8
 $ cat runtime/doc/vim-fr.1 | sed 's/.*//' > /dev/null
sed: RE error: illegal byte sequence
 $ cat runtime/doc/vim-fr.1 | LC_ALL=C sed 's/.*//' > /dev/null
 $ # no errors
Modifying $LC_ALL temporarily fixes the problem.

Of course, in stead of adding LC_ALL before the `sed's,
we can add it at more macro level... I mean, before using installman.sh:
  $ LC_ALL=C /bin/sh ./installman.sh
or more globally
  $ LC_ALL=C sudo make install
suppresses the errors of sed.

Portability
I don't know that which shell supports modifying a variable temporarily.

Reference
+ http://stackoverflow.com/questions/19242275/
+ http://stackoverflow.com/questions/11287564/
(Sorry for choosing stackoverflow as references, but it actually works.)

On Sunday, June 22, 2014 7:43:19 PM UTC+9, Bram Moolenaar wrote:
> Itchyny wrote:
> 
> 
> 
> > # Command
> 
> >   $ sudo make install
> 
> > 
> 
> > # On
> 
> >   Mac OS X
> 
> >   Vim the latest
> 
> > 
> 
> > # Produces sed errors
> 
> > /bin/sh ./installman.sh install /usr/local/share/man/fr/man1 "-fr" 
> > /usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
> > ../runtime/doc 644 vim vimdiff evim
> 
> > installing /usr/local/share/man/fr/man1/vim.1
> 
> > sed: RE error: illegal byte sequence
> 
> 
> 
> [...]
> 
> 
> 
> > installing /usr/local/share/man/ru.KOI8-R/man1/vimdiff.1
> 
> > installing /usr/local/share/man/ru.KOI8-R/man1/evim.1
> 
> > sed: RE error: illegal byte sequence
> 
> > 
> 
> > # To fix
> 
> >   add LC_ALL=C before sed.
> 
> 
> 
> How to do that in a portable way?
> 
> 
> 
> Does Mac have a different sed from what most systems are using?
> 
> 
> 
> -- 
> 
> FATHER:Did you kill all those guards?
> 
> LAUNCELOT: Yes ...  I'm very sorry ...
> 
> FATHER:They cost fifty pounds each!
> 
>  "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.

sed: RE error: illegal byte sequence while installing the manuals

[itchyny]

# Command
  $ sudo make install

# On
  Mac OS X
  Vim the latest

# Produces sed errors
/bin/sh ./installman.sh install /usr/local/share/man/fr/man1 "-fr" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/fr/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/fr/man1/vimtutor.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/fr/man1/vimdiff.1
installing /usr/local/share/man/fr/man1/evim.1
sed: RE error: illegal byte sequence
/bin/sh ./installman.sh install /usr/local/share/man/fr.ISO8859-1/man1 "-fr" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/fr.ISO8859-1/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/fr.ISO8859-1/man1/vimtutor.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/fr.ISO8859-1/man1/vimdiff.1
installing /usr/local/share/man/fr.ISO8859-1/man1/evim.1
sed: RE error: illegal byte sequence
/bin/sh ./installman.sh install /usr/local/share/man/fr.UTF-8/man1 "-fr.UTF-8" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/fr.UTF-8/man1/vim.1
installing /usr/local/share/man/fr.UTF-8/man1/vimtutor.1
installing /usr/local/share/man/fr.UTF-8/man1/vimdiff.1
installing /usr/local/share/man/fr.UTF-8/man1/evim.1
/bin/sh ./installman.sh install /usr/local/share/man/it/man1 "-it" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/it/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/it/man1/vimtutor.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/it/man1/vimdiff.1
installing /usr/local/share/man/it/man1/evim.1
sed: RE error: illegal byte sequence
/bin/sh ./installman.sh install /usr/local/share/man/it.ISO8859-1/man1 "-it" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/it.ISO8859-1/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/it.ISO8859-1/man1/vimtutor.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/it.ISO8859-1/man1/vimdiff.1
installing /usr/local/share/man/it.ISO8859-1/man1/evim.1
sed: RE error: illegal byte sequence
/bin/sh ./installman.sh install /usr/local/share/man/it.UTF-8/man1 "-it.UTF-8" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/it.UTF-8/man1/vim.1
installing /usr/local/share/man/it.UTF-8/man1/vimtutor.1
installing /usr/local/share/man/it.UTF-8/man1/vimdiff.1
installing /usr/local/share/man/it.UTF-8/man1/evim.1
/bin/sh ./installman.sh install /usr/local/share/man/ja/man1 "-ja.UTF-8" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/ja/man1/vim.1
installing /usr/local/share/man/ja/man1/vimtutor.1
installing /usr/local/share/man/ja/man1/vimdiff.1
installing /usr/local/share/man/ja/man1/evim.1
/bin/sh ./installman.sh install /usr/local/share/man/pl/man1 "-pl" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/pl/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/pl/man1/vimtutor.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/pl/man1/vimdiff.1
installing /usr/local/share/man/pl/man1/evim.1
sed: RE error: illegal byte sequence
/bin/sh ./installman.sh install /usr/local/share/man/pl.ISO8859-2/man1 "-pl" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/pl.ISO8859-2/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/pl.ISO8859-2/man1/vimtutor.1
sed: RE error: illegal byte sequence
installing /usr/local/share/man/pl.ISO8859-2/man1/vimdiff.1
installing /usr/local/share/man/pl.ISO8859-2/man1/evim.1
sed: RE error: illegal byte sequence
/bin/sh ./installman.sh install /usr/local/share/man/pl.UTF-8/man1 "-pl.UTF-8" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/pl.UTF-8/man1/vim.1
installing /usr/local/share/man/pl.UTF-8/man1/vimtutor.1
installing /usr/local/share/man/pl.UTF-8/man1/vimdiff.1
installing /usr/local/share/man/pl.UTF-8/man1/evim.1
/bin/sh ./installman.sh install /usr/local/share/man/ru.KOI8-R/man1 "-ru" 
/usr/local/share/vim /usr/local/share/vim/vim74 /usr/local/share/vim 
../runtime/doc 644 vim vimdiff evim
installing /usr/local/share/man/ru.KOI8-R/man1/vim.1
sed: RE error: illegal byte sequence
installing /usr/local/share/m

Re: vimString breaks the syntax (syntax/vim.vim)

[itchyny]

Thank you so much.

On Tuesday, June 10, 2014 5:39:34 AM UTC+9, Charles Campbell wrote:
> itchyny wrote:
> 
> > let m = 5
> 
> > let y = 20 * (m / 4) + m / 4
> 
> > let z = 10
> 
> > for i in range(10)
> 
> >echo i
> 
> > endfor
> 
> > while i
> 
> >let i -= 1
> 
> > endwhile
> 
> Please try v7.4-30 which you can get from my website: 
> 
> http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM .
> 
> 
> 
> Thank you for the report,
> 
> 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.

vimString breaks the syntax (syntax/vim.vim)

[itchyny]

Hi, list.

This is a bug in syntax/vim.vim.
Consider we are editing a Vim script file. (setl ft=vim)
When we use two slashes in a line, the syntax is broken.
For example:

let [a, b] = [winheight(0) / 2, winwidth(0) / 2]

'/ 2, winwidth(0) /' is considered as a string.

It's tolerable if it does not affect the following lines.
But in the next example, the vimString in slashes plus the parenthesis
break the syntax to the end of the  file.

let m = 5
let y = 20 * (m / 4) + m / 4 
let z = 10
for i in range(10)
  echo i
endfor
while i
  let i -= 1
endwhile

-- 
-- 
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: [bugreport] pastetoggle does not update statusline

[itchyny]

On Wednesday, February 6, 2008 5:44:23 AM UTC+9, Bram Moolenaar wrote:
> Jan Christoph Ebersbach wrote:
> 
> > Hi,
> > 
> > I set the following options to see the current status of paste:
> > 
> > set pastetoggle=
> > set statusline=%{&paste}
> > 
> > It works perfectly except that a single press of  in normal/visual
> > *all*/select *all*-mode doesn't update the statusline until I do
> > something else, i.e. move the cursor.
> 
> Yes, it appears the statusline is only updated when setting an option
> directly.  One more for the todo list.
> 
> -- 
> While it's true that many normal people whould prefer not to _date_ an
> engineer, most normal people harbor an intense desire to _mate_ with them,
> thus producing engineerlike children who will have high-paying jobs long
> before losing their virginity.
>   (Scott Adams - The Dilbert principle)
> 
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\download, build and distribute -- http://www.A-A-P.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///

Hello.
Any updates on this issue?

-- 
-- 
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/groups/opt_out.

Re: syntax problem in vim.vim: vimUserAttrbCmpltFunc

[itchyny]

On Saturday, July 6, 2013 1:39:03 AM UTC+9, Charles Campbell wrote:
> Please try syntax/vim.vim v7.3-26 , available at my website at 
> 
> http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM .
> 
> 
> 
> The problem: s:Xxxx was permitted (old rules for what was allowed to be 
> 
> a function name), but lower case such as s: was not. syntax/vim.vim 
> 
> is now updated to use \h instead of \u (ie. head-of-word) to recognize 
> 
> that first letter following the s:.
> 
> 
> 
> Regards,
> 
> Chip Campbell

Thank you, Chip.
And you too, Bram.
I confirmed syntax/vim.vim was updated.

-- 
-- 
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/groups/opt_out.

syntax problem in vim.vim: vimUserAttrbCmpltFunc

[itchyny]

Hi list. There is a problem in vim.vim for |command-completion-customlist|.
-
command! -nargs=+ -complete=customlist,s: X call s:x()
-
The above example is looks like:
https://f.cloud.github.com/assets/375258/752414/fb5dee78-e543-11e2-8fcd-b9ea89846ad6.png

Expected:
https://f.cloud.github.com/assets/375258/752415/ff719bc2-e543-11e2-97cd-f552f0139768.png

While using a script function for custom completion is allowed (not documented;
but can be executed as we expect), the syntax-group vimUserAttrbCmpltFunc does 
not.
The `s:` is colored by vimUserCmdError.

A patch is attached. Thanks.

- Ken Hamada

-- 
-- 
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/groups/opt_out.


diff -r 99797d166c1f runtime/syntax/vim.vim
--- a/runtime/syntax/vim.vimThu Jul 04 22:50:40 2013 +0200
+++ b/runtime/syntax/vim.vimFri Jul 05 15:50:29 2013 +0900
@@ -205,7 +205,7 @@
 syn keywordvimUserAttrbKey   contained bar ban[g]  cou[nt] ra[nge] com[plete]  n[args] re[gister]
 syn keywordvimUserAttrbCmplt contained augroup buffer color command compiler cscope dir environment event expression file file_in_path filetype function help highlight locale mapping menu option shellcmd sign syntax tag tag_listfiles var
 syn keywordvimUserAttrbCmplt contained custom customlist nextgroup=vimUserAttrbCmpltFunc,vimUserCmdError
-syn match  vimUserAttrbCmpltFunc contained ",\%([sS]:\|<[sS][iI][dD]>\)\=\%(\h\w*\%(#\u\w*\)\+\|\u\w*\)"hs=s+1 nextgroup=vimUserCmdError
+syn match  vimUserAttrbCmpltFunc contained ",\%([sS]:\|<[sS][iI][dD]>\)\=\%(\h\w*\%(#\a\w*\)\+\|\a\w*\)"hs=s+1 nextgroup=vimUserCmdError

 syn case match
 syn match  vimUserAttrbCmplt contained "custom,\u\w*"