Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
Hello Vim developers, I've noticed a regression: :s/.*/\=foo\nbar/ This correctly replaces the current line with two lines containing foo and bar, respectively. Now add the confirm flag, and accept the replacement: :s/.*/\=foo\nbar/c This replaces the current line with a single line containing foo^@bar (where ^@ is Nul). This is inconsistent and unexpected. Replacing with \r instead works (with and without the flag), and can be used as a workaround. Using the attached scriptlet, I've bisected this to the following patch: ,[ bad change ] | 7.3.225 \n in a substitute() inside :s not handled correctly ` The problem therefore can be seen in this and all following Vim versions, verified up to the latest 7.4.258. (I've used a HUGE build on both Windows/x64 and Linux/x64.) -- regards, ingo -- -- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ -- -- http://vim.sourceforge.net/account/profile.php?user_id=9713 -- -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. bug-s_c-newline.vim Description: application/octetstream
Re: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
Ingo Karkat wrote: I've noticed a regression: :s/.*/\=foo\nbar/ This correctly replaces the current line with two lines containing foo and bar, respectively. Now add the confirm flag, and accept the replacement: :s/.*/\=foo\nbar/c This replaces the current line with a single line containing foo^@bar (where ^@ is Nul). This is inconsistent and unexpected. Replacing with \r instead works (with and without the flag), and can be used as a workaround. Using the attached scriptlet, I've bisected this to the following patch: ,[ bad change ] | 7.3.225 \n in a substitute() inside :s not handled correctly ` The problem therefore can be seen in this and all following Vim versions, verified up to the latest 7.4.258. (I've used a HUGE build on both Windows/x64 and Linux/x64.) I cannot reproduce this problem. -- From know your smileys: :} You lie like Pinocchio /// 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: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
On 23-Apr-2014 16:28 +0200, Bram Moolenaar wrote:
Ingo Karkat wrote:
I've noticed a regression:
:s/.*/\=foo\nbar/
This correctly replaces the current line with two lines containing foo
and bar, respectively. Now add the confirm flag, and accept the
replacement:
:s/.*/\=foo\nbar/c
This replaces the current line with a single line containing foo^@bar
(where ^@ is Nul). This is inconsistent and unexpected. Replacing with
\r instead works (with and without the flag), and can be used as a
workaround.
Using the attached scriptlet, I've bisected this to the following patch:
,[ bad change ]
| 7.3.225 \n in a substitute() inside :s not handled correctly
`
The problem therefore can be seen in this and all following Vim
versions, verified up to the latest 7.4.258. (I've used a HUGE build on
both Windows/x64 and Linux/x64.)
I cannot reproduce this problem.
Ah, sorry, I missed one crucial detail of my environment (and forgot to
use -N -u NONE). In my 'statusline', I have a custom function that
performs a =~ comparison. Define the following:
function! TitleString()
let check = 'foo' =~ 'bar'
return
endfunction
set titlestring=%{TitleString()}
Then, the
:s/.*/\=foo\nbar/c
command will produce the ^@. So the =~ (probably triggered while the
confirm flag is in action) somehow affects the behavior of :substitute.
Attached is an updated scriptlet.
-- regards, ingo
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
bug-s_c-newline.vim
Description: application/octetstream
Re: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
On 23-Apr-2014 17:37 +0200, Christian Brabandt wrote: Am 2014-04-23 16:28, schrieb Bram Moolenaar: Ingo Karkat wrote: I've noticed a regression: :s/.*/\=foo\nbar/ This correctly replaces the current line with two lines containing foo and bar, respectively. Now add the confirm flag, and accept the replacement: :s/.*/\=foo\nbar/c This replaces the current line with a single line containing foo^@bar (where ^@ is Nul). This is inconsistent and unexpected. Replacing with \r instead works (with and without the flag), and can be used as a workaround. Using the attached scriptlet, I've bisected this to the following patch: ,[ bad change ] | 7.3.225 \n in a substitute() inside :s not handled correctly ` The problem therefore can be seen in this and all following Vim versions, verified up to the latest 7.4.258. (I've used a HUGE build on both Windows/x64 and Linux/x64.) I cannot reproduce this problem. I see the problem with vim-airline. I think, it is caused by the evaluation of the statusline resetting reg_line_lbr when displaying the confirmation message. Attached patch fixes this, but I think one should also reset all the other internal static variables. Thanks Christian, that patch indeed fixes the problem for me. Good hunch about the statusline, that is indeed a necessary condition (as I have added in my updated message). You seem to be really knowledgable about Vim's internals. The question I have in mind right now is whether you still feel comfortable about those internal static variables, or whether you think this poses long-term risks to Vim's stability. At least some people think so, and have suggested / started a complete rewrite (in a language like C++ that has better means to avoid such). Is there anything (apart from more test coverage) that we can do with the current code base?! -- regards, ingo -- -- 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: Bug for i_Ctrl-U
Am 2014-04-20 13:37, schrieb Pine Wu:
Hello Vim devs:
The online doc (7.3) says send bugs to b...@vim.org, but in my vim
7.4 it says unless it's security issue just post it here. So here I am
:-)
As for i_Ctrl-U, vim doc says:
Delete all entered characters in the current line (see i_backspacing
about joining lines).
That is the case when you don't use arrow keys to move the cursor
e.g.
For a line:
vim
You type a, vim, Ctrl-U, what's left is
vim
That is what you'd expect, but
If you type a, vim, Left-Arrow, the line would be
vimvim
Then Ctrl-U
All text before cursor would be deleted, what's left is
m
I was expecting vim or vimm
I was going to say, for me the first result wouldn't be expected. While
the second one was.
Turns out, I have mapped Ctrl-U to break the undo sequence (to be able
to undo an accidental Ctrl-U)
and this results in always deleting until the first column, and for the
same reason, pressing
arrow keys results in that unexpected manner.
Turns out, because of patch 7.4.183, a fix is really simple, something
like the attached patch.
(I'll try to update that patch to include a test later today).
Interestingly, this has gotten unnoticed for so long. It seems Ctrl-U in
insert mode is
just such an mysteric command, that one always expects it to be doing
the wrong thing ;)
Best,
Christian
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/edit.c b/src/edit.c
--- a/src/edit.c
+++ b/src/edit.c
@@ -8760,8 +8760,8 @@ ins_bs(c, mode, inserted_space_p)
((curwin-w_cursor.lnum == 1 curwin-w_cursor.col == 0)
|| (!can_bs(BS_START)
(arrow_used
- || (curwin-w_cursor.lnum == Insstart.lnum
- curwin-w_cursor.col = Insstart.col)))
+ || (curwin-w_cursor.lnum == Insstart_orig.lnum
+ curwin-w_cursor.col = Insstart_orig.col)))
|| (!can_bs(BS_INDENT) !arrow_used ai_col 0
curwin-w_cursor.col = ai_col)
|| (!can_bs(BS_EOL) curwin-w_cursor.col == 0
@@ -8812,8 +8812,8 @@ ins_bs(c, mode, inserted_space_p)
*/
if (curwin-w_cursor.col == 0)
{
- lnum = Insstart.lnum;
- if (curwin-w_cursor.lnum == Insstart.lnum
+ lnum = Insstart_orig.lnum;
+ if (curwin-w_cursor.lnum == Insstart_orig.lnum
#ifdef FEAT_RIGHTLEFT
|| revins_on
#endif
@@ -8822,8 +8822,8 @@ ins_bs(c, mode, inserted_space_p)
if (u_save((linenr_T)(curwin-w_cursor.lnum - 2),
(linenr_T)(curwin-w_cursor.lnum + 1)) == FAIL)
return FALSE;
- --Insstart.lnum;
- Insstart.col = MAXCOL;
+ --Insstart_orig.lnum;
+ Insstart_orig.col = MAXCOL;
}
/*
* In replace mode:
@@ -8981,9 +8981,9 @@ ins_bs(c, mode, inserted_space_p)
while (vcol want_vcol)
{
/* Remember the first char we inserted */
- if (curwin-w_cursor.lnum == Insstart.lnum
-curwin-w_cursor.col Insstart.col)
- Insstart.col = curwin-w_cursor.col;
+ if (curwin-w_cursor.lnum == Insstart_orig.lnum
+curwin-w_cursor.col Insstart_orig.col)
+ Insstart_orig.col = curwin-w_cursor.col;
#ifdef FEAT_VREPLACE
if (State VREPLACE_FLAG)
@@ -9071,8 +9071,8 @@ ins_bs(c, mode, inserted_space_p)
revins_on ||
#endif
(curwin-w_cursor.col mincol
- (curwin-w_cursor.lnum != Insstart.lnum
- || curwin-w_cursor.col != Insstart.col)));
+ (curwin-w_cursor.lnum != Insstart_orig.lnum
+ || curwin-w_cursor.col != Insstart_orig.col)));
did_backspace = TRUE;
}
#ifdef FEAT_SMARTINDENT
@@ -9090,9 +9090,9 @@ ins_bs(c, mode, inserted_space_p)
AppendCharToRedobuff(c);
/* If deleted before the insertion point, adjust it */
-if (curwin-w_cursor.lnum == Insstart.lnum
-curwin-w_cursor.col Insstart.col)
- Insstart.col = curwin-w_cursor.col;
+if (curwin-w_cursor.lnum == Insstart_orig.lnum
+curwin-w_cursor.col Insstart_orig.col)
+ Insstart_orig.col = curwin-w_cursor.col;
/* vi behaviour: the cursor moves backward but the character that
* was there remains visible
Re: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
Am 2014-04-23 17:54, schrieb Ingo Karkat: You seem to be really knowledgable about Vim's internals. The question I have in mind right now is whether you still feel comfortable about those internal static variables, or whether you think this poses long-term risks to Vim's stability. For the current case, yes I believe it should be fixed correctly by saving and restoring all the static variables. But I am far from an expert on the Vim codebase and have probably already introduced too many bugs with my patches. I just enjoy hacking Vim code and trying to contribute. Vim has gotten really complex in certain areas and sometimes it is hard to figure out what is going on (because of autocommands that might kick in anywhere and result in unexpected ways). So this is becoming more and more a problem. At least some people think so, and have suggested / started a complete rewrite (in a language like C++ that has better means to avoid such). You are talking about neovim? I keep an eye on it, but I am not sure, a major rewrite is such a good idea and they already seem to drop support for certain plattforms (even Windows, I think). Is there anything (apart from more test coverage) that we can do with the current code base?! Yes, tests would probably be very welcome. But I admit, writing them is a huge PITA. Even more then patching the actual core ;) So anybody who likes to improve Vim by contributing tests is probably very welcome (can't talk for Bram, but I am sure he'll appreciate it). Best, Christian -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
Christian Brabandt wrote: Am 2014-04-23 16:28, schrieb Bram Moolenaar: Ingo Karkat wrote: I've noticed a regression: :s/.*/\=foo\nbar/ This correctly replaces the current line with two lines containing foo and bar, respectively. Now add the confirm flag, and accept the replacement: :s/.*/\=foo\nbar/c This replaces the current line with a single line containing foo^@bar (where ^@ is Nul). This is inconsistent and unexpected. Replacing with \r instead works (with and without the flag), and can be used as a workaround. Using the attached scriptlet, I've bisected this to the following patch: ,[ bad change ] | 7.3.225 \n in a substitute() inside :s not handled correctly ` The problem therefore can be seen in this and all following Vim versions, verified up to the latest 7.4.258. (I've used a HUGE build on both Windows/x64 and Linux/x64.) I cannot reproduce this problem. I see the problem with vim-airline. I think, it is caused by the evaluation of the statusline resetting reg_line_lbr when displaying the confirmation message. Attached patch fixes this, but I think one should also reset all the other internal static variables. Thanks for pinpointing the problem. I don't think the variables need to be saved/restored. reg_line_lbr should be set in vim_regsub() and vim_regusub_multi(), instead of relying it's still the right value from a previous vim_regexec.*(). -- From know your smileys: :~)A man with a tape recorder up his nose /// 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: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
Ingo Karkat wrote:
I've noticed a regression:
:s/.*/\=foo\nbar/
This correctly replaces the current line with two lines containing foo
and bar, respectively. Now add the confirm flag, and accept the
replacement:
:s/.*/\=foo\nbar/c
This replaces the current line with a single line containing foo^@bar
(where ^@ is Nul). This is inconsistent and unexpected. Replacing with
\r instead works (with and without the flag), and can be used as a
workaround.
Using the attached scriptlet, I've bisected this to the following patch:
,[ bad change ]
| 7.3.225 \n in a substitute() inside :s not handled correctly
`
The problem therefore can be seen in this and all following Vim
versions, verified up to the latest 7.4.258. (I've used a HUGE build on
both Windows/x64 and Linux/x64.)
I cannot reproduce this problem.
Ah, sorry, I missed one crucial detail of my environment (and forgot to
use -N -u NONE). In my 'statusline', I have a custom function that
performs a =~ comparison. Define the following:
function! TitleString()
let check = 'foo' =~ 'bar'
return
endfunction
set titlestring=%{TitleString()}
Then, the
:s/.*/\=foo\nbar/c
command will produce the ^@. So the =~ (probably triggered while the
confirm flag is in action) somehow affects the behavior of :substitute.
Attached is an updated scriptlet.
Thanks, now I see the problem. I'll use that script to create a test
from.
--
From know your smileys:
:-HIs missing teeth
/// 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: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag
Ingo Karkat wrote: On 23-Apr-2014 17:37 +0200, Christian Brabandt wrote: Am 2014-04-23 16:28, schrieb Bram Moolenaar: Ingo Karkat wrote: I've noticed a regression: :s/.*/\=foo\nbar/ This correctly replaces the current line with two lines containing foo and bar, respectively. Now add the confirm flag, and accept the replacement: :s/.*/\=foo\nbar/c This replaces the current line with a single line containing foo^@bar (where ^@ is Nul). This is inconsistent and unexpected. Replacing with \r instead works (with and without the flag), and can be used as a workaround. Using the attached scriptlet, I've bisected this to the following patch: ,[ bad change ] | 7.3.225 \n in a substitute() inside :s not handled correctly ` The problem therefore can be seen in this and all following Vim versions, verified up to the latest 7.4.258. (I've used a HUGE build on both Windows/x64 and Linux/x64.) I cannot reproduce this problem. I see the problem with vim-airline. I think, it is caused by the evaluation of the statusline resetting reg_line_lbr when displaying the confirmation message. Attached patch fixes this, but I think one should also reset all the other internal static variables. Thanks Christian, that patch indeed fixes the problem for me. Good hunch about the statusline, that is indeed a necessary condition (as I have added in my updated message). You seem to be really knowledgable about Vim's internals. The question I have in mind right now is whether you still feel comfortable about those internal static variables, or whether you think this poses long-term risks to Vim's stability. At least some people think so, and have suggested / started a complete rewrite (in a language like C++ that has better means to avoid such). Is there anything (apart from more test coverage) that we can do with the current code base?! Traditionally Vim has been using a lot of global variables. Gradually I have been moving them into structs. This started when supporting multiple buffers and windows. There still is more to do. A complete rewrite is likely to introduce lots of new problems, another language won't help much. Refactoring is a much better solution. -- From know your smileys: :-)Funny |-)Funny Oriental (-:Funny Australian /// 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.261
Patch 7.4.261
Problem:When updating the window involves a regexp pattern, an interactive
substitute to replace a \n with a line break fails. (Ingo
Karkat)
Solution: Set reg_line_lbr in vim_regsub() and vim_regsub_multi().
Files: src/regexp.c, src/testdir/test79.in, src/testdir/test79.ok
*** ../vim-7.4.260/src/regexp.c 2014-04-06 21:33:39.671363743 +0200
--- src/regexp.c2014-04-23 18:40:37.094866280 +0200
***
*** 7381,7386
--- 7381,7387
reg_mmatch = NULL;
reg_maxline = 0;
reg_buf = curbuf;
+ reg_line_lbr = TRUE;
return vim_regsub_both(source, dest, copy, magic, backslash);
}
#endif
***
*** 7400,7405
--- 7401,7407
reg_buf = curbuf; /* always works on the current buffer! */
reg_firstlnum = lnum;
reg_maxline = curbuf-b_ml.ml_line_count - lnum;
+ reg_line_lbr = FALSE;
return vim_regsub_both(source, dest, copy, magic, backslash);
}
*** ../vim-7.4.260/src/testdir/test79.in2014-04-02 19:00:53.043644100
+0200
--- src/testdir/test79.in 2014-04-23 18:36:29.158872254 +0200
***
*** 1,6
--- 1,7
Test for *sub-replace-special* and *sub-replace-expression* on :substitute.
Test for submatch() on :substitue.
Test for *:s%* on :substitute.
+ Test for :s replacing \n with line break.
STARTTEST
:so small.vim
***
*** 234,239
--- 235,254
Q
STARTTEST
+ :function! TitleString()
+ let check = 'foo' =~ 'bar'
+ return
+ endfunction
+ :set titlestring=%{TitleString()}
+ :/^test_one/s/.*/\=foo\nbar/
+ :/^test_two/s/.*/\=foo\nbar/c
+ y
+ ENDTEST
+
+ test_one
+ test_two
+
+ STARTTEST
:g/^STARTTEST/.,/^ENDTEST/d
:1;/^Results/,$wq! test.out
:call getchar()
*** ../vim-7.4.260/src/testdir/test79.ok2014-04-02 19:00:53.043644100
+0200
--- src/testdir/test79.ok 2014-04-23 18:35:30.650873664 +0200
***
*** 126,128
--- 126,134
Q
Q
+
+ foo
+ bar
+ foo
+ bar
+
*** ../vim-7.4.260/src/version.c2014-04-23 17:43:37.366948683 +0200
--- src/version.c 2014-04-23 18:46:45.250857408 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 261,
/**/
--
From know your smileys:
!-|I-am-a-Cylon-Centurian-with-one-red-eye-bouncing-back-and-forth
/// 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.262
Patch 7.4.262
Problem:Duplicate code in regexec().
Solution: Add line_lbr flag to regexec_nl().
Files: src/regexp.c, src/regexp_nfa.c, src/regexp.h
*** ../vim-7.4.261/src/regexp.c 2014-04-23 18:48:43.546854558 +0200
--- src/regexp.c2014-04-23 18:59:38.606838773 +0200
***
*** 3709,3733
/* TRUE if using multi-line regexp. */
#define REG_MULTI (reg_match == NULL)
! static int bt_regexec __ARGS((regmatch_T *rmp, char_u *line, colnr_T col));
/*
* Match a regexp against a string.
* rmp-regprog is a compiled regexp as returned by vim_regcomp().
* Uses curbuf for line count and 'iskeyword'.
*
* Return TRUE if there is a match, FALSE if not.
*/
static int
! bt_regexec(rmp, line, col)
regmatch_T*rmp;
char_u*line; /* string to match against */
colnr_T col;/* column to start looking for match */
{
reg_match = rmp;
reg_mmatch = NULL;
reg_maxline = 0;
! reg_line_lbr = FALSE;
reg_buf = curbuf;
reg_win = NULL;
ireg_ic = rmp-rm_ic;
--- 3709,3736
/* TRUE if using multi-line regexp. */
#define REG_MULTI (reg_match == NULL)
! static int bt_regexec_nl __ARGS((regmatch_T *rmp, char_u *line, colnr_T col,
int line_lbr));
!
/*
* Match a regexp against a string.
* rmp-regprog is a compiled regexp as returned by vim_regcomp().
* Uses curbuf for line count and 'iskeyword'.
+ * if line_lbr is TRUE consider a \n in line to be a line break.
*
* Return TRUE if there is a match, FALSE if not.
*/
static int
! bt_regexec_nl(rmp, line, col, line_lbr)
regmatch_T*rmp;
char_u*line; /* string to match against */
colnr_T col;/* column to start looking for match */
+ int line_lbr;
{
reg_match = rmp;
reg_mmatch = NULL;
reg_maxline = 0;
! reg_line_lbr = line_lbr;
reg_buf = curbuf;
reg_win = NULL;
ireg_ic = rmp-rm_ic;
***
*** 3738,3772
return (bt_regexec_both(line, col, NULL) != 0);
}
- #if defined(FEAT_MODIFY_FNAME) || defined(FEAT_EVAL) \
- || defined(FIND_REPLACE_DIALOG) || defined(PROTO)
-
- static int bt_regexec_nl __ARGS((regmatch_T *rmp, char_u *line, colnr_T
col));
-
- /*
- * Like vim_regexec(), but consider a \n in line to be a line break.
- */
- static int
- bt_regexec_nl(rmp, line, col)
- regmatch_T*rmp;
- char_u*line; /* string to match against */
- colnr_T col;/* column to start looking for match */
- {
- reg_match = rmp;
- reg_mmatch = NULL;
- reg_maxline = 0;
- reg_line_lbr = TRUE;
- reg_buf = curbuf;
- reg_win = NULL;
- ireg_ic = rmp-rm_ic;
- #ifdef FEAT_MBYTE
- ireg_icombine = FALSE;
- #endif
- ireg_maxcol = 0;
- return (bt_regexec_both(line, col, NULL) != 0);
- }
- #endif
-
static long bt_regexec_multi __ARGS((regmmatch_T *rmp, win_T *win, buf_T
*buf, linenr_T lnum, colnr_T col, proftime_T *tm));
/*
--- 3741,3746
***
*** 7985,7995
{
bt_regcomp,
bt_regfree,
- bt_regexec,
- #if defined(FEAT_MODIFY_FNAME) || defined(FEAT_EVAL) \
- || defined(FIND_REPLACE_DIALOG) || defined(PROTO)
bt_regexec_nl,
- #endif
bt_regexec_multi
#ifdef DEBUG
,(char_u *)
--- 7959,7965
***
*** 8003,8013
{
nfa_regcomp,
nfa_regfree,
- nfa_regexec,
- #if defined(FEAT_MODIFY_FNAME) || defined(FEAT_EVAL) \
- || defined(FIND_REPLACE_DIALOG) || defined(PROTO)
nfa_regexec_nl,
- #endif
nfa_regexec_multi
#ifdef DEBUG
,(char_u *)
--- 7973,7979
***
*** 8131,8137
char_u *line; /* string to match against */
colnr_T col;/* column to start looking for match */
{
! return rmp-regprog-engine-regexec(rmp, line, col);
}
#if defined(FEAT_MODIFY_FNAME) || defined(FEAT_EVAL) \
--- 8097,8103
char_u *line; /* string to match against */
colnr_T col;/* column to start looking for match */
{
! return rmp-regprog-engine-regexec_nl(rmp, line, col, FALSE);
}
#if defined(FEAT_MODIFY_FNAME) || defined(FEAT_EVAL) \
***
*** 8145,8151
char_u *line;
colnr_T col;
{
! return rmp-regprog-engine-regexec_nl(rmp, line, col);
}
#endif
--- 8111,8117
char_u *line;
colnr_T col;
{
! return rmp-regprog-engine-regexec_nl(rmp, line, col, TRUE);
}
#endif
*** ../vim-7.4.261/src/regexp_nfa.c 2014-04-06 21:33:39.675363743 +0200
--- src/regexp_nfa.c2014-04-23 19:00:44.354837189 +0200
***
*** 311,317
static long nfa_regexec_both __ARGS((char_u *line, colnr_T col));
static regprog_T *nfa_regcomp __ARGS((char_u *expr, int re_flags));
static void nfa_regfree __ARGS((regprog_T *prog));
! static int nfa_regexec __ARGS((regmatch_T *rmp, char_u *line, colnr_T col));
Re: Patch 7.4.260
Kent Sibilev wrote:
After this change, in contrary to the documentation, I cannot define a
global function like this:
function g:Foo()
endfunction
Sorry, the documentation is wrong. Although I could just skip the g:,
in case some people have already been using this in plugins.
Also, what is the reason to restrict this case:
function Foo()
endfunction
let b:my_func = function('Foo')
What do you mean? That works.
--
From know your smileys:
:-O-o Smiley American tourist (note big mouth and camera)
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.260
On Wednesday, April 23, 2014 1:30:15 PM UTC-4, Bram Moolenaar wrote:
Kent Sibilev wrote:
After this change, in contrary to the documentation, I cannot define a
global function like this:
function g:Foo()
endfunction
Sorry, the documentation is wrong. Although I could just skip the g:,
in case some people have already been using this in plugins.
Yes. It broke several plugins that i'm using.
Also, what is the reason to restrict this case:
function Foo()
endfunction
let b:my_func = function('Foo')
What do you mean? That works.
I'm getting this error:
E884: Function name cannot contain a colon: b:my_func
Regards,
Kent.
--
--
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.263
Patch 7.4.263
Problem:GCC 4.8 compiler warning for hiding a declaration (Francois Gannaz)
Solution: Remove the second declaration.
Files: src/eval.c
*** ../vim-7.4.262/src/eval.c 2014-04-23 17:43:37.362948683 +0200
--- src/eval.c 2014-04-23 19:34:46.678787977 +0200
***
*** 18319,18325
char_u *s = NULL;
char_u *start;
char_u *end;
- char_u *p;
int i;
res = get_cmd_output(get_tv_string(argvars[0]), infile,
--- 18319,18324
*** ../vim-7.4.262/src/version.c2014-04-23 19:06:33.702828771 +0200
--- src/version.c 2014-04-23 19:43:22.366775550 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 263,
/**/
--
How many light bulbs does it take to change a person?
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.260
On 23 April 2014, Kent Sibilev ksibi...@gmail.com wrote: On Wednesday, April 23, 2014 1:30:15 PM UTC-4, Bram Moolenaar wrote: Kent Sibilev wrote: After this change, in contrary to the documentation, I cannot define a global function like this: function g:Foo() endfunction Sorry, the documentation is wrong. Although I could just skip the g:, in case some people have already been using this in plugins. Yes. It broke several plugins that i'm using. [...] +1 This breaks a lot of plugins, for no reason whatsoever. The authors have simply trusted the docs that g: is fine, they shouldn't be punished for that. /lcd -- -- 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.260
Kent Sibilev wrote:
After this change, in contrary to the documentation, I cannot define a
global function like this:
function g:Foo()
endfunction
Sorry, the documentation is wrong. Although I could just skip the g:,
in case some people have already been using this in plugins.
Yes. It broke several plugins that i'm using.
OK, I'll allow that then.
Also, what is the reason to restrict this case:
function Foo()
endfunction
let b:my_func = function('Foo')
What do you mean? That works.
I'm getting this error:
E884: Function name cannot contain a colon: b:my_func
Sorry, I tried with an older Vim. I'll see how that should be fixed.
--
From know your smileys:
:-)-O Smiling doctor with stethoscope
/// 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: Bug for i_Ctrl-U
Hi Bram! On Mi, 23 Apr 2014, Bram Moolenaar wrote: Christian Brabandt wrote: Am 2014-04-20 13:37, schrieb Pine Wu: Hello Vim devs: The online doc (7.3) says send bugs to b...@vim.org, but in my vim 7.4 it says unless it's security issue just post it here. So here I am :-) As for i_Ctrl-U, vim doc says: Delete all entered characters in the current line (see i_backspacing about joining lines). That is the case when you don't use arrow keys to move the cursor e.g. For a line: vim You type a, vim, Ctrl-U, what's left is vim That is what you'd expect, but If you type a, vim, Left-Arrow, the line would be vimvim Then Ctrl-U All text before cursor would be deleted, what's left is m I was expecting vim or vimm I was going to say, for me the first result wouldn't be expected. While the second one was. Turns out, I have mapped Ctrl-U to break the undo sequence (to be able to undo an accidental Ctrl-U) and this results in always deleting until the first column, and for the same reason, pressing arrow keys results in that unexpected manner. Turns out, because of patch 7.4.183, a fix is really simple, something like the attached patch. (I'll try to update that patch to include a test later today). Interestingly, this has gotten unnoticed for so long. It seems Ctrl-U in insert mode is just such an mysteric command, that one always expects it to be doing the wrong thing ;) I also have trouble reproducing this. 'compatible' matters. Anyway, can you please add some test for this to the patch? Here we go. I added some more usage of i_Ctrl-U Best, Christian -- Fällt der Speicher aus dem Tower, sind die Daten nicht von Dauer. -- -- 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: Bug for i_Ctrl-U
On Mi, 23 Apr 2014, Christian Brabandt wrote: Hi Bram! On Mi, 23 Apr 2014, Bram Moolenaar wrote: Christian Brabandt wrote: Am 2014-04-20 13:37, schrieb Pine Wu: Hello Vim devs: The online doc (7.3) says send bugs to b...@vim.org, but in my vim 7.4 it says unless it's security issue just post it here. So here I am :-) As for i_Ctrl-U, vim doc says: Delete all entered characters in the current line (see i_backspacing about joining lines). That is the case when you don't use arrow keys to move the cursor e.g. For a line: vim You type a, vim, Ctrl-U, what's left is vim That is what you'd expect, but If you type a, vim, Left-Arrow, the line would be vimvim Then Ctrl-U All text before cursor would be deleted, what's left is m I was expecting vim or vimm I was going to say, for me the first result wouldn't be expected. While the second one was. Turns out, I have mapped Ctrl-U to break the undo sequence (to be able to undo an accidental Ctrl-U) and this results in always deleting until the first column, and for the same reason, pressing arrow keys results in that unexpected manner. Turns out, because of patch 7.4.183, a fix is really simple, something like the attached patch. (I'll try to update that patch to include a test later today). Interestingly, this has gotten unnoticed for so long. It seems Ctrl-U in insert mode is just such an mysteric command, that one always expects it to be doing the wrong thing ;) I also have trouble reproducing this. 'compatible' matters. Anyway, can you please add some test for this to the patch? Here we go. I added some more usage of i_Ctrl-U I think, it is actually reasonable, to expect an attachment. So let's try that again. Best, Christian -- Es sind aber die Schmutzigsten, von denen man sagt, daß sie mit allen Wassern gewaschen sind. -- -- 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: Bug for i_Ctrl-U
On Mi, 23 Apr 2014, Christian Brabandt wrote:
Here we go. I added some more usage of i_Ctrl-U
I think, it is actually reasonable, to expect an attachment. So let's
try that again.
Okay, this is becoming ridiculous now.
Perhaps I need a couple of more attempts ;)
Best,
Christian
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/edit.c b/src/edit.c
--- a/src/edit.c
+++ b/src/edit.c
@@ -8760,8 +8760,8 @@ ins_bs(c, mode, inserted_space_p)
((curwin-w_cursor.lnum == 1 curwin-w_cursor.col == 0)
|| (!can_bs(BS_START)
(arrow_used
- || (curwin-w_cursor.lnum == Insstart.lnum
- curwin-w_cursor.col = Insstart.col)))
+ || (curwin-w_cursor.lnum == Insstart_orig.lnum
+ curwin-w_cursor.col = Insstart_orig.col)))
|| (!can_bs(BS_INDENT) !arrow_used ai_col 0
curwin-w_cursor.col = ai_col)
|| (!can_bs(BS_EOL) curwin-w_cursor.col == 0
@@ -8812,8 +8812,8 @@ ins_bs(c, mode, inserted_space_p)
*/
if (curwin-w_cursor.col == 0)
{
- lnum = Insstart.lnum;
- if (curwin-w_cursor.lnum == Insstart.lnum
+ lnum = Insstart_orig.lnum;
+ if (curwin-w_cursor.lnum == Insstart_orig.lnum
#ifdef FEAT_RIGHTLEFT
|| revins_on
#endif
@@ -8822,8 +8822,8 @@ ins_bs(c, mode, inserted_space_p)
if (u_save((linenr_T)(curwin-w_cursor.lnum - 2),
(linenr_T)(curwin-w_cursor.lnum + 1)) == FAIL)
return FALSE;
- --Insstart.lnum;
- Insstart.col = MAXCOL;
+ --Insstart_orig.lnum;
+ Insstart_orig.col = MAXCOL;
}
/*
* In replace mode:
@@ -8981,9 +8981,9 @@ ins_bs(c, mode, inserted_space_p)
while (vcol want_vcol)
{
/* Remember the first char we inserted */
- if (curwin-w_cursor.lnum == Insstart.lnum
-curwin-w_cursor.col Insstart.col)
- Insstart.col = curwin-w_cursor.col;
+ if (curwin-w_cursor.lnum == Insstart_orig.lnum
+curwin-w_cursor.col Insstart_orig.col)
+ Insstart_orig.col = curwin-w_cursor.col;
#ifdef FEAT_VREPLACE
if (State VREPLACE_FLAG)
@@ -9071,8 +9071,8 @@ ins_bs(c, mode, inserted_space_p)
revins_on ||
#endif
(curwin-w_cursor.col mincol
- (curwin-w_cursor.lnum != Insstart.lnum
- || curwin-w_cursor.col != Insstart.col)));
+ (curwin-w_cursor.lnum != Insstart_orig.lnum
+ || curwin-w_cursor.col != Insstart_orig.col)));
did_backspace = TRUE;
}
#ifdef FEAT_SMARTINDENT
@@ -9090,9 +9090,9 @@ ins_bs(c, mode, inserted_space_p)
AppendCharToRedobuff(c);
/* If deleted before the insertion point, adjust it */
-if (curwin-w_cursor.lnum == Insstart.lnum
-curwin-w_cursor.col Insstart.col)
- Insstart.col = curwin-w_cursor.col;
+if (curwin-w_cursor.lnum == Insstart_orig.lnum
+curwin-w_cursor.col Insstart_orig.col)
+ Insstart_orig.col = curwin-w_cursor.col;
/* vi behaviour: the cursor moves backward but the character that
* was there remains visible
diff --git a/src/testdir/test29.in b/src/testdir/test29.in
--- a/src/testdir/test29.in
+++ b/src/testdir/test29.in
@@ -102,6 +102,34 @@ if (condition) // Remove the next commen
}
STARTTEST
+: Test with backspace set to the non-compatible setting
+/^\d\+ this
+:set cp bs=2
+Avim1
+Avim2u
+:set cpo-=
+:inoremap c-u leftc-u
+Avim3
+:iunmap c-u
+Avim4
+: Test with backspace set to the compatible setting
+:set bs=
+A vim5A
+A vim6Azweiu
+:inoremap c-u leftc-u
+A vim7
+:set cp
+ENDTEST
+1 this shouldn't be deleted
+2 this shouldn't be deleted
+3 this shouldn't be deleted
+4 this should be deleted
+5 this shouldn't be deleted
+6 this shouldn't be deleted
+7 this shouldn't be deleted
+8 this shouldn't be deleted (not touched yet)
+
+STARTTEST
/^{/+1
:set comments=sO:*\ -,mO:*\ \ ,exO:*/
:set comments+=s1:/*,mb:*,ex:*/,://
diff --git a/src/testdir/test29.ok b/src/testdir/test29.ok
--- a/src/testdir/test29.ok
+++ b/src/testdir/test29.ok
@@ -62,6 +62,15 @@ if (condition) // Remove the next commen
action();
}
+1 this shouldn't be deleted
+2 this shouldn't be deleted
+3 this shouldn't be deleted
+4 this should be deleted3
+
+6 this shouldn't be deleted vim5
+7 this shouldn't be deleted vim6
+8 this shouldn't be deleted (not touched yet) vim7
+
{
/* Make sure the previous comment leader is not removed. */
Patch 7.4.264
Patch 7.4.264 (after 7.4.260)
Problem:Can't define a function starting with g:. Can't assign a
funcref to a buffer-local variable.
Solution: Skip g: at the start of a function name. Don't check for colons
when assigning to a variable.
Files: src/eval.c, src/testdir/test_eval.in, src/testdir/test_eval.ok
*** ../vim-7.4.263/src/eval.c 2014-04-23 19:44:26.366774008 +0200
--- src/eval.c 2014-04-23 20:40:16.738693276 +0200
***
*** 21583,21589
* Get the function name. There are these situations:
* func normal function name
*name == func, fudi.fd_dict == NULL
- * s:func script-local function name
* dict.funcnew dictionary entry
*name == NULL, fudi.fd_dict set,
*fudi.fd_di == NULL, fudi.fd_newkey == func
--- 21583,21588
***
*** 21593,21598
--- 21592,21599
* dict.funcexisting dict entry that's not a Funcref
*name == NULL, fudi.fd_dict set,
*fudi.fd_di set, fudi.fd_newkey == NULL
+ * s:func script-local function name
+ * g:func global function name, same as func
*/
p = eap-arg;
name = trans_function_name(p, eap-skip, 0, fudi);
***
*** 22286,22292
}
else
{
! if (lead == 2) /* skip over s: */
lv.ll_name += 2;
len = (int)(end - lv.ll_name);
}
--- 22287,22294
}
else
{
! /* skip over s: and g: */
! if (lead == 2 || (lv.ll_name[0] == 'g' lv.ll_name[1] == ':'))
lv.ll_name += 2;
len = (int)(end - lv.ll_name);
}
***
*** 22317,22333
else if (!(flags TFN_INT) builtin_function(lv.ll_name, len))
{
EMSG2(_(E128: Function name must start with a capital or \s:\: %s),
! lv.ll_name);
goto theend;
}
! if (!skip)
{
char_u *cp = vim_strchr(lv.ll_name, ':');
if (cp != NULL cp end)
{
! EMSG2(_(E884: Function name cannot contain a colon: %s),
! lv.ll_name);
goto theend;
}
}
--- 22319,22334
else if (!(flags TFN_INT) builtin_function(lv.ll_name, len))
{
EMSG2(_(E128: Function name must start with a capital or \s:\: %s),
! start);
goto theend;
}
! if (!skip !(flags TFN_QUIET))
{
char_u *cp = vim_strchr(lv.ll_name, ':');
if (cp != NULL cp end)
{
! EMSG2(_(E884: Function name cannot contain a colon: %s), start);
goto theend;
}
}
*** ../vim-7.4.263/src/testdir/test_eval.in 2014-04-23 17:43:37.362948683
+0200
--- src/testdir/test_eval.in2014-04-23 20:36:50.494698246 +0200
***
*** 144,150
:delcommand AR
:call garbagecollect(1)
:
! : function name includes a colon
:try
:func! g:test()
:echo test
--- 144,150
:delcommand AR
:call garbagecollect(1)
:
! : function name not starting with capital
:try
:func! g:test()
:echo test
***
*** 153,158
--- 153,167
:$put =v:exception
:endtry
:
+ : function name includes a colon
+ :try
+ :func! b:test()
+ :echo test
+ :endfunc
+ :catch
+ :$put =v:exception
+ :endtry
+ :
: function name folowed by #
:try
:func! test2() #
***
*** 162,167
--- 171,183
:$put =v:exception
:endtry
:
+ : function name starting with/without g:, buffer-local funcref.
+ :function! g:Foo()
+ : $put ='called Foo()'
+ :endfunction
+ :let b:my_func = function('Foo')
+ :call b:my_func()
+ :
:/^start:/+1,$wq! test.out
: vim: et ts=4 isk-=\: fmr=???,???
:call getchar()
*** ../vim-7.4.263/src/testdir/test_eval.ok 2014-04-23 17:43:37.362948683
+0200
--- src/testdir/test_eval.ok2014-04-23 20:37:45.526696920 +0200
***
*** 336,339
--- 336,341
Executing call setreg(1, [, , [], ])
Vim(call):E730: using List as a String
Vim(function):E128: Function name must start with a capital or s:: g:test()
+ Vim(function):E128: Function name must start with a capital or s:: b:test()
Vim(function):E128: Function name must start with a capital or s:: test2()
#
+ called Foo()
*** ../vim-7.4.263/src/version.c2014-04-23 19:44:26.370774008 +0200
--- src/version.c 2014-04-23 20:27:17.614712050 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 264,
/**/
--
In order for something to become clean, something else must become dirty;
but you can get everything dirty without getting anything clean.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net
Re: Bug for i_Ctrl-U
Christian Brabandt wrote: On Mi, 23 Apr 2014, Christian Brabandt wrote: Here we go. I added some more usage of i_Ctrl-U I think, it is actually reasonable, to expect an attachment. So let's try that again. Okay, this is becoming ridiculous now. Perhaps I need a couple of more attempts ;) Or more coffee :-). Worked now, thanks. -- You are only young once, but you can stay immature indefinitely. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.264
On 23 April 2014, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.4.264 (after 7.4.260) Problem:Can't define a function starting with g:. Can't assign a funcref to a buffer-local variable. Solution: Skip g: at the start of a function name. Don't check for colons when assigning to a variable. [...] Thank you, it's now back to sanity. /lcd -- -- 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.264
Patch 7.4.264 (after 7.4.260) Problem:Can't define a function starting with g:. Can't assign a funcref to a buffer-local variable. Solution: Skip g: at the start of a function name. Don't check for colons when assigning to a variable. I'm still having problems: line 17: E121: Undefined variable: g:vundle_last_status E15: Invalid expression: 'updated' == g:vundle_last_status empty(msg) Error detected while processing function vundle#installer#new..SNR106_process. .vundle#installer#run..vundle#installer#install..SNR106_sync: line6: E117: Unknown function: g:shellesc_cd E15: Invalid expression: g:shellesc_cd(cmd) Error detected while processing function vundle#installer#new..SNR106_process: line 13: E121: Undefined variable: g:vundle_last_status E15: Invalid expression: 'error' == g:vundle_last_status line 17: E121: Undefined variable: g:vundle_last_status E15: Invalid expression: 'updated' == g:vundle_last_status empty(msg) Error detected while processing function vundle#installer#new..SNR106_process. .vundle#installer#run..vundle#installer#install..SNR106_sync: line6: E117: Unknown function: g:shellesc_cd E15: Invalid expression: g:shellesc_cd(cmd) Error detected while processing function vundle#installer#new..SNR106_process: line 13: E121: Undefined variable: g:vundle_last_status E15: Invalid expression: 'error' == g:vundle_last_status the following looks more like it's the script author fault, but I'm not sure if all the errors are due to the illegal function name or not, so I'm pasting them all: Error detected while processing /Users/matteo/.vim/bundle/vdebug/plugin/vdebug.vim: line 151: E128: Function name must start with a capital or s:: vdebug:get_visual_selection() line 155: E684: list index out of range: -1 E15: Invalid expression: lines[-1][: col2 - 1] line 156: E684: list index out of range: 0 E15: Invalid expression: lines[0][col1 - 1:] line 157: E133: :return not inside a function line 158: E193: :endfunction not inside a function line 160: E128: Function name must start with a capital or s:: vdebug:edit(filename) line 162: E121: Undefined variable: a:filename E116: Invalid arguments for function fnameescape(a:filename) E15: Invalid expression: fnameescape(a:filename) Press ENTER or type command to continue -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
