Summary: | EDITING - allow end-of-range selection relative to selection-corner cell | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | panoworks |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | CC: | crxssi, tmacalp |
Priority: | medium | ||
Version: | 3.4.1 release | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: |
Description
panoworks
2012-09-09 02:15:42 UTC
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. Setup: 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. Old behavior: 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 New behavior? 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. |