edit grid: issues involving marking, selecting, inserting, undoing

Hi developers! Hi Dave!

Testing RC2. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4.

I think I have found more issues in the edit grid, which have some
potential to damage things.
Sorry to bring this up so close to release. I did not find it any
earlier. Anyway, it is up to you what you fix, what you postpone and
what you reject.

Definition:
I use the term "marked" for the field with the bold frame, which is
edited when you start typing.
I use the term "selected" for the field or range that is being highlighted.

In the edit grid try the following:
Copy a string.
Mark a field of an existing tuple. Only mark it, do not click a second
time to get into edit mode.
Press <ctrl><v>.
Popup warns me (my primary key is a serial field):
"This table contains serial columns. Do you want to use the values
in the clipboard for these columns?"
Say YES.
!! I wouldn't actually say YES, but if there was no sequence involved,
we would not even get a warning.
A NEW tuple is inserted at the end and the value is copied to the first
field.
!! <esc> does not help, "undo" button stays inactive. Looks like I am
trapped.
Actually, "undo" gets activated after I have entered edit mode in the
field with the value in the newly inserted row. And I can get rid of the
new row by pressing "undo".
The "undo" feature even works _without_ entering the new field. Even
though the button is inactive, <ctrl><z> will fire.
!!! BUT if you do this, the "current" row (where the field is marked)
gets deleted. (Or so it seems.) And this row has gone for good. No
undoing the buggy "undo" ...
(Actually, a reload shows that the row is still there, so the last part
seems to be a display issue.)
I think you get the idea ..

Several issues are involved:

# I think it is misleading to start a new tuple, while a field of an
existing tuple is marked and I press <ctrl><v>. Rather, it should (enter
edit mode and) replace the value of the marked field.
I am not sure if pgAdmin is aware of the data structure in the
clipboard. If it is, then it might act depending on the data in this
case. If it is a record, do nothing, if it is simple data, insert it in
the marked field.
Or, if that causes problems, do nothing at all, rather.
New tuples should only be inserted if the "new" tuple is marked. (Or
more precisely, starting from the field that is being marked.)

# When a new tuple is inserted, the "undo" button should be activated.
Generally the "undo" feature is quirky:
If I edit a field, the button gets active.
If I leave the field, by clicking another field in the same row, the
button stays active and I can click any number of times on it. It stays
activated. Only the first click, however, has an effect: it reverts the
changes. Button should fall back to inactive, after the feature has "run
out of ammo".
However, if I leave the field, by pressing <tab>, thus marking the next
field in the same row, the button stays INACTIVE and clicking it has no
effect. I can still press <ctrl><z> to revert my changes, though.
Button should stay activated, regardless of _how_ I leave the field, as
long as the changes can be undone.

# Undoing the changes after inserting a new row (inadvertently or not)
should not wipe out the wrong row (the one that holds the marked field)
You might circumvent this problem if you automatically mark the (first?)
field of a newly inserted row, but this fix would only go half the way.
It would force a save if one was in the middle of editing another row.
Rather, you should insert values or records only at the position of the
marked field.

I think much arises from the management of marked fields and selected
ranges.
Try this:
Mark a field.
Select a different row.
Press <shift> and try to select a range of rows. Start of the range is
(to my surprise) defined by the _marked_ field, not the _selected_ row.

Or try this:
Mark a field.
Press <shift> and select another field, the whole area gets selected,
_including_ the marked field.
Now, start over, mark a field.
Press <ctrl> and select another field (or a number of fields). The
marked filed is _excluding_ from the selection. (Should be included.)

Maybe, the general cure for most of the above mentioned symptoms would
be to mark what you select and select what is marked (not: what you
mark!). It would make things easier to manage - or that is what I
assume, not actually knowing the code.
If you look at OOo Calc for instance, the last field selected is always
the one being marked.

Sorry for the longish report. I have gone over it several times to try
and avoid misunderstandings. After all, English is not my first language.

Regards
Erwin