Re: replace VimScript
Robert Lee wrote: Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. What plugins/functionality are we missing that require better efficiency? Efficiency is definitely important. VimScript is probably in the order of 10^6 times slower (if not more) than C, and yet we have loads and loads of usable plugins. And what about the size of, for example, Tamarin. It's quite a big piece of software. That would certainly incur a memory penalty. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? Microsoft has, though hardly to any real degree of success, always pushed for VBA. Sure it has JScript as well and many languages could be used for application automation of windows applications. There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Wasn't that sort of my argument? Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? I don't see why you have to replace VimScript with ECMAScript to get ECMAScripts do what can be done with the, for example, Ruby bindings. As for following the leader, you are on shaky ground. No, but the following argument certainly is: Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. Yes, Vim took over where vi had stagnated. Linux was created as a free version of a Unix-like operating system. I don't see how that has anything to do with rip out all the internals of Vim and replace them with a spider-monkey-type-thingy. I mean, it's not like Bram had Vi, removed insert mode and replaced it with virtual replace mode and made a better editor. (Yes, straw-man that if you like.) And just because companies like Adobe and software foundations like Mozilla have chosen JavaScript (and most Adobe applications have a COM interface, so their not usually limited to just JavaScript) for their extension languages doesn't mean it makes sense for others. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? Would you like it if I talked condescending to you? The only question that is really relevant here is: why it isn't enough with having an ECMAScript extension instead of having it replace VimScript? The following arguments have been given: 1. Because people wouldn't have to learn another language 2. Because it is standardized 3. Because lots of people are working on efficient implementations Argument 1) fails because not all people know ECMAScript in the first place. Arguably there are many other choices for languages that more people know than ECMAScript. This is completely true. EMCAScript, however, is never going away and is known by a very large number of users (both technical and non-technical). Frankly, one of Vim's greatest barriers-of-entry is the learning curve. I think much of this is due to its use of proprietary scripting formats. I think there is probably a great deal of overlap between Vim users and current EMCAScript (a.k.a. JavaScript) users. For example, I'd imaging that many PHP developers use Vim as their primary editor (such as myself)...and that most of those users use JavaScript on the client. Argument 2) fails because using a standardized language instead of a application-specific language gives us no
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
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: Vim's ole functionality
Am Dienstag, den 24.04.2007, 16:46 +0530 schrieb Nageshwar M: I tried all the options I checked :version and there is this line with OLE support. I tried to run the application from python as said in documentation and its working fine there. But from java with swt library I'm getting the same error. Please give more information: Perhaps it's a java problem? Can you post (some of) your code? Then we could try to reproduce it. Sebastian.
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: replace VimScript
On 4/25/07, Robert Lee [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: The only question that is really relevant here is: why it isn't enough with having an ECMAScript extension instead of having it replace VimScript? The following arguments have been given: 1. Because people wouldn't have to learn another language 2. Because it is standardized 3. Because lots of people are working on efficient implementations Argument 1) fails because not all people know ECMAScript in the first place. Arguably there are many other choices for languages that more people know than ECMAScript. This is completely true. EMCAScript, however, is never going away and is known by a very large number of users (both technical and non-technical). Never is a very bold claim. I'm sure Grace Hopper figured COBOL would be around a lot longer than it was (well, OK, it /is/ still around in legacy systems, but has, in essence, gone away). And how big is the user base for ECMASCript compared to those of Python, Perl, Ruby, PHP, Lua, Haskell, O'Caml, ML, Java, Scheme, Erlang, Lisp? And for the combination of language X and Vim? Frankly, one of Vim's greatest barriers-of-entry is the learning curve. I think much of this is due to its use of proprietary scripting formats. The greatest barrier is the radically different mode of operation. Most editors people come in contact with when beginning to use computers are the Notepad-type editors: you type in what you want and there are certain key combinations that you can strike to execute commands. Vi (and thus Vim) is radically different (although it wasn't the first editor to work this way). Getting used to working with modes and executing commands is what makes Vi(m) difficult for beginners. Having its own scripting language isn't. And in the end, how different is VimScript from other languages. The biggest annoyance I have with it now is that it's not easy enough to do prototype-based object-orientation with it and that parameters must be prefixed with a:. I think there is probably a great deal of overlap between Vim users and current EMCAScript (a.k.a. JavaScript) users. For example, I'd imaging that many PHP developers use Vim as their primary editor (such as myself)...and that most of those users use JavaScript on the client. And how many PHP developers are using Vim? I'd argue that very few people developing with ECMAScript use Vim, considering the not-quite complete/updated syntax definition and the lack of a good indentation definition. I've written my own syntax definition and contemplated writing and indentation definition, but I don't use ECMAScript enough to actually get around to it. Obviously, few people have. Argument 2) fails because using a standardized language instead of a application-specific language gives us no advantages. On can also argue that the application-specific language is standardized in the sense that it is the standard. I disagree. By using a standard language you automatically inherit a great deal of existing frameworks, libraries and scripts...not to mention talent. It seems to me that you're using the word standard here to mean normal or common. I'll assume that were still talking about ECMAScript being a language with a standardization attached to it. The ECMA standard of ECMAScript doesn't standardize any frameworks, libraries or scripts. I'd also state that it is no accident that EMCAScript (JavaScript) is a standard. It is a standard because it is a technically excellent scripting solution. It has vast support for object oriented programming, is extensible (think DOM), is easy to learn, is very mature, and has several available free and open source implementations. /Prototype-based/ object-oriented programming. This can be done with VimScript as well, although JavaScript has slightly better syntax for it. The DOM isn't defined in the ECMAScript standard. It is maintained by W3. Browsers enable access to the DOM in their ECMAScript/JavaScript API. Mature? ECMAScript is rapidly changing. Just check out what they're doing for 1.7. Sure, that doesn't mean that it's not mature, but it certainly doesn't mean that it's in any way done and you won't have to learn new stuff if you use it. I'd add at least two additional arguments: 4) Using an existing (unmodified) implementation takes some of the maintenance burden out of the hands of the Vim developer(s). Its always nice to let someone else to the work. :-) Yes. All you have to do is replace one of the largest parts of the code base. 5) EMCAScript is more mature and technically superior. You may not like the language personally, but certainly you cannot deny that there are advantages in using an object oriented language. ECMAScript is a prototype-based language, just like VimScript. To be fair, I like neither language very much. nikolai
Re: [PATCH] Determining whether a window used :lcd
On 4/24/07, Bob Hiestand [EMAIL PROTECTED] wrote: On 4/23/07, Nikolai Weibull [EMAIL PROTECTED] wrote: The attached patch very simply implements the following from the todo: Wait! I have a comment! Isn't this todo just a subset of 6 Add :cdprev: go back to the previous directory. Need to remember a stack of previous directories. We also need :cdnext. Not at all. This patch merely exposes some information about the current cd/lcd functionality. It does not provide new directory changing stack capability. You misunderstand. Isn't the functionality requested in your todo entry just a subset of the one above? I mean, can't the functionality that your todo entry adds be made available with the addition of a directory stack? nikolai
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
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
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: [PATCH] Determining whether a window used :lcd
On 4/25/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Not at all. This patch merely exposes some information about the current cd/lcd functionality. It does not provide new directory changing stack capability. You misunderstand. Isn't the functionality requested in your todo entry just a subset of the one above? I mean, can't the functionality that your todo entry adds be made available with the addition of a directory stack? No, I understand your question, but I don't see any relationship, at all, between the two items. Adding current directory stacks has nothing to do with allowing introspection of the state of a window variable. The two changes are completely orthogonal. That said, for the purpose of my needs, I would be happy if I could temporarily override the current directory of a window without having to worry whether the directory was local or global. An implementation of either todo would be therefore sufficient for my plugin; I chose to address the more obvious lacking functionality instead of adding entirely new functionality. Thank you, bob
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: [PATCH] Determining whether a window used :lcd
On 4/25/07, Bob Hiestand [EMAIL PROTECTED] wrote: On 4/25/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Not at all. This patch merely exposes some information about the current cd/lcd functionality. It does not provide new directory changing stack capability. You misunderstand. Isn't the functionality requested in your todo entry just a subset of the one above? I mean, can't the functionality that your todo entry adds be made available with the addition of a directory stack? No, I understand your question, but I don't see any relationship, at all, between the two items. Adding current directory stacks has nothing to do with allowing introspection of the state of a window variable. The two changes are completely orthogonal. OK, I guess then I don't understand your todo entry and Yakov's need for it. The todo entry is There is no way to change directory and go back without changing the local and/or global directory. Add a way to find out if the current window uses a local directory. Add cdcmd() that returns :cd or :lcd? I guess I'm just confused about how the first two sentences relate. Ah, the first sentence is simply a statement that really has very little to do with the actual todo entry. I figured that the todo was about having a way of changing directories and being able to go back. Either way, wouldn't it be more useful to alter getcwd() to take an optional argument stating whether we want the local or global cwd? nikolai
Re: Vim's ole functionality
I am sending you the code that I wrote to start a ole window.The
following code tries to start the application in a separate window. (
To run this code as an application we need to have swt library )
import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.ole.win32.OLE;
import org.eclipse.swt.ole.win32.OleAutomation;
import org.eclipse.swt.ole.win32.OleControlSite;
import org.eclipse.swt.ole.win32.*;
import org.eclipse.swt.ole.win32.OleFrame;
import org.eclipse.swt.ole.win32.Variant;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
public class SWTOleFrame {
public static void main(String[] args) {
final Display display = new Display();
Shell shell = new Shell(display);
shell.setSize(600, 400);
shell.setLayout(new FillLayout());
OleControlSite oleControlSite;
OleFrame oleFrame = new OleFrame(shell, SWT.NONE);
oleControlSite = new OleControlSite(oleFrame, SWT.NONE,
Vim.Application);//--Error is coming here
oleControlSite.doVerb(OLE.OLEIVERB_INPLACEACTIVATE);
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
display.dispose();
}
}
This is the error mesg:
Exception in thread main org.eclipse.swt.SWTException: Failed to
create Ole Client. result = -2147221164
at org.eclipse.swt.ole.win32.OLE.error(OLE.java:302)
at
org.eclipse.swt.ole.win32.OleControlSite.init(OleControlSite.java:101)
at SWTOleFrame.main(SWTOleFrame.java:23)
When I replaced the Vim.Application with Shell.Explorer it is
working fine, an IE window is opening.
On 4/25/07, Sebastian Menge [EMAIL PROTECTED] wrote:
Am Dienstag, den 24.04.2007, 16:46 +0530 schrieb Nageshwar M:
I tried all the options I checked :version and there is this line
with OLE support. I tried to run the application from python as said
in documentation and its working fine there. But from java with swt
library I'm getting the same error.
Please give more information: Perhaps it's a java problem? Can you post
(some of) your code? Then we could try to reproduce it.
Sebastian.
Thanks,
Nageshwar M
if_spidermonkey
Hi, all. I have a patch to add SpiderMonkey interface to Vim. This is not well tested and have only few features. But someone is interested in this. (This is not proposal to add SpiderMonkey interface to Vim) http://yukihiro.nakadaira.googlepages.com/if_spidermonkey.diff Usage: (On Windows) 1. Compile SpiderMonkey wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.60.tar.gz tar xzf js-1.60.tar.gz cd js\src nmake -f js.mak CFG=js - Win32 Release 2. Compile Vim with if_spidermonkey svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 cd vim7 patch -p1 if_spidermonkey.diff cd src namke -f Make_mvc.mak USE_MSVCRT=yes GUI=yes SPIDERMONKEY=C:\tmp\js DYNAMIC_SPIDERMONKEY=yes DYNAMIC_SPIDERMONKEY_DLL=js32.dll 3. Type :spidermonkey command :spidermonkey print(hello, JavaScript!) see :help if_spidermonkey.txt -- Yukihiro Nakadaira - [EMAIL PROTECTED]
Re: replace VimScript
Nikolai Weibull wrote:
On 4/24/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
[snip]
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] =
Vim.options['formatoptions'].replace('t',
)
than
:set fo-=t
It's all about domain specific languages. It's said so on the
internet.
More intuitive?
Yes, it would be more intuitive for me in case I did not know VimScript.
(and that's the context of the discussion if I understand correctly).
Of course something like
vim.options.format.auto_wrap_without_comments = false
would be even more intuitive but that's probably not the way
to go anyway (making it so much more verbose just for beginners).
[snip]
--
For robots (please don't mail me there): [EMAIL PROTECTED]
Re: [PATCH] Determining whether a window used :lcd
On 4/25/07, Nikolai Weibull [EMAIL PROTECTED] wrote: OK, I guess then I don't understand your todo entry and Yakov's need for it. I should clarify, it is my need, and I have no idea who added the todo. I found it while trying to discern if the functionality I needed was provided already. The todo entry is There is no way to change directory and go back without changing the local and/or global directory. Add a way to find out if the current window uses a local directory. Add cdcmd() that returns :cd or :lcd? I guess I'm just confused about how the first two sentences relate. Ah, the first sentence is simply a statement that really has very little to do with the actual todo entry. True. Either way, wouldn't it be more useful to alter getcwd() to take an optional argument stating whether we want the local or global cwd? The problem is that my plugin needs to change the current working directory, perform an action, and then restore the previous working directory. I need to know whether to use :lcd or :cd to do that. If I use :cd in a window that had previously used :lcd, then I clobbered the :lcd usage and that window is now stuck to the global directory; additionally, the global directory is changed to whatever the prior value. If I instead use :lcd always, and the window wasn't previously using a local directory, it now is. In either case, I have adversely and unexpectedly altered the environment. The patch as it stands lets me check to see if the current window has a local directory, and therefore which version of the change directory command to use. Thank you, bob
