Steps to reproduce: * Open LO Calc. * Write something that would evaluate to a date, format, or formula, prefixing it with escape character "'" (single quote) at the beginning so that it would interpret it as raw text. E.g. "'2019-01-33", or "'*not_bold*". * Press enter Expected behavior: should show the text after the "'" as simple text, without trying to evaluate it to date/format/etc. Actual behavior: depending on whether it's written from scratch or not, it might respect the "'" escape character, but will end up showing it in the cell (i.e. while MS Excel will show "2019-01-33", Calc will show "'2019-01-33"), or in some cases when there was something there from before, will ignore the "'" and evaluate anyway.
Cannot edit the comment now, but I think this only happens when the input is invalid after being evaluated. E.g. MS Excel: "'2019-01-01" -> "2019-01-01" (text) MS Excel: "'2019-13-33" -> "2019-13-33" (text) LO Calc: "'2019-01-01" -> "2019-01-01" (text) LO Calc: "'2019-13-33" -> "'2019-13-33" (text, but includes extra character).
(In reply to david.cortes.rivera from comment #1) > LO Calc: "'2019-01-01" -> "2019-01-01" (text) > LO Calc: "'2019-13-33" -> "'2019-13-33" (text, but includes extra character). confirming, even with text, e.g.: "'Hello" -> "'Hello" this behaviour is different from AOO 4.1.5, but i don't know if the change was intended.
I don't think it is a bug. Character escape only works with valid non text values, otherwise there is nothing to escape. And a way to know if the escaped value it's valid or not.
(In reply to m.a.riosv from comment #3) > I don't think it is a bug. > Character escape only works with valid non text values, otherwise there is > nothing to escape. And a way to know if the escaped value it's valid or not. But in MS Excel it doesn't show in the output when it's applied to regular text. Also being an escape character IMO it'd make sense to not show it regardless. Finally, it has the problem that if I apply a function that adds it to a whole column, it will show it in some entries and not in others.
Dear david.cortes.rivera, 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://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
Still reproducible: Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 16; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 1:7.0.4-4 Calc: threaded
This is solved with the resolution in bug 149665 for LO 7.5. I'm not sure I would call it a duplicate, but the behavior presented here in bug 126308 is no longer present. If you want the apostrophe to be really part of the cell, then format the cell as text before introducing the content with its initial "'" (see Release Notes for LO 7.5). Setting as WFM.