Bug 81571 - AutoCorrect incorrectly requires and keeps spaces around special characters
Summary: AutoCorrect incorrectly requires and keeps spaces around special characters
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:4.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-20 18:04 UTC by bugzilla
Modified: 2014-08-25 05:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla 2014-07-20 18:04:18 UTC
If one wants to use special symbols for things like copyright, trademark, etc: e.g. 
© 
™ 
® 
one has to type a space before and after the "(C)", "(tm)", (R), characters. 
But these symbols should NOT be preceded by a space in the final document, so the AutoCorrect function forces the typist to remove the unwanted extra space manually, so that, for example, "Sony ™ Corporation" becomes Sony™ Corporation"

Likewise, when one wants an n-dash to indicate a range of numbers such as dates, pages, etc., e.g. 
pp.23–25
6–12 October
2013–14
ages 22–36
one is forced to a space before and after the double hyphen, and then delete both  of the extra unwanted spaces manually.

SURELY Writer should accept "(C)", "(tm)", "(R)", and "--" without requiring a space before and after? What is the point of requiring those extra keystrokes?

And if, for some good reason that I can't think of, Writer does have to have those spaces, then surely when it AutoCorrects those characters and replaces them with the required special symbols, it ought to get rid of the unwanted spaces?
Comment 1 tommy27 2014-07-20 19:15:20 UTC
ti otbain what you look for you need to use wildcard autocorrection which is a new feature of 4.2.x (feature is full functional in 4.2.4.2 and above)

enter the autocorrect replacement table and add an entry like:

.*(tm) --> ™ 

it will solve the issue about the blank space

I set status to RESOLVED WORKSFORME
feel free to reopen if this doesn't work
Comment 2 tommy27 2014-07-20 19:17:27 UTC
more about wildcard autocorrection here:
https://wiki.documentfoundation.org/ReleaseNotes/4.2#Writer
Comment 3 bugzilla 2014-07-20 19:36:09 UTC
Thanks for this.

I have now successfully set AutoCorrect to replace ".*--" such that when I type [alphanumeric character][hyphen][hyphen][space] I get an n-dash "–" with no preceding space; so that's a great improvement.

But are you saying I can make it remove the suffix space as well? 
".*--.*" does not do it for me.
Comment 4 tommy27 2014-07-20 20:02:40 UTC
don't know if it can be user for suffix as well... you have to play with it.
Comment 5 bugzilla 2014-07-20 22:55:52 UTC
OK, thanks.

But it still leaves the original question: surely the default behaviour of AutoCorrect for these special symbols is simply WRONG (or at least totally unhelpful and counter-productive), and should thus be considered as a bug that needs fixing?!

Just because there is a work-around (which only half-works anyway) does not mean that the bug has been fixed!
Comment 6 tommy27 2014-07-21 07:56:29 UTC
try adding 
0--.* --> 0–
1--.* --> 1–
2--.* --> 2–
etc. etc. 

it should fix both the "space before" and "space after issues"

I also ask advise from Lazlo Nemeth who's the author of wildcard autocorrection to see if there's a smarter way to set a rule for double of triple digit numbers as well, since the "2--.*" rule won't work with 12--, 342-- etc. etc.

I tried the syntax .*2--.* but it doesn't work like .*--.*
Comment 7 bugzilla 2014-07-21 08:28:52 UTC
As I showed with my original examples, one is almost always dealing with 2-, 3-, or 4-digit numerals:

ages 23–25
pp.156–234
$125–$175
5.23cm–6.48cm
Genesis 1:23–2:56
financial years 2013–2014

So this is an *extremely* incomplete work-around to the original bug, not a solution to it.
Comment 8 tommy27 2014-07-21 08:35:22 UTC
as you can read in my previous post I'm aware that is a workaround not proficient for double digits and more, so I asked advise to an expert developer.

so please, don't be so impatient and try to be more gentle, showing more respect for people who's spending time trying to help you... you should really adjust the "tone" of your posts.
Comment 9 bugzilla 2014-07-21 08:58:50 UTC
I apologise if my tone seemed rude or impatient. I really do appreciate the help you guys are trying to give me. 

It's just that it seems to me that the community's valuable time and energy should be spent on creating real solutions, not work-arounds.
Comment 10 tommy27 2014-07-21 09:24:45 UTC
(In reply to comment #9)
> ...
> It's just that it seems to me that the community's valuable time and energy
> should be spent on creating real solutions, not work-arounds.

so you are complaining again... please avoid this type of comment that do not help fixing things but just piss of the people who's trying to help.

you opened a bug report yesterday and after just 1 hour you already got a solution that fixed the special symbols (© ™ ®) issues.

after 14 hours you received another hint that fixed the "number dash" issue for single digits only, and a developers has already been alerted to ask for a better solution for double and triple digits, which I agree with you is not yet resolved.

so it seems to me that the time and energy of the community (which is mainly composed by volunteers) are showing good results in a very limited amount of time.

I'm also confident that Lazlo will find a solution to improve the wildcard autocorrection and use it in the scenario you describe.

we need to understand why the ".*--.*" doesn't do what we are expecting from it.

please be patient and show appreciation for what has been done till now. :-)
Comment 11 bugzilla 2014-07-21 09:39:29 UTC
OK, if I still seem impatient I am expressing myself badly. Apologies!

I have been living with this "problem" for at least a year, but it only this week that I decided to try to get a proper solution. I spent a considerable amount of time reading the Help documentation etc. before posting a bug report.

Clearly I am not the first person to have raised the issue; see here, for example: http://ask.libreoffice.org/en/question/11581/automatically-place-en-not-em-dashes-between-numbers/

If the response to my bug report had been: "We're aware of the problem, and working on it", that would have been fine. I would have been patient and maybe sent a reminder 3 or 6 months later.

But to be offered an imperfect work-around and to have the status changed to "RESOLVED" did not seem to me to be a good way to proceed. I hope you see why I sent my series of follow-up messages, and am sorry if they seemed impatient or ungrateful
Comment 12 tommy27 2014-07-21 11:00:37 UTC
(In reply to comment #11)
> ...
> I have been living with this "problem" for at least a year, but it only this
> week that I decided to try to get a proper solution. I spent a considerable
> amount of time reading the Help documentation etc. before posting a bug
> report.

Ok. the right place to raise bugs is Bugzilla.
next time don't wait 1 year before doing it. the earlier you post a report the earlier QA and devs will pay attention to it.


> Clearly I am not the first person to have raised the issue; see here, for
> example:
> http://ask.libreoffice.org/en/question/11581/automatically-place-en-not-em-
> dashes-between-numbers/

sure, I have no doubt that this issue can annoy other people. 
nut the "ask LibO" site is meant for user support, tips and trick etc. etc.
again, if you wanna file a bug you have to do it in Bugzilla.


> If the response to my bug report had been: "We're aware of the problem, and
> working on it", that would have been fine. I would have been patient and
> maybe sent a reminder 3 or 6 months later.
> 
> But to be offered an imperfect work-around and to have the status changed to
> "RESOLVED" did not seem to me to be a good way to proceed. I hope you see
> why I sent my series of follow-up messages, and am sorry if they seemed
> impatient or ungrateful

read again comment 1 and expecially this 2 lines that I quote here:

> I set status to RESOLVED WORKSFORME
> feel free to reopen if this doesn't work

so there's really nothing you can complain about it...
a solution was offered to you, status was changed to FIXED but I said that you were *FREE* to reopen if it did not work... that's a correct way to proceed, and I have nothing to regret about it.

it seems to me that anytime you apologize for "expressing badly" just soon after doing it, you start with another polemic which still sounds ungrateful and inappropriate.

now, let's stop this game that's not contributing at all in fixing the bug.
the situation is the "we are aware of the bug and will work to find a solution".
consider that it's summer and I don't know when the specific developer will take a look at it.

in the meantime use wildcard autocorrect to deal with a consistent part of your problems and wait with patience for a complete solution.
Comment 13 Commit Notification 2014-08-01 17:48:46 UTC
Laszlo Nemeth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b3b6361c555e54ce852d62c80c0bb3d19c1ec78f

fdo#81571 autocorrect doesn't need space before (c), (r), (tm)...



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 László Németh 2014-08-01 17:50:39 UTC
Fixed autocorrect patterns. Thanks for your bug report!
Comment 15 tommy27 2014-08-03 15:52:10 UTC
just to add that the whole en-dash/em-dash autocorrect thing needs some specific autocorrect entries to cover all possible corner case as described here:
https://bugs.freedesktop.org/show_bug.cgi?id=55292#c19

thanks again Lazlo for the fix.