Bug 161588 - Autoinput suggestions cannot be rejected (e.g. with Esc)
Summary: Autoinput suggestions cannot be rejected (e.g. with Esc)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.3.0.3 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2024-06-15 18:51 UTC by SY
Modified: 2024-12-11 05:34 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 SY 2024-06-15 18:51:35 UTC
Description:
When LibreOffice suggests an autocompletion, any action except deleting the suggested text accepts the suggestion.  This is a non-standard, unexpected, and obtrusive behavior on an otherwise useful feature.

Steps to Reproduce:
1.Start typing a word or phrase that is in the autocomplete dictionary.
2.Press escape OR navigate to a different line the document using the mouse or keyboard (e.g. home or end keys).

Actual Results:
Autocomplete suggestion is automatically accepted without pressing tab or enter.

Expected Results:
Autocomplete suggestion is canceled, leaving only what the user actually typed.


Reproducible: Always


User Profile Reset: No

Additional Info:
As far as I'm aware, this happens on all versions of LibreOffice.  Reproduced on 24.2.3.2 in Writer and Calc.
Comment 1 m_a_riosv 2024-06-15 22:30:07 UTC
Have you tried with undo? [Ctrl+Z]
Comment 2 SY 2024-06-15 22:37:56 UTC
(In reply to m_a_riosv from comment #1)
> Have you tried with undo? [Ctrl+Z]

Yes, it doesn't do anything in Calc.  I realized that the autocomplete for Calc is a different feature called Autoinput and have updated the bug title accordingly.
Comment 3 m_a_riosv 2024-06-15 22:59:39 UTC
Please take a look at the help
https://help.libreoffice.org/latest/en-US/text/scalc/01/06130000.html?&DbPAR=CALC&System=WIN
Comment 4 SY 2024-06-15 23:03:23 UTC
(In reply to m_a_riosv from comment #3)
> Please take a look at the help
> https://help.libreoffice.org/latest/en-US/text/scalc/01/06130000.
> html?&DbPAR=CALC&System=WIN

I have looked at that.  I though maybe F2 would do something, but all it does is accept the autoinput (like any other action).
Comment 5 Buovjaga 2024-08-20 12:46:54 UTC
The behaviour of Autoinput was changed in bug 145198.

While testing this, I noticed that you can't reject things you wrote by pressing Esc, if you have pressed F2 before it to enter edit mode.

1. Type Something into A1
2. Start typing Something in A2
3. Hit F2
4. Delete what you wrote completely
5. Hit Esc

Result: Something appears in A2 even though you had deleted it.

If I am *not* in F2 edit mode, I *can* reject autoinput, but it then just removes all that I wrote and comes out of typing mode. I could not find any reports about this F2 + Esc behaviour, even saying it's a feature and not a bug.

Let's ask UX: do you think it would be intuitive that hitting Esc when having Autoinput active would reject only that suggestion and not throw you out of typing mode?
Comment 6 ady 2024-08-20 13:18:45 UTC
(In reply to SY from comment #0)
> Expected Results:
> Autocomplete suggestion is canceled, leaving only what the user actually
> typed.

FWIW...

ATM, you have to press [DEL] in order to remove the additional suggested auto-completed text and leave the typed-in text only; then [ENTER].

In older versions (before the highly-contested bash-like auto-complete method), while in normal edit mode, pressing [ESC] would cancel all the new typed-in text (not just the extra suggested text), effectively exiting editing mode and leaving the content of the cell as it was prior to starting the edition.
Comment 7 Heiko Tietze 2024-08-23 08:03:28 UTC
Having a two-step escape sequence sounds reasonable to me. While escape currently cancels the cell editing it could cancel the auto-completion first. SO one has to press escape twice to leave.

I don't think this is much controversial.
Comment 8 SY 2024-08-27 04:11:41 UTC
(In reply to Heiko Tietze from comment #7)
> Having a two-step escape sequence sounds reasonable to me. While escape
> currently cancels the cell editing it could cancel the auto-completion
> first. SO one has to press escape twice to leave.
> 
> I don't think this is much controversial.

This is the behavior I would expect.
Comment 9 ady 2024-08-27 10:29:45 UTC
(In reply to SY from comment #8)
> (In reply to Heiko Tietze from comment #7)
> > Having a two-step escape sequence sounds reasonable to me. While escape
> > currently cancels the cell editing it could cancel the auto-completion
> > first. SO one has to press escape twice to leave.
> > 
> > I don't think this is much controversial.
> 
> This is the behavior I would expect.

Or just use [DEL] for one action and [ESC] for the other, without having to change anything in Calc.
Comment 10 SY 2024-08-28 03:33:48 UTC
(In reply to ady from comment #9)
> (In reply to SY from comment #8)
> > (In reply to Heiko Tietze from comment #7)
> > > Having a two-step escape sequence sounds reasonable to me. While escape
> > > currently cancels the cell editing it could cancel the auto-completion
> > > first. SO one has to press escape twice to leave.
> > > 
> > > I don't think this is much controversial.
> > 
> > This is the behavior I would expect.
> 
> Or just use [DEL] for one action and [ESC] for the other, without having to
> change anything in Calc.

The bigger problem is that navigating away from the cell you're editing automatically accepts the auto-completion.  I shouldn't have to manually delete the auto-complete text; it should be automatically deleted unless I explicitly accept it.
Comment 11 ady 2024-08-28 06:07:00 UTC
(In reply to SY from comment #10)

> The bigger problem is that navigating away from the cell you're editing
> automatically accepts the auto-completion.  I shouldn't have to manually
> delete the auto-complete text; it should be automatically deleted unless I
> explicitly accept it.

Let's recap.

The report was supposed to be about not being able to reject the AutoInput suggestion.

The current available method is [DEL] or [BACKSPACE].

Currently [ESC] cancels the edition (with or without a suggestion).


Then the issue seemed to move to "I'd rather have [ESC] do that", which would mean that the current action for [ESC] would require an additional key press, while there are already other 2 available keys that achieve the desired result.

Now we are moving to not automatically accepting the AutoInput suggestion, but rather automatically rejecting it unless manually accepted. I guess this is similar to when Calc suggests possible functions when typing-in; the user has to "accept" one of the suggestions (e.g. by typing the opening bracket for the function, or by [ENTER]), or press [CTRL]+[TAB] to change to the next suggested function.

While I can understand the concept (although I'm not sure which key(s) would _accept_ the suggestion, under such logic), I suspect that such change will not be OK with users that want to easily type repeating values in the same column. This means that, in order to have the flexibility that users expect from a spreadsheet tool, the AutoInput feature would have to include some kind of option, so the user would select whether to automatically accept the suggestion (by [ENTER]), or instead to automatically reject the suggestion (by [ENTER]). I admit I don't recall whether such option already exists somewhere.

I would argue that maybe a keyboard shortcut that allows to set the AutoInput OFF or ON during cell's edition should allow the desired behavior. The AutoInput feature is already available in menu Tools > Customize > Keyboard (corresponding to command .uno:AutoComplete).
Comment 12 Heiko Tietze 2024-08-28 08:33:29 UTC
(In reply to ady from comment #11)
> I suspect that such change will not be OK with users that want to easily
> type repeating values in the same column.
Those would press enter anyway to confirm the input and advance to the next cell downwards.

The first aspect is to escape to cancel the autocompletion. And I guess we are all on the same page here.

The second part is what happens on navigation, meaning autocompletion followed by tab. This advances to the next column and might indeed be used widely to confirm the editing.
Comment 13 ady 2024-08-28 13:10:54 UTC
(In reply to Heiko Tietze from comment #12)
> (In reply to ady from comment #11)
> > I suspect that such change will not be OK with users that want to easily
> > type repeating values in the same column.
> Those would press enter anyway to confirm the input and advance to the next
> cell downwards.

You did not understand what I wrote in comment 11. I'm not planning on explaining it again.

BTW, the last change on AutoInput (to work as bash auto-completion) was not discussed beforehand and was contested by many users after its (first and second) implementation, who were completely ignored.

FTR, I do not agree with changing what the first [ESC] is supposed to do, while we already have 2 other keys that act as desired, and when we can dynamically disable AutoInput by customizing keyboard shortcuts.
Comment 14 SY 2024-08-28 17:53:30 UTC
(In reply to ady from comment #11)
This means that, in order to have the flexibility that users expect
> from a spreadsheet tool, the AutoInput feature would have to include some
> kind of option, so the user would select whether to automatically accept the
> suggestion (by [ENTER]), or instead to automatically reject the suggestion
> (by [ENTER]). I admit I don't recall whether such option already exists
> somewhere.

Using enter to accept the suggestion would be manually, not automatically accepting it.  I think that both the ENTER and TAB should accept the suggestion and canceling edit mode in any way should automatically reject it.

I don't see how this negatively impacts users who want to quickly enter the same values into cells, as you're already using either ENTER or TAB to navigate to the next cell; but sure, making it configurable is always best.

The core issue is that the current behavior is non-standard (this is the only auto-complete feature I know of that auto-accepts suggestions like this) and obtrusive (it forces suggestions on the user unless they manually delete them).

It seems obvious to me that this was implemented this way not as a deliberate design choice, but rather out of convenience - it's a lot easier to implement an auto-complete that just types out the suggestion and selects that text (so the user can manually delete it) than it is to implement a proper system that gives suggestions and allows the user to accept them, inputting that text.

Ultimately I think the system should be reworked to bring it up to par with competing software and add features like selecting from a list of suggestions and the ability to edit the suggestions list and what kinds of things can be added to that list.
Comment 15 ady 2024-08-28 18:11:32 UTC
Comment 14 contradicts prior posts.

We have a communication problem, and a report that keeps changing its main focus.

I already expressed my opinion.
Comment 16 SY 2024-08-28 18:14:27 UTC
(In reply to ady from comment #15)
> Comment 14 contradicts prior posts.
> 
> We have a communication problem, and a report that keeps changing its main
> focus.
> 
> I already expressed my opinion.

Read the report again, nothing has changed.