Bug 34686 - Option to turn off Paste mode for Return
Summary: Option to turn off Paste mode for Return
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium enhancement
Assignee: Martin van Zijl
URL:
Whiteboard: target:7.1.0
Keywords:
: 39531 (view as bug list)
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2011-02-24 18:54 UTC by Dakov
Modified: 2021-03-31 13:49 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of proposed option. (89.91 KB, image/png)
2020-06-06 03:40 UTC, Martin van Zijl
Details
Video demo of proposed option. (5.85 MB, image/gif)
2020-06-06 03:41 UTC, Martin van Zijl
Details
Updated screenshot of proposed option, after UX team feedback. (89.59 KB, image/png)
2020-06-07 03:33 UTC, Martin van Zijl
Details
Updated video demo of proposed option, after UX team feedback. (6.12 MB, image/gif)
2020-06-07 03:34 UTC, Martin van Zijl
Details
Latest video demo of proposed option. (6.40 MB, image/gif)
2020-06-07 18:57 UTC, Martin van Zijl
Details
Latest screenshot of proposed option. (89.02 KB, image/png)
2020-06-07 18:58 UTC, Martin van Zijl
Details
Latest video demo of proposed option. (3.55 MB, image/gif)
2020-08-04 18:38 UTC, Martin van Zijl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dakov 2011-02-24 18:54:10 UTC
If you copy a cell (ctrl+c) and then want to edit another cell before pasting - you of course press Return to edit that other cell - but LibreOffice has confusingly changed the behaviour of Return (toggle edit mode) and frustratingly PASTES the copied content into that cell instead of editing it.

This is obstructing and a daily frustrating.
Comment 1 Don't use this account, use tml@iki.fi 2011-03-08 00:23:14 UTC Comment hidden (no-value)
Comment 2 Kohei Yoshida 2011-03-08 05:22:12 UTC
Yes, this is 100% intentional.  You can hit ESC to get out of the paste mode.  As this is an essential part of LibreOffice Calc's internal, there is unfortunately no way to turn this off even as a configuration option (lots of other features depend on this one).
Comment 3 Dakov 2011-03-08 05:52:51 UTC
Thanks for the workaround - Escape - to be able to edit cells by without pasting into them.

Please consider an option to turn off Return for pasting. Copy mode is good (the highlight is a great feature) - but pasting with Return is dangerous.

I really hope you will consider changing this issue into an enhancement as it totally obstructs the workflow for some users (me and my colleagues). I haven't experienced this in Open Office or other spreadsheet programs.

It's suprisingly often that I work while having something important in the copy buffer and suddenly find out I've pasted it into a wrong cell since I edited a couple of cells before pasting. Really dangerous actually :(
Comment 4 Kohei Yoshida 2011-03-08 06:17:01 UTC
Sorry.  Like I said, no.  And you can always Ctrl-Z to undo accidental pasting.
Comment 5 Kohei Yoshida 2011-03-08 06:23:06 UTC
Well, maybe we should leave this open just in case.  But the chance of us working on making it configurable is pretty slim.  I'm just being honest about this.
Comment 6 Dakov 2011-03-08 07:15:37 UTC
Sure - I can't set this as an enhancement or suggestion, though.

Anyway thanks agian - Ctrl + Z don't work if you never realize what happened. It might be hard to distinguish the wrongly pasted cell from what was there before so often you might be in doubt or not discover it until later when somethings goes wrong (or the client reports a bug in the spreadsheet). That's what I meant be dangerous.
Comment 7 Kohei Yoshida 2011-03-08 07:23:35 UTC
You mean, you can't tell if something is pasted or not at the current cursor position, even though the pasted data is highlighted?

Sorry, but I find that very hard to believe.
Comment 8 Dakov 2011-03-08 07:28:24 UTC
(In reply to comment #7)
> You mean, you can't tell if something is pasted or not at the current cursor
> position, even though the pasted data is highlighted?

When I use Ctrl+V the "no-questions-asked pasted-into overwritten" cell gets nicely highlighted :) - it great and easy to see, yes.

However, when you press Return on a cell there's no indication that you pasted into it. No highlight. The content just change (which might be impossible to see if the formula is different but the result is the same).
Comment 9 Kohei Yoshida 2011-03-08 07:33:55 UTC
(In reply to comment #8)

> However, when you press Return on a cell there's no indication that you pasted
> into it. No highlight. The content just change (which might be impossible to
> see if the formula is different but the result is the same).

Like I said, when I paste by hitting ENTER (or RETURN), it hightlights the pasted data.  I'm just not seeing what you are seeing.
Comment 10 Dakov 2011-03-08 07:37:17 UTC
That's odd... let's continue this in my new bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=35116


This issue is about a Return paste mode on/off option.
Comment 11 bstern 2012-04-21 14:04:39 UTC
(In reply to comment #6)
> Ctrl + Z don't work if you never realize what happened.
> It might be hard to distinguish the wrongly pasted cell from what was there
> before so often you might be in doubt or not discover it until later when
> somethings goes wrong (or the client reports a bug in the spreadsheet). That's
> what I meant be dangerous.

I agree with this.  If you don't notice immediately upon pressing enter, and save and exit, all the Ctrl-Z in the world won't help you.

This bad behavior in Excel is why I use OpenOffice on the rare occasions that I need to use Windows, and is encouraging me to switch back to OO.o.  This breaks workflow in Calc.
Comment 12 daniel.schaaaf 2012-09-13 08:24:48 UTC
Wow, the arrogance dripping from some of these comments here!

There are obviously some people who use Enter to edit cells! Otherwise we wouldn't have bug reports on it (this one and https://bugs.freedesktop.org/show_bug.cgi?id=39531 ).

@Tor Lillqvist
It is not a slight change for some users and it is not "a step forward in evolution". It is merely a copy of MS Excel's behavior.

@Kohei Yoshida
You stated that the new paste behavior is 100 % intentional. Would you mind to elaborate why it was introduced?
What is the difference for users between using Enter and Ctrl+v? If you use Ctrl+c to copy, then Ctrl+v is much easier to reach than Enter. If you use the mouse for copying, then the keyboard is irrelevant.
The "Enter to edit" behavior in Calc is present as "F2 to edit" in Excel, and it is inferior because Enter is close to Backspace and Delete, it is a bigger key than others and more difficult to miss than F2 (oh the joy from accidentally hitting F1).
You even copied the "Remove content from clipboard after paste" from Excel! Something that is driving me crazy in Excel, and one of the reasons I turned to Calc! And again, there is not reason for this behavior since we live in times of cheap RAM and, quite frankly, items in the clipboard are probably the smallest problem of LibreOffice's memory footprint.
Introducing the new behavior does not give us any usability enhancements! Instead, it destroys some people's work-flow!

I deeply respect everyone who contributes to LibreOffice and I deeply admire people who know how to program software. But we users are part of the package too! If you cannot introduce a change in behavior without adding an option to turn it off, then don't introduce it! We have "Enter to edit" as an option, please respect that. (And don't get any ideas and remove that option to force your view of what is right and wrong upon others.)
Peace! (And ... breathe.)

Btw., what other features of Calc depend on "Enter to paste"?
Comment 13 daniel.schaaaf 2012-09-13 08:31:03 UTC
*** Bug 39531 has been marked as a duplicate of this bug. ***
Comment 14 Dan H 2014-04-24 15:04:03 UTC
Dear All,

Sorry to reopen something that had turned into a bit of a flame war, but...

Here's a variant of this behaviour that I believe is _very_ unlikely to be intentional.  Steps to reproduce:

1. Highlight a set of cells.
2. Press ctrl-c to copy.
3. Select another cell.
4. Press ctrl-alt-c to add a comment.
5. In the comment field that pops up, type a passage of text.
6. Decide that, somewhere in the middle of that passage of text, there should be a line break.
7. Click at the appropriate location in the comment text.
8. Press enter, intending to add a line break.
9. Notice that, instead of adding a line break in the comment, pressing enter has pasted material in some cell or group of cells.
10. Notice further that the text you entered in the comment field at step 5 has disappeared (more precisely, has been overwritten by whatever comment or absence of comment was in the cell(s) you copied at step 2).
11. Decide you'd like to retrieve the text you typed at step 5.
12. Press ctrl-z to undo.
13. Notice that ctrl-z has failed to restore the comment text, which is apparently irreversibly lost.

As an aside, I note that this behaviour is not shared by Excel, which clears the clipboard at step 4.
Comment 15 Dan H 2014-04-25 09:04:58 UTC
Incidentally - since step 13 of the above involves irreversible data loss, is there a case to upgrade this bug from "enhancement" to "critical"?
Comment 16 Dan H 2014-04-29 09:28:37 UTC
It's been four days since I mooted the possibility of upgrading this to critical, due to the irreversible data loss.  No-one's raised any objections, so I'm doing it.
Comment 17 Jonathan Addleman 2014-04-29 12:14:47 UTC
I just wanted to chime in to say that I would love to be able to turn this off. Hitting enter to paste is a very strange mechanic, and one that's hard to predict. Especially when there's an option explicitly saying that enter should edit the cell instead! Maybe it's copying an existing behaviour in excel, maybe some people expect it, but I don't think it's intuitive at all. I would love to see an option for disabling it.
Comment 18 Joel Madero 2014-11-04 02:55:15 UTC
So a couple notes on this:
1. It's not a critical bug, please don't set your pet bugs to critical - we have a system that works.
2. Removing the whiteboard status as I have no clue what that means - we have a list of whiteboard status' that are used, that is not one of them.
3. Setting to UNCONFIRMED as it doesn't look like anyone ever confirmed this and REOPENED is not the correct status regardless

If you're interested in learning more, please join the QA team. Thanks
Comment 19 Joel Madero 2014-11-20 05:32:57 UTC
This is a fine enhancement request but as Kohei has said - very unlikely that a volunteer will ever tackle it. Marking as NEW as the bar for enhancements is quite low.
Comment 20 Aron Budea 2017-08-24 00:21:41 UTC
Version field is for the oldest known affected version, please don't change it to a new one, just note in a comment that the bug is still there in that version.
Comment 21 thomas 2019-06-10 12:35:16 UTC
hi! just today, 10th June 2019 (!), I switched from OpenOffice (4.1.3) to LibreOffice (6.1.6.3) and I realize in LibreOffice Calc, that this bad feature of pasting with the enter key IS STILL THERE !!! – this bug report 34686 is dating back to 2011 !! – I am not capable in programming, but would so much appreciate, if those who can program LibreOffice implement a check box in "Preferences..." > "LibreOffice Calc" > "General" allowing to "Disable paste with Enter key"!! It would be great if the users themselves could just choose which behaviours of the enter key they like to use! It is not good that this function is not deactivatable!!! Thanks !
Comment 22 Mike Kaganski 2019-06-10 13:28:04 UTC
A reference to implementing commit: https://git.libreoffice.org/core/+/be2150398ce765b87d44ada8a13c09345be52e22, which may give an idea where to put an option check - and then expect unknown list of features mentioned in comment 2 to fail.
Comment 23 leander.holtmann 2019-09-09 11:25:18 UTC
I also switched from OpenOffice to LibreOffice recently and this Enter-to-Paste behaviour drives me crazy, as I use Enter to edit cells.
I cannot understand how anybody sees this as a useful feature, it harms workflow big time. It is so unpredictable; it even deletes the clipboard contents afterwards so you cannot just undo the accidental paste and carry on, you also have to copy again.

Btw what other features rely on this? Why did anybody implement this in the first place?
Comment 24 gyrlgith 2020-04-06 08:01:24 UTC
7a302dee87224d02853a5955cc6f715a40186803
6.4.4.0.0+
press enter to switch to edit mode. but use ctrl+x key is useless aute paste.
right now, i tried attempt send bug report with this. but i discover this report. so i cancel send.
why this movement action? and why dose not package this option?
that is wonderful solution and calm solution for controversy. i don't know, why this suggest is negation?
press to enter to switch do edit mode need this solution option.
Comment 25 Martin van Zijl 2020-06-06 03:36:21 UTC
I am writing a patch to add an option for this.
Comment 26 Martin van Zijl 2020-06-06 03:40:28 UTC
Created attachment 161673 [details]
Screenshot of proposed option.
Comment 27 Martin van Zijl 2020-06-06 03:41:49 UTC
Created attachment 161674 [details]
Video demo of proposed option.
Comment 28 Martin van Zijl 2020-06-06 03:51:08 UTC
UX Team -- please take a look at this enhancement. I've attached a demo screenshot and video of my current patch, and would like your feedback.

In particular:

1) The label of the new checkbox is currently "Use Enter key to paste and clear clipboard". Would "Enable Paste Mode for Enter key", or something else, make more sense?

2) Should the checkbox be moved to after the other two preferences about the Enter key (i.e. just below "Press Enter to switch to edit mode")?

Also, do you know what other UX features depend on Paste Mode? Is there any harm in disabling it?
Comment 29 Roman Kuznetsov 2020-06-06 08:12:28 UTC
(In reply to Martin van Zijl from comment #28)
> UX Team -- please take a look at this enhancement. I've attached a demo
> screenshot and video of my current patch, and would like your feedback.
> 
> In particular:
> 
> 1) The label of the new checkbox is currently "Use Enter key to paste and
> clear clipboard". Would "Enable Paste Mode for Enter key", or something
> else, make more sense?
> 
> 2) Should the checkbox be moved to after the other two preferences about the
> Enter key (i.e. just below "Press Enter to switch to edit mode")?
> 
> Also, do you know what other UX features depend on Paste Mode? Is there any
> harm in disabling it?

1) "Use Enter key to paste and clear clipboard" is very clear for me
2) Should

Thanks for your patch.
Comment 30 Martin van Zijl 2020-06-07 03:33:20 UTC
Created attachment 161704 [details]
Updated screenshot of proposed option, after UX team feedback.
Comment 31 Martin van Zijl 2020-06-07 03:34:41 UTC
Created attachment 161705 [details]
Updated video demo of proposed option, after UX team feedback.
Comment 32 Martin van Zijl 2020-06-07 03:35:59 UTC
(In reply to Roman Kuznetsov from comment #29)

Thanks, have updated the patch and updated the screenshot and video attachments.
Comment 33 Dakov 2020-06-07 12:14:05 UTC
GREAT work, Martin!! - I've been waiting nine years for this :) (longer if you count earlier 'Offices') - I'm so glad you've put effort into this. Hope it wasn't too complicated :)

Cheers!
- David
Denmark, Copenhagen
Comment 34 Martin van Zijl 2020-06-07 18:57:45 UTC
Created attachment 161742 [details]
Latest video demo of proposed option.
Comment 35 Martin van Zijl 2020-06-07 18:58:23 UTC
Created attachment 161743 [details]
Latest screenshot of proposed option.
Comment 36 Martin van Zijl 2020-06-07 18:59:48 UTC
Changed label to "Press Enter to paste and clear clipboard" to make them consistent with the two options above it.

Submitted patch for review.
Comment 37 Heiko Tietze 2020-06-08 08:24:30 UTC
(In reply to Martin van Zijl from comment #36)
> Changed label ... to make them consistent with the two options above it.

Consistency over labels is rather contra-productive as you have to read more carefully. 

In this particular case not so important, both "Use Enter key to paste and clear clipboard" and "Press Enter to paste and clear clipboard" are easy to understand ("Press Enter" seems to be better English).

(In reply to Martin van Zijl from comment #28)
> Also, do you know what other UX features depend on Paste Mode? Is there any
> harm in disabling it?

Eike, anything to consider?
Comment 38 Buovjaga 2020-07-15 15:23:51 UTC
Eike unfortunately does not have time to look into this.

We should git grep through the code and also inspect the history to find out more about the Paste Mode.

Maybe also run the whole test suite while having the mode disabled by default.
Comment 39 Eike Rathke 2020-07-15 15:32:22 UTC
(In reply to Heiko Tietze from comment #37)
> (In reply to Martin van Zijl from comment #28)
> > Also, do you know what other UX features depend on Paste Mode? Is there any
> > harm in disabling it?
> 
> Eike, anything to consider?
I don't think so. Apart from that the marching ants should not be shown if the option is disabled as they indicate exactly that clipboard-enter-will-clear state.
Comment 40 Martin van Zijl 2020-08-02 17:42:38 UTC
(In reply to Eike Rathke from comment #39)
> I don't think so. Apart from that the marching ants should not be shown if
> the option is disabled as they indicate exactly that
> clipboard-enter-will-clear state.

Thanks for the tip.

The marching ants are currently still shown if the option is disabled. Let me try to fix that.
Comment 41 Martin van Zijl 2020-08-04 18:38:43 UTC
Created attachment 163951 [details]
Latest video demo of proposed option.

Updated video demo. No longer shows "marching ants" on copied cells if option is turned off.
Comment 42 Martin van Zijl 2020-08-04 18:45:51 UTC
(In reply to Martin van Zijl from comment #40)
> (In reply to Eike Rathke from comment #39)
> > I don't think so. Apart from that the marching ants should not be shown if
> > the option is disabled as they indicate exactly that
> > clipboard-enter-will-clear state.
> 
> Thanks for the tip.
> 
> The marching ants are currently still shown if the option is disabled. Let
> me try to fix that.

I fixed it so the marching ants are not shown if the option is disabled.

However, the downside is that you no longer have a reminder of what you copied (or that you copied something at all).
Comment 43 Martin van Zijl 2020-08-07 04:55:10 UTC
(In reply to Buovjaga from comment #38)
> Maybe also run the whole test suite while having the mode disabled by
> default.

To run the whole test suite, do you just use "make check"?
Comment 44 Buovjaga 2020-08-07 05:35:56 UTC
(In reply to Martin van Zijl from comment #43)
> (In reply to Buovjaga from comment #38)
> > Maybe also run the whole test suite while having the mode disabled by
> > default.
> 
> To run the whole test suite, do you just use "make check"?

Yes.
Comment 45 Martin van Zijl 2020-08-10 23:39:18 UTC
(In reply to Buovjaga from comment #44)
> (In reply to Martin van Zijl from comment #43)
> > (In reply to Buovjaga from comment #38)
> > > Maybe also run the whole test suite while having the mode disabled by
> > > default.
> > 
> > To run the whole test suite, do you just use "make check"?
> 
> Yes.

Thanks. I ran "make check" with the option disabled by default. It seemed to run OK without any failures.

For the test, in officecfg/registry/schema/org/openoffice/Office/Calc.xcs, I put <value>false</value> instead of <value>true</value> for the option.
Comment 46 Commit Notification 2020-11-18 12:56:40 UTC
Martin van Zijl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a6e1647612cc3d39e8a6e44c9365ccecb1da2fe6

tdf#34686 calc: add option to disable paste with enter key

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 47 Jadeja. R 2020-12-02 14:00:05 UTC Comment hidden (spam)
Comment 48 Xisco Faulí 2021-03-31 13:49:09 UTC
A polite ping to Martin van Zijl:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ?
Otherwise, Could you please explain what's missing?
Thanks