When "Press Enter to switch to edit mode" is selected, Enter still works as Paste when a selection is copied to clipboard. The features overlap, which is counterintuitive and not very productive.
If the overlapping is considered okay, there should atleast be an option to disable Enter as Paste.
We are talking about preference in Menu 'Tools -> Options -> Calc -> General - Input settinsg - "Press Enter to switch to Edit mode"'
Expected from OOo:
a1) "Press Enter to switch to Edit mode" UNchecked: Cell cursor will move to
position defined in "Press Enter to move selection"
a2) "Press Enter to switch to Edit mode" checked: Enter will do the same as
<f2>, starts "Edit Mode" (Caret flashes in Cell)
b1) "Press Enter to switch to Edit mode" UNchecked: Cell cursor will move to
position defined in "Press Enter to move selection"
b2) "Press Enter to switch to Edit mode" checked:
b21) With spreadsheet contents in clipboard: Clipboard to cells.
B22) WithOUT spreadsheet contents in clipboard: Enter will do the same as
<f2>, starts "Edit Mode" (Caret flashes in Cell) (as expected)
I see that unexpected behavior with "LibreOffice 3.4.1 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:202)]",
"LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 188.8.131.52)]",
Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI
As expected with OOo 3.1.1, OOo-dev 3.4
Bug or feature? I dislike it.
BTW, IMHO selection "Press Enter to move selection" should be inactive if "Press Enter to switch to Edit mode" is selected, we can't have both in time.
Can you see any intention for current behavior?
Help is really poor here, can you please watch results here and add to Help?
Help under Heading "Shortcut Keys for Spreadsheets - Navigating in Spreadsheets" is wrong.
Enter (in a selected range): Moves the cursor ....
Enter: Moves the cursor one cell to the direction selected in Tools - Options - LibreOffice Calc - General. If a cell range or several cells have been selected:
Selection "Right": Moves Cell Cursor right, from the most right cell to the most left marked cell in the next line containing a marked cell. If the most bottom line with marked cells has been reached, from the last cell Cell cursor will jump to the most left cell in the first line containing marked cells.
Selection "Left": Moves Cell Cursor left, from the most left cell to the most right marked cell in the next line above containing a marked cell.
Selection "Down": Moves Cell Cursor down in the column to the next marked cell, from the most bottom cell to the most top marked cell in the next column to the right containing a marked cell.
Selection "Up": Moves Cell Cursor up in the column to the next marked cell, from the most top cell to the most bottom marked cell in the previous column to the left containing a marked cell.
Also [Reproducible] with "LibreOffice Portable 3.3.0 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:6 Tag 184.108.40.206)]", so Version to "from beginning"
Confirmed on LibreOffice 3.4 340m1(Build:103) for OpenSuse Linux.
I've forwarded this bug to the docs ML for discussion and action.
(In reply to comment #1)
> In LibO
> b1) "Press Enter to switch to Edit mode" UNchecked: Cell cursor will move to
> position defined in "Press Enter to move selection"
> b2) "Press Enter to switch to Edit mode" checked:
> b21) With spreadsheet contents in clipboard: Clipboard to cells.
> (UNEXPECTED paste)
> B22) WithOUT spreadsheet contents in clipboard: Enter will do the same as
> <f2>, starts "Edit Mode" (Caret flashes in Cell) (as expected)
> Bug or feature? I dislike it.
Definitively a usability bug - (again) caused by the totally flawed (and unhelpful) Enter-Is-Paste-Almost-Like-In-Excel-Implementation.
Question: In the version I've tested (LibO 3.3.2), the cases b21/b22 need a bit refinement. Instead "spreadsheet contents in clipboard" it is "directly after the user copied/cut the content". Is that correct? Note: We don't talk about the standard clipboard, because nothing is left in the clipboard (after Enter finished the insert mode) even if the original content was copied.
If yes, then we have three modes:
* navigation mode --> no special indication
* editing mode --> blinking cursor in cell / edit line
* insert mode --> indicated by the blinking border (if copied), or no special indication (if cut)
If we want to keep that "insert mode" stuff, then the status bar should indicate that special mode by saying something like "Press Enter to insert the " in the (whole) status bar. And, it might be helpful for the user to also use the blinking border to highlight the (former) position of the original content. That should be sufficient to inform the users.
My more generic recommendation is still to go back to the OOo behavior (or make it the default), because the new behavior breaks too much without providing sufficient value.
> BTW, IMHO selection "Press Enter to move selection" should be inactive if
> "Press Enter to switch to Edit mode" is selected, we can't have both in time.
The German translation seems a bit better in this case, because it says (something like) "input confirmation" in the former case. Both is valid, because:
* in navigation mode: ENTER will enter the edit mode
* in editing mode: ENTER will confirm the change and moves the cell cursor
@ David: Might the German text contain some inspiration to improve the English version?
@ Rainer: Removed whiteboard "infoprovider: Christoph" item. And thanks for (as always) excellent refined bug description.
@ "mrelwood": Thanks for the report!
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Yes, still happens in LOdev 3.5.0 beta 2 with the attached spreadsheet. Opens fine in OpenOffice 3.3.0.
This issue originally reported in LibreOffice 3.3.1 release.
Sorry, the previous post was misleading. No attachment in this bug report. Still, the issue remains.
Another "interesting" thing about this bug: After "pasting with enter key", the clipboard is being emptied!
Steps to reproduce in v220.127.116.11:
1) Copy cell
2) Paste by pressing the enter key
3) Try to paste again with Ctrl+v
=> Nothing happens
4) Repeat step 1)
5) Press Esc key (and see "crawling ants" around copied cell disappear)
6) Paste with Ctrl+v as many times as you want
=> Pasting works as expected
I hope I don't offend anyone by marking this as a duplicate. Bug 34686 is essentially the same thing (less focus on having "Enter to paste as an option that can be switched off" in the beginning, but it changed into that eventually). And the other bug report has someone assigned to it (even though it is a person opposing the resolution of the bug).
*** This bug has been marked as a duplicate of bug 34686 ***