RE: wish: allow a: in the function def
Sorry; it's located here: http://vim.sourceforge.net/scripts/script.php?script_id=353 > -Original Message- > From: Halim, Salman > Sent: Wednesday, April 25, 2007 10:28 AM > To: 'Marc Weber'; vim-dev@vim.org > Subject: RE: wish: allow a: in the function def > > I uploaded GetVar a long long time ago to vim.sf.net > (initially in 2002, updated for Vim 7 in 2006) that basically > is called with the name of a variable and an optional default > value. It checks w:, b:, t:, and finally g: before returning > the specified default value (default default value is -1). > > There is also a VarExists function in there that just returns > true/false (1/0) based on whether it was able to find any of those. > > I use these to override global plugin settings on a > per-buffer basis, among other things. > > Salman.
RE: wish: allow a: in the function def
I uploaded GetVar a long long time ago to vim.sf.net (initially in 2002,
updated for Vim 7 in 2006) that basically is called with the name of a
variable and an optional default value. It checks w:, b:, t:, and
finally g: before returning the specified default value (default default
value is -1).
There is also a VarExists function in there that just returns true/false
(1/0) based on whether it was able to find any of those.
I use these to override global plugin settings on a per-buffer basis,
among other things.
Salman.
> -Original Message-
> From: Marc Weber [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 25, 2007 10:24 AM
> To: vim-dev@vim.org
> Subject: Re: wish: allow a: in the function def
>
> > So maybe one could make vimscript search a variable foo as l:foo,
> > a:foo, (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an
> > undefined variable name error if none exists. Or so.
>
> No. I don't want to go back to VB without using Option
> Explicit ;) Don't let vim find some value somewhere. This
> leads to failures not so easy to spot
>
> But you are right. This might be useful:
> Use buffer setting if it exists, if not use global one..
> But you should be able to emulate this behaviour using the
> function exists:
>
> function GetSetting(name)
> if exists('b:'.a:name)
> exec 'return b:'.a:name
> elseif exists('g:'.a:name)
> exec 'return g:'.a:name
> else
> echoe "Please define setting ".a:name
> endif
> endfunction
>
> perhaps even add a optional parameter for a default value..
>
> I'm using this very often:
>
> function! vl#lib#brief#args#GetOptionalArg( name, default, ...)
> if a:0 == 1
> let idx = a:1
> else
> let idx = 1
> endif
> if type( a:default) != 1
> throw "wrong type: default parameter of
> vl#lib#brief#args#GetOptionalArg must be a string, use string(value)"
> endif
> let script = [ "if a:0 >= ". idx
>\ , " let ".a:name." = a:".idx
>\ , "else"
>\ , " let ".a:name." = ".a:default
>\ , "endif"
>\ ]
> return join( script, "\n")
> endfunction
>
> function GetSetting(name, ...)
> exec vl#lib#brief#args#GetOptionalArg('default',
> string("option not given"))
> if exists('b:'.a:name)
> exec 'return b:'.a:name
> elseif exists('g:'.a:name)
> exec 'return g:'.a:name
> else
> return default
> endif
> endfunction
>
> Then you can use
> let b = GetSetting('my_name','default value') or let b =
> GetSetting('my_name') which will set b to "option not given"
> if neither b:my_name nor g:my_name does exist
>
> HTH Marc
>
Re: wish: allow a: in the function def
> So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> variable name error if none exists. Or so.
No. I don't want to go back to VB without using Option Explicit ;)
Don't let vim find some value somewhere. This leads to failures not so easy to
spot
But you are right. This might be useful:
Use buffer setting if it exists, if not use global one..
But you should be able to emulate this behaviour using the function exists:
function GetSetting(name)
if exists('b:'.a:name)
exec 'return b:'.a:name
elseif exists('g:'.a:name)
exec 'return g:'.a:name
else
echoe "Please define setting ".a:name
endif
endfunction
perhaps even add a optional parameter for a default value..
I'm using this very often:
function! vl#lib#brief#args#GetOptionalArg( name, default, ...)
if a:0 == 1
let idx = a:1
else
let idx = 1
endif
if type( a:default) != 1
throw "wrong type: default parameter of vl#lib#brief#args#GetOptionalArg
must be a string, use string(value)"
endif
let script = [ "if a:0 >= ". idx
\ , " let ".a:name." = a:".idx
\ , "else"
\ , " let ".a:name." = ".a:default
\ , "endif"
\ ]
return join( script, "\n")
endfunction
function GetSetting(name, ...)
exec vl#lib#brief#args#GetOptionalArg('default', string("option not given"))
if exists('b:'.a:name)
exec 'return b:'.a:name
elseif exists('g:'.a:name)
exec 'return g:'.a:name
else
return default
endif
endfunction
Then you can use
let b = GetSetting('my_name','default value')
or
let b = GetSetting('my_name')
which will set b to "option not given" if neither b:my_name nor g:my_name does
exist
HTH Marc
Re: wish: allow a: in the function def
> So that the name is consistent everywhere. Makes it much easier to search. I > would appreciate this addition, too. Example function! Test(param) echo a:param endfunction When you see param and want to know where it is used, all you have to do is pressing * (using set hlsearch or a plugin such as mark.vim) When seeing the line a:param you know where to look as well. using [[ should take you to the place where param was defined. So I can't see why this should make it much easier to search ? (joke: If you see a:param and you do start grepping .vim you've missed a point :)
Re: wish: allow a: in the function def
On Mon, 23 Apr 2007 21:10:20 -0500 Robert Lee <[EMAIL PROTECTED]> wrote: > Nikolai Weibull wrote: > > On 4/23/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: > >> wish: allow a: in the function definition line: > >> function foo(a:line1, a:line2) > >> This is currently not allowed. But it seems logical to allow it. > > > > Why should it be? Extra typing? > > > > Counterwish: implement better semantics for VimScript so that the > > lookup order of variables alleviates the need for explicit > > environments. Yes, this will break backwards compatibility. Tough. > > > > nikolai > > > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe > using SpiderMonkey) so that people don't need to learn a new language > just to change the color scheme or keyboard mappings. Yes, this will > break backwards compatibility. Tough. This sounds like flame bait, and it seems that an unusually high number of very decent folks have taken it. Healthy discussion is all well and good, but I think if you're really interested in implementing extensions to Vim in ECMAScript, you should build an interface like those that already exist for Perl, Python, Ruby, etc. I know that ECMAScript is fairly popular, so finding some help along the way shouldn't be too difficult. If it's a feature you honestly want, go for it. When its working well enough, submit it for consideration to be included into the official Vim release. But for starters, I'd recommend taking a look at src/if_python.c and src/if_ruby.c to see how this has been done with other languages. As for eliminating Vim script, I think choice is a good thing, and Vim script is very well suited to programming the Vim editor. If you can write an interface for ECMAScript, you don't need to worry about Vim script. You can write in the language you like, and those who still favor Vim script can continue to use it. Live and let live. -- Taylor Venable [EMAIL PROTECTED] http://www.metasyntax.net/
Re: wish: allow a: in the function def
On 4/25/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Nikolai Weibull wrote: > Yes, that's the reason for the a: modifier. And yes, why are they > read-only?VimScript isn't a functionaly programming language. > Variables are mutable; arguments should be to. Why? Vim is a good programming language, arguments as such should never be mutable. When a value can be passed back (in languages which allow it), the argument is not the value but the _address_ of the value, and that is, again, not changeable. I'm not suggesting implementing pass-by-reference. nikolai
Re: wish: allow a: in the function def
On Wed, 25 Apr 2007 03:02:39 +0200, Nikolai Weibull wrote: > On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote: > > As long as function arguments are read-only, it is good to have > > the a: modifier. > > > > In fact, why are they read-only, although call is by value? > > Yes, that's the reason for the a: modifier. And yes, why are they > read-only?VimScript isn't a functionaly programming language. > Variables are mutable; arguments should be to. Maybe its to stop people thinking that assigning to an argument will change its value back at the call point? Spencer -- <<< Eagles may soar, but weasels don't get sucked into jet engines >>> 7:38am up 56 days 14:21, 19 users, load average: 0.01, 0.06, 0.04 Registered Linux User #232457 | LFS ID 11703
Re: wish: allow a: in the function def
On Mon, 23 Apr 2007 21:10:20 -0500, Robert Lee wrote: > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe > using SpiderMonkey) so that people don't need to learn a new language > just to change the color scheme or keyboard mappings. Yes, this will > break backwards compatibility. Tough. This is a windup, right? I mean, who uses ECMAScript other than webmonkeys? Certainly not a majority of Vim users - not even a majority of programmers. If I'm going to have to learn a new language to do things in Vim, I'd rather it were a simple domain-specific one like VimScript. Most of VimScript is just Vim commands anyway. Changing a color scheme or keyboard mappings (the examples you gave) can be done - indeed, normally _are_ done - using basic Vim commands. To throw your own argument back at you, why should I have to learn ECMAScript to do something I already know how to do in Vim (note, _not_ VimScript) anyway? And yes, I have tried to learn ECMAScript (back in the days when it was still known as JavaScript) and it certainly didn't feel easy-to-learn to me, whereas with VimScript I had the basics down in less than a day - certainly enough to write scripts and know where to look if I needed to figure something out. Spencer -- <<< Eagles may soar, but weasels don't get sucked into jet engines >>> 7:26am up 56 days 14:08, 19 users, load average: 0.42, 0.15, 0.04 Registered Linux User #232457 | LFS ID 11703
Re: wish: allow a: in the function def
Nikolai Weibull wrote:
On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
Nikolai Weibull schrieb:
> On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
>> Thomas schrieb:
>
>> > So maybe one could make vimscript search a variable foo as l:foo,
>> a:foo,
>> > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an
undefined
>> > variable name error if none exists. Or so.
>
>> Don't like the idea.
>> In Vim script there is no need or possibility to declare variables.
>> Now, if I forget to init a fun-local variable (happens often to me)
>> Vim gives me a helpful error ("undefined variable").
>
> And I have the same problem with a: prefixes for my arguments. Fine,
> keep prefixes for g:, w:, and b:, but a: is just such an incredibly
> nonstandard way of doing things. In almost all languages parameters
> are treated the same as local variables.
>
> nikolai
As long as function arguments are read-only, it is good to have
the a: modifier.
In fact, why are they read-only, although call is by value?
Yes, that's the reason for the a: modifier. And yes, why are they
read-only?VimScript isn't a functionaly programming language.
Variables are mutable; arguments should be to.
Why?
Vim is a good programming language, arguments as such should never be mutable.
When a value can be passed back (in languages which allow it), the argument is
not the value but the _address_ of the value, and that is, again, not changeable.
Although I'm sure there's an implementation reason for this, it must
be possible to fix.
Still, I don't have a patch, so I should probably just shut up now. I
just hoped it could be better to spend some time to remove this
restriction and drop the requirement of a: instead of adding
additional handling for the declaration of parameters.
nikolai
Best regards,
Tony.
--
What this world needs is a good five-dollar plasma weapon.
Re: wish: allow a: in the function def
On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
Nikolai Weibull schrieb:
> On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
>> Thomas schrieb:
>
>> > So maybe one could make vimscript search a variable foo as l:foo,
>> a:foo,
>> > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
>> > variable name error if none exists. Or so.
>
>> Don't like the idea.
>> In Vim script there is no need or possibility to declare variables.
>> Now, if I forget to init a fun-local variable (happens often to me)
>> Vim gives me a helpful error ("undefined variable").
>
> And I have the same problem with a: prefixes for my arguments. Fine,
> keep prefixes for g:, w:, and b:, but a: is just such an incredibly
> nonstandard way of doing things. In almost all languages parameters
> are treated the same as local variables.
>
> nikolai
As long as function arguments are read-only, it is good to have
the a: modifier.
In fact, why are they read-only, although call is by value?
Yes, that's the reason for the a: modifier. And yes, why are they
read-only?VimScript isn't a functionaly programming language.
Variables are mutable; arguments should be to.
Although I'm sure there's an implementation reason for this, it must
be possible to fix.
Still, I don't have a patch, so I should probably just shut up now. I
just hoped it could be better to spend some time to remove this
restriction and drop the requirement of a: instead of adding
additional handling for the declaration of parameters.
nikolai
Re: wish: allow a: in the function def
On 4/24/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: Besides C and descentants, no other language treats function parameters as local variables. What am I missing? * You can assign to parameters in most languages. * You don't prefix parameters in some manner in most languages. * A parameter is shadowed by later declarations of variables with the same name in most languages. I actually like a:,l:,g:,b: etc prefixes. They are useful in practice because in languages like C++, people tend to invent project-specific suffixes and prefixes to distinguish between method vars, local vars, etc. Vim codifies this. I find this convenient. I have never seen anyone having a separate prefix for method variables and local variables. Instance variables, static variables, global variables, sure, for example, "m_", "s_", "g_". "Incredibly nonstandard" ? Since when ALL programming languages obey one and the same standard ? From forth to lisp to vb.net to perl ? Where did you see common standard for all programing languages ? This thing does not exist. There are families of related languages with common features and spirit, yes, but where did you see "standard features" that programming language must obey ? This is ridiculous statement. There is no such thing. Eh, that "incredibly nonstandard" refers to the nonstandard treatment of parameters. nikolai
Re: wish: allow a: in the function def
Nikolai Weibull schrieb:
On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
Thomas schrieb:
> So maybe one could make vimscript search a variable foo as l:foo,
a:foo,
> (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> variable name error if none exists. Or so.
Don't like the idea.
In Vim script there is no need or possibility to declare variables.
Now, if I forget to init a fun-local variable (happens often to me)
Vim gives me a helpful error ("undefined variable").
And I have the same problem with a: prefixes for my arguments. Fine,
keep prefixes for g:, w:, and b:, but a: is just such an incredibly
nonstandard way of doing things. In almost all languages parameters
are treated the same as local variables.
nikolai
As long as function arguments are read-only, it is good to have
the a: modifier.
In fact, why are they read-only, although call is by value?
--
Regards,
Andy
EOM
Re: wish: allow a: in the function def
Robert Lee wrote: [...] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language just to change the color scheme or keyboard mappings. Yes, this will break backwards compatibility. Tough. [...] Don't? WTF EMCAScript? If you want to replace vimscript by something I already know (yes, /I/ am people), use COBOL, BASIC or FORTRAN. Or even ALGOL. At least vimscript uses the same commands as those which I type at the vim command-line. OTOH, some other "people" prefer LISP. But replacing vimscript by Lisp has already been done: it's called Emacs. Or if you want to scrap ex-commands everywhere (even when typed-in by hand, one by one) and use EMC-WTF instead, go ahead, I'm not detaining you. But don't call your new editor Vim. Best regards, Tony. -- Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?
Re: wish: allow a: in the function def
On 4/24/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
> Thomas schrieb:
> > So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> > variable name error if none exists. Or so.
> Don't like the idea.
> In Vim script there is no need or possibility to declare variables.
> Now, if I forget to init a fun-local variable (happens often to me)
> Vim gives me a helpful error ("undefined variable").
And I have the same problem with a: prefixes for my arguments. Fine,
keep prefixes for g:, w:, and b:, but a: is just such an incredibly
nonstandard way of doing things.
In almost all languages parameters are treated the same as local variables.
"almost all languages" ? totally untrue. This is only true for in C
(and descendants).
Besides C and descentants, no other language treats function parameters
as local variables.
I actually like a:,l:,g:,b: etc prefixes. They are useful in practice
because in languages
like C++, people tend to invent project-specific suffixes and prefixes
to distinguish between method vars, local vars, etc.
Vim codifies this. I find this convenient.
"Incredibly nonstandard" ? Since when ALL programming languages
obey one and the same standard ? From forth to lisp to vb.net to perl ?
Where did you see common standard for all programing languages ?
This thing does not exist. There are families of related languages with
common features and spirit, yes, but where did you see "standard features"
that programming language must obey ? This is ridiculous statement.
There is no such thing.
Yakov
Re: wish: allow a: in the function def
On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
Thomas schrieb:
> So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> variable name error if none exists. Or so.
Don't like the idea.
In Vim script there is no need or possibility to declare variables.
Now, if I forget to init a fun-local variable (happens often to me)
Vim gives me a helpful error ("undefined variable").
And I have the same problem with a: prefixes for my arguments. Fine,
keep prefixes for g:, w:, and b:, but a: is just such an incredibly
nonstandard way of doing things. In almost all languages parameters
are treated the same as local variables.
nikolai
Re: wish: allow a: in the function def
Also would it be _recommended_ to ever use a window-local variable
without
the "w:" prefix? ... IMHO not.
Well, it would make it easier for the user to configure scripts. I'm
myself not convinced that it's a good idea to allow this for all
variables, though. But I think it could be useful in some situations
when you want the user to set a variable per buffer/window or use the
global value. I sometimes end up with code like this
if a:0 >= 1
let x = a:1
elseif exists('b:foo')
let x = b:foo
else
let x = g:foo
endif
The idea was to solve this with some magic.
Of course, with the exception of s:, a user-defined function could help
too, which probably is sufficient.
let x = a:0 >= 1 ? a:1 : GetValue('foo', 'bg')
Re: wish: allow a: in the function def
Thomas schrieb:
Yakov Lerner schrieb:
wish: allow a: in the function definition line:
function foo(a:line1, a:line2)
yeah, occasionally I do
:setl isk+=:
to get completion of variable names in vim scripts.
I'd like to have this for function arguments, too.
Counterwish: implement better semantics for VimScript so that the
lookup order of variables alleviates the need for explicit
environments. Yes, this will break backwards compatibility.
I personally like both wishes. I don't think that this has to
necessarily break backwards compatibility as variables can already have
implicit prefixes: eg foo could be l:foo when used in a function or
g:foo when used in global scope.
So maybe one could make vimscript search a variable foo as l:foo, a:foo,
(maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
variable name error if none exists. Or so.
Don't like the idea.
In Vim script there is no need or possibility to declare variables.
Now, if I forget to init a fun-local variable (happens often to me)
Vim gives me a helpful error ("undefined variable").
This wouldn't be the case anymore if Vim could find obscure variables with
the same name I've never heard of (e.g. set by some weird plugin).
Also would it be _recommended_ to ever use a window-local variable without
the "w:" prefix? ... IMHO not.
--
Regards,
Andy
EOM
Re: wish: allow a: in the function def
wish: allow a: in the function definition line: function foo(a:line1, a:line2) Counterwish: implement better semantics for VimScript so that the lookup order of variables alleviates the need for explicit environments. Yes, this will break backwards compatibility. I personally like both wishes. I don't think that this has to necessarily break backwards compatibility as variables can already have implicit prefixes: eg foo could be l:foo when used in a function or g:foo when used in global scope. So maybe one could make vimscript search a variable foo as l:foo, a:foo, (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined variable name error if none exists. Or so.
Re: wish: allow a: in the function def
--- Nikolai Weibull <[EMAIL PROTECTED]> wrote: > On 4/23/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > wish: allow a: in the function definition line: > > function foo(a:line1, a:line2) > > This is currently not allowed. But it seems logical to allow it. > > Why should it be? Extra typing? So that the name is consistent everywhere. Makes it much easier to search. I would appreciate this addition, too. regards, Peter Send instant messages to your online friends http://au.messenger.yahoo.com
Re: wish: allow a: in the function def
Nikolai Weibull wrote: On 4/23/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: wish: allow a: in the function definition line: function foo(a:line1, a:line2) This is currently not allowed. But it seems logical to allow it. Why should it be? Extra typing? Counterwish: implement better semantics for VimScript so that the lookup order of variables alleviates the need for explicit environments. Yes, this will break backwards compatibility. Tough. nikolai Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language just to change the color scheme or keyboard mappings. Yes, this will break backwards compatibility. Tough. While you are at it: Use XPCOM for GVim and include better OS integration (so that we can do things like drag and drop text to and from a Vim window). Also, allow automatic word-wrapping in comments to be specified on a per-comment-type basis, so that, for example, // comments can be set to not wrap while */ /* comments do. Cheers, -Robert
Re: wish: allow a: in the function def
On 4/23/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: wish: allow a: in the function definition line: function foo(a:line1, a:line2) This is currently not allowed. But it seems logical to allow it. Why should it be? Extra typing? Counterwish: implement better semantics for VimScript so that the lookup order of variables alleviates the need for explicit environments. Yes, this will break backwards compatibility. Tough. nikolai
