After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 88167 - cell movement using Tab/rtn
cell movement using Tab/rtn
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.0.x
Other Linux
: Low enhancement
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 342865 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-07-14 23:29 UTC by lambert_joshua
Modified: 2007-08-22 14:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description lambert_joshua 2002-07-14 23:29:44 UTC 
Desired result:  After typing in a cell and pressing tab and repeating this
procedure x times across a row, press Return (Enter) and the highlighted
cell should be under the first cell of the tabbed series.

Current result:  Same as above except...press Return and the highlighted
cell is the one under last one typed in.

Desired result Example1:  Starting at A1, type 4.99 Tab(to B1) 5.35 Tab(to
C1) 6.99 Enter (to A2).  Cell fill and position don't matter
Desired result Example2:  B45 Tab, C45 Tab, D45 Tab, E45 Enter.  Enter
should highlight cell B46 instead of E46.

Advantage:  Fingers can stay in normal keyboard position and fill in a
large block of cells.  Home and arrow keys not needed.

This action is only realistic in consistent movement across a row using Tab
(not arrow keys or other navigational keys).
Comment 1 Andreas J. Guelzow 2002-11-08 02:43:48 UTC 
Why is this significantly better than selecting the area to be filled
and then to cycle through all cells using tab (and the right end of
the selected area the cursor will jump to the left end of the selected
area but one row below)?
Comment 2 lambert_joshua 2002-11-08 04:22:59 UTC 
I'm not sure if it is _significantly_ better.  I was not aware of the
behavior you describe but the behavior is similar.  Although, there
seem to be a couple disadvantages of the highlighting cells method. 
1. If the number of needed columns varies from one row to the next,
more keystrokes are needed when the cells are highlighted.  2. Any
movement between cells other than Tab and Shift+Tab removes
highlighting.  This also messes up the Tab sequences but only for one
row, not many, as it does when highlighting.

I still would like to see the changes made, but if I am the only one,
it must not be too important.  I'll change the Priority to "Low."
Comment 3 Andreas J. Guelzow 2003-07-06 07:06:37 UTC 
The menu change proposal (bug 116535) contains a proposal how to
handle this.
Comment 4 Andreas J. Guelzow 2003-07-06 07:07:54 UTC 
ignore my last comment (wrong bug)
Comment 5 Jody Goldberg 2006-06-06 12:34:19 UTC 
Finally thought about this a bit this morning and realized it would be 6 lines of code.  Patch will be in 1.7.1
Comment 6 Jody Goldberg 2007-08-22 14:18:04 UTC 
*** Bug 342865 has been marked as a duplicate of this bug. ***