Some smaller notes

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Hi everyone!

Sorry about the delay -- I haven't been able to connect to the net till
yesterday. First, let me point out a bug (on the Mac platform; can't
test it on others at the moment).

It's keymaps again: On the German keymap, y and z are reversed. gZZ has
a strange behaviour about this: y rotates the y-axis, but Alt-Y rotates
the z-axis, or more accurately: invokes the Alt-Z key binding, which
rotates. I suppose that's because gZZ does internal translation only
when control keys are pressed, and lets Java do translation otherwise.
Anyway, it's something to be fixed. (It wouldn't be as bad if y would
invoke z during navigation, but then, this mustn't happen in text
editing mode!)

An almost-bug is that the default height of the windows is 700. It's
straightforward to make a window *bigger* if you want it, but if you
want to make a window *smaller* and the part of the window you do that
with is outside the screen area, you're lost (at least if you are a
novice user of a platform, like me, who doesn't know the magic ways to
do it anyway). To use the 0726 snapshot, I had to understand the code of
ZZWindows first, to know that I had to insert d.bounds to the dimension
list, and rotate to it with the cursor on the window's cell -- not a
recommended user interface. ;)

And... the width of the billowing text should be the width of the window
the text is rastered into. That would make *much* more sense. (Also,
up/down keys for last line/next line should be easy to implement: take
the x coordinate of the current insertion cursor, use an y coordinate in
the line above, and use the same code you'd use to translate a user's
mouse click to a position in the text.)

Here are some suggestions, which you can as well see as questions: is
something like this implemented or planned yet, and where can I find out
about it? And everything which isn't is a suggestion. :) They are
requests for primitive operations, which should be really
straight-forward: fetch cursor, and go to headcell. I've done
implementations of both, but as I'm not really familiar with gZZ coding
style yet (and not with diff, either -- I don't even have it here), it's
probably easier for you to implement them from scratch than to use my
code. 

Fetch cursor (FETCH and CFETCH?) positions one view's cursor on the same
cell as the other one's. This is helpful when you haven't used the
Control view for some time, and want to use it for the '/' connecting op
now -- you want to 'fetch' it from the distant point in the structure
where it currently is. I use '<' and '>' as keys (< to fetch the control
view, and > to fetch the data view; this is handy on the German keymap,
where < is a non-shift key, as you need to fetch the control view more often).

Go to headcell (HEAD and CHEAD?) takes a direction as argument and
positions a view's cursor on the headcell in that direction. So, you
could either have a binding like Alt-Up to go up to the headcell on Y-,
or a headcell key like ö (probably nothing for US keyboards, but I'm not
aware which US keys still are free :)), which is followed by a cursor
key and then does the same (similar to the new cell, clone etc. ops
which take a cursor key as argument). Go to headcell is very helpful in
navigating lists, long or short; I use gZZ to take notes in an (almost)
corner list structure, and go to headcell is great when I want to go
multiple levels up fastly.

Hope you can use this,
- Benja