Bug 121377 - Autocorrect strikeout writing convention potential for unintended changes
Summary: Autocorrect strikeout writing convention potential for unintended changes
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2018-11-12 19:30 UTC by Telesto
Modified: 2019-04-15 10:15 UTC (History)
5 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 Telesto 2018-11-12 19:30:32 UTC
Description:
I unintentionally typing something between dashes without spaces.. I got a strike-out for a full alinea. 

Adding formatting while typing using autocorrect is a type of feature which shouldn't be enabled by default; IMHO. It's not something I would expect from autocorrect while typing. At least not by default. 

Yes, it has been doing this for * * and _ _  for years. But there range has extended  - - and / /.  It increases the change for activating it by accident. I'm not seeing the need for it (as default). There are already shortcuts. It's a niche function. It should be activated manually (IMHO). It's not common behavior either for editors either (as far I tested). 

Steps to Reproduce:
1. Writer
2. Type -Hello World- + space -> Strikeout

Actual Results:
Strike out (or Italic/Bold/Underline)

Expected Results:
Adding formatting while typing using autocorrect shouldn't be default; 
People who use it should enable it manually


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.0.0.alpha1+
Build ID: 30df4a32449f3b717e77eb447583730e026b7d17
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-11_07:42:44
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Dieter 2018-11-12 21:51:20 UTC
I confirm it, but let's ask design team, if it should be changed.
Comment 2 Heiko Tietze 2018-11-13 08:33:30 UTC
It's intended design. Autocorrection is a powerful and widely accepted functionality. Plus, you can undo the last step to restore -Hello World- as typed. That works for me perfectly.
Comment 3 Telesto 2018-11-13 09:06:40 UTC
(In reply to Heiko Tietze from comment #2)
> It's intended design. Autocorrection is a powerful and widely accepted
> functionality. Plus, you can undo the last step to restore -Hello World- as
> typed. That works for me perfectly.

* Autocorrection is a powerful and widely accepted functionality.. 
Yes, not denying that. 

* Undo resolves it
Again, true 

You're missing my point. The question: should the autocorrect while typing change the text formatting when typing -zzz- or *zz * or /zzz/ or _zzz_ as a DEFAULT setting.

Not everybody likes it:
https://ask.libreoffice.org/en/question/142095/how-do-i-turn-off-the-automatic-strikethrough-text/
https://listarchives.libreoffice.org/global/users/msg51099.html

And it has quite the surprise effect (huh, what's happening here).I personally see it as a geeky feature for Power users who want this & know how it works..

It shouldn't be a out of the box experience, as it can be rather annoying and confusing (I don't want this.. How do I disable it..
Comment 4 Heiko Tietze 2018-11-13 09:15:14 UTC
(In reply to Telesto from comment #3)
> You're missing my point. The question: should the autocorrect while typing
> change the text formatting when typing -zzz- or *zz * or /zzz/ or _zzz_ as a
> DEFAULT setting.

Okay, up to the agenda for the team meeting. My WFM position stands. 

Btw, why did you add dashes at all? I mean isn't it very unlikely that Benjamin types *Hello*. And making this bold is not unusual.
Comment 5 Xisco Faulí 2018-11-13 10:42:16 UTC
I won't make it to the Design meeting but I agree with Heiko's POV here
Comment 6 Telesto 2018-11-13 11:21:32 UTC
(In reply to Heiko Tietze from comment #4)
> (In reply to Telesto from comment #3)
> > You're missing my point. The question: should the autocorrect while typing
> > change the text formatting when typing -zzz- or *zz * or /zzz/ or _zzz_ as a
> > DEFAULT setting.
> 
> Okay, up to the agenda for the team meeting. My WFM position stands. 
> 
> Btw, why did you add dashes at all? I mean isn't it very unlikely that
> Benjamin types *Hello*. And making this bold is not unusual.


I should be a little more specific:

*Asterisk* 
Writing things between two asterisks enable bold. However, I used this only sporadically and only in cases of single words. So no large surprise effect. 

However there a stylistic usages to, for example *ouch*.
Or as a marking to indicate a temporally item. Say *possible* (which is open for change,   

So not sure if this was perfect anyway

_Underscore_
Writing a sentence or a word as as _hello_  never occurred to me (so never an issue). Can't think of a situation right now.

/Slash/ (since 5.4)
Not run into yet. But at least problematic when typing directory's like: /usr/john/pictures

-dash- (since 5.4)
Quite common to use. I typed multiple sentence and ended with a dash (-).. Suddenly I got a strike-through paragraph. Not aware it typed a dash without a space at the beginning. 
Another example: say I want to type -12-12 (outcome: -24).
Comment 7 Telesto 2018-11-13 11:46:32 UTC
Asterisks can be used in textual media to represent *emphasis* when bold or italic text is not available (e.g., Twitter, text messaging).

Bounding asterisks as "a kind of self-describing stage direction", as linguist Ben Zimmer has put it. For example, in "Another gas station robbery *sigh*," the writer uses *sigh* to express disappointment (but does not necessarily literally sigh).[26]

Also some models use * quite a lot. Try typing:
De heer *, wonende te *, *, geboren te * op *, houder van een *, nummer *, uitgegeven te * op *, gehuwd*,
Comment 8 V Stuart Foote 2018-11-13 13:24:19 UTC
If we move to adjust work done to autocorrect handling [1] and make control more granular than simple enabled/disabled while typing or editing (Tools -> Autocorrect -> AutoCorrect Options: Options) then would want to reopen see also bug 115418 [2] and selectively apply STYLE or DF.

Otherwise, the current behavior is as intended, but lacks granularity. Acceptable and => WF

=-ref-=
[1] https://gerrit.libreoffice.org/#/c/31076/
[2] https://wiki.documentfoundation.org/Design/Meetings/2018-03-21
Comment 9 Telesto 2018-11-13 21:23:02 UTC
Alternative proposal (in case of WFM for the default question and/or the more granular settings): make it easier to disable this feature (at the minimum for autocorrection while typing). It's rather deeply buried in the Tools / Autocorrect / AutoCorrect Options/ Options dialog. So rather hard to access...

A bit similar to Number recognition for tables
Comment 10 V Stuart Foote 2018-11-13 22:11:16 UTC
(In reply to Telesto from comment #9)
> Alternative proposal (in case of WFM for the default question and/or the
> more granular settings): make it easier to disable this feature (at the
> minimum for autocorrection while typing). It's rather deeply buried in the
> Tools / Autocorrect / AutoCorrect Options/ Options dialog. So rather hard to
> access...
> 
> A bit similar to Number recognition for tables

No! The AutoCorrect options dialog is simple as can be. The entry "Automatic *bold*, /italic/, -strikeout- and _underline_" labeling is a simple translation. And GUI makes behavior to apply while [M] -- modify, or [T] -- typing is obvious. Moving the control elsewhere, or into Expert Configuration would make less sense than adjusting the default state(s) to disabled.

And though I beleive we would benefit from more ambitious refactoring to provide granularity and user selection of using Character STYLE or DIRECT FORMATTING (as currently applied). Absent that effort, the existing control is suitable to task.

Again IMHO => WF
Comment 11 Cor Nouws 2018-11-14 18:55:42 UTC
I understand it is annoying. Handling various correction types different, is strange to me. So I see it as unavoidable little collateral damage. It will force people to look in this functional part.. Is that a pro ? :)
Anyway, for me too: WFM.
Comment 12 Telesto 2018-11-14 19:08:11 UTC
Let's move on.. WFM it is. Thanks for the input everyone..
Comment 13 Heiko Tietze 2018-11-15 08:16:22 UTC
Would have asked the users (G+, Twitter) if these autoformat options should get disabled. Expected 90% No.
Comment 14 Telesto 2018-11-15 10:12:00 UTC
(In reply to Heiko Tietze from comment #13)
> Would have asked the users (G+, Twitter) if these autoformat options should
> get disabled. Expected 90% No.

Actually, I'm still interested in the outcome.. But don't think that a survey reaches regular users. Followers are (mostly) LibreOffice enthusiast (ergo: mostly pro-users). But that's me being skeptic. 

To get more response from every day users some sort of push notification model could be used. A info bar (similar to Get involved or donation bar) to inform about a surveys with a check for open survey's similar to the auto-updater..
Comment 16 Telesto 2018-11-16 09:05:14 UTC
Another suggestion, if this end up in UX Advise again.. The dialog caption 'Options' in the AutoCorrect Options should - ideally - [*strike-through warning*] be relabelled to something more meaningful. Word calls it AutoFormat as you Type. A little more obvious place to look, compared to non-informative description: 'options'.

https://word.tips.net/T000636_Making_Text_Bold.html
Comment 17 Heiko Tietze 2018-11-19 12:11:33 UTC
(In reply to Heiko Tietze from comment #15)
> Here we go
> 
> https://twitter.com/liboDesign/status/1063023582064844800
> https://plus.google.com/102673546895803839652/posts/JUbGDNmeCGK

Twitter 47/53%, G+ 36/64% for "Yes, change"/"No, keep" (around 100 answers; intentionally wrote the question in a kind of double negation with Yes=Change so some replies may have mistakenly done wrong)


(In reply to Telesto from comment #16)
> Another suggestion... relabelled to something more meaningful

You talk about the tab "Options" that collects a list of predefined, hard-coded things together with true options and tweaking settings. Hard to believe that a terminology change solves anything. But feel free to create a new ticket with a proposal.
Comment 18 Telesto 2019-04-15 10:04:32 UTC
I still think this should be optimized somehow (triggered by bug 124747).

* There is a group who are running into the automarkdown feature unaware about the existence & find it disturbing/annoying/confusing
* There is a group who loves Markdown support and want it to be enabled all the time

Still searching for a bright idea to make everybody happy..

Would a info-bar popping up the first time when the auto-formatting gets triggered? Something like: autoformatting is enabled by default, you can disable it in.. or see for more info..
Comment 19 Heiko Tietze 2019-04-15 10:15:26 UTC
(In reply to Telesto from comment #18)
> Would a info-bar popping up the first time when the auto-formatting gets
> triggered? Something like: autoformatting is enabled by default, you can
> disable it in.. or see for more info..

If we'd have a balloon tip, maybe. But then people scream "clippy is back".