Bug 39531 - EDITING; Enter is paste even when Enter supposed to switch edit mode.
Summary: EDITING; Enter is paste even when Enter supposed to switch edit mode.
Status: RESOLVED DUPLICATE of bug 34686
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.0 Beta2
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-25 12:52 UTC by mrelwood
Modified: 2012-09-13 08:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mrelwood 2011-07-25 12:52:18 UTC
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.
Comment 1 Rainer Bielefeld Retired 2011-07-25 22:59:21 UTC
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)

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)

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 3.3.3.1)]", 
Master "LibO-dev 3.4.5  – WIN7  Home Premium  (64bit) English UI 
[(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43
	2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb
	6a9633a-931d089-ecd263f-c9b55e9-b31b807
	82ff335-599f7e9-bc6a545-1926fdf)]"

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.

@Christoph:
Can you see any intention for current behavior? 

@David:
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.

Actual Text:
Enter (in a selected range): Moves the cursor ....

Should be:
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.
Comment 2 Rainer Bielefeld Retired 2011-07-25 23:00:31 UTC
Also [Reproducible] with "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6 Tag 3.3.0.4)]", so Version to "from beginning"
Comment 3 Jeffrey 2011-07-26 08:14:29 UTC
Confirmed on LibreOffice 3.4  340m1(Build:103) for OpenSuse Linux.
Comment 4 David Nelson 2011-07-27 00:16:04 UTC
I've forwarded this bug to the docs ML for discussion and action.
Comment 5 Christoph 2011-07-28 13:37:24 UTC
(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!
Comment 6 Björn Michaelsen 2011-12-23 12:21:53 UTC
[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:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 7 Björn Michaelsen 2011-12-23 17:01:59 UTC
needinfo keyword redundant by needinfo status.
Comment 8 mrelwood 2011-12-24 13:22:35 UTC
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.
Comment 9 mrelwood 2011-12-24 13:24:43 UTC
Sorry, the previous post was misleading. No attachment in this bug report. Still, the issue remains.
Comment 10 daniel.schaaaf 2012-09-04 09:26:43 UTC
Another "interesting" thing about this bug: After "pasting with enter key", the clipboard is being emptied!

Steps to reproduce in v3.5.6.2:

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
Comment 11 daniel.schaaaf 2012-09-13 08:31:03 UTC
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 ***