Prior to 4.1x, I had set up autocorrect to correct three hyphens --- with an em-dash — .
This no longer functions. Libre now inserts an *en*-dash followed by a hyphen.
What appears to be happening is that Libre now only gets as far as the first two dashes, then invokes autocorrect to insert an en-dash.
Steps to reproduce:
1. Set up autocorrect to correct --- to an em-dash.
2. Type --- and space.
Produces an en-dash followed by the third hyphen.
Should replace the three hyphens with an em-dash.
Operating System: Ubuntu
Version: 18.104.22.168 release
thanks for reporting this. But... it works fine for me _if_ I remove the autocorrect for single hyphen - to an em-dash —
Can you pls check that?
There *is* no "utocorrect for single hyphen", so it's not something I can remove. I only have an auto correct option for two hyphens --> en-dash, or three ---> em-dash. Even if I remove the double hyphen, Libre still incorrectly replaces a triple hyphen with an en-dash and a hyphen.
Hmm.. maybe related to the locale? Which laguage version are you working in ?
I have to correct a previous assertion. The three hyphen ---> em-dash *does* work if I remove the double hyphen ---> en-dash option. Apparently, Libre doesn't record changes in the dialog windows for Options or Autocorrect until they're closed.
Isn't it high time for an APPLY button?
Anyway, --- to em-dash works, but now I have no option for -- to en-dash. I think my first supposition was correct, somewhere along the line a developer changed how Libre autocorrects. It sees the first two hyphens and now ignores the third.
What version of Libre are you using and what language?
Well... I have three separate installs that I've upgraded (on three seperate computers) and they've all developed the same bug. I'll guess I'll be the one to mark the bug as confirmed.
I use all kind of LibreOffice versions, usually Dutch and English, on Ubuntu.
Maybe the problem is, that a hyphen triggers autocorrection while it should not ?
I'm not sure what's going on.
I can't reproduce this behavior (yet) with any other autocorrectable words, only hyphens.
A workaround is to use -= for an em-dash.
hi, are you still seeing this issue with current LibO 22.214.171.124?
Yes, I'm still experiencing this issue, but my workaround has been to add the following entry in autocorrect:
Correct ‒- to —
Libre doesn't wait for me to add the third dash. That is, it corrects two dashes to an em-dash before waiting for the third dash. Adding the option above assures that when it does this, adding a third dash will autocorrect to an em-dash.
The previous comment should read:
"That is, it corrects two dashes to an **en-dash** before waiting for the third dash."
OK, I've been testing with the Master126.96.36.199.alpha, and there are still a series of bugs.
In autocorrect, I've entered all possible combinations to produce an en-dash or an em-dash. here's what happens:
If you like super--man --> incorrectly inserts an em-dash instead of an en-dash.
If you like super---man --> does not correct to either en-dash or em-dash
"Test--" --> does not correct to an en-dash. Perhaps autocorrect doesn't recognize the quote for wildcard purposes?
"Test---" does not correct to an em-dash.
If you try-- ---> successfully corrects to an en-dash.
If you try--- ---> incorrectly corrects to an a dash and en-dash "If I try-–"
"--you interrupted" ---> Does not correct.
“---You interrupted” ---> Does not correct.
So... these are all examples of dialog one might find when writing fiction. Libre still doesn't seem able to properly discriminate between an en-dash or an em-dash and doesn't seem to recognize quotes for wildcard purposes.
I'm adding this coment to Bug 55292 as well.
the only way to avoid all these hyphen/en-dash/em-dash autocorrect conflicts and corner case is to use new wildcard autocorrect patterns like explained here:
new feature is available in 4.4.x current daily build.
if tests will show the fix is stable it will probably be backported to 4.2.x and 4.3.x
so I'm closing this one and marking as a duplicate of bug 55292.
let's continue discussion over there.
*** This bug has been marked as a duplicate of bug 55292 ***
just to add that is probably better to avoid the 3 hyphens at all as an autocorrect replacement even with the new wildcard features.
this is explained in more detail here:
I'm reverting status from DUPLICATE to NEW since after many tests, even the use of wildcard autocorrection does not represent a consistent solution for this annoying -- and --- autocorrect collisions
the root of the bug is that when you type the second hyphen in the --- sequence triggers the -- autocorrect replacement before you hit the third hyphen
I however see a potential idea for a fix that I've already suggested to Lazlo Nemeth (a very active developer about autocorrection) here at:
edited summary notes and component field.
** 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 on a currently supported version of LibreOffice (188.8.131.52 or later)
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
retested under Win8.1 x64 using a recent LibO 5.1.0 alpha daily build
if you use:
-- for "en-dash" and --- for "em-dash" with or without wildcard (.*--.* and .*---.*) the autocorrect collision will still take place
as said in comment 10 and comment 14, the issue takes place because the second "-" immediately triggers autocorrect even before typing the third "-"
the issue was somehow workarounded in LibO 5.0.0 using emoji patterns
:--: for en-dash and :---: for em-dash
if you use these patterns and delete the other, there will be no collision.
a mixed approach could be:
:--: for en-dash and .*---.* so the user has to type extra-characters only for "en-dash" and not for "em-dash"
another alternative, even better, approach IMHO would be:
wildcard .*--.* for "en-dash" and emoji :-: for "em-dash"
this way the user just has to type 2 keys for the "en-dash" and 3 keys for the "em-dash" and there will be no conflict between them
using current emojis :--: for "en-dash" and :---: for "em-dash" the user has to type respectively 4 and 5 keys
as a side effect of the committ that fixed Bug 83037 now it's possible to set .*--.* for en-dash and .*---.* for em-dash with no issue since the autocorrect collision caused by hyphens will not happen again.
remember you have to disable the "replace dashes" rule from:
this was VERIFIED under Win7 x64 using
Build ID: 4c70a1a6666a079872b8f1966bd398e924dc1d1a
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-22_06:54:24
Locale: it-IT (it_IT); Calc: CL
hopefully the fix will be backported in LibO 5.2.3 (too late for 5.2.2)
Thanks Caolan McNamara for his fix.