After the discussions in Bug 37230 and Bug 78534 I'm filing a new bug to request finally a better solution for CTRL+SHIFT+ARROW selection. This solution shell... - Have a fixed cursor position - Detect empty/filled and filled/empty transitions over the full selection range (not from a single focal point cell) For better understanding I provide the following demonstration: - Open the attached TestCase.odf - Make sure cursor is set to cell D1 - While holding down SHIFT+CTRL click arrow-left - While holding down SHIFT+CTRL click arrow-down Resulting selection: A1:D6 Expected selection (Excel): A1:D4
Created attachment 99046 [details] TestCase.ods
*** Bug 78534 has been marked as a duplicate of this bug. ***
Just to make sure I understand this, you're proposing a third behavior where the selection stops when ANY of the cells on the front of the selection range collide with a empty/non-empty cell? Basically, it perform a select to block margin on each cell in your currently selected range and stop at the first collision? For instance, if we have a selection of A1:C1, and we press ctrl+shift+down, you want it to stop when we encounter ANY change in columns A, B, or C? In certain situations, that behavior would make things MUCH less efficient than even the non-legacy mode. For instance, if you had lots of randomly populated columns, it would render ctrl+shift+arrow entirely useless. I don't have any way to test this under MS Excel, but is this behavior really the new standard? I see no use for this behavior unless it already is an established standard and is implemented as another option for compatibility. Even if that is the case, it would still be an enhancement request. I will mark it as such. Whatever is decided, please do not modify the newly implemented "Use legacy cursor movement behavior when selecting." I understand it will no longer be checked by default starting in 4.3, but that's fine as long as it's easy to enable. I still see it as the only useful selection mode available.
I don't understand how this bug report is a duplicate of bug 78534 or why it needed to be created. In any case... If what tmacalp describes is correct, the proposed third behavior is even more whacky than the recent non-legacy behavior. Personally, I don't care what Excel does (nor can I find out, since I have no access to it). I am more concerned with what makes sense. I and many of my users have been GREATLY upset by the changing of the CTRL+SHIFT+ARROW behavior in LO 4 (to supposedly match the completely illogical Excel behavior), and ecstatic that an option to turn on the proper, 15-year "legacy" behavior was recently added. Even the mention of another change to CTRL+SHIFT+ARROW behavior makes me want to scream...
After more investigation I found out that Excel does not detect over the full range. But nevertheless I think this idea is worth to be discussed for LibreOffice.
Hm so this is consistent with Microsoft Office - I'm not sure that this would be good at all ( personally it would interrupt a workflow that I'm used to). That being said, I will request additional input before closing as WONTFIX.
@tmacalp: You are right, I am proposing a third behaviour. You are understanding my proposal correctly. 1) [ ] Use legacy cursor movement behaviour when selecting 2) [X] Use legacy cursor movement behaviour when selecting 3) My proposal in this Bug 78711. In fact Excel uses 1), not 3). Saying that Excel would behave like 3) was my mistake. But nevertheless I like number 3). This is why I remain commited to this Bug 78711.
.
Migrating Whiteboard tags to Keywords: (needAdvice) [NinjaEdit]
'needsConfirmationAdvice' is only used for unconfirmed bugs. Removing it from this bug. [NinjaEdit]