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:
2. Type -Hello World- + space -> Strikeout
Strike out (or Italic/Bold/Underline)
Adding formatting while typing using autocorrect shouldn't be default;
People who use it should enable it manually
User Profile Reset: No
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
I confirm it, but let's ask design team, if it should be changed.
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.
(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
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:
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..
(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 won't make it to the Design meeting but I agree with Heiko's POV here
(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:
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
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).
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).
Also some models use * quite a lot. Try typing:
De heer *, wonende te *, *, geboren te * op *, houder van een *, nummer *, uitgegeven te * op *, gehuwd*,
If we move to adjust work done to autocorrect handling  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  and selectively apply STYLE or DF.
Otherwise, the current behavior is as intended, but lacks granularity. Acceptable and => WF
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
(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
> 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
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.
Let's move on.. WFM it is. Thanks for the input everyone..
Would have asked the users (G+, Twitter) if these autoformat options should get disabled. Expected 90% No.
(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..
Here we go
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'.
(In reply to Heiko Tietze from comment #15)
> Here we go
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.