https://bugs.freedesktop.org/show_bug.cgi?id=54679
Bug #: 54679
Summary: EDITING - allow end-of-range selection relative to
selection-corner cell
Classification: Unclassified
Product: LibreOffice
Version: 3.4.1 release
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: enhancement
Priority: medium
Component: Spreadsheet
AssignedTo: [email protected]
ReportedBy: [email protected]
This is a request to bring back end-of-range selection as being relative to the
current selection-corner cell.
References:
https://bugs.freedesktop.org/show_bug.cgi?id=44556
EDITING: Undesired Behavior Change in 3.5b2 when Extending a Selection in Calc
not picked up.
https://bugs.freedesktop.org/show_bug.cgi?id=52239
EDITING , trouble selecting cells with keyboard in calc
not picked up.
https://bugs.freedesktop.org/show_bug.cgi?id=39438
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.
https://bugs.freedesktop.org/show_bug.cgi?id=37230
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.
And potentially:
https://bugs.freedesktop.org/show_bug.cgi?id=44389
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.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
