From henri.ducrocq at gmail.com  Fri May  1 04:11:50 2009
From: henri.ducrocq at gmail.com (Henri Ducrocq)
Date: Fri, 1 May 2009 12:11:50 +0100
Subject: [Vimperator] Extremely choppy scrolling with j/k using latest
	git
In-Reply-To: <dd9711230904300138v460300e6v4c68819b3abb9f3d@mail.gmail.com>
References: <EE7DA6EE-8102-4123-BD8F-95A5D8CC3D6D@gmail.com> 
	<20090429213230.GF7948@jg.home> <49F8E7E7.4060602@vimperator.org> 
	<20090430002620.GG7948@jg.home>
	<aaae92100904300132i4712676dj509493292061c6b5@mail.gmail.com> 
	<dd9711230904300138v460300e6v4c68819b3abb9f3d@mail.gmail.com>
Message-ID: <391beaa80905010411n2679a176j9dd062455b65f7b4@mail.gmail.com>

Just did a side by side comparison of last Vimperator release against latest
git version, I can't see any improvement in the completion speed. Using
complete=l and wildoptions=auto.
What am I missing here?

On Thu, Apr 30, 2009 at 9:38 AM, Daniel Bainton <dpb at driftaway.org> wrote:

> 2009/4/30 Martin Stubenschrott <maxauthority at vimperator.org>:
> > On Thu, Apr 30, 2009 at 2:26 AM, Kris Maglione <maglione.k at gmail.com>
> wrote:
> >>> After <tab> it gets into <waiting> state, but it doesn't reset
> >>> the tab index after pressing backspace, so once you get back to
> >>> "face" you get "facebook.com" completed (well, in case you surfed
> >>> to that site).
> >>
> >> Yes, completion is *soo* much faster now.
> >
> > Either I didn't get your joke, or you didn't consider my bug report as a
> real
> > bug but a feature... (which it is not, it's a bug).
> >
> > Anyway, thanks a lot for your *HACK*, I think with that, I'll release
> > 2.1 quite soon.
> > I am just thinking, whether we should merge the localized docs patch
> > before that,
> > or after that.
>
> I'd say after. Needs to have some testing.
>
> --
> Daniel
> _______________________________________________
> Vimperator mailing list
> Vimperator at mozdev.org
> https://www.mozdev.org/mailman/listinfo/vimperator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090501/b5a9c45b/attachment.html>

From henri.ducrocq at gmail.com  Fri May  1 04:44:02 2009
From: henri.ducrocq at gmail.com (Henri Ducrocq)
Date: Fri, 1 May 2009 12:44:02 +0100
Subject: [Vimperator] Firefox personas and Vimperator status line
Message-ID: <391beaa80905010444h5872ad80p8a4745ef4e9e08ba@mail.gmail.com>

Tip: If you are using the new Personas extension, you can have it skin the
Vimperator status line by not setting a background color, e.g.
    :hi StatusLine color: white;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090501/bd267369/attachment.html>

From stubenschrott at vimperator.org  Fri May  1 05:03:09 2009
From: stubenschrott at vimperator.org (Martin Stubenschrott)
Date: Fri, 01 May 2009 14:03:09 +0200
Subject: [Vimperator] Extremely choppy scrolling with j/k using latest
 git
In-Reply-To: <391beaa80905010411n2679a176j9dd062455b65f7b4@mail.gmail.com>
References: <EE7DA6EE-8102-4123-BD8F-95A5D8CC3D6D@gmail.com>
	<20090429213230.GF7948@jg.home> <49F8E7E7.4060602@vimperator.org>
	<20090430002620.GG7948@jg.home>	<aaae92100904300132i4712676dj509493292061c6b5@mail.gmail.com>
	<dd9711230904300138v460300e6v4c68819b3abb9f3d@mail.gmail.com>
	<391beaa80905010411n2679a176j9dd062455b65f7b4@mail.gmail.com>
Message-ID: <49FAE4FD.2080705@vimperator.org>

On 05/01/2009 01:11 PM, Henri Ducrocq wrote:

> Just did a side by side comparison of last Vimperator release against
> latest git version, I can't see any improvement in the completion speed.
> Using complete=l and wildoptions=auto.
> What am I missing here?


Always try to find search queries which you don't use often, and which
you didn't use just before, then both are usually fast enough.

For me with the current version, all 12 (maximum) items are shown within
a second, while it took considerably longer for the old version, and
showed "Waiting..." for some time as the last item.

Even more visible it's with wildoptions=   as it doesn't already cache/search
for items while typing.

Also using :open aaaaaaaaaaaaaaaaa<bs><bs><bs>... etc. is much less choppy
than before (with wop=auto).

From henri.ducrocq at gmail.com  Fri May  1 05:52:35 2009
From: henri.ducrocq at gmail.com (Henri Ducrocq)
Date: Fri, 1 May 2009 13:52:35 +0100
Subject: [Vimperator] Extremely choppy scrolling with j/k using latest
	git
In-Reply-To: <49FAE4FD.2080705@vimperator.org>
References: <EE7DA6EE-8102-4123-BD8F-95A5D8CC3D6D@gmail.com> 
	<20090429213230.GF7948@jg.home> <49F8E7E7.4060602@vimperator.org> 
	<20090430002620.GG7948@jg.home>
	<aaae92100904300132i4712676dj509493292061c6b5@mail.gmail.com> 
	<dd9711230904300138v460300e6v4c68819b3abb9f3d@mail.gmail.com> 
	<391beaa80905010411n2679a176j9dd062455b65f7b4@mail.gmail.com> 
	<49FAE4FD.2080705@vimperator.org>
Message-ID: <391beaa80905010552tb3e013bte0af86efb19ace23@mail.gmail.com>

On Fri, May 1, 2009 at 1:03 PM, Martin Stubenschrott <
stubenschrott at vimperator.org> wrote:

> For me with the current version, all 12 (maximum) items are shown within
> a second, while it took considerably longer for the old version, and
> showed "Waiting..." for some time as the last item.


It never took more than 1 or 1.5 second for me.


> Also using :open aaaaaaaaaaaaaaaaa<bs><bs><bs>... etc. is much less choppy
> than before (with wop=auto).
>

Just tried it, still don't see any difference between the two versions. Both
are only slightly choppy.

I redid these tests after discarding my vimperatorrc file, still the same. I
double-checked the versions. This leaves me very confused.
We'll see what others experience on that one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090501/faa60921/attachment-0001.html>

From vimperator at vanhoecke.org  Fri May  1 10:17:29 2009
From: vimperator at vanhoecke.org (Guido Van Hoecke)
Date: Fri, 01 May 2009 19:17:29 +0200
Subject: [Vimperator] Problems with using gvim as textbox editor
Message-ID: <49FB2EA9.2090000@vanhoecke.org>

Hi,

When I press ctrl-i in a textarea, vimperator creates a tmp file in /tmp
(e.g. vimperator-vanhoecke.org.tmp) and launches gvim to edit this file.
The titlebar shows the filename followed by (/tmp) and the (single) tab
also shows the temp filename. However the textarea is blank.

My editor setting in .vimperatorrc is:
set editor=/usr/bin/gvim -f

As my firefox page uses latin1, and gvim uses utf-8, I have also tried
with following setting without success:
set editor=/usr/bin/gvim -c "set encoding=latin1" -f

This has been working before, and I do not know why nor when exactly it
stopped working.

version info
:version
Vimperator 2.0 (created: 2009/03/28 23:48:07) running on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523
Ubuntu/9.04 (jaunty) Firefox/3.0.10

To exclude some general environment error, I've tried the "It's all
text" extension with gvim as editor. And that works fine.

Please advise on the proper steps to debug this annoying problem.

Thanks in advance.

Guido

--
Writing is turning one's worst moments into money.
		-- J.P. Donleavy

http://vanhoecke.org ... and go2 places!


From gary.katsevman at gmail.com  Fri May  1 10:29:10 2009
From: gary.katsevman at gmail.com (Gary Katsevman)
Date: Fri, 1 May 2009 13:29:10 -0400
Subject: [Vimperator] Problems with using gvim as textbox editor
In-Reply-To: <49FB2EA9.2090000@vanhoecke.org>
References: <49FB2EA9.2090000@vanhoecke.org>
Message-ID: <97265dfa0905011029t57581f58i2cbf34dff5404f62@mail.gmail.com>

I am guessing you want to quote the whole thing:
set editor="/usr/bin/gvim -c 'set encoding=latin1' -f"
Or something along those lines.

------------------------
Gary Katsevman
Computer Science Undergraduate
Northeastern University
gkatsev at ccs.neu.edu
gary.katsevman.com



On Fri, May 1, 2009 at 13:17, Guido Van Hoecke <vimperator at vanhoecke.org> wrote:
> Hi,
>
> When I press ctrl-i in a textarea, vimperator creates a tmp file in /tmp
> (e.g. vimperator-vanhoecke.org.tmp) and launches gvim to edit this file.
> The titlebar shows the filename followed by (/tmp) and the (single) tab
> also shows the temp filename. However the textarea is blank.
>
> My editor setting in .vimperatorrc is:
> set editor=/usr/bin/gvim -f
>
> As my firefox page uses latin1, and gvim uses utf-8, I have also tried
> with following setting without success:
> set editor=/usr/bin/gvim -c "set encoding=latin1" -f
>
> This has been working before, and I do not know why nor when exactly it
> stopped working.
>
> version info
> :version
> Vimperator 2.0 (created: 2009/03/28 23:48:07) running on:
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523
> Ubuntu/9.04 (jaunty) Firefox/3.0.10
>
> To exclude some general environment error, I've tried the "It's all
> text" extension with gvim as editor. And that works fine.
>
> Please advise on the proper steps to debug this annoying problem.
>
> Thanks in advance.
>
> Guido
>
> --
> Writing is turning one's worst moments into money.
> ? ? ? ? ? ? ? ?-- J.P. Donleavy
>
> http://vanhoecke.org ... and go2 places!
>
> _______________________________________________
> Vimperator mailing list
> Vimperator at mozdev.org
> https://www.mozdev.org/mailman/listinfo/vimperator
>

From vimperator at vanhoecke.org  Fri May  1 10:52:25 2009
From: vimperator at vanhoecke.org (Guido Van Hoecke)
Date: Fri, 01 May 2009 19:52:25 +0200
Subject: [Vimperator] Problems with using gvim as textbox editor
In-Reply-To: <97265dfa0905011029t57581f58i2cbf34dff5404f62@mail.gmail.com>
References: <49FB2EA9.2090000@vanhoecke.org>
	<97265dfa0905011029t57581f58i2cbf34dff5404f62@mail.gmail.com>
Message-ID: <49FB36D9.9060803@vanhoecke.org>

Gary Katsevman wrote:
> I am guessing you want to quote the whole thing:
> set editor="/usr/bin/gvim -c 'set encoding=latin1' -f"
Thanx, that solved my problem :)

Guido

--
Never reveal your best argument.

http://vanhoecke.org ... and go2 places!


From maglione.k at gmail.com  Fri May  1 10:54:41 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Fri, 1 May 2009 13:54:41 -0400
Subject: [Vimperator] Problems with using gvim as textbox editor
In-Reply-To: <49FB2EA9.2090000@vanhoecke.org>
References: <49FB2EA9.2090000@vanhoecke.org>
Message-ID: <20090501175441.GB7947@jg.home>

On Fri, May 01, 2009 at 07:17:29PM +0200, Guido Van Hoecke wrote:
>As my firefox page uses latin1, and gvim uses utf-8, I have also tried
>with following setting without success:
>set editor=/usr/bin/gvim -c "set encoding=latin1" -f

We should actually add a 'fileencoding' option (defaults to 
$LANG?) and convert between the page's encoding and the system 
encoding. Please file a bug report.

Oh, and you need to quote option values that have spaces.

-- 
Kris Maglione

A language that doesn't have everything is actually easier to program
in than some that do.
	--Dennis M. Ritchie


From maglione.k at gmail.com  Fri May  1 11:49:32 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Fri, 1 May 2009 14:49:32 -0400
Subject: [Vimperator] Problems with using gvim as textbox editor
In-Reply-To: <20090501175441.GB7947@jg.home>
References: <49FB2EA9.2090000@vanhoecke.org> <20090501175441.GB7947@jg.home>
Message-ID: <20090501184932.GC7947@jg.home>

On Fri, May 01, 2009 at 01:54:41PM -0400, Kris Maglione wrote:
> We should actually add a 'fileencoding' option (defaults to $LANG?) and 
> convert between the page's encoding and the system encoding. Please file 
> a bug report.

Actually, it occurs to me that this is irrelevant. We read and 
write files as UTF-8 by default, and Firefox treats all strings 
as Unicode, no matte the page encoding. So, telling Vim to use 
8859-1 should definately not produce any useful result.

-- 
Kris Maglione

I did say something along the lines of "C makes it easy to shoot
yourself in the foot; C++ makes it harder, but when you do, it blows
your whole leg off."
	--Bjarne Stroustrup


From mama.sako at yahoo.com  Mon May  4 16:34:33 2009
From: mama.sako at yahoo.com (Mama Sako)
Date: Mon, 4 May 2009 16:34:33 -0700 (PDT)
Subject: [Vimperator] A suggestion for "hint links"
Message-ID: <983062.74498.qm@web110308.mail.gq1.yahoo.com>

Dear all,

Vimperator is the BEST add-on I have ever found for Firefox. Thank you for that.

I just have a small suggestion:
maybe in the future versions it could be possible after pressing "f" or "F" and entering the number to trigger a "mouse-over-the-link" event rather than open that link automatically (in the same page or new tab), because there are some good Firefox add-ons which use mouse-over-the-link event very nicely. Then I would totally forget about my mouse & feed it to the cats    :)

Thank you,
anonymous



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090504/83d68094/attachment.html>

From stubenschrott at vimperator.org  Tue May  5 00:29:58 2009
From: stubenschrott at vimperator.org (Martin Stubenschrott)
Date: Tue, 05 May 2009 09:29:58 +0200
Subject: [Vimperator] A suggestion for "hint links"
In-Reply-To: <983062.74498.qm@web110308.mail.gq1.yahoo.com>
References: <983062.74498.qm@web110308.mail.gq1.yahoo.com>
Message-ID: <49FFEAF6.5040309@vimperator.org>

On 05/05/2009 01:34 AM, Mama Sako wrote:

> Dear all,
> 
> Vimperator is the BEST add-on I have ever found for Firefox. Thank you
> for that.

Thanks :)

> I just have a small suggestion:
> maybe in the future versions it could be possible after pressing "f" or
> "F" and entering the number to trigger a "mouse-over-the-link" event
> rather than open that link automatically (in the same page or new tab),
> because there are some good Firefox add-ons which use
> mouse-over-the-link event very nicely. Then I would totally forget about
> my mouse & feed it to the cats    :)


You could try to enter hint mode with ;; which will focus the link rather
than following. Maybe that helps for your use case. Otherwise, if somebody
feels like it, he could add a ;m hint mode for mouse over and send me a 
patch.

--
Martin

From andrew at pimlott.net  Tue May  5 11:55:21 2009
From: andrew at pimlott.net (Andrew Pimlott)
Date: Tue, 5 May 2009 11:55:21 -0700
Subject: [Vimperator] with 'focuscontent',
	vimp raises the window on page load
Message-ID: <20090505185520.GI11701@pimlott.net>

When I set the 'focuscontent' option, my vimperator window autoraises
itself when a page finishes loading, even if I've switched to another
window in the meantime.  (Actually, what I usually do is switch to
another screen of my virtual desktop, and vimperator switches me back.)
All the searching I've done on this problem leads to discussion in 2005
about a mozilla.widget.raise-on-setfocus firefox preference that no
longer seems to exist in firefox 3.  I could not find anything in
connection with vimperator.

I thought I would get comment on this before filing a bug.  I'm using
Debian unstable with the latest packaged versions (iceweasel 3.0.9-1,
vimperator 2.0-1), and fvwm.

Andrew

From maglione.k at gmail.com  Tue May  5 12:51:51 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 5 May 2009 15:51:51 -0400
Subject: [Vimperator] with 'focuscontent',
	vimp raises the window on	page load
In-Reply-To: <20090505185520.GI11701@pimlott.net>
References: <20090505185520.GI11701@pimlott.net>
Message-ID: <20090505195151.GA8688@jg.home>

On Tue, May 05, 2009 at 11:55:21AM -0700, Andrew Pimlott wrote:
>When I set the 'focuscontent' option, my vimperator window autoraises
>itself when a page finishes loading, even if I've switched to another
>window in the meantime.  (Actually, what I usually do is switch to
>another screen of my virtual desktop, and vimperator switches me back.)
>All the searching I've done on this problem leads to discussion in 2005
>about a mozilla.widget.raise-on-setfocus firefox preference that no
>longer seems to exist in firefox 3.  I could not find anything in
>connection with vimperator.

There have been recent discussions of this here or in the bug 
tracker. In short, yes, it's annoying, and it's Firefox's fault. 
The best solution, in my opinion, is to switch to a window 
manager that ignores such insanity (it's the main reason I 
stopped using Fluxbox some years ago). At any rate, please file 
a bug at bugzilla.mozilla.org.

-- 
Kris Maglione

When a religion is good, I conceive it will support itself; and when
it does not support itself, and God does not take care to support it
so that its professors are obliged to call for help of the civil
power, 'tis a sign, I apprehend, of its being a bad one.
	--Benjamin Franklin


From andrew at pimlott.net  Tue May  5 13:05:16 2009
From: andrew at pimlott.net (Andrew Pimlott)
Date: Tue, 5 May 2009 13:05:16 -0700
Subject: [Vimperator] with 'focuscontent',
	vimp raises the window on	page load
In-Reply-To: <20090505195151.GA8688@jg.home>
References: <20090505185520.GI11701@pimlott.net>
	<20090505195151.GA8688@jg.home>
Message-ID: <20090505200516.GN11701@pimlott.net>

On Tue, May 05, 2009 at 03:51:51PM -0400, Kris Maglione wrote:
> On Tue, May 05, 2009 at 11:55:21AM -0700, Andrew Pimlott wrote:
> >When I set the 'focuscontent' option, my vimperator window autoraises
> >itself when a page finishes loading, even if I've switched to another
> >window in the meantime.
> 
> There have been recent discussions of this here or in the bug 
> tracker.

Hmm, couldn't find it.

> At any rate, please file a bug at bugzilla.mozilla.org.

How do I describe it?  Do you know what is vimperator doing that
triggers the behavior (when 'focuscontent' is set)?  I don't see that
plain firefox users are complaining.

Andrew

From maglione.k at gmail.com  Tue May  5 13:17:55 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 5 May 2009 16:17:55 -0400
Subject: [Vimperator] with 'focuscontent',
	vimp raises the window on	page load
In-Reply-To: <20090505200516.GN11701@pimlott.net>
References: <20090505185520.GI11701@pimlott.net>
	<20090505195151.GA8688@jg.home>
	<20090505200516.GN11701@pimlott.net>
Message-ID: <20090505201755.GB8688@jg.home>

On Tue, May 05, 2009 at 01:05:16PM -0700, Andrew Pimlott wrote:
>> There have been recent discussions of this here or in the bug 
>> tracker.
>
>Hmm, couldn't find it.

http://vimperator.org/trac/ticket/18

>> At any rate, please file a bug at bugzilla.mozilla.org.
>
>How do I describe it?  Do you know what is vimperator doing that
>triggers the behavior (when 'focuscontent' is set)?  I don't see that
>plain firefox users are complaining.

It calls content.focus() (more or less). The problem is that the 
focus method causes the Firefox window to request the focus as 
well, which causes most window managers to a) focus it, and b) 
raise it. I had this problem long before Vimperator even 
existed.

-- 
Kris Maglione

One of my most productive days was throwing away 1000 lines of code.
	--Ken Thompson


From maglione.k at gmail.com  Tue May  5 14:30:13 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 5 May 2009 17:30:13 -0400
Subject: [Vimperator] Alternative :map command
Message-ID: <20090505213013.GC8688@jg.home>

Hi,

Attached is a plugin for an alternative to the :map command. The 
usage is mostly self-explanitory (I need to add descriptions to 
the option specs, but that requires slight internals changes). 
This will only work with the latest bleeding edge. There are 
some differences to be aware of:

1) The default behavior is that of :noremap. If you want 
    remapping, use the -noremap flag.
2) <silent> is now -silent, as one would likely expect.
3) You probably don't want -silent anyway. Try -ex or -js, which 
    will be faster and won't muddle with your command line 
    history.
4) Mappings won't take a count unless you use the -count flag,
    and they won't be prepended to the fed keys unless you 
    explicitly prepend <count>.

-- 
Kris Maglione

If buffer overflows are ever controlled, it won't be due to mere
crashes, but due to their making systems vulnerable to hackers.
Software crashes due to mere incompetence apparently don't raise any
eyebrows, because no one wants to fault the incompetent programmer and
his incompetent boss.
	--Henry Baker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: map.js
Type: application/x-javascript
Size: 2246 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090505/ea219092/attachment.js>

From maglione.k at gmail.com  Tue May  5 14:54:02 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 5 May 2009 17:54:02 -0400
Subject: [Vimperator] Some JS utility functions that seem to have some
	utility
Message-ID: <20090505215402.GD8688@jg.home>

Attached are some utility functions that I find useful and 
lately miss in Vimperator. The most noteworty I think, though, 
is Class, which makes class-like objects a lot easier to create. 
It doesn't allow for closure-based instances like we currently 
use, but I think this is a feature. They're big, messy, and 
slow. Most of the functions are Pythonesque, as JS 1.7+ seems to 
be moving in that direction, anyway.

An example of a class:

const BaseClass = Class(Class, {}, {})

const Command = Class(BaseClass, {
     __init__: function(name, action) {
	this.name = name;
	this.action = action;
     },
     execute: function(argstring) {
	return this.action(Command.parseArgs(argString));
     },
}, {
     parseArgs: function (str) {
	return Commands.parseArgs(str);
     },
});

const commands = [
     Command("foo", function() liberator.echo("foo")),
     Command("bar", function() liberator.echoerr("bar")),
];

const commandMap = dict([c.name, c] for each (c in commands)]);

I'd personally advocate this approach for most of our small, 
non-singleton classes, such as Map, Command, Option, and 
possibly others.

As for the utility functions, I think that most of them should 
probably be moved out of the util namespace. Especially ones 
like range, and the provided keys, values, dict, ... They just 
take up too much space when prefixed with ?util.?, especially 
when several are on one line. As the names provided will be 
familiar to most Python programmers, and Python generally seems 
to be the New Hotness, I don't think that many programmers will 
be confused by them.

-- 
Kris Maglione

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
	--Alan Kay


From maglione.k at gmail.com  Tue May  5 14:54:54 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 5 May 2009 17:54:54 -0400
Subject: [Vimperator] Some JS utility functions that seem to have some
	utility
In-Reply-To: <20090505215402.GD8688@jg.home>
References: <20090505215402.GD8688@jg.home>
Message-ID: <20090505215454.GE8688@jg.home>

Obviously,

-- 
Kris Maglione

I can hardly see how anyone ought to wish Christianity to be true; for
if so the plain language of the text seems to show that the men who do
not believe, and this would include my Father, Brother, and almost all
my best friends, will be everlastingly punished.  And this is a
damnable doctrine.
	--Charles Darwin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jslib.js
Type: application/x-javascript
Size: 4628 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090505/32281a45/attachment-0001.js>

From stubenschrott at vimperator.org  Tue May  5 14:59:35 2009
From: stubenschrott at vimperator.org (Martin Stubenschrott)
Date: Tue, 05 May 2009 23:59:35 +0200
Subject: [Vimperator] Alternative :map command
In-Reply-To: <20090505213013.GC8688@jg.home>
References: <20090505213013.GC8688@jg.home>
Message-ID: <4A00B6C7.8090701@vimperator.org>

On 05/05/2009 11:30 PM, Kris Maglione wrote:

> Hi,
> 
> Attached is a plugin for an alternative to the :map command. The 
> usage is mostly self-explanitory (I need to add descriptions to 
> the option specs, but that requires slight internals changes). 
> This will only work with the latest bleeding edge. There are 
> some differences to be aware of:
> 
> 1) The default behavior is that of :noremap. If you want 
>     remapping, use the -noremap flag.


wouldn't -remap make more sense to NOT get a noremap behavior?

> 2) <silent> is now -silent, as one would likely expect.


makes sense

> 3) You probably don't want -silent anyway. Try -ex or -js, which 
>     will be faster and won't muddle with your command line 
>     history.


Great addition! 

> 4) Mappings won't take a count unless you use the -count flag,
>     and they won't be prepended to the fed keys unless you 
>     explicitly prepend <count>.

Haven't thought about that one but i am sure, you had reasons for this.

Actually I think, such a :map command should probably be default in vimperator,
not just by a plugin, but probably just after vimp 2.1 is released (which
I plan to do quite soon, unless you know of some real showstoppers).

We could maybe even add a :map -modes=normal,insert,browser,caret,...

For vim compatibility, we probably should keep :imap, etc. mapped to :map -modes=insert

However, what do others think about it? 

--
Martin

From maglione.k at gmail.com  Tue May  5 15:03:02 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 5 May 2009 18:03:02 -0400
Subject: [Vimperator] Alternative :map command
In-Reply-To: <4A00B6C7.8090701@vimperator.org>
References: <20090505213013.GC8688@jg.home> <4A00B6C7.8090701@vimperator.org>
Message-ID: <20090505220302.GF8688@jg.home>

On Tue, May 05, 2009 at 11:59:35PM +0200, Martin Stubenschrott wrote:
>> 1) The default behavior is that of :noremap. If you want 
>>     remapping, use the -noremap flag.
>
>wouldn't -remap make more sense to NOT get a noremap behavior?

Sorry, read the source, not the text. That's what it does.

>> 4) Mappings won't take a count unless you use the -count flag,
>>     and they won't be prepended to the fed keys unless you 
>>     explicitly prepend <count>.
>
>Haven't thought about that one but i am sure, you had reasons for this.

Well, it seemed that it made more sense to let the user decide 
what to do with the count, and if he has that control, he may as 
well be able to decide whether or not to take a count.

>Actually I think, such a :map command should probably be default in vimperator,
>not just by a plugin, but probably just after vimp 2.1 is released (which
>I plan to do quite soon, unless you know of some real showstoppers).

Cool.

-- 
Kris Maglione

An organisation that treats its programmers as morons will soon have
programmers that are willing and able to act like morons only.
	--Bjarne Stroustrup


From stubenschrott at vimperator.org  Tue May  5 15:44:01 2009
From: stubenschrott at vimperator.org (Martin Stubenschrott)
Date: Wed, 06 May 2009 00:44:01 +0200
Subject: [Vimperator] Some JS utility functions that seem to have some
 utility
In-Reply-To: <20090505215402.GD8688@jg.home>
References: <20090505215402.GD8688@jg.home>
Message-ID: <4A00C131.5070504@vimperator.org>

On 05/05/2009 11:54 PM, Kris Maglione wrote:

> Attached are some utility functions that I find useful and 
> lately miss in Vimperator.


I am not the biggest fan of too many utility functions, since for
non-hardcore vimp developers it makes reading code quite a lot harder
since many algorithms do not consist of just standard JS anymore.

> The most noteworty I think, though, 
> is Class, which makes class-like objects a lot easier to create. 
> It doesn't allow for closure-based instances like we currently 
> use, but I think this is a feature. They're big, messy, and 
> slow. Most of the functions are Pythonesque, as JS 1.7+ seems to 
> be moving in that direction, anyway.
> <snip>
> const commandMap = dict([c.name, c] for each (c in commands)]);
> 
> I'd personally advocate this approach for most of our small, 
> non-singleton classes, such as Map, Command, Option, and 
> possibly others.

I am not too happy with how the current class approach works (mainly
the difficulty to make things "private" which i am a very big proponent
of), but since JS2 is on its way, i will not introduce another class
concept which needs to be changed again to "standard" classes when
JS2 is finally available to addon authors. And as i said above, I really
do like keeping usage of non-standard methods/utilities to a bar minimum.

> As for the utility functions, I think that most of them should 
> probably be moved out of the util namespace. Especially ones 
> like range, and the provided keys, values, dict, ... They just 
> take up too much space when prefixed with ?util.?, especially 
> when several are on one line.


Maybe that code should be rewritten than? :) Honestly, and we already
had this discussion briefly, lots of this code is just not quickly/easily
readable by "non-hardcore-coders":

Array.slice(arguments, 1).filter(util.identity).forEach(function (src)

with util.identity being: 

identity: function identity(k) k,

I mean, we keep filling up the 'util' namespace with such rarely used
methods/concepts which no JavaScript developer has probably ever heard
of, instead of using "util" for what it was originally meant - for
providing *high-level* convenience functions like stringToUrlArray().


> As the names provided will be 
> familiar to most Python programmers, and Python generally seems 
> to be the New Hotness, I don't think that many programmers will 
> be confused by them.


Aehm, isn't ruby the New Hotness? :)
Anyway, I do not really like the python way of thinking and having
many "top level" methods, i prefer the "everything is an object" way
of thinking like [1, 2, 3].each(...).

Anyway, I don't even want to make JavaScript Python, nor do I want to 
make it Ruby (although i really like Ruby). I want it still to feel
like JavaScript. Therefore the best would be to just extend
Array.prototype.uniq = ... so we could use [1, 3, 5].uniq().sort().
However, this probably has some unpredictable results, if JS decides
to add a uniq method by default.

Although the principle of vimperator's code should be that a developer
with profound knowledge of the *latest* JS standard but not much
knowledge of the vimperator code base can *read* the
code easily. This is more important than saving 2 lines of code by
using 5 nested method calls where 3 of them are not standard JS methods! 

Ok, enough of my difficult-to-follow rant for today and I hope I didn't
offend anybody :)

--
Martin

From dmishd at gmail.com  Wed May  6 09:52:43 2009
From: dmishd at gmail.com (mish)
Date: Wed, 6 May 2009 17:52:43 +0100
Subject: [Vimperator] jV and vimperator
Message-ID: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>

I've been using vimperator for a little while and love it. Then while
documenting various ways to make everything work like vim, I came
across the firefox extension jV - that makes text areas work like vi.
It's not quite at version 1, but works pretty well.

So first off I thought I'd make sure vimperator folks know about it. I
often don't always launch gvim as the wait of a second or so can be a
bit much, but having vi editing directly in the text boxes is great.

Next, I don't know if we can work with the jV developer so that we can
include the code in vimperator and have this behaviour in text boxes.

In the meantime, there is a little conflict as recorded here:
http://code.google.com/p/jv-extension/issues/detail?id=14

Basically when in insert mode in the text box in jV, pressing Escape
causes the focus to go to the vimperator command line.

Another option is to do

:inoremap <Esc> <C-v><C-[>
:inoremap <Tab> <Esc>

This means that, when in (vimperator) insert mode, Esc will be passed
through vimperator to be C-[ in the text box (and thus for jV).
Meanwhile, when in (vimperator) insert mode the Tab key will take you
to the vimperator prompt. Generally the tab key will take you out of
the text box anyway, so this seems like a good way of doing it. This
does have the disadvantage that you can't just tab to the button to
submit the form.

Anyone have suggestions for what key to use to go to the vimperator
prompt? Maybe Alt? Or maybe no key, you just have to tab out of the
text box first ...

Another option mentioned in the bug report is to use the Ctrl-[
combination. I don't like it so much, but to do so use:

:imap <C-[> <C-v><C-[>

mish


jV links
https://addons.mozilla.org/en-US/firefox/addon/8529
http://code.google.com/p/jv-extension/

From maglione.k at gmail.com  Wed May  6 10:34:36 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Wed, 6 May 2009 13:34:36 -0400
Subject: [Vimperator] jV and vimperator
In-Reply-To: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>
Message-ID: <20090506173436.GA13711@jg.home>

On Wed, May 06, 2009 at 05:52:43PM +0100, mish wrote:
>I've been using vimperator for a little while and love it. Then while
>documenting various ways to make everything work like vim, I came
>across the firefox extension jV - that makes text areas work like vi.
>It's not quite at version 1, but works pretty well.
>
>So first off I thought I'd make sure vimperator folks know about it. I
>often don't always launch gvim as the wait of a second or so can be a
>bit much, but having vi editing directly in the text boxes is great.

We have it already. :h 'insertmode'

>Next, I don't know if we can work with the jV developer so that we can
>include the code in vimperator and have this behaviour in text boxes.
>
>In the meantime, there is a little conflict as recorded here:
>http://code.google.com/p/jv-extension/issues/detail?id=14

See my recently posted map.js plugin, and:

:map -m textarea <Esc> <C-v><Esc>

-- 
Kris Maglione

Doing linear scans over an associative array is like trying to club
someone to death with a loaded Uzi.
	--Larry Wall


From chm.duquesne at gmail.com  Wed May  6 11:57:53 2009
From: chm.duquesne at gmail.com (Christophe-Marie Duquesne)
Date: Wed, 6 May 2009 20:57:53 +0200
Subject: [Vimperator] jV and vimperator
In-Reply-To: <20090506173436.GA13711@jg.home>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com> 
	<20090506173436.GA13711@jg.home>
Message-ID: <8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>

Or, you can use xembed to embed the _real_ vim in firefox.

This has the disadvantage of not being portable and will run only on
linux. But the big advantage is that you will be able to rely on the
real vim, so no trouble with bugs due to badly ported
functionnalities, and it will be lauched _inside_ firefox, replacing
the textarea. Obviously, this can only come as a plugin.

The good news is there already exists such a firefox plugin. I spent a
bit of time trying to hack its code, because it was not working at the
time on firefox 3, but now it has been ported and you should be able
to install it easily. You can find it at
https://addons.mozilla.org/en-US/firefox/addon/5482.

However, if someone wants to port this code as a vimperator plugin, I
would be glad to help. There is a great optimization that could be
added, because now it is unefficient and monitors files in a very
dirty way. At the time, I would have finished the port if I had known
how to start an external program from the js (I'm a total beginner in
js, but I still managed to embed vim in a textarea with very few lines
of code). Using inotify, one could achieve the same behavior as the
plugin, but in a much more efficient way. This would probably make it
faster and lighter (at the cost of adding a dependency).
-- 
Christophe-Marie Duquesne

From maglione.k at gmail.com  Wed May  6 12:07:54 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Wed, 6 May 2009 15:07:54 -0400
Subject: [Vimperator] jV and vimperator
In-Reply-To: <8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>
Message-ID: <20090506190754.GA12886@jg.home>

On Wed, May 06, 2009 at 08:57:53PM +0200, Christophe-Marie Duquesne wrote:
>Or, you can use xembed to embed the _real_ vim in firefox.

Not really. XEmbed is a specific protocol which Vim doesn't 
really support. EmbeddedEditor will embed vim via mozplugger 
without XEmbed, though.

>However, if someone wants to port this code as a vimperator plugin, I
>would be glad to help. There is a great optimization that could be
>added, because now it is unefficient and monitors files in a very
>dirty way. At the time, I would have finished the port if I had known
>how to start an external program from the js (I'm a total beginner in
>js, but I still managed to embed vim in a textarea with very few lines
>of code). Using inotify, one could achieve the same behavior as the
>plugin, but in a much more efficient way. This would probably make it
>faster and lighter (at the cost of adding a dependency).

It's actually quite a trivial optimization. Polling a single 
file is cheap. Even if a browser had dozens of textareas open at 
once, it would be cheap, but it could be optimized to only poll 
when they're visible, nonetheless. Regardless, you couldn't use 
inotify from Firefox without writing a C++ component, which is 
more trouble than it's worth. At any rate, you don't need to 
know how to spawn a program from JavaScript (or, more 
accurately, from Gecko), as you have no way to embed it without 
something like mozplugger. If you want to learn, though,  have a 
look at liberator.git/common/content/io.js. The model that 
EmbeddedEditor uses leaves the spawning to mozplugger itself and 
only deals with monitoring for changes and managing the overlay.

-- 
Kris Maglione

Are you quite sure that all those bells and whistles, all those
wonderful facilities of your so called powerful programming languages,
belong to the solution set rather than the problem set?
	--Edsger W. Dijkstra


From chm.duquesne at gmail.com  Wed May  6 14:30:25 2009
From: chm.duquesne at gmail.com (Christophe-Marie Duquesne)
Date: Wed, 6 May 2009 23:30:25 +0200
Subject: [Vimperator] jV and vimperator
In-Reply-To: <20090506190754.GA12886@jg.home>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com> 
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com> 
	<20090506190754.GA12886@jg.home>
Message-ID: <8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com>

You are right, I used a shortcut and I said xembed instead of
mozplugger. EmbeddedEditor uses mozplugger, and what mozplugger does
is embedding clients using the xembed protocol.

For those who are interested in what I have in my mind exactly, I'm
going to put it here. If I have time, I'll do it one day, but I think
this is worth sharing.

@Kris: you seem to have read the code of embeddedEditor too, so if I
say something wrong, please correct me.

Embedded Editor does a pretty simple job. On the ctrl +e event, it
detects size and style of the focused textarea and hides it. It adds
in the page an object with a custom mimetype, putting these size and
style in this mimetype (like parameters for mozplugger). Then
mozplugger does all the job, parsing automatically the mimetype and
launching an odd command, which is : launch an xterm with the given
size and style, and execute inside : create a lock file, launch vim on
a temporary file, remove the lock file, quit the xterm. As long as vim
is running, the lock file is not removed. When vim is closed, the lock
file is removed and the xterm is closed.

As mozplugger has no way to tell javascript that vim has stop running,
using a lock file is the only way to know that vim is still running,
and then to unhide the textarea. To detect the fact the lock file has
been removed, embeddedEditor probes every x milliseconds the existence
of this file (IMO, this is Ugly).

The second point is that in case the user wants for example to press a
'send' button while vim is open, the content of the textarea has to be
updated when the timestamp of the temporary file is changed. Embedded
editor also uses monitoring to know this and update the textarea (Ugly
also).

IMO, using the inotify feature of the linux kernel  be much cleaner...

@Kris: Your idea to poll only for visible textarea is good, but I
think we might gain more if we used inotify-tools, since we would not
poll at all.

Another thing that could be cool, to know when vim has been closed,
could be to use dtach or screen. If vim was lauched from js through
dtach, and dtach was used in the xterm, then we would have no problem
to know when vim has been closed, and we would not have to use
lockfiles.

Again, if you have something to add, please share :)
-- 
Christophe-Marie Duquesne

From maglione.k at gmail.com  Wed May  6 14:48:39 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Wed, 6 May 2009 17:48:39 -0400
Subject: [Vimperator] jV and vimperator
In-Reply-To: <8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>
	<20090506190754.GA12886@jg.home>
	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com>
Message-ID: <20090506214839.GB12886@jg.home>

On Wed, May 06, 2009 at 11:30:25PM +0200, Christophe-Marie Duquesne wrote:
>You are right, I used a shortcut and I said xembed instead of
>mozplugger. EmbeddedEditor uses mozplugger, and what mozplugger does
>is embedding clients using the xembed protocol.

No, it doesn't. It embeds X clients, yes. It doesn't, however, 
make use of the XEmbed protocol. In fact, it doesn't really do 
anything particularly elegant whatsoever. As I recall, it 
bascially just launches a program, waits for a window with a 
matching class to pop up, and just stuffs it into its plugin 
window.

>As mozplugger has no way to tell javascript that vim has stop running,
>using a lock file is the only way to know that vim is still running,
>and then to unhide the textarea. To detect the fact the lock file has
>been removed, embeddedEditor probes every x milliseconds the existence
>of this file (IMO, this is Ugly).
>
>The second point is that in case the user wants for example to press a
>'send' button while vim is open, the content of the textarea has to be
>updated when the timestamp of the temporary file is changed. Embedded
>editor also uses monitoring to know this and update the textarea (Ugly
>also).
>
>IMO, using the inotify feature of the linux kernel  be much cleaner...

But, again, there's no clean way to use it from Firefox. Either 
you need to use an external program, or write a C++ component. 
And, even then, you need to maintain the polling method as a 
fallback for other Unices and older Linux versions. I don't 
think that inotify really provides sufficient advantage to 
warrant the extra effort.

>Another thing that could be cool, to know when vim has been closed,
>could be to use dtach or screen. If vim was lauched from js through
>dtach, and dtach was used in the xterm, then we would have no problem
>to know when vim has been closed, and we would not have to use
>lockfiles.

I think that would be doable, and there are probably even a few 
better hacks, but I think they would be best accomplished via 
user hooks. I'm not sure what that would look like.

-- 
Kris Maglione

We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
	--Donald Knuth


From chm.duquesne at gmail.com  Wed May  6 15:03:36 2009
From: chm.duquesne at gmail.com (Christophe-Marie Duquesne)
Date: Thu, 7 May 2009 00:03:36 +0200
Subject: [Vimperator] jV and vimperator
In-Reply-To: <20090506214839.GB12886@jg.home>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com> 
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com> 
	<20090506190754.GA12886@jg.home>
	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com> 
	<20090506214839.GB12886@jg.home>
Message-ID: <8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com>

> But, again, there's no clean way to use it from Firefox. Either you need to
> use an external program, or write a C++ component. And, even then, you need
> to maintain the polling method as a fallback for other Unices and older
> Linux versions. I don't think that inotify really provides sufficient
> advantage to warrant the extra effort.

I am not sure I understand. You mean that, to launch an external
program from firefox, you need to write a C++ component? I know the
way inotify is usually used is from C code, but there is an external
tool I use all the time in bash scripts, which comes usually in a
package called inotify-tools in most distribs. It is called
inotifywait, you can find the man page here :
http://linux.die.net/man/1/inotifywait .

Are you speaking about writing C/C++ code because you did not know
this tool, or do you mean it is really necessary? Sorry if I ask
strange questions, I don't really know how launching external programs
from gecko is done, so I would be glad if you enlighted me :)
-- 
Christophe-Marie Duquesne

From maglione.k at gmail.com  Wed May  6 15:18:19 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Wed, 6 May 2009 18:18:19 -0400
Subject: [Vimperator] jV and vimperator
In-Reply-To: <8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>
	<20090506190754.GA12886@jg.home>
	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com>
	<20090506214839.GB12886@jg.home>
	<8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com>
Message-ID: <20090506221819.GC12886@jg.home>

On Thu, May 07, 2009 at 12:03:36AM +0200, Christophe-Marie Duquesne wrote:
>> But, again, there's no clean way to use it from Firefox. Either you need to
>> use an external program, or write a C++ component. And, even then, you need
>> to maintain the polling method as a fallback for other Unices and older
>> Linux versions. I don't think that inotify really provides sufficient
>> advantage to warrant the extra effort.
>
>I am not sure I understand. You mean that, to launch an external
>program from firefox, you need to write a C++ component? I know the
>way inotify is usually used is from C code, but there is an external
>tool I use all the time in bash scripts, which comes usually in a
>package called inotify-tools in most distribs. It is called
>inotifywait, you can find the man page here :
>http://linux.die.net/man/1/inotifywait .

Unless my eyes deceive me (and I wouldn't put it past them), I 
think I explicitly said ?Either you need to use an external 
program, or write a C++ component.? And, even in the former 
case, that external program is non-standard, platform specific, 
and an additional dependency (even above installing mozplugger 
and manually editing mozpluggerrc).

-- 
Kris Maglione

Do not worry about your difficulties in mathematics, I assure you that
mine are greater.
	--Albert Einstein


From chm.duquesne at gmail.com  Wed May  6 15:31:42 2009
From: chm.duquesne at gmail.com (Christophe-Marie Duquesne)
Date: Thu, 7 May 2009 00:31:42 +0200
Subject: [Vimperator] jV and vimperator
In-Reply-To: <20090506221819.GC12886@jg.home>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com> 
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com> 
	<20090506190754.GA12886@jg.home>
	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com> 
	<20090506214839.GB12886@jg.home>
	<8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com> 
	<20090506221819.GC12886@jg.home>
Message-ID: <8ccc3510905061531t6d34a3b0i24bf497c9ce40d0c@mail.gmail.com>

> that external program is
> non-standard, platform specific, and an additional dependency (even above
> installing mozplugger and manually editing mozpluggerrc).

Well, inotifywait is available on every recent distrib, but anyway you
need a recent distrib to install firefox 3 and run vimperator.

But this is true : this hack would add 3 dependencies : mozplugger,
dtach and inotifywait.

-- 
Christophe-Marie Duquesne

From maglione.k at gmail.com  Wed May  6 15:38:12 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Wed, 6 May 2009 18:38:12 -0400
Subject: [Vimperator] jV and vimperator
In-Reply-To: <8ccc3510905061531t6d34a3b0i24bf497c9ce40d0c@mail.gmail.com>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>
	<20090506190754.GA12886@jg.home>
	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com>
	<20090506214839.GB12886@jg.home>
	<8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com>
	<20090506221819.GC12886@jg.home>
	<8ccc3510905061531t6d34a3b0i24bf497c9ce40d0c@mail.gmail.com>
Message-ID: <20090506223812.GD12886@jg.home>

On Thu, May 07, 2009 at 12:31:42AM +0200, Christophe-Marie Duquesne wrote:
>> that external program is
>> non-standard, platform specific, and an additional dependency (even above
>> installing mozplugger and manually editing mozpluggerrc).
>
>Well, inotifywait is available on every recent distrib, but anyway you
>need a recent distrib to install firefox 3 and run vimperator.
>
>But this is true : this hack would add 3 dependencies : mozplugger,
>dtach and inotifywait.

Available, yes. Dependency, yes. And, again, that's only 
considering Linux, and recent Linux versions. It's possible to 
install Firefox 3 on Linux kernels that don't support inotify.

-- 
Kris Maglione

Perhaps when a man has special knowledge and special powers like my
own, it rather encourages him to seek a complex explanation when a
simpler one is at hand.
	--"Sherlock Holmes"


From henri.ducrocq at gmail.com  Wed May  6 15:51:10 2009
From: henri.ducrocq at gmail.com (Henri Ducrocq)
Date: Wed, 6 May 2009 23:51:10 +0100
Subject: [Vimperator] jV and vimperator
In-Reply-To: <20090506223812.GD12886@jg.home>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com> 
	<20090506173436.GA13711@jg.home>
	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com> 
	<20090506190754.GA12886@jg.home>
	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com> 
	<20090506214839.GB12886@jg.home>
	<8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com> 
	<20090506221819.GC12886@jg.home>
	<8ccc3510905061531t6d34a3b0i24bf497c9ce40d0c@mail.gmail.com> 
	<20090506223812.GD12886@jg.home>
Message-ID: <391beaa80905061551u3f8dd6ex324110493f6c2fc@mail.gmail.com>

And to be fair the benefit in using a real Vim process for textarea editing
is non-existent for the vast majority of users. For these rare cases when
fancy editing is necessary C-i does the job.

On Wed, May 6, 2009 at 11:38 PM, Kris Maglione <maglione.k at gmail.com> wrote:

> On Thu, May 07, 2009 at 12:31:42AM +0200, Christophe-Marie Duquesne wrote:
>
>> that external program is
>>> non-standard, platform specific, and an additional dependency (even above
>>> installing mozplugger and manually editing mozpluggerrc).
>>>
>>
>> Well, inotifywait is available on every recent distrib, but anyway you
>> need a recent distrib to install firefox 3 and run vimperator.
>>
>> But this is true : this hack would add 3 dependencies : mozplugger,
>> dtach and inotifywait.
>>
>
> Available, yes. Dependency, yes. And, again, that's only considering Linux,
> and recent Linux versions. It's possible to install Firefox 3 on Linux
> kernels that don't support inotify.
>
> --
> Kris Maglione
>
> Perhaps when a man has special knowledge and special powers like my
> own, it rather encourages him to seek a complex explanation when a
> simpler one is at hand.
>        --"Sherlock Holmes"
>
>
> _______________________________________________
> Vimperator mailing list
> Vimperator at mozdev.org
> https://www.mozdev.org/mailman/listinfo/vimperator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090506/369decac/attachment.html>

From stubenschrott at vimperator.org  Wed May  6 15:51:59 2009
From: stubenschrott at vimperator.org (Martin Stubenschrott)
Date: Thu, 07 May 2009 00:51:59 +0200
Subject: [Vimperator] jV and vimperator
In-Reply-To: <20090506223812.GD12886@jg.home>
References: <2af236e00905060952x2d6d991bi52a28e2e0d987091@mail.gmail.com>	<20090506173436.GA13711@jg.home>	<8ccc3510905061157v56cd2ceei255c1d46d741f41d@mail.gmail.com>	<20090506190754.GA12886@jg.home>	<8ccc3510905061430n21adaef0j5dd52bffad201533@mail.gmail.com>	<20090506214839.GB12886@jg.home>	<8ccc3510905061503i45aabaf1l4d3a0c4c3002a687@mail.gmail.com>	<20090506221819.GC12886@jg.home>	<8ccc3510905061531t6d34a3b0i24bf497c9ce40d0c@mail.gmail.com>
	<20090506223812.GD12886@jg.home>
Message-ID: <4A02148F.6010107@vimperator.org>

On 05/07/2009 12:38 AM, Kris Maglione wrote:

>>But this is true : this hack would add 3 dependencies : mozplugger,
>>dtach and inotifywait.

For a plugin, totally acceptable, but of course not for vimperator
itself.

> Available, yes. Dependency, yes. And, again, that's only 
> considering Linux, and recent Linux versions. It's possible to 
> install Firefox 3 on Linux kernels that don't support inotify.


Well right, but if the major distros ship inotify, that would be
enough IMHO. It's more important that all main vimperator features
work an all supported platforms. Of course legacy support is nice,
but not so important if it would require extra work, when a new,
better solution is already possible.

--
Martin

From coolcd05a at gmail.com  Fri May  8 06:12:19 2009
From: coolcd05a at gmail.com (Alan CHENG)
Date: Fri, 8 May 2009 21:12:19 +0800
Subject: [Vimperator]  Number hint problem in Debian Iceweasel
Message-ID: <56096cc30905080612t361e5575ud7a53d63baa7f23c@mail.gmail.com>

hi, all

I recently noticed that numbered hint feature (when pressing f) seems to be
broken in Iceweasel. After pressing f, if the number is greater then 9, the
link won't be followed after typing the numbered hint. For example, 13,
normally, typing 1 and 3 would bring you to the link address. But now,
vimperator would first focus 1, then 3, and then go to the link hintted 3.

I encountered this problem when using Vimperator 2.0 and a few recent
nightly versions in Iceweasel 3.0.9 on Debian testing. But it works fine in
Firefox 3.0.10 on Windows XP.

I've googled this problem. And it seems this also happens to Vimperator 2.0
in Firefox 3.0.8 on Arch Linux.
http://bbs.archlinux.org/viewtopic.php?id=69059

Hope someone can help find the solution.



Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090508/61273553/attachment.html>

From stubenschrott at vimperator.org  Fri May  8 12:29:13 2009
From: stubenschrott at vimperator.org (Martin Stubenschrott)
Date: Fri, 08 May 2009 21:29:13 +0200
Subject: [Vimperator] Number hint problem in Debian Iceweasel
In-Reply-To: <56096cc30905080612t361e5575ud7a53d63baa7f23c@mail.gmail.com>
References: <56096cc30905080612t361e5575ud7a53d63baa7f23c@mail.gmail.com>
Message-ID: <4A048809.3030802@vimperator.org>

On 05/08/2009 03:12 PM, Alan CHENG wrote:

> Hope someone can help find the solution.


Have you tried a nightly snapshot from our homepage to
see if that does work fine?

And do you have special settings in your rc file?

--
Martin

From jona.hunt777 at gmail.com  Fri May  8 20:01:53 2009
From: jona.hunt777 at gmail.com (Hunt Jon)
Date: Sat, 9 May 2009 12:01:53 +0900
Subject: [Vimperator] Anyway to make the caret more visible?
Message-ID: <5e1f1f1f0905082001k48b4dd92n63aa1f13345f0475@mail.gmail.com>

When I press "i", it goes into caret mode, but I find it difficult to
find the location of the carret.

I think some CSS styling might help, but I cannot find a way...

Can anybody help on this?

John

From fb at intoxicatedmind.net  Fri May  8 22:49:37 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Sat, 9 May 2009 07:49:37 +0200
Subject: [Vimperator] Anyway to make the caret more visible?
In-Reply-To: <5e1f1f1f0905082001k48b4dd92n63aa1f13345f0475@mail.gmail.com>
References: <5e1f1f1f0905082001k48b4dd92n63aa1f13345f0475@mail.gmail.com>
Message-ID: <20090509054937.GC11333@intoxicatedmind.net>

Hi.

On Sat 2009-05-09 12:01, Hunt Jon <jona.hunt777 at gmail.com> proclaimed:
> When I press "i", it goes into caret mode, but I find it difficult to
> find the location of the carret.
> 
> I think some CSS styling might help, but I cannot find a way...
> 
> Can anybody help on this?

http://forums.mozillazine.org/viewtopic.php?f=38&t=865895

set! ui.caretWidth=4
set! ui.caretBlinkTime=250

Note that this also affects the cursor on Vimperator's command line.


Greetings,
Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090509/9f83698d/attachment.bin>

From andrew at pimlott.net  Sun May 10 11:56:14 2009
From: andrew at pimlott.net (Andrew Pimlott)
Date: Sun, 10 May 2009 11:56:14 -0700
Subject: [Vimperator] does not revert position in incremental search
	(regression)
Message-ID: <20090510185614.GF28854@pimlott.net>

When I start an incremental search, and it scrolls down to the first
hit, and then I cancel with escape, vimperator does scroll back to the
original position.  Similarly, if I use backspace during an incremental
search, vimperator does not go back to the first hit from where I
started the search, but but to the first hit currently visible.
Older versions of vimperator did this right (to my delight!).  I'm using
2.0 now, and I'm pretty sure it worked before I upgraded from whatever
1.x I was using.

Andrew

From maglione.k at gmail.com  Sun May 10 13:25:46 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Sun, 10 May 2009 16:25:46 -0400
Subject: [Vimperator] does not revert position in incremental
	search	(regression)
In-Reply-To: <20090510185614.GF28854@pimlott.net>
References: <20090510185614.GF28854@pimlott.net>
Message-ID: <20090510202546.GA29018@jg.hsd1.nj.comcast.net>

On Sun, May 10, 2009 at 11:56:14AM -0700, Andrew Pimlott wrote:
>When I start an incremental search, and it scrolls down to the first
>hit, and then I cancel with escape, vimperator does scroll back to the
>original position.  Similarly, if I use backspace during an incremental
>search, vimperator does not go back to the first hit from where I
>started the search, but but to the first hit currently visible.
>Older versions of vimperator did this right (to my delight!).  I'm using
>2.0 now, and I'm pretty sure it worked before I upgraded from whatever
>1.x I was using.

I don't think it did. I had a commit several months ago to make 
it do so, but I reverted it before we made a release.

-- 
Kris Maglione

TeX has found at least one bug in every Pascal compiler it's been run
on, I think, and at least two in every C compiler.
	--Donald Knuth


From EJensen at scu.edu  Sun May 10 23:13:38 2009
From: EJensen at scu.edu (Eva Jensen)
Date: Sun, 10 May 2009 23:13:38 -0700
Subject: [Vimperator] help question command line problem
Message-ID: <4A075FA20200001A00008EB1@gwia2.scu.edu>

I can't use the command line. I type a colon then everything after that crashes. I can go to help via F1 and search, but is there an easy way to reinstall vimperator or is it currently down? It was working before, I just stopped today. Thanks,
Eva Jensen

-EJ

From dougkearns at gmail.com  Mon May 11 20:19:41 2009
From: dougkearns at gmail.com (Doug Kearns)
Date: Tue, 12 May 2009 13:19:41 +1000
Subject: [Vimperator] Some JS utility functions that seem to have some
	utility
In-Reply-To: <20090505215402.GD8688@jg.home>
References: <20090505215402.GD8688@jg.home>
Message-ID: <644fc65e0905112019g6b7ad414ida382f84033de1c6@mail.gmail.com>

On 5/6/09, Kris Maglione <maglione.k at gmail.com> wrote:

<snip>

> As the names
> provided will be familiar to most Python programmers, and Python generally
> seems to be the New Hotness, I don't think that many programmers will be
> confused by them.

Have you considered actually using Python?

Doug

From lecterror at gmail.com  Tue May 12 15:06:00 2009
From: lecterror at gmail.com (dr. Hannibal Lecter)
Date: Wed, 13 May 2009 00:06:00 +0200
Subject: [Vimperator] congrats to everyone developing vimperator
Message-ID: <54fb6d0f0905121506m172ebb15i4f5afb2b323aa514@mail.gmail.com>

Hi everyone!
I don't know where else to do this, so pardon me if this is the wrong
place.. I'm a fresh vim convert (for a few months now), and I must say I'm
loving it.

Since I don't have any credit card or plain old cash to spare (viva el
capitalismo!) so I'd just like to say "thank you very much" to everyone who
contributed to vimperator. So.. Thank you very much! You're all doing a
great job, just keep doing what you're doing now.

Cheers!

-- 
Misanthropy unleashed:
http://dsi.vozibrale.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090513/19be2f30/attachment.html>

From fb at intoxicatedmind.net  Mon May 18 01:27:50 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Mon, 18 May 2009 10:27:50 +0200
Subject: [Vimperator] Saving options (whitelist of flashblock.js)
Message-ID: <20090518082750.GE11083@intoxicatedmind.net>

Hi,

I was wondering if there is a way to make the current value of an option
persistent, i.e. write/replace a ``set opt=val'' line in the rc file.

I started using the flashblock.js plugin, which adds whitelisted sites
in the ``fbwhitelist'' option. I'd like to keep this list. Manually
editing the rc file is quite inconvenient in this case.


Greetings,
Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090518/5049567a/attachment.bin>

From maglione.k at gmail.com  Mon May 18 09:11:36 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Mon, 18 May 2009 12:11:36 -0400
Subject: [Vimperator] Saving options (whitelist of flashblock.js)
In-Reply-To: <20090518082750.GE11083@intoxicatedmind.net>
References: <20090518082750.GE11083@intoxicatedmind.net>
Message-ID: <20090518161136.GC18381@jg.hsd1.nj.comcast.net>

On Mon, May 18, 2009 at 10:27:50AM +0200, Frank Blendinger wrote:
>I was wondering if there is a way to make the current value of an option
>persistent, i.e. write/replace a ``set opt=val'' line in the rc file.
>
>I started using the flashblock.js plugin, which adds whitelisted sites
>in the ``fbwhitelist'' option. I'd like to keep this list. Manually
>editing the rc file is quite inconvenient in this case.

I use :mkv! ~/.vimperatorrc.mkv and :source it from 
.vimperatorrc.

-- 
Kris Maglione

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
	--Alan Kay


From fb at intoxicatedmind.net  Mon May 18 15:24:04 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Tue, 19 May 2009 00:24:04 +0200
Subject: [Vimperator] Saving options (whitelist of flashblock.js)
In-Reply-To: <20090518161136.GC18381@jg.hsd1.nj.comcast.net>
References: <20090518082750.GE11083@intoxicatedmind.net>
	<20090518161136.GC18381@jg.hsd1.nj.comcast.net>
Message-ID: <20090518222404.GI11083@intoxicatedmind.net>


On Mon 2009-05-18 12:11, Kris Maglione <maglione.k at gmail.com>
proclaimed:
> On Mon, May 18, 2009 at 10:27:50AM +0200, Frank Blendinger wrote:
>> I was wondering if there is a way to make the current value of an option
>> persistent, i.e. write/replace a ``set opt=val'' line in the rc file.
>>
>> I started using the flashblock.js plugin, which adds whitelisted sites
>> in the ``fbwhitelist'' option. I'd like to keep this list. Manually
>> editing the rc file is quite inconvenient in this case.
>
> I use :mkv! ~/.vimperatorrc.mkv and :source it from .vimperatorrc.

Ah, that was what I was looking for, no idea why I could not find it
myself in the docs.

I now have it this way:

    " save settings on quit
    autocmd VimperatorLeave .* mkv! ~/.vimperatorrc.mkv

This should be at the very end of .vimperatorrc:

    " order does matter, as some settings are only available when a certain
    " plugin is loaded
    loadplugins
    source! ~/.vimperatorrc.mkv


Thanks for the help and the nice plugin.


Greetings,
Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090519/898a8f84/attachment.bin>

From fb at intoxicatedmind.net  Tue May 19 05:08:27 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Tue, 19 May 2009 14:08:27 +0200
Subject: [Vimperator] Mapping contentAccess keys possible?
Message-ID: <20090519120827.GL11083@intoxicatedmind.net>

Hi,

I tried to create a mapping for some so called "contentAccess" keys that
some sites use, but could not get it to work.

I set this Firefox preference:

    " 0=disable, 1=Shift, 2=Ctrl, 4=Alt, 8=Meta
    set! ui.key.contentAccess=5

and pressing Shift+Alt+somekey works fine (even when not in pass through
mode).

I then tried to map something like this:
    
    map x <S-A-x>

but pressing `x' does not do a thing. I also tried putting <C-v> in
before and I tried setting different contentAccess keys (just Alt, map
to <A-x>), which did not help either.

I also tried with this command I found in the wiki:

    com! -nargs=+ passthrough :js events.feedkeys(<q-args>, true)

but :passthrough <S-A-x> also did not work.


I also tried the feedSomeKeys_2.js plugin[1], I used something like
fmap! x,<S-A-x> with and without a -vkey, all in vain.


So am I doing it just wrong or is there no way to map those
contentAccess keys?


Greetings,
Frank


[1] http://vimperator.org/trac/attachment/ticket/48/feedSomeKeys_2.js

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090519/8df2df50/attachment.bin>

From ted at tedpavlic.com  Tue May 19 05:28:00 2009
From: ted at tedpavlic.com (Ted Pavlic)
Date: Tue, 19 May 2009 08:28:00 -0400
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <20090519120827.GL11083@intoxicatedmind.net>
References: <20090519120827.GL11083@intoxicatedmind.net>
Message-ID: <4A12A5D0.8050205@tedpavlic.com>

(side note: In Vimperator, when mapping shift-modified modifiers, use an 
uppercase key rather than putting a S- in front of it. So don't use 
<S-A-x>. Use <A-X> instead. That's different than Vim, I know)

IIRC, Firefox grabs processes content access keys differently than it 
does other things. For example, let's say I do...

:set! ui.key.contentAccess=3
:map <C-X> :echo 'hi'
:map x <C-X>

and then I go to a Wikipedia main page:

*) If I hit <C-S-x>, I get a random page *AND* see ":echo 'hi'" show up 
in the command line.

*) If I hit x, I see ":echo 'hi'" show up in the command line.

So it's as if Vimperator's feedkeys isn't "low" enough to tickle 
Firefox's access key handler. So I think access keys are ironically 
inaccessible. I could be wrong, but the example above clearly isn't a 
desirable behavior. :(

--Ted


On 5/19/09 8:08 AM, Frank Blendinger wrote:
> Hi,
>
> I tried to create a mapping for some so called "contentAccess" keys that
> some sites use, but could not get it to work.
>
> I set this Firefox preference:
>
>      " 0=disable, 1=Shift, 2=Ctrl, 4=Alt, 8=Meta
>      set! ui.key.contentAccess=5
>
> and pressing Shift+Alt+somekey works fine (even when not in pass through
> mode).
>
> I then tried to map something like this:
>
>      map x<S-A-x>
>
> but pressing `x' does not do a thing. I also tried putting<C-v>  in
> before and I tried setting different contentAccess keys (just Alt, map
> to<A-x>), which did not help either.
>
> I also tried with this command I found in the wiki:
>
>      com! -nargs=+ passthrough :js events.feedkeys(<q-args>, true)
>
> but :passthrough<S-A-x>  also did not work.
>
>
> I also tried the feedSomeKeys_2.js plugin[1], I used something like
> fmap! x,<S-A-x>  with and without a -vkey, all in vain.
>
>
> So am I doing it just wrong or is there no way to map those
> contentAccess keys?
>
>
> Greetings,
> Frank
>
>
> [1] http://vimperator.org/trac/attachment/ticket/48/feedSomeKeys_2.js
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Vimperator mailing list
> Vimperator at mozdev.org
> https://www.mozdev.org/mailman/listinfo/vimperator

-- 
Ted Pavlic <ted at tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

From noid.phn at gmail.com  Tue May 19 08:49:50 2009
From: noid.phn at gmail.com (Timo Mihaljov)
Date: Tue, 19 May 2009 18:49:50 +0300
Subject: [Vimperator] [PATCH] Fix 'hi' to mean 'history' and 'hin' to mean
	'hintinputs'
Message-ID: <4A12D51E.8050204@gmail.com>

---
  common/content/hints.js |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/content/hints.js b/common/content/hints.js
index 2a76dd3..0d93a31 100644
--- a/common/content/hints.js
+++ b/common/content/hints.js
@@ -837,7 +837,7 @@ function Hints() //{{{
          "How words are split for hintmatching",
          "string", '[.,!?:;/"^$%&?()[\\]{}<>#*+|=~ _-]');

-    options.add(["hintinputs", "hi"],
+    options.add(["hintinputs", "hin"],
          "How text inputs are hinted",
          "stringlist", "label,value",
          {
-- 
1.6.3.1


From noid.phn at gmail.com  Tue May 19 09:11:57 2009
From: noid.phn at gmail.com (Timo Mihaljov)
Date: Tue, 19 May 2009 19:11:57 +0300
Subject: [Vimperator] [PATCH] Fix 'hi' to mean 'history' and 'hin' to mean
	'hintinputs'
Message-ID: <4A12DA4D.2020507@gmail.com>

---
  common/content/hints.js |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-hi-to-mean-history-and-hin-to-mean-hintinputs.patch
Type: text/x-patch
Size: 473 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090519/dd10734f/attachment.bin>

From maglione.k at gmail.com  Tue May 19 10:03:27 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Tue, 19 May 2009 13:03:27 -0400
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <20090519120827.GL11083@intoxicatedmind.net>
References: <20090519120827.GL11083@intoxicatedmind.net>
Message-ID: <20090519170327.GB10976@jg.hsd1.nj.comcast.net>

On Tue, May 19, 2009 at 02:08:27PM +0200, Frank Blendinger wrote:
>I tried to create a mapping for some so called "contentAccess" keys that
>some sites use, but could not get it to work.

Try this:

function accessKey(key) {
     let elem = buffer.evaluateXPath("*[@accesskey='" + key + "']");
     if (elem)
         buffer.followLink(elem)
}

:map x :js accessKey('x')<cr>

-- 
Kris Maglione

Perspective is worth 80 IQ points.
	--Alan Kay


From fb at intoxicatedmind.net  Tue May 19 22:57:37 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Wed, 20 May 2009 07:57:37 +0200
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <20090519170327.GB10976@jg.hsd1.nj.comcast.net>
References: <20090519120827.GL11083@intoxicatedmind.net>
	<20090519170327.GB10976@jg.hsd1.nj.comcast.net>
Message-ID: <20090520055737.GB22522@intoxicatedmind.net>

Hi.

On Tue 2009-05-19 13:03, Kris Maglione <maglione.k at gmail.com>
proclaimed:
> On Tue, May 19, 2009 at 02:08:27PM +0200, Frank Blendinger wrote:
>> I tried to create a mapping for some so called "contentAccess" keys that
>> some sites use, but could not get it to work.
>
> Try this:
>
> function accessKey(key) {
>     let elem = buffer.evaluateXPath("*[@accesskey='" + key + "']");
>     if (elem)
>         buffer.followLink(elem)
> }
>
> :map x :js accessKey('x')<cr>

I get this error:
chrome://liberator/content/buffer.js:1177: TypeError: doc is undefined

:ver
Vimperator 2.1a1pre (created: 2009/05/18 07:30:30) running on:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042805
Iceweasel/3.0.9 (Debian-3.0.9-1)


Greetings,
Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090520/24457628/attachment.bin>

From maglione.k at gmail.com  Wed May 20 08:30:57 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Wed, 20 May 2009 11:30:57 -0400
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <20090520055737.GB22522@intoxicatedmind.net>
References: <20090519120827.GL11083@intoxicatedmind.net>
	<20090519170327.GB10976@jg.hsd1.nj.comcast.net>
	<20090520055737.GB22522@intoxicatedmind.net>
Message-ID: <20090520153057.GC10976@jg.hsd1.nj.comcast.net>

On Wed, May 20, 2009 at 07:57:37AM +0200, Frank Blendinger wrote:
>I get this error:
>chrome://liberator/content/buffer.js:1177: TypeError: doc is undefined
>
>:ver
>Vimperator 2.1a1pre (created: 2009/05/18 07:30:30) running on:
>Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042805
>Iceweasel/3.0.9 (Debian-3.0.9-1)

Sorry, I wasn't thinking. Try:

     for (let elem in buffer.evaluateXPath("*[@accesskey='" + key + "']"))
         return buffer.followLink(elem)


-- 
Kris Maglione

Deleted code is debugged code.
	--Jeff Sickel


From fb at intoxicatedmind.net  Thu May 21 04:23:50 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Thu, 21 May 2009 13:23:50 +0200
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <20090520153057.GC10976@jg.hsd1.nj.comcast.net>
References: <20090519120827.GL11083@intoxicatedmind.net>
	<20090519170327.GB10976@jg.hsd1.nj.comcast.net>
	<20090520055737.GB22522@intoxicatedmind.net>
	<20090520153057.GC10976@jg.hsd1.nj.comcast.net>
Message-ID: <20090521112350.GD22522@intoxicatedmind.net>

Hi.

On Wed 2009-05-20 11:30, Kris Maglione <maglione.k at gmail.com>
proclaimed:
> On Wed, May 20, 2009 at 07:57:37AM +0200, Frank Blendinger wrote:
> Sorry, I wasn't thinking. Try:
>
>     for (let elem in buffer.evaluateXPath("*[@accesskey='" + key + "']"))
>         return buffer.followLink(elem)

It don't get any elems with this. I have no clue about evaluateXPath,
does it maybe only reach <a href=...> links? I am trying to reach an
<input type="submit" ...> here.


Greetings,
Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090521/e45ada35/attachment.bin>

From dougkearns at gmail.com  Thu May 21 05:01:05 2009
From: dougkearns at gmail.com (Doug Kearns)
Date: Thu, 21 May 2009 22:01:05 +1000
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <20090521112350.GD22522@intoxicatedmind.net>
References: <20090519120827.GL11083@intoxicatedmind.net>
	<20090519170327.GB10976@jg.hsd1.nj.comcast.net>
	<20090520055737.GB22522@intoxicatedmind.net>
	<20090520153057.GC10976@jg.hsd1.nj.comcast.net>
	<20090521112350.GD22522@intoxicatedmind.net>
Message-ID: <644fc65e0905210501o4a98ac57t6fe81845718a39f@mail.gmail.com>

On 5/21/09, Frank Blendinger <fb at intoxicatedmind.net> wrote:
> Hi.
>
>  On Wed 2009-05-20 11:30, Kris Maglione <maglione.k at gmail.com>
>  proclaimed:
>
> > On Wed, May 20, 2009 at 07:57:37AM +0200, Frank Blendinger wrote:
>
> > Sorry, I wasn't thinking. Try:
>  >
>  >     for (let elem in buffer.evaluateXPath("*[@accesskey='" + key + "']"))
>  >         return buffer.followLink(elem)
>
>
> It don't get any elems with this. I have no clue about evaluateXPath,
>  does it maybe only reach <a href=...> links? I am trying to reach an
>  <input type="submit" ...> here.

"//*[@accesskey='" + key + "']"

Doug

From mchalkley at mail.com  Thu May 21 07:57:35 2009
From: mchalkley at mail.com (mchalkley at mail.com)
Date: Thu, 21 May 2009 10:57:35 -0400
Subject: [Vimperator] Printable doc?
Message-ID: <804273223.20090521105735@mail.com>

Is there an easy way to produce printable doc containing all of the
Vimperator help?  There's so many things Vimperator is capable of, it
would seem to be a big help to be able to have something that you
could print off to read in your spare time, just so you could find new
ways of using it...

Mark


From fb at intoxicatedmind.net  Thu May 21 09:50:10 2009
From: fb at intoxicatedmind.net (Frank Blendinger)
Date: Thu, 21 May 2009 18:50:10 +0200
Subject: [Vimperator] Mapping contentAccess keys possible?
In-Reply-To: <644fc65e0905210501o4a98ac57t6fe81845718a39f@mail.gmail.com>
References: <20090519120827.GL11083@intoxicatedmind.net>
	<20090519170327.GB10976@jg.hsd1.nj.comcast.net>
	<20090520055737.GB22522@intoxicatedmind.net>
	<20090520153057.GC10976@jg.hsd1.nj.comcast.net>
	<20090521112350.GD22522@intoxicatedmind.net>
	<644fc65e0905210501o4a98ac57t6fe81845718a39f@mail.gmail.com>
Message-ID: <20090521165010.GG22522@intoxicatedmind.net>

Hi.

On Thu 2009-05-21 22:01, Doug Kearns <dougkearns at gmail.com> proclaimed:
> On 5/21/09, Frank Blendinger <fb at intoxicatedmind.net> wrote:
> >  On Wed 2009-05-20 11:30, Kris Maglione <maglione.k at gmail.com>
> >  proclaimed:
> > > On Wed, May 20, 2009 at 07:57:37AM +0200, Frank Blendinger wrote:
> >
> > > Sorry, I wasn't thinking. Try:
> >  >
> >  >     for (let elem in buffer.evaluateXPath("*[@accesskey='" + key + "']"))
> >  >         return buffer.followLink(elem)
> >
> >
> > It don't get any elems with this. I have no clue about evaluateXPath,
> >  does it maybe only reach <a href=...> links? I am trying to reach an
> >  <input type="submit" ...> here.
> 
> "//*[@accesskey='" + key + "']"

Ok, I get the element now, but how do I "press" the button? The
buffer.followLink() does not work.


Greetings,
Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090521/10c1e377/attachment.bin>

From maglione.k at gmail.com  Thu May 21 10:59:26 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Thu, 21 May 2009 13:59:26 -0400
Subject: [Vimperator] Printable doc?
In-Reply-To: <804273223.20090521105735@mail.com>
References: <804273223.20090521105735@mail.com>
Message-ID: <20090521162743.GA32139@jg.hsd1.nj.comcast.net>

On Thu, May 21, 2009 at 10:57:35AM -0400, mchalkley at mail.com wrote:
>Is there an easy way to produce printable doc containing all of the
>Vimperator help?  There's so many things Vimperator is capable of, it
>would seem to be a big help to be able to have something that you
>could print off to read in your spare time, just so you could find new
>ways of using it...

We're big fans of saving trees. Use :hardcopy if you must.

-- 
Kris Maglione

Lisp doesn't look any deader than usual to me.
	--David Thornley


From maxauthority at vimperator.org  Fri May 22 00:55:04 2009
From: maxauthority at vimperator.org (Martin Stubenschrott)
Date: Fri, 22 May 2009 09:55:04 +0200
Subject: [Vimperator] Printable doc?
In-Reply-To: <20090521162743.GA32139@jg.hsd1.nj.comcast.net>
References: <804273223.20090521105735@mail.com>
	<20090521162743.GA32139@jg.hsd1.nj.comcast.net>
Message-ID: <aaae92100905220055i35fa453oc808cd6503da1d0b@mail.gmail.com>

> We're big fans of saving trees.

Jup

> Use :hardcopy if you must.

Right, but i think what he wants (printed or on the screen) is a
one-page-for the whole help.
This might be nice, and I thought Doug had a patch for that, but maybe
it either got bitrotten or it is/was to big/hacky.

From dougkearns at gmail.com  Fri May 22 00:59:07 2009
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 22 May 2009 17:59:07 +1000
Subject: [Vimperator] Printable doc?
In-Reply-To: <aaae92100905220055i35fa453oc808cd6503da1d0b@mail.gmail.com>
References: <804273223.20090521105735@mail.com>
	<20090521162743.GA32139@jg.hsd1.nj.comcast.net>
	<aaae92100905220055i35fa453oc808cd6503da1d0b@mail.gmail.com>
Message-ID: <644fc65e0905220059k67853c62l612e68daa93d5e96@mail.gmail.com>

On 5/22/09, Martin Stubenschrott <maxauthority at vimperator.org> wrote:
> > We're big fans of saving trees.
>
>
> Jup
>
>
>  > Use :hardcopy if you must.
>
>
> Right, but i think what he wants (printed or on the screen) is a
>  one-page-for the whole help.
>  This might be nice, and I thought Doug had a patch for that, but maybe
>  it either got bitrotten or it is/was to big/hacky.

I think I was hoping asciidoc was going away. ;-)  I'll dig it up over
the next day or so.

Doug

From mchalkley at mail.com  Fri May 22 06:17:30 2009
From: mchalkley at mail.com (mchalkley at mail.com)
Date: Fri, 22 May 2009 09:17:30 -0400
Subject: [Vimperator] Printable doc?
In-Reply-To: <aaae92100905220055i35fa453oc808cd6503da1d0b@mail.gmail.com>
References: <804273223.20090521105735@mail.com>
	<20090521162743.GA32139@jg.hsd1.nj.comcast.net>
	<aaae92100905220055i35fa453oc808cd6503da1d0b@mail.gmail.com>
Message-ID: <55871968.20090522091730@mail.com>

>> We're big fans of saving trees.

> Jup

Me, too...

>> Use :hardcopy if you must.

> Right, but i think what he wants (printed or on the screen) is a
> one-page-for the whole help.
> This might be nice, and I thought Doug had a patch for that, but maybe
> it either got bitrotten or it is/was to big/hacky.

After the remonstration re saving the ecology, ;), I went through all
the pages of help, and found that the index page is very good, and
does help quite a bit in accomplishing what I wanted.  I'm not really
sure why I hadn't used it that way before - it appears to have been
there for 3 months...

However, I'm an old guy (well, old enough that my first PC was a
Sinclair ZX-80...), and old dogs can learn new tricks (otherwise I
wouldn't be using Vimperator, would I?), but it's not often our first
choice.  Therefore, my reflex action when learning something new (and
Vimperator is still relatively new to me, even though I've been using
it for 8 months, largely due to the topic we're discussing here...) is
to reach for the book (or e-book, pdf, text file, you get the
idea...).

And, essentially, the problem I have with the help facility is this:
How am I going to know how, or even if, I can request help for a topic
I don't know is part of Vimperator's feature set?

So, you were both right: I want a summary, but I also wanted a single
doc that I could read through and know that all the high points of
Vimperator's capabilities have been touched on, so I can be sure
there's not some gem hidden away that I'm not using because I don't
know it's there.  Whether I print it or not is not the issue - I
probably would, so I can study it easily in the airport or on a plane,
but I'd look at it or search it in electronic form even more often.

Thanks very much for listening.


From witicir at gmail.com  Fri May 22 16:58:01 2009
From: witicir at gmail.com (William)
Date: Sat, 23 May 2009 09:58:01 +1000
Subject: [Vimperator] can't mapping a dash (-).
Message-ID: <20090523095032.F025.F601E90@gmail.com>

Hi, 

i'd like to 
-------------
:map - gT
------------

however, "Invalid option: -".

i do think that it is SO convenient  for me to map - to gT and map = to
gt

Anybody know how i could work around?

//thx
-- 
William <witicir at gmail.com>


From maglione.k at gmail.com  Fri May 22 19:20:34 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Fri, 22 May 2009 22:20:34 -0400
Subject: [Vimperator] can't mapping a dash (-).
In-Reply-To: <20090523095032.F025.F601E90@gmail.com>
References: <20090523095032.F025.F601E90@gmail.com>
Message-ID: <20090523022034.GB32139@jg.hsd1.nj.comcast.net>

On Sat, May 23, 2009 at 09:58:01AM +1000, William wrote:
>Hi, 
>
>i'd like to 
>-------------
>:map - gT
>------------
>
>however, "Invalid option: -".
>...
>Anybody know how i could work around?

Two options:

1) Use the latest HEAD, and :map <Minus>

2) :map -- - gT

-- 
Kris Maglione

Common sense is the collection of prejudices acquired by age 18.
	--Albert Einstein


From yozohida at gmail.com  Fri May 22 18:19:18 2009
From: yozohida at gmail.com (Yozo Hida)
Date: Fri, 22 May 2009 21:19:18 -0400
Subject: [Vimperator] can't mapping a dash (-).
References: <20090523095032.F025.F601E90@gmail.com>
Message-ID: <slrnh1ejom.3lc.yozohida@chardonnay.vinyard.ath.cx>

On 2009-05-22, William <witicir at gmail.com> wrote:
> Hi, 
>
> i'd like to 
> -------------
>:map - gT
> ------------
>
> however, "Invalid option: -".
>

Try

  :map -- - gT

-Yozo



From dougkearns at gmail.com  Sat May 23 04:51:14 2009
From: dougkearns at gmail.com (Doug Kearns)
Date: Sat, 23 May 2009 21:51:14 +1000
Subject: [Vimperator] Some JS utility functions that seem to have some
	utility
In-Reply-To: <4A00C131.5070504@vimperator.org>
References: <20090505215402.GD8688@jg.home> <4A00C131.5070504@vimperator.org>
Message-ID: <644fc65e0905230451w251bd35bt4655b5e41461b32@mail.gmail.com>

On 5/6/09, Martin Stubenschrott <stubenschrott at vimperator.org> wrote:
> On 05/05/2009 11:54 PM, Kris Maglione wrote:

<snip>

> I am not too happy with how the current class approach works (mainly
>  the difficulty to make things "private" which i am a very big proponent
>  of), but since JS2 is on its way, i will not introduce another class
>  concept which needs to be changed again to "standard" classes when
>  JS2 is finally available to addon authors. And as i said above, I really
>  do like keeping usage of non-standard methods/utilities to a bar minimum.

I think that this JS2 you're waiting for is probably never coming.  I
don't think the direction they're taking with Harmony is really what you
were hoping for?

>  > As for the utility functions, I think that most of them should
>  > probably be moved out of the util namespace. Especially ones
>  > like range, and the provided keys, values, dict, ... They just
>  > take up too much space when prefixed with ?util.?, especially
>  > when several are on one line.

I'm not too fussed either way about importing the common things.  As an
aside, I'd probably prefer we look at adding Range types etc.

> Maybe that code should be rewritten than? :) Honestly, and we already
>  had this discussion briefly, lots of this code is just not quickly/easily
>  readable by "non-hardcore-coders":
>
>  Array.slice(arguments, 1).filter(util.identity).forEach(function (src)
>
>  with util.identity being:
>
>  identity: function identity(k) k,

I don't understand what's difficult about that at all.  Perhaps it's
just a bad example?  To be honest, I think anyone "non-hardcore" enough
to be troubled by that is going to find much larger obstacles helping
with Vimperator.

>  I mean, we keep filling up the 'util' namespace with such rarely used
>  methods/concepts which no JavaScript developer has probably ever heard
>  of, instead of using "util" for what it was originally meant - for
>  providing *high-level* convenience functions like stringToUrlArray().

Well they're no longer rarely used.  They're certainly frequently used
in new code.  And are slowly making their way into older code as it's
refactored.  I'm probably not doing enough of that myself because I know
you're not so keen and you broke me long ago. ;-)

They're being dumped in util because we're somewhat hamstrung by the
environment.  E.g. not being able to enhance the existing types.

>  > As the names provided will be
>  > familiar to most Python programmers, and Python generally seems
>  > to be the New Hotness, I don't think that many programmers will
>  > be confused by them.
>
>
>
> Aehm, isn't ruby the New Hotness? :)

I thought that was Haskell?

>  Anyway, I do not really like the python way of thinking and having
>  many "top level" methods, i prefer the "everything is an object" way
>  of thinking like [1, 2, 3].each(...).
>
>  Anyway, I don't even want to make JavaScript Python, nor do I want to

It would seem that others disagree:

"By standing on Python's shoulders we reuse developer knowledge as well
as design and implementation experience." - Brendan Eich [1]

I wasn't being sarcastic about using Python.  If I feel bored one
weekend I might try porting a subset of Vimperator.

>  make it Ruby (although i really like Ruby). I want it still to feel
>  like JavaScript. Therefore the best would be to just extend
>  Array.prototype.uniq = ... so we could use [1, 3, 5].uniq().sort().
>  However, this probably has some unpredictable results, if JS decides
>  to add a uniq method by default.

Well, remember we can't extend those like that because we don't own them
and need to play nicely with others.

>  Although the principle of vimperator's code should be that a developer
>  with profound knowledge of the *latest* JS standard but not much
>  knowledge of the vimperator code base can *read* the
>  code easily. This is more important than saving 2 lines of code by
>  using 5 nested method calls where 3 of them are not standard JS methods!

Again, who is this mythical developer with "profound" knowledge of JS
(only?) who can't read a function definition?  I don't see anything in
util that's particularly confusing.  I agree that it's compromised at
the moment, but I think that's what Kris is trying to address.

Using only 'standard' JS methods is a PITA because there are gaping
holes in core JS.  We're hardly alone in coming to this conclusion.
Just look at the recent proliferation of libraries available.

I think the question should be not if but how to address these
shortcomings.

>  Ok, enough of my difficult-to-follow rant for today and I hope I didn't
>  offend anybody :)

I don't really follow, no.  So, I'll just muddy the water further. :)

It seems we're at a bit of an impasse but my major concern is that we
make some sort of decision to improve the consistency of the code base.
It is not desirable, to me at least, that one can look at any block of
code and know with good certainty who wrote it, and when.

Doug

[1] http://weblogs.mozillazine.org/roadmap/archives/2006/02/js_and_python_news.html

From chousuke at gmail.com  Sun May 24 11:51:33 2009
From: chousuke at gmail.com (Jarkko Oranen)
Date: Sun, 24 May 2009 21:51:33 +0300
Subject: [Vimperator] [PATCH] commit 0cba60ee breaks vimperator
Message-ID: <8B0EC6FF-B1A6-4DF2-8A88-05C0F514BB56@gmail.com>

Hi.

Commit 0cba60ee7210069b4b3884c59c5d9ea4e5d7c3ef seems to break  
vimperator.
I investigated a bit and it seems that removing the null check for  
config.modes is mistaken,

The code is run when load("modes.js") is called in liberator-overlay,  
at which point the config object isn't properly initialised yet.

The attached patch initialises the config object earlier and fixes  
vimperator.

--
Jarkko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Initialise-base-config-earlier.patch
Type: application/octet-stream
Size: 1055 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090524/cb8de6c6/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090524/cb8de6c6/attachment.bin>

From maglione.k at gmail.com  Mon May 25 08:49:15 2009
From: maglione.k at gmail.com (Kris Maglione)
Date: Mon, 25 May 2009 11:49:15 -0400
Subject: [Vimperator] [PATCH] commit 0cba60ee breaks vimperator
In-Reply-To: <8B0EC6FF-B1A6-4DF2-8A88-05C0F514BB56@gmail.com>
References: <8B0EC6FF-B1A6-4DF2-8A88-05C0F514BB56@gmail.com>
Message-ID: <20090525154915.GA12110@jg.domain_not_set.invalid>

On Sun, May 24, 2009 at 09:51:33PM +0300, Jarkko Oranen wrote:
> Commit 0cba60ee7210069b4b3884c59c5d9ea4e5d7c3ef seems to break  
> vimperator.
> I investigated a bit and it seems that removing the null check for  
> config.modes is mistaken,
>
> The code is run when load("modes.js") is called in liberator-overlay, at 
> which point the config object isn't properly initialised yet.
>
> The attached patch initialises the config object earlier and fixes  
> vimperator.

Wow, your patch is almost identical to my fix. I'm impressed.

-- 
Kris Maglione

Haskell is faster than C++, more concise than Perl, more regular than
Python, more flexible than Ruby, more typeful than C#, more robust
than Java, and has absolutely nothing in common with PHP.
	--Autrijus Tang


From maxauthority at vimperator.org  Mon May 25 10:52:09 2009
From: maxauthority at vimperator.org (Martin Stubenschrott)
Date: Mon, 25 May 2009 19:52:09 +0200
Subject: [Vimperator] [PATCH] commit 0cba60ee breaks vimperator
In-Reply-To: <20090525154915.GA12110@jg.domain_not_set.invalid>
References: <8B0EC6FF-B1A6-4DF2-8A88-05C0F514BB56@gmail.com>
	<20090525154915.GA12110@jg.domain_not_set.invalid>
Message-ID: <aaae92100905251052ob3e2ea5y2606164d10067aaf@mail.gmail.com>

On Mon, May 25, 2009 at 5:49 PM, Kris Maglione <maglione.k at gmail.com> wrote:
> Wow, your patch is almost identical to my fix. I'm impressed.

and it's certainly very hard to impress Kris, therefore well done,
Jarkko. Thanks.

And you seem to know Vimperator's code base quite well, so looking
forward for more nice patches :)

--
Martin

From chousuke at gmail.com  Mon May 25 11:56:19 2009
From: chousuke at gmail.com (Jarkko Oranen)
Date: Mon, 25 May 2009 21:56:19 +0300
Subject: [Vimperator] [PATCH] commit 0cba60ee breaks vimperator
In-Reply-To: <aaae92100905251052ob3e2ea5y2606164d10067aaf@mail.gmail.com>
References: <8B0EC6FF-B1A6-4DF2-8A88-05C0F514BB56@gmail.com>
	<20090525154915.GA12110@jg.domain_not_set.invalid>
	<aaae92100905251052ob3e2ea5y2606164d10067aaf@mail.gmail.com>
Message-ID: <5214F02D-7519-4FE5-B326-00D81D101177@gmail.com>

On 25 May 2009, at 20:52, Martin Stubenschrott wrote:

> On Mon, May 25, 2009 at 5:49 PM, Kris Maglione  
> <maglione.k at gmail.com> wrote:
>> Wow, your patch is almost identical to my fix. I'm impressed.
>
> and it's certainly very hard to impress Kris, therefore well done,
> Jarkko. Thanks.
>
> And you seem to know Vimperator's code base quite well, so looking
> forward for more nice patches :)

Don't expect too much. Most of the code is still a mystery to me.  
Also, I know next to nothing of the Firefox extension API, so I can  
only contribute "generic" fixes for now.

I'll try to fix stuff if it affects my daily use of vimperator, but at  
the moment everything seems to be
working fine. However, please don't break stuff just to get me to  
contribute. :p

--
Jarkko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://www.mozdev.org/pipermail/vimperator/attachments/20090525/1915c24d/attachment.bin>

From maxauthority at vimperator.org  Tue May 26 03:45:22 2009
From: maxauthority at vimperator.org (Martin Stubenschrott)
Date: Tue, 26 May 2009 12:45:22 +0200
Subject: [Vimperator] Some JS utility functions that seem to have some
	utility
In-Reply-To: <644fc65e0905230451w251bd35bt4655b5e41461b32@mail.gmail.com>
References: <20090505215402.GD8688@jg.home> <4A00C131.5070504@vimperator.org>
	<644fc65e0905230451w251bd35bt4655b5e41461b32@mail.gmail.com>
Message-ID: <aaae92100905260345p485f5f0jc07429c056a70fa9@mail.gmail.com>

On Sat, May 23, 2009 at 1:51 PM, Doug Kearns <dougkearns at gmail.com> wrote:
> I think that this JS2 you're waiting for is probably never coming. ?I
> don't think the direction they're taking with Harmony is really what you
> were hoping for?

It's not as good, but probably good enough and if i am not wrong, they at least
support "real" classes which I am fond of.

> I'm not too fussed either way about importing the common things. ?As an
> aside, I'd probably prefer we look at adding Range types etc.

Range types? for what?

>> Maybe that code should be rewritten than? :) Honestly, and we already
>> ?had this discussion briefly, lots of this code is just not quickly/easily
>> ?readable by "non-hardcore-coders":
>>
>> ?Array.slice(arguments, 1).filter(util.identity).forEach(function (src)
>>
>> ?with util.identity being:
>>
>> ?identity: function identity(k) k,
>
> I don't understand what's difficult about that at all. ?Perhaps it's
> just a bad example? ?To be honest, I think anyone "non-hardcore" enough
> to be troubled by that is going to find much larger obstacles helping
> with Vimperator.

I still don't fully know what that code does, I *think* that
.filter(util.identity)
just drops all elements of the array which are "false"? For me (and probably
lots of others), probably this code would be much more readable without
severe thinking:

Array.slice(arguments, 1).forEach(function (src) {
if (src)
...
})

and we would also keep the util. namespace small while making the
actual code more readable (for non-Kris people ;)).

>> ?I mean, we keep filling up the 'util' namespace with such rarely used
>> ?methods/concepts which no JavaScript developer has probably ever heard
>> ?of, instead of using "util" for what it was originally meant - for
>> ?providing *high-level* convenience functions like stringToUrlArray().
>
> Well they're no longer rarely used. ?They're certainly frequently used
> in new code.

Which I am not a big fan of, as it often makes the code really hard to
understand
when just browing through the code base.

> They're being dumped in util because we're somewhat hamstrung by the
> environment. ?E.g. not being able to enhance the existing types.

That's not true. Javascript is one of the few languages which at least
allow to extend basic types. We could also just do:

if (typeof Array.prototype.uniq == "undefined")
Array.prototype.uniq = ...

Of course this had other problems, but given a 'uniq' method, that should
always do the same, no matter if we implement it, or if it ever becomes
default in Mozilla (at which time we *could* just remove our uniq method
and raise the minimum version where vimp runs).

>> Aehm, isn't ruby the New Hotness? :)
>
> I thought that was Haskell?

Probably. At least lots of this "new" code reads very functional-language
inspired.


> Again, who is this mythical developer with "profound" knowledge of JS
> (only?) who can't read a function definition? ?I don't see anything in
> util that's particularly confusing. ?I agree that it's compromised at
> the moment, but I think that's what Kris is trying to address.

The thing is, the developer shouldn't have to read util.js source
everytime he wants to hack on a module. He should be able to
understand the code just when reading it at a normal speed.
Often it's better to write 3 more lines instead of squeezing it
into a one-liner with 3 references to util. where the developer
has to flip back and forth between the actual code and util.js

> Using only 'standard' JS methods is a PITA because there are gaping
> holes in core JS. ?We're hardly alone in coming to this conclusion.
> Just look at the recent proliferation of libraries available.

JS 'standard' methods keep getting better and better. Every release
gives us quite a few goodies on Arrays/Strings etc. and I am happy to
use them. For me, waiting for even more built-in methods is much better
than add hacks in our own "util" namepace which might become obsolete
in a year or two anyway.

> It seems we're at a bit of an impasse but my major concern is that we
> make some sort of decision to improve the consistency of the code base.
> It is not desirable, to me at least, that one can look at any block of
> code and know with good certainty who wrote it, and when.

Right, therefore sticking with a rather simple-to-read and simple-to-write
style is probably prefered. Not that we always agree, but I think my and
yours (Doug) coding style is much more consistent. And even when I
look at recent commits from you, i hardly see any fancy chaining of
util methods but still simple code (which is good). So you seem to promote
usage of a "complex/big" helper class while not really using it much yourself?

--
Martin

From dougkearns at gmail.com  Thu May 28 08:45:32 2009
From: dougkearns at gmail.com (Doug Kearns)
Date: Fri, 29 May 2009 01:45:32 +1000
Subject: [Vimperator] Some JS utility functions that seem to have some
	utility
In-Reply-To: <aaae92100905260345p485f5f0jc07429c056a70fa9@mail.gmail.com>
References: <20090505215402.GD8688@jg.home> <4A00C131.5070504@vimperator.org>
	<644fc65e0905230451w251bd35bt4655b5e41461b32@mail.gmail.com>
	<aaae92100905260345p485f5f0jc07429c056a70fa9@mail.gmail.com>
Message-ID: <644fc65e0905280845k6f0e6202rbd244ac60f6f4ca8@mail.gmail.com>

On 5/26/09, Martin Stubenschrott <maxauthority at vimperator.org> wrote:
> On Sat, May 23, 2009 at 1:51 PM, Doug Kearns <dougkearns at gmail.com> wrote:

<snip>

> Range types? for what?

Err, ranges or intervals. ;-)  It was just an example as we already have
a range generator in util that was mentioned.

<snip>

> I still don't fully know what that code does, I *think* that
>  .filter(util.identity)
>  just drops all elements of the array which are "false"? For me (and probably
>  lots of others), probably this code would be much more readable without
>  severe thinking:
>
>  Array.slice(arguments, 1).forEach(function (src) {
>  if (src)
>  ...
>  })
>
>  and we would also keep the util. namespace small while making the
>  actual code more readable (for non-Kris people ;)).

Well the identity function is just basic maths, for some arbitrary
definition of basic I guess.  Perhaps it is a little 'Lisp-refugeeish',
I don't know.  Although, Python's map() even defaults to using this
implicitly and I think there's a PEP for adding identity() and if that
happens it can only be a matter of time before it finds its way into
JS. ;-)

I just don't think this specific example is an issue either way really.

>  >>  I mean, we keep filling up the 'util' namespace with such rarely used
>  >>  methods/concepts which no JavaScript developer has probably ever heard
>  >>  of, instead of using "util" for what it was originally meant - for
>  >>  providing *high-level* convenience functions like stringToUrlArray().

That is the worst example of what should go into util.  It has almost no
utility whatsoever. :)

>  > Well they're no longer rarely used.  They're certainly frequently used
>  > in new code.
>
>
> Which I am not a big fan of, as it often makes the code really hard to
> understand when just browing through the code base.

We're going round in circles but I don't find that to be the case.  I
think that most of util makes the code much easier to read.  Though, as
I mentioned before, it's pretty half-baked at the moment and I'd like to
go much further.

>  > They're being dumped in util because we're somewhat hamstrung by the
>  > environment.  E.g. not being able to enhance the existing types.
>
>
> That's not true. Javascript is one of the few languages which at least
>  allow to extend basic types.

I haven't had a recent lobotomy but thanks for asking. ;-)

>  We could also just do:
>  if (typeof Array.prototype.uniq == "undefined")
>  Array.prototype.uniq = ...

So use some other random extension author's implementation then?
Cool! :)

>  Of course this had other problems, but given a 'uniq' method, that should
>  always do the same, no matter if we implement it, or if it ever becomes
>  default in Mozilla (at which time we *could* just remove our uniq method
>  and raise the minimum version where vimp runs).

My point was that we can't extend the core objects because they are
shared.  I know a lot of other extensions do such things but they're
rubbish and we went to some trouble to not do so in the past so I'm not
sure why you're advocating it now.  Maybe the AMO review process checks
for this sort of thing now but I'm not sure.

We're still good little Mozilla-land citizens aren't we?

>  >> Aehm, isn't ruby the New Hotness? :)
>  >
>  > I thought that was Haskell?
>
> Probably. At least lots of this "new" code reads very functional-language
>  inspired.

Which is really what JavaScript wants to be so it's only natural.

>  > Again, who is this mythical developer with "profound" knowledge of JS
>  > (only?) who can't read a function definition?  I don't see anything in
>  > util that's particularly confusing.  I agree that it's compromised at
>  > the moment, but I think that's what Kris is trying to address.
>
>
> The thing is, the developer shouldn't have to read util.js source
>  everytime he wants to hack on a module. He should be able to
>  understand the code just when reading it at a normal speed.
>  Often it's better to write 3 more lines instead of squeezing it
>  into a one-liner with 3 references to util. where the developer
>  has to flip back and forth between the actual code and util.js

He has to flip back and forth once at most surely?  If I haven't done
anything in JS for months I have to check the docs for the difference
between substring and substr because I always forget. *gasp*  Can we
avoid those too?

>  > Using only 'standard' JS methods is a PITA because there are gaping
>  > holes in core JS.  We're hardly alone in coming to this conclusion.
>  > Just look at the recent proliferation of libraries available.
>
>
> JS 'standard' methods keep getting better and better. Every release
>  gives us quite a few goodies on Arrays/Strings etc. and I am happy to
>  use them. For me, waiting for even more built-in methods is much better
>  than add hacks in our own "util" namepace which might become obsolete
>  in a year or two anyway.

A year or two?  Vimperator may be a memory by then, I'm interested in
now.  If similar built-in methods are provided in the future then
updating to use those is easy, sometimes trivial.

>  > It seems we're at a bit of an impasse but my major concern is that
>  > we  make some sort of decision to improve the consistency of
>  > the code base.  It is not desirable, to me at least, that one
>  > can look at any block of
>  > code and know with good certainty who wrote it, and when.
>
>
>  Right, therefore sticking with a rather simple-to-read and simple-to-write
>  style is probably prefered.

You keep presenting opinion as fact.  Do you have any concrete examples
of this "simple-to-read/write" style?

>  Not that we always agree, but I think my and
>  yours (Doug) coding style is much more consistent. And even when I
>  look at recent commits from you, i hardly see any fancy chaining of
>  util methods but still simple code (which is good). So you seem to
>  promote usage of a "complex/big" helper class while not really using
>  it much yourself?

No, I just try hard to blend in with the predominant style no matter
what I'm working on (for I am a saint).  Unfortunately, I no longer know
what that style is here.  Although it was always difficult to discern
which is why it was dubbed "maxauthority style" in the past rather than
"simple-to-read/write style" because it seemed to be completely
arbitrary to me. :P

FWIW, if I had had free rein you'd probably be much more disapproving
than you are now. ;-)

I'm not sure why this issue is cropping up now rather than 6 months ago.
The code has been heading down this path for at least that long.

Doug