https://bugs.freedesktop.org/show_bug.cgi?id=33899
--- Comment #14 from Ian Goddard <[email protected]> --- I checked this out after finding that the problem has not gone away in LO4. ITYF find that most users, when entering a string such as 1/2/2011 will be intending it to be a date. If such a user finds it converted into ½/2011 they would not consider this to have been corrected - just the opposite. This is not autocorrection, it's autocorruption. Sure, there's a workaround - to kill the autocorrection even in those cases where the correction would have been reasonable. But a workaround is all it is, it doesn't mean that the behaviour being worked around isn't a bug. If a program exhibits behaviour which a reasonable user wouldn't expect to be the norm in a common situation then I think it has to be considered to be a bug, albeit, as Tommy says, an awkward corner case. Suggested mitigations: 1. if LO is setting out to be bug-for-bug compatible with Excel do the same as Excel & default the autocorrect table to exclude fractions. 2. if autocorrect has been invoked add a review phase after the next character to see if the autocorrect still looks reasonable and back it out. However, there are clearly 2 parse and reformat operations at work here, one which applies the autocorrect/autocorrupt & one which applies the normal date format check, e.g. expand 1/2/11 to 01/02/2011 and they're invoked in that order. Can this order be reversed? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
