Re: Toggling local option value also changes global value
On Wed, Aug 3, 2016 at 7:29 PM, Christian Brabandt wrote: > Hi Tony! [...] > That has been discussed before: > https://groups.google.com/d/msg/vim_dev/HpwZWJojl3E/4zCBH3qWQ5IJ > > Best, > Christian > -- > Die Vergangenheit sollten wir als Sprungbrett benutzen, nicht als Sofa. I had forgotten that discussion of 2012 even though I participated in it, but it has (a few posts down) clear steps to reproduce, and I thought then, and I still think now, that it is a bug. When an option has a global setting and a local setting which can (at least in some circumstances) be different, changing the one via :setlocal or :setglobal ought never to change the other. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] Put ~ markers into their own highlight group
On Sun, Nov 02, 2014 at 09:55:07PM +0100, Bram Moolenaar wrote:
>
> Marco Hinz wrote:
>
> > Bram Moolenaar wrote (Fri, Oct 31, 2014 at 01:03:59PM +0100):
> >
> > > The only bit that I don't like is having to change all color schemes
> > > to add the highlight link. Can't this be done by default? Instead of
> > > specifying colors that are initially equal to NonText, link
> > > EndOfBuffer to NonText when initializing the colors.
> >
> > You're right, and it was only one line that had to be changed in the
> > patch. Now EndOfBuffer gets linked to NonText when the built-in colors
> > get initialized.
>
> Thanks for the update. I'll add it in the todo list.
Updated patch to build against 7.4.2152.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
--
--
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 i/runtime/doc/options.txt w/runtime/doc/options.txt
index 16002dd..c44e1af 100644
--- i/runtime/doc/options.txt
+++ w/runtime/doc/options.txt
@@ -3945,17 +3945,16 @@ A jump table for the options with a short description can be found at |Q_op|.
*'highlight'* *'hl'*
'highlight' 'hl' string (default (as a single string):
- "8:SpecialKey,@:NonText,d:Directory,
- e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,
- M:ModeMsg,n:LineNr,N:CursorLineNr,
- r:Question,s:StatusLine,S:StatusLineNC,
- c:VertSplit, t:Title,v:Visual,
- w:WarningMsg,W:WildMenu,
- f:Folded,F:FoldColumn,A:DiffAdd,
- C:DiffChange,D:DiffDelete,T:DiffText,
- >:SignColumn,B:SpellBad,P:SpellCap,
- R:SpellRare,L:SpellLocal,-:Conceal,
- +:Pmenu,=:PmenuSel,
+ "8:SpecialKey,~:EndOfBuffer,@:NonText,
+ d:Directory,e:ErrorMsg,i:IncSearch,
+ l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,
+ N:CursorLineNr,r:Question,s:StatusLine,
+ S:StatusLineNC,c:VertSplit,t:Title,
+ v:Visual,w:WarningMsg,W:WildMenu,f:Folded,
+ F:FoldColumn,A:DiffAdd,C:DiffChange,
+ D:DiffDelete,T:DiffText,>:SignColumn,
+ B:SpellBad,P:SpellCap,R:SpellRare,
+ L:SpellLocal,-:Conceal,+:Pmenu,=:PmenuSel,
x:PmenuSbar,X:PmenuThumb")
global
{not in Vi}
@@ -3964,7 +3963,8 @@ A jump table for the options with a short description can be found at |Q_op|.
first character in a pair gives the occasion, the second the mode to
use for that occasion. The occasions are:
|hl-SpecialKey| 8 Meta and special keys listed with ":map"
- |hl-NonText| @ '~' and '@' at the end of the window and
+ |hl-EndOfBuffer| ~ lines after the last line in the buffer
+ |hl-NonText| @ '@' at the end of the window and
characters from 'showbreak'
|hl-Directory| d directories in CTRL-D listing and other special
things in listings
diff --git i/runtime/doc/syntax.txt w/runtime/doc/syntax.txt
index 20af7ce..bbb1b00 100644
--- i/runtime/doc/syntax.txt
+++ w/runtime/doc/syntax.txt
@@ -4868,6 +4868,9 @@ DiffChange diff mode: Changed line |diff.txt|
DiffDelete diff mode: Deleted line |diff.txt|
*hl-DiffText*
DiffText diff mode: Changed text within a changed line |diff.txt|
+ *hl-EndofBuffer*
+EndOfBuffer filler lines (~) after the last line in the buffer.
+ By default, this is highlighted like |hl-NonText|.
*hl-ErrorMsg*
ErrorMsg error messages on the command line
*hl-VertSplit*
@@ -4896,10 +4899,10 @@ ModeMsg 'showmode' message (e.g., "-- INSERT --")
*hl-MoreMsg*
MoreMsg |more-prompt|
*hl-NonText*
-NonText '~' and '@' at the end of the window, characters from
- 'showbreak' and other characters that do not really exist in
- the text (e.g., ">" displayed when a double-wide character
- doesn't fit at the end of the line).
+NonText '@' at the end of the window, characters from 'showbreak'
+ and other characters that do not really exist in the text
+ (e.g., ">" displayed when a double-wide character doesn't
+ fit at the end of the line).
*hl-Normal*
Normal normal text
*hl-Pmenu*
diff --git i/src/option.c w/src/option.c
index b9b59ee..a57cf98 100644
--- i/src/option.c
+++ w/src/option.c
@@ -468,7 +468,7 @@ struct vimoption
#if defined(FEAT_DIFF) || defined(FEAT_FOLDING) || defined(FEAT_SPELL) \
|| defined(FEAT_WINDOWS) || defined(FEAT_CLIPBOARD) \
|| defined(FEAT_INS_EXPAND) || defined(FEAT_SYN_HL) || defined(FEAT_CONCEAL)
-# define HIGHLIGHT_INIT "8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,N:CursorLineNr,r:Question,s:StatusLine,S:StatusLin
Re: Wish list for a more powerful search in Vim
On Wednesday, August 3, 2016 at 3:54:18 PM UTC-4, Christian Brabandt wrote: > I attach an updated patch, which fixes all issues mentioned so far. > Additionally I added a test for this. > > I will be away the next 2-3 weeks, so won't have time to work on this > further. However, I'd appreciate feedback and will work further on it > after I return, if there are more issues. > > Oh and before I forget to mention it. I made Ctrl-N always go further > down and Ctrl-P always go further up and I don't intend to change that. > > Best, > Christian I really like this patch. Thanks for working on it. 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.
Re: Wish list for a more powerful search in Vim
Hi Christian, On Wed, Aug 3, 2016 at 12:54 PM, Christian Brabandt wrote: > > On Fr, 29 Jul 2016, Yegappan Lakshmanan wrote: > >> On Fri, Jul 29, 2016 at 11:03 AM, Christian Brabandt >> wrote: >> >> On Thu, Jul 28, 2016 at 11:16 PM, Christian Brabandt >> >> wrote: >> >> > On Do, 28 Jul 2016, Bram Moolenaar wrote: >> >> > >> >> >> I think it should. Most users will have 'wrapscan' on, since it is the >> >> >> default. If someone switches it off he must have a reason for it. >> >> > >> >> > okay, fixed with the latest version >> >> > >> >> >> >> I tested the latest patch and the confirmed that the problems I reported >> >> earlier >> >> are fixed. I saw some new issues. Take the following text: >> >> >> >> 1 >> >> 2 these >> >> 3 the >> >> 4 their >> >> 5 there >> >> 6 their >> >> 7 the >> >> 8 them >> >> 9 these >> >> >> >> The cursor is in line 1 and I have 'nowrapscan' set. I search for "the" >> >> and >> >> press CTRL-N 7 times and "the" in "these" is highlighted. Now I press >> >> CTRL-L to copy "s" and then erase it. Now if I press CTRL-P, I expect >> >> that the cursor will move to line 8. Instead the cursor moves to line 7. >> >> >> >> Another problem: Place the cursor in line 1. Enter "/thes" and then press >> >> CTRL-N. The "thes" in line 9 is highlighted. Now if you press backspace, >> >> the cursor jumps back to line 3. I expected that the cursor will remain >> >> in line 9. >> > >> > Thanks, will look at these and add some tests. >> > >> >> I think, the CTRL-N and CTRL-P should respect the search direction. >> >> For example, if I search a pattern using "?text", pressing CTRL-N >> >> should search backwards. Currently CTRL-N always searches >> >> forward (irrespective of the search direction). Note that this is >> >> different from how "n" and "N" work. >> > >> > Please don't make me do this. Currently the inconsistent search >> > direction is one of my biggest annoyances of Vim. I really really really >> > hate it, that I can't rely on the fact that N searches backwards and n >> > forward. >> > >> >> I don't have any preference between the two options. I was just pointing >> out the deviation from the behavior of 'n' and 'N' commands. > > I attach an updated patch, which fixes all issues mentioned so far. > Additionally I added a test for this. > I can confirm that this patch fixes all the issues reported so far. I played around with CTRL-N and CTRL-P at the search prompt for some time and didn't find any issues. Thanks for working on this. Regards, Yegappan > > I will be away the next 2-3 weeks, so won't have time to work on this > further. However, I'd appreciate feedback and will work further on it > after I return, if there are more issues. > > Oh and before I forget to mention it. I made Ctrl-N always go further > down and Ctrl-P always go further up and I don't intend to change that. > -- -- 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.2149
skywind3000 wrote:
> 在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> > Christian Brabandt wrote:
> >
> > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > >
> > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > > Christian Brabandt wrote:
> > > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > > Patch 7.4.2149
> > > > > > > > Problem:If a test leaves a window open a following test may
> > > > > > > > fail.
> > > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > > > > >
> > > > > > > I think, this patch broke the appveyor build:
> > > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > > >
> > > > > > Why would it break only there? The tests pass for me.
> > > > >
> > > > > I don't know. But if you go on history, you can see, that the failure
> > > > > started exactly with this patch (also happened at the win32-installer
> > > > > builds).
> > > > >
> > > > > I pushed the rebuild commit button, perhaps, that was just a
> > > > > temporary
> > > > > flaw?
> > > >
> > > > Something is seriously broken. On windows, I can reproduce the problem.
> > > > When the command :lhelpgrep quickfix has been executed and the location
> > > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > > >
> > > >
> > > > I'll try to debug this later.
> > >
> > > I think, it is opening the locationlist of the wrong window.
> > > However, I don't understand, why it only happens on Windows.
> > >
> > > This patch fixes it for me:
> > > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > > @@ -407,6 +407,7 @@
> > >
> > > function Test_helpgrep()
> > >call s:test_xhelpgrep('c')
> > > + helpclose
> > >call s:test_xhelpgrep('l')
> > > endfunc
> >
> > Thanks. I do wonder why the behavior differs on Windows...
> >
>
> Seems like somewhere in the heap was destroyed by an invalid memory
> accessing,
> which was caused by some old bugs long long ago both in unix build and
> windows build.
>
> Some un-important variables in the heap had already been modified by accident
> in the previous releases, and they had not been noticed before.
>
> As the code base is growing, heap structure is changing too, these old bugs
> become harmful.
>
> Issues are both in unix and windows, but the heap structures in unix and
> windows are different. It just didn't lead to serious consequences in unix.
>
> If we have enough test, we may also find some strange behaviors caused by
> these bugs.
>
> if so, something really bad
> Just a guess, hope I am wrong.
Running test_quickfix under Valgrind doesn't reveal problems.
--
THEOREM: VI is perfect.
PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are
1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect.
QED
-- Arthur Tateishi
/// 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.2152
Patch 7.4.2152
Problem:No proper translation of messages with a count.
Solution: Use ngettext(). (Sergey Alyoshin)
Files: src/evalfunc.c, src/fold.c, src/os_win32.c, src/screen.c, src/vim.h
*** ../vim-7.4.2151/src/evalfunc.c 2016-08-01 15:40:24.179878441 +0200
--- src/evalfunc.c 2016-08-03 21:49:31.786227537 +0200
***
*** 3448,3453
--- 3448,3454
char_u*r;
int len;
char *txt;
+ long count;
#endif
rettv->v_type = VAR_STRING;
***
*** 3478,3491
s = skipwhite(s + 1);
}
}
! txt = _("+-%s%3ld lines: ");
r = alloc((unsigned)(STRLEN(txt)
+ STRLEN(dashes)/* for %s */
+ 20/* for %3ld */
+ STRLEN(s))); /* concatenated */
if (r != NULL)
{
! sprintf((char *)r, txt, dashes, (long)(foldend - foldstart + 1));
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
--- 3479,3493
s = skipwhite(s + 1);
}
}
! count = (long)(foldend - foldstart + 1);
! txt = ngettext("+-%s%3ld line: ", "+-%s%3ld lines: ", count);
r = alloc((unsigned)(STRLEN(txt)
+ STRLEN(dashes)/* for %s */
+ 20/* for %3ld */
+ STRLEN(s))); /* concatenated */
if (r != NULL)
{
! sprintf((char *)r, txt, dashes, count);
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
***
*** 3505,3511
#ifdef FEAT_FOLDING
linenr_T lnum;
char_u*text;
! char_ubuf[51];
foldinfo_T foldinfo;
int fold_count;
#endif
--- 3507,3513
#ifdef FEAT_FOLDING
linenr_T lnum;
char_u*text;
! char_ubuf[FOLD_TEXT_LEN];
foldinfo_T foldinfo;
int fold_count;
#endif
***
*** 3520,3527
fold_count = foldedCount(curwin, lnum, &foldinfo);
if (fold_count > 0)
{
! text = get_foldtext(curwin, lnum, lnum + fold_count - 1,
! &foldinfo, buf);
if (text == buf)
text = vim_strsave(text);
rettv->vval.v_string = text;
--- 3522,3528
fold_count = foldedCount(curwin, lnum, &foldinfo);
if (fold_count > 0)
{
! text = get_foldtext(curwin, lnum, lnum + fold_count - 1, &foldinfo,
buf);
if (text == buf)
text = vim_strsave(text);
rettv->vval.v_string = text;
*** ../vim-7.4.2151/src/fold.c 2016-07-01 18:16:47.493936250 +0200
--- src/fold.c 2016-08-03 21:49:04.982474748 +0200
***
*** 1853,1860
/* get_foldtext() {{{2 */
/*
* Return the text for a closed fold at line "lnum", with last line "lnume".
! * When 'foldtext' isn't set puts the result in "buf[51]". Otherwise the
! * result is in allocated memory.
*/
char_u *
get_foldtext(
--- 1853,1860
/* get_foldtext() {{{2 */
/*
* Return the text for a closed fold at line "lnum", with last line "lnume".
! * When 'foldtext' isn't set puts the result in "buf[FOLD_TEXT_LEN]".
! * Otherwise the result is in allocated memory.
*/
char_u *
get_foldtext(
***
*** 1960,1967
if (text == NULL)
#endif
{
! sprintf((char *)buf, _("+--%3ld lines folded "),
! (long)(lnume - lnum + 1));
text = buf;
}
return text;
--- 1960,1971
if (text == NULL)
#endif
{
! long count = (long)(lnume - lnum + 1);
!
! vim_snprintf((char *)buf, FOLD_TEXT_LEN,
!ngettext("+--%3ld line folded ",
! "+--%3ld lines folded ", count),
!count);
text = buf;
}
return text;
*** ../vim-7.4.2151/src/os_win32.c 2016-08-03 20:54:53.360238783 +0200
--- src/os_win32.c 2016-08-03 21:54:38.807398375 +0200
***
*** 472,483
--- 472,486
# endif
/* Dummy functions */
static char *null_libintl_gettext(const char *);
+ static char *null_libintl_ngettext(const char *, const char *, unsigned long
n);
static char *null_libintl_textdomain(const char *);
static char *null_libintl_bindtextdomain(const char *, const char *);
static char *null_libintl_bind_textdomain_codeset(const char *, const char *);
static HINSTANCE hLibintlDLL = NULL;
char *(*dyn_libintl_gettext)(const char *) = null_libintl_gettext;
+ char *(*dyn_libintl_ngettext)(const char *, const char *, unsigned long n)
+ = null_libintl_ngettext;
char *(*dyn_libintl_textdomain)(co
Re: [patch] ngettext() support
Sergey Alyoshin wrote: > This patch add ngettext() support to allow localization with plural > form, e.g. in folded line count message. Thanks. I don't think the change to gvimext.cpp is needed, ngettext() isn't used there. In os_win32.c I think we need a few more lines, like with gettext(). I notice the buffer size for the fold text is hard coded and there is no overflow check. I'll fix that. -- ./configure Checking whether build environment is sane ... build environment is grinning and holding a spatula. Guess not. /// 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.2149
在 2016年8月4日星期四 UTC+8上午3:48:10，skywind3000写道：
> 在 2016年8月4日星期四 UTC+8上午3:45:32，skywind3000写道：
> > 在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> > > Christian Brabandt wrote:
> > >
> > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > >
> > > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > > > Christian Brabandt wrote:
> > > > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > > > Patch 7.4.2149
> > > > > > > > > Problem:If a test leaves a window open a following test
> > > > > > > > > may fail.
> > > > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > > > Files: src/testdir/runtest.vim,
> > > > > > > > > src/testdir/test_popup.vim
> > > > > > > >
> > > > > > > > I think, this patch broke the appveyor build:
> > > > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > > > >
> > > > > > > Why would it break only there? The tests pass for me.
> > > > > >
> > > > > > I don't know. But if you go on history, you can see, that the
> > > > > > failure
> > > > > > started exactly with this patch (also happened at the
> > > > > > win32-installer
> > > > > > builds).
> > > > > >
> > > > > > I pushed the rebuild commit button, perhaps, that was just a
> > > > > > temporary
> > > > > > flaw?
> > > > >
> > > > > Something is seriously broken. On windows, I can reproduce the
> > > > > problem.
> > > > > When the command :lhelpgrep quickfix has been executed and the
> > > > > location
> > > > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > > > >
> > > > >
> > > > > I'll try to debug this later.
> > > >
> > > > I think, it is opening the locationlist of the wrong window.
> > > > However, I don't understand, why it only happens on Windows.
> > > >
> > > > This patch fixes it for me:
> > > > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > > > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > > > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > > > @@ -407,6 +407,7 @@
> > > >
> > > > function Test_helpgrep()
> > > >call s:test_xhelpgrep('c')
> > > > + helpclose
> > > >call s:test_xhelpgrep('l')
> > > > endfunc
> > >
> > > Thanks. I do wonder why the behavior differs on Windows...
> > >
> >
> > Seems like somewhere in the heap was destroyed by an invalid memory
> > accessing,
> > which was caused by some old bugs long long ago both in unix build and
> > windows build.
> >
> > Some un-important variables in the heap had already been modified by
> > accident in the previous releases, and they had not been noticed before.
> >
> > As the code base is growing, heap structure is changing too, these old bugs
> > become harmful.
> >
> > Issues are both in unix and windows, but the heap structures in unix and
> > windows are different. It just didn't lead to serious consequences in unix.
> >
> > If we have enough test, we may also find some strange behaviors caused by
> > these bugs.
> >
> > if so, something really bad
> > Just a guess, hope I am wrong.
>
> If we have enough test, we may also find some strange behaviors caused by
> these bugs in unix.
I think we should not modify our test to adapt bugs, maybe it is an opportunity
to find them out.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Wish list for a more powerful search in Vim
On Fr, 29 Jul 2016, Yegappan Lakshmanan wrote: > On Fri, Jul 29, 2016 at 11:03 AM, Christian Brabandt > wrote: > >> On Thu, Jul 28, 2016 at 11:16 PM, Christian Brabandt > >> wrote: > >> > On Do, 28 Jul 2016, Bram Moolenaar wrote: > >> > > >> >> I think it should. Most users will have 'wrapscan' on, since it is the > >> >> default. If someone switches it off he must have a reason for it. > >> > > >> > okay, fixed with the latest version > >> > > >> > >> I tested the latest patch and the confirmed that the problems I reported > >> earlier > >> are fixed. I saw some new issues. Take the following text: > >> > >> 1 > >> 2 these > >> 3 the > >> 4 their > >> 5 there > >> 6 their > >> 7 the > >> 8 them > >> 9 these > >> > >> The cursor is in line 1 and I have 'nowrapscan' set. I search for "the" and > >> press CTRL-N 7 times and "the" in "these" is highlighted. Now I press > >> CTRL-L to copy "s" and then erase it. Now if I press CTRL-P, I expect > >> that the cursor will move to line 8. Instead the cursor moves to line 7. > >> > >> Another problem: Place the cursor in line 1. Enter "/thes" and then press > >> CTRL-N. The "thes" in line 9 is highlighted. Now if you press backspace, > >> the cursor jumps back to line 3. I expected that the cursor will remain > >> in line 9. > > > > Thanks, will look at these and add some tests. > > > >> I think, the CTRL-N and CTRL-P should respect the search direction. > >> For example, if I search a pattern using "?text", pressing CTRL-N > >> should search backwards. Currently CTRL-N always searches > >> forward (irrespective of the search direction). Note that this is > >> different from how "n" and "N" work. > > > > Please don't make me do this. Currently the inconsistent search > > direction is one of my biggest annoyances of Vim. I really really really > > hate it, that I can't rely on the fact that N searches backwards and n > > forward. > > > > I don't have any preference between the two options. I was just pointing > out the deviation from the behavior of 'n' and 'N' commands. I attach an updated patch, which fixes all issues mentioned so far. Additionally I added a test for this. I will be away the next 2-3 weeks, so won't have time to work on this further. However, I'd appreciate feedback and will work further on it after I return, if there are more issues. Oh and before I forget to mention it. I made Ctrl-N always go further down and Ctrl-P always go further up and I don't intend to change that. 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. From f7e06483300fcc632414ad49afb30f4459336d78 Mon Sep 17 00:00:00 2001 From: Christian Brabandt Date: Tue, 26 Jul 2016 11:18:51 +0200 Subject: [PATCH] Make Ctrl-N/P jump to next/previous search match Currently, you cannot move from one match to the next match when doing a search '/' or '?'. This patch adds the functionality to use 'Ctrl-N' to move the cursor to the next match, if 'insearch' is set. Similarily 'Ctrl-P' will move to the previous match. Also c_CTRL-N and c_CTRL-P are already used to move within in history of search patterns, I have for now made them something different in search mode, when incsearch is set. This is because c_CTRL-L already does something useful in search mode and second, because Ctrl-N and Ctrl-P are already used to select next/previous match in completion mode so it seems logically to also extend their use in search mode. Bugfixes: - works correctly with Ctrl-P after ? search - after clearing the search command line, starts searching back at the original position - works correctly, when using \? in a forward search / and then jumping backwards using Ctrl-P - obey to 'wrapscan' setting - beep, when no further match is found - fix cursor moved when backspacing a character and adding another char - when wrapping around and finishing the search using make sure, cursor is back at the match - add test_search.vim for testing Updated enhanced search patch --- runtime/doc/cmdline.txt | 9 ++ src/ex_getln.c | 163 +--- src/testdir/Make_all.mak| 1 + src/testdir/test_search.vim | 198 4 files changed, 343 insertions(+), 28 deletions(-) create mode 100644 src/testdir/test_search.vim diff --git a/runtime/doc/cmdline.txt b/runtime/doc/cmdline.txt index 8186678..7fe2a34 100644 --- a/runtime/doc/cmdline.txt +++ b/runtime/doc
Re: Patch 7.4.2149
在 2016年8月4日星期四 UTC+8上午3:45:32，skywind3000写道：
> 在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> > Christian Brabandt wrote:
> >
> > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > >
> > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > > Christian Brabandt wrote:
> > > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > > Patch 7.4.2149
> > > > > > > > Problem:If a test leaves a window open a following test may
> > > > > > > > fail.
> > > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > > > > >
> > > > > > > I think, this patch broke the appveyor build:
> > > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > > >
> > > > > > Why would it break only there? The tests pass for me.
> > > > >
> > > > > I don't know. But if you go on history, you can see, that the failure
> > > > > started exactly with this patch (also happened at the win32-installer
> > > > > builds).
> > > > >
> > > > > I pushed the rebuild commit button, perhaps, that was just a
> > > > > temporary
> > > > > flaw?
> > > >
> > > > Something is seriously broken. On windows, I can reproduce the problem.
> > > > When the command :lhelpgrep quickfix has been executed and the location
> > > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > > >
> > > >
> > > > I'll try to debug this later.
> > >
> > > I think, it is opening the locationlist of the wrong window.
> > > However, I don't understand, why it only happens on Windows.
> > >
> > > This patch fixes it for me:
> > > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > > @@ -407,6 +407,7 @@
> > >
> > > function Test_helpgrep()
> > >call s:test_xhelpgrep('c')
> > > + helpclose
> > >call s:test_xhelpgrep('l')
> > > endfunc
> >
> > Thanks. I do wonder why the behavior differs on Windows...
> >
>
> Seems like somewhere in the heap was destroyed by an invalid memory
> accessing,
> which was caused by some old bugs long long ago both in unix build and
> windows build.
>
> Some un-important variables in the heap had already been modified by accident
> in the previous releases, and they had not been noticed before.
>
> As the code base is growing, heap structure is changing too, these old bugs
> become harmful.
>
> Issues are both in unix and windows, but the heap structures in unix and
> windows are different. It just didn't lead to serious consequences in unix.
>
> If we have enough test, we may also find some strange behaviors caused by
> these bugs.
>
> if so, something really bad
> Just a guess, hope I am wrong.
If we have enough test, we may also find some strange behaviors caused by these
bugs in unix.
--
--
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.2149
在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> Christian Brabandt wrote:
>
> > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> >
> > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > Christian Brabandt wrote:
> > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > Patch 7.4.2149
> > > > > > > Problem:If a test leaves a window open a following test may
> > > > > > > fail.
> > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > > > >
> > > > > > I think, this patch broke the appveyor build:
> > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > >
> > > > > Why would it break only there? The tests pass for me.
> > > >
> > > > I don't know. But if you go on history, you can see, that the failure
> > > > started exactly with this patch (also happened at the win32-installer
> > > > builds).
> > > >
> > > > I pushed the rebuild commit button, perhaps, that was just a temporary
> > > > flaw?
> > >
> > > Something is seriously broken. On windows, I can reproduce the problem.
> > > When the command :lhelpgrep quickfix has been executed and the location
> > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > >
> > >
> > > I'll try to debug this later.
> >
> > I think, it is opening the locationlist of the wrong window.
> > However, I don't understand, why it only happens on Windows.
> >
> > This patch fixes it for me:
> > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > @@ -407,6 +407,7 @@
> >
> > function Test_helpgrep()
> >call s:test_xhelpgrep('c')
> > + helpclose
> >call s:test_xhelpgrep('l')
> > endfunc
>
> Thanks. I do wonder why the behavior differs on Windows...
>
Seems like somewhere in the heap was destroyed by an invalid memory accessing,
which was caused by some old bugs long long ago both in unix build and windows
build.
Some un-important variables in the heap had already been modified by accident
in the previous releases, and they had not been noticed before.
As the code base is growing, heap structure is changing too, these old bugs
become harmful.
Issues are both in unix and windows, but the heap structures in unix and
windows are different. It just didn't lead to serious consequences in unix.
If we have enough test, we may also find some strange behaviors caused by these
bugs.
if so, something really bad
Just a guess, hope I am wrong.
--
--
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.2151
Patch 7.4.2151
Problem:Quickfix test fails on MS-Windows.
Solution: Close the help window. (Christian Brabandt)
Files: src/testdir/test_quickfix.vim
*** ../vim-7.4.2150/src/testdir/test_quickfix.vim 2016-07-20
21:44:33.370131700 +0200
--- src/testdir/test_quickfix.vim 2016-08-03 21:03:10.247735636 +0200
***
*** 407,412
--- 407,413
function Test_helpgrep()
call s:test_xhelpgrep('c')
+ helpclose
call s:test_xhelpgrep('l')
endfunc
*** ../vim-7.4.2150/src/version.c 2016-08-03 20:54:53.360238783 +0200
--- src/version.c 2016-08-03 21:03:26.287589730 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2151,
/**/
--
"I've been teaching myself to play the piano for about 5 years and now write
most of my songs on it, mainly because I can never find any paper."
Jeff Lynne, ELO's greatest hits
/// 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.2149
Christian Brabandt wrote:
> On Mi, 03 Aug 2016, Christian Brabandt wrote:
>
> > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > Christian Brabandt wrote:
> > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > Patch 7.4.2149
> > > > > > Problem:If a test leaves a window open a following test may
> > > > > > fail.
> > > > > > Solution: Always close extra windows after running a test.
> > > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > > >
> > > > > I think, this patch broke the appveyor build:
> > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > >
> > > > Why would it break only there? The tests pass for me.
> > >
> > > I don't know. But if you go on history, you can see, that the failure
> > > started exactly with this patch (also happened at the win32-installer
> > > builds).
> > >
> > > I pushed the rebuild commit button, perhaps, that was just a temporary
> > > flaw?
> >
> > Something is seriously broken. On windows, I can reproduce the problem.
> > When the command :lhelpgrep quickfix has been executed and the location
> > list has been opened, w:quickfix_title is still ':lexpr ""'
> >
> >
> > I'll try to debug this later.
>
> I think, it is opening the locationlist of the wrong window.
> However, I don't understand, why it only happens on Windows.
>
> This patch fixes it for me:
> diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> @@ -407,6 +407,7 @@
>
> function Test_helpgrep()
>call s:test_xhelpgrep('c')
> + helpclose
>call s:test_xhelpgrep('l')
> endfunc
Thanks. I do wonder why the behavior differs on Windows...
--
SECOND SOLDIER: It could be carried by an African swallow!
FIRST SOLDIER: Oh yes! An African swallow maybe ... but not a European
swallow. that's my point.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2145
Ken Takata wrote:
> 2016/8/3 Wed 6:02:45 UTC+9 John Marriott wrote:
> > On 03-Aug-2016 05:55, Bram Moolenaar wrote:
> > > Patch 7.4.2145
> > > Problem:Win32: Using CreateThread/ExitThread is not safe.
> > > Solution: Use _beginthreadex and return from the thread. (Ken Takata)
> > > Files: src/os_win32.c
> > >
> > >
> > This patch generates a warning, like so (on mingw64):
> > gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603
> > -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32
> > -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer
> > -freg-struct-return -s os_win32.c -o gobjnative/os_win32.o
> > os_win32.c: In function 'mch_system_piped':
> > os_win32.c:4497:4: warning: passing argument 3 of '_beginthreadex' from
> > incompatible pointer type [-Wincompatible-pointe
> > r-types]
> > sub_process_writer, /* function to be executed */
> > ^~
> > In file included from os_win32.c:35:0:
> > C:/Programs/MinGW64/x86_64-w64-mingw32/include/process.h:33:29: note:
> > expected 'unsigned int (*)(void *)' but argument i
> > s of type 'DWORD (*)(void *) {aka long unsigned int (*)(void *)}'
> > _CRTIMP uintptr_t __cdecl _beginthreadex(void *_Security,unsigned
> > _StackSize,unsigned (__stdcall *_StartAddress) (voi
> > d *),void *_ArgList,unsigned _InitFlag,unsigned *_ThrdAddr);
> > ^~
>
> Oh. Attached patch should fix the problem.
Thanks.
--
There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. The other way
is to make it so complicated that there are no obvious deficiencies.
-C.A.R. Hoare
/// 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.2150
Patch 7.4.2150
Problem:Warning with MinGW 64. (John Marriott)
Solution: Change return type. (Ken Takata)
Files: src/os_win32.c
*** ../vim-7.4.2149/src/os_win32.c 2016-08-02 21:55:14.409138620 +0200
--- src/os_win32.c 2016-08-03 20:52:47.153376911 +0200
***
*** 4212,4218
* process. This way avoid to hang up vim totally if the children
* process take a long time to process the lines.
*/
! static DWORD WINAPI
sub_process_writer(LPVOID param)
{
HANDLEg_hChildStd_IN_Wr = param;
--- 4212,4218
* process. This way avoid to hang up vim totally if the children
* process take a long time to process the lines.
*/
! static unsigned int __stdcall
sub_process_writer(LPVOID param)
{
HANDLEg_hChildStd_IN_Wr = param;
*** ../vim-7.4.2149/src/version.c 2016-08-02 23:04:46.185887154 +0200
--- src/version.c 2016-08-03 20:53:38.860910612 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2150,
/**/
--
Clothes make the man. Naked people have little or no influence on society.
-- Mark Twain (Samuel Clemens) (1835-1910)
/// 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: Toggling local option value also changes global value
Hi Tony! On So, 31 Jul 2016, Tony Mechelynck wrote: > Bug or feature? I see the following in my Huge gvim with GTK2/Gnome > GUI (and as many features as I could get, including +keymap and +xim): > > I have the following in my keymap: > > map:let &l:imi = !&l:imi > sunmap > map! > > I would expect that with this set of mappings, hitting F8 should > toggle the local setting between keymap and no keymap, without > changing the global setting. But this is not the case. At startup, > after loading my editfiles and setting their keymaps where > appropriate, I see &g:imi == 2 (IM active) and &l:imi == 1 (keymap > active). So there exist a global and a local setting for this > (buffer-local) option, and they are distinct. However, as soon as I > hit F8 (in Normal or Insert mode it behaves identically), not only > &l:imi toggles to 0 (neither keymap nor IM) and subsequently back to 1 > (keymap) but &g:imi follows the local value. This is what I expected > for the local setting but not for the global setting. > > Bug or feature? And if it is a feature, how does it work? In > particular, if a feature, how can I circumvent it to toggle only the > local value? > > FWIW, I'm displaying the values with > :setl imi? > :setg imi? > to see what they are after hitting F8, and ":verbose map " and > ":verbose map! " tell me that the mappings are still as the keymap > defined them. That has been discussed before: https://groups.google.com/d/msg/vim_dev/HpwZWJojl3E/4zCBH3qWQ5IJ Best, Christian -- Die Vergangenheit sollten wir als Sprungbrett benutzen, nicht als Sofa. -- -- 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.2149
On Mi, 03 Aug 2016, Christian Brabandt wrote:
> On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > Christian Brabandt wrote:
> > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > Patch 7.4.2149
> > > > > Problem:If a test leaves a window open a following test may fail.
> > > > > Solution: Always close extra windows after running a test.
> > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > >
> > > > I think, this patch broke the appveyor build:
> > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > >
> > > Why would it break only there? The tests pass for me.
> >
> > I don't know. But if you go on history, you can see, that the failure
> > started exactly with this patch (also happened at the win32-installer
> > builds).
> >
> > I pushed the rebuild commit button, perhaps, that was just a temporary
> > flaw?
>
> Something is seriously broken. On windows, I can reproduce the problem.
> When the command :lhelpgrep quickfix has been executed and the location
> list has been opened, w:quickfix_title is still ':lexpr ""'
>
>
> I'll try to debug this later.
I think, it is opening the locationlist of the wrong window.
However, I don't understand, why it only happens on Windows.
This patch fixes it for me:
diff -r ecc1173685b0 src/testdir/test_quickfix.vim
--- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
+++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
@@ -407,6 +407,7 @@
function Test_helpgrep()
call s:test_xhelpgrep('c')
+ helpclose
call s:test_xhelpgrep('l')
endfunc
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: Patch 7.4.2149
On Mi, 03 Aug 2016, Christian Brabandt wrote: > Hi Bram! > > On Mi, 03 Aug 2016, Bram Moolenaar wrote: > > > Christian Brabandt wrote: > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar: > > > > Patch 7.4.2149 > > > > Problem:If a test leaves a window open a following test may fail. > > > > Solution: Always close extra windows after running a test. > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim > > > > > > I think, this patch broke the appveyor build: > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247 > > > > Why would it break only there? The tests pass for me. > > I don't know. But if you go on history, you can see, that the failure > started exactly with this patch (also happened at the win32-installer > builds). > > I pushed the rebuild commit button, perhaps, that was just a temporary > flaw? Something is seriously broken. On windows, I can reproduce the problem. When the command :lhelpgrep quickfix has been executed and the location list has been opened, w:quickfix_title is still ':lexpr ""' I'll try to debug this later. 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: [patch] ngettext() support
Sergey Alyoshin wrote:
> On Wed, Aug 3, 2016 at 3:38 PM, Sergey Alyoshin wrote:
>> On Wed, Aug 3, 2016 at 3:19 PM, Dominique Pellé
>> wrote:
>>> Sergey Alyoshin wrote:
>>>
Hello
This patch add ngettext() support to allow localization with plural
form, e.g. in folded line count message.
>>>
>>> That's the wrong way of fixing this in my opinion:
>>> - It assumes that plural is n != 1. Rules for what's plural or singular
>>> are different in different languages.
>>> In English, plural is for n != 1. In French plural is for n >= 2 for
>>> example.
>>> - It assumes that there are only 2 forms (plurals and singular), but
>>> several languages have more than 2 plural forms (Polish has 3 for
>>> example).
>>>
>>> The right way to fix it would be to use the plural form feature of gettext.
>>
>> Actually it is ngettext() from libintl.
>
> And this null_libintl_ngettext() is just a stub if libintl is not available:
>
> +null_libintl_ngettext(const char *msgid, const char *msgid_plural,
> +unsigned long int n)
> +{
> +if (n == 1)
> +return (char *)msgid;
> +else
> +return (char *)msgid_plur;
> +}
I see. Sorry, I read it too quickly.
I misunderstood that tt was a stub.
Regards
Dominique
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] ngettext() support
On Wed, Aug 3, 2016 at 3:38 PM, Sergey Alyoshin wrote:
> On Wed, Aug 3, 2016 at 3:19 PM, Dominique Pellé
> wrote:
>> Sergey Alyoshin wrote:
>>
>>> Hello
>>>
>>> This patch add ngettext() support to allow localization with plural
>>> form, e.g. in folded line count message.
>>
>> That's the wrong way of fixing this in my opinion:
>> - It assumes that plural is n != 1. Rules for what's plural or singular
>> are different in different languages.
>> In English, plural is for n != 1. In French plural is for n >= 2 for
>> example.
>> - It assumes that there are only 2 forms (plurals and singular), but
>> several languages have more than 2 plural forms (Polish has 3 for example).
>>
>> The right way to fix it would be to use the plural form feature of gettext.
>
> Actually it is ngettext() from libintl.
And this null_libintl_ngettext() is just a stub if libintl is not available:
+null_libintl_ngettext(const char *msgid, const char *msgid_plural,
+unsigned long int n)
+{
+if (n == 1)
+return (char *)msgid;
+else
+return (char *)msgid_plur;
+}
--
--
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] ngettext() support
On Wed, Aug 3, 2016 at 3:19 PM, Dominique Pellé wrote: > Sergey Alyoshin wrote: > >> Hello >> >> This patch add ngettext() support to allow localization with plural >> form, e.g. in folded line count message. > > That's the wrong way of fixing this in my opinion: > - It assumes that plural is n != 1. Rules for what's plural or singular > are different in different languages. > In English, plural is for n != 1. In French plural is for n >= 2 for > example. > - It assumes that there are only 2 forms (plurals and singular), but > several languages have more than 2 plural forms (Polish has 3 for example). > > The right way to fix it would be to use the plural form feature of gettext. Actually it is ngettext() from libintl. -- -- 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] ngettext() support
Sergey Alyoshin wrote: > Hello > > This patch add ngettext() support to allow localization with plural > form, e.g. in folded line count message. That's the wrong way of fixing this in my opinion: - It assumes that plural is n != 1. Rules for what's plural or singular are different in different languages. In English, plural is for n != 1. In French plural is for n >= 2 for example. - It assumes that there are only 2 forms (plurals and singular), but several languages have more than 2 plural forms (Polish has 3 for example). The right way to fix it would be to use the plural form feature of gettext. See: https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html http://stackoverflow.com/questions/12121515/multiple-plural-forms-in-gettext Regards Dominique -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2145
Hi,
2016/8/3 Wed 6:02:45 UTC+9 John Marriott wrote:
> On 03-Aug-2016 05:55, Bram Moolenaar wrote:
> > Patch 7.4.2145
> > Problem:Win32: Using CreateThread/ExitThread is not safe.
> > Solution: Use _beginthreadex and return from the thread. (Ken Takata)
> > Files: src/os_win32.c
> >
> >
> This patch generates a warning, like so (on mingw64):
> gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603
> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32
> -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer
> -freg-struct-return -s os_win32.c -o gobjnative/os_win32.o
> os_win32.c: In function 'mch_system_piped':
> os_win32.c:4497:4: warning: passing argument 3 of '_beginthreadex' from
> incompatible pointer type [-Wincompatible-pointe
> r-types]
> sub_process_writer, /* function to be executed */
> ^~
> In file included from os_win32.c:35:0:
> C:/Programs/MinGW64/x86_64-w64-mingw32/include/process.h:33:29: note:
> expected 'unsigned int (*)(void *)' but argument i
> s of type 'DWORD (*)(void *) {aka long unsigned int (*)(void *)}'
> _CRTIMP uintptr_t __cdecl _beginthreadex(void *_Security,unsigned
> _StackSize,unsigned (__stdcall *_StartAddress) (voi
> d *),void *_ArgList,unsigned _InitFlag,unsigned *_ThrdAddr);
> ^~
Oh. Attached patch should fix the problem.
Regards,
Ken Takata
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent ecc1173685b0544f46c1e7d020f16ae59a80fc56
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -4212,7 +4212,7 @@ mch_system_classic(char *cmd, int option
* process. This way avoid to hang up vim totally if the children
* process take a long time to process the lines.
*/
-static DWORD WINAPI
+static unsigned int __stdcall
sub_process_writer(LPVOID param)
{
HANDLE g_hChildStd_IN_Wr = param;
Re: Patch 7.4.2149
Hi Bram! On Mi, 03 Aug 2016, Bram Moolenaar wrote: > Christian Brabandt wrote: > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar: > > > Patch 7.4.2149 > > > Problem:If a test leaves a window open a following test may fail. > > > Solution: Always close extra windows after running a test. > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim > > > > I think, this patch broke the appveyor build: > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247 > > Why would it break only there? The tests pass for me. I don't know. But if you go on history, you can see, that the failure started exactly with this patch (also happened at the win32-installer builds). I pushed the rebuild commit button, perhaps, that was just a temporary flaw? Best, Christian -- Fische: gehören nicht zu den Zeugetieren, Laich und Laich gesellt sich gern, wenn das Wortspiel nicht grät, soll man den Rogen nicht unbuttmäßig überspannen -- -- 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] ngettext() support
Hello
This patch add ngettext() support to allow localization with plural
form, e.g. in folded line count message.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From 672a2c7562c8e1a31ae776ad2027e402d3a5217c Mon Sep 17 00:00:00 2001
From: Sergey Alyoshin
Date: Wed, 3 Aug 2016 14:55:23 +0300
Subject: [PATCH] Add ngettext() support
---
src/GvimExt/gvimext.cpp | 10 ++
src/evalfunc.c | 3 ++-
src/fold.c | 4 +++-
src/os_win32.c | 2 ++
src/vim.h | 3 +++
5 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/GvimExt/gvimext.cpp b/src/GvimExt/gvimext.cpp
index b682b74..47e4b18 100644
--- a/src/GvimExt/gvimext.cpp
+++ b/src/GvimExt/gvimext.cpp
@@ -258,6 +258,16 @@ null_libintl_gettext(const char *msgid)
}
static char *
+null_libintl_ngettext(const char *msgid, const char *msgid_plural,
+ unsigned long int n)
+{
+if (n == 1)
+ return (char *)msgid;
+else
+ return (char *)msgid_plur;
+}
+
+static char *
null_libintl_bindtextdomain(const char * /* domainname */, const char * /* dirname */)
{
return NULL;
diff --git a/src/evalfunc.c b/src/evalfunc.c
index 68a8b16..f41903c 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -3478,7 +3478,8 @@ f_foldtext(typval_T *argvars UNUSED, typval_T *rettv)
s = skipwhite(s + 1);
}
}
- txt = _("+-%s%3ld lines: ");
+ txt = ngettext("+-%s%3ld line: ", "+-%s%3ld lines: ",
+ (long)(foldend - foldstart + 1));
r = alloc((unsigned)(STRLEN(txt)
+ STRLEN(dashes) /* for %s */
+ 20 /* for %3ld */
diff --git a/src/fold.c b/src/fold.c
index 35ceceb..7ad9b63 100644
--- a/src/fold.c
+++ b/src/fold.c
@@ -1960,7 +1960,9 @@ get_foldtext(
if (text == NULL)
#endif
{
- sprintf((char *)buf, _("+--%3ld lines folded "),
+ sprintf((char *)buf, ngettext("+--%3ld line folded ",
+ "+--%3ld lines folded ",
+ (long)(lnume - lnum + 1)),
(long)(lnume - lnum + 1));
text = buf;
}
diff --git a/src/os_win32.c b/src/os_win32.c
index 7122177..797454a 100644
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -478,6 +478,8 @@ static char *null_libintl_bind_textdomain_codeset(const char *, const char *);
static HINSTANCE hLibintlDLL = NULL;
char *(*dyn_libintl_gettext)(const char *) = null_libintl_gettext;
+char *(*dyn_libintl_ngettext)(const char *, const char *, unsigned long int n)
+ = null_libintl_ngettext;
char *(*dyn_libintl_textdomain)(const char *) = null_libintl_textdomain;
char *(*dyn_libintl_bindtextdomain)(const char *, const char *)
= null_libintl_bindtextdomain;
diff --git a/src/vim.h b/src/vim.h
index 18c3ff8..9d310a6 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -561,6 +561,7 @@ typedef unsigned long u8char_T; /* long should be 32 bits or more */
# endif
/* These are in os_win32.c */
extern char *(*dyn_libintl_gettext)(const char *msgid);
+extern char *(*dyn_libintl_ngettext)(const char *msgid, const char *msgid_plural, unsigned long int n);
extern char *(*dyn_libintl_bindtextdomain)(const char *domainname, const char *dirname);
extern char *(*dyn_libintl_bind_textdomain_codeset)(const char *domainname, const char *codeset);
extern char *(*dyn_libintl_textdomain)(const char *domainname);
@@ -574,6 +575,7 @@ extern char *(*dyn_libintl_textdomain)(const char *domainname);
#ifdef FEAT_GETTEXT
# ifdef DYNAMIC_GETTEXT
# define _(x) (*dyn_libintl_gettext)((char *)(x))
+# define ngettext(x, xs, n) (*dyn_libintl_ngettext)((char *)(x), (char *)(xs), n)
# define N_(x) x
# define bindtextdomain(domain, dir) (*dyn_libintl_bindtextdomain)((domain), (dir))
# define bind_textdomain_codeset(domain, codeset) (*dyn_libintl_bind_textdomain_codeset)((domain), (codeset))
@@ -592,6 +594,7 @@ extern char *(*dyn_libintl_textdomain)(const char *domainname);
# endif
#else
# define _(x) ((char *)(x))
+# define ngettext(x, xs, n) ((n == 1)?(char *)(x):(char *)(xs))
# define N_(x) x
# ifdef bindtextdomain
# undef bindtextdomain
--
2.1.4
Re: Patch 7.4.2149
Christian Brabandt wrote: > Am 2016-08-02 23:05, schrieb Bram Moolenaar: > > Patch 7.4.2149 > > Problem:If a test leaves a window open a following test may fail. > > Solution: Always close extra windows after running a test. > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim > > I think, this patch broke the appveyor build: > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247 Why would it break only there? The tests pass for me. -- ARTHUR: The swallow may fly south with the sun, or the house martin or the plover seek warmer hot lands in winter, yet these are not strangers to our land. SOLDIER: Are you suggesting coconuts migrate? "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2149
Am 2016-08-02 23:05, schrieb Bram Moolenaar: Patch 7.4.2149 Problem:If a test leaves a window open a following test may fail. Solution: Always close extra windows after running a test. Files: src/testdir/runtest.vim, src/testdir/test_popup.vim I think, this patch broke the appveyor build: https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247 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.
