Problem description: LibreOffice should not prompt with dialog every time the Paste keyboard shortcut or menu paste option is chosen. Steps to reproduce: 1. Copy a number to the clipboard from a website 2. Paste that number into the spreadsheet 3. .... Current behavior: Pasting into the dialog you currently get a dialog that says "Select the language to use for import" and you must chose - EVERY TIME YOU PASTE - Automatic or Custom. This is new bad behavior as of 3.6. It never used to prompt me for this. Expected behavior: Pasting should never ever prompt with a dialog, but even if it does, it should be a setting that can be remembered. My language never changes, I always want the option to be automatic. You offer no option to remember the choice in the dialog and you offer no option in the preferences dialog to set and remember the choice. Users copy and paste things from websites sometimes hundreds of times a day. By forcing this dialog on every paste, you are causing the user hundreds of extra unnecessary keystrokes. That is wrong. You should give the users the ability to paste without being bombarded with a dialog box every single time. The dialog box should remember my choice or I should have preference I can set in the preferences to remember my choice. On a related issue - In addition, in Excel, the default for paste should be to paste unformatted text. Pasting formatted text totally messes up the formatting of the spreadsheet. I know about the ctrl-shift option - but there I am once again presented with an unnecessary dialog and I must choose unformatted text - it should be obvious I want unformatted text with that keyboard shortcut. Operating System: Mac OS X Version: 3.6.6.2 release Last worked in: 3.5.0 release
David thanks for the report. I can confirm this behavior in LO 4.1.0.1, OS X 10.8.4. The dialogue is annoying, but if decided to display it, it should have a checkbox (set to "on" by default) that allows LO to remember this setting for all future pasting. Setting to NEW.
Also with LibreOffice 4.0.2.2 in Linux Mint 15. Not in Windows 7.
I have tested this all the way back to 3.5beta0 and can confirm it all the way back to that point. Without a version that is known to work I am removing regression from keywords
what an absolutely horrible "feature". Who could have possibly thought that this would be of any use under any circumstance. It's practically a show stopper. As much as I have been trying to avoid using MS Office, I may have no choice. I can't believe that after all this time and all the negative comments, someone has not fixed it. I would, but my programming skills are not up to the task as a one-off.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
In addition, it would be helpful to have the default paste option as a user preference
Please don't add different enhancement requests to this bug - the last one is completely different and should be a different bug report....despite them being related we have a policy of 1 bug per report. Thanks! You can add the new bug report in the "see also" field so that devs know they are related
I can confirm this is happening in Version: 5.1.1.3 Build ID: 89f508ef3ecebd2cfb8e1def0f0ba9a803b88a6d CPU Threads: 4; OS Version: Linux 4.1; UI Render: default; Locale: en-US (en_US.UTF-8)
*** Bug 101880 has been marked as a duplicate of this bug. ***
Optional workarounds: - Create a macro to do the operation, probably best option - Alt+key combinations, assign "Edit/Paste Unformatted Text" to Alt+V - Use ctrl-alt-shift-v - Double click the cell instead of single clicking, then ctrl-v paste Each has limitations, which are, respectively: - Have to manually create macro, per user - Have to manually create, per user - Have to have very dexterous hands, or use both hands - Pastes untrimmed leading whitespace
Confirmed that this is still an issue in: Version: 5.4.0.3 Build ID: 1:5.4.0~rc3-0ubuntu0.16.04.1~lo1 Any updates on this? I'm surprised that such an annoying issue has been around for 4 years!
I constantly copy and pasting into Office documents and this infuriating "feature" is the only reason Microsoft Office is still installed on my system. Please provide a way to disable this dialog box permanently.
I can confirm that this issue persists to version 6.0.3.2 running on Linux. It has been more than 5 years since David first reported the issue.
Still an issue in Version 6.0.5.2 on Linux.
This is still happening on Version: 4.3.5.2 on Mac. Terrible bug has probably cost thousands of hours or more of productivity worldwide
Over five years!?! Helloooo..... Sorry I'm being such a whiner but please someone on the libreoffice team fix this. How do we make this happen?
use paste special and then that dialog wont popup some workarounds are used, see comment11, in the paste special options Version: 6.2.0.0.alpha0+ Build ID: fd41fb8392a4e9a27d9fd09071a5f1e2be4b5a0e CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: threaded
This dialog should not even exist; 'automatic' should be the default and all the options in there should go to the 'paste special' dialogue. Does this need a bounty for someone to implement it, or what is causing the delay fixing this issue of > Importance: high ? If there is a lack of clarity among you LO devs, please inquire.
As fat as I can see, this is Linux-only problem? That is mentioned in the meta here, and also all references mention Linux here (and comment 3 explicitly mentions no problem on Windows). IIUC, the said behavior is normal *when plain text clipboard format is used to paste*. Usually, copying something from web pages produces multiple formats available in clipboard, including HTML (here on Windows), so LO *by default* chooses HTML as most rich... and doesn't ask for import options. Does copying a web stuff produce plain text only in clipboard on Linux? Or maybe some clipboard manager does it? Pasting plain text should always produce the said dialog (because there's pasting CSV-like stupp use case); the only optimization possible here is maybe checking if the clipboard content is a single word...
Please someone stop this horrible behaviour it makes one of the most marvellous time saving gui inventions (middle click paste) and turns it into a horribly frustrating waste of time.
*** Bug 137316 has been marked as a duplicate of this bug. ***
Code pointers: https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/viewfun5.cxx?r=2d873932#335 https://opengrok.libreoffice.org/xref/core/sc/source/ui/unoobj/filtuno.cxx?r=1e97ca02#180 The implementer of a new "do not show again" option must add a check for the new option being set, and if it is, read ScAsciiOptions from saved values, instead of from the dialog.
I've assigned this bug to myself and have done this so far: https://gerrit.libreoffice.org/c/core/+/107402. My main problem is that I can't see how to set up new preferences so I don't know how to save the user's choice for a new session. However, I have made the relevant UI changes in both the paste dialog and the preferences dialog (under Options->LibreOffice Calc->General->Input Settings). For testing purposes the user's choice is instead stored in a static variable in a method (marked with a FIXME comment as this is obviously not something I want to keep). Is this otherwise broadly what people were expecting to see and if so how do I create the new preferences? As far as I can tell it is just two integers (one to select from always prompt/automatic locale/fixed locale, and one for the language chosen) and a boolean (for the special numbers setting) that need to be saved.
Is someone working on this? If not, can I?
(In reply to adityapratapsingh51 from comment #25) Hi! I'm sorry that I haven't looked at the change by George Bateman mentioned in comment 24. The mails from Bugzilla sometimes go to spam filter, and I only saw it when I read your comment. Only now could I review https://gerrit.libreoffice.org/c/core/+/107402; this delay makes me uncertain if George Bateman is still willing to continue after all that time. Please do not start working on this, until it's clear what George feels about it. Thanks!
Sorry to adityapratapsingh51 for the lack of response. I am still interested although haven't done anything much since December. Re Mike's comments on Gerrit: what exactly should this patch do then? If I am saving the user's preference from the dialog, I presumably have to provide some means for them to change their minds later and so I thought putting it into the preferences would be a valid solution. However that does seem like the sort of thing that bloats preference dialogs over time. It would possibly be helpful to only save the preference temporarily so that the user makes a choice once per session (as mentioned in comment 24) but I'm not sure what the best way would be to go about that.
(In reply to George Bateman from comment #27) > Re Mike's comments on Gerrit: what exactly should this patch do then? If I > am saving the user's preference from the dialog, I presumably have to > provide some means for them to change their minds later and so I thought > putting it into the preferences would be a valid solution. However that does > seem like the sort of thing that bloats preference dialogs over time. First I must mention that it's good to have conversation related to patches right there on gerrit, not on Bugzilla. Yes you are right that if the setting would persist, it needs an UI. Interesting if Heiko wants to mentor an easyhack for adding a "list of disabled dialogs" dedicated options page, to allow (un)checking it there. Or a button like "enable all disabled dialogs" (no idea if that would be a better UX - I'm skeptical, and would prefer a detailed list, but whoami... :-)) Anyway, this UI is absent at the moment, so *if* you want to make the option persistent, you need to add it to Options->General, which is already crowded. But without that, having it only in Expert Configuration, we'd have complaints immediately. > It would possibly be helpful to only save the preference temporarily so that > the user makes a choice once per session (as mentioned in comment 24) but > I'm not sure what the best way would be to go about that. Well - *that* is easy, and your WIP already has everything to make this work: just use a static variable - it exactly keeps its value for the session. :-)
(In reply to Mike Kaganski from comment #28) > adding a "list of disabled dialogs" dedicated options page Added a couple of "Show this" options to various tabs myself. This dedicated page sounds tempting but is likely to fail. Imagine a lot of dialogs from different sources- when you say "Show the paste dialog", for example, it's quite hard to understand what exactly this means. For this request I wonder why someone wouldn't want Automatic (c19). The per-session setting seems to be a quick and dirty solution that could be enhance later to be persistent.
George Bateman committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/57dec020b9527d3dd472e33010381822d4ca306c tdf#65872 [WIP] Allow prefered interpretation of pasted numbers to be saved It will be available in 7.2.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.
(In reply to Heiko Tietze from comment #29) > For this request I wonder why someone wouldn't want Automatic (c19). c#19 makes a very good point: we have a Paste Special function, *and it has "Use text import dialog"*. It naturally looks like default should do *some* default action without interaction, and the "Use text import dialog" should do the UI; the current solution from comment 30 would break that explicit "Use text import dialog" in the session where one has already unchecked "Keep asking...". So this is not fixed, the mentioned commit is just a step forward. But I disagree that the default should be "Automatic". The Automatic is not always correct, otherwise we would not need the manual way. And you cannot just assume that everyone's workflow only has non-Automatic as rare case. Some would work with manually overridden settings most of the time; they just need that those settings were not re-asked every time. So just like with our PDF export, the default should be "take saved settings - whatever was saved in the dialog last time"; and the explicit use of dialog should update the settings that will be used by default next time.
Not a big deal to change the language after inserting what coming in. And whether dates are detected or not, you can easily change this afterwards too.
(In reply to Heiko Tietze from comment #32) Not quite sure I understand which words does that answer?
(In reply to Mike Kaganski from comment #33) > Not quite sure I understand which words does that answer? Automatic is fine because you can change mistakenly auto formatted content later.
(In reply to Heiko Tietze from comment #34) > Automatic is fine because you can change mistakenly auto formatted content > later. Based on that, dialog is fine because it is no more annoyance than the need to change inserted data later. Do you say that in the two scenarios with same implementation complexity: 1. Pasting uses hardcoded settings; when hardcoded settings do not match, one must use dialog every time, or correct pasted data every time, no matter how often that is required, 2. Pasting uses last settings from the dialog the first one is a better UX?
(In reply to Mike Kaganski from comment #35) > ... correct pasted data every time, no matter > how often that is required, This, I expect this to happen less often. The dialog interrupts the workflow and it needs good reasons to do so.
(In reply to Heiko Tietze from comment #36) > This, I expect this to happen less often. Based on what? Do you have any evidence? Also, do you have any reason to believe that having the "Automatic" as default, and allowing the last setting to be remembered to those who need that, be a worse UX? > The dialog interrupts the workflow and it needs good reasons to do so. You seem to talk about something that only you understand. The discussion *at this point* is not whether we need to show dialog *every time* or not - the commit above already made a step toward not showing it every time! - but about "should the pasting *without* dialog always use the same "automatic" or some setting that was last used". Which means - if user had never called the dialog, it would be automatic (the default); if user needs the dialog, then the choice there is memorized for reuse at later pastes.
I think there are another few issues with this dialog: - Users may not be aware of locale-specific number rules, and after reading the dialog would have no idea what the purpose of the language-selection box is in the first place. An English user would not necessarily know that they should select French to parse "123,45". - The dialog appears even when it is irrelevant, pasting whole numbers without any punctuation. - The dialog does not appear when it is relevant if the source was plain text (e.g. my terminal window) It would be helpful at least to not show the dialog unless there is a genuine choice to be made, i.e. there is punctuation in the number.
(In reply to George Bateman from comment #38) > - Users may not be aware of locale-specific number rules, and after reading > the dialog would have no idea what the purpose of the language-selection box > is in the first place. An English user would not necessarily know that they > should select French to parse "123,45". This is bug 138748, and is off-topic in this specific bug. > - The dialog appears even when it is irrelevant, pasting whole numbers > without any punctuation. > > - The dialog does not appear when it is relevant if the source was plain > text (e.g. my terminal window) > > It would be helpful at least to not show the dialog unless there is a > genuine choice to be made, i.e. there is punctuation in the number. This would be bad. Trying to be too smart is not going to fit all. The best is the dialog never shown by default, and has an special command with possibility to assign a shortcut for cases when user wants it. You already implemented a way to not show again it during this session. Next step would be to introduce a dedicated command for showing the dialog, and make default paste to never show it.
Dear George Bateman, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.