Re: Quickfix List vs Location List

2016-08-08 Fir de Conversatie Kent Sibilev 
On Monday, August 8, 2016 at 12:44:56 PM UTC-4, LCD 47 wrote:

> By default the status line of the quickfix open shows "[Quickfix
> List]" or "[Location List]", followed by the w:quickfix_title variable
> described above.  Some of the plugins that customize status lines choose
> to ignore that information.  I don't think this is something that needs
> to be fixed in Vim.

That's my point. There is no reliable way to distinguish if we are dealing with 
a quickfix or a location window.  Considering that you have to use different 
set of 
commands to handle these windows, this information has to be easily obtainable. 
But
as of right now, it's not the case. w:quickfix_window can be modified, which 
means it 
is not a reliable source.

Also status line uses buf_spname() function that is not exposed via API and as 
Bram
mentioned returns values that are translated.

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: Quickfix List vs Location List

2016-08-08 Fir de Conversatie Kent Sibilev 
On Monday, August 8, 2016 at 4:03:22 AM UTC-4, LCD 47 wrote:

> 
> Wait, isn't the title already supposed to tell you that?
> 

What do you mean by title?

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: Quickfix List vs Location List

2016-08-07 Fir de Conversatie Kent Sibilev 
On Saturday, August 6, 2016 at 1:02:18 PM UTC-4, Bram Moolenaar wrote:
> 
> The problem with this solution is that the names are translated.
> A more direct solution would be better.
> 
> The 'buftype' option is "quickfix" for both quickfix and location list.
> We can't change that without causing problems.
> 
> Perhaps we should add a buftype({expr}) function, that can get the
> buffer type of any buffer, and make a difference between "quickfix" and
> "loclist".

I see. Even though it's quite awkward to add a new function just to accommodate 
this particular case, i'm attaching my attempt to implement 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.
diff --git a/src/evalfunc.c b/src/evalfunc.c
index 8b5ad22..035a68c 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -65,6 +65,7 @@ static void f_buflisted(typval_T *argvars, typval_T *rettv);
 static void f_bufloaded(typval_T *argvars, typval_T *rettv);
 static void f_bufname(typval_T *argvars, typval_T *rettv);
 static void f_bufnr(typval_T *argvars, typval_T *rettv);
+static void f_buftype(typval_T *argvars, typval_T *rettv);
 static void f_bufwinid(typval_T *argvars, typval_T *rettv);
 static void f_bufwinnr(typval_T *argvars, typval_T *rettv);
 static void f_byte2line(typval_T *argvars, typval_T *rettv);
@@ -484,6 +485,7 @@ static struct fst
 {"bufloaded",	1, 1, f_bufloaded},
 {"bufname",		1, 1, f_bufname},
 {"bufnr",		1, 2, f_bufnr},
+{"buftype",		1, 1, f_buftype},
 {"bufwinid",	1, 1, f_bufwinid},
 {"bufwinnr",	1, 1, f_bufwinnr},
 {"byte2line",	1, 1, f_byte2line},
@@ -1592,6 +1594,41 @@ f_bufnr(typval_T *argvars, typval_T *rettv)
 	rettv->vval.v_number = -1;
 }
 
+/*
+ * "buftype(expr)" function
+ */
+static void
+f_buftype(typval_T *argvars, typval_T *rettv)
+{
+buf_T	*buf;
+win_T	*win;
+char_u	*val;
+tabpage_T	*tp;
+
+(void)get_tv_number([0]);	/* issue errmsg if type error */
+++emsg_off;
+buf = get_buf_tv([0], FALSE);
+rettv->v_type = VAR_STRING;
+if (buf != NULL && buf->b_p_bt != NULL)
+{
+	val = buf->b_p_bt;
+#if defined(FEAT_QUICKFIX) && defined(FEAT_WINDOWS)
+	/*
+	 * For location list window, w_llist_ref points to the location list.
+	 * For quickfix window, w_llist_ref is NULL.
+	 */
+	if (bt_quickfix(buf)
+		&& find_win_for_buf(buf, , ) == OK
+		&& win->w_llist_ref != NULL)
+	val = (char_u *)"loclist";
+#endif
+	rettv->vval.v_string = vim_strsave(val);
+}
+else
+	rettv->vval.v_string = NULL;
+--emsg_off;
+}
+
 static void
 buf_win_common(typval_T *argvars, typval_T *rettv, int get_nr)
 {

Quickfix List vs Location List

2016-08-05 Fir de Conversatie Kent Sibilev 
Currently it's hard to distinguish between Quickfix or Location list windows.

Unless I'm mistaken, but when either window is open the only way I could check
which one is open is by using :ls and checking if it reports the name of any
buffer as "[Quickfix List]" or "[Location List]".

I think it would be much easier if function bufname() had a second argument and 
when it's not zero it would return a special buffer name. Please see the patch 
attached.

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.
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index 04edbd3..c87a17a 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -1983,7 +1983,7 @@ browsedir({title}, {initdir})	String	put up a directory requester
 bufexists({expr})		Number	|TRUE| if buffer {expr} exists
 buflisted({expr})		Number	|TRUE| if buffer {expr} is listed
 bufloaded({expr})		Number	|TRUE| if buffer {expr} is loaded
-bufname({expr})			String	Name of the buffer {expr}
+bufname({expr} [, {special}])	String	Name of the buffer {expr}
 bufnr({expr} [, {create}])	Number	Number of the buffer {expr}
 bufwinid({expr})		Number	window ID of buffer {expr}
 bufwinnr({expr})		Number	window number of buffer {expr}
@@ -2647,7 +2647,8 @@ bufloaded({expr})	*bufloaded()*
 		{expr} exists and is loaded (shown in a window or hidden).
 		The {expr} argument is used like with |bufexists()|.
 
-bufname({expr})		*bufname()*
+			*bufname()*
+bufname({expr} [, {special}])
 		The result is the name of a buffer, as it is displayed by the
 		":ls" command.
 		If {expr} is a Number, that buffer number's name is given.
@@ -2669,11 +2670,14 @@ bufname({expr})		*bufname()*
 		number, force it to be a Number by adding zero to it: >
 			:echo bufname("3" + 0)
 <		If the buffer doesn't exist, or doesn't have a name, an empty
-		string is returned. >
+		string is returned.
+		If the {special} argument is present and not zero, a special
+		buffer name is returned instead. >
 	bufname("#")		alternate buffer name
 	bufname(3)		name of buffer 3
 	bufname("%")		name of current buffer
 	bufname("file2")	name of buffer where "file2" matches.
+	bufname("%", 1)		"[Quickfix List]" for the quickfix window.
 <			*buffer_name()*
 		Obsolete name: buffer_name().
 
diff --git a/src/evalfunc.c b/src/evalfunc.c
index 0095661..46773cb 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -475,11 +475,11 @@ static struct fst
 {"browsedir",	2, 2, f_browsedir},
 {"bufexists",	1, 1, f_bufexists},
 {"buffer_exists",	1, 1, f_bufexists},	/* obsolete */
-{"buffer_name",	1, 1, f_bufname},	/* obsolete */
+{"buffer_name",	1, 2, f_bufname},	/* obsolete */
 {"buffer_number",	1, 1, f_bufnr},		/* obsolete */
 {"buflisted",	1, 1, f_buflisted},
 {"bufloaded",	1, 1, f_bufloaded},
-{"bufname",		1, 1, f_bufname},
+{"bufname",		1, 2, f_bufname},
 {"bufnr",		1, 2, f_bufnr},
 {"bufwinid",	1, 1, f_bufwinid},
 {"bufwinnr",	1, 1, f_bufwinnr},
@@ -1543,16 +1543,33 @@ get_buf_tv(typval_T *tv, int curtab_only)
 f_bufname(typval_T *argvars, typval_T *rettv)
 {
 buf_T	*buf;
+int		error = FALSE;
+char_u	*name = NULL;
 
 (void)get_tv_number([0]);	/* issue errmsg if type error */
 ++emsg_off;
 buf = get_buf_tv([0], FALSE);
+--emsg_off;
+
 rettv->v_type = VAR_STRING;
-if (buf != NULL && buf->b_fname != NULL)
+
+/* If the buffer is found and the second argument is not zero return
+ * a special buffer name. */
+if (buf != NULL
+	&& argvars[1].v_type != VAR_UNKNOWN
+	&& get_tv_number_chk([1], ) != 0
+	&& !error)
+{
+	name = buf_spname(buf);
+	if (name != NULL)
+	rettv->vval.v_string = vim_strsave(name);
+	else
+	rettv->vval.v_string = NULL;
+}
+else if (buf != NULL && buf->b_fname != NULL)
 	rettv->vval.v_string = vim_strsave(buf->b_fname);
 else
 	rettv->vval.v_string = NULL;
---emsg_off;
 }
 
 /*

Re: Wish list for a more powerful search in Vim

2016-08-03 Fir de Conversatie Kent Sibilev 
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: Patch 7.4.2118

2016-07-29 Fir de Conversatie Kent Sibilev 
On Friday, July 29, 2016 at 3:01:36 PM UTC-4, Bram Moolenaar wrote:
> Patch 7.4.2118
> Problem:Mac: can't build with tiny features.
> Solution:   Don't define FEAT_CLIPBOARD unconditionally. (Kazunobu Kuriyama)
> Files:  src/vim.h

After this patch the FEAT_CLIPBOARD is not enabled when building with huge 
feature set. The issue is that this condition

 # if defined(FEAT_SMALL) && !defined(FEAT_CLIPBOARD) 
 #  define FEAT_CLIPBOARD 
 # endif 

is evaluated before the following #include

#include "feature.h"

which actually defines FEAT_SMALL.

It looks like that the following patch fixes it:

diff --git a/src/vim.h b/src/vim.h
index b785527..157be28 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -84,6 +84,8 @@
 # define ROOT_UID 0
 #endif

+#include "feature.h" /* #defines for optionals and features */
+
 /*
  * MACOS_CLASSIC compiling for MacOS prior to MacOS X
  * MACOS_X_UNIX  compiling for MacOS X (using os_unix.c)
@@ -180,8 +182,6 @@
 #endif


-#include "feature.h"   /* #defines for optionals and features */
-
 /* +x11 is only enabled when it's both available and wanted. */
 #if defined(HAVE_X11) && defined(WANT_X11)
 # define FEAT_X11


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: Patch 7.4.1976

2016-07-01 Fir de Conversatie Kent Sibilev 
On Friday, July 1, 2016 at 4:39:49 PM UTC-4, Christian Brabandt wrote:
> Hi Kent!
> 
> On Fr, 01 Jul 2016, Kent Sibilev wrote:
> 
> > Hi All,
> > 
> > After this change I've noticed the following discrepancy 
> > 
> > Before patch:
> > 
> > echo :bomp
> > 0
> > 
> > After patch:
> > 
> > echo :bomp
> > -6827100518448365568
> > 
> > It breaks one of my plugins.
> 
> You mean 'bomb' setting?
> What system is this?
> 
> Best,
> Christian
> -- 
> Hallo Wäsche-Vorwärmer!

I'm on OSX. 

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: Patch 7.4.1976

2016-07-01 Fir de Conversatie Kent Sibilev 
Hi All,

After this change I've noticed the following discrepancy 

Before patch:

echo :bomp
0

After patch:

echo :bomp
-6827100518448365568

It breaks one of my plugins.

Regards,
Kent

> Solution:   Add the num64 feature. (Ken Takata)
> Files:  runtime/doc/eval.txt, runtime/doc/various.txt,
>   src/Make_cyg_ming.mak, src/Make_mvc.mak, src/charset.c,
>   src/eval.c, src/ex_cmds.c, src/ex_getln.c, src/feature.h,
>   src/fileio.c, src/fold.c, src/json.c, src/message.c, src/misc1.c,
>   src/misc2.c, src/ops.c, src/option.c, src/proto/charset.pro,
>   src/proto/eval.pro, src/quickfix.c, src/structs.h,
>   src/testdir/test_viml.vim, src/version.c
> 
> 

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

2016-04-21 Fir de Conversatie Kent Sibilev 
On Thursday, April 21, 2016 at 3:11:42 PM UTC-4, Bram Moolenaar wrote:
> Patch 7.4.1770
> Problem:Cannot use true color in the terminal.
> Solution:   Add the 'guicolors' option. (Nikolai Pavlov)
> Files:  runtime/doc/options.txt, runtime/doc/term.txt,
> runtime/doc/various.txt, src/auto/configure, src/config.h.in,
> src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c,
> src/option.c, src/option.h, src/proto/term.pro, src/screen.c,
> src/structs.h, src/syntax.c, src/term.c, src/term.h,
> src/version.c, src/vim.h
> 

That's great, but how do I set it?

:set guicolors?
E519: Option not supported: guicolors?
:echo 
0
:set guicolors
:echo 
0

Also now when running 'make install'  I get the following error at the end:

if test -d /usr/local/share/applications -a -w /usr/local/share/applications; 
then \
   cp ../runtime/vim.desktop \
../runtime/gvim.desktop \
/usr/local/share/applications; \
   if test -z "" -a -x ; then \
   -q /usr/local/share/applications; \
   fi \
fi
/bin/sh: line 0: test: argument expected


Regards,
Kent Sibilev

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

2016-03-20 Fir de Conversatie Kent Sibilev 
On Thursday, March 17, 2016 at 5:07:25 PM UTC-4, Bram Moolenaar wrote:
> Kent Sibilev wrote:
> 
> > On Wednesday, March 16, 2016 at 5:52:38 PM UTC-4, Bram Moolenaar wrote:
> > > Patch 7.4.1582
> > > Problem:Get E923 when using function(dict.func, [], dict). (Kent 
> > > Sibilev)
> > > Storing a function with a dict in a variable drops the dict 
> > > if the
> > > function is script-local.
> > > Solution:   Translate the function name.  Use dict arg if present.
> > > Files:  src/eval.c, src/testdir/test_partial.vim
> > > 
> > > 
> > 
> > This change introduced another bug:
> > 
> > function! s:MyFunc(bang, buffer)
> >   echo a:bang . a:buffer
> > endfunction
> > command! -bang -complete=buffer -nargs=? MyFunc call s:MyFunc('', 
> > '')
> > command! -bang -complete=buffer -nargs=? MyFuncBug call 
> > MyFunc('', '')
> > 
> > 
> > Calling MyFunc command works fine. Calling MyFuncBug command triggers
> > E116 error.
> 
> I cannot reproduce that problem.  Not sure if your situation is
> different or a later patch fixed it.
> 
> -- 

Hm, :version says I'm running 1-1586 and I can consistently reproduce it. 
Strange.

BR,
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: Patch 7.4.1582

2016-03-19 Fir de Conversatie Kent Sibilev 
On Wednesday, March 16, 2016 at 5:52:38 PM UTC-4, Bram Moolenaar wrote:
> Patch 7.4.1582
> Problem:Get E923 when using function(dict.func, [], dict). (Kent Sibilev)
> Storing a function with a dict in a variable drops the dict if the
> function is script-local.
> Solution:   Translate the function name.  Use dict arg if present.
> Files:  src/eval.c, src/testdir/test_partial.vim
> 
> 

This change introduced another bug:

function! s:MyFunc(bang, buffer)
  echo a:bang . a:buffer
endfunction
command! -bang -complete=buffer -nargs=? MyFunc call s:MyFunc('', 
'')
command! -bang -complete=buffer -nargs=? MyFuncBug call MyFunc('', 
'')


Calling MyFunc command works fine. Calling MyFuncBug command triggers E116 
error.

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

2016-03-19 Fir de Conversatie Kent Sibilev 
On Thursday, March 17, 2016 at 6:26:05 PM UTC-4, Kent Sibilev wrote:

> 
> When I execute MyFunc command, it works:
> 
> :MyFunc /tmp
> /tmp
> 
> When I execute MyFuncBug command, it produces an error:
> 
> :MyFuncBug /tmp
> E116: Invalid arguments for function 164_MyFunc

It looks like path 1589 has fixed this problem.

BR,
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: Patch 7.4.1577

2016-03-18 Fir de Conversatie Kent Sibilev 
On Wednesday, March 16, 2016 at 10:43:13 AM UTC-4, Bram Moolenaar wrote:
> Kent Sibilev wrote:
> 
> > On Tuesday, March 15, 2016 at 2:33:55 PM UTC-4, Bram Moolenaar wrote:
> > > Patch 7.4.1577
> > > Problem:Cannot pass "dict.Myfunc" around as a partial.
> > > Solution:   Create a partial when expected.
> > > Files:  src/eval.c, src/testdir/test_partial.vim
> > > 
> > 
> > This change doesn't allow functions like this:
> > 
> > function! s:cache_clear(...) dict
> > 
> > function! rails#cache_clear(...)
> > 
> > to be defined at the same time. Any particular reason for this, cause
> > this change breaks vim-rails plugin.
> 
> The patch should not change anything about what functions you can
> define.
> 
> What is the error?  Can you make a small example that fails?

Here is the small script to reproduce:

function s:cache_clear(...) dict
return self.name
endfunction

function! s:function(name)
return function(substitute(a:name,'^s:',matchstr(expand(''), 
'\d\+_'),''))
endfunction

let s:obj = {'name': 'cache'}

let s:obj['clear'] = s:function('s:cache_clear')

" this works
echo s:obj.clear()

" this fails with E924
echo call(s:obj.clear, [], s:obj)

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

2016-03-18 Fir de Conversatie Kent Sibilev 
On Thursday, March 17, 2016 at 6:22:25 PM UTC-4, Bram Moolenaar wrote:
> Kent Sibilev wrote:
> 
> > > > On Wednesday, March 16, 2016 at 5:52:38 PM UTC-4, Bram Moolenaar wrote:
> > > > > Patch 7.4.1582
> > > > > Problem:Get E923 when using function(dict.func, [], dict). (Kent 
> > > > > Sibilev)
> > > > > Storing a function with a dict in a variable drops the 
> > > > > dict if the
> > > > > function is script-local.
> > > > > Solution:   Translate the function name.  Use dict arg if present.
> > > > > Files:  src/eval.c, src/testdir/test_partial.vim
> > > > > 
> > > > > 
> > > > 
> > > > This change introduced another bug:
> > > > 
> > > > function! s:MyFunc(bang, buffer)
> > > >   echo a:bang . a:buffer
> > > > endfunction
> > > > command! -bang -complete=buffer -nargs=? MyFunc call s:MyFunc('', 
> > > > '')
> > > > command! -bang -complete=buffer -nargs=? MyFuncBug call 
> > > > MyFunc('', '')
> > > > 
> > > > 
> > > > Calling MyFunc command works fine. Calling MyFuncBug command triggers
> > > > E116 error.
> > > 
> > > I cannot reproduce that problem.  Not sure if your situation is
> > > different or a later patch fixed it.
> > > 
> > > -- 
> > 
> > Hm, :version says I'm running 1-1586 and I can consistently reproduce
> > it. Strange.
> 
> What is the command you give then?  Does it matter if you type it or put
> it in the same script as s:MyFunc()?
> 
> -- 

When I execute MyFunc command, it works:

:MyFunc /tmp
/tmp

When I execute MyFuncBug command, it produces an error:

:MyFuncBug /tmp
E116: Invalid arguments for function 164_MyFunc

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

2016-03-15 Fir de Conversatie Kent Sibilev 
On Tuesday, March 15, 2016 at 2:33:55 PM UTC-4, Bram Moolenaar wrote:
> Patch 7.4.1577
> Problem:Cannot pass "dict.Myfunc" around as a partial.
> Solution:   Create a partial when expected.
> Files:  src/eval.c, src/testdir/test_partial.vim
> 

This change doesn't allow functions like this:

function! s:cache_clear(...) dict

function! rails#cache_clear(...)

to be defined at the same time. Any particular reason for this, cause this 
change breaks vim-rails plugin.

Thanks,
Kent Sibilev

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

2015-06-25 Fir de Conversatie Kent Sibilev 
On Thursday, June 25, 2015 at 12:20:57 PM UTC-4, Kent Sibilev wrote:
 This patch crashes vim for me when I'm starting it from tmux:
 
 $ lldb vim
 (lldb) target create vim
 Current executable set to 'vim' (x86_64).
 (lldb) run
 Process 16364 launched: '/usr/local/bin/vim' (x86_64)
 Process 16364 stopped
 * thread #1: tid = 0x4f71ea, 0x000100193d13 vim`may_req_bg_color + 99 at 
 term.c:3429, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
 (code=1, address=0x0)
 frame #0: 0x000100193d13 vim`may_req_bg_color + 99 at term.c:3429
3426  p_ek
3427 #  ifdef UNIX
3428  isatty(1)
 - 3429  isatty(read_cmd_fd)
3430 #  endif
3431  *T_RBG != NUL
3432  !option_was_set((char_u *)bg))
 (lldb)
 
 
 Kent.

This diff fixes the crash, but i'm not sure it is correct way to fix the 
problem:

diff --git a/src/term.c b/src/term.c
index 0d684e0..9dace0b 100644
--- a/src/term.c
+++ b/src/term.c
@@ -3428,7 +3428,7 @@ may_req_bg_color()
 isatty(1)
 isatty(read_cmd_fd)
 #  endif
-*T_RBG != NUL
+T_RBG != NUL  *T_RBG != NUL
 !option_was_set((char_u *)bg))
 {
LOG_TR(Sending BG request);

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

2015-06-25 Fir de Conversatie Kent Sibilev 
This patch crashes vim for me when I'm starting it from tmux:

$ lldb vim
(lldb) target create vim
Current executable set to 'vim' (x86_64).
(lldb) run
Process 16364 launched: '/usr/local/bin/vim' (x86_64)
Process 16364 stopped
* thread #1: tid = 0x4f71ea, 0x000100193d13 vim`may_req_bg_color + 99 at 
term.c:3429, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x0)
frame #0: 0x000100193d13 vim`may_req_bg_color + 99 at term.c:3429
   3426  p_ek
   3427 #  ifdef UNIX
   3428  isatty(1)
- 3429  isatty(read_cmd_fd)
   3430 #  endif
   3431  *T_RBG != NUL
   3432  !option_was_set((char_u *)bg))
(lldb)


Kent.

On Thursday, June 25, 2015 at 11:03:57 AM UTC-4, Bram Moolenaar wrote:
 Patch 7.4.757
 Problem:Cannot detect the background color of a terminal.
 Solution:   Add T_RBG to request the background color if possible. (Lubomir
 Rintel)
 Files:  src/main.c, src/term.c, src/term.h, src/proto/term.pro
 
 
 *** ../vim-7.4.756/src/main.c 2015-04-17 22:08:10.998772925 +0200
 --- src/main.c2015-06-25 17:01:47.917747345 +0200
 ***
 *** 837,844 
   
   starttermcap(); /* start termcap if not done by wait_return() */
   TIME_MSG(start termcap);
 ! #if defined(FEAT_TERMRESPONSE)  defined(FEAT_MBYTE)
   may_req_ambiguous_char_width();
   #endif
   
   #ifdef FEAT_MOUSE
 --- 837,847 
   
   starttermcap(); /* start termcap if not done by wait_return() */
   TIME_MSG(start termcap);
 ! #if defined(FEAT_TERMRESPONSE)
 ! # if defined(FEAT_MBYTE)
   may_req_ambiguous_char_width();
 + # endif
 + may_req_bg_color();
   #endif
   
   #ifdef FEAT_MOUSE
 *** ../vim-7.4.756/src/term.c 2015-03-31 18:30:09.139370916 +0200
 --- src/term.c2015-06-25 16:52:59.359131386 +0200
 ***
 *** 124,129 
 --- 124,134 
   #  define U7_SENT   2   /* did send T_U7, waiting for answer */
   #  define U7_GOT3   /* received T_U7 response */
   static int u7_status = U7_GET;
 + /* Request background color report: */
 + #  define RBG_GET   1   /* send T_RBG when switched to RAW mode */
 + #  define RBG_SENT  2   /* did send T_RBG, waiting for answer */
 + #  define RBG_GOT   3   /* received T_RBG response */
 + static int rbg_status = RBG_GET;
   # endif
   
   /*
 ***
 *** 949,954 
 --- 954,960 
   {(int)KS_CWP,   IF_EB(\033[3;%d;%dt, ESC_STR [3;%d;%dt)},
   #  endif
   {(int)KS_CRV,   IF_EB(\033[c, ESC_STR [c)},
 + {(int)KS_RBG,   IF_EB(\033]11;?\007, ESC_STR ]11;?\007)},
   {(int)KS_U7,IF_EB(\033[6n, ESC_STR [6n)},
   
   {K_UP,  IF_EB(\033O*A, ESC_STR O*A)},
 ***
 *** 1240,1245 
 --- 1246,1252 
   #  endif
   {(int)KS_CRV,   [CRV]},
   {(int)KS_U7,[U7]},
 + {(int)KS_RBG,   [RBG]},
   {K_UP,  [KU]},
   {K_DOWN,[KD]},
   {K_LEFT,[KL]},
 ***
 *** 3224,3230 
* doesn't work in Cooked mode, an external program may get
* them. */
   if (tmode != TMODE_RAW  (crv_status == CRV_SENT
 !  || u7_status == U7_SENT))
   (void)vpeekc_nomap();
   check_for_codes_from_term();
   }
 --- 3231,3238 
* doesn't work in Cooked mode, an external program may get
* them. */
   if (tmode != TMODE_RAW  (crv_status == CRV_SENT
 !  || u7_status == U7_SENT
 !  || rbg_status == RBG_SENT))
   (void)vpeekc_nomap();
   check_for_codes_from_term();
   }
 ***
 *** 3285,3292 
   if (!gui.in_use  !gui.starting)
   # endif
   {
 ! /* May need to discard T_CRV or T_U7 response. */
 ! if (crv_status == CRV_SENT || u7_status == U7_SENT)
   {
   # ifdef UNIX
   /* Give the terminal a chance to respond. */
 --- 3293,3301 
   if (!gui.in_use  !gui.starting)
   # endif
   {
 ! /* May need to discard T_CRV, T_U7 or T_RBG response. */
 ! if (crv_status == CRV_SENT || u7_status == U7_SENT
 !  || rbg_status == RBG_SENT)
   {
   # ifdef UNIX
   /* Give the terminal a chance to respond. */
 ***
 *** 3398,3403 
 --- 3407,3447 
   }
   # endif
   
 + #if defined(FEAT_TERMRESPONSE) || defined(PROTO)
 + /*
 +  * Check how the terminal treats ambiguous character width (UAX #11).
 +  * First, we move the cursor to (1, 0) and print a test ambiguous character
 +  * \u25bd (WHITE DOWN-POINTING TRIANGLE) and query current cursor position.
 +  * If the terminal treats \u25bd as single width, the position is (1, 1),
 +  * or if it is treated as double width, that will be (1, 2).
 +  *

Re: incorrect rendering with 'nolist' setting

2014-07-30 Fir de Conversatie Kent Sibilev 
On Wednesday, July 30, 2014 10:44:37 AM UTC-4, Bram Moolenaar wrote:
 Christian wrote:
 
 
 
   Hi John!
 
   
 
   On Mi, 30 Jul 2014, John Little wrote:
 
   
 
On Wednesday, July 30, 2014 3:12:05 AM UTC+12, Kent Sibilev wrote:
 
 I've found that some C code is incorrectly rendered when I use 
 'nolist' option. 
 

 
Yes, I see it.  7.4.383.  The problem is not seen with 7.4.0, and not 
with -u NONE -N.  I will try later to bisect my .vimrc to find minimal 
settings that show the problem.
 
   
 
   Probably 7.4.353 which changed the way 'list' and 'linebreak' worked 
 
   together. I couldn't however reproduce it. I'll look into it.
 
  
 
  Attached patch fixes it for me and includes a test.
 
  
 
  I am not entirely sure, why I put the test for linebreak in there at 
 
  all, but without it, test_listlbr_utf8 fails, so it should probably 
 
  stay.
 
 
 
 Thanks.  I verified the test fails before including the fix.
 
 


Thanks everyone. The patch 7.4.388 has fixed the problem.

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

incorrect rendering with 'nolist' setting

2014-07-29 Fir de Conversatie Kent Sibilev 
I've found that some C code is incorrectly rendered when I use 'nolist' option. 

In the attached file, lines 6-7 are incorrectly shifted to the right and when I 
press '$' the cursor doesn't move all the way to the end of the text. 

I wonder if it is something related to my environment or can be reproduced by 
others?

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.
void
getgcmask(byte *p, Type *t, byte **mask, uintptr *len)
{
	byte *base;

	*mask = nil;
	*len = 0;

	if(p = data  p  edata) {
	}
}

Re: incorrect rendering with 'nolist' setting

2014-07-29 Fir de Conversatie Kent Sibilev 
On Tuesday, July 29, 2014 11:12:05 AM UTC-4, Kent Sibilev wrote:
 I've found that some C code is incorrectly rendered when I use 'nolist' 
 option. 
 
 In the attached file, lines 6-7 are incorrectly shifted to the right and when 
 I press '$' the cursor doesn't move all the way to the end of the text. 
 
 I wonder if it is something related to my environment or can be reproduced by 
 others?
 
 Kent.

Just a bit of information. This problem is related to 'linebreak' setting. If I 
set nolinebreak, the problem disappears. 

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: Patch 7.4.260

2014-04-23 Fir de Conversatie Kent Sibilev 
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.

Re: Patch to utilize undefined text-objects

2013-11-14 Fir de Conversatie Kent Sibilev 
On Thursday, November 14, 2013 6:24:42 AM UTC-5, Daniel paradigm Thau wrote:
 On Wednesday, November 13, 2013 11:10:39 PM UTC-5, Kent Sibilev wrote:
  Maybe i'm missing something, but you don't need to patch Vim in order to 
  get this functionality. What you need is kana's textobj pluing:
  https://github.com/kana/vim-textobj-user
  along with textobj-between
  https://github.com/thinca/vim-textobj-between
 
 Yes, there are plenty of ways to make custom text-objects without editing 
 Vim.  However, everything you've listed require the end-user list the desired 
 objects ahead of time.  You could loop over the character range in a plugin 
 or vimrc and make them all, or make an operator-mode mapping to a function 
 that calls getchar() then tries to either make it on-the-fly or fall back to 
 existing things, but all of these options get ugly fast.  Adding three lines 
 to normal.c ends up being much quicker and cleaner.

With textobj-between plugin installed you don't need to loop over and make a 
mapping for every possible character. The plugin adds a single text object 
activated by pressing 'f'. So if you want to delete a content between to 
underscores (_) characters, you press dif_. If you want change text between two 
dollar sign characters you press cif$, etc.

Also I don't understand how the aforementioned fallback would work in practice. 
For example, if I edit an html content h1aattbb/h1 and my cursor is on 
one of the dot characters. Is it true that pressing dit would delete only dots 
characters instead of all tag's content?

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

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

Re: Patch to utilize undefined text-objects

2013-11-14 Fir de Conversatie Kent Sibilev 
On Thursday, November 14, 2013 9:59:51 AM UTC-5, Ben Fritz wrote:
 On Wednesday, November 13, 2013 10:10:39 PM UTC-6, Kent Sibilev wrote:
 
  On Wednesday, November 13, 2013 8:14:20 PM UTC-5, Daniel paradigm Thau 
  wrote:
 
   Attached is a patch to add an 'autotextobject' setting which will treat
 
   undefined text-objects like quote text objects, using the provided
 
   character as bounds.  For example, with this setting if a user enters
 
   
 
   di, with the cursor between two commas, the text between the commas
 
   will be removed.  This is very useful for editing lists.  Similarly, if
 
  
 
  Maybe i'm missing something, but you don't need to patch Vim in order to get
 
  this functionality. What you need is kana's textobj pluing:
 
  
 
  https://github.com/kana/vim-textobj-user
 
  
 
  along with textobj-between
 
  
 
  https://github.com/thinca/vim-textobj-between
 
  
 
  Also you can check kana's other projects where he provides many other useful
 
  text objects like:
 
  
 
  https://github.com/kana/vim-textobj-line
 
  https://github.com/kana/vim-textobj-indent
 
  etc.
 
 
 
 While mappings are more customizable, and there is a plugin for this, C
 
 code is faster and works in more situations. Mappings can be removed,
 
 ignored for various commands, problems can occur while chaining them
 
 together, complex mappings can break the undo sequence, etc.
 
 
 
 I don't think the existence of a plugin is a good reason to avoid a
 
 patch in this case. Text objects are one of the most powerful features
 
 of Vim. I support making them more powerful and adding more of them. The
 
 same arguments you make here can be used against adding ANY new text
 
 object, even defined ones.
 
 
 
 Relative line numbering could be done (poorly) with a plugin before the
 
 'relativenumber' option was introduced. I'm very glad that made it into
 
 the C code.
 
 
 
 And Daniel's point about listing desired text-objects ahead of time is
 
 important as well. With the exception of commas, most of the time when
 
 I'd like a patch like this it's for something I didn't even think about
 
 ahead of time and will probably not think of again until the next time I
 
 need it. Stopping to make another mapping or plugin configuration, and
 
 maybe restarting Vim, is NOT an option. I'll just do it by hand.
 
 
 
 I certainly support this patch. I'll be applying it and running with it
 
 a while at least to try it out. I'd love to see a better option, but this
 
 is WAY better than nothing.

I agree that having the native Vim support for a certain functionality is more 
appealing. My point is that the proposed patch is quite limited in nature and 
could potentially break existing plugins. I'd love to have a native support of 
the functionality that is provided by textobj-user where I can define my own 
text objects and avoid the possibility of problems associated with complex 
mappings. Saying that i've been using textobj-user plugin for many years and 
still have to encounter a single problem you mentioned.

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

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

Re: Patch to utilize undefined text-objects

2013-11-14 Fir de Conversatie Kent Sibilev 
On Thursday, November 14, 2013 11:28:45 AM UTC-5, Daniel paradigm Thau wrote:
 On Thursday, November 14, 2013 11:01:56 AM UTC-5, Kent Sibilev wrote:
  On Thursday, November 14, 2013 6:24:42 AM UTC-5, Daniel paradigm Thau 
  wrote:

 Vim tries to use the existing text-objects with a function for each type of 
 object, then if an invalid specifier is provided it falls back to flag = 
 FAIL.  All my patch does is wrap that flag = FAIL at the end in an 
 if-check against the setting I added and, if the setting is set, do a
 
 flag = current_quote(cap-oap, cap-count1, include, cap-nchar);
 
 i.e.: fall back to treating it like quotes are treated if an object is 
 requested that isn't (yet) defined.
 
 
 [skip]
 
 My argument for this patch really boils down to the following:
 
 As Vim acts now, most of the operator[ai]character namespace is 
 completely unused.  Reserving it for future use doesn't benefit anyone nearly 
 as much as having it do something sane/useful.  A trivially small patch can 
 be used to have do something useful in the unused part of that namespace 
 (without touching the used part at all).  A disclaimer - plus the fact it is 
 a default-off setting - can be made (and is, in the patch) so that people do 
 not rely on those keystrokes always acting the same.

I agree with what you are saying. My only complain is that your patch provides 
a single fallback algorithm, in particular relying on current_quote function. 
What I would like is to have a more general solution where I can specify my own 
function to execute based on the pressed character.

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

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

Re: Patch to utilize undefined text-objects

2013-11-13 Fir de Conversatie Kent Sibilev 
On Wednesday, November 13, 2013 8:14:20 PM UTC-5, Daniel paradigm Thau wrote:
 Attached is a patch to add an 'autotextobject' setting which will treat
 undefined text-objects like quote text objects, using the provided
 character as bounds.  For example, with this setting if a user enters
 
 di, with the cursor between two commas, the text between the commas
 will be removed.  This is very useful for editing lists.  Similarly, if

Maybe i'm missing something, but you don't need to patch Vim in order to get 
this functionality. What you need is kana's textobj pluing:

https://github.com/kana/vim-textobj-user

along with textobj-between

https://github.com/thinca/vim-textobj-between

Also you can check kana's other projects where he provides many other useful 
text objects like:

https://github.com/kana/vim-textobj-line
https://github.com/kana/vim-textobj-indent
etc.

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

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

Problem with the latest changes to syntax/css.vim

2013-09-23 Fir de Conversatie Kent Sibilev 
Hi everyone!

The latest revision of syntax/css.vim introduced a subtle problem with the 
following line:

 Required for cssHacks
setlocal iskeyword-=_

I'm not sure if the syntax file that is the correct place to set vim's options 
other than syntax settings. For example, rails.vim plugin allows highlighting 
of xhtml syntax inside of ruby files, by loading syntax/xhtml and 
syntax/css.vim for ruby files. By setting iskeyword setting in the syntax file, 
the word completion is broken for any filetype that happens to be reusing css 
syntax.

I believe that 5354 revision has introduced this change:

hg diff -r5354 runtime/syntax/css.vim

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

Re: :rubydo X fail on Mac OS X 10.7.5

2013-07-08 Fir de Conversatie Kent Sibilev 
On Monday, July 8, 2013 7:25:03 AM UTC-4, Timothee Gauthier wrote:
 Hi,
 
 I compile Vim on OS X with the latest version, but when I do in vim every 
 rubydo command:
 :rubydo puts x
 
 It crash with 
 Vim: Caught deadly signal TRAP
 Vim: Finished.
 

When you install vim, ask it not to strip symbol table:

$ sudo make install STRIP=/usr/bin/true

For some reason ruby 2.0 has problems with that.

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

Re: Adding a PwdChanged hook for autocmds

2011-12-11 Fir de Conversatie Kent Sibilev 
On Sun, Dec 11, 2011 at 8:51 AM, Rich Healey healey.r...@gmail.com wrote:
 I'm not completely sure I understand, (Please forgive my ignorance) the
 caller of vim_chdir should not be obviously aware of the existance of the
 hook surely? The actions take place just before returning.

 Obviously the user adding a hook to PwdChanged that attempts to invoke
 :chdir would problematic, but I'm not sure I understand your meaning. I was
 aware that there was probably a good reason this has not been done before,
 because it seemed like a very useful feature I was surprised not to find
 already there.


I'm not sure how it's possible to reliably implement this feature
given that I can easily chdir with Vim being unaware , for example:

:ruby Dir.chdir '..'


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

Mouse support regression

2011-11-12 Fir de Conversatie Kent Sibilev 
Hello,

There is a problem introduced by the latest mouse patch. I'm using Vim
in iTerm2 terminal which I believe closely emulates xterm on Mac OSX.
I noticed that with the latest patches after executing an external
program, for example :!ls, the mouse support stops working even though
mouse=a is still set. I had to restart Vim in order to get the mouse
support back.

Does anyone else see the same problem?
Thanks.
-- 
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

Re: Fix for crash in eval.c

2009-05-27 Fir de Conversatie Kent Sibilev 

2009/5/22 Bram Moolenaar b...@moolenaar.net:


 Dominique Pelle wrote:

 Nico Weber wrote:

  Hi,
 
  On 03.05.2009, at 00:03, Dominique Pellé wrote:
 
  After applying your patch, there are no such errors anymore.
 
  However, when exiting, I see that those blocks are not being
  freed:
 
  ==16990== 217 bytes in 10 blocks are possibly lost in loss record 36
  of 57
  ==16990==    at 0x402603E: malloc (vg_replace_malloc.c:207)
  ==16990==    by 0x81142FA: lalloc (misc2.c:866)
  ==16990==    by 0x8114216: alloc (misc2.c:765)
  ==16990==    by 0x807AD1D: dictitem_alloc (eval.c:6775)
  ==16990==    by 0x8074FFD: set_var_lval (eval.c:2856)
  ==16990==    by 0x80742F4: ex_let_one (eval.c:2414)
  ==16990==    by 0x807329F: ex_let_vars (eval.c:1869)
  ==16990==    by 0x8073250: ex_let (eval.c:1834)
  ==16990==    by 0x80A6AA3: do_one_cmd (ex_docmd.c:2622)
  ==16990==    by 0x80A4323: do_cmdline (ex_docmd.c:1096)
  ==16990==    by 0x8090328: call_user_func (eval.c:21301)
  ==16990==    by 0x807C4FE: call_func (eval.c:8079)
  ==16990==    by 0x807C142: get_func_tv (eval.c:7925)
  ==16990==    by 0x8075B83: ex_call (eval.c:)
  ==16990==    by 0x80A6AA3: do_one_cmd (ex_docmd.c:2622)
  ==16990==    by 0x80A4323: do_cmdline (ex_docmd.c:1096)
  ==16990==    by 0x812A758: nv_colon (normal.c:5227)
  ==16990==    by 0x8123DA2: normal_cmd (normal.c:1189)
  ==16990==    by 0x80E6D49: main_loop (main.c:1180)
  ==16990==    by 0x80E6896: main (main.c:939)
 
  I built Vim with -DEXITFREE (i.e. uncommented line
  PROFILE_CFLAGS = -DEXITFREE  in src/Makefile)
  so normally all blocks should be freed when exiting.
 
  Thanks for checking.
 
  I've attached an updated version of the patch that fixes some of the
  leaks. The copy()d dicts in the script don't get freed, but I don't
  (yet?) understand why.
 
  Nico


 I tried to fix the leak as well but without success so far.
 It does not seem simple.

 In any cases, it's a real leak, running the following leak.vim
 script for example causes Vim memory usage to grow
 continuously:

 --- 8 --- cut here --- 8 --- cut here --- 8 ---
 set nocp

  foo.vim is the script attached in the original bug submission
  at 
 http://groups.google.com/group/vim_mac/browse_thread/thread/4e0149ff4f84e3d3
 so foo.vim

 let g:count_loops = 0
 while 1
   call foo#Buffer.New()
   q
   let g:count_loops = g:count_loops + 1
 endwhile
 --- 8 --- cut here --- 8 --- cut here --- 8 ---

 I do:

 $ vim -u NONE leak.vim
 :so %

 Then in another xterm, I can see with top that memory usage
 of Vim keeps increasing.

 If I run the leak.vim script with Valgrind...

 valgrind --leak-resolution=high --leak-check=yes \
     --num-callers=30 --track-fds=yes 2 vg.log \
    ./vim -u NONE leak.vim

 Then do:
 - :so %
 - let the script execute for some time
 - press CTRL-C to interrupt the infinite loop
 - Look at how many times loop iterated with
    :echo g:count_loops
   (it prints 2774 for example)
 - then quit vim: qa!

 Then look for leaks in vg.log, and observe that some leaks
 happen exactly 2774 times (same number as number as
 g:loop_count):

 ==22962== 27,740 bytes in 2,774 blocks are possibly lost in loss
 record 113 of 125
 ==22962==    at 0x402603E: malloc (vg_replace_malloc.c:207)
 ==22962==    by 0x81147FD: lalloc (misc2.c:866)
 ==22962==    by 0x8114708: alloc (misc2.c:765)
 ==22962==    by 0x8114C16: vim_strsave (misc2.c:1177)
 ==22962==    by 0x808C427: copy_tv (eval.c:19380)
 ==22962==    by 0x808AE51: get_var_tv (eval.c:18452)
 ==22962==    by 0x80785E7: eval7 (eval.c:5032)
 ==22962==    by 0x8077EA3: eval6 (eval.c:4685)
 ==22962==    by 0x8077A8F: eval5 (eval.c:4501)
 ==22962==    by 0x8076FE0: eval4 (eval.c:4196)
 ==22962==    by 0x8076E38: eval3 (eval.c:4108)
 ==22962==    by 0x8076CC4: eval2 (eval.c:4037)
 ==22962==    by 0x8076AF4: eval1 (eval.c:3962)
 ==22962==    by 0x8079667: get_list_tv (eval.c:5675)
 ==22962==    by 0x807837D: eval7 (eval.c:4943)
 ==22962==    by 0x8077EA3: eval6 (eval.c:4685)
 ==22962==    by 0x8077A8F: eval5 (eval.c:4501)
 ==22962==    by 0x8076FE0: eval4 (eval.c:4196)
 ==22962==    by 0x8076E38: eval3 (eval.c:4108)
 ==22962==    by 0x8076CC4: eval2 (eval.c:4037)
 ==22962==    by 0x8076AF4: eval1 (eval.c:3962)
 ==22962==    by 0x8076A5B: eval0 (eval.c:3919)
 ==22962==    by 0x807326C: ex_let (eval.c:1833)
 ==22962==    by 0x80A6C8B: do_one_cmd (ex_docmd.c:2622)
 ==22962==    by 0x80A450B: do_cmdline (ex_docmd.c:1096)
 ==22962==    by 0x8090507: call_user_func (eval.c:21381)
 ==22962==    by 0x807C6DD: call_func (eval.c:8159)
 ==22962==    by 0x807C321: get_func_tv (eval.c:8005)
 ==22962==    by 0x8075C03: ex_call (eval.c:3341)
 ==22962==    by 0x80A6C8B: do_one_cmd (ex_docmd.c:2622)
 ==22962==
 ==22962==
 ==22962== 33,288 bytes in 5,548 blocks are possibly lost in loss
 record 114 of 125
 ==22962==    at 0x402603E: malloc (vg_replace_malloc.c:207)
 ==22962==    by 0x81147FD: lalloc (misc2.c:866)
 ==22962==    by 0x8114708: alloc (misc2.c:765)
 ==22962==    by