[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: Interface inconsistancy



> Just noticed:  If you insert a cell by pressing insert then an arrow,
> your cursor ends up on the new cell.  But if you do it by putting the
> action cursor on one of the insert actions and pressing enter, it
> doesn't move.
>
> That's potentially confusing.  Which do we prefer?

Consider this plan:

1. You add all those little utility functions that I mentioned to you
   last week.

2. We replace the built-in key binding table with something acessible
   in Zig Zag space, perhaps something like this:

        +--> d.keybinding

        n --- # create cell

3. We replace all the built-in key functions with Zig Zag action cells.

   For example, at present, when you press `n' it invokes the function
   `cell_create(0)'.  In my replacement, it would look in the zig zag
   space for an action cell that was linked +d.keybindingward from the
   `n' cell, and then it would execute the contents of that action
   cell.  Initially this action cell would contain something like
   this:

        # create cell
        display_message("Insert cell in which direction?");
        my ($win, $dir) = input_get_direction();
        display_message("");
        # ***
        
        my $dim = axis_dimension($win, $dir); # Turn `R' into `d.2'
        my $cur_cell = get_accursed($win);
        if (linked($cur_cell, $dim)) {
          display_message("This cell is already linked in that dimension.");
          return;
        }

        my $new_cell = new_cell();
        unless (insert_cell($new_cell, $cur_cell, $dim)) {
          display_message("Mystery error #37!"); # ``Should never happen''
        }

        # Comment this out if you don't want the cursor to jump to the new cell
        jump_cursor($win, $new_cell);

        # Comment this out if you don't want to edit the new cell
        edit_cell($new_cell);

4. It's this action cell that is linked into the action menu.  Since
   the actual contents of the action cell defines what the key does,
   the meaning of the `n' key and the meaning of the cell are always
   exactly the same.  

   Of course, the user can decouple the two behaviors by relinking the
   `n' cell to some other action instead.  If you want `n' to do
   something completely different, you just link it to a different
   action cell.

5. If you only want to change the behavior of the key a little bit, 
   you can do that by editing the action cell.  For example, if you
   want the cursor to stay where it is when you create a new cell,
   instead of moving to the new cell, you just comment out the line
   that says

        # Comment this out if you don't want the cursor to jump to the new cell
        jump_cursor($win, $new_cell);

   and after that it stays where it is.

   Another example: The existing behavior of the `n' key is that if
   you type `nw' to insert a new cell above the *action* cursor,
   nothing happens; `nw' is not analogous to `ni'.  I didn't include
   that inconsistency in the cell I showed above, but if you wanted
   that feature you could just go and insert the line

        return if $win == 0;

   at the place where the *** is now.

Now let's return to your original question:

> That's potentially confusing.  Which do we prefer?

This plan lets the user choose the one that they prefer.  If they want
one behavior or the other, they can get the one they want.  If they
want inconsistent behavior, they can get that too.  If they want `n'
to invoke one behavior and `m' to invoke the other, they can also get
that.