Don't show dict functions in expression complete candidates in command-line.

48 views
Skip to first unread message

mattn

unread,
Oct 7, 2011, 5:57:37 AM10/7/11
to vim...@googlegroups.com
Hi.

When you type ':echo <tab>', you can see complete candidates like variables, functions, or etc.
But it include dict functions.  For example,

-------
$ cat foo.vim
let s:foo = {}
function! s:foo.bar()
endfunction

$ vim -u foo.vim -N
-------

Type ":echo <tab>", it will be ":echo 1()".
Below is a patch for fixing this problem.

Note that this patch remove dict functions and script functions from complete candidates.
I think completing of script functions is not useful for us like '<SNR>14_XXX'.
Please check and include.

Thanks.

diff -r 409691084d19 src/eval.c
--- a/src/eval.c Tue Oct 04 21:22:44 2011 +0200
+++ b/src/eval.c Fri Oct 07 13:32:44 2011 +0900
@@ -21735,6 +21735,9 @@
     ++hi;
  fp = HI2UF(hi);
 
+ if (fp->uf_flags & FC_DICT || fp->uf_name[0] == K_SPECIAL)
+    return NULL;
+
  if (STRLEN(fp->uf_name) + 4 >= IOSIZE)
     return fp->uf_name; /* prevents overflow */
 

Bram Moolenaar

unread,
Oct 8, 2011, 10:53:08 AM10/8/11
to mattn, vim...@googlegroups.com

Yasuhiro Matsumoto wrote:

> When you type ':echo <tab>', you can see complete candidates like variables,
> functions, or etc.
> But it include dict functions. For example,
>
> -------
> $ cat foo.vim
> let s:foo = {}
> function! s:foo.bar()
> endfunction
>
> $ vim -u foo.vim -N
> -------
>
> Type ":echo <tab>", it will be ":echo 1()".
> Below is a patch for fixing this problem.
>
> Note that this patch remove dict functions and script functions from
> complete candidates.
> I think completing of script functions is not useful for us like
> '<SNR>14_XXX'.
> Please check and include.

Makes sense. I wonder if we should still show the matches when the user
is explicitly looking for such a function.

--
hundred-and-one symptoms of being an internet addict:
46. Your wife makes a new rule: "The computer cannot come to bed."

/// Bram Moolenaar -- Br...@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 ///

mattn

unread,
Oct 8, 2011, 1:29:25 PM10/8/11
to vim...@googlegroups.com, mattn


On Saturday, October 8, 2011 11:53:08 PM UTC+9, Bram Moolenaar wrote:

Makes sense.  I wonder if we should still show the matches when the user
is explicitly looking for such a function.

 
Do you mean that vim have better to show candidate like following? (for example)

:echo <SNR>14_foo

and type <tab>

:echo <SNR>14_foobar

I think no need to show it. 

Christian Brabandt

unread,
Oct 8, 2011, 2:35:21 PM10/8/11
to vim...@googlegroups.com
Hi mattn!

On Sa, 08 Okt 2011, mattn wrote:

> Do you mean that vim have better to show candidate like following? (for
> example)
>
> :echo <SNR>14_foo
>
> and type <tab>
>
> :echo <SNR>14_foobar
>
> I think no need to show it.

Please don't turn that feature off. I use it all the time.

regards,
Christian
--
Die bescheidenen Menschen w�ren die berufenen Politiker, wenn sie
nicht so bescheiden w�ren.
-- Ernst R. Hauschka

Bram Moolenaar

unread,
Oct 9, 2011, 9:43:25 AM10/9/11
to Christian Brabandt, vim...@googlegroups.com

Christian Brabandt wrote:

> On Sa, 08 Okt 2011, mattn wrote:
>
> > Do you mean that vim have better to show candidate like following? (for
> > example)
> >
> > :echo <SNR>14_foo
> >
> > and type <tab>
> >
> > :echo <SNR>14_foobar
> >
> > I think no need to show it.
>
> Please don't turn that feature off. I use it all the time.

How about only showing these when the user has typed "<". I would like
that when typing ":call <Ctrl-D>" you only see alphabetic function
names.

--
hundred-and-one symptoms of being an internet addict:

48. You get a tatoo that says "This body best viewed with Netscape 3.1 or
higher."

Benjamin R. Haskell

unread,
Oct 9, 2011, 12:33:45 PM10/9/11
to vim...@googlegroups.com, Christian Brabandt
On Sun, 9 Oct 2011, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
>> On Sa, 08 Okt 2011, mattn wrote:
>>
>>> Do you mean that vim have better to show candidate like following?
>>> (for example)
>>>
>>> :echo <SNR>14_foo
>>>
>>> and type <tab>
>>>
>>> :echo <SNR>14_foobar
>>>
>>> I think no need to show it.
>>
>> Please don't turn that feature off. I use it all the time.
>
> How about only showing these when the user has typed "<". I would
> like that when typing ":call <Ctrl-D>" you only see alphabetic
> function names.

I also use this occasionally.

It makes sense to hide dictionary functions, because you can't call them
directly:

Doing: :call <Tab><CR>
Completes: :call 1()
Result: E129: Function name required

So, the result of the completion is something that doesn't
work. It doesn't make sense in context.

Script functions, though, can be called. So they're perfectly valid
candidates.

:call <Tab>(until reaching an example SNR function)
:call <SNR>19_LoadIndent()
Result: (it runs the function... i.e. It works fine.)

I vote for leaving them in the list.

--
Best,
Ben

Christian Brabandt

unread,
Oct 10, 2011, 8:30:31 AM10/10/11
to Bram Moolenaar, vim...@googlegroups.com
On Sun, October 9, 2011 3:43 pm, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
>> On Sa, 08 Okt 2011, mattn wrote:
>>
>> > Do you mean that vim have better to show candidate like following?
>> (for
>> > example)
>> >
>> > :echo <SNR>14_foo
>> >
>> > and type <tab>
>> >
>> > :echo <SNR>14_foobar
>> >
>> > I think no need to show it.
>>
>> Please don't turn that feature off. I use it all the time.
>
> How about only showing these when the user has typed "<". I would like
> that when typing ":call <Ctrl-D>" you only see alphabetic function
> names.

That is fine for me. Also the comment from Benjamin is valid (remove only
dictionary functions).

regards,
Christian

mattn

unread,
Oct 10, 2011, 9:43:59 AM10/10/11
to vim...@googlegroups.com, Bram Moolenaar
I hope that <SNR> functions should be following after global functions. Is this a problem of sort?
Currently, <SNR> functions are there before global functions. it's not useful.

However, If I want to find global function leading "z", I may feed that "<SNR> functions are not useful for complete".
We should hear another's comment more.

Thanks.

Ingo Karkat

unread,
Oct 10, 2011, 10:45:26 PM10/10/11
to vim...@googlegroups.com
On 10/10/2011 03:43 PM, mattn wrote:
> I hope that <SNR> functions should be following after global
> functions. Is this a problem of sort?
> Currently, <SNR> functions are there before global functions. it's not
> useful.

It's a good idea to show the <SNR> functions last. "Normal" users don't
use them, and the cryptic names look intimidating.

> However, If I want to find global function leading "z", I may feed that
> "<SNR> functions are not useful for complete".

Wouldn't you then type z<Tab>, to only get functions starting with "z"?
The <SNR> functions wouldn't show up, then.

> We should hear another's comment more.

Here's another vote for keeping them in, at least when the "<SNR>" base
has already been typed (and preferably also at the end of the list of
all functions).

-- regards, ingo

mattn

unread,
Oct 10, 2011, 11:43:11 PM10/10/11
to vim...@googlegroups.com
Thanks for all in this thread.

I still don't assent that vim show <SNR> functions in complete candidates.

And I wonder why they use ":echo <tab>" to get candidate from completion.
I'm thinking who want to know SID are very minorities. And as Ingo Karkat says, <SNR> is the cryptic names look intimidating.
As you know it, SID is not constant value. if you install scripts in your
runtime path, followers in alphabetical get a different SID value with restarted.
AFAIK, who want to know SID are developer. And they should know how to see SID of the script.

1. :scriptnames
 and find your script file.

2. :command Foo
 to find definition of the command which is defined in your script.

3. define function s:SID()
  see :help <SID>

I want to prior normal users.

Benjamin R. Haskell

unread,
Oct 11, 2011, 2:25:40 PM10/11/11
to vim...@googlegroups.com
On Mon, 10 Oct 2011, mattn wrote:

> Thanks for all in this thread.
>
> I still don't assent that vim show <SNR> functions in complete candidates.
>
> And I wonder why they use ":echo <tab>" to get candidate from completion.
> I'm thinking who want to know SID are very minorities. And as Ingo
> Karkat says, <SNR> is the cryptic names look intimidating.
> As you know it, SID is not constant value. if you install scripts in
> your runtime path, followers in alphabetical get a different SID value
> with restarted.
> AFAIK, who want to know SID are developer. And they should know how to
> see SID of the script.

It's often useful to see or use script-local functions from a script
without using scriptnames. Some scripts have many functions they define
as script-local, some of which, especially when developing, you may want
to call. It's easier to Tab-complete them than to look up the number
followed by having to type the full function.

> 1. :scriptnames
>  and find your script file.
>
> 2. :command Foo
>  to find definition of the command which is defined in your script.
>
> 3. define function s:SID()
>   see :help <SID>
>
> I want to prior normal users.

My vote is for <SNR> functions to sort to the end. It keeps them
tab-completable, but also prioritizes for normal users (if there is such
a thing as a "normal" Vim user).

--
Best,
Ben

mattn

unread,
Oct 12, 2011, 2:42:21 AM10/12/11
to vim...@googlegroups.com
Ok.
Bram, If anyone don't object to this changes, please check and include.


diff -r 409691084d19 src/eval.c
--- a/src/eval.c Tue Oct 04 21:22:44 2011 +0200
+++ b/src/eval.c Wed Oct 12 15:41:53 2011 +0900
@@ -21735,6 +21735,9 @@
     ++hi;
  fp = HI2UF(hi);
 
+ if (fp->uf_flags & FC_DICT)
+    return NULL; /* don't show dict functions */
+
  if (STRLEN(fp->uf_name) + 4 >= IOSIZE)
     return fp->uf_name; /* prevents overflow */
 
diff -r 409691084d19 src/ex_getln.c
--- a/src/ex_getln.c Tue Oct 04 21:22:44 2011 +0200
+++ b/src/ex_getln.c Wed Oct 12 15:41:53 2011 +0900
@@ -3286,6 +3286,21 @@
     return check_abbr(c, ccline.cmdbuff, ccline.cmdpos, 0);
 }
 
+    static int
+#ifdef __BORLANDC__
+_RTLENTRYF
+#endif
+sort_func_compare(s1, s2)
+    const void *s1;
+    const void *s2;
+{
+    char_u *p1 = *(char **)s1, *p2 = *(char **)s2;
+    
+    if (*p1 != '<' && *p2 == '<') return -1;
+    if (*p1 == '<' && *p2 != '<') return 1;
+    return STRCMP(p1, p2);
+}
+
 /*
  * Return FAIL if this is not an appropriate context in which to do
  * completion of anything, return OK if it is (even if there are no matches).
@@ -4734,8 +4749,16 @@
     }
 
     /* Sort the results.  Keep menu's in the specified order. */
-    if (xp->xp_context != EXPAND_MENUNAMES && xp->xp_context != EXPAND_MENUS)
- sort_strings(*file, *num_file);
+    if (xp->xp_context != EXPAND_MENUNAMES && xp->xp_context != EXPAND_MENUS) {
+ if (xp->xp_context == EXPAND_EXPRESSION
+ || xp->xp_context == EXPAND_FUNCTIONS
+ || xp->xp_context == EXPAND_USER_FUNC)
+    /* <SNR> functions should be sorted to the end. */
+    qsort((void *)*file, (size_t)*num_file, sizeof(char_u *),
+    sort_func_compare);
+ else
+    sort_strings(*file, *num_file);
+    }
 
 #ifdef FEAT_CMDL_COMPL
     /* Reset the variables used for special highlight names expansion, so that

Bram Moolenaar

unread,
Oct 12, 2011, 6:29:49 AM10/12/11
to Ingo Karkat, vim...@googlegroups.com

Ingo Karkat wrote:

> On 10/10/2011 03:43 PM, mattn wrote:
> > I hope that <SNR> functions should be following after global
> > functions. Is this a problem of sort?
> > Currently, <SNR> functions are there before global functions. it's not
> > useful.
>
> It's a good idea to show the <SNR> functions last. "Normal" users don't
> use them, and the cryptic names look intimidating.

Agreed. Leaving them out would result in the strange behavior that you
have to type a character to get more completions.

> > However, If I want to find global function leading "z", I may feed that
> > "<SNR> functions are not useful for complete".
>
> Wouldn't you then type z<Tab>, to only get functions starting with "z"?
> The <SNR> functions wouldn't show up, then.
>
> > We should hear another's comment more.
>
> Here's another vote for keeping them in, at least when the "<SNR>" base
> has already been typed (and preferably also at the end of the list of
> all functions).
>
> -- regards, ingo

--
Over the years, I've developed my sense of deja vu so acutely that now
I can remember things that *have* happened before ...

Bram Moolenaar

unread,
Oct 12, 2011, 6:29:49 AM10/12/11
to mattn, vim...@googlegroups.com

Yasuhiro Matsumoto wrote:

> Ok.
> Bram, If anyone don't object to this changes, please check and include.
>
> https://gist.github.com/1280464

Thanks! I'll add it in the todo list.

--
hundred-and-one symptoms of being an internet addict:

57. You begin to wonder how on earth your service provider is allowed to call
200 hours per month "unlimited."

mattn

unread,
Oct 13, 2011, 10:26:29 PM10/13/11
to vim...@googlegroups.com, mattn
MSVC make warning about prototype.


Below is a fixed patch.

diff -r f530aef0d959 src/ex_getln.c
--- a/src/ex_getln.c Wed Oct 12 22:02:14 2011 +0200
+++ b/src/ex_getln.c Fri Oct 14 11:25:08 2011 +0900
@@ -121,6 +121,12 @@
 static int ex_window __ARGS((void));
 #endif
 
+static int
+#ifdef __BORLANDC__
+_RTLENTRYF
+#endif
+sort_func_compare __ARGS((const void *s1, const void *s2));
+
 /*
  * getcmdline() - accept a command line starting with firstc.
  *
@@ -3286,6 +3292,21 @@
     return check_abbr(c, ccline.cmdbuff, ccline.cmdpos, 0);
 }
 
+    static int
+#ifdef __BORLANDC__
+_RTLENTRYF
+#endif
+sort_func_compare(s1, s2)
+    const void *s1;
+    const void *s2;
+{
+    char_u *p1 = *(char **)s1, *p2 = *(char **)s2;
+    
+    if (*p1 != '<' && *p2 == '<') return -1;
+    if (*p1 == '<' && *p2 != '<') return 1;
+    return STRCMP(p1, p2);
+}
+
 /*
  * Return FAIL if this is not an appropriate context in which to do
  * completion of anything, return OK if it is (even if there are no matches).
@@ -4734,8 +4755,16 @@
Reply all
Reply to author
Forward
0 new messages