[Vimperator] un[let]

[Виктор]

В ср, 2007-09-19 в 03:37 +1000, Doug Kearns написа:
> G'day Viktor,
> 
> Nice to see you back.
> 
> On 9/18/07, Виктор Кожухаров <vkojouharov at gmail.com> wrote:
> > В вт, 2007-09-18 в 01:59 +0200, Martin Stubenschrott написа:
> > > On Mon, Sep 17, 2007 at 10:36:44PM +0300, Виктор Кожухаров wrote:
> 
> <snip>
> 
> > This eval is "good enough" to implement what is needed for the :let
> > mapleader stuff. So I have no plans to "fix" anything to it, unless some
> > bug appears.
> 
> So "mapleader" is on it's way? Cool. :)
> 
> <snip>
> 
> > I think it's ready. The only thing I'm not quite sure of is the
> > namespace of this eval function. It's clearly not in the range of the
> > true vimscript eval, so it might go there. But I think in general, all
> > vimscript functions should go into their own namespace, like
> > "vimperator.vimscript". That way we can isolate them with the 'with'
> > keyword, so that implementing the whole of vimscript sooner or later
> > will be possible.
> 
> Is that your plan?  It hadn't even occurred to me that that was on the
> pending feature list but I wouldn't complain if a VimScript parser
> turned up.  I'd just always assumed that JS would fill that role.
Oh no. This is one of those things that might turn up 5 minutes after
the world ends (or after the next debian stable is released, whichever
come first), But since this is "needed" (if we want to implement
mapleader the vim way), might as well have a clear foundation for the
very distant future. My idea is to also have JS be the main language,
and if we isolate such useful functions, script writes can use them with
ease (lets say that all JS/vimscript scripts are executed so that the
main namespace is not window, but vimperator.vimscript).
> 
> > However, since this isn't what the vimscript eval will be, it shouldn't
> > go into the vimscript namespace, rather, there should be another eval
> > function in that namespace that calls it (and that can still way after
> > you or I commit this).
> 
> Looks useful to me. Two quick comments:
> - Options have a value property so you don't need to call getter() explicitly
I was looking for something like that, but the only thing I could find
was getter(). So .value would be equivalent to .getter() then?

> - variableReference() should probably be a 'private' helper...at least for now.
unless I'm mistaken here, this would mean that variableReference would
only be accessible from methods of the vimperator object. However, this
is also used for the commands, so I don't see how to make it private.
> 
> > I'll wait for a comment from Doug before committing this.
> 
> No need to wait for me. :)
> 
> Thanks,
> Doug
So I guess I can commit it then, and everyone can look at it.
> _______________________________________________
> Vimperator mailing list
> Vimperator at mozdev.org
> http://www.mozdev.org/mailman/listinfo/vimperator
-- 
Виктор Кожухаров /Viktor Kojouharov/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: =?UTF-8?Q?=D0=A2=D0=BE=D0=B2=D0=B0?= =?UTF-8?Q?_=D0=B5?=
	=?UTF-8?Q?_=D1=86=D0=B8=D1=84=D1=80=D0=BE=D0=B2=D0=BE?=
	=?UTF-8?Q?_=D0=BF=D0=BE=D0=B4=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=B0?=
	=?UTF-8?Q?_=D1=87=D0=B0=D1=81=D1=82?= =?UTF-8?Q?_=D0=BE=D1=82?=
	=?UTF-8?Q?_=D0=BF=D0=B8=D1=81=D0=BC=D0=BE=D1=82=D0=BE?=
Url : http://www.mozdev.org/pipermail/vimperator/attachments/20070918/64bf2df3/attachment.bin