[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Doug Kearns]

On 5/24/07, Martin Stubenschrott <stubenschrott at gmx.net> wrote:
> On Thu, May 24, 2007 at 07:37:09PM +1000, Doug Kearns wrote:

<snip>

> > It seems to me now that you wish to conflate these?
>
> Actually right now I think, having a high-level API which support
> "advanced" features like "overloading" with convenient functions makes
> sense, and the ex commands just calling them with the right parameters
> and doing the error reporting.

I think you just described the vimperator.ex.* commands? ;-)

Seriously, what functionality is this high-level API you describe
introducing that's not available via the ex-commands?   There may be
the odd thing but I don't think at this stage it's vital.  If it's
really important let's add a new ex-command or extend the
functionality of an existing one.

I don't use tabs in Vim but its tab commands appear pretty limited -
probably because it's a new feature and one hardly anyone who
understands buffers bothers using.  I was thinking of adding a
:tabalt[ernate] (maybe with a better name) mapped to Ctrl-^ for
bouncing between two tabs, as an example.

I really don't think having to change to a tab before deleting it in a
user script/command is too onerous.  At least for now...

Adding a whole new level of abstraction just so a user can do:

v.tabs.keepOnly('+2')

instead of:

v.ex.tabmove('+2')
v.ex.tabonly()

doesn't make any sense to me.

I guess we could even add the "$" arg to the tabmove ex-command if you
felt it was clearer than having no arg take you to the last postion
which is how Vim does it.  I don't know what your position on
compatiblity with Vim's commands is but I don't see it as a problem if
Vimperator offers a superset of its functionality.

> If the vimperator.tabs. API just accepts
> indices, it will really just be a wrapper to the firefox commands.

Yes largely, but we're using a bad example with tabs because the
TabBrowser API is pretty complete. All I think that's really needed is
a thin wrapper that shields you from changes to TabBrowser, adds
convenience methods, and provides the missing functionality which is
important in the context of Vimperator but not available in TabBrowser
like the ability to reload all tabs bypassing the cache etc.

However, a complete low-level API would also need to provide a similar
interface to Vimperator only functionality like the unique bookmarking
system, command-line history, and dialog system which is really the
interesting part.

<snip>

> > Well that would more likely be: v.tabs.move(v.tabs.current + 1) or
> > similar.
>
> In fact it would be:
> vimperator.tabs.move(vimperator.tabs.current(), vimperator.tabs.current() + 1);

Touche! ;-)  But, to be honest, I think the whole interface is wrong
at this level and v.tabs should really just be manipulated through a
standard list interface...

> > > E.g. the user can do a:
> > > vimperator.tabs.removeAllOthers("$"); to remove all but the last tab.
> >
> > Show that to someone and ask them what it does - then show them
> > v.tabs.removeAllOthers(v.tabs.last) or even
> > v.tabs.keepOnly(v.tabs.last).
>
> The user would have to read the API docs anyway to use these functions,

To use them, yes, but not to read them (or modify them) - 50% less
effort already. ;-)

I've found FF extension development to be largely trivial to pick up
exactly because it is so easy to read without any documentation.  I
only recently took a look at the XUL docs for the first time to figure
out what values -moz-user-select accepted. :)

<snip>

> But the more I talk about the API, the more I see how difficult it is to
> design a good one :( That's why I did not answer all your questions,
> just because I don't know an answer to most of them :( And I am really
> 50:50 for your and for my proposal as I think, both have advantages.
>
> So the question is, how do we continue from here, I really would like
> the api to be kinda fixed before 0.5 is released.

To be honest I think worrying about a low-level API as I described
above is extremely premature and simply something to keep in mind
whilst we improve the existing architecture.  I also think you're
proposed high level API is really just the ex commands by another
name.

So, IMHO, I think the best way forward is to make sure we have as much
ex command coverage as possible and to make this available as the only
API.  If users want to do something more sophisticated than is
available via the ex commands then they can dig around in browser.jar
like the rest of us. ;-)  I think it's infinitely more important that
we have things like quality suport for :map and :command.

So I guess, in short, I think we're kind of going about this the wrong
way. No offense intended. ;-)

Regards,
Doug

PS.  Do any other foks out there have any thoughts on this or are we
just muttering amongst ourselves? :-)