Bug 67364 - Autocorrect collisions between 2 hyphens (--) for en-dash an 3 hyphens (---) for em-dash
Summary: Autocorrect collisions between 2 hyphens (--) for en-dash an 3 hyphens (---) ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA target:5.3.0
Depends on:
Reported: 2013-07-26 18:34 UTC by vermontpoet
Modified: 2016-09-23 11:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description vermontpoet 2013-07-26 18:34:33 UTC
Problem description: 

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.

Current behavior:

Produces an en-dash followed by the third hyphen.

Expected behavior:

Should replace the three hyphens with an em-dash.              
Operating System: Ubuntu
Version: release
Comment 1 Cor Nouws 2013-07-26 22:10:36 UTC

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?
Comment 2 vermontpoet 2013-07-27 00:36:54 UTC
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.
Comment 3 Cor Nouws 2013-07-27 10:17:11 UTC
Hmm.. maybe related to the locale? Which laguage version are you working in ?
Comment 4 vermontpoet 2013-07-27 11:59:11 UTC

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?
Comment 5 vermontpoet 2013-07-28 21:21:59 UTC
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.
Comment 6 Cor Nouws 2013-07-30 20:09:32 UTC

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 ?
Comment 7 vermontpoet 2013-07-30 21:43:43 UTC
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.
Comment 8 tommy27 2014-07-23 05:17:46 UTC
hi, are you still seeing this issue with current LibO
Comment 9 Patrick Gillespie 2014-07-27 19:25:02 UTC
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.
Comment 10 Patrick Gillespie 2014-07-27 19:26:09 UTC
The previous comment should read:

"That is, it corrects two dashes to an **en-dash** before waiting for the third dash."
Comment 11 Patrick Gillespie 2014-08-02 17:56:20 UTC
OK, I've been testing with the Master4.4.0.0.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.
Comment 12 tommy27 2014-08-03 15:26:57 UTC
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 ***
Comment 13 tommy27 2014-08-15 16:07:58 UTC
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: 
Comment 14 tommy27 2014-08-31 19:08:57 UTC
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:
Comment 15 tommy27 2014-08-31 19:15:10 UTC
edited summary notes and component field.
Comment 16 QA Administrators 2015-09-04 02:48:58 UTC Comment hidden (obsolete)
Comment 17 tommy27 2015-09-06 11:24:40 UTC
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"
Comment 18 tommy27 2015-11-12 05:29:09 UTC
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
Comment 19 tommy27 2016-09-23 11:54:32 UTC
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:
Tools/AutoCorrect\AutoCorrect options.../Options"

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.