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 699631 - Go to First does not jump to first cell in row
Go to First does not jump to first cell in row
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2013-05-03 20:51 UTC by Adam Dingle
Modified: 2013-05-06 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Dingle 2013-05-03 20:51:33 UTC
To see the problem:

1. Start Gnumeric.
2. Enter the values 123, "abc" and "def" in cells A1, B1 and C1 respectively.
3. With the cursor in C1, choose Edit->Select->Go to First.

The cursor will jump to B1.  It should jump to A1, the first cell in the row, right?  Or am I missing something here?
Comment 1 Andreas J. Guelzow 2013-05-05 16:36:15 UTC
It is not supposed to jump to the first cell in the row but to the first cell of the data block in this row, (or the last cell of the previous data block if one is already at the first cell). Choosing go to first again should move you to A1.
Comment 2 Adam Dingle 2013-05-05 16:43:10 UTC
I'm not sure what you mean by "data block" - a set of cells that contain similar data?  It doesn't seem to matter what I put in the cells - if I enter 123, 456 and 789 then Go to First still jumps to B1.  If I run Go to First again, the cursor stays at B1.
Comment 3 Andreas J. Guelzow 2013-05-06 02:03:12 UTC
A data block inthis context is a set of cells that contain similar data. You are right that something is wrong here. I was primarily looking at your expectation of 'first cell in row'. That is not expected, but it should jmp to the first cell in the block. (I though that using the command a second time moves further to the left but apparently I was mistaken on that.) You can see the correct behavious by using cells C3,D3,E3 rather than A1,B1,C1. There is something wrong in the case that the first column is involved.
Comment 4 Andreas J. Guelzow 2013-05-06 02:11:47 UTC
I have created a bug #699737 report to collect all the "please provide a keyboard shortcut for my favourite command" enhancement requests.

They could all be simultaneously solved by having editable short cuts.

*** This bug has been marked as a duplicate of bug 699737 ***
Comment 5 Andreas J. Guelzow 2013-05-06 02:13:32 UTC
please ignore the comment #4, I attached it to the wrong bug report.
Comment 6 Andreas J. Guelzow 2013-05-06 06:06:52 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 7 Adam Dingle 2013-05-06 10:12:28 UTC
Great - thanks!