breaking changes

[John J. Foerch]

Hi all,

  I just pushed a few new features as well as some breaking changes.
Updates to your rc may be necessary.  First the list of breaking
changes:

 * The command line switch `-uu` was renamed to `+u`.  Mozilla consumes
   `-u`, which is our first choice for this purpose.  `+u` is a more
   aesthetic alternative to `-uu`.  As a side-effect, the `+` character
   is now a synonym for `-` with all non-special command-line switches
   (everything but -q and -E).

 * The key bindings `<<` and `>>` are now simply `<` and `>` to have a more responsive UI.

 * page-mode keymaps are now declared in the `define_page_mode` form
   with a new keyword argument, `$keymaps`.  See
   http://conkeror.org/WritingPageModes for more information about the
   new style.

 * `default_directory` and `set_default_directory` have been removed and
   replaced by the variable `cwd`.  The value of cwd must be an
   nsILocalFile object.  For practical purposes, this means that setting
   cwd in your rc will now look something like this:

     cwd = make_file("/foo/bar/");

 * buffer-local variables are now indexed by `buffer.local.foo`.
   page-local variables are indexed by `buffer.page.local.foo`.  Within
   an interactive command, the top of the locality stack is referred to
   by `I.local.foo`.

 * The command `send-ret` was removed since it is redundant of the
   module `global-overlay-keymap`.  If you used it, do this instead:

     require("global-overlay-keymap.js");
     define_key_alias("C-m", "return");

 * Buffer-local cwd is no longer set or inherited automatically.  The
   following code in your rc will bring back the old behavior:

     /**
      * This bit of code is how auto-cwd and cwd-inheritance can be done.
      * Auto-cwd means that buffers created from a command-line action will
      * get their cwd set to the working directory of the command-line
      * invocation.  Cwd-inheritance means that new buffers will inherit
      * their cwd from the buffer that caused them to be created.  For
      * auto-cwd, buffer.opener will be `instanceof interactive_context'.
      * For cwd-inheritance, buffer.opener will be `instanceof buffer'.
      */
     function cwd_setup (buffer) {
         if (buffer.opener && buffer.opener.local) {
             if (buffer.opener.local.hasOwnProperty('cwd')) {
                 buffer.local.cwd = buffer.opener.local.cwd;
             }
         }
     }
     add_hook('create_buffer_hook', cwd_setup);

 * `download-cancel` is now bound to `d` instead of `C-g`, and it asks
   for confirmation.  The `d` key was chosen based on similar bindings
   in dired-mode and other modes in Emacs.  `C-g` was cited by users as
   confusing in this situation, and an additional reason for removing
   the binding is that it is not ''forward-compatible'' with our desire
   to one day have download buffers that may show more than one
   download.



  And here are the new features:


 * undefine_key: takes a keymap and a key, and unbinds that key.

 * default browser-object can now be overridden in define_key.  This
   means you can do cool things like:

     define_key(some_keymap, some_key, some_command,
                $browser_object=some_browser_object);

 * download buffer display fixed for narrow windows.

 * download-cancel prompts for confirmation.  the binding is `d'.


Thanks.  If you have any trouble updating your rc, just flag me down
by email or on our irc channel.

--
John Foerch

_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror

[Axel Beckert]

Hi,

On Fri, Jun 05, 2009 at 04:41:32PM -0400, John J Foerch wrote:
>  * The key bindings `<<` and `>>` are now simply `<` and `>` to have
>  a more responsive UI.

That sounds great. I often felt as if I had to hit ">" three times to
get the effect two times should do. I use it quite often, especially
when reading online documentation.

BTW: What about "[[" and "]]"? Don't those keybindings fall into the
same category?

                Regards, Axel
--
Axel Beckert - abe@..., abe@... - http://noone.org/abe/
_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror