In Calc, I tried to create a field with the text "Cum. interest"*. This is exactly what I typed into field A1, followed by a return. Autocorrect capitalized it to "Cum. Interest". I didn't want the word "interest" to be capitalized, so I hit Undo. I expected the autocorrect capitalization to be undone, resulting in the text "Cum. interest", but instead Undo caused the entire field A1 to be emptied. I tried the same thing in Writer and there the undo action seems to behave different: in Writer, the undo action results in the desired text "Cum. interest", just as I desire. So this seems to be Calc-specific behavior. As a workaround I type "Cum. interest", then move the text input cursor to the word "Cum." and then hit return (or otherwise change field selection). However, this is not a very satisfying solution. It would be great if autocorrect would behave the same in Calc as it behaves in Writer. (* in my language, "cum." is a perfectly acceptable abbreviation for cumulative ;))
Hi Willy, Have you tried turning off via Tools > Autocorrect options? Cheers, Cor
Hi Cor, Thanks for your thoughts. Turning autocorrect off would probably work, but I'd like to leave it on and to be able to override the autocorrect per individual occurrance, as is the case in Writer. The reason I'm posting this bug report here is because I think it is undesirable behavior that should be fixed.
Pressing "Undo" or Ctrl+Z after validating an entry in a cell remove this entry. This is the normal behavior. If you do not want Calc to autocorrect what you are typing: Press Ctrl+Z just after writing "Cum. interest" and *before* pressing Enter. When presing Enter you accept autocorrection. Reopen this bug if you don't agree.
Oups, sorry. Reopen. Ctrl+Z don't not works in this case. I confused with autocomplete. Sorry.
@willie : I change the summary. Better behaviour of Undo is the best we can get here. Not wanting autocorrect to act without turning it off :D .. no I can't imagine how that should work. Still we could check if this worked different in an older version. Cheers, Cor
Hi Cor, thanks for changing the summary. You're right about that, it's not really autocorrect's fault. I tested a few different versions of LibO and the undo behavior is the same in these versions: 4.1.6.2 (40ff705089295be5be0aae9b15123f687c05b0a) 4.2.5.1 (881bb88abfe2992c6cede97c23e64a9885de87de) 4.3.0.0.beta1 (2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f) 4.3.0.0.beta1+ (29162832feafca9259dc1589d10f3cfd43ea8126 / TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time: 2014-06-02_07:05:39) and of course version 4.2.4.2 (release) which I use normally. Hope this helps.
Just a small bump. The undesired behavior is still present in version 4.3.0.1 (9ed0c4329cf13f882dab0ee8b9ecd7b05e4aafbb) and 4.3.1.0.0+ (Build ID: c482a2f87ef2a38d249c276924e071bbc714a07f / TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time: 2014-07-02_02:22:32)
LibreOffice behaviour with regard to "Undo" is similar if not the same to what Microsoft Excel does. There undo does revert the whole cell change as well even if was autocorrected after ENTER. However, there is one key difference that it is possible to enter "Cum. interest" in Excel without turning off autocorrect while it IS NOT possible to do that in LibreOffice. Generally autocorrection happens as you type and it can be reverted with CTRL+Z while still typing (like suggested in comment #3). This is fine as long as the word which has be autocorrected is the last one (this is our case with "Cum. interest"). Obviously, this last word (and only it) has to be autocorrected upon ENTER as there is no other way. And that's where Excel and LibreOffice behaviour differs: in Excel autocorrect of the last word is performed only when the cursor is at the end of line upon ENTER. On the contratry, in LibreOffice, it is always performed regardless of cursor position. Think about it, Excel behaviour makes much sense: 1) User types in "Cum. interest" and presses ENTER. Libreoffice corrects it to "Cum. Interest". 2) User sees LibreOffice did it wrong. He may try CTRL+Z which won't work, but I'm pretty sure that eventually he will try to fix up LibreOffice "mistake" manually: edit the cell, go to "I" letter, correct it to "i" and press ENTER. In Excel, this would work (-> user happy) because the cursor was not at the end of line. However, LibreOffice would autocorrect "I" letter again. The worst part is that no matter how user enters plain "Cum. interest", Libreoffice will autocorrect it (user very unhappy). The two workarounds are: * Turning off autocorrect. * Entering text as formula, e.g. ="Cum. interest" (which is what I typically do). But this is not very obvious and very user-unfriendly in my option. I like Excel behaviour much more, because it feels more "natural". Excel does not seem to insist on repeat the same wrong things when I explicitly correct it. I know technically Excel is sort of "cheating", but typically users won't notice that. P.S. Willie, I'm sort of hijacking your bug but would you be ok with this "autocorrect the last word only if the cursor is at the end of line" solution? I suppose it would be much easier for LibreOffice developers to implement than change "Undo" behaviour.
Hi Modestas Vainius, Thank you for this elaborate analysis of the problem. There is no need to excuse yourself, as your comment is quite on-topic and insightful. I don't perceive your comment as highjacking at all, but rather as a quite valuable refinement of the problem. I agree with you that Excel's behavior is much more user-friendly and I find it desirable to follow Excel's example in LibreOffice. -Willie
REOPENED is reserved for a bug that: 1. a developer has marked as FIXED; 2. a developer is assigned to the bug that is marked as FIXED; In this case the bug report was never independently confirmed so correct status is UNCONFIRMED. Thanks!
I can confirm the originally described behaviour althought I expect that the locales were set to Dutch, while I could confirm it only with Hungarian ones. Status changed to NEW LinuxMint 17 Cinnamon LO 4.2.4.2
reproducible under Windows 8.1 x64 too using LibO 5.1.0.0.alpha1+ Build ID: 7d3fa6bae9f7a755eb2d0ca24bf1afd5f3646bb7 TinderBox: Win-x86@39, Branch:master, Time: 2015-08-09_08:38:08 Locale: it-IT (it_IT) edited summary notes
*** Bug 93682 has been marked as a duplicate of this bug. ***
Reproducable under Windows 10: Version: 5.1.4.2 Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Locale: en-GB (en_GB) I want to get 'News fora' in a cell, but LO changes this into 'News for a'. Since in most cases 'fora' should indeed be 'for a', deleting this entry from the Auto Correct doesn't make sense. One of those small but highly annoying bugs :/
(In reply to GerardF from comment #4) > Oups, sorry. > Reopen. Ctrl+Z don't not works in this case. I confused with autocomplete. It does work when typing a space after 'interest', what then changes to "Interest' and that then Ctrl-Z undoos
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hi, I can confirm that I still have the bug in LibO 6.0.3.2 / Win 10 x64. Here's my About LibreOffice: Version: 6.0.3.2 (x64) Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU threads: 8; OS: Windows 10.0; UI render: GL; Locale: en-US (en_US); Calc: group
Hi, This bug seems PARTIALLY fixed in my version of LibO: ℹ️ Version: 6.2.3.2 (x64) Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded ✔️ What works: - Type "Cum. interest" in a cell - Hit Enter => it gets auto-corrected to "Cum. Interest" - Hit CTRL+Z => the cell content is now "Cum. interest", as expected ❌ What still doesn't work: - Type "http://example.com" in a cell - Hit Enter => it gets auto-corrected with URL formatting - Hit CTRL+Z => the cell content vanishes. Expected behavior: the cell content should be the non-formatted URL
Dear Willie, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Reproduced as in Description in OOo 3.3, so issue is inherited. Reproduced as in comment 19 in: Version: 7.6.0.0.beta1 (X86_64) / LibreOffice Community Build ID: be55b15d98c5f059483845a183fcb5ea8023d27c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Captialize first letter of every sentence" is undoable, but undoing Email and URL autocorrects (controlled by the "URL recognition" option) still removes the whole content.
*** Bug 125646 has been marked as a duplicate of this bug. ***