This is a request to bring back end-of-range selection as being relative to the current selection-corner cell.
EDITING: Undesired Behavior Change in 3.5b2 when Extending a Selection in Calc
not picked up.
EDITING , trouble selecting cells with keyboard in calc
not picked up.
EDITING: shift-arrow key does not move selected cell
Explained as not being a bug and pointing out that other spreadsheet applications exhibit the same current behavior.
shift-ctrl-down/up/left/right keystroke changed its behavior
Explained as not being a bug and pointing out that the old behavior was actually a bug, and that this could not be made configurable as it would create a maintenance nightmare.
UI: Certain cursor move and range selection keyboard shortcuts do not work when entering formulae
Asked for submitter to re-test in newer release, not updated.
I am making this feature request to ask that this behavior / lack of behavior toggle be reconsidered. While I understand that the old behavior may be considered a bug, it was a most useful bug.
Consider, if you will, the following scenario:
Fill cells A100 through A300 with data.
Fill cells AZ1 through AZ1000 with data.
Move to cell AZ100.
Use shift+ctrl+left to select A100 through AZ100.
( The AZ column should now be well out of view. )
Now use shift+ctrl+down to extend the selection down.
With the new behavior, you will now have a selection from A100 through AZ1000. The screen is filled with empty cells, and there's no obvious reason as to why this is the selection range - the reason is that the selection is extended from the originating cell.
With the old behavior, you will now have a selection from A100 through AZ300, with the last cell from the data range in the A column clearly selected - the selection having been extended down from cell A100, the 'selection corner' cell.
You may ask what to do if the user actually wants the new behavior. But this is not an issue with the old method, since the steps are simply swapped:
Move to cell AZ100.
Use shift+ctrl+down to extend the selection down (you now have selection AZ100 through AZ1000).
Use shift+ctrl+left to extend the selection to the left. You now have selection A100 through AZ1000. The reason for it being on row 1000 is now also obvious, because that's the cell row you extended to the left from.
Unfortunately, with the new behavior, there is no "just swap the steps" work-around.
Note that this is also merely a single-step of such a selection. Assume that cell A200 is actually empty. With the old method the initial selection would be A100 through AZ199. Extending it down further to include A201 through AZ300 requires no more than two more shift+ctrl+down key presses.
If you then realize that not all rows are complete - row B only goes down to a mystery row (not visible on screen), it's also not a problem. Shift+right, followed by shift+ctrl+up will bring the selection right up to that last cell, and a shift+left extends the selection to include the A column again. With the new behavior, on the other hand, using shift+ctrl+up will make the selection match B1 through AZ100. Pressing shift+ctrl+down in the hopes of getting back to where you were will make the selection match B100 through AZ1000.
I understand that some users will be used to how Excel, Gnumeric and Google Docs handle this, and be confused when confronted with the old behavior (despite it being the old behavior for many users coming from OO.o, which still exhibits this behavior).
However, familiarity with a - to me, and those in the bug reports - strange behavior does not make for a particularly compelling argument for changing to that behavior and essentially making shift+ctrl+cursor selections far less functional than they had been, as opposed to users learning that the new behavior is in fact more powerful.
In addition, and this argument has been put forth before but bears repeating, it makes shift+ctrl+cursor behavior differ entirely from ctrl+cursor behavior.
I won't pretend to know how much maintenance would actually be required by offering a user-configurable switch of behaviors - but given that ctrl+cursor does exactly what is being asked for of shirt+ctrl+cursor except that it doesn't create a selection based on the two corners, it seems to me like the more complex part is done.
( I did try my hand at writing a macro that relies on the above, but am currently stuck trying to find out how to set the cell pointer, as after setting the selection the cell pointer is moved to the top-left corner of the selection. )
Thank you for your consideration.
I will confirm what you are saying. But it is NOT an "enhancement".
You mentioned Excel and Gnumeric. I just tried Gnumeric. It is true that Gnumeric does not move the active cell indicator with Shift-arrow or Shift-Control-arrow. However, Gnumeric is also not *broken* when selecting ranges that way. LibreOffice is now *broken* and this can be seen in Bug 61534.
So it looks like someone decided to change LibreOffice calc to act like Excel and Gnumeric when using ranges (Shift-arrow) and proceeded to break it when using Shift-Control-Arrow because they didn't test it properly and realize that other code would have to be changed too.
This is a severe regression bug. I can understand wanting to have the choice of old or new behavior for how the active cell moves or doesn't move, but it breaking proper Shift-Control-arrow behavior is a bug and needs to be fixed ASAP.
I kind of suspected this regression(yes, it's a regression) was intentional, but couldn't find the reports to back it up. Thanks for putting together the list of references, panoworks.
This decision appears to be quite political. It forces me to question the ultimate goals of LibreOffice. We're taking a huge step back in spreadsheet navigation for the sake of imitating an inferior design. I haven't seen a single argument that claims that the new behavior is superior to the previous in terms of functionality. It's purely done for the sake of cloning the current standard. Writer also does a lot of other things better than Word. Should we throw away those advantages too, for the sake of following the “standard.” Where does it stop?
I would also argue the validity of this behavior as "standard." I can confirm that crxssi is right, Gnumeric handles select to block margin properly. I'll also add the current OpenOffice and Calligra Sheets to the list of spreadsheet apps that handle it properly.
Google Docs displays the same broken behavior as LO, and I don't yet have a way to test this behavior against MS Excel.
Since the decision on default behavior seems to have already been made, I would LOVE to be able to toggle the old behavior. I understand that it might not be trivial to implement, but I don't think most people appreciate how much functionality is lost when working with large spreadsheets.
Getting around with the new behavior typically involves breaking up my workflow into a number of separate actions or just plain doing it manually. I know many examples have been provided, but here's mine!
Challenge: Simply select a range of cells in a completely empty/ filled column, parallel to a column containing a large data range. Also, let this data range be in the middle of the spreadsheet so you can't cheat and use the top of the spreadsheet as a stopping point.
1. Create a blank spreadsheet
2. Paste the number “1” in the range A1000:A2000
3. Try to only select the cells Z1000:Z2000 without overwriting any cells in columns A or Z.
1. start in cell Z1000
2. shift-left until column A
3. ctrl-shift-down (select to bottom of A column's data block)
4. shift-right until back to column Z
I can't think of a way to do this without cheating and selecting the range manually or overwriting cells.
Can anyone else give a solution using simple keyboard shortcuts? As far as I know, an action that was trivial before can no longer be done with the current implementation.
*** This bug has been marked as a duplicate of bug 37230 ***