Bug 78217 - Autocorrect replacement table: selected text is copied in "With" field rather than "Replace" field
Summary: Autocorrect replacement table: selected text is copied in "With" field rather...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0
Keywords:
: 118141 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-05-03 07:24 UTC by tommy27
Modified: 2018-06-14 06:53 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
test case with screenshot (67.78 KB, application/vnd.oasis.opendocument.text)
2014-05-03 07:24 UTC, tommy27
Details
test case and screenshot (67.78 KB, application/vnd.oasis.opendocument.text)
2014-05-03 07:27 UTC, tommy27
Details
screenshot pre- & post-patch (100.45 KB, image/png)
2014-05-05 05:29 UTC, tommy27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tommy27 2014-05-03 07:24:45 UTC
Created attachment 98361 [details]
test case with screenshot

tested under Win7x64 but I suppose it applies to other O/S as well.

this issue is present in OOo 3.3.0, all LibO releases up to 4.2.3 and 4.3.0alpha1 and AOO 4.1 as well, so "inherited from OOo"

STEPS TO REPRODUCE (see attached .odt file as well)
1- open an empty Writer document
2- type something including a spelling error
3- select that error with left double click
3- hit "Options / "Autocorrect options"
4- the autocorrect replacement table pops up

EXPECTED BEHAVIOUR
the selected text should be automatically copied
into the "Replace" field

CURRENT BEHAVIOUR
the selected text is automatically copied
into the "With" field

this is basically non-sense since if you select a word and open the autocorrect replacement table is very likely that you selected an error, and you wanna just enter the proper spelling in the "With" field

with current behaviour you have to cut the spelling mistake from "With" and paste it into "Replace" then go back to "With" and type the correct spelling, this is annoying.

moreover there's risk that some user could not pay attention to the field names and directly enter the correct spelling in the empty "Replace" field rather than the proper "With" filed which is already occupied by the bad spelling.
so next time you type correctly that word in will be autocorrected into a mistake.

I'm not a developer but I think it's should be easy to identify the code that copies selected text into the replacement table and change the field destination from "With" to "Replace"
Comment 1 tommy27 2014-05-03 07:27:58 UTC
Created attachment 98362 [details]
test case and screenshot
Comment 2 Jacques Guilleron 2014-05-03 11:54:07 UTC
Hello tommy27,

I confirm with LO 3.6.6.2, LO 4.1.6.2 
& Windows 7 Home Premium.

Nice day,

Jacques
Comment 3 Julien Nabet 2014-05-04 06:32:59 UTC
On pc Debian x86-64 with master sources updated yesterday, I can reproduce this.
Comment 4 Commit Notification 2014-05-04 06:33:24 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: fdo#78217 selected text should be copied in "Replace"



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 5 Julien Nabet 2014-05-04 06:35:33 UTC
For 4.2: https://gerrit.libreoffice.org/#/c/9247/
Comment 6 tommy27 2014-05-04 06:46:29 UTC
thanks Julien for your rapid committ.
I will test it as soon as a master daily build is available.

I hope it will cherry picked as well to 4.2.5 (I understand we are too late for 4.2.4).
Comment 7 Julien Nabet 2014-05-04 06:48:58 UTC
Tommy27: just for information, if you build from sources (master or 4.2), you can retrieve use the patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4d61b3c556189bf0733ab6e7bedaf975427a35a without updating all your local repo.
Comment 8 Cor Nouws 2014-05-04 11:30:59 UTC
(In reply to comment #0)

> 2- type something including a spelling error


Hi Tommy,

Does your scenario also take use cases into account where people create a (longer) text, select that, and want to enter a short text (e.g. an abbreviation) in the replace field that they want to have replaced with the longer text?
Comment 9 tommy27 2014-05-04 11:45:49 UTC
@Cor
I understand what you mean, but in my experience most of the times people enter the replacement table to correct spelling errors (which is the main function of autocorrect) not to enter text snippets (which is IMHO a secondary function of autocorrect).

for examples I have autocorrect list of more than 260K items, and probably 98% are true spelling errors and just 2% are text snippets.

just my 2 cents, I'm open to hear other people opinion as well.
Comment 10 Cor Nouws 2014-05-04 12:54:18 UTC
Hi Tommy,

(In reply to comment #9)
 
> just my 2 cents, I'm open to hear other people opinion as well.

I understand your situation. 
But the Help is quite explicit in explaining the scenario I sketched,
Of course we have AutoText for that too, but that would mean a serious change in behaviour.
Comment 11 tommy27 2014-05-04 16:22:29 UTC
please drop here the link to the help chapter you refer.

however as I said, that scenario you are talking about is AutoText.
autocorrect is a completely different thing...

you can use autocorrect as a surrogate of autotext as well, but that's not it's real function... autocorrect is primarly meant to correct typing errors not create text snippets.
Comment 12 Cor Nouws 2014-05-04 16:46:00 UTC
(In reply to comment #11)
> please drop here the link to the help chapter you refer.

https://help.libreoffice.org/Common/Replace#Replacement_table
Comment 13 tommy27 2014-05-04 17:00:06 UTC
@Cor
thanks for the link. anyway it just says that you can use this for autocorrect and autotext as well.

there's nothing telling that a selected word should be automatically pasted in the "replace" or "with" field when loading the replacement table.

the bug report here was meant just to invert the current behaviour that automatically pastes selected text into "with" field rather than "replace"

as I said before since primary goal of autocorrection is typing error correction, so IMHO ideal behaviour is to paste selected text into "replace"

autotexting is a secondary goal, but you can still do it manually moving selected text to "with" and enter your text snippet into "replace"

as said before I think it's more likely that user will use more frequently the option to do autocorrection rather than autotexting.

anyway autotexting is still possible even with julien patch

tell me if I'm missing something
Comment 14 Cor Nouws 2014-05-04 18:47:15 UTC
(In reply to comment #13)

> autotexting is a secondary goal, but you can still do it manually moving
> selected text to "with" and enter your text snippet into "replace"

Are you sure that this also works with text with more paragraphs / OLE / graphics?
Pls note there is the 'text only' checkbox too.

Also: as written before, changing the behaviour is a serious one. There are tens of millions of users out there. Many for more then ten years too. Forcing them to change behaviour can be done, but I prefer discussing this kind of changes is wider audience since we may even overlook use cases. Sorry..
Comment 15 tommy27 2014-05-04 19:11:29 UTC
@Cor
again, what has been replaced by the patch is just the initial destination of selected text, "replace" rather than "with" field

once the table is opened you still can do anything you want with that text... 
I mean you may move to the other column, edit it, even delete it and write anything else...

until you don't manually edit your autocorrect entry and put the desired text in both columns and save it you can do whatever you like with it... 

moreover you can even enter the replacement table without any previous text selection, in that case both "replace" and "with" fields will be empty

I have no troubles asking UX-advise but I think you are misunderstanding the whole situation since you talk about OLE, paragraphs and graphics that IMHOM have nothing to do the current issue and requested patch change.

did you try opening my test file and reproduce the easy steps?
Comment 16 Julien Nabet 2014-05-04 19:27:34 UTC
Stefan/Michael: following the last comments, it seems we need expert Writer Dev/UX here. Any opinion?
Comment 17 Cor Nouws 2014-05-04 20:01:35 UTC
@tommy,

OK, if there is no problem with moving the text from one field to another when it holds more then plain text (as explained in the Help) - I don't have a build to test the patch - there is no real problem...
And I don't need to try your test file: the explanation is clear enough and fully understandable :)
Comment 18 tommy27 2014-05-05 05:29:37 UTC
Created attachment 98444 [details]
screenshot pre- & post-patch

@Cor
yes, no problem at all. patch doesn't change how autocorrect works, it just change initial column position of selected text. the rest of the procedure is still manual and unchanged.

@Julien
I tested your patch in 4.3.0.0.alpha1+
Build ID: f76026a43acc65465882924796d93e635c35fd90
TinderBox: Win-x86@39, Branch:master, Time: 2014-05-04_06:34:33

it works as expected. so I mark this as FIXED and VERIFIED

now let's hear what Stefan/Michael think about backporting to 4.2.x but I'm quite convinced that the change represents an improvement in UX.

if you are not familiar with autocorrect
Comment 19 tommy27 2014-05-05 05:32:24 UTC
if you are not familiar with autocorrect try Attachment 98362 [details] in 4.2.x and 4.3.x to see the different behaviour (same of previous screenshot)
Comment 20 Michael Stahl (allotropia) 2014-05-09 11:01:51 UTC
the documented (comment #12) use-case of having something other
than plain-text (frames, images, OLE) in the replacement text does
not work with the patch...

the "With" field contains only a plain text string, so by
copying that to the Replace field you can't get images.

but, why don't we just initialize *both" With and Replace fields
with the selected text?  the user has to edit at least one
of the fields anyway, and any guess as to which one it will
be is going to be wrong some of the time; if we pre-fill
both fields then the user will manually clear one of them,
and if they leave the "Replace" field as-is then the
images etc. will work fine.
Comment 21 Julien Nabet 2014-05-09 11:27:33 UTC
First I found the change obvious, now I understand better why sometimes one's would want to have the "With" field filled instead of "Replace" one.

Filling both all the time would mean, delete the content of 1 field each time too.
What about adding an option in the dialog or global option which would be saved in LO profile?
However, to put it clear, I wouldn't know at all how to implement this so I reset the assignee.
Finally, since there's a debate about all this, I reopen this tracker and put UI.
Comment 22 Julien Nabet 2014-05-09 11:29:42 UTC
(Forgot to tell about the second part (first, ... then).)
So then I thought indeed one's could consider useful to type a text or create an objet, then to use this dialog to tell LO to use this.
Comment 23 Cor Nouws 2014-05-09 13:51:18 UTC
@tommy: it's understandable and more then OK when you are enthusiastic about an idea, but pls try extra hard in that case to understand some else's questions ;)
Comment 24 tommy27 2014-05-09 16:06:28 UTC
@Cor
what a shame :-(
sorry, my bad. next time I'll do more accurate testing.

I confirm that in 4.3.x in the patch if you select text in a frame and it's copied in the "replace" field, it won't preserve those attributes if you then paste it in the with field.

so it's seems that that stuff is preserved just when is initialized in the "with" field... maybe the "replace" field accepts only text strings.

so I ask the patch to be reverted.

I've read Micheal Stahl proposal to initialize both fields which could be a good compromise.

however I think that of a more elegant solution would be:

if selection is just plain text --> copy to the "replace" field
if selection contains text and frames and pictures and anything else --> copy to "with" field

is this something feasible from a dev point of view?
would it give UX issues?
Comment 25 e_psi 2014-05-10 11:23:57 UTC
IMHO entering selected content in "with" is neither a bug nor is it bad usability.
A feature for adding spelling errors to AutoCorrect is already implemented in a user-friendly an logical way.
1. Type something wrong and it becomes underlined red
2. Place cursor in Word>rightclick
3. Always correct to>choose a word
and there you are. Maybe "Something else" is missing, and add "Always correct" even if spellcheck presents no alternatives.
I strongly oppose change in behaviour, it's right like ist is even for text only. Behavioural functionality (only text then do this) will only lead to confusion, because most users will never guess why.
Comment 26 e_psi 2014-05-10 11:25:42 UTC Comment hidden (obsolete)
Comment 27 tommy27 2014-05-10 12:26:56 UTC
(In reply to comment #26)
> ...
> A feature for adding spelling errors to AutoCorrect is already implemented
> in a user-friendly an logical way.
> 1. Type something wrong and it becomes underlined red
> 2. Place cursor in Word>rightclick
> 3. Always correct to>choose a word
> and there you are. 

sure I know that feature but you should keep in mind that autocorrect right click suggestion are not always 100% accurate and in my experience there are many cases in which there's no valid suggestion and you have to manually enter the correct typing in the replacement list.
Comment 28 tommy27 2014-05-10 12:29:48 UTC
regarding this last scenario I've already opened a report sometime ago
Bug 65952 - Enter custom autocorrect entries without opening the replacement table
Comment 29 e_psi 2014-05-10 21:51:18 UTC
(In reply to comment #27)
> sure I know that feature but you should keep in mind that autocorrect right
> click suggestion are not always 100% accurate and in my experience there are
> many cases in which there's no valid suggestion and you have to manually
> enter the correct typing in the replacement list.

(In reply to comment #26)
> Maybe "Something else" is missing, and add "Always
> correct" even if spellcheck presents no alternatives..

I kept that in mind, that is really missing.
Comment 30 tommy27 2014-05-11 06:10:08 UTC
(In reply to comment #26)
> ...
> Behavioural functionality (only text then do this) will only lead to
> confusion, because most users will never guess why.

Let's summarize. The autocorrect replacement table may be used for 3 categories of autocorrection:

1- real typing errors (i.e. yrllow ; yellow) comment 0

2- text snippets for formatted text + images + tables ecc. ecc. (like a table with your name in bold italics and company logo etc. etc.) comment 13

3- text snippets for text only long phrases (i.e. asap ; as soon as possibile) comment 8

so the problem here is: “which is the right place” we should paste a user “selection” when opening the replacement table?

I believe that behavioural functionality would not lead to confusion at all but will exactly do what is expected by the user in a logical way... let's see some scenarios: 

1- user selects text but just a “single word” 
then is very likely that he selected a typing error and he wanna enter the proper spelling, so the selection IMHO should directly go in “replace” rather than “with”. 

Otherwise, as in 4.2.x, if the typo fills the “with” field and you have to cut and paste into the “replace” field and then go back to “with” and type the correct spelling.

2- user selects “formatted text + images + tables ecc. ecc.” 
is indeed very likely that he's not willing to correct a typing error but rather enter a text snippet for formatted text etc. etc. so logical destination is “with”

as shown (and I initially missed it), if the initial destination is “replace” (like in the patched 4.3.x) you can't preserve formatting by moving manually to “with” so that's why that patch has to be reverted.

3- user selects text in “a long phrase”
I see 3 different scenarios:

a- user selected a correct phrase to enter an abbreviation snippet (i.e. as soon as possible ; asap) so that selection should go in “with”

b- however there are chances that user selected a long phrase like “as son as possible”
in which spellchecker doesn't see errors but the content of the phrase is wrong (“son / soon”) so in this case logical destination is “replace” and type “as soon as possible” in the “with field”

so, bottomline is if it's technically feasible to teach LibO to guess the correct scenario and do the right choice... 

while I suppose it can be easy to distinguish between 1 and 2, I think that it would be probably impossible for a computer to distinguish between case 3a and 3b. 

probably the “prefill both” idea from Micheal Stahl ( comment 20 ) is the one which is technically easier to implement.


for the moment it's better to revert patch in comment 4, than think if this "autocorrect destination field" can be managed without breaking functionality.
Comment 31 tommy27 2014-05-11 10:49:31 UTC
hi guys, reading all you comments I came out with an idea that would simultaneously fix both current Bug 78217 and Bug 65952

idea would be to leave the current 4.2.x behaviour for selected text in a document and to copy into "with" field either if it's plain or formatted or OLE etc. etc. that would be ok in scenarios 2 and 3a of my previous post

regarding scenario 1, that happens only when you try to autocorrect a typing error with right click menu and you don't find a proper spellcheck suggestion.

If we could add a new item in the "right click autocorrect" suggestion like it was suggested in comment 26

(In reply to comment #26)
> ... Maybe "Something else" is missing, and add "Always
> correct" even if spellcheck presents no alternatives.
> ...
 
and here: https://bugs.freedesktop.org/show_bug.cgi?id=65952#c7

>  ... something like "add custom" could be added, 
> which then triggers a dialog to enter a custom
> autocorrect entry. This is something that could be done easily.


that new "add custom" menu item should be used to launch the autocorrect replacement table and allow the user to type his desired correction.
only in this case the word should be pasted into the "replace" field because we are clearly dealing with a typing error situation.

I'd like to hear your opinion about that.
IMHO this would not alter current "selection to autocorrect" behaviour and will instead represent a clear improvement in the "right click autocorrect" experience.
Comment 32 Commit Notification 2014-05-11 12:19:09 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

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

Revert "Resolves: fdo#78217 selected text should be copied in "Replace""



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 33 tommy27 2014-05-11 12:59:06 UTC
thanks Julien

I mark this report as WONTFIX since the change I suggested leads to nasty side effects.

I think the right way to implement the feature is to work on the "right click autocorrect suggestions" menu like explained in comment 31

discussion may continue in bug 65952
Comment 34 tommy27 2018-06-14 06:53:13 UTC
*** Bug 118141 has been marked as a duplicate of this bug. ***