[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Interface inconsistancy
- To: zzdev@xxxxxxxxxx
- Subject: Re: Interface inconsistancy
- From: Mark-Jason Dominus <mjd@xxxxxxxxxx>
- Date: Sun, 15 Nov 1998 10:57:46 -0500
- Cc: mjd@xxxxxxxxxx
- In-reply-to: Your message of "Sun, 15 Nov 1998 18:51:15 +1100." <19981115185115.E569@xxxxxxxxxxxxxx>
- Reply-to: zzdev@xxxxxxxxxx
> 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.