Good day all,

I have been following this thread with interest and would like to add a
comment.  Before I do that I would like to caveat my post in a number of
ways. 1) I love Conkeror and really appreciate the community work here. 2) I
am not a JavaScript programmer. 3) I know very little about the internals of
Conkeror/XulRunner.

I mainly wanted to make some observations about the buffer numbers and
ordering.  It seems this thread is highlighting the tension between wanting
to have a dynamic buffer ordering (both spatial and temporal) and a static
ordering.  There are probably many pros and cons to each point-of-view. The
main reason I see for a static ordering is so that you can bind a key as a
shortcut to the static buffer position as a short-cut to that buffer.  This
strikes me a somewhat fragile. Even if the buffer ordering were static there
is still the issue of deleting the buffers thus trashing the buffer ordering
and messing up any key bindings that may have been dependent on that order.

I (humbly) propose that a better solution is one that I have been using for
about six months now.  That solution involves explicitly naming buffers and
binding keys to go to those named buffers.  For lack of imagination I have
called this "single buffer jump".  I have included the code from my
.conkerorrc file below, but in a nutshell it is pretty straightforward.  I
create a mapping between a name and buffer (with URL).  I then define some
functions that allow me to either switch to the named buffer or, if it does
not exists, open the URL in a new (named) buffer.  This has two very nice
properties. 1) I can bind keys to the named buffer, and 2) I do not have to
worry whether or not I have a named buffer open already, if it is open I go
there otherwise I create it.

This has been working nicely for me.  Maybe others will find it useful

Sincerely,
-Tim Ramsey

var single_buffer_map = {};

// Add the key and url to the single_buffer_map
// Define an interactive function that will go to the named buffer
function define_single_jump(name, url) {
    interactive("sj-"+name, "Go to "+name,
            function(I) {
                single_buffer_goto(I, name);
            }
           );
    single_buffer_map[name] = {
        key: name,
        buffer: null,
        url: url
    };
};


// the workhorse of single buffer functionality.
// Takes the name of the buffer (as defined in define_single_jump) and
either
// goes to the buffer if it exists or creates a new buffer visiting the
// correct URL and goes to it
function single_buffer_goto(I, bname) {
    var map = single_buffer_map[bname]
    var buff = map.buffer
    var win = I.window
    if (buff == null || buff.dead) {
        buff = new content_buffer(win, $opener = win.buffers.current)
        win.buffers.current = buff;
        map.buffer = buff;
        apply_load_spec(buff, load_spec(map.url));
    } else {
        switch_to_buffer(win, buff);
    }

}


// Convenience interactive function to prompt for a single buffer to go to
// and goes there.
interactive('single-buffer-goto', 'Either start up a new page or use the old
one',
            function (I) {
                var base_completer = prefix_completer(
                    $completions = [ v for ([k,v] in
Iterator(single_buffer_map)) ],
                    $get_string = function (x) { return x.key; },
                    $get_description = function (x) { return x.url; });
                single_buffer_goto(I, (yield I.minibuffer.read($prompt =
"Jump:", $completer = base_completer)));
            });


define_key(content_buffer_normal_keymap, "C-j", "single-buffer-goto");
define_single_jump('mail', 'http://mail.google.com');
define_key(content_buffer_normal_keymap, "f1", "sj-mail");


On Sun, May 15, 2011 at 4:18 PM, John J. Foerch <[email protected]>wrote:

> On Sat, May 14, 2011 at 02:40:51PM -0400, John J. Foerch wrote:
> >  * When you open an url or a webjump in a new buffer, the new buffer
> opens
> >    at the front of the list. (on the left side, in terms of tabs)
> >
> >  * When you follow a link or other DOM object in a new buffer, the buffer
> >    containing that link or object is called the "opener", and the new
> >    buffer is created to the immediate right of its opener.
>
>
> My thinking is changing about the first point above.  Now I am thinking
> maybe the behavior should be made configurable, but the default not
> changed.  What we would do is introduce a pair of user variables, one for
> buffers without an opener, and one for buffers with, that give the
> position at which to create them.  The allowed values would be: 'left',
> 'right', 'end', or an integer.
>
> The values 'left' and 'right' would mean immediately before or after the
> opener or current buffer.  The value 'end' would mean at the end of the
> list.  An integer value would give an explicit index, 0 indicating the
> front of the list.
>
> The second point above seems uncontroversial, and has even been requested
> by several people, so that could be made default.
>
> What to do about bury-buffer is something I want to think more about.
> It's a logical extension of a temporally-organized UI, but not so much of
> a spacially-organized one.
>
> --
> John Foerch
> _______________________________________________
> Conkeror mailing list
> [email protected]
> https://www.mozdev.org/mailman/listinfo/conkeror
>
_______________________________________________
Conkeror mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/conkeror

Reply via email to